14. Header Field Definitions (Définitions des Champs d'En-tête)

14 Définitions des champs d'en-tête

Cette section définit la syntaxe et la sémantique de tous les champs d'en-tête HTTP/1.1 standard. Pour les champs d'en-tête d'entité, l'expéditeur et le destinataire désignent l'un ou l'autre du client ou du serveur, selon qui envoie et qui reçoit l'entité.

14.1 Accept

Le champ d'en-tête de requête Accept peut être utilisé pour spécifier certains types de médias qui sont acceptables pour la réponse. Les en-têtes Accept peuvent être utilisés pour indiquer que la requête est spécifiquement limitée à un petit ensemble de types souhaités, comme dans le cas d'une requête portant sur une image incorporée.

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

   media-range    = ( "*/*"
                    | ( type "/" "*" )
                    | ( type "/" subtype )
                    ) *( ";" parameter )
   accept-params  = ";" "q" "=" qvalue *( accept-extension )
   accept-extension = ";" token [ "=" ( token | quoted-string ) ]

Le caractère astérisque "" est utilisé pour regrouper les types de médias en plages, "/" désignant tous les types de médias et "type/" tous les sous-types de ce type. La media-range PEUT inclure des paramètres de type de média applicables à cette plage.

Chaque media-range PEUT être suivie d'un ou plusieurs accept-params, commençant par le paramètre "q" servant à indiquer un facteur de qualité relatif. Le premier paramètre "q" (le cas échéant) sépare le ou les paramètres de la media-range des accept-params. Les facteurs de qualité permettent à l'utilisateur ou à l'agent utilisateur d'indiquer le degré relatif de préférence pour cette media-range, en utilisant l'échelle qvalue de 0 à 1 (section 3.9). La valeur par défaut est q=1.

  Note : L'utilisation du nom de paramètre "q" pour séparer les
  paramètres de type de média des paramètres d'extension Accept
  résulte d'une pratique historique. Bien que cela empêche
  l'utilisation de tout paramètre de type de média nommé "q" avec
  une plage de médias, un tel cas est jugé improbable étant donné
  l'absence de tout paramètre "q" dans le registre IANA des types de
  médias et la rareté de l'usage de paramètres de type de média dans
  Accept. Il est déconseillé aux futurs types de médias
  d'enregistrer un paramètre nommé "q".

L'exemple

   Accept: audio/*; q=0.2, audio/basic

DEVRAIT être interprété comme « je préfère audio/basic, mais envoyez-moi n'importe quel type audio s'il constitue la meilleure option disponible après une décote de 80 % en qualité ».

Si aucun champ d'en-tête Accept n'est présent, il est alors supposé que le client accepte tous les types de médias. Si un champ d'en-tête Accept est présent et que le serveur ne peut pas envoyer une réponse acceptable au regard de la valeur combinée du champ Accept, le serveur DEVRAIT alors envoyer une réponse 406 (not acceptable).

Un exemple plus élaboré est

   Accept: text/plain; q=0.5, text/html,
           text/x-dvi; q=0.8, text/x-c

Formulé en toutes lettres, cela serait interprété comme « text/html et text/x-c sont les types de médias préférés, mais s'ils n'existent pas, envoyez alors l'entité text/x-dvi, et si celle-ci n'existe pas, envoyez l'entité text/plain ».

Les plages de médias peuvent être supplantées par des plages de médias plus spécifiques ou par des types de médias spécifiques. Si plusieurs plages de médias s'appliquent à un type donné, la référence la plus spécifique prévaut. Par exemple,

   Accept: text/*, text/html, text/html;level=1, */*

possède la préséance suivante :

   1) text/html;level=1
   2) text/html
   3) text/*
   4) */*

