ความแตกต่างระหว่างรหัสการเปลี่ยนเส้นทาง HTTP


151

ความแตกต่างระหว่างรหัสการเปลี่ยนเส้นทาง HTTP 3XX ต่างๆนั้นไม่ชัดเจนสำหรับฉัน ใช่ฉันอ่านสเป็คแล้ว แต่ดูเหมือนว่ามีความคลาดเคลื่อนระหว่างมาตรฐานและการปฏิบัติจริงที่นี่

301รหัสการเปลี่ยนเส้นทางดูเหมือนว่าพอที่ชัดเจนซึ่งหมายความว่าทรัพยากรที่ถูกย้ายอย่างถาวร URI อื่นและคำขอในอนาคตควรใช้ว่า URI

และ307รหัสการเปลี่ยนเส้นทางก็ชัดเจนเช่นกันนั่นหมายถึงการเปลี่ยนเส้นทางนั้นเป็นการชั่วคราวและคำขอในอนาคตยังควรใช้ URI ดั้งเดิม

แต่ฉันไม่สามารถบอกสิ่งที่แตกต่างระหว่าง302และหรือทำไมทั้งของพวกเขาเป็นจริงที่แตกต่างจาก303 301มันดูเหมือนว่า302เดิมทีตั้งใจจะเป็นชั่วคราวเปลี่ยนเส้นทาง (ชอบ307) 303แต่ในทางปฏิบัติมากที่สุดเบราว์เซอร์ได้รับการปฏิบัติเหมือน แต่ความแตกต่างระหว่าง a 303และ a 301คืออะไร? คือ301ควรจะหมายถึงการเปลี่ยนเส้นทางเป็นมากขึ้นอย่างถาวร?

คำตอบ:


139
  • 301 : การเปลี่ยนเส้นทางถาวร ลูกค้าที่ทำการร้องขอในภายหลังสำหรับทรัพยากรนี้ควรใช้ URI ใหม่ ลูกค้าไม่ควรติดตามการเปลี่ยนเส้นทางโดยอัตโนมัติสำหรับคำขอ POST / PUT / DELETE
  • 302 : เปลี่ยนเส้นทางด้วยเหตุผลที่ไม่ได้กำหนด ลูกค้าที่ทำการร้องขอในภายหลังสำหรับทรัพยากรนี้ไม่ควรใช้ URI ใหม่ ลูกค้าไม่ควรติดตามการเปลี่ยนเส้นทางโดยอัตโนมัติสำหรับคำขอ POST / PUT / DELETE
  • 303 : เปลี่ยนเส้นทางด้วยเหตุผลที่ไม่ได้กำหนด โดยปกติแล้ว 'การดำเนินการเสร็จสมบูรณ์แล้วดำเนินการต่อที่อื่น' ลูกค้าที่ทำการร้องขอในภายหลังสำหรับทรัพยากรนี้ไม่ควรใช้ URI ใหม่ ลูกค้าควรติดตามการเปลี่ยนเส้นทางสำหรับโพสต์ / PUT / คำขอลบ แต่การใช้งานจะได้รับการร้องขอติดตาม
  • 307 : การเปลี่ยนเส้นทางชั่วคราว ทรัพยากรอาจกลับมาที่ตำแหน่งนี้ในภายหลัง ลูกค้าที่ทำการร้องขอในภายหลังสำหรับทรัพยากรนี้ควรใช้ URI เก่า ลูกค้าไม่ควรติดตามการเปลี่ยนเส้นทางโดยอัตโนมัติสำหรับคำขอ POST / PUT / DELETE

ฉันเองแนะนำให้หลีกเลี่ยง 302 ถ้าคุณมีทางเลือก ไคลเอนต์จำนวนมากไม่ปฏิบัติตามข้อกำหนดเมื่อพวกเขาพบ 302 สำหรับการเปลี่ยนเส้นทางชั่วคราวคุณควรใช้ 303 หรือ 307 ขึ้นอยู่กับประเภทของพฤติกรรมที่คุณต้องการในคำขอที่ไม่ใช่ GET ชอบ 307 ถึง 303 ยกเว้นว่าคุณต้องการพฤติกรรมสำรองบน ​​POST / PUT / DELETE


26
Nope การติดตาม 303 ต้องมีการเขียนวิธีใหม่ให้กับ GET ติดตามคนอื่น ๆ ต้องรักษาวิธีการ แต่เพื่อยืนยันกับ UA หากวิธีการไม่ปลอดภัย (ดังนั้นวิธีการอื่นนอกเหนือจาก OPTIONS, HEAD, GET, PROPFIND ... )
Julian Reschke

