2014-10-05 21 views
12

Tôi có một cuộc thảo luận tuyệt vời về khái niệm với đồng nghiệp của tôi về việc sử dụng tiêu đề Vị trí trong 202 Phản hồi được chấp nhận.Việc sử dụng tiêu đề Vị trí trong phản hồi RFC HTTP 202 có tuân thủ không?

Câu chuyện bắt đầu phân tích hành vi của hàm PHP header() từ here. Đoạn trích thú vị:

Trường hợp đặc biệt thứ hai là tiêu đề "Vị trí:". Nó không chỉ gửi tiêu đề này trở lại trình duyệt mà còn trả về mã trạng thái REDIRECT (302) cho trình duyệt trừ khi mã trạng thái 201 hoặc mã 3xx đã được đặt.

Chúng không bao gồm 202 mã trạng thái trong hành vi mặc định này. Có vẻ như họ không mong đợi rằng 202 phản hồi có Vị trí và thực sự:

header("HTTP/1.1 202"); 
header("Location: http://example.com"); 

chuyển hướng khách hàng đến URL vị trí. Tất nhiên, có thể thay đổi hành vi này với tham số thứ ba của hàm header() nhưng điều thu hút sự chú ý của tôi là: Tại sao họ hiểu rằng theo mặc định 202 không được mong đợi để giữ tiêu đề Vị trí?

Sau đó, tôi xem lại RFC để tìm ý nghĩa chính thức của 202 trạng thái. Đoạn trích thú vị:

Thực thể trả về với phản hồi này NÊN bao gồm chỉ báo trạng thái hiện tại của yêu cầu và con trỏ đến màn hình trạng thái hoặc ước tính thời điểm người dùng có thể mong đợi yêu cầu được hoàn thành.

Nó không đề cập rõ ràng đến tiêu đề Vị trí như trước đây (trong cùng một tài liệu RFC) 201 phản hồi. Điều đó có lẽ sẽ là lý do tại sao PHP guys hiểu rằng 202 phản ứng không nên giữ tiêu đề Location. Một con trỏ có được hiểu là tiêu đề Vị trí hoặc các tên PHP đã đưa ra giả định sai? Nếu tiêu chuẩn cho phép tiêu đề Vị trí có 202 phản hồi: không nên là tài liệu chính thức rõ ràng hơn như định nghĩa phản hồi 201?

Cuối cùng tôi xem xét các phiên bản recently RFC nhất và tìm thấy một thay đổi nhỏ trong soạn thảo:

Các đại diện gửi với phản ứng này nên để mô tả tình trạng hiện tại của yêu cầu và điểm đến (hoặc nhúng) theo dõi trạng thái đó cung cấp cho người dùng ước tính thời điểm yêu cầu sẽ được thực hiện.

Một lần nữa, không đủ rõ ràng để giả định rằng trỏ đến có nghĩa là Tiêu đề vị trí.

Tóm lại, sau các sửa đổi ở trên: Tôi có tuân thủ RFC khi sử dụng tiêu đề Vị trí với 202 phản hồi không?

Trả lời

15

Cuối cùng, tôi nhận được phản hồi từ R. Fielding:

enter image description here

202 là một trạng thái thành công. Con trỏ được đề cập chỉ là siêu văn bản trong phần phản hồi. Cần gửi 303 nếu bạn muốn sử dụng Vị trí để chuyển hướng ứng dụng đến một tài nguyên khác. Kết quả của việc yêu cầu chuyển hướng có thể là một 202.

.... Roy

Vì vậy, tiêu đề Địa điểm không nên được sử dụng trong 202 Accepted phản ứng. Các chàng trai PHP đã giải thích đúng.

Sửa Tháng Ba, 2017: Xin lỗi, tôi quên để thêm thông điệp khác mà chúng tôi đã trao đổi trong cùng một thread lúc đó vì vậy tôi đang đăng ngay bây giờ cho các hồ sơ:

