Les en-têtes de réponse HTTP en double sont-ils acceptables?


123

Je n'ai trouvé aucune spécification indiquant si les en-têtes de réponse HTTP en double sont autorisés par la norme, mais j'ai besoin de savoir si cela entraînera des problèmes de compatibilité.

Disons que j'ai un en-tête de réponse comme celui-ci:

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

Notez qu'il existe deux en- Cache-Controltêtes avec des valeurs différentes. Les navigateurs les traitent-ils toujours comme s'ils étaient écrits comme "Cache-Control: no-cache, no-store"?

Réponses:


157

Oui

HTTP RFC2616 disponible ici dit:

Plusieurs champs d'en-tête de message avec le même nom de champ PEUVENT être présents dans un message si et seulement si la valeur de champ entière pour ce champ d'en-tête est définie comme une liste séparée par des virgules [c'est-à-dire # (valeurs)]. Il DOIT être possible de combiner les multiples champs d'en-tête en une paire «nom de champ: valeur de champ», sans changer la sémantique du message, en ajoutant chaque valeur de champ suivante au premier, chacun séparé par une virgule. L'ordre dans lequel les champs d'en-tête avec le même nom de champ sont reçus est donc significatif pour l'interprétation de la valeur de champ combinée, et donc un mandataire NE DOIT PAS changer l'ordre de ces valeurs de champ lorsqu'un message est transmis

Ainsi, plusieurs en-têtes avec le même nom sont ok (www-authenticate est un tel cas) si la valeur de champ entière est définie comme une liste de valeurs séparées par des virgules.

Le contrôle du cache est documenté ici: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 comme ceci:

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

La #1cache-directivesyntaxe définit une liste d'au moins un éléments de directive cache (voir ici pour la définition formelle de #values: Notational Conventions and Generic Grammar )

Donc oui,

Cache-Control: no-cache, no-store

équivaut à (l'ordre est important)

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

2
Merci pour votre réponse rapide, Simon! Mais le paragraphe cité de la RFC 2616 ne s'applique-t-il pas également à Cache-Control? Est-ce que je manque quelque chose?
Su Zhang

1
Presque 100% correct. Cache Control permet de multiples valeurs: Cache-Control = "Cache-Control" ":" 1#cache-directive. Remarquez l' #avant cache-directive. Cela indique que plusieurs valeurs sont acceptées (à droite de votre définition ci-dessus) ...
ircmaxell

1
"si et seulement si la valeur de champ entière pour ce champ d'en-tête est définie comme une liste séparée par des virgules" - cela me semble que les valeurs multiples doivent être définies comme une liste séparée par des virgules, c'est-à-dire qu'elles ne peuvent pas être divisé en en-têtes séparés.
mpen

2
@mark - "défini comme une liste séparée par des virgules" signifie ici "défini dans la grammaire BNF comme une liste séparée par des virgules". Les champs de contrôle du cache sont en effet définis comme ça (x # blahblah).
Simon Mourier

2
La section dans la nouvelle RFC 7230 qui parle de la gestion de plusieurs en-têtes est tools.ietf.org/html/rfc7230#section-3.2.2
Matthew Buckett

0

Notez que la RFC6797 HSTS contredit la RFC2616 (violant le langage «si et seulement si») en définissant le comportement pour plusieurs instances de l'en-tête STS, bien qu'il ne soit pas rempli avec des valeurs séparées par des virgules:

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

Incorrect. RFC6797 ne définit PAS l'en-tête STS comme contenant une liste séparée par des virgules. Ainsi, la règle «si et seulement si» de la RFC 2616 s'applique de la même manière (ce qui signifie que plusieurs en-têtes STS ne sont PAS autorisés car l'en-tête STS n'est pas défini comme prenant une liste séparée par des virgules). La RFC6797 rend juste non déterministe les conséquences de la violation de cette règle, ce que la RFC2616 semble laisser ouverte.
Frans
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.