Le facteur de qualité de type de média associé à un type donné est déterminé en recherchant la plage de médias ayant la préséance la plus élevée qui correspond à ce type. Par exemple,

   Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
           text/html;level=2;q=0.4, */*;q=0.5

entraînerait l'association des valeurs suivantes :

   text/html;level=1         = 1
   text/html                 = 0.7
   text/plain                = 0.3

   image/jpeg                = 0.5
   text/html;level=2         = 0.4
   text/html;level=3         = 0.7

  Note : Un agent utilisateur peut être doté d'un ensemble par défaut
  de valeurs de qualité pour certaines plages de médias. Cependant, à
  moins que l'agent utilisateur ne soit un système fermé incapable
  d'interagir avec d'autres agents de rendu, cet ensemble par défaut
  devrait être configurable par l'utilisateur.

14.2 Accept-Charset

Le champ d'en-tête de requête Accept-Charset peut être utilisé pour indiquer quels jeux de caractères sont acceptables pour la réponse. Ce champ permet aux clients capables de comprendre des jeux de caractères plus étendus ou à usage spécifique de signaler cette capacité à un serveur en mesure de représenter des documents dans ces jeux de caractères.

  Accept-Charset = "Accept-Charset" ":"
          1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )

Les valeurs de jeu de caractères sont décrites à la section 3.4. Chaque charset PEUT se voir attribuer une valeur de qualité associée qui représente la préférence de l'utilisateur pour ce charset. La valeur par défaut est q=1. Voici un exemple :

  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

La valeur spéciale "", si elle est présente dans le champ Accept-Charset, correspond à tout jeu de caractères (y compris ISO-8859-1) qui n'est pas mentionné ailleurs dans le champ Accept-Charset. Si aucun "" n'est présent dans un champ Accept-Charset, tous les jeux de caractères non explicitement mentionnés reçoivent une valeur de qualité de 0, à l'exception d'ISO-8859-1, qui reçoit une valeur de qualité de 1 s'il n'est pas explicitement mentionné.

Si aucun en-tête Accept-Charset n'est présent, la valeur par défaut est que tout jeu de caractères est acceptable. Si un en-tête Accept-Charset est présent et que le serveur ne peut pas envoyer une réponse acceptable au regard de l'en-tête Accept-Charset, le serveur DEVRAIT alors envoyer une réponse d'erreur avec le code d'état 406 (not acceptable), bien que l'envoi d'une réponse non acceptable soit également autorisé.

14.3 Accept-Encoding

Le champ d'en-tête de requête Accept-Encoding est similaire à Accept, mais restreint les content-codings (section 3.5) qui sont acceptables dans la réponse.

   Accept-Encoding  = "Accept-Encoding" ":"
                      1#( codings [ ";" "q" "=" qvalue ] )
   codings          = ( content-coding | "*" )

Voici des exemples de son utilisation :

   Accept-Encoding: compress, gzip
   Accept-Encoding:
   Accept-Encoding: *
   Accept-Encoding: compress;q=0.5, gzip;q=1.0
   Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Un serveur détermine si un content-coding est acceptable, au regard d'un champ Accept-Encoding, en appliquant les règles suivantes :

  1. Si le content-coding fait partie des content-codings énumérés
     dans le champ Accept-Encoding, alors il est acceptable, sauf
     s'il est accompagné d'une qvalue de 0. (Comme défini à la
     section 3.9, une qvalue de 0 signifie « non acceptable ».)

  2. Le symbole spécial "*" dans un champ Accept-Encoding correspond
     à tout content-coding disponible qui n'est pas explicitement
     énuméré dans le champ d'en-tête.

  3. Si plusieurs content-codings sont acceptables, alors le
     content-coding acceptable ayant la qvalue non nulle la plus
     élevée est préféré.

  4. Le content-coding "identity" est toujours acceptable, sauf s'il
     est expressément refusé parce que le champ Accept-Encoding
     inclut "identity;q=0", ou parce que le champ inclut "*;q=0" et
     n'inclut pas explicitement le content-coding "identity". Si la
     valeur du champ Accept-Encoding est vide, alors seul l'encodage
     "identity" est acceptable.

Si un champ Accept-Encoding est présent dans une requête et que le serveur ne peut pas envoyer une réponse acceptable au regard de l'en-tête Accept-Encoding, le serveur DEVRAIT alors envoyer une réponse d'erreur avec le code d'état 406 (Not Acceptable).

Si aucun champ Accept-Encoding n'est présent dans une requête, le serveur PEUT supposer que le client acceptera tout codage de contenu. Dans ce cas, si "identity" fait partie des content-codings disponibles, le serveur DEVRAIT alors utiliser le content-coding "identity", à moins qu'il ne dispose d'informations supplémentaires indiquant qu'un content-coding différent est pertinent pour le client.

  Note : Si la requête n'inclut pas de champ Accept-Encoding et que
  le content-coding "identity" n'est pas disponible, alors les
  content-codings couramment compris par les clients HTTP/1.0
  (c'est-à-dire "gzip" et "compress") sont préférés ; certains
  clients plus anciens affichent incorrectement les messages envoyés
  avec d'autres content-codings. Le serveur peut également fonder
  cette décision sur des informations relatives à l'agent utilisateur
  ou au client concerné.

  Note : La plupart des applications HTTP/1.0 ne reconnaissent ni ne
  respectent les qvalues associées aux content-codings. Cela signifie
  que les qvalues ne fonctionneront pas et ne sont pas autorisées
  avec x-gzip ou x-compress.

14.4 Accept-Language

Le champ d'en-tête de requête Accept-Language est similaire à Accept, mais restreint l'ensemble des langues naturelles préférées en réponse à la requête. Les étiquettes de langue sont définies à la section 3.10.

   Accept-Language = "Accept-Language" ":"
                     1#( language-range [ ";" "q" "=" qvalue ] )
   language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

Chaque language-range PEUT se voir attribuer une valeur de qualité associée qui représente une estimation de la préférence de l'utilisateur pour les langues spécifiées par cette plage. La valeur de qualité vaut par défaut "q=1". Par exemple,

   Accept-Language: da, en-gb;q=0.8, en;q=0.7

signifierait : « je préfère le danois, mais j'accepterai l'anglais britannique et d'autres variétés d'anglais ». Une language-range correspond à une language-tag si elle est exactement égale à l'étiquette, ou si elle est exactement égale à un préfixe de l'étiquette tel que le premier caractère de l'étiquette suivant le préfixe soit "-". La plage spéciale "*", si elle est présente dans le champ Accept-Language, correspond à toute étiquette qui n'est mise en correspondance par aucune autre plage présente dans le champ Accept-Language.

  Note : Cet usage d'une règle de correspondance par préfixe
  n'implique pas que les étiquettes de langue soient attribuées aux
  langues de telle manière qu'il soit toujours vrai que, si un
  utilisateur comprend une langue portant une certaine étiquette,
  cet utilisateur comprendra également toutes les langues dont les
  étiquettes ont cette étiquette pour préfixe. La règle du préfixe
  permet simplement l'usage d'étiquettes de préfixe lorsque tel est
  le cas.

Le facteur de qualité linguistique attribué à une language-tag par le champ Accept-Language est la valeur de qualité de la language-range la plus longue du champ qui correspond à la language-tag. Si aucune language-range du champ ne correspond à l'étiquette, le facteur de qualité linguistique attribué est 0. Si aucun en-tête Accept-Language n'est présent dans la requête, le serveur DEVRAIT supposer que toutes les langues sont également acceptables. Si un en-tête Accept-Language est présent, alors toutes les langues auxquelles est attribué un facteur de qualité supérieur à 0 sont acceptables.

Il pourrait être contraire aux attentes de l'utilisateur en matière de vie privée d'envoyer un en-tête Accept-Language contenant l'ensemble complet de ses préférences linguistiques dans chaque requête. Pour une discussion de cette question, voir la section 15.1.4.

L'intelligibilité dépendant fortement de chaque utilisateur, il est recommandé que les applications clientes mettent le choix de la préférence linguistique à la disposition de l'utilisateur. Si ce choix n'est pas proposé, alors le champ d'en-tête Accept-Language NE DOIT PAS figurer dans la requête.

  Note : Lorsqu'ils mettent le choix de la préférence linguistique à
  la disposition de l'utilisateur, nous rappelons aux implémenteurs
  que les utilisateurs ne sont pas familiarisés avec les détails de
  la correspondance linguistique décrite ci-dessus, et qu'il convient
  de fournir des indications appropriées. À titre d'exemple, les
  utilisateurs pourraient supposer qu'en sélectionnant "en-gb", tout
  type de document anglais leur sera servi si l'anglais britannique
  n'est pas disponible. Un agent utilisateur pourrait, en pareil cas,
  suggérer d'ajouter "en" afin d'obtenir le comportement de
  correspondance le plus adapté.

14.5 Accept-Ranges

  Le champ d'en-tête de réponse Accept-Ranges permet au serveur
  d'indiquer qu'il accepte les requêtes de plage pour une ressource :

      Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
      acceptable-ranges = 1#range-unit | "none"

  Les serveurs d'origine qui acceptent les requêtes byte-range
  PEUVENT envoyer

      Accept-Ranges: bytes

  mais ne sont pas tenus de le faire. Les clients PEUVENT générer des
  requêtes byte-range sans avoir reçu cet en-tête pour la ressource
  concernée. Les unités de plage sont définies à la section 3.12.

  Les serveurs qui n'acceptent aucun type de requête de plage pour
  une ressource PEUVENT envoyer

      Accept-Ranges: none

  afin de conseiller au client de ne pas tenter une requête de plage.

14.6 Age

  Le champ d'en-tête de réponse Age communique l'estimation par
  l'expéditeur du temps écoulé depuis que la réponse (ou sa
  revalidation) a été générée par le serveur d'origine. Une réponse
  mise en cache est « fraîche » si son âge n'excède pas sa durée de
  fraîcheur. Les valeurs d'âge sont calculées comme spécifié à la
  section 13.2.3.

       Age = "Age" ":" age-value
       age-value = delta-seconds

  Les valeurs d'âge sont des entiers décimaux non négatifs,
  représentant un temps en secondes.

  Si un cache reçoit une valeur supérieure au plus grand entier
  positif qu'il peut représenter, ou si l'un de ses calculs d'âge
  déborde, il DOIT transmettre un en-tête Age d'une valeur de
  2147483648 (2^31). Un serveur HTTP/1.1 comportant un cache DOIT
  inclure un champ d'en-tête Age dans chaque réponse générée à partir
  de son propre cache. Les caches DEVRAIENT utiliser un type
  arithmétique offrant une amplitude d'au moins 31 bits.

14.7 Allow

  Le champ d'en-tête d'entité Allow énumère l'ensemble des méthodes
  prises en charge par la ressource identifiée par la Request-URI. Ce
  champ a pour seul objet d'informer le destinataire des méthodes
  valides associées à la ressource. Un champ d'en-tête Allow DOIT
  être présent dans une réponse 405 (Method Not Allowed).

      Allow   = "Allow" ":" #Method

  Exemple d'utilisation :

      Allow: GET, HEAD, PUT

  Ce champ ne peut empêcher un client d'essayer d'autres méthodes.
  Cependant, les indications données par la valeur du champ d'en-tête
  Allow DEVRAIENT être suivies. L'ensemble effectif des méthodes
  autorisées est défini par le serveur d'origine au moment de chaque
  requête.

  Le champ d'en-tête Allow PEUT être fourni avec une requête PUT afin
  de recommander les méthodes devant être prises en charge par la
  ressource nouvelle ou modifiée. Le serveur n'est pas tenu de
  prendre en charge ces méthodes et DEVRAIT inclure un en-tête Allow
  dans la réponse indiquant les méthodes effectivement prises en
  charge.

  Un proxy NE DOIT PAS modifier le champ d'en-tête Allow même s'il ne
  comprend pas toutes les méthodes spécifiées, car l'agent
  utilisateur peut disposer d'autres moyens de communiquer avec le
  serveur d'origine.

14.8 Authorization

  Un agent utilisateur qui souhaite s'authentifier auprès d'un
  serveur — généralement, mais pas nécessairement, après avoir reçu
  une réponse 401 — le fait en incluant un champ d'en-tête de requête
  Authorization dans la requête. La valeur du champ Authorization se
  compose de credentials contenant les informations
  d'authentification de l'agent utilisateur pour le domaine (realm)
  de la ressource demandée.

      Authorization  = "Authorization" ":" credentials

  L'authentification d'accès HTTP est décrite dans « HTTP
  Authentication: Basic and Digest Access Authentication » [43]. Si
  une requête est authentifiée et qu'un realm est spécifié, les mêmes
  credentials DEVRAIENT être valides pour toutes les autres requêtes
  relevant de ce realm (à supposer que le schéma d'authentification
  lui-même n'exige pas le contraire, comme dans le cas de credentials
  variant en fonction d'une valeur de défi ou reposant sur des
  horloges synchronisées).

  Lorsqu'un cache partagé (voir la section 13.7) reçoit une requête
  contenant un champ Authorization, il NE DOIT PAS renvoyer la
  réponse correspondante en réponse à une autre requête, sauf si
  l'une des exceptions spécifiques suivantes s'applique :

  1. Si la réponse inclut la directive de cache-control "s-maxage",
     le cache PEUT utiliser cette réponse pour répondre à une requête
     ultérieure. Mais (si l'âge maximal spécifié est dépassé) un
     cache proxy DOIT d'abord la revalider auprès du serveur
     d'origine, en utilisant les en-têtes de requête de la nouvelle
     requête afin de permettre au serveur d'origine d'authentifier la
     nouvelle requête. (Il s'agit du comportement défini pour
     s-maxage.) Si la réponse inclut "s-maxage=0", le proxy DOIT
     toujours la revalider avant de la réutiliser.

  2. Si la réponse inclut la directive de cache-control
     "must-revalidate", le cache PEUT utiliser cette réponse pour
     répondre à une requête ultérieure. Mais si la réponse est
     périmée, tous les caches DOIVENT d'abord la revalider auprès du
     serveur d'origine, en utilisant les en-têtes de requête de la
     nouvelle requête afin de permettre au serveur d'origine
     d'authentifier la nouvelle requête.

  3. Si la réponse inclut la directive de cache-control "public",
     elle PEUT être renvoyée en réponse à toute requête ultérieure.

14.9 Cache-Control

Le champ d'en-tête général Cache-Control est utilisé pour spécifier des directives qui DOIVENT être respectées par tous les mécanismes de mise en cache tout au long de la chaîne requête/réponse. Ces directives spécifient un comportement destiné à empêcher les caches d'interférer négativement avec la requête ou la réponse. Elles supplantent généralement les algorithmes de mise en cache par défaut. Les directives de cache sont unidirectionnelles, en ce sens que la présence d'une directive dans une requête n'implique pas que la même directive doive figurer dans la réponse.

  Notez que les caches HTTP/1.0 peuvent ne pas implémenter
  Cache-Control et n'implémenter que Pragma: no-cache (voir la
  section 14.32).

Les directives de cache DOIVENT être transmises par une application proxy ou passerelle, indépendamment de leur importance pour cette application, car ces directives peuvent s'appliquer à tous les destinataires le long de la chaîne requête/réponse. Il n'est pas possible de spécifier une directive de cache destinée à un cache particulier.

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

cache-directive = cache-request-directive
     | cache-response-directive

cache-request-directive =
       "no-cache"                          ; Section 14.9.1
     | "no-store"                          ; Section 14.9.2
     | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
     | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
     | "min-fresh" "=" delta-seconds       ; Section 14.9.3
     | "no-transform"                      ; Section 14.9.5
    | "only-if-cached"                    ; Section 14.9.4
    | cache-extension                     ; Section 14.9.6

cache-response-directive =
      "public"                               ; Section 14.9.1
    | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
    | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
    | "no-store"                             ; Section 14.9.2
    | "no-transform"                         ; Section 14.9.5
    | "must-revalidate"                      ; Section 14.9.4
     | "proxy-revalidate"                     ; Section 14.9.4
     | "max-age" "=" delta-seconds            ; Section 14.9.3
     | "s-maxage" "=" delta-seconds           ; Section 14.9.3
     | cache-extension                        ; Section 14.9.6

cache-extension = token [ "=" ( token | quoted-string ) ]

Lorsqu'une directive apparaît sans aucun paramètre 1#field-name, la directive s'applique à l'ensemble de la requête ou de la réponse. Lorsque une telle directive apparaît avec un paramètre 1#field-name, elle ne s'applique qu'au champ ou aux champs nommés, et non au reste de la requête ou de la réponse. Ce mécanisme favorise l'extensibilité ; les implémentations de futures versions du protocole HTTP pourront appliquer ces directives à des champs d'en-tête non définis dans HTTP/1.1.

Les directives cache-control peuvent être réparties dans les catégories générales suivantes :

  - Restrictions sur ce qui peut être mis en cache ; celles-ci ne
    peuvent être imposées que par le serveur d'origine.

  - Restrictions sur ce qui peut être stocké par un cache ; celles-ci
    peuvent être imposées soit par le serveur d'origine, soit par
    l'agent utilisateur.

  - Modifications du mécanisme d'expiration de base ; celles-ci peuvent
    être imposées soit par le serveur d'origine, soit par l'agent
    utilisateur.

  - Contrôles sur la revalidation et le rechargement du cache ; ceux-ci
    ne peuvent être imposés que par un agent utilisateur.

  - Contrôle de la transformation des entités.

  - Extensions du système de mise en cache.

14.9.1 What is Cacheable (Ce qui peut être mis en cache)

Par défaut, une réponse peut être mise en cache si les exigences de la méthode de requête, des champs d'en-tête de requête et du statut de la réponse indiquent qu'elle peut l'être. La section 13.4 résume ces valeurs par défaut en matière de possibilité de mise en cache. Les directives de réponse Cache-Control suivantes permettent à un serveur d'origine de supplanter la possibilité de mise en cache par défaut d'une réponse :

public Indique que la réponse PEUT être mise en cache par n'importe quel cache, même si elle ne serait normalement pas cacheable ou ne serait cacheable que dans un cache non partagé. (Voir également Authorization, section 14.8, pour des détails supplémentaires.)

private Indique que tout ou partie du message de réponse est destiné à un utilisateur unique et NE DOIT PAS être mis en cache par un cache partagé. Cela permet à un serveur d'origine de déclarer que les parties spécifiées de la réponse sont destinées à un seul utilisateur et ne constituent pas une réponse valide pour les requêtes d'autres utilisateurs. Un cache privé (non partagé) PEUT mettre la réponse en cache.

   Note : Cet usage du mot private contrôle uniquement l'endroit où la
   réponse peut être mise en cache, et ne saurait garantir la
   confidentialité du contenu du message.

no-cache Si la directive no-cache ne spécifie pas de field-name, alors un cache NE DOIT PAS utiliser la réponse pour satisfaire une requête ultérieure sans revalidation réussie auprès du serveur d'origine. Cela permet à un serveur d'origine d'empêcher la mise en cache même par des caches configurés pour renvoyer des réponses périmées aux requêtes des clients.

  Si la directive no-cache spécifie effectivement un ou plusieurs
  field-names, alors un cache PEUT utiliser la réponse pour satisfaire
  une requête ultérieure, sous réserve de toute autre restriction
  relative à la mise en cache. Cependant, le ou les field-names
  spécifiés NE DOIVENT PAS être envoyés dans la réponse à une requête
  ultérieure sans revalidation réussie auprès du serveur d'origine.
  Cela permet à un serveur d'origine d'empêcher la réutilisation de
  certains champs d'en-tête dans une réponse, tout en autorisant la
  mise en cache du reste de la réponse.

   Note : La plupart des caches HTTP/1.0 ne reconnaîtront ni ne
   respecteront cette directive.

14.9.2 What May be Stored by Caches (Ce qui peut être stocké par les caches)

no-store La directive no-store a pour but d'empêcher la divulgation ou la conservation par inadvertance d'informations sensibles (par exemple, sur des bandes de sauvegarde). La directive no-store s'applique à l'ensemble du message et PEUT être envoyée soit dans une réponse, soit dans une requête. Si elle est envoyée dans une requête, un cache NE DOIT stocker aucune partie de cette requête ni d'aucune réponse à celle-ci. Si elle est envoyée dans une réponse, un cache NE DOIT stocker aucune partie de cette réponse ni de la requête qui l'a suscitée. Cette directive s'applique aussi bien aux caches non partagés qu'aux caches partagés. Dans ce contexte, « NE DOIT PAS stocker » signifie que le cache NE DOIT PAS stocker intentionnellement les informations dans un stockage non volatil, et DOIT s'efforcer au mieux de supprimer les informations du stockage volatil aussi rapidement que possible après les avoir transmises.

  Même lorsque cette directive est associée à une réponse, les
  utilisateurs peuvent explicitement stocker une telle réponse en
  dehors du système de mise en cache (par exemple, au moyen d'une boîte
  de dialogue « Enregistrer sous »). Les tampons d'historique PEUVENT
  stocker de telles réponses dans le cadre de leur fonctionnement
  normal.

  Cette directive a pour but de répondre aux exigences exprimées par
  certains utilisateurs et auteurs de services préoccupés par les
  divulgations accidentelles d'informations résultant d'accès
  imprévus aux structures de données des caches. Bien que l'utilisation
  de cette directive puisse améliorer la confidentialité dans certains
  cas, nous avertissons qu'elle ne constitue en AUCUNE manière un
  mécanisme fiable ou suffisant pour garantir la confidentialité. En
  particulier, des caches malveillants ou compromis peuvent ne pas
  reconnaître ni respecter cette directive, et les réseaux de
  communication peuvent être vulnérables à l'écoute clandestine.

14.9.3 Modifications of the Basic Expiration Mechanism (Modifications du mécanisme d'expiration de base)

Le délai d'expiration d'une entité PEUT être spécifié par le serveur d'origine au moyen de l'en-tête Expires (voir la section 14.21). Il PEUT également être spécifié au moyen de la directive max-age dans une réponse. Lorsque la directive cache-control max-age est présente dans une réponse mise en cache, la réponse est périmée si son âge actuel est supérieur à la valeur d'âge indiquée (en secondes) au moment d'une nouvelle requête portant sur cette ressource. La directive max-age dans une réponse implique que la réponse est cacheable (c'est-à-dire « public »), à moins qu'une autre directive de cache plus restrictive ne soit également présente.

Si une réponse comporte à la fois un en-tête Expires et une directive max-age, la directive max-age supplante l'en-tête Expires, même si celui-ci est plus restrictif. Cette règle permet à un serveur d'origine de fournir, pour une réponse donnée, un délai d'expiration plus long à un cache HTTP/1.1 (ou ultérieur) qu'à un cache HTTP/1.0. Cela peut se révéler utile si certains caches HTTP/1.0 calculent incorrectement les âges ou les délais d'expiration, peut-être en raison d'horloges désynchronisées.

De nombreuses implémentations de caches HTTP/1.0 traiteront une valeur Expires inférieure ou égale à la valeur Date de la réponse comme équivalente à la directive de réponse Cache-Control « no-cache ». Si un cache HTTP/1.1 reçoit une telle réponse et que celle-ci ne comporte pas de champ d'en-tête Cache-Control, il DEVRAIT considérer la réponse comme non cacheable afin de conserver la compatibilité avec les serveurs HTTP/1.0.

   Note : Un serveur d'origine pourrait souhaiter utiliser une
   fonctionnalité de contrôle de cache HTTP relativement récente, telle
   que la directive « private », sur un réseau comportant des caches
   plus anciens qui ne comprennent pas cette fonctionnalité. Le serveur
   d'origine devra combiner la nouvelle fonctionnalité avec un champ
   Expires dont la valeur est inférieure ou égale à la valeur Date. Cela
   empêchera les caches plus anciens de mettre indûment la réponse en
   cache.

s-maxage Si une réponse comporte une directive s-maxage, alors, pour un cache partagé (mais non pour un cache privé), l'âge maximal spécifié par cette directive supplante l'âge maximal spécifié soit par la directive max-age, soit par l'en-tête Expires. La directive s-maxage implique également la sémantique de la directive proxy-revalidate (voir la section 14.9.4), à savoir que le cache partagé ne doit pas utiliser l'entrée après qu'elle est devenue périmée pour répondre à une requête ultérieure sans l'avoir au préalable revalidée auprès du serveur d'origine. La directive s-maxage est toujours ignorée par un cache privé.

Notez que la plupart des caches plus anciens, non conformes à la présente spécification, n'implémentent aucune directive cache-control. Un serveur d'origine souhaitant utiliser une directive cache-control qui restreint, sans l'empêcher, la mise en cache par un cache conforme à HTTP/1.1 PEUT exploiter l'exigence selon laquelle la directive max-age supplante l'en-tête Expires, ainsi que le fait que les caches antérieurs à HTTP/1.1 n'observent pas la directive max-age.

D'autres directives permettent à un agent utilisateur de modifier le mécanisme d'expiration de base. Ces directives PEUVENT être spécifiées dans une requête :

max-age Indique que le client est disposé à accepter une réponse dont l'âge n'excède pas la durée spécifiée en secondes. À moins que la directive max-stale ne soit également incluse, le client n'est pas disposé à accepter une réponse périmée.

min-fresh Indique que le client est disposé à accepter une réponse dont la durée de fraîcheur n'est pas inférieure à son âge actuel augmenté de la durée spécifiée en secondes. Autrement dit, le client souhaite une réponse qui restera fraîche pendant au moins le nombre de secondes spécifié.

max-stale Indique que le client est disposé à accepter une réponse ayant dépassé son délai d'expiration. Si une valeur est attribuée à max-stale, le client est alors disposé à accepter une réponse ayant dépassé son délai d'expiration de tout au plus le nombre de secondes spécifié. Si aucune valeur n'est attribuée à max-stale, le client est alors disposé à accepter une réponse périmée de n'importe quel âge.

Si un cache renvoie une réponse périmée, soit en raison d'une directive max-stale figurant dans une requête, soit parce que le cache est configuré pour supplanter le délai d'expiration d'une réponse, le cache DOIT joindre un en-tête Warning à la réponse périmée, en utilisant Warning 110 (Response is stale).

Un cache PEUT être configuré pour renvoyer des réponses périmées sans validation, mais uniquement si cela n'entre pas en conflit avec les exigences de niveau « MUST » relatives à la validation du cache (par exemple, une directive cache-control « must-revalidate »).

Si la nouvelle requête et l'entrée en cache comportent toutes deux des directives « max-age », alors la plus petite des deux valeurs est utilisée pour déterminer la fraîcheur de l'entrée en cache au regard de cette requête.

14.9.4 Cache Revalidation and Reload Controls (Contrôles de revalidation et de rechargement du cache)

Un agent utilisateur peut parfois vouloir ou devoir exiger qu'un cache revalide son entrée de cache auprès du serveur d'origine (et non seulement auprès du cache suivant sur le chemin menant au serveur d'origine), ou recharge son entrée de cache à partir du serveur d'origine. Une revalidation de bout en bout peut être nécessaire si le cache ou le serveur d'origine a surestimé le délai d'expiration de la réponse en cache. Un rechargement de bout en bout peut être nécessaire si l'entrée de cache a été corrompue pour une raison quelconque.

Une revalidation de bout en bout peut être demandée soit lorsque le client ne dispose pas de sa propre copie en cache locale, auquel cas nous parlons de « revalidation de bout en bout non spécifiée », soit lorsque le client dispose d'une copie en cache locale, auquel cas nous parlons de « revalidation de bout en bout spécifiée ».

Le client peut spécifier ces trois types d'action au moyen des directives de requête Cache-Control suivantes :

End-to-end reload (Rechargement de bout en bout) La requête inclut une directive de cache-control « no-cache » ou, pour assurer la compatibilité avec les clients HTTP/1.0, « Pragma: no-cache ». Les noms de champ NE DOIVENT PAS être inclus avec la directive no-cache dans une requête. Le serveur NE DOIT PAS utiliser de copie en cache pour répondre à une telle requête.

Specific end-to-end revalidation (Revalidation de bout en bout spécifiée) La requête inclut une directive de cache-control « max-age=0 », qui force chaque cache le long du chemin menant au serveur d'origine à revalider sa propre entrée, le cas échéant, auprès du cache ou du serveur suivant. La requête initiale inclut une condition de validation de cache avec le validateur actuel du client.

Unspecified end-to-end revalidation (Revalidation de bout en bout non spécifiée) La requête inclut une directive de cache-control « max-age=0 », qui force chaque cache le long du chemin menant au serveur d'origine à revalider sa propre entrée, le cas échéant, auprès du cache ou du serveur suivant. La requête initiale n'inclut pas de condition de validation de cache ; le premier cache le long du chemin (le cas échéant) qui détient une entrée de cache pour cette ressource inclut une condition de validation de cache avec son validateur actuel.

max-age Lorsqu'un cache intermédiaire est contraint, au moyen d'une directive max-age=0, de revalider sa propre entrée de cache, et que le client a fourni son propre validateur dans la requête, le validateur fourni peut différer du validateur actuellement stocké avec l'entrée de cache. Dans ce cas, le cache PEUT utiliser l'un ou l'autre validateur pour formuler sa propre requête sans affecter la transparence sémantique.

  Toutefois, le choix du validateur peut affecter les performances. La
  meilleure approche consiste pour le cache intermédiaire à utiliser son
  propre validateur lors de sa requête. Si le serveur répond par 304 (Not
  Modified), alors le cache peut renvoyer sa copie désormais validée au
  client avec une réponse 200 (OK). Si le serveur répond par une nouvelle
  entité et un nouveau validateur de cache, cependant, le cache
  intermédiaire peut comparer le validateur renvoyé à celui fourni dans la
  requête du client, au moyen de la fonction de comparaison forte. Si le
  validateur du client est égal à celui du serveur d'origine, alors le
  cache intermédiaire renvoie simplement 304 (Not Modified). Sinon, il
  renvoie la nouvelle entité avec une réponse 200 (OK).

  Si une requête inclut la directive no-cache, elle NE DEVRAIT PAS inclure
  min-fresh, max-stale ou max-age.

only-if-cached Dans certains cas, tels que des moments de connectivité réseau extrêmement médiocre, un client peut vouloir qu'un cache renvoie uniquement les réponses qu'il détient déjà en mémoire, et n'effectue aucun rechargement ni revalidation auprès du serveur d'origine. Pour ce faire, le client peut inclure la directive only-if-cached dans une requête. S'il reçoit cette directive, un cache DEVRAIT soit répondre en utilisant une entrée en cache cohérente avec les autres contraintes de la requête, soit répondre avec un statut 504 (Gateway Timeout). Toutefois, si un groupe de caches est exploité comme un système unifié doté d'une bonne connectivité interne, une telle requête PEUT être transmise au sein de ce groupe de caches.

must-revalidate Étant donné qu'un cache PEUT être configuré pour ignorer le délai d'expiration spécifié par un serveur, et qu'une requête de client PEUT inclure une directive max-stale (qui a un effet similaire), le protocole inclut également un mécanisme permettant au serveur d'origine d'exiger la revalidation d'une entrée de cache à chaque utilisation ultérieure. Lorsque la directive must-revalidate est présente dans une réponse reçue par un cache, ce cache NE DOIT PAS utiliser l'entrée après qu'elle est devenue périmée pour répondre à une requête ultérieure sans l'avoir d'abord revalidée auprès du serveur d'origine. (Autrement dit, le cache DOIT effectuer une revalidation de bout en bout à chaque fois que, sur la seule base de la valeur Expires ou max-age du serveur d'origine, la réponse en cache est périmée.)

  La directive must-revalidate est nécessaire pour prendre en charge le
  fonctionnement fiable de certaines fonctionnalités du protocole. En
  toutes circonstances, un cache HTTP/1.1 DOIT respecter la directive
  must-revalidate ; en particulier, si le cache ne peut joindre le serveur
  d'origine pour une raison quelconque, il DOIT générer une réponse 504
  (Gateway Timeout).

  Les serveurs DEVRAIENT envoyer la directive must-revalidate si et
  seulement si l'échec de la revalidation d'une requête portant sur
  l'entité pourrait entraîner un fonctionnement incorrect, tel qu'une
  transaction financière exécutée en silence. Les destinataires NE DOIVENT
  prendre aucune action automatisée qui viole cette directive, et NE
  DOIVENT PAS fournir automatiquement une copie non validée de l'entité si
  la revalidation échoue.

  Bien que cela ne soit pas recommandé, les agents utilisateurs soumis à
  de sévères contraintes de connectivité PEUVENT violer cette directive,
  mais, le cas échéant, DOIVENT avertir explicitement l'utilisateur qu'une
  réponse non validée a été fournie. L'avertissement DOIT être fourni à
  chaque accès non validé, et DEVRAIT exiger une confirmation explicite de
  l'utilisateur.

proxy-revalidate La directive proxy-revalidate a la même signification que la directive must-revalidate, excepté qu'elle ne s'applique pas aux caches d'agents utilisateurs non partagés. Elle peut être utilisée sur une réponse à une requête authentifiée pour permettre au cache de l'utilisateur de stocker puis de renvoyer ultérieurement la réponse sans avoir besoin de la revalider (étant donné qu'elle a déjà été authentifiée une fois par cet utilisateur), tout en exigeant néanmoins que les proxies desservant de nombreux utilisateurs la revalident à chaque fois (afin de s'assurer que chaque utilisateur a été authentifié). Notez que de telles réponses authentifiées nécessitent également la directive de cache-control « public » pour pouvoir être mises en cache.

14.9.5 No-Transform Directive (Directive No-Transform)

no-transform Les implémenteurs de caches intermédiaires (proxies) ont trouvé utile de convertir le type de média de certains corps d'entité. Un proxy non transparent pourrait, par exemple, convertir entre différents formats d'image afin d'économiser de l'espace de cache ou de réduire le volume de trafic sur une liaison lente.

  De graves problèmes de fonctionnement surviennent toutefois lorsque ces
  transformations sont appliquées à des corps d'entité destinés à certains
  types d'applications. Par exemple, les applications d'imagerie
  médicale, d'analyse de données scientifiques et celles utilisant
  l'authentification de bout en bout dépendent toutes de la réception
  d'un corps d'entité identique bit à bit au corps d'entité d'origine.

  Par conséquent, si un message inclut la directive no-transform, un cache
  intermédiaire ou un proxy NE DOIT PAS modifier les en-têtes qui sont
  énumérés à la section 13.5.2 comme étant soumis à la directive
  no-transform. Cela implique que le cache ou le proxy NE DOIT PAS modifier
  aucun aspect du corps d'entité spécifié par ces en-têtes, y compris la
  valeur du corps d'entité lui-même.

14.9.6 Cache Control Extensions (Extensions du contrôle de cache)

Le champ d'en-tête Cache-Control peut être étendu au moyen d'un ou plusieurs jetons cache-extension, chacun avec une valeur attribuée facultative. Les extensions informatives (celles qui n'exigent pas de modification du comportement du cache) PEUVENT être ajoutées sans changer la sémantique des autres directives. Les extensions comportementales sont conçues pour agir comme des modificateurs de l'ensemble de directives de cache existantes. La nouvelle directive et la directive standard sont toutes deux fournies, de sorte que les applications qui ne comprennent pas la nouvelle directive reviennent par défaut au comportement spécifié par la directive standard, et celles qui comprennent la nouvelle directive la reconnaissent comme modifiant les exigences associées à la directive standard. De cette manière, des extensions des directives de cache-control peuvent être réalisées sans nécessiter des changements dans le protocole de base.

Ce mécanisme d'extension repose sur le fait qu'un cache HTTP respecte l'ensemble des directives cache-control définies pour sa version native de HTTP, respecte certaines extensions et ignore toutes les directives qu'il ne comprend pas.

Par exemple, considérons une hypothétique nouvelle directive de réponse appelée community qui agit comme un modificateur de la directive private. Nous définissons cette nouvelle directive comme signifiant que, en plus de tout cache non partagé, tout cache partagé uniquement par les membres de la communauté nommée dans sa valeur peut mettre la réponse en cache. Un serveur d'origine souhaitant autoriser la communauté UCI à utiliser, dans ses caches partagés, une réponse par ailleurs privée pourrait le faire en incluant :

   Cache-Control: private, community="UCI"

Un cache voyant ce champ d'en-tête agira correctement même s'il ne comprend pas l'extension community, puisqu'il verra et comprendra la directive private et reviendra par défaut au comportement sûr.

Les directives cache-control non reconnues DOIVENT être ignorées ; on suppose que toute directive cache-control susceptible de ne pas être reconnue par un cache HTTP/1.1 sera combinée avec des directives standard (ou la possibilité de mise en cache par défaut de la réponse) de sorte que le comportement du cache reste au minimum correct même si le cache ne comprend pas l'extension.

14.10 Connection

Le champ d'en-tête général Connection permet à l'expéditeur de spécifier des options souhaitées pour cette connexion particulière et NE DOIT PAS être communiquées par les proxies via d'autres connexions.

L'en-tête Connection a la grammaire suivante :

   Connection = "Connection" ":" 1#(connection-token)
   connection-token  = token

Les proxies HTTP/1.1 DOIVENT analyser le champ d'en-tête Connection avant qu'un message ne soit transmis et, pour chaque connection-token de ce champ, supprimer du message tout champ d'en-tête portant le même nom que le connection-token. Les options de connexion sont signalées par la présence d'un connection-token dans le champ d'en-tête Connection, et non par d'éventuels champs d'en-tête additionnels, étant donné que le champ d'en-tête additionnel peut ne pas être envoyé s'il n'y a aucun paramètre associé à cette option de connexion.

Les en-têtes de message énumérés dans l'en-tête Connection NE DOIVENT PAS inclure des en-têtes de bout en bout, tels que Cache-Control.

HTTP/1.1 définit l'option de connexion « close » permettant à l'expéditeur de signaler que la connexion sera fermée après l'achèvement de la réponse. Par exemple,

   Connection: close

dans les champs d'en-tête de la requête ou de la réponse indique que la connexion NE DEVRAIT PAS être considérée comme « persistante » (section 8.1) après l'achèvement de la requête/réponse courante.

Les applications HTTP/1.1 qui ne prennent pas en charge les connexions persistantes DOIVENT inclure l'option de connexion « close » dans chaque message.

Un système recevant un message HTTP/1.0 (ou de version inférieure) incluant un en-tête Connection DOIT, pour chaque connection-token de ce champ, supprimer et ignorer tout champ d'en-tête du message portant le même nom que le connection-token. Cela protège contre la transmission erronée de tels champs d'en-tête par des proxies antérieurs à HTTP/1.1. Voir la section 19.6.2.

14.11 Content-Encoding

Le champ d'en-tête d'entité Content-Encoding est utilisé comme modificateur du type de média. Lorsqu'il est présent, sa valeur indique quels codages de contenu additionnels ont été appliqués au corps d'entité, et donc quels mécanismes de décodage doivent être appliqués afin d'obtenir le type de média référencé par le champ d'en-tête Content-Type. Content-Encoding est principalement utilisé pour permettre à un document d'être compressé sans perdre l'identité de son type de média sous-jacent.

   Content-Encoding  = "Content-Encoding" ":" 1#content-coding

Les codages de contenu sont définis à la section 3.5. Un exemple de son utilisation est :

   Content-Encoding: gzip

Le codage de contenu est une caractéristique de l'entité identifiée par l'URI de requête. Typiquement, le corps d'entité est stocké avec ce codage et n'est décodé qu'avant le rendu ou une utilisation analogue. Toutefois, un proxy non transparent PEUT modifier le codage de contenu si le nouveau codage est connu comme acceptable pour le destinataire, à moins que la directive cache-control « no-transform » ne soit présente dans le message.

Si le codage de contenu d'une entité n'est pas « identity », alors la réponse DOIT inclure un en-tête d'entité Content-Encoding (section 14.11) qui énumère les codages de contenu non identity utilisés.

Si le codage de contenu d'une entité dans un message de requête n'est pas acceptable pour le serveur d'origine, le serveur DEVRAIT répondre avec un code de statut 415 (Unsupported Media Type).

Si de multiples codages ont été appliqués à une entité, les codages de contenu DOIVENT être énumérés dans l'ordre où ils ont été appliqués. Des informations additionnelles sur les paramètres de codage PEUVENT être fournies par d'autres champs d'en-tête d'entité non définis par la présente spécification.

14.12 Content-Language

Le champ d'en-tête d'entité Content-Language décrit la ou les langues naturelles du public visé pour l'entité enclose. Notez que cela peut ne pas être équivalent à l'ensemble des langues utilisées au sein du corps d'entité.

   Content-Language  = "Content-Language" ":" 1#language-tag

Les balises de langue sont définies à la section 3.10. L'objectif principal de Content-Language est de permettre à un utilisateur d'identifier et de différencier les entités selon sa propre langue préférée. Ainsi, si le contenu du corps est destiné uniquement à un public maîtrisant le danois, le champ approprié est :

   Content-Language: da

Si aucun Content-Language n'est spécifié, la valeur par défaut est que le contenu est destiné à l'ensemble des publics linguistiques. Cela peut signifier que l'expéditeur ne considère pas le contenu comme propre à une langue naturelle quelconque, ou qu'il ne sait pas à quelle langue il est destiné.

Plusieurs langues PEUVENT être énumérées pour un contenu destiné à plusieurs publics. Par exemple, une version du « Traité de Waitangi », présentée simultanément dans les versions originales maorie et anglaise, nécessiterait :

   Content-Language: mi, en

Toutefois, le fait que plusieurs langues soient présentes au sein d'une entité ne signifie pas pour autant qu'elle est destinée à de multiples publics linguistiques. Un exemple serait un abécédaire pour débutants, tel que « A First Lesson in Latin », qui est clairement destiné à être utilisé par un public maîtrisant l'anglais. Dans ce cas, Content-Language ne devrait correctement inclure que « en ».

Content-Language PEUT être appliqué à tout type de média — il n'est pas limité aux documents textuels.

14.13 Content-Length

Le champ d'en-tête d'entité Content-Length indique la taille du corps d'entité, en nombre décimal d'OCTETS, envoyée au destinataire ou, dans le cas de la méthode HEAD, la taille du corps d'entité qui aurait été envoyée si la requête avait été un GET.

   Content-Length    = "Content-Length" ":" 1*DIGIT

Un exemple est :

   Content-Length: 3495

Les applications DEVRAIENT utiliser ce champ pour indiquer la longueur de transfert du corps de message, à moins que cela ne soit interdit par les règles de la section 4.4.

Toute valeur Content-Length supérieure ou égale à zéro est une valeur valide. La section 4.4 décrit comment déterminer la longueur d'un corps de message si aucun Content-Length n'est fourni.

Notez que la signification de ce champ est très différente de la définition correspondante dans MIME, où il s'agit d'un champ optionnel utilisé au sein du type de contenu « message/external-body ». En HTTP, il DEVRAIT être envoyé chaque fois que la longueur du message peut être déterminée au préalable.

14.14 Content-Location

Le champ d'en-tête d'entité Content-Location PEUT être utilisé pour fournir l'emplacement de la ressource pour l'entité enclose dans le message lorsque cette entité est accessible depuis un emplacement distinct de l'URI de la ressource demandée. Un serveur DEVRAIT fournir un Content-Location pour la variante correspondant à l'entité de réponse ; en particulier dans le cas où une ressource a plusieurs entités associées, et que ces entités ont en réalité des emplacements séparés par lesquels elles peuvent être individuellement accessibles, le serveur DEVRAIT fournir un Content-Location pour la variante particulière qui est renvoyée.

   Content-Location = "Content-Location" ":"
                     ( absoluteURI | relativeURI )

La valeur de Content-Location définit également l'URI de base de l'entité.

La valeur Content-Location n'est pas un remplacement de l'URI de requête d'origine ; elle est uniquement une indication de l'emplacement de la ressource correspondant à cette entité particulière au moment de la requête. Les requêtes futures PEUVENT spécifier l'URI Content-Location comme URI de requête si le souhait est d'identifier la source de cette entité particulière.

Un cache ne peut pas supposer qu'une entité dont le Content-Location diffère de l'URI utilisé pour la récupérer peut être utilisée pour répondre à des requêtes ultérieures portant sur cet URI Content-Location. Toutefois, le Content-Location peut être utilisé pour différencier plusieurs entités récupérées à partir d'une seule ressource demandée, comme décrit à la section 13.6.

Si le Content-Location est un URI relatif, l'URI relatif est interprété par rapport à l'URI de requête.

La signification de l'en-tête Content-Location dans les requêtes PUT ou POST n'est pas définie ; les serveurs sont libres de l'ignorer dans ces cas.

14.15 Content-MD5

Le champ d'en-tête d'entité Content-MD5, tel que défini dans la RFC 1864 [23], est un condensé MD5 du corps d'entité destiné à fournir un contrôle d'intégrité de bout en bout (MIC) du corps d'entité. (Note : un MIC est utile pour détecter une modification accidentelle du corps d'entité en transit, mais ne constitue pas une preuve contre des attaques malveillantes.)

    Content-MD5   = "Content-MD5" ":" md5-digest
    md5-digest   = `<base64 du condensé MD5 128 bits conformément à la RFC 1864>`

Le champ d'en-tête Content-MD5 PEUT être généré par un serveur d'origine ou un client pour servir de contrôle d'intégrité du corps d'entité. Seuls les serveurs d'origine ou les clients PEUVENT générer le champ d'en-tête Content-MD5 ; les proxies et passerelles NE DOIVENT PAS le générer, car cela détruirait sa valeur en tant que contrôle d'intégrité de bout en bout. Tout destinataire du corps d'entité, y compris les passerelles et les proxies, PEUT vérifier que la valeur de condensé de ce champ correspond à celle du corps d'entité tel que reçu.

Le condensé MD5 est calculé sur le contenu du corps d'entité, y compris tout codage de contenu qui a été appliqué, mais non pas tout codage de transfert appliqué au corps de message. Si le message est reçu avec un codage de transfert, ce codage DOIT être supprimé avant de vérifier la valeur Content-MD5 par rapport à l'entité reçue.

Il en résulte que le condensé est calculé sur les octets du corps d'entité exactement comme, et dans l'ordre où, ils seraient envoyés si aucun codage de transfert n'était appliqué.

HTTP étend la RFC 1864 pour permettre le calcul du condensé pour les types de média composites MIME (par exemple, multipart/* et message/rfc822), mais cela ne change pas la manière dont le condensé est calculé telle que définie au paragraphe précédent.

Il y a plusieurs conséquences à cela. Le corps d'entité pour les types composites PEUT contenir de nombreuses parties de corps, chacune avec ses propres en-têtes MIME et HTTP (y compris les en-têtes Content-MD5, Content-Transfer-Encoding et Content-Encoding). Si une partie de corps comporte un en-tête Content-Transfer-Encoding ou Content-Encoding, on suppose que le contenu de la partie de corps a subi le codage, et la partie de corps est incluse dans le condensé Content-MD5 telle quelle — c'est-à-dire après l'application du codage. Le champ d'en-tête Transfer-Encoding n'est pas autorisé au sein des parties de corps.

La conversion de tous les sauts de ligne en CRLF NE DOIT PAS être effectuée avant de calculer ou de vérifier le condensé : la convention de saut de ligne utilisée dans le texte effectivement transmis DOIT être laissée inchangée lors du calcul du condensé.

  Note : bien que la définition de Content-MD5 soit exactement la même
  pour HTTP que dans la RFC 1864 pour les corps d'entité MIME, il
  existe plusieurs manières dont l'application de Content-MD5 aux corps
  d'entité HTTP diffère de son application aux corps d'entité MIME. L'une
  d'elles est qu'HTTP, contrairement à MIME, n'utilise pas
  Content-Transfer-Encoding, et utilise à la fois Transfer-Encoding et
  Content-Encoding. Une autre est qu'HTTP utilise plus fréquemment des
  types de contenu binaire que MIME, aussi vaut-il la peine de noter
  que, dans de tels cas, l'ordre des octets utilisé pour calculer le
  condensé est l'ordre de transmission des octets défini pour le type.
  Enfin, HTTP autorise la transmission de types texte avec n'importe
  laquelle de plusieurs conventions de saut de ligne et non
  seulement la forme canonique utilisant CRLF.

14.16 Content-Range

L'en-tête d'entité Content-Range est envoyé avec un corps d'entité partiel afin de spécifier où, dans le corps d'entité complet, le corps partiel doit être appliqué. Les unités de plage sont définies à la section 3.12.

   Content-Range = "Content-Range" ":" content-range-spec

   content-range-spec      = byte-content-range-spec
   byte-content-range-spec = bytes-unit SP
                             byte-range-resp-spec "/"
                             ( instance-length | "*" )

   byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
                                  | "*"
   instance-length           = 1*DIGIT

L'en-tête DEVRAIT indiquer la longueur totale du corps d'entité complet, à moins que cette longueur ne soit inconnue ou difficile à déterminer. Le caractère astérisque « * » signifie que la longueur de l'instance est inconnue au moment où la réponse a été générée.

Contrairement aux valeurs byte-ranges-specifier (voir la section 14.35.1), un byte-range-resp-spec NE DOIT spécifier qu'une seule plage, et DOIT contenir des positions d'octets absolues tant pour le premier que pour le dernier octet de la plage.

Un byte-content-range-spec dont le byte-range-resp-spec a une valeur last-byte-pos inférieure à sa valeur first-byte-pos, ou dont la valeur instance-length est inférieure ou égale à sa valeur last-byte-pos, est invalide. Le destinataire d'un byte-content-range-spec invalide DOIT l'ignorer ainsi que tout contenu transféré avec lui.

Un serveur envoyant une réponse avec le code de statut 416 (Requested range not satisfiable) DEVRAIT inclure un champ Content-Range avec un byte-range-resp-spec de « * ». L'instance-length spécifie la longueur actuelle de la ressource sélectionnée. Une réponse avec le code de statut 206 (Partial Content) NE DOIT PAS inclure de champ Content-Range avec un byte-range-resp-spec de « * ».

Exemples de valeurs byte-content-range-spec, en supposant que l'entité contient un total de 1234 octets :

  . Les 500 premiers octets :
   bytes 0-499/1234

  . Les 500 octets suivants :
   bytes 500-999/1234

  . Tous sauf les 500 premiers octets :
   bytes 500-1233/1234

  . Les 500 derniers octets :
   bytes 734-1233/1234

Lorsqu'un message HTTP inclut le contenu d'une seule plage (par exemple, une réponse à une requête pour une seule plage, ou à une requête pour un ensemble de plages qui se chevauchent sans aucun trou), ce contenu est transmis avec un en-tête Content-Range, et un en-tête Content-Length indiquant le nombre d'octets réellement transférés. Par exemple,

   HTTP/1.1 206 Partial content
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
   Content-Range: bytes 21010-47021/47022
   Content-Length: 26012
   Content-Type: image/gif

Lorsqu'un message HTTP inclut le contenu de plusieurs plages (par exemple, une réponse à une requête pour de multiples plages non chevauchantes), celles-ci sont transmises sous forme de message multipart. Le type de média multipart utilisé à cette fin est « multipart/byteranges » tel que défini à l'appendice 19.2. Voir l'appendice 19.6.3 pour un problème de compatibilité.

Une réponse à une requête pour une seule plage NE DOIT PAS être envoyée en utilisant le type de média multipart/byteranges. Une réponse à une requête pour de multiples plages, dont le résultat est une seule plage, PEUT être envoyée sous forme de type de média multipart/byteranges avec une partie. Un client qui ne peut pas décoder un message multipart/byteranges NE DOIT PAS demander de multiples plages d'octets dans une seule requête.

Lorsqu'un client demande plusieurs plages d'octets dans une requête, le serveur DEVRAIT les renvoyer dans l'ordre où elles sont apparues dans la requête.

Si le serveur ignore un byte-range-spec parce qu'il est syntaxiquement invalide, le serveur DEVRAIT traiter la requête comme si le champ d'en-tête Range invalide n'existait pas. (Normalement, cela signifie renvoyer une réponse 200 contenant l'entité complète.)

Si le serveur reçoit une requête (autre qu'une requête incluant un champ d'en-tête de requête If-Range) avec un champ d'en-tête de requête Range non satisfiable (c'est-à-dire dont toutes les valeurs byte-range-spec ont une valeur first-byte-pos supérieure à la longueur actuelle de la ressource sélectionnée), il DEVRAIT renvoyer un code de réponse 416 (Requested range not satisfiable) (section 10.4.17).

  Note : les clients ne peuvent pas compter sur les serveurs pour
  envoyer une réponse 416 (Requested range not satisfiable) au lieu
  d'une réponse 200 (OK) pour une requête Range non satisfiable, étant
  donné que tous les serveurs n'implémentent pas cet en-tête de requête.

14.17 Content-Type

Le champ d'en-tête d'entité Content-Type indique le type de média du corps d'entité envoyé au destinataire ou, dans le cas de la méthode HEAD, le type de média qui aurait été envoyé si la requête avait été un GET.

   Content-Type   = "Content-Type" ":" media-type

Les types de média sont définis à la section 3.7. Un exemple du champ est

   Content-Type: text/html; charset=ISO-8859-4

Une discussion plus approfondie des méthodes d'identification du type de média d'une entité est fournie à la section 7.2.1.

14.18 Date

Le champ d'en-tête général Date représente la date et l'heure auxquelles le message a été émis, ayant la même sémantique que orig-date dans la RFC 822. La valeur du champ est un HTTP-date, tel que décrit à la section 3.3.1 ; il DOIT être envoyé au format date RFC 1123 [8].

   Date  = "Date" ":" HTTP-date

Un exemple est

   Date: Tue, 15 Nov 1994 08:12:31 GMT

Les serveurs d'origine DOIVENT inclure un champ d'en-tête Date dans toutes les réponses, sauf dans les cas suivants :

  1. Si le code de statut de la réponse est 100 (Continue) ou 101
     (Switching Protocols), la réponse PEUT inclure un champ d'en-tête
     Date, à la discrétion du serveur.

  2. Si le code de statut de la réponse traduit une erreur de serveur,
     par exemple 500 (Internal Server Error) ou 503 (Service
     Unavailable), et qu'il est incommode ou impossible de générer une
     Date valide.

  3. Si le serveur ne dispose pas d'horloge capable de fournir une
     approximation raisonnable de l'heure courante, ses réponses NE
     DOIVENT PAS inclure de champ d'en-tête Date. Dans ce cas, les
     règles de la section 14.18.1 DOIVENT être suivies.

Un message reçu ne comportant pas de champ d'en-tête Date DOIT se voir en attribuer un par le destinataire si le message doit être mis en cache par ce destinataire ou transmis par passerelle via un protocole exigeant une Date. Une implémentation HTTP sans horloge NE DOIT PAS mettre en cache des réponses sans les revalider à chaque utilisation. Un cache HTTP, en particulier un cache partagé, DEVRAIT utiliser un mécanisme, tel que NTP [28], pour synchroniser son horloge avec une norme externe fiable.

Les clients NE DEVRAIENT envoyer un champ d'en-tête Date que dans les messages qui incluent un corps d'entité, comme dans le cas des requêtes PUT et POST, et même alors c'est facultatif. Un client sans horloge NE DOIT PAS envoyer de champ d'en-tête Date dans une requête.

Le HTTP-date envoyé dans un en-tête Date NE DEVRAIT PAS représenter une date et une heure postérieures à la génération du message. Il DEVRAIT représenter la meilleure approximation disponible de la date et de l'heure de génération du message, à moins que l'implémentation ne dispose d'aucun moyen de générer une date et une heure raisonnablement exactes. En théorie, la date devrait représenter l'instant juste avant que l'entité soit générée. Dans la pratique, la date peut être générée à n'importe quel moment au cours de l'émission du message sans affecter sa valeur sémantique.

14.18.1 Clockless Origin Server Operation (Fonctionnement d'un serveur d'origine sans horloge)

Certaines implémentations de serveur d'origine peuvent ne pas disposer d'horloge. Un serveur d'origine sans horloge NE DOIT PAS assigner de valeurs Expires ou Last-Modified à une réponse, à moins que ces valeurs n'aient été associées à la ressource par un système ou un utilisateur disposant d'une horloge fiable. Il PEUT assigner une valeur Expires connue, au moment de la configuration du serveur ou avant, comme étant dans le passé (cela permet la « pré-expiration » de réponses sans stocker de valeurs Expires séparées pour chaque ressource).

14.19 ETag

Le champ d'en-tête de réponse ETag fournit la valeur courante de la balise d'entité pour la variante demandée. Les en-têtes utilisés avec les balises d'entité sont décrits aux sections 14.24, 14.26 et 14.44. La balise d'entité PEUT être utilisée pour la comparaison avec d'autres entités de la même ressource (voir la section 13.3.3).

  ETag = "ETag" ":" entity-tag

Exemples :

  ETag: "xyzzy"
  ETag: W/"xyzzy"
  ETag: ""

14.20 Expect

Le champ d'en-tête de requête Expect est utilisé pour indiquer que certains comportements particuliers du serveur sont requis par le client.

  Expect       =  "Expect" ":" 1#expectation

  expectation  =  "100-continue" | expectation-extension
  expectation-extension =  token [ "=" ( token | quoted-string )
                           *expect-params ]
  expect-params =  ";" token [ "=" ( token | quoted-string ) ]

Un serveur qui ne comprend pas ou n'est pas en mesure de se conformer à l'une quelconque des valeurs d'expectation dans le champ Expect d'une requête DOIT répondre avec un statut d'erreur approprié. Le serveur DOIT répondre avec un statut 417 (Expectation Failed) si l'une des expectations ne peut être satisfaite ou, s'il y a d'autres problèmes avec la requête, un autre statut 4xx.

Ce champ d'en-tête est défini avec une syntaxe extensible pour permettre de futures extensions. Si un serveur reçoit une requête contenant un champ Expect qui inclut une expectation-extension qu'il ne prend pas en charge, il DOIT répondre avec un statut 417 (Expectation Failed).

La comparaison des valeurs d'expectation n'est pas sensible à la casse pour les jetons non quotés (y compris le jeton 100-continue), et est sensible à la casse pour les expectation-extensions en quoted-string.

Le mécanisme Expect est saut par saut (hop-by-hop) : autrement dit, un proxy HTTP/1.1 DOIT renvoyer un statut 417 (Expectation Failed) s'il reçoit une requête avec une expectation qu'il ne peut satisfaire. Toutefois, l'en-tête de requête Expect lui-même est de bout en bout ; il DOIT être transmis si la requête est transmise.

De nombreuses applications HTTP/1.0 et HTTP/1.1 plus anciennes ne comprennent pas l'en-tête Expect.

Voir la section 8.2.3 pour l'utilisation du statut 100 (continue).

14.21 Expires

Le champ d'en-tête d'entité Expires donne la date/heure après laquelle la réponse est considérée comme périmée. Une entrée de cache périmée ne peut normalement pas être renvoyée par un cache (qu'il soit un cache proxy ou un cache d'agent utilisateur) à moins qu'elle ne soit d'abord validée auprès du serveur d'origine (ou auprès d'un cache intermédiaire détenant une copie fraîche de l'entité). Voir la section 13.2 pour une discussion plus approfondie du modèle d'expiration.

La présence d'un champ Expires n'implique pas que la ressource d'origine changera ou cessera d'exister à, avant ou après ce moment.

Le format est une date et heure absolue telle que définie par HTTP-date à la section 3.3.1 ; il DOIT être au format date RFC 1123 :

  Expires = "Expires" ":" HTTP-date

Un exemple de son utilisation est

  Expires: Thu, 01 Dec 1994 16:00:00 GMT

  Note : si une réponse inclut un champ Cache-Control avec la directive
  max-age (voir la section 14.9.3), cette directive supplante le champ
  Expires.

Les clients et caches HTTP/1.1 DOIVENT traiter les autres formats de date invalides,

HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").

Pour marquer une réponse comme « déjà expirée », un serveur d'origine envoie une date Expires égale à la valeur de l'en-tête Date. (Voir les règles de calcul d'expiration à la section 13.2.4.)

Pour marquer une réponse comme « n'expire jamais », un serveur d'origine envoie une date Expires environ un an après le moment où la réponse est envoyée. Les serveurs HTTP/1.1 NE DEVRAIENT PAS envoyer de dates Expires à plus d'un an dans le futur.

La présence d'un champ d'en-tête Expires avec une valeur de date située dans le futur sur une réponse qui serait par ailleurs, par défaut, non cacheable indique que la réponse est cacheable, à moins qu'indiqué autrement par un champ d'en-tête Cache-Control (section 14.9).

14.22 From

Le champ d'en-tête de requête From, s'il est fourni, DEVRAIT contenir une adresse de courrier électronique Internet pour l'utilisateur humain qui contrôle l'agent utilisateur demandeur. L'adresse DEVRAIT être exploitable par machine, telle que définie par « mailbox » dans la RFC 822 [9] telle que mise à jour par la RFC 1123 [8] :

   From   = "From" ":" mailbox

Un exemple est :

   From: [email protected]

Ce champ d'en-tête PEUT être utilisé à des fins de journalisation et comme moyen d'identifier la source de requêtes non valides ou indésirables. Il NE DEVRAIT PAS être utilisé comme forme non sécurisée de protection d'accès. L'interprétation de ce champ est que la requête est effectuée au nom de la personne indiquée, qui accepte la responsabilité de la méthode exécutée. En particulier, les agents robots DEVRAIENT inclure cet en-tête afin que la personne responsable de l'exécution du robot puisse être contactée si des problèmes surviennent du côté receveur.

L'adresse de courrier électronique Internet dans ce champ PEUT être distincte de l'hôte Internet ayant émis la requête. Par exemple, lorsqu'une requête est passée par l'intermédiaire d'un proxy, l'adresse de l'émetteur d'origine DEVRAIT être utilisée.

Le client NE DEVRAIT PAS envoyer le champ d'en-tête From sans l'accord de l'utilisateur, car cela pourrait entrer en conflit avec les intérêts de confidentialité de l'utilisateur ou avec la politique de sécurité de son site. Il est fortement recommandé que l'utilisateur puisse désactiver, activer et modifier la valeur de ce champ à tout moment avant une requête.

14.23 Host

Le champ d'en-tête de requête Host spécifie le nom d'hôte Internet et le numéro de port de la ressource demandée, tels qu'obtenus à partir de l'URI d'origine fournie par l'utilisateur ou la ressource référente (généralement une URL HTTP, telle que décrite à la section 3.2.2). La valeur du champ Host DOIT représenter l'autorité de nommage du serveur d'origine ou de la passerelle donnée par l'URL d'origine. Cela permet au serveur d'origine ou à la passerelle de différencier les URL ambiguës en interne, telles que l'URL racine « / » d'un serveur pour de multiples noms d'hôte sur une seule adresse IP.

   Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

Un « host » sans aucune information de port finale implique le port par défaut pour le service demandé (par exemple, « 80 » pour une URL HTTP). Par exemple, une requête sur le serveur d'origine pour « http://www.w3.org/pub/WWW/ » inclurait correctement :

   GET /pub/WWW/ HTTP/1.1
   Host: www.w3.org

Un client DOIT inclure un champ d'en-tête Host dans tous les messages de requête HTTP/1.1. Si l'URI demandée n'inclut pas de nom d'hôte Internet pour le service demandé, alors le champ d'en-tête Host DOIT être fourni avec une valeur vide. Un proxy HTTP/1.1 DOIT s'assurer que tout message de requête qu'il transmet contient un champ d'en-tête Host approprié identifiant le service demandé par le proxy. Tous les serveurs HTTP/1.1 basés sur Internet DOIVENT répondre avec un code de statut 400 (Bad Request) à tout message de requête HTTP/1.1 dépourvu de champ d'en-tête Host.

Voir les sections 5.2 et 19.6.1.1 pour d'autres exigences relatives à Host.

14.24 If-Match

Le champ d'en-tête de requête If-Match est utilisé avec une méthode pour la rendre conditionnelle. Un client qui a précédemment obtenu une ou plusieurs entités à partir de la ressource peut vérifier que l'une de ces entités est courante en incluant une liste de leurs balises d'entité associées dans le champ d'en-tête If-Match. Les balises d'entité sont définies à la section 3.11. L'objectif de cette fonctionnalité est d'autoriser des mises à jour efficaces d'informations en cache avec un minimum de frais de transaction. Elle est également utilisée, sur les requêtes de mise à jour, pour empêcher la modification involontaire de la mauvaise version d'une ressource. À titre de cas particulier, la valeur « * » correspond à toute entité courante de la ressource.

   If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

Si l'une des balises d'entité correspond à la balise d'entité de l'entité qui aurait été renvoyée dans la réponse à une requête GET similaire (sans l'en-tête If-Match) sur cette ressource, ou si « * » est fourni et qu'une entité courante existe pour cette ressource, alors le serveur PEUT exécuter la méthode demandée comme si le champ d'en-tête If-Match n'existait pas.

Un serveur DOIT utiliser la fonction de comparaison forte (voir la section 13.3.3) pour comparer les balises d'entité dans If-Match.

Si aucune des balises d'entité ne correspond, ou si « * » est fourni et qu'aucune entité courante n'existe, le serveur NE DOIT PAS exécuter la méthode demandée, et DOIT renvoyer une réponse 412 (Precondition Failed). Ce comportement est particulièrement utile lorsque le client souhaite empêcher une méthode de mise à jour, telle que PUT, de modifier une ressource qui a changé depuis la dernière récupération par le client.

Si la requête devait, sans le champ d'en-tête If-Match, aboutir à autre chose qu'un statut 2xx ou 412, alors l'en-tête If-Match DOIT être ignoré.

La signification de « If-Match: * » est que la méthode DEVRAIT être exécutée si la représentation sélectionnée par le serveur d'origine (ou par un cache, utilisant éventuellement le mécanisme Vary, voir la section 14.44) existe, et NE DOIT PAS être exécutée si la représentation n'existe pas.

Une requête destinée à mettre à jour une ressource (par exemple, un PUT) PEUT inclure un champ d'en-tête If-Match pour signaler que la méthode de requête NE DOIT PAS être appliquée si l'entité correspondant à la valeur If-Match (une seule balise d'entité) n'est plus une représentation de cette ressource. Cela permet à l'utilisateur d'indiquer qu'il ne souhaite pas que la requête aboutisse si la ressource a été modifiée à son insu. Exemples :

   If-Match: "xyzzy"
   If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
   If-Match: *

Le résultat d'une requête comportant à la fois un champ d'en-tête If-Match et un champ d'en-tête If-None-Match ou If-Modified-Since n'est pas défini par la présente spécification.

14.25 If-Modified-Since

Le champ d'en-tête de requête If-Modified-Since est utilisé avec une méthode pour la rendre conditionnelle : si la variante demandée n'a pas été modifiée depuis l'heure spécifiée dans ce champ, une entité ne sera pas renvoyée par le serveur ; à la place, une réponse 304 (not modified) sera renvoyée sans aucun corps de message.

   If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Un exemple du champ est :

   If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Une méthode GET avec un en-tête If-Modified-Since et sans en-tête Range demande que l'entité identifiée ne soit transférée que si elle a été modifiée depuis la date donnée par l'en-tête If-Modified-Since. L'algorithme pour déterminer cela inclut les cas suivants :

  a) Si la requête aboutirait normalement à autre chose qu'un statut 200
     (OK), ou si la date If-Modified-Since transmise est invalide, la
     réponse est exactement la même que pour un GET normal. Une date
     postérieure à l'heure courante du serveur est invalide.

  b) Si la variante a été modifiée depuis la date If-Modified-Since, la
     réponse est exactement la même que pour un GET normal.

  c) Si la variante n'a pas été modifiée depuis une date If-Modified-Since
     valide, le serveur DEVRAIT renvoyer une réponse 304 (Not Modified).

  d) Si la requête aboutirait normalement à un statut 200 (OK), et que
     l'en-tête If-Modified-Since est valide, la réponse est exactement la
     même que pour un GET normal si la variante n'a pas été modifiée
     depuis la date fournie par l'en-tête If-Modified-Since.

L'objectif de cette fonctionnalité est de permettre des mises à jour efficaces d'informations en cache avec un minimum de frais de transaction.

  Note : Le champ d'en-tête de requête Range modifie la signification de
  If-Modified-Since ; voir la section 14.35 pour tous les détails.

  Note : Les heures If-Modified-Since sont interprétées par le serveur,
  dont l'horloge peut ne pas être synchronisée avec le client.

  Note : Lors du traitement d'un en-tête If-Modified-Since, certains
  serveurs utiliseront une fonction de comparaison de date exacte, plutôt
  qu'une fonction de comparaison « inférieur à », pour décider s'il faut
  envoyer une réponse 304 (Not Modified). Pour obtenir les meilleurs
  résultats lors de l'envoi d'un en-tête If-Modified-Since pour la
  validation du cache, les clients sont conseillés d'utiliser autant que
  possible la chaîne de date exacte reçue dans un en-tête Last-Modified
  précédent.

  Note : Si un client utilise une date arbitraire dans l'en-tête
  If-Modified-Since au lieu d'une date tirée de l'en-tête Last-Modified
  pour la même requête, il doit être conscient que cette date est
  interprétée selon la compréhension du temps qu'en a le serveur. Le
  client doit prendre en compte les horloges non synchronisées et les
  problèmes d'arrondi dus aux différents encodages du temps entre le
  client et le serveur. Cela inclut la possibilité de conditions de
  concurrence si le document a changé entre le moment où il a été
  demandé la première fois et la date If-Modified-Since d'une requête
  ultérieure, ainsi que la possibilité de problèmes liés au décalage
  d'horloge si la date If-Modified-Since est dérivée de l'horloge du
  client sans correction par rapport à l'horloge du serveur. Les
  corrections pour des bases de temps différentes entre le client et le
  serveur sont au mieux approximatives en raison de la latence du réseau.

Le résultat d'une requête comportant à la fois un champ d'en-tête If-Modified-Since et l'un des champs d'en-tête If-Match ou If-Unmodified- Since n'est pas défini par la présente spécification.

14.26 If-None-Match

Le champ d'en-tête de requête If-None-Match est utilisé avec une méthode pour la rendre conditionnelle. Un client qui possède une ou plusieurs entités précédemment obtenues à partir de la ressource peut vérifier qu'aucune de ces entités n'est courante en incluant une liste de leurs balises d'entité associées dans le champ d'en-tête If-None-Match. L'objectif de cette fonctionnalité est de permettre des mises à jour efficaces d'informations en cache avec un minimum de frais de transaction. Elle est également utilisée pour empêcher une méthode (par exemple PUT) de modifier involontairement une ressource existante lorsque le client croit que la ressource n'existe pas.

À titre de cas particulier, la valeur « * » correspond à toute entité courante de la ressource.

   If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

Si l'une des balises d'entité correspond à la balise d'entité de l'entité qui aurait été renvoyée dans la réponse à une requête GET similaire (sans l'en-tête If-None-Match) sur cette ressource, ou si « * » est fourni et qu'une entité courante existe pour cette ressource, alors le serveur NE DOIT PAS exécuter la méthode demandée, à moins d'y être contraint parce que la date de modification de la ressource ne correspond pas à celle fournie dans un en-tête If-Modified-Since de la requête. À la place, si la méthode de requête était GET ou HEAD, le serveur DEVRAIT répondre avec une réponse 304 (Not Modified), incluant les champs d'en-tête liés au cache (en particulier ETag) de l'une des entités qui a correspondu. Pour toutes les autres méthodes de requête, le serveur DOIT répondre avec un statut 412 (Precondition Failed).

Voir la section 13.3.3 pour les règles permettant de déterminer si deux balises d'entité correspondent. La fonction de comparaison faible ne peut être utilisée qu'avec les requêtes GET ou HEAD.

Si aucune des balises d'entité ne correspond, alors le serveur PEUT exécuter la méthode demandée comme si le champ d'en-tête If-None-Match n'existait pas, mais DOIT également ignorer tout champ d'en-tête If-Modified-Since de la requête. Autrement dit, si aucune balise d'entité ne correspond, alors le serveur NE DOIT PAS renvoyer une réponse 304 (Not Modified).

Si la requête aboutirait, sans le champ d'en-tête If-None-Match, à autre chose qu'un statut 2xx ou 304, alors l'en-tête If-None-Match DOIT être ignoré. (Voir la section 13.3.4 pour une discussion du comportement du serveur lorsque If-Modified-Since et If-None-Match apparaissent dans la même requête.)

La signification de « If-None-Match: * » est que la méthode NE DOIT PAS être exécutée si la représentation sélectionnée par le serveur d'origine (ou par un cache, utilisant éventuellement le mécanisme Vary, voir la section 14.44) existe, et DEVRAIT être exécutée si la représentation n'existe pas. Cette fonctionnalité est destinée à être utile pour prévenir les conditions de concurrence entre opérations PUT.

Exemples :

   If-None-Match: "xyzzy"
   If-None-Match: W/"xyzzy"
   If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
   If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
   If-None-Match: *

Le résultat d'une requête comportant à la fois un champ d'en-tête If-None-Match et l'un des champs d'en-tête If-Match ou If-Unmodified-Since n'est pas défini par la présente spécification.

14.27 If-Range

Si un client possède une copie partielle d'une entité dans son cache, et souhaite obtenir une copie à jour de l'entité complète dans son cache, il pourrait utiliser l'en-tête de requête Range avec un GET conditionnel (en utilisant l'un ou l'autre, ou les deux, des en-têtes If-Unmodified-Since et If-Match). Toutefois, si la condition échoue parce que l'entité a été modifiée, le client devrait alors effectuer une seconde requête pour obtenir l'entité courante complète.

L'en-tête If-Range permet à un client de « court-circuiter » la seconde requête. Informellement, sa signification est : « si l'entité est inchangée, envoyez-moi la ou les parties qu'il me manque ; sinon, envoyez-moi l'entité nouvelle complète ».

    If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

Si le client ne dispose pas de balise d'entité pour une entité, mais dispose d'une date Last-Modified, il PEUT utiliser cette date dans un en-tête If-Range. (Le serveur peut distinguer une HTTP-date valide de toute forme de balise d'entité en examinant au plus deux caractères.) L'en-tête If-Range NE DEVRAIT être utilisé qu'associé à un en-tête Range, et DOIT être ignoré si la requête n'inclut pas d'en-tête Range, ou si le serveur ne prend pas en charge l'opération de sous-plage.

Si la balise d'entité fournie dans l'en-tête If-Range correspond à la balise d'entité courante de l'entité, alors le serveur DEVRAIT fournir la sous-plage spécifiée de l'entité au moyen d'une réponse 206 (Partial content). Si la balise d'entité ne correspond pas, alors le serveur DEVRAIT renvoyer l'entité complète au moyen d'une réponse 200 (OK).

14.28 If-Unmodified-Since

Le champ d'en-tête de requête If-Unmodified-Since est utilisé avec une méthode pour la rendre conditionnelle. Si la ressource demandée n'a pas été modifiée depuis l'instant spécifié dans ce champ, le serveur DEVRAIT exécuter l'opération demandée comme si l'en-tête If-Unmodified-Since était absent.

Si la variante demandée a été modifiée depuis l'instant spécifié, le serveur NE DOIT PAS exécuter l'opération demandée, et DOIT renvoyer un statut 412 (Precondition Failed).

  If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

Un exemple du champ est :

   If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si la requête aboutirait normalement (c'est-à-dire sans l'en-tête If-Unmodified-Since) à autre chose qu'un statut 2xx ou 412, l'en-tête If-Unmodified-Since DEVRAIT être ignoré.

Si la date spécifiée est invalide, l'en-tête est ignoré.

Le résultat d'une requête comportant à la fois un champ d'en-tête If-Unmodified-Since et l'un des champs d'en-tête If-None-Match ou If-Modified-Since n'est pas défini par la présente spécification.

14.29 Last-Modified

Le champ d'en-tête d'entité Last-Modified indique la date et l'heure auxquelles le serveur d'origine pense que la variante a été modifiée pour la dernière fois.

   Last-Modified  = "Last-Modified" ":" HTTP-date

Un exemple de son utilisation est

   Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

La signification exacte de ce champ d'en-tête dépend de l'implémentation du serveur d'origine et de la nature de la ressource d'origine. Pour des fichiers, il peut s'agir simplement de l'heure de dernière modification du système de fichiers. Pour des entités comportant des parties incluses dynamiquement, il peut s'agir de la plus récente des dates de dernière modification de ses composants. Pour les passerelles vers des bases de données, il peut s'agir de l'horodatage de dernière mise à jour de l'enregistrement. Pour les objets virtuels, il peut s'agir de la dernière fois où l'état interne a changé.

Un serveur d'origine NE DOIT PAS envoyer une date Last-Modified postérieure à l'heure de génération du message par le serveur. Dans de tels cas, où

un serveur d'origine serait amené à indiquer une date dans le futur pour la dernière modification de la ressource, le serveur DOIT remplacer cette date par la date de génération du message.

Un serveur d'origine DEVRAIT obtenir la valeur Last-Modified de l'entité aussi proche que possible du moment où il génère la valeur Date de sa réponse. Cela permet à un destinataire d'évaluer avec précision le moment de modification de l'entité, particulièrement si l'entité change à proximité du moment où la réponse est générée.

Les serveurs HTTP/1.1 DEVRAIENT envoyer Last-Modified chaque fois que c'est possible.

14.30 Location

Le champ d'en-tête de réponse Location est utilisé pour rediriger le destinataire vers un emplacement autre que le Request-URI pour l'achèvement de la requête ou l'identification d'une nouvelle ressource. Pour les réponses 201 (Created), la valeur Location est celle de la nouvelle ressource qui a été créée par la requête. Pour les réponses 3xx, la valeur Location DEVRAIT indiquer l'URI privilégié par le serveur pour la redirection automatique vers la ressource. La valeur du champ se compose d'un URI absolu unique.

   Location       = "Location" ":" absoluteURI

Un exemple est :

   Location: http://www.w3.org/pub/WWW/People.html

  Note : Le champ d'en-tête Content-Location (section 14.14) diffère de
  Location en ce que Content-Location identifie l'emplacement d'origine de
  l'entité enclose dans la requête. Il est donc possible pour une réponse
  de contenir à la fois les champs d'en-tête Location et Content-Location.
  Voir également la section 13.10 pour les exigences de mise en cache de
  certaines méthodes.

14.31 Max-Forwards

Le champ d'en-tête de requête Max-Forwards fournit un mécanisme, avec les méthodes TRACE (section 9.8) et OPTIONS (section 9.2), pour limiter le nombre de proxies ou de passerelles pouvant transférer la requête vers le serveur d'entrée suivant. Cela peut être utile lorsque le client tente de tracer une chaîne de requêtes qui semble échouer ou boucler en plein milieu de la chaîne.

   Max-Forwards   = "Max-Forwards" ":" 1*DIGIT

La valeur Max-Forwards est un entier décimal indiquant le nombre de fois restant où ce message de requête peut être transféré.

Chaque proxy ou passerelle destinataire d'une requête TRACE ou OPTIONS contenant un champ d'en-tête Max-Forwards DOIT vérifier et mettre à jour sa valeur avant de transférer la requête. Si la valeur reçue est zéro (0), le destinataire NE DOIT PAS transférer la requête ; à la place, il DOIT répondre en tant que destinataire final. Si la valeur Max-Forwards reçue est supérieure à zéro, alors le message transféré DOIT contenir un champ Max-Forwards mis à jour avec une valeur décrémentée de un (1).

Le champ d'en-tête Max-Forwards PEUT être ignoré pour toutes les autres méthodes définies par la présente spécification, ainsi que pour toute méthode d'extension pour laquelle il n'est pas explicitement mentionné comme faisant partie de la définition de cette méthode.

14.32 Pragma

Le champ d'en-tête général Pragma est utilisé pour inclure des directives propres à l'implémentation qui pourraient s'appliquer à tout destinataire le long de la chaîne requête/réponse. Toutes les directives pragma spécifient un comportement facultatif du point de vue du protocole ; toutefois, certains systèmes PEUVENT exiger que le comportement soit cohérent avec les directives.

   Pragma            = "Pragma" ":" 1#pragma-directive
   pragma-directive  = "no-cache" | extension-pragma
   extension-pragma  = token [ "=" ( token | quoted-string ) ]

Lorsque la directive no-cache est présente dans un message de requête, une application DEVRAIT transmettre la requête vers le serveur d'origine même si elle dispose d'une copie en cache de ce qui est demandé. Cette directive pragma a la même sémantique que la directive de cache no-cache (voir la section 14.9) et est définie ici pour la compatibilité ascendante avec HTTP/1.0. Les clients DEVRAIENT inclure les deux champs d'en-tête lorsqu'une requête no-cache est envoyée à un serveur dont on ne sait pas qu'il respecte HTTP/1.1.

Les directives pragma DOIVENT être transmises par une application proxy ou passerelle, indépendamment de leur importance pour cette application, car les directives peuvent s'appliquer à tous les destinataires le long de la chaîne requête/réponse. Il n'est pas possible de spécifier un pragma pour un destinataire particulier ; toutefois, toute directive pragma non pertinente pour un destinataire DEVRAIT être ignorée par celui-ci.

Les caches HTTP/1.1 DEVRAIENT traiter « Pragma: no-cache » comme si le client avait envoyé « Cache-Control: no-cache ». Aucune nouvelle directive Pragma ne sera définie dans HTTP.

  Note : étant donné que la signification de « Pragma: no-cache » en tant
  que champ d'en-tête de réponse n'est pas réellement spécifiée, il ne
  constitue pas un remplacement fiable de « Cache-Control: no-cache »
  dans une réponse.

14.33 Proxy-Authenticate

Le champ d'en-tête de réponse Proxy-Authenticate DOIT être inclus comme partie d'une réponse 407 (Proxy Authentication Required). La valeur du champ se compose d'un défi qui indique le schéma d'authentification et les paramètres applicables au proxy pour ce Request-URI.

   Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge

Le processus d'authentification d'accès HTTP est décrit dans « HTTP Authentication: Basic and Digest Access Authentication » [43]. Contrairement à WWW-Authenticate, le champ d'en-tête Proxy-Authenticate s'applique uniquement à la connexion courante et NE DEVRAIT PAS être transmis aux clients en aval. Toutefois, un proxy intermédiaire pourrait avoir besoin d'obtenir ses propres identifiants en les demandant au client en aval, ce qui, dans certaines circonstances, apparaîtra comme si le proxy transmettait le champ d'en-tête Proxy-Authenticate.

14.34 Proxy-Authorization

Le champ d'en-tête de requête Proxy-Authorization permet au client de s'identifier (ou d'identifier son utilisateur) auprès d'un proxy exigeant une authentification. La valeur du champ Proxy-Authorization se compose d'identifiants contenant les informations d'authentification de l'agent utilisateur pour le proxy et/ou le domaine de la ressource demandée.

   Proxy-Authorization     = "Proxy-Authorization" ":" credentials

Le processus d'authentification d'accès HTTP est décrit dans « HTTP Authentication: Basic and Digest Access Authentication » [43]. Contrairement à Authorization, le champ d'en-tête Proxy-Authorization s'applique uniquement au proxy sortant suivant ayant exigé une authentification au moyen du champ Proxy-Authenticate. Lorsque plusieurs proxies sont utilisés dans une chaîne, le champ d'en-tête Proxy-Authorization est consommé par le premier proxy sortant qui s'attendait à recevoir des identifiants. Un proxy PEUT relayer les identifiants de la requête client vers le proxy suivant si c'est le mécanisme par lequel les proxies authentifient coopérativent une requête donnée.

14.35 Range

14.35.1 Byte Ranges (Plages d'octets)

Puisque toutes les entités HTTP sont représentées dans les messages HTTP comme des séquences d'octets, le concept de plage d'octets a un sens pour toute entité HTTP. (Toutefois, tous les clients et serveurs n'ont pas besoin de prendre en charge les opérations sur les plages d'octets.)

Les spécifications de plage d'octets dans HTTP s'appliquent à la séquence d'octets dans le corps d'entité (pas nécessairement identique au corps de message).

Une opération de plage d'octets PEUT spécifier une seule plage d'octets, ou un ensemble de plages au sein d'une seule entité.

   ranges-specifier = byte-ranges-specifier
   byte-ranges-specifier = bytes-unit "=" byte-range-set
   byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
   byte-range-spec = first-byte-pos "-" [last-byte-pos]
   first-byte-pos  = 1*DIGIT
   last-byte-pos   = 1*DIGIT

La valeur first-byte-pos dans un byte-range-spec donne le décalage d'octet du premier octet d'une plage. La valeur last-byte-pos donne le décalage d'octet du dernier octet de la plage ; autrement dit, les positions d'octets spécifiées sont inclusives. Les décalages d'octets commencent à zéro.

Si la valeur last-byte-pos est présente, elle DOIT être supérieure ou égale à la valeur first-byte-pos dans ce byte-range-spec, sinon le byte-range-spec est syntaxiquement invalide. Le destinataire d'un byte-range-set incluant une ou plusieurs valeurs byte-range-spec syntaxiquement invalides DOIT ignorer le champ d'en-tête qui inclut ce byte-range-set.

Si la valeur last-byte-pos est absente, ou si la valeur est supérieure ou égale à la longueur courante du corps d'entité, last-byte-pos est pris égal à un de moins que la longueur courante du corps d'entité en octets.

Par le choix de last-byte-pos, un client peut limiter le nombre d'octets récupérés sans connaître la taille de l'entité.

   suffix-byte-range-spec = "-" suffix-length
   suffix-length = 1*DIGIT

Un suffix-byte-range-spec est utilisé pour spécifier le suffixe du corps d'entité, d'une longueur donnée par la valeur suffix-length. (Autrement dit, cette forme spécifie les N derniers octets d'un corps d'entité.) Si la

entité est plus courte que la longueur de suffixe spécifiée, l'intégralité du corps d'entité est utilisée.

Si un byte-range-set syntaxiquement valide inclut au moins un byte-range-spec dont le first-byte-pos est inférieur à la longueur courante du corps d'entité, ou au moins un suffix-byte-range-spec avec une suffix-length non nulle, alors le byte-range-set est satisfiable. Sinon, le byte-range-set est insatisfiable. Si le byte-range-set est insatisfiable, le serveur DEVRAIT renvoyer une réponse avec un statut 416 (Requested range not satisfiable). Sinon, le serveur DEVRAIT renvoyer une réponse avec un statut 206 (Partial Content) contenant les plages satisfiables du corps d'entité.

Exemples de valeurs byte-ranges-specifier (en supposant un corps d'entité de longueur 10000) :

  - Les 500 premiers octets (décalages d'octets 0-499, inclus) :
    bytes=0-499

  - Les 500 octets suivants (décalages d'octets 500-999, inclus) :
    bytes=500-999

  - Les 500 derniers octets (décalages d'octets 9500-9999, inclus) :
    bytes=-500

  - Ou bytes=9500-

  - Les premier et dernier octets uniquement (octets 0 et 9999) :
    bytes=0-0,-1

  - Plusieurs spécifications légales mais non canoniques des 500 octets
    suivants (décalages d'octets 500-999, inclus) :
     bytes=500-600,601-999
     bytes=500-700,601-999

14.35.2 Range Retrieval Requests (Requêtes de récupération par plage)

Les requêtes de récupération HTTP utilisant des méthodes GET conditionnelles ou inconditionnelles PEUVENT demander une ou plusieurs sous-plages de l'entité, au lieu de l'entité complète, au moyen de l'en-tête de requête Range, qui s'applique à l'entité renvoyée comme résultat de la requête :

  Range = "Range" ":" ranges-specifier

Un serveur PEUT ignorer l'en-tête Range. Toutefois, les serveurs d'origine HTTP/1.1 et les caches intermédiaires devraient prendre en charge les plages d'octets lorsque c'est possible, étant donné que Range favorise une récupération efficace après des transferts partiellement échoués, et favorise la récupération partielle efficace de grandes entités.

Si le serveur prend en charge l'en-tête Range et que la ou les plages spécifiées conviennent à l'entité :

  - La présence d'un en-tête Range dans un GET inconditionnel modifie ce
    qui est renvoyé si le GET réussit par ailleurs. Autrement dit, la
    réponse porte un code de statut 206 (Partial Content) au lieu de 200
    (OK).

  - La présence d'un en-tête Range dans un GET conditionnel (une requête
    utilisant l'un ou les deux en-têtes If-Modified-Since et
    If-None-Match, ou l'un ou les deux en-têtes If-Unmodified-Since et
    If-Match) modifie ce qui est renvoyé si le GET réussit par ailleurs et
    que la condition est vraie. Cela n'affecte pas la réponse 304 (Not
    Modified) renvoyée si la condition est fausse.

Dans certains cas, il peut être plus approprié d'utiliser l'en-tête If-Range (voir la section 14.27) en plus de l'en-tête Range.

Si un proxy prenant en charge les plages reçoit une requête Range, transmet la requête à un serveur d'entrée, et reçoit en réponse une entité complète, il NE DEVRAIT renvoyer que la plage demandée à son client. Il DEVRAIT stocker l'intégralité de la réponse reçue dans son cache si cela est cohérent avec ses politiques d'allocation de cache.

14.36 Referer

Le champ d'en-tête de requête Referer [sic] permet au client de spécifier, pour le bénéfice du serveur, l'adresse (URI) de la ressource à partir de laquelle le Request-URI a été obtenu (le « référent », bien que le champ d'en-tête soit mal orthographié). Le champ de requête Referer permet à un serveur de générer des listes de liens retour vers des ressources à des fins d'intérêt, de journalisation, de mise en cache optimisée, etc. Il permet également de tracer des liens obsolètes ou mal saisis aux fins de maintenance. Le champ Referer NE DOIT PAS être envoyé si le Request-URI a été obtenu à partir d'une source ne possédant pas son propre URI, telle qu'une saisie au clavier par l'utilisateur.

   Referer        = "Referer" ":" ( absoluteURI | relativeURI )

Exemple :

   Referer: http://www.w3.org/hypertext/DataSources/Overview.html

Si la valeur du champ est un URI relatif, il DEVRAIT être interprété relativement au Request-URI. L'URI NE DOIT PAS inclure de fragment. Voir la section 15.1.3 pour les considérations de sécurité.

14.37 Retry-After

Le champ d'en-tête de réponse Retry-After peut être utilisé avec une réponse 503 (Service Unavailable) pour indiquer combien de temps le service devrait rester indisponible pour le client demandeur. Ce champ PEUT également être utilisé avec toute réponse 3xx (Redirection) pour indiquer le temps minimal pendant lequel l'agent utilisateur est prié d'attendre avant d'émettre la requête redirigée. La valeur de ce champ peut être soit une HTTP-date, soit un nombre entier de secondes (en décimal) après l'heure de la réponse.

   Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

Deux exemples de son utilisation sont

   Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
   Retry-After: 120

Dans ce dernier exemple, le délai est de 2 minutes.

14.38 Server

Le champ d'en-tête de réponse Server contient des informations sur le logiciel utilisé par le serveur d'origine pour traiter la requête. Le champ peut contenir plusieurs jetons produit (section 3.8) et commentaires identifiant le serveur et tout sous-produit significatif. Les jetons produit sont listés par ordre de leur importance pour l'identification de l'application.

   Server         = "Server" ":" 1*( product | comment )

Exemple :

   Server: CERN/3.0 libwww/2.17

Si la réponse est retransmise via un proxy, l'application proxy NE DOIT PAS modifier l'en-tête de réponse Server. À la place, elle DEVRAIT inclure un champ Via (tel que décrit à la section 14.45).

  Note : Révéler la version logicielle spécifique du serveur pourrait
  rendre la machine serveur plus vulnérable aux attaques ciblant des
  logiciels connus pour contenir des failles de sécurité. Les
  implémenteurs de Server sont encouragés à rendre ce champ configurable.

14.39 TE

Le champ d'en-tête de requête TE indique quels codages de transfert d'extension il est disposé à accepter dans la réponse, et s'il est disposé à accepter des champs de fin (trailer) dans un codage de transfert fragmenté. Sa valeur peut consister en le mot-clé « trailers » et/ou une liste séparée par des virgules de noms de codages de transfert d'extension avec paramètres d'acceptation facultatifs (tels que décrits à la section 3.6).

   TE        = "TE" ":" #( t-codings )
   t-codings = "trailers" | ( transfer-extension [ accept-params ] )

La présence du mot-clé « trailers » indique que le client est disposé à accepter des champs de fin dans un codage de transfert fragmenté, tel que défini à la section 3.6.1. Ce mot-clé est réservé à un usage avec des valeurs de codage de transfert, bien qu'il ne représente pas lui-même un codage de transfert.

Des exemples de son utilisation sont :

   TE: deflate
   TE:
   TE: trailers, deflate;q=0.5

Le champ d'en-tête TE ne s'applique qu'à la connexion immédiate. Par conséquent, le mot-clé DOIT être fourni au sein d'un champ d'en-tête Connection (section 14.10) chaque fois que TE est présent dans un message HTTP/1.1.

Un serveur teste si un codage de transfert est acceptable, selon un champ TE, en utilisant ces règles :

  1. Le codage de transfert « chunked » est toujours acceptable. Si le
     mot-clé « trailers » est listé, le client indique qu'il est disposé
     à accepter des champs de fin dans la réponse fragmentée pour lui-même
     et pour tout client en aval. Cela implique que, si indiqué, le client
     déclare soit que tous les clients en aval sont disposés à accepter
     des champs de fin dans la réponse retransmise, soit qu'il tentera de
     mettre en tampon la réponse pour le compte des destinataires en aval.

     Note : HTTP/1.1 ne définit aucun moyen de limiter la taille d'une
     réponse fragmentée de sorte qu'un client puisse être assuré de pouvoir
     mettre en tampon la réponse entière.

  2. Si le codage de transfert testé est l'un des codages de transfert
     listés dans le champ TE, alors il est acceptable à moins qu'il ne
     soit accompagné d'une qvalue de 0. (Telle que définie à la section
     3.9, une qvalue de 0 signifie « non acceptable ».)

  3. Si plusieurs codages de transfert sont acceptables, alors le codage
     de transfert acceptable avec la plus grande qvalue non nulle est
     privilégié. Le codage de transfert « chunked » a toujours une qvalue
     de 1.

Si la valeur du champ TE est vide ou si aucun champ TE n'est présent, le seul codage de transfert est « chunked ». Un message sans codage de transfert est toujours acceptable.

14.40 Trailer

La valeur du champ général Trailer indique que l'ensemble de champs d'en-tête donné est présent dans la fin (trailer) d'un message encodé avec le codage de transfert fragmenté.

   Trailer  = "Trailer" ":" 1#field-name

Un message HTTP/1.1 DEVRAIT inclure un champ d'en-tête Trailer dans un message utilisant le codage de transfert fragmenté avec une fin non vide. Ce faisant, le destinataire sait quels champs d'en-tête attendre dans la fin.

Si aucun champ d'en-tête Trailer n'est présent, la fin NE DEVRAIT inclure aucun champ d'en-tête. Voir la section 3.6.1 pour les restrictions sur l'utilisation des champs de fin dans un codage de transfert « chunked ».

Les champs d'en-tête de message listés dans le champ d'en-tête Trailer NE DOIVENT PAS inclure les champs d'en-tête suivants :

  . Transfer-Encoding

  . Content-Length

  . Trailer

14.41 Transfer-Encoding

Le champ d'en-tête général Transfer-Encoding indique quelle(s) transformation(s) (le cas échéant) ont été appliquées au corps de message afin de le transférer en toute sécurité entre l'expéditeur et le destinataire. Cela diffère du content-coding en ce que le transfer-coding est une propriété du message, non de l'entité.

 Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

Les transfer-codings sont définis à la section 3.6. Un exemple est :

 Transfer-Encoding: chunked

Si plusieurs codages ont été appliqués à une entité, les transfer-codings DOIVENT être listés dans l'ordre où ils ont été appliqués. Des informations additionnelles sur les paramètres de codage PEUVENT être fournies par d'autres champs d'en-tête d'entité non définis par la présente spécification.

De nombreuses applications plus anciennes HTTP/1.0 ne comprennent pas l'en-tête Transfer-Encoding.

14.42 Upgrade

Le champ d'en-tête général Upgrade permet au client de spécifier quels protocoles de communication additionnels il prend en charge et souhaiterait utiliser si le serveur juge approprié de changer de protocole. Le serveur DOIT utiliser le champ d'en-tête Upgrade au sein d'une réponse 101 (Switching Protocols) pour indiquer le(s) protocole(s) vers le(s)quel(s) le changement s'opère.

   Upgrade        = "Upgrade" ":" 1#product

Par exemple,

   Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Le champ d'en-tête Upgrade est destiné à fournir un mécanisme simple pour la transition de HTTP/1.1 vers un autre protocole, incompatible. Il le fait en permettant au client d'annoncer son désir d'utiliser un autre protocole, tel qu'une version ultérieure de HTTP avec un numéro de version majeure supérieur, même si la requête courante a été formulée en utilisant HTTP/1.1. Cela facilite la difficile transition entre protocoles incompatibles en permettant au client d'initier une requête dans le protocole le plus largement pris en charge, tout en indiquant au serveur qu'il aimerait utiliser un protocole « meilleur » si disponible (où « meilleur » est déterminé par le serveur, possiblement selon la nature de la méthode et/ou de la ressource demandée).

Le champ d'en-tête Upgrade ne s'applique qu'au changement de protocoles de couche application sur la connexion de couche transport existante. Upgrade ne peut être utilisé pour exiger un changement de protocole ; son acceptation et son utilisation par le serveur sont facultatives. Les capacités et la nature de la communication de couche application après le changement de protocole dépendent entièrement du nouveau protocole choisi, bien que la première action après le changement de protocole DOIVE être une réponse à la requête HTTP initiale contenant le champ d'en-tête Upgrade.

Le champ d'en-tête Upgrade ne s'applique qu'à la connexion immédiate. Par conséquent, le mot-clé upgrade DOIT être fourni au sein d'un champ d'en-tête Connection (section 14.10) chaque fois que Upgrade est présent dans un message HTTP/1.1.

Le champ d'en-tête Upgrade ne peut pas être utilisé pour indiquer un changement vers un protocole sur une connexion différente. À cette fin, il est plus approprié d'utiliser une réponse de redirection 301, 302, 303 ou 305.

La présente spécification ne définit que le nom de protocole « HTTP » pour l'usage de la famille des protocoles de transfert hypertexte, tel que défini par les règles de version HTTP de la section 3.1 et les mises à jour futures de cette spécification. N'importe quel jeton peut être utilisé comme nom de protocole ; toutefois, il ne sera utile que si le client et le serveur associent tous deux le nom au même protocole.

14.43 User-Agent

Le champ d'en-tête de requête User-Agent contient des informations sur l'agent utilisateur à l'origine de la requête. Cela sert à des fins statistiques, à la traçabilité des violations de protocole, et à la reconnaissance automatique des agents utilisateurs afin d'adapter les réponses pour éviter certaines limites des agents utilisateurs. Les agents utilisateurs DEVRAIENT inclure ce champ avec les requêtes. Le champ peut contenir plusieurs jetons produit (section 3.8) et commentaires identifiant l'agent et tout sous-produit constituant une partie significative de l'agent utilisateur. Par convention, les jetons produit sont listés par ordre de leur importance pour l'identification de l'application.

   User-Agent     = "User-Agent" ":" 1*( product | comment )

Exemple :

   User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.44 Vary

La valeur du champ Vary indique l'ensemble des champs d'en-tête de requête qui détermine de façon exhaustive, tant que la réponse est fraîche, si un cache est autorisé à utiliser la réponse pour répondre à une requête ultérieure sans revalidation. Pour les réponses non cacheables ou périmées, la valeur du champ Vary renseigne l'agent utilisateur sur les critères qui ont été utilisés pour sélectionner la représentation. Une valeur de champ Vary égale à « * » implique qu'un cache ne peut pas déterminer, à partir des en-têtes de requête d'une requête ultérieure, si cette réponse est la représentation appropriée. Voir la section 13.6 pour l'utilisation du champ d'en-tête Vary par les caches.

   Vary  = "Vary" ":" ( "*" | 1#field-name )

Un serveur HTTP/1.1 DEVRAIT inclure un champ d'en-tête Vary avec toute réponse cacheable soumise à une négociation pilotée par le serveur. Ce faisant, un cache peut interpréter correctement les requêtes futures sur cette ressource et informer l'agent utilisateur de la présence de négociation sur cette ressource. Un serveur PEUT inclure un champ d'en-tête Vary avec une réponse non cacheable soumise à une négociation pilotée par le serveur, étant donné que cela pourrait fournir à l'agent utilisateur des informations utiles sur les dimensions selon lesquelles la réponse varie au moment de la réponse.

Une valeur de champ Vary consistant en une liste de noms de champs signale que la représentation sélectionnée pour la réponse repose sur un algorithme de sélection qui ne considère QUE les valeurs des champs d'en-tête de requête listés pour choisir la représentation la plus appropriée. Un cache PEUT supposer que la même sélection sera effectuée pour les requêtes futures avec les mêmes valeurs pour les noms de champs listés, pendant la durée pendant laquelle la réponse est fraîche.

Les noms de champs donnés ne sont pas limités à l'ensemble des champs d'en-tête de requête standard définis par la présente spécification. Les noms de champs ne sont pas sensibles à la casse.

Une valeur de champ Vary égale à « * » signale que des paramètres non spécifiés, non limités aux en-têtes de requête (par exemple, l'adresse réseau du client), jouent un rôle dans la sélection de la représentation de réponse. La valeur « * » NE DOIT PAS être générée par un serveur proxy ; elle ne peut être générée que par un serveur d'origine.

14.45 Via

Le champ d'en-tête général Via DOIT être utilisé par les passerelles et les proxies pour indiquer les protocoles intermédiaires et les destinataires entre l'agent utilisateur et le serveur sur les requêtes, et entre le serveur d'origine et le client sur les réponses. Il est analogue au champ « Received » de la RFC 822 [9] et est destiné à être utilisé pour tracer les transferts de messages, éviter les boucles de requêtes, et identifier les capacités de protocole de tous les expéditeurs le long de la chaîne requête/réponse.

  Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
  received-protocol = [ protocol-name "/" ] protocol-version
  protocol-name     = token
  protocol-version  = token
  received-by       = ( host [ ":" port ] ) | pseudonym
  pseudonym         = token

Le received-protocol indique la version de protocole du message reçu par le serveur ou le client le long de chaque segment de la chaîne requête/réponse. La version received-protocol est ajoutée à la valeur du champ Via lorsque le message est transféré, afin que l'information sur les capacités de protocole des applications en amont reste visible pour tous les destinataires.

Le protocol-name est facultatif si et seulement si il serait « HTTP ». Le champ received-by est normalement l'hôte et le numéro de port facultatif d'un serveur ou client destinataire ayant ensuite transféré le message. Toutefois, si le véritable hôte est considéré comme une information sensible, il PEUT être remplacé par un pseudonyme. Si le port n'est pas donné, il PEUT être supposé être le port par défaut du received-protocol.

Plusieurs valeurs de champ Via représentent chaque proxy ou passerelle ayant transféré le message. Chaque destinataire DOIT ajouter ses informations de sorte que le résultat final soit ordonné selon la séquence des applications de transfert.

Des commentaires PEUVENT être utilisés dans le champ d'en-tête Via pour identifier le logiciel du proxy ou de la passerelle destinataire, par analogie avec les champs d'en-tête User-Agent et Server. Toutefois, tous les commentaires du champ Via sont facultatifs et PEUVENT être supprimés par tout destinataire avant de transférer le message.

Par exemple, un message de requête pourrait être envoyé depuis un agent utilisateur HTTP/1.0 vers un proxy interne surnommé « fred », qui utilise HTTP/1.1 pour transférer la requête à un proxy public chez nowhere.com, qui achève la requête en la transférant au serveur d'origine chez www.ics.uci.edu. La requête reçue par www.ics.uci.edu comporterait alors le champ d'en-tête Via suivant :

   Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Les proxies et passerelles utilisés comme portail à travers un pare-feu de réseau NE DEVRAIENT PAS, par défaut, transférer les noms et ports des hôtes à l'intérieur de la région du pare-feu. Cette information NE DEVRAIT être propagée que si elle est explicitement activée. Si elle ne l'est pas, le received-by host de tout hôte situé derrière le pare-feu DEVRAIT être remplacé par un pseudonyme approprié pour cet hôte.

Pour les organisations ayant de fortes exigences de confidentialité quant à la dissimulation de structures internes, un proxy PEUT combiner une sous-séquence ordonnée d'entrées de champ d'en-tête Via ayant des valeurs received-protocol identiques en une seule entrée. Par exemple,

   Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

    pourrait être réduit à

   Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Les applications NE DEVRAIENT PAS combiner plusieurs entrées à moins qu'elles ne soient toutes sous le même contrôle organisationnel et que les hôtes n'aient déjà été remplacés par des pseudonymes. Les applications NE DOIVENT PAS combiner des entrées ayant des valeurs received-protocol différentes.

14.46 Warning

Le champ d'en-tête général Warning est utilisé pour transporter des informations additionnelles sur l'état ou la transformation d'un message qui pourraient ne pas être reflétées dans le message. Cette information est typiquement utilisée pour avertir d'un manque possible de transparence sémantique provenant d'opérations de mise en cache ou de transformations appliquées au corps d'entité du message.

Les en-têtes Warning sont envoyés avec les réponses en utilisant :

   Warning    = "Warning" ":" 1#warning-value

   warning-value = warn-code SP warn-agent SP warn-text
                                         [SP warn-date]

   warn-code  = 3DIGIT
   warn-agent = ( host [ ":" port ] ) | pseudonym
                   ; le nom ou le pseudonyme du serveur ajoutant
                   ; l'en-tête Warning, à des fins de débogage
   warn-text  = quoted-string
   warn-date  = `<">` HTTP-date `<">`

Une réponse PEUT transporter plus d'un en-tête Warning.

Le warn-text DEVRAIT être dans une langue naturelle et un jeu de caractères les plus susceptibles d'être intelligibles pour l'utilisateur humain recevant la réponse. Cette décision PEUT être basée sur toute connaissance disponible, telle que l'emplacement du cache ou de l'utilisateur, le champ Accept-Language dans une requête, le champ Content-Language dans une réponse, etc. La langue par défaut est l'anglais et le jeu de caractères par défaut est ISO-8859-1.

Si un jeu de caractères autre que ISO-8859-1 est utilisé, il DOIT être encodé dans le warn-text en utilisant la méthode décrite dans la RFC 2047 [14].

Les en-têtes Warning peuvent en général être appliqués à tout message, toutefois certains warn-codes spécifiques sont propres aux caches et ne peuvent être appliqués qu'aux messages de réponse. Les nouveaux en-têtes Warning DEVRAIENT être ajoutés après tout en-tête Warning existant. Un cache NE DOIT PAS supprimer tout en-tête Warning qu'il a reçu avec un message. Toutefois, si un cache valide avec succès une entrée de cache, il DEVRAIT supprimer tout en-tête Warning précédemment attaché à cette entrée, sauf tel que spécifié pour des warn-codes spécifiques. Il DOIT alors ajouter tout en-tête Warning reçu dans la réponse de validation. En d'autres termes, les en-têtes Warning sont ceux qui seraient attachés à la réponse pertinente la plus récente.

Lorsque plusieurs en-têtes Warning sont attachés à une réponse, l'agent utilisateur devrait informer l'utilisateur du plus grand nombre d'entre eux possible, dans l'ordre où ils apparaissent dans la réponse. S'il n'est pas possible d'informer l'utilisateur de tous les avertissements, l'agent utilisateur DEVRAIT suivre ces heuristiques :

  - Les avertissements apparaissant tôt dans la réponse ont la priorité
    sur ceux apparaissant plus tard dans la réponse.

  - Les avertissements dans le jeu de caractères préféré de l'utilisateur
    ont la priorité sur les avertissements dans d'autres jeux de caractères
    mais avec des warn-codes et warn-agents identiques.

Les systèmes générant plusieurs en-têtes Warning DEVRAIENT les ordonner en gardant ce comportement de l'agent utilisateur à l'esprit.

Les exigences relatives au comportement des caches vis-à-vis des avertissements sont énoncées à la section 13.1.2.

Voici une liste des warn-codes actuellement définis, chacun avec un texte d'avertissement recommandé en anglais et une description de sa signification.

110 Response is stale (La réponse est périmée) DOIT être inclus chaque fois que la réponse renvoyée est périmée.

111 Revalidation failed (La revalidation a échoué) DOIT être inclus si un cache renvoie une réponse périmée parce qu'une tentative de revalidation de la réponse a échoué, due à une impossibilité de joindre le serveur.

112 Disconnected operation (Fonctionnement déconnecté) DEVRAIT être inclus si le cache est intentionnellement déconnecté du reste du réseau pendant une période de temps.

113 Heuristic expiration (Expiration heuristique) DOIT être inclus si le cache a choisi heuristiquement une durée de fraîcheur supérieure à 24 heures et que l'âge de la réponse est supérieur à 24 heures.

199 Miscellaneous warning (Avertissement divers) Le texte d'avertissement PEUT inclure des informations arbitraires à présenter à un utilisateur humain, ou à journaliser. Un système recevant cet avertissement NE DOIT PAS prendre d'action automatisée, au-delà de présenter l'avertissement à l'utilisateur.

214 Transformation applied (Transformation appliquée) DOIT être ajouté par un cache ou proxy intermédiaire s'il applique toute transformation modifiant le content-coding (tel que spécifié dans l'en-tête Content-Encoding) ou le media-type (tel que spécifié dans l'en-tête Content-Type) de la réponse, ou le corps d'entité de la réponse, à moins que ce code d'avertissement n'apparaisse déjà dans la réponse.

299 Miscellaneous persistent warning (Avertissement persistant divers) Le texte d'avertissement PEUT inclure des informations arbitraires à présenter à un utilisateur humain, ou à journaliser. Un système recevant cet avertissement NE DOIT PAS prendre d'action automatisée.

Si une implémentation envoie un message avec un ou plusieurs en-têtes Warning dont la version est HTTP/1.0 ou inférieure, alors l'expéditeur DOIT inclure dans chaque warning-value une warn-date correspondant à la date de la réponse.

Si une implémentation reçoit un message avec une warning-value incluant une warn-date, et que cette warn-date est différente de la valeur Date de la réponse, alors cette warning-value DOIT être supprimée du message avant de le stocker, de le transférer, ou de l'utiliser. (Cela évite les mauvaises conséquences d'une mise en cache naïve des champs d'en-tête Warning.) Si toutes les warning-values sont supprimées pour cette raison, l'en-tête Warning DOIT également être supprimé.

14.47 WWW-Authenticate

Le champ d'en-tête de réponse WWW-Authenticate DOIT être inclus dans les messages de réponse 401 (Unauthorized). La valeur du champ se compose d'au moins un défi qui indique le(s) schéma(s) d'authentification et les paramètres applicables au Request-URI.

   WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

Le processus d'authentification d'accès HTTP est décrit dans « HTTP Authentication: Basic and Digest Access Authentication » [43]. Les agents utilisateurs sont conseillés de faire preuve d'une grande prudence dans l'analyse de la valeur du champ WWW-Authenticate car il pourrait contenir plus d'un défi, ou, si plus d'un champ d'en-tête WWW-Authenticate est fourni, le contenu d'un défi lui-même peut contenir une liste d'identifiants d'authentification séparée par des virgules.