web-dev-qa-db-fra.com

Quels en-têtes de réponse HTTP sont requis

Quels en-têtes de réponse HTTP doivent être envoyés du serveur au client?

Je travaille pour optimiser les en-têtes de réponse HTTP afin de minimiser la surcharge de réponse HTTP. Je sais que les "frais généraux" sont quelque peu exagérés, mais j'aime une sortie nette.

Je vois beaucoup de sites Web, qui envoient des en-têtes de cache redondants.

par exemple.

Il est redondant de spécifier à la fois Expires et Cache-Control: max-age, ou pour spécifier les deux Last-Modified et ETag.

  • Source
  • HTTP/1.1: Définitions des champs d'en-tête
httphttp-headershttpresponse
58
Beni

Cela dépend de ce que vous définissez comme étant requis: il n'y a pas de champs d'en-tête qui doivent être envoyés avec chaque réponse quelles que soient les circonstances, mais il y a des champs d'en-tête que vous avez vraiment devrait envoyer. Le seul champ d'en-tête qui se rapproche est Date, mais même il a des circonstances dans lesquelles il n'est pas requis.

Dans le langage de RFC 2119 , le terme [~ # ~] doit [~ # ~] signifie que quelque chose est un l'exigence de la spécification et ne répondant pas à l'exigence serait invalide. Aucun champ d'en-tête n'est défini par les RFC 72 , 7231 , 7232 , 72 , 7234 , ou 7235 qui [~ # ~] doit [~ # ~] être envoyé par un serveur Origin dans tous les cas.

Les en-têtes suivants, par exemple, peuvent être omis (bien que vous devriez probablement les envoyer):

7.1.1.2. Date

Un serveur d'origine NE DOIT PAS envoyer un champ d'en-tête Date s'il n'a pas d'horloge capable de fournir une approximation raisonnable de l'instance actuelle en temps universel coordonné. Un serveur d'origine PEUT envoyer un champ d'en-tête Date si la réponse est dans la classe de codes d'état 1xx (informationnel) ou 5xx (erreur serveur). Un serveur d'origine DOIT envoyer un champ d'en-tête Date dans tous les autres cas.

Notez la dernière phrase de la citation. Le champ d'en-tête Date [~ # ~] doit [~ # ~] être envoyé si le serveur Origin est capable de fournir un " approximation raisonnable "de la date en UTC, mais rien n'empêche un serveur de se déformer.

7.4.2. Serveur

Un serveur d'origine PEUT générer un champ Server dans ses réponses.

.3.2. Content-Length

Mis à part [un nombre fini de cas prédéfinis], en l'absence de Transfer-Encoding, un serveur d'origine DEVRAIT envoyer un Content-Length champ d'en-tête lorsque la taille du corps de la charge utile est connue avant d'envoyer la section d'en-tête complète.

Au sujet de Content-Length et Transfer-Encoding, notez qu'aucun des deux ne peut être envoyé, auquel cas la longueur de la réponse est "déterminée par le nombre d'octets reçus avant la fermeture de la connexion par le serveur".

.1.1.5. Type de conten

Si un Content-Type le champ d'en-tête n'est pas présent, le destinataire PEUT supposer soit un type de support de application/octet-stream (RFC2046, section 4.5.1) ou examinez les données pour déterminer leur type.

Il existe des circonstances dans lesquelles des en-têtes particuliers peuvent être requis, par exemple:

56
Whymarrh

Cela dépend des spécificités de la réponse, mais généralement, une réponse d'un serveur Origin doit avoir:

  • Date
  • Type de contenu
  • Serveur

et soit Content-Length, Transfer-Encoding ou Connection: close.

Si vous voulez faire de la mise en cache, ajoutez Cache-Control (par exemple, avec max-age); Expire n'est généralement plus nécessaire. Si vous souhaitez que les clients puissent valider, ajoutez Last-Modified ou ETag.

22
Mark Nottingham