tôi:Trên section 4.1 of the RFC 7240 sự tác giả (J. Snell) đưa ra một ví dụ sử dụng tiêu đề Vị trí trong 202 Phản hồi được chấp nhận. Anh ta có sai không? Nó giống như nhiều người hiểu hành vi này từ RFC 7231. Bạn có thể gửi cho tôi bất kỳ tham chiếu nào về vấn đề gây tranh cãi này không?

Roy:Ví dụ được đưa ra mà không cần hướng dẫn, vì vậy ông không phải là sai vì ông không nói ý nghĩa của nó. Vị trí có thể được gửi trong bất kỳ tin nhắn nào. Ý nghĩa của nó chỉ được xác định cho các mã trạng thái nhất định.

Ví dụ, nếu ông đã nói rằng tác nhân người dùng sẽ tận dụng rằng lĩnh vực Location để cung cấp một chỉ báo tình trạng cho người dùng, sau đó ông sẽ có được sai. Đó có thể là một ý tưởng hay, nhưng không phải là một phần của tiêu chuẩn.

PHP làm cho một giả định sai lầm rằng vị trí được chỉ được sử dụng trong 201 và phản ứng 3xx, nhưng nó được phép làm như vậy bởi vì API nội bộ của mình không HTTP là; nó chuyển luồng sang HTTP để thay thế.

Không có tranh cãi. Để trở thành một phần của tiêu chuẩn, tại ít nhất hai triển khai độc lập sẽ phải hiển thị cùng một hành vi . Trong trường hợp này, không ai làm được.

7

Từ RFC-2616:

Thực thể trở lại với phản ứng này nên bao gồm một dấu hiệu của tình trạng hiện tại của yêu cầu và hoặc là một con trỏ đến một màn hình trạng thái hoặc một số ước tính khi người dùng có thể mong đợi yêu cầu được hoàn thành.

Tôi nghĩ khóa ở đây là "thực thể", vì câu hỏi ở đây là liệu chúng tôi có bao gồm chỉ báo trạng thái trong tiêu đề phản hồi hoặc trong nội dung phản hồi hay không.Hầu như ở khắp mọi nơi một thực thể được đề cập đến, nó có vẻ hàm ý cơ thể phản ứng. Ví dụ:

10,5 Server Error 5xx

mã trạng thái phản ứng bắt đầu với chữ số "5" chỉ ra trường hợp trong đó các máy chủ là nhận thức được rằng nó đã sai lầm hoặc không có khả năng thực hiện theo yêu cầu. Ngoại trừ khi trả lời yêu cầu HEAD, máy chủ NÊN bao gồm một thực thể có chứa một lời giải thích về tình trạng lỗi, và cho dù đó là một tình trạng tạm thời hoặc vĩnh viễn. Tác nhân người dùng NÊN hiển thị bất kỳ thực thể được bao gồm nào cho người dùng. Các mã phản hồi này được áp dụng cho bất kỳ phương thức yêu cầu nào.

Tôi chưa thấy trình duyệt bao giờ hiển thị tiêu đề phản hồi cho người dùng. Và đối với 303s:

10.3.4 303 Xem Khác

URI khác nhau NÊN được đưa ra bởi các lĩnh vực Vị trí trong các phản ứng. Trừ khi phương thức yêu cầu là HEAD, thực thể của câu trả lời NÊN chứa một lưu ý siêu văn bản ngắn với một siêu liên kết tới (các) URI mới.

Bạn sẽ không nhận được phản hồi siêu văn bản trong tiêu đề.

Tuy nhiên, section 7 là khá rõ ràng về những gì thực thể đề cập đến:

Một thực thể bao gồm các lĩnh vực tổ chức-header và một tổ chức cơ thể, mặc dù một số phản ứng sẽ chỉ bao gồm các thực thể tiêu đề.

