2013-07-12 39 views
12

Hành vi đúng mong đợi của POST => 302 chuyển hướng đến GET là gì?Hành vi đúng mong đợi của chuyển hướng HTTP POST => 302 là GET là gì?

Trong chrome (và hầu hết mọi trình duyệt), sau I POST (tài nguyên muốn tôi chuyển hướng) và tôi nhận được chuyển hướng 302, trình duyệt tự động phát hành GET ở vị trí 302. Đây thậm chí là well known pattern. Nhưng cách tôi đọc spec, có vẻ như đề nghị điều này không nên xảy ra.

The HTTP spec says

Nếu mã 302 trạng thái được nhận để đáp ứng với yêu cầu khác hơn GET hoặc HEAD, user agent PHẢI KHÔNG tự động chuyển hướng các yêu cầu trừ khi nó có thể được xác nhận bởi người dùng, vì điều này có thể thay đổi các điều kiện theo đó yêu cầu được đưa ra.

Và cáy đang hiển thị:

REQUEST 1: POST URLA 
RESPONSE 1: 302 redirect to URLB 
REQUEST 2: GET URLB 

Phần dường như trên để nói rằng trình duyệt không nên thực hiện các yêu cầu GET? Tôi đang thiếu gì?

  1. Something trước đó trong spec mà làm cho phần này không liên quan
  2. sự hiểu biết của tôi về tự động chuyển hướng là sai (và trình duyệt chrome mà đã làm các GET đã không thực sự tự động chuyển hướng)
  3. sự hiểu biết của tôi về xác nhận điều này với tư cách là người dùng
  4. Cái gì khác?

Trả lời

13

Điểm mấu rất tiếp theo trong spec bắt đầu:

Lưu ý: RFC 1945 và 2068 xác định rằng khách hàng không được phép để thay đổi phương pháp theo yêu cầu chuyển hướng. Tuy nhiên, hầu hết việc triển khai tác nhân người dùng hiện tại xử lý 302 như thể đó là phản hồi 303 , thực hiện GET trên giá trị trường Vị trí bất kể của phương thức yêu cầu ban đầu. Các mã trạng thái 303 và 307 có được thêm vào cho các máy chủ muốn làm rõ ràng rõ ràng rằng loại phản ứng được mong đợi của khách hàng.

Và ngay sau đó, nó giải thích cách xử lý 303 và chính xác là những gì bạn đang thấy.


Nếu bạn đang thắc mắc tại sao các máy chủ vẫn đang sử dụng 302 thay vì 307, mà tất cả các trình duyệt hiện nay sẽ xử lý một cách chính xác, đó là vì các trình duyệt cũ sẽ không xử lý nó. Nếu bạn đang tự hỏi tại sao các trình duyệt xử lý 302 là 303, đó là vì các máy chủ cũ mong đợi nó. Thực sự không có cách nào thoát khỏi vòng lặp đó và có lẽ sẽ tốt hơn cho HTTP để hoàn nguyên 302 để có nghĩa là nó đã có ý nghĩa và không dùng nó (cho non-GET/HEAD) để ủng hộ 307.

+1

abarnet: xin vui lòng làm rõ những gì bạn có ý nghĩa bởi "trình duyệt cũ". –

+0

@JulianReschke: Tôi không biết chính xác. Nếu tôi đã đoán, tôi đoán cổ điển là khoảng IE6 và FF 1.9. Nhưng hãy nhớ rằng các trình duyệt trên máy tính để bàn (và các trình duyệt di động WebKit) không phải là các tác nhân người dùng duy nhất trên mạng; có rất nhiều người sử dụng các thiết bị khác có trình duyệt trong đó, khách hàng dịch vụ web được mã hóa bằng tay hoặc công cụ cạo, v.v. – abarnert

+0

@JulianReschke: Ngoài ra, tôi nên đề cập rằng 303 và 307 chỉ có trong HTTP/1.1. Có rất nhiều máy chủ và lưu trữ trên đó (và một số tác nhân người dùng) không thể xử lý 1.1 hoặc vô hiệu hóa nó. Trong khi đó, tôi chỉ tìm thấy [bài đăng trên blog] (http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on- http-methods-like-head-get-post-and-delete.aspx) từ nhóm IE có vẻ phù hợp. – abarnert

0

abarnert đã đúng! Tôi đã gặp vấn đề tương tự với Google App Engine nhưng tôi đã tìm thấy một giải pháp khác.

Vấn đề của tôi với appengine là, tôi đã gửi một POST với biểu mẫu tới biểu mẫu GO tại chương trình phụ trợ. Nhưng nó đã được thực hiện như sau.

yêu cầu 1: GET/formHandler -> phản ứng 1: 302 Tìm thấy

yêu cầu 1: POST/formHandler -> phản ứng 1: 302 Tìm thấy

yêu cầu 1: GET/formHandler -> phản ứng 1: 200 Được.

Additionaly tôi đã

Không 'Access-Control-Allow-Origin' tiêu đề là hiện tại trên tài nguyên yêu cầu

nào là một vấn đề CORS.

Tuy nhiên, các giải pháp hóa ra là sử dụng HTTP S thay vì HTTP.

Sau đó, bạn sẽ có

yêu cầu: POST/formHandler -> phản ứng: 200 Ok

Các vấn đề liên quan