เมื่อผู้ใช้ไม่ได้เข้าสู่ระบบและพยายามเข้าถึงหน้าที่ต้องเข้าสู่ระบบรหัสสถานะ HTTP ที่ถูกต้องสำหรับการเปลี่ยนเส้นทางไปยังหน้าล็อกอินคืออะไร
ฉันขอเพราะไม่มี รหัสตอบกลับ 3xx ที่กำหนดโดย W3C ดูเหมือนว่าจะตรงกับข้อกำหนด:
10.3.1 300 ทางเลือกหลายทาง
ทรัพยากรที่ร้องขอจะสอดคล้องกับชุดการเป็นตัวแทนชุดใดชุดหนึ่งแต่ละชุดมีตำแหน่งเฉพาะของตนเองและมีการจัดเตรียมข้อมูลการเจรจาที่ขับเคลื่อนด้วยตัวแทน (ส่วนที่ 12) เพื่อให้ผู้ใช้ (หรือตัวแทนผู้ใช้) สามารถเลือกการแสดงที่ต้องการและเปลี่ยนเส้นทางได้ ร้องขอไปยังสถานที่นั้น
เว้นแต่จะเป็นคำขอ HEAD การตอบสนองควรรวมเอนทิตีที่มีรายการลักษณะทรัพยากรและตำแหน่งที่ตั้งซึ่งผู้ใช้หรือตัวแทนผู้ใช้สามารถเลือกสิ่งที่เหมาะสมที่สุดได้ รูปแบบเอนทิตีถูกระบุโดยประเภทสื่อที่กำหนดในฟิลด์ส่วนหัวประเภทเนื้อหา ขึ้นอยู่กับรูปแบบและความสามารถของ
ตัวแทนผู้ใช้การเลือกตัวเลือกที่เหมาะสมที่สุดอาจดำเนินการโดยอัตโนมัติ อย่างไรก็ตามข้อกำหนดนี้ไม่ได้กำหนดมาตรฐานใด ๆ สำหรับการเลือกอัตโนมัติดังกล่าว
หากเซิร์ฟเวอร์มีทางเลือกในการเป็นตัวแทนที่ต้องการเซิร์ฟเวอร์ควรรวม URI เฉพาะสำหรับการแสดงนั้นในฟิลด์ตำแหน่ง ตัวแทนผู้ใช้อาจใช้ค่าฟิลด์ตำแหน่งสำหรับการเปลี่ยนเส้นทางอัตโนมัติ การตอบสนองนี้สามารถแคชได้เว้นแต่จะระบุไว้เป็นอย่างอื่น
10.3.2 301 ย้ายถาวร
ทรัพยากรที่ร้องขอได้รับการกำหนด URI ถาวรใหม่และการอ้างอิงในอนาคตไปยังทรัพยากรนี้ควรใช้หนึ่งใน URI ที่ส่งคืน ไคลเอ็นต์ที่มีความสามารถในการแก้ไขลิงก์ควรเชื่อมโยงการอ้างอิงไปยัง Request-URI ใหม่โดยอัตโนมัติกับการอ้างอิงใหม่ที่เซิร์ฟเวอร์ส่งคืนหากเป็นไปได้ การตอบสนองนี้สามารถแคชได้เว้นแต่จะระบุไว้เป็นอย่างอื่น
URI ถาวรใหม่ควรได้รับจากฟิลด์ Location ในการตอบกลับ เว้นแต่วิธีการร้องขอคือ HEAD เอนทิตีของการตอบสนองควรมีไฮเปอร์เท็กซ์สั้น ๆ ที่มีไฮเปอร์ลิงก์ไปยัง URI ใหม่
หากได้รับรหัสสถานะ 301 ตามคำขออื่นที่ไม่ใช่ GET หรือ HEAD เอเจนต์ผู้ใช้จะต้องไม่เปลี่ยนเส้นทางคำขอโดยอัตโนมัติเว้นแต่จะได้รับการยืนยันจากผู้ใช้เนื่องจากอาจเปลี่ยนแปลงเงื่อนไขในการออกคำขอได้
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 พบ
ทรัพยากรที่ร้องขออยู่ชั่วคราวภายใต้ URI อื่น เนื่องจากการเปลี่ยนเส้นทางอาจมีการเปลี่ยนแปลงในบางครั้งไคลเอ็นต์จึงควรใช้ Request-URI ต่อไปสำหรับคำขอในอนาคต การตอบกลับนี้สามารถใช้แคชได้หากระบุโดยฟิลด์ส่วนหัว Cache-Control หรือ Expires
URI ชั่วคราวควรได้รับจากฟิลด์ Location ในการตอบกลับ เว้นแต่วิธีการร้องขอคือ HEAD เอนทิตีของการตอบสนองควรมีไฮเปอร์เท็กซ์สั้น ๆ ที่มีไฮเปอร์ลิงก์ไปยัง URI ใหม่
หากได้รับรหัสสถานะ 302 ตามคำขออื่นที่ไม่ใช่ GET หรือ HEAD เอเจนต์ผู้ใช้จะต้องไม่เปลี่ยนเส้นทางคำขอโดยอัตโนมัติเว้นแต่จะได้รับการยืนยันจากผู้ใช้เนื่องจากอาจเปลี่ยนแปลงเงื่อนไขในการออกคำขอ
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itเป็นการตอบกลับ 303 โดยดำเนินการ GET ในค่าฟิลด์ตำแหน่งโดยไม่คำนึงถึงวิธีการร้องขอเดิม มีการเพิ่มรหัสสถานะ 303 และ 307 สำหรับเซิร์ฟเวอร์ที่ต้องการสร้างความชัดเจนอย่างชัดเจนว่าลูกค้าคาดหวังปฏิกิริยาใด
10.3.4 303 ดูอื่น ๆ
การตอบกลับคำขอสามารถพบได้ภายใต้ URI ที่แตกต่างกันและควรดึงข้อมูลโดยใช้เมธอด GET บนทรัพยากรนั้น วิธีนี้มีอยู่เป็นหลักเพื่ออนุญาตให้เอาต์พุตของสคริปต์ที่เปิดใช้งาน POST เปลี่ยนทิศทางตัวแทนผู้ใช้ไปยังรีซอร์สที่เลือก URI ใหม่ไม่ใช่การอ้างอิงทดแทนสำหรับทรัพยากรที่ร้องขอในตอนแรก การตอบกลับ 303 ต้องไม่ถูกแคช แต่การตอบกลับคำขอที่สอง (เปลี่ยนเส้นทาง) อาจเป็นแคชได้
URI ที่แตกต่างกันควรได้รับจากฟิลด์ Location ในการตอบกลับ เว้นแต่วิธีการร้องขอคือ HEAD เอนทิตีของการตอบสนองควรมีไฮเปอร์เท็กซ์สั้น ๆ ที่มีไฮเปอร์ลิงก์ไปยัง URI ใหม่
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 ไม่ได้แก้ไข
หากไคลเอ็นต์ดำเนินการร้องขอ GET แบบมีเงื่อนไขและอนุญาตให้เข้าถึงได้ แต่เอกสารไม่ได้รับการแก้ไขเซิร์ฟเวอร์ควรตอบสนองด้วยรหัสสถานะนี้ การตอบกลับ 304 ต้องไม่มีเนื้อความดังนั้นจึงมักจะสิ้นสุดโดยบรรทัดแรกว่างหลังฟิลด์ส่วนหัว
คำตอบต้องมีฟิลด์ส่วนหัวต่อไปนี้:
- Date, unless its omission is required by section 14.18.1 If aเซิร์ฟเวอร์ต้นทางที่ไม่ใช้นาฬิกาปฏิบัติตามกฎเหล่านี้และพร็อกซีและไคลเอนต์จะเพิ่มวันที่ของตนเองลงในการตอบกลับใด ๆ ที่ได้รับโดยไม่มีวันที่ (ตามที่ระบุไว้แล้วโดย [RFC 2068] ส่วน 14.19) แคชจะทำงานได้อย่างถูกต้อง
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seeส่วน 13.3.3) คำตอบไม่ควรรวมส่วนหัวของเอนทิตีอื่น ๆ มิฉะนั้น (กล่าวคือ GET ตามเงื่อนไขใช้ตัวตรวจสอบความถูกต้องที่อ่อนแอ) การตอบสนองจะต้องไม่รวมส่วนหัวของเอนทิตีอื่น ๆ สิ่งนี้จะป้องกันความไม่สอดคล้องกันระหว่างเนื้อหาเอนทิตีที่แคชและส่วนหัวที่อัปเดต
หากการตอบกลับ 304 ระบุว่าเอนทิตีไม่ได้ถูกแคชไว้แคชจะต้องไม่สนใจการตอบกลับและทำซ้ำคำขอโดยไม่มีเงื่อนไข
หากแคชใช้การตอบกลับ 304 ที่ได้รับเพื่ออัปเดตรายการแคชแคชจะต้องอัปเดตรายการเพื่อแสดงค่าฟิลด์ใหม่ที่ระบุในการตอบกลับ
10.3.6 305 ใช้ Proxy
ต้องเข้าถึงทรัพยากรที่ร้องขอผ่านพร็อกซีที่กำหนดโดยฟิลด์ตำแหน่ง ฟิลด์ตำแหน่งให้ URI ของพร็อกซี คาดว่าผู้รับจะทำซ้ำคำขอเดียวนี้ผ่านทางพร็อกซี 305 คำตอบต้องสร้างโดยเซิร์ฟเวอร์ต้นทางเท่านั้น
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (ไม่ได้ใช้)
รหัสสถานะ 306 ถูกใช้ในข้อกำหนดรุ่นก่อนหน้านี้ไม่ได้ใช้อีกต่อไปและมีการสงวนรหัสไว้
10.3.8 307 การเปลี่ยนเส้นทางชั่วคราว
ทรัพยากรที่ร้องขออยู่ชั่วคราวภายใต้ URI อื่น เนื่องจากการเปลี่ยนเส้นทางอาจมีการเปลี่ยนแปลงในบางครั้งไคลเอนต์จึงควรใช้ Request-URI ต่อไปสำหรับคำขอในอนาคต การตอบกลับนี้สามารถใช้แคชได้หากระบุโดยฟิลด์ส่วนหัว Cache-Control หรือ Expires
URI ชั่วคราวควรได้รับจากฟิลด์ Location ในการตอบกลับ เว้นแต่วิธีการร้องขอคือ HEAD เอนทิตีของการตอบกลับควรมีไฮเปอร์เท็กซ์สั้น ๆ ที่มีไฮเปอร์ลิงก์ไปยัง URI ใหม่เนื่องจากเอเจนต์ผู้ใช้พรี HTTP / 1.1 จำนวนมากไม่เข้าใจสถานะ 307 ดังนั้นหมายเหตุควรมีข้อมูลที่จำเป็นสำหรับผู้ใช้ในการทำซ้ำคำขอเดิมใน URI ใหม่
หากได้รับรหัสสถานะ 307 ตามคำขออื่นที่ไม่ใช่ GET หรือ HEAD ตัวแทนผู้ใช้ต้องไม่เปลี่ยนเส้นทางคำขอโดยอัตโนมัติเว้นแต่จะได้รับการยืนยันจากผู้ใช้เนื่องจากอาจเปลี่ยนแปลงเงื่อนไขในการออกคำขอ
ตอนนี้ฉันใช้ 302 จนกระทั่งพบไฟล์ตอบที่ถูกต้อง
อัปเดตและสรุป:
HTTP 302 ดีกว่าเนื่องจากทราบว่ามีความเข้ากันได้ดีที่สุดกับไคลเอนต์ / เบราว์เซอร์