Tôi nghĩ rằng trong trường hợp của bạn, những gì bạn đang làm là tuân thủ RFC-2616. Tuy nhiên, thực tế tất cả điều này đi xuống để thực hiện khách hàng. Khách hàng có thể nhận được phản hồi 202 của bạn xử lý một tiêu đề Location: cho một phản hồi 2xx không? Đó là bài kiểm tra ngữ pháp của bạn về cách trả lời và cũng là bài kiểm tra được sử dụng để thúc đẩy các tiêu chuẩn trong quá trình chuẩn hóa/tài liệu của họ.

+0

Làm theo lời giải thích của bạn, tôi nên thực hiện ** khái niệm ** đối tượng dưới dạng ** đối tượng **. Tuyệt quá! nhưng nếu điều này là đúng thì RFC 2616: *** Các thực thể ** trả lại với phản ứng này ... * có nghĩa là chỉ thị trạng thái nên được đặt trong cơ quan thực thể, KHÔNG ở vị trí. Mọi tiêu đề có thể có của tiêu đề Vị trí đã được đề cập rõ ràng trên toàn bộ RFC như tôi đã thấy. Có Tôi biết rằng nó sẽ đơn giản như chỉ bao gồm Vị trí, sau đó đọc nó từ khách hàng nhưng câu hỏi của tôi là thực sự nếu nó là khái niệm đúng theo RFC. – Delmo

+0

Tôi nghĩ rằng nó phù hợp với văn bản của RFC. – Brad

+0

Cảm ơn bạn đã giải thích. Tôi đã bình chọn. Vấn đề này không đủ rõ ràng cho tôi. Tôi thực sự tin rằng RFC nên rõ ràng hơn một chút hoặc có thể tôi cần phản hồi từ các tác giả RFC (LOL). – Delmo

-1

RFC thừa nhận mơ hồ về khái niệm đó. Điều này có nghĩa là thông số kỹ thuật hiện tại không cho biết cách "Vị trí" được sử dụng với 202, nhưng mặt khác, nó không phải là giấy phép cho các thư viện chỉ đơn giản là thay thế mã trạng thái. Vì vậy, đây chắc chắn là một lỗi PHP.

+0

Nó không phải là một lỗi, nó cũng tài liệu và chức năng dự định. Điều đó không có nghĩa là bạn phải thích nó hoặc đồng ý với quyết định mà các tác giả PHP thực hiện. – Brad

+0

Tôi không tin rằng đó là một lỗi nhưng chỉ là một quyết định thực hiện dựa trên giả định rằng chỉ có 201 phản hồi và 300 gia đình phản hồi cần tiêu đề Vị trí. Do đó, theo mặc định, họ chỉ định mã trạng thái 302 cho phản hồi bạn đặt tiêu đề Vị trí vào trừ khi bạn xác định phản hồi có liên quan đến Vị trí cụ thể hơn (201 hoặc 3xx). Tôi cho rằng họ đã cố gắng "giúp chúng tôi" ngăn chặn việc tạo phản hồi RFC hoặc vô nghĩa không tuân thủ, ví dụ: 200 phản hồi với tiêu đề Vị trí không có ý nghĩa. Trong cùng một cách họ giả định rằng 202 phản ứng không có ý nghĩa, do đó họ ghi đè mã trạng thái với 302. – Delmo

+0

Tôi đã gửi email tới Roy Fielding để làm rõ vấn đề này. Tôi sẽ giữ cho bạn được đăng. – Delmo

2

Thực ra, theo số 7240 http://tools.ietf.org/html/rfc7240#section-4.1, bạn có thể gửi 202 Mã trạng thái cùng với tiêu đề Vị trí. Đó sẽ là một phản ứng không đồng bộ, mặc dù, rõ ràng, PHP sẽ không cho phép bạn làm như vậy.

+0

Tuyệt vời !!! Tôi liên lạc với Roy để giúp tôi làm rõ điều này. Có lẽ tôi sẽ cập nhật phản hồi của tôi. Tôi đã bình chọn câu trả lời của bạn. – Delmo

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