Le intestazioni di risposta HTTP duplicate sono accettabili?

123

Non ho trovato alcuna specifica sul fatto che le intestazioni di risposta HTTP duplicate siano consentite dallo standard, ma ho bisogno di sapere se ciò causerà problemi di compatibilità.

Supponiamo di avere un'intestazione di risposta come questa:

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

Notare che ci sono due Cache-Controlintestazioni con valori diversi. I browser li trattano sempre come se fossero scritti come "Cache-Control: no-cache, no-store"?

http-headers

— Su Zhang
fonte

Risposte:

157

sì

HTTP RFC2616 disponibile qui dice:

Più campi di intestazione del messaggio con lo stesso nome di campo POSSONO essere presenti in un messaggio se e solo se l'intero valore del campo per quel campo di intestazione è definito come un elenco separato da virgole [cioè, # (valori)]. DEVE essere possibile combinare più campi di intestazione in una coppia "nome-campo: valore-campo", senza modificare la semantica del messaggio, aggiungendo ogni successivo valore di campo al primo, ciascuno separato da una virgola. L'ordine in cui vengono ricevuti i campi di intestazione con lo stesso nome di campo è quindi significativo per l'interpretazione del valore di campo combinato, e quindi un proxy NON DEVE cambiare l'ordine di questi valori di campo quando viene inoltrato un messaggio

Quindi, più intestazioni con lo stesso nome sono ok (www-authenticate è un caso del genere) se l'intero valore del campo è definito come un elenco di valori separati da virgole.

Il controllo della cache è documentato qui: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 in questo modo:

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

La #1cache-directivesintassi definisce un elenco di almeno un elemento di direttiva cache (vedere qui per la definizione formale di #values: Convenzioni notazionali e grammatica generica )

Quindi sì,

Cache-Control: no-cache, no-store

è equivalente a (l'ordine è importante)

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

— Simon Mourier
fonte

Grazie per la tua rapida risposta, Simon! Ma il paragrafo citato dalla RFC 2616 non si applica anche a Cache-Control? Mi sto perdendo qualcosa?

— Su Zhang

Corretto quasi al 100%. Controllo della cache consente valori multipli: Cache-Control = "Cache-Control" ":" 1#cache-directive. Notare il #prima cache-directive. Ciò indica che sono accettati più valori (direttamente dalla tua definizione sopra) ...

— ircmaxell

"se e solo se l'intero valore del campo per quel campo di intestazione è definito come un elenco delimitato da virgole" - a me sembra che i valori multipli debbano essere definiti come un elenco separato da virgole, ovvero non possono essere suddiviso in intestazioni separate.

— mpen

@mark - "definito come un elenco separato da virgole" qui significa "definito nella grammatica BNF come un elenco separato da virgole". I campi di controllo della cache sono effettivamente definiti in questo modo (x # blahblah).

— Simon Mourier

La sezione nella più recente RFC 7230 che parla della gestione di più intestazioni è tools.ietf.org/html/rfc7230#section-3.2.2

— Matthew Buckett

Si noti che l'HSTS RFC6797 contraddice l'RFC2616 (violando il linguaggio "if and only if") definendo il comportamento per più istanze dell'intestazione STS, sebbene non sia popolato con valori separati da virgole:

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

— Ragazzo copertina
fonte

Non corretto. RFC6797 NON definisce l'intestazione STS come contenente un elenco separato da virgole. Quindi la regola "se e solo se" della RFC 2616 si applica allo stesso modo (il che significa che NON sono consentite più intestazioni STS poiché l'intestazione STS non è definita come un elenco separato da virgole). RFC6797 rende semplicemente non deterministiche le conseguenze della violazione di quella regola, qualcosa che RFC2616 sembra lasciare aperto.

— Frans