1
@JulianReschke คุณช่วยชี้สถานที่ในสเปคสำรองคำสั่งของคุณได้ไหม?
Piotr Dobrogost

7
@BobAman ในคำอธิบายของคุณคุณกำลังทำผิดพลาดเหมือนกันในข้อมูลจำเพาะ HTTP ดั้งเดิม ( RFC 1945 ) ตัวอย่างเช่นบอกว่าลูกค้าควรทำตามการเปลี่ยนเส้นทางสำหรับคำขอ POST / PUT / DELETE หลังจากเปลี่ยนเส้นทาง 303 โดยไม่ระบุว่าคำกริยา http ที่ใช้ในคำขอต่อไปนี้ต้องเป็น GET ทำให้เข้าใจผิด ...
Piotr Dobrogost

2
การแก้ไขตัวเอง: "การทำตาม 303 จะต้องเขียนวิธีการใหม่ให้กับ GET เว้นแต่วิธีเริ่มต้นคือ HEAD"
Julian Reschke

2
Piotr: เริ่มต้นควรจะไม่ได้ที่จะปรับเปลี่ยนวิธีการ; ย้ายทรัพยากรแล้วซึ่งไม่มีผลกระทบต่อวิธีการจัดการ 303 เป็นข้อยกเว้น; ไม่ได้แปลว่า "ทรัพยากรย้ายแล้ว" แต่ "คำขอได้รับการประมวลผลและนี่คือผลลัพธ์ของคุณ"; เป็นการเปลี่ยนเส้นทางประเภทอื่นทั้งหมด ดูgreenbytes.de/tech/webdav/…
Julian Reschke

84

ข้อแตกต่างระหว่าง 303 กับ 307 คือ:

303 : ดูอื่น ๆ ได้รับคำขออย่างถูกต้อง แต่ควรดึงผลลัพธ์โดยใช้ GET บน URL เปลี่ยนเส้นทาง

307 : การเปลี่ยนเส้นทางชั่วคราว คำขอทั้งหมดควรถูกเปลี่ยนเส้นทางไปยัง URL ใหม่ ข้อมูลโพสต์ใด ๆ ควรโพสต์ใหม่

โปรดทราบว่า302มีวัตถุประสงค์เพื่อให้มีพฤติกรรมที่ 307 แต่เบราว์เซอร์ส่วนใหญ่ใช้งานเป็นพฤติกรรมของ 303 (ซึ่งทั้งสองอย่างนี้ไม่ได้มีอยู่แล้ว) ดังนั้นทั้งสองรหัสใหม่ได้รับการแนะนำเพื่อแทนที่ 302

ความแตกต่างระหว่าง 301 และ 303:

301 : เอกสารถูกย้าย คำขอในอนาคตควรใช้ URL ใหม่ URL นี้ล้าสมัยแล้ว

หมายเหตุ: ระมัดระวังรหัสนี้ เบราว์เซอร์และพรอกซีมีแนวโน้มที่จะใช้การแคชที่ก้าวร้าวกับมันดังนั้นหากคุณตอบกลับด้วย 301 อาจใช้เวลานานพอสมควรที่จะมีคนมาเยี่ยมชม URL นั้นอีกครั้ง

303 : ได้รับคำขออย่างถูกต้อง คำขอ PUT จะได้รับการประมวลผล เอกสารส่งผลให้สามารถเรียกข้อมูลจาก URL การเปลี่ยนเส้นทาง คำขอในอนาคตยังควรไปที่ URL ดั้งเดิม


โพสต์บล็อกที่ดีซึ่งจะกล่าวถึงรายละเอียดของ 3xx (และปัญหาทั้งหมดที่มี) อยู่ที่: insanecoding.blogspot.no/2014/02/ …
arcuri82

@ skeller88 คุณเปลี่ยนทำให้คำตอบของฉันไม่ถูกต้องดังนั้นฉันจึงเปลี่ยนกลับ (ให้คนที่ยอมรับการเปลี่ยนแปลง) คุณแนะนำข้อผิดพลาดเช่นเดียวกับคำตอบที่ยอมรับได้ 303 เป็นการเปลี่ยนเส้นทางประเภทอื่นและมีการใช้กฎที่แตกต่างกันตามที่ได้รับการยืนยันโดยความคิดเห็นของ Julian Reschke ในคำตอบที่ยอมรับและบล็อกที่เชื่อมโยงโดย arcuri82
GolezTrol
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.