Czy dopuszczalne są zduplikowane nagłówki odpowiedzi HTTP?

123

Nie znalazłem żadnej specyfikacji dotyczącej tego, czy zduplikowane nagłówki odpowiedzi HTTP są dozwolone przez standard, ale muszę wiedzieć, czy spowoduje to problemy ze zgodnością.

Powiedzmy, że mam taki nagłówek odpowiedzi:

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

Zwróć uwagę, że istnieją dwa Cache-Controlnagłówki z różnymi wartościami. Czy przeglądarki zawsze traktują je tak, jakby były napisane w stylu „Cache-Control: no-cache, no-store”?

http-headers

— Su Zhang
źródło

Odpowiedzi:

157

tak

HTTP RFC2616 dostępne tutaj mówi:

W komunikacie MOŻE znajdować się wiele pól nagłówka wiadomości o tej samej nazwie pola wtedy i tylko wtedy, gdy cała wartość pola dla tego pola nagłówka jest zdefiniowana jako lista oddzielona przecinkami [tj. # (Wartości)]. MUSI istnieć możliwość połączenia wielu pól nagłówka w jedną parę „nazwa-pola: wartość-pola”, bez zmiany semantyki wiadomości, poprzez dołączanie każdej kolejnej wartości pola do pierwszej, oddzielonej przecinkami. Kolejność, w jakiej odbierane są pola nagłówka o tej samej nazwie pola, jest zatem istotna dla interpretacji połączonej wartości pola, a zatem proxy NIE MOŻE zmieniać kolejności tych wartości pól, gdy wiadomość jest przekazywana

Tak więc, wiele nagłówków o tej samej nazwie jest w porządku (tak jest z uwierzytelnianiem przez www), jeśli cała wartość pola jest zdefiniowana jako lista wartości oddzielonych przecinkami.

Kontrola pamięci podręcznej jest udokumentowana tutaj: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 w następujący sposób:

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

#1cache-directiveSkładnia określa listę co najmniej jednego elementów pamięci podręcznej dyrektywy (zob tutaj formalnej definicji #values: Konwencje i generycznych Gramatyka )

Więc tak,

Cache-Control: no-cache, no-store

jest równoważne (kolejność jest ważna)

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

— Simon Mourier
źródło

Dziękuję za szybką odpowiedź, Simon! Ale czy cytowany akapit z RFC 2616 nie dotyczy również Cache-Control? Czy coś mi brakuje?

— Su Zhang

Prawie w 100% poprawne. Kontrola pamięci podręcznej pozwala na wiele wartości: Cache-Control = "Cache-Control" ":" 1#cache-directive. Zwróć uwagę na #poprzednie cache-directive. Oznacza to, że akceptowanych jest wiele wartości (bezpośrednio z powyższej definicji) ...

— ircmaxell

„wtedy i tylko wtedy, gdy cała wartość pola dla tego pola nagłówka jest zdefiniowana jako lista oddzielona przecinkami” - wydaje mi się, że wiele wartości musi być zdefiniowane jako lista oddzielona przecinkami, tj. nie mogą być podzielone na oddzielne nagłówki.

— mpen

@mark - „zdefiniowana jako lista oddzielona przecinkami” oznacza tutaj „zdefiniowana w gramatyce BNF jako lista oddzielona przecinkami”. Pola kontrolne pamięci podręcznej są rzeczywiście zdefiniowane w ten sposób (x # blahblah).

— Simon Mourier

Sekcja w nowszym RFC 7230, która mówi o obsłudze wielu nagłówków, to tools.ietf.org/html/rfc7230#section-3.2.2

— Matthew Buckett,

Zwróć uwagę, że HSTS RFC6797 jest sprzeczny z RFC2616 (naruszającym język „if and only if”), definiując zachowanie dla wielu wystąpień nagłówka STS, chociaż nie jest wypełniony wartościami oddzielonymi przecinkami:

  "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."

— Wizerunkowa postać
źródło

Błędny. RFC6797 NIE definiuje nagłówka STS jako zawierającego listę oddzieloną przecinkami. Zatem reguła „jeśli i tylko jeśli” z RFC 2616 ma zastosowanie dokładnie to samo (co oznacza, że wiele nagłówków STS NIE jest dozwolonych, ponieważ nagłówek STS nie jest zdefiniowany jako przyjmujący listę oddzieloną przecinkami). RFC6797 sprawia, że nie jest deterministyczne, jakie są konsekwencje naruszenia tej zasady, coś, co wydaje się pozostawić otwarte w RFC2616.

— Frans