Tiêu đề phản hồi HTTP trùng lặp có được chấp nhận không?


123

Tôi chưa tìm thấy bất kỳ thông số kỹ thuật nào về việc liệu tiêu đề phản hồi HTTP trùng lặp có được phép theo tiêu chuẩn hay không, nhưng tôi cần biết liệu điều này có gây ra sự cố tương thích hay không.

Giả sử tôi có một tiêu đề phản hồi như sau:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: no-cache
Cache-Control: no-store
Location: http://localhost:9876/foo.bar
Content-Language: en-US
Content-Length: 0
Date: Mon, 06 Dec 2010 21:18:26 GMT

Lưu ý rằng có hai Cache-Controltiêu đề có giá trị khác nhau. Có phải các trình duyệt luôn coi chúng như thể chúng được viết như "Cache-Control: no-cache, no-store" không?

Câu trả lời:


157

Đúng

HTTP RFC2616 có sẵn ở đây cho biết:

Nhiều trường tiêu đề thư có cùng tên trường CÓ THỂ có trong thư nếu và chỉ khi toàn bộ trường-giá trị cho trường tiêu đề đó được xác định là danh sách được phân tách bằng dấu phẩy [tức là, # (giá trị)]. PHẢI có thể kết hợp nhiều trường tiêu đề thành một cặp "field-name: field-value", mà không làm thay đổi ngữ nghĩa của thông báo, bằng cách nối mỗi trường-giá trị tiếp theo vào đầu tiên, mỗi trường được phân tách bằng dấu phẩy. Do đó, thứ tự mà các trường tiêu đề có cùng tên trường được nhận có ý nghĩa quan trọng đối với việc diễn giải giá trị trường kết hợp và do đó proxy KHÔNG ĐƯỢC thay đổi thứ tự của các giá trị trường này khi một thông báo được chuyển tiếp

Vì vậy, nhiều tiêu đề có cùng tên là ok (www-authenticate là một trường hợp như vậy) nếu toàn bộ giá trị trường được xác định là danh sách các giá trị được phân tách bằng dấu phẩy.

Cache-control được ghi lại ở đây: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 như thế này:

Cache-Control   = "Cache-Control" ":" 1#cache-directive

Các #1cache-directivecú pháp định nghĩa một danh sách ít nhất một yếu tố bộ nhớ cache-chỉ (xem ở đây để định nghĩa chính thức của #values: ước Notational và Generic Grammar )

Vì vậy, vâng,

Cache-Control: no-cache, no-store

tương đương với (thứ tự là quan trọng)

Cache-Control: no-cache
Cache-Control: no-store

2
Cảm ơn bạn đã phản hồi nhanh chóng, Simon! Nhưng không phải đoạn trích dẫn từ RFC 2616 cũng áp dụng cho Cache-Control? Tui bỏ lỡ điều gì vậy?
Su Zhang

1
Gần như đúng 100%. Bộ nhớ cache Control cho phép cho nhiều giá trị: Cache-Control = "Cache-Control" ":" 1#cache-directive. Chú ý #trước cache-directive. Cho biết nhiều giá trị được chấp nhận (ngay từ định nghĩa của bạn ở trên) ...
ircmaxell

1
"nếu và chỉ khi toàn bộ giá trị trường cho trường tiêu đề đó được xác định là danh sách được phân tách bằng dấu phẩy" - đối với tôi nghe có vẻ như nhiều giá trị phải được xác định là danh sách được phân tách bằng dấu phẩy, tức là chúng không thể được tách ra dưới dạng các tiêu đề riêng biệt.
mpen

2
@mark - "được định nghĩa là danh sách được phân tách bằng dấu phẩy" ở đây có nghĩa là "được định nghĩa trong ngữ pháp BNF là danh sách được phân tách bằng dấu phẩy". Các trường Cache-control thực sự được định nghĩa như vậy (x # blahblah).
Simon Mourier

2
Phần trong RFC 7230 mới hơn nói về việc xử lý nhiều tiêu đề là tools.ietf.org/html/rfc7230#section-3.2.2
Matthew Buckett

0

Lưu ý rằng HSTS RFC6797 mâu thuẫn với RFC2616 (vi phạm ngôn ngữ "nếu và chỉ nếu") bằng cách xác định hành vi cho nhiều trường hợp của tiêu đề STS, mặc dù nó không được điền bằng các giá trị được phân tách bằng dấu phẩy:

  "If a UA receives more than one STS header field in an HTTP
  response message over secure transport, then the UA MUST process
  only the first such header field."

Sai. RFC6797 KHÔNG xác định tiêu đề STS chứa danh sách được phân tách bằng dấu phẩy. Vì vậy, quy tắc "nếu và chỉ nếu" từ RFC 2616 cũng áp dụng giống nhau (nghĩa là KHÔNG cho phép nhiều tiêu đề STS vì tiêu đề STS không được định nghĩa là sử dụng danh sách được phân tách bằng dấu phẩy). RFC6797 chỉ làm cho nó không xác định được hậu quả của việc vi phạm quy tắc đó, điều mà RFC2616 dường như bỏ ngỏ.
Frans
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.