3. Protocol Parameters (Paramètres du Protocole)
3.1 HTTP Version (Version HTTP)
HTTP utilise un schéma de numérotation "<major>.<minor>" pour indiquer les versions du protocole. La politique de version du protocole est destinée à permettre à l'expéditeur d'indiquer le format d'un message et sa capacité à comprendre une communication HTTP ultérieure, plutôt que les fonctionnalités obtenues via cette communication. Aucune modification n'est apportée au numéro de version pour les ajouts aux composants de message qui n'affectent pas le comportement de communication ou qui ne font qu'ajouter aux valeurs de champ extensibles. Le numéro <minor> est incrémenté lorsque les modifications apportées au protocole ajoutent des fonctionnalités qui ne changent pas l'algorithme d'analyse de message général, mais peuvent ajouter à la sémantique du message et impliquer des capacités supplémentaires de l'expéditeur. Le numéro <major> est incrémenté lorsque le format des messages dans le protocole est modifié. Voir RFC 2145 [36] pour une explication plus complète.
La version d'un message HTTP est indiquée par un champ HTTP-Version dans la première ligne du message.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Notez que les numéros de version majeure et mineure doivent (MUST) être traités comme des entiers séparés et que chaque numéro peut (MAY) être incrémenté au-delà d'un seul chiffre. Ainsi, HTTP/2.4 est une version inférieure à HTTP/2.13, qui est elle-même inférieure à HTTP/12.3. Les zéros de tête doivent (MUST) être ignorés par les destinataires et ne doivent pas (MUST NOT) être envoyés.
Une application qui envoie un message de requête ou de réponse contenant "HTTP/1.1" comme HTTP-Version doit (MUST) être au moins conditionnellement conforme à cette spécification. Les applications qui sont au moins conditionnellement conformes à cette spécification devraient (SHOULD) utiliser une HTTP-Version de "HTTP/1.1" dans leurs messages, et doivent (MUST) le faire pour tout message qui n'est pas compatible avec HTTP/1.0. Pour plus de détails sur le moment d'envoyer une valeur HTTP-Version spécifique, voir RFC 2145 [36].
La version HTTP d'une application est la version HTTP la plus élevée à laquelle l'application est au moins conditionnellement conforme.
Les applications proxy et passerelle doivent être prudentes lorsqu'elles transmettent des messages d'une version de protocole différente de celle de l'application. Étant donné que la version du protocole indique la capacité du protocole de l'expéditeur, un proxy/passerelle ne doit pas (MUST NOT) envoyer un message avec un indicateur de version supérieur à sa version réelle. Si une requête de version supérieure est reçue, le proxy/passerelle doit (MUST) soit dégrader la version de la requête, soit répondre avec une erreur, soit passer en comportement tunnel.
En raison des problèmes d'interopérabilité avec les proxies HTTP/1.0 découverts depuis la publication de RFC 2068 [33], les proxies de mise en cache doivent (MUST), les passerelles peuvent (MAY), et les tunnels ne doivent pas (MUST NOT) mettre à niveau la requête vers la version la plus élevée qu'ils prennent en charge. La réponse du proxy/passerelle à cette requête doit (MUST) être dans la même version majeure que la requête.
Note : La conversion entre les versions HTTP peut impliquer la modification des champs d'en-tête requis ou interdits par les versions impliquées.
3.2 Uniform Resource Identifiers (Identificateurs de Ressources Uniformes)
Les URI ont de nombreux noms : adresses WWW, Universal Document Identifiers, Universal Resource Identifiers [3], et enfin la combinaison de Localisateurs de Ressources Uniformes (Uniform Resource Locators, URL) [4] et de Noms (Names, URN) [20]. En ce qui concerne HTTP, les Identificateurs de Ressources Uniformes (Uniform Resource Identifiers) sont simplement des chaînes formatées qui identifient une ressource par un nom, un emplacement ou toute autre caractéristique.
3.2.1 General Syntax (Syntaxe Générale)
Les URI dans HTTP peuvent être représentés sous forme absolue ou relativement à un URI de base connu [11], selon le contexte de leur utilisation. La distinction entre ces deux formes est que les URI absolus commencent toujours par un nom de schéma suivi de deux points. Pour des informations faisant autorité sur la syntaxe et la sémantique des URL, voir "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396 [42] (qui remplace RFC 1738 [4] et RFC 1808 [11]). Cette spécification adopte les définitions de "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path" et "authority" de cette spécification.
Le protocole HTTP n'impose aucune limitation a priori sur la longueur des URI. Les serveurs doivent (MUST) être capables de gérer les URI de toutes les ressources qu'ils servent, et devraient (SHOULD) être capables de gérer des URI de longueur illimitée s'ils fournissent des formulaires basés sur GET qui pourraient générer de tels URI. Un serveur devrait (SHOULD) retourner un statut 414 (Request-URI Too Long) (voir section 10.4.15) si un URI est plus long que le serveur ne peut le gérer.
Note : Les serveurs devraient être prudents quant à la dépendance vis-à-vis de longueurs d'URI supérieures à 255 octets, car certaines implémentations de clients ou de proxies plus anciennes peuvent ne pas prendre en charge correctement ces longueurs.
3.2.2 http URL
Le schéma "http" est utilisé pour localiser des ressources réseau via le protocole HTTP. Cette section définit la syntaxe et la sémantique spécifiques au schéma de l'URL http.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Si le port est vide ou non fourni, le port 80 est supposé. La sémantique est que la ressource identifiée est située sur le serveur écoutant les connexions TCP sur ce port de cet hôte, et le Request-URI de la ressource est abs_path (section 5.1.2). L'utilisation d'adresses IP dans les URL devrait (SHOULD) être évitée autant que possible (voir RFC 1900 [24]). Si abs_path n'est pas présent dans l'URL, il doit (MUST) être spécifié comme "/" lorsqu'il est utilisé comme Request-URI pour une ressource (section 5.1.2). Si un proxy reçoit un nom d'hôte qui n'est pas un nom de domaine pleinement qualifié, il peut (MAY) ajouter son domaine au nom d'hôte qu'il a reçu. Si un proxy reçoit un nom de domaine pleinement qualifié, le proxy ne doit pas (MUST NOT) modifier le nom d'hôte.
3.2.3 URI Comparison (Comparaison d'URI)
Lors de la comparaison de deux URI pour déterminer s'ils correspondent, un client devrait (SHOULD) utiliser une comparaison octet par octet sensible à la casse de l'URI entier, avec les exceptions suivantes :
- Un port vide ou non fourni est équivalent au port par défaut pour cette référence URI ;
- Les comparaisons de noms d'hôte doivent (MUST) être insensibles à la casse ;
- Les comparaisons de noms de schéma doivent (MUST) être insensibles à la casse ;
- Un abs_path vide est équivalent à un abs_path de "/".
Les caractères autres que ceux des ensembles "reserved" et "unsafe" (voir RFC 2396 [42]) sont équivalents à leur encodage "%HEX HEX".
Par exemple, les trois URI suivants sont équivalents :
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
3.3 Date/Time Formats (Formats de Date/Heure)
3.3.1 Full Date (Date Complète)
Les applications HTTP ont historiquement permis trois formats différents de représentation de date/heure :
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
Le premier format est préféré comme norme Internet et représente un sous-ensemble de longueur fixe de celui défini par RFC 1123 [8] (une mise à jour de RFC 822 [9]). Le deuxième format est d'usage courant, mais est basé sur le format de date obsolète RFC 850 [12] et manque d'une année à quatre chiffres. Les clients et serveurs HTTP/1.1 qui analysent la valeur de date doivent (MUST) accepter les trois formats (pour la compatibilité avec HTTP/1.0), mais ils doivent (MUST) générer uniquement le format RFC 1123 pour représenter les valeurs HTTP-date dans les champs d'en-tête. Voir la section 19.3 pour plus d'informations.
Note : Les destinataires de valeurs de date sont encouragés à être robustes en acceptant des valeurs de date qui peuvent avoir été envoyées par des applications non HTTP, ce qui peut se produire parfois lors de la récupération ou de la publication de messages via des proxies/passerelles vers SMTP ou NNTP.
Tous les horodatages de date/heure HTTP doivent (MUST) être représentés en temps moyen de Greenwich (Greenwich Mean Time, GMT), sans exception. Pour HTTP, GMT est exactement égal à UTC (Temps Universel Coordonné). Ceci est indiqué dans les deux premiers formats en incluant "GMT" comme abréviation de trois lettres pour le fuseau horaire, et doit (MUST) être supposé lors de la lecture du format asctime. HTTP-date est sensible à la casse et ne doit pas (MUST NOT) inclure de LWS supplémentaire au-delà de ce qui est explicitement inclus comme SP dans la grammaire.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Note : Les exigences HTTP pour les formats de date/horodatage s'appliquent uniquement à leur utilisation dans le flux de protocole. Les clients et les serveurs ne sont pas tenus d'utiliser ces formats pour la présentation utilisateur, les journaux de requête, etc.
3.3.2 Delta Seconds (Secondes Delta)
Certains champs d'en-tête HTTP permettent de spécifier une valeur de temps sous forme d'un entier de secondes, représenté en décimal, après le moment de réception du message.
delta-seconds = 1*DIGIT
3.4 Character Sets (Jeux de Caractères)
HTTP utilise la même définition du terme "jeu de caractères" (character set) que celle décrite dans MIME :
Le terme "jeu de caractères" est utilisé dans ce document pour désigner une méthode utilisée avec une ou plusieurs tables pour convertir une séquence d'octets en une séquence de caractères. Notez qu'une conversion inconditionnelle dans l'autre sens n'est pas requise, car tous les caractères ne sont pas nécessairement disponibles dans un jeu de caractères donné et qu'un jeu de caractères peut fournir plusieurs séquences d'octets pour représenter un caractère particulier. Cette définition est destinée à permettre divers encodages de caractères, des mappages de table unique simples tels que US-ASCII aux méthodes complexes de changement de table telles que celles qui utilisent les techniques ISO-2022. Cependant, la définition associée à un nom de jeu de caractères MIME doit (MUST) spécifier complètement le mappage à effectuer des octets aux caractères. En particulier, l'utilisation d'informations de profil externes pour déterminer le mappage exact n'est pas autorisée.
Note : Cette utilisation du terme "jeu de caractères" (character set) est plus communément appelée "encodage de caractères" (character encoding). Cependant, puisque HTTP et MIME partagent le même registre, il est important que les termes soient également partagés.
Les jeux de caractères HTTP sont identifiés par des jetons (tokens) insensibles à la casse. L'ensemble complet des jetons est défini par le registre de jeux de caractères IANA [19].
charset = token
Bien que HTTP permette l'utilisation d'un jeton arbitraire comme valeur de jeu de caractères, tout jeton qui a une valeur prédéfinie dans le registre de jeux de caractères IANA [19] doit (MUST) représenter le jeu de caractères défini par ce registre. Les applications devraient (SHOULD) limiter leur utilisation des jeux de caractères à ceux définis par le registre IANA.
Les implémenteurs doivent être conscients des exigences IETF concernant les jeux de caractères [38] [41].
3.4.1 Missing Charset (Jeu de Caractères Manquant)
Certains logiciels HTTP/1.0 ont interprété à tort un en-tête Content-Type sans paramètre charset comme signifiant "le destinataire devrait deviner". Les expéditeurs souhaitant vaincre ce comportement peuvent (MAY) inclure un paramètre charset lorsque le jeu de caractères est ISO-8859-1 et devraient (SHOULD) le faire s'il est connu que cela ne confondra pas le destinataire.
Malheureusement, certains clients HTTP/1.0 plus anciens n'ont pas traité correctement un paramètre charset explicite. Les destinataires HTTP/1.1 doivent (MUST) respecter l'étiquette de jeu de caractères fournie par l'expéditeur ; les agents utilisateurs qui ont une disposition à "deviner" le jeu de caractères doivent (MUST) utiliser le jeu de caractères du champ de type de contenu plutôt que le jeu de caractères déduit par le destinataire, même si l'expéditeur est un client HTTP/1.0.
3.5 Content Codings (Encodages de Contenu)
Les valeurs d'encodage de contenu indiquent une transformation d'encodage qui a été ou peut être appliquée à une entité. Les encodages de contenu sont principalement utilisés pour permettre la compression d'un document sans perdre l'identité de son type de média sous-jacent et sans perdre d'informations. Les entités ne sont stockées sous forme encodée que lorsque leur représentation sous-jacente est encodée pour la transmission.
content-coding = token
Toutes les valeurs d'encodage de contenu sont insensibles à la casse. HTTP/1.1 utilise les valeurs d'encodage de contenu dans les champs d'en-tête Accept-Encoding et Content-Encoding. Bien que la valeur décrive l'encodage de contenu appliqué au corps d'entité, ce qui est plus important, c'est qu'elle indique quel mécanisme de décodage peut être appliqué pour obtenir le type de média référencé par le champ d'en-tête Content-Type.
L'Internet Assigned Numbers Authority (IANA) sert de registre pour les jetons de valeur d'encodage de contenu. Initialement, le registre contient les jetons suivants :
gzip Un format d'encodage utilisant l'encodage Lempel-Ziv (LZ77) avec un CRC 32 bits, tel que décrit dans RFC 1952 [25]. Ce format d'encodage est produit par le programme gzip UNIX. Les implémenteurs HTTP/1.1 sont informés que, pour des raisons historiques, certains destinataires traitent "x-gzip" et "gzip" comme équivalents.
compress Le format d'encodage produit en utilisant l'algorithme Lempel-Ziv-Welch (LZW). Ce format d'encodage est produit par le programme commun de compression de fichiers UNIX "compress". Les destinataires devraient traiter "x-compress" et "compress" comme équivalents pour des raisons historiques.
deflate La combinaison du format "zlib" décrit dans RFC 1950 [31] et du mécanisme de compression "deflate" décrit dans RFC 1951 [29].
identity L'encodage par défaut (identité) ; l'utilisation de cet encodage de contenu indique uniquement qu'aucun encodage n'a été effectué. Cet encodage de contenu est utilisé dans le champ d'en-tête Accept-Encoding et ne devrait pas (SHOULD NOT) être utilisé dans le champ d'en-tête Content-Encoding.
Les nouveaux jetons d'encodage de contenu devraient être enregistrés auprès de l'Internet Assigned Numbers Authority (IANA).
3.6 Transfer Codings (Encodages de Transfert)
Les valeurs d'encodage de transfert sont utilisées pour indiquer une transformation d'encodage qui a été, peut être ou peut avoir besoin d'être appliquée au corps d'entité afin d'assurer un "transfert sûr" à travers le réseau. Ceci diffère d'un encodage de contenu en ce que l'encodage de transfert est une propriété du message, plutôt que de l'entité d'origine.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
Les paramètres prennent la forme de paires attribut/valeur.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
Toutes les valeurs d'encodage de transfert sont insensibles à la casse. HTTP/1.1 utilise les valeurs d'encodage de transfert dans le champ d'en-tête TE (section 14.39) et le champ d'en-tête Transfer-Encoding (section 14.41).
Les encodages de transfert sont une nouvelle fonctionnalité de HTTP/1.1. Les expéditeurs ne doivent pas (MUST NOT) appliquer un encodage de transfert au corps d'un message à moins que le message ne soit indiqué comme HTTP/1.1 ou supérieur.
3.6.1 Chunked Transfer Coding (Encodage de Transfert par Morceaux)
L'encodage par morceaux modifie le corps du message pour le transférer sous forme d'une série de morceaux, chacun avec son propre indicateur de taille, suivi d'un en-queue (trailer) optionnel contenant des champs d'en-tête d'entité. Cela permet au contenu généré dynamiquement d'être transféré avec les informations de vérification d'intégrité nécessaires sur le message.
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
Le champ chunk-size est une chaîne de chiffres hexadécimaux indiquant la taille des données de morceau. L'encodage par morceaux se termine par un morceau de taille zéro, suivi de l'en-queue, qui se termine par une ligne vide.
L'en-queue permet à l'expéditeur d'inclure des champs d'en-tête HTTP supplémentaires à la fin du message. Le champ d'en-tête Trailer (section 14.40) peut être utilisé pour indiquer quels champs d'en-tête sont inclus dans l'en-queue.
Il n'est pas permis d'inclure des champs d'en-tête de message dans l'en-queue à moins qu'ils ne soient explicitement autorisés, comme décrit dans la section 7.1.
Un serveur peut (MAY) utiliser l'encodage de transfert par morceaux si les encodages de transfert acceptables du destinataire incluent l'encodage de transfert par morceaux. La présence de l'en-queue peut être indiquée en incluant un champ d'en-tête Trailer dans le message.
Une application qui reçoit un corps de message par morceaux doit (MUST) ignorer les extensions de morceau qu'elle ne comprend pas, sauf si l'extension de morceau correspondante est définie par un champ d'en-tête Trailer.
3.7 Media Types (Types de Médias)
HTTP utilise les types de médias Internet [17] dans les champs d'en-tête Content-Type (section 14.17) et Accept (section 14.1) afin de fournir un typage de données ouvert et extensible et une négociation de type concernant les types de données.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Les types, sous-types et noms d'attributs de paramètres sont insensibles à la casse. Les valeurs des paramètres peuvent être sensibles ou insensibles à la casse, selon la sémantique du nom du paramètre. L'espace blanc linéaire (LWS) ne doit pas (MUST NOT) être utilisé entre le type et le sous-type, ni entre un attribut et sa valeur. Les agents utilisateurs devraient (SHOULD) respecter l'étiquette de jeu de caractères identifiée par les paramètres de type de média (section 3.4).
La présence d'une valeur de type de média n'implique pas qu'un corps d'entité doit être présent dans le message HTTP. Pour certaines méthodes ou réponses de certains codes de réponse, un message de réponse peut inclure un champ d'en-tête Content-Type même si le message n'inclut pas de corps d'entité. Ces messages de réponse commencent par une ligne vide qui termine les champs d'en-tête plutôt qu'un corps d'entité.
3.7.1 Canonicalization and Text Defaults (Canonisation et Valeurs par Défaut du Texte)
Les types de médias Internet enregistrés avec le type principal "text" standard adoptent les mêmes règles que dans MIME. Cela signifie que si le paramètre "charset" n'est pas inclus dans le champ d'en-tête Content-Type d'un type de média avec un type principal "text", le destinataire devrait (SHOULD) le traiter comme ayant un jeu de caractères "ISO-8859-1" (voir section 3.4.1). Les données d'un flux d'octets "text" dans HTTP sont envoyées en "forme canonique" (canonical form) ; c'est-à-dire que HTTP n'effectue aucune traduction sur les séquences de fin de ligne CRLF.
3.7.2 Multipart Types (Types Multipartites)
MIME fournit un certain nombre de types multipartites - encapsulant une ou plusieurs entités dans un seul corps de message. Tous les types multipartites partagent une syntaxe commune, telle que définie dans la section 5.1 de MIME [7], et doivent (MUST) inclure un paramètre de frontière comme partie de la valeur du type de média. Le corps du message lui-même est un élément de protocole et doit donc (MUST) utiliser CRLF comme séparateur de ligne entre deux parties du corps. Contrairement à MIME, la fin d'un corps multipartite dans HTTP doit (MUST) être marquée par un délimiteur de frontière de fin.
Dans HTTP, les mêmes sémantiques devraient (SHOULD) être suivies pour l'en-tête Content-Location pour les types multipartites comme dans MIME ; cependant, dans HTTP, toute partie du corps ayant un en-tête Content-Location est traitée comme ayant une identité indépendante, même si elle correspond au Content-Location externe de son message contenant.
En général, HTTP traite les parties du corps multipartie comme des ressources séparées, chacune avec son propre URI. Cela permet d'envoyer plusieurs ressources en parallèle ou séquentiellement dans un seul message, et prend en charge les réponses 206 (Partial Content).
3.8 Product Tokens (Jetons de Produit)
Les jetons de produit sont utilisés pour permettre aux applications communicantes de s'identifier par nom et version de logiciel. La plupart des champs qui utilisent des jetons de produit permettent également de lister des sous-produits qui forment une partie significative de l'application, séparés par des espaces. Par convention, les produits sont listés par ordre d'importance décroissante dans l'application.
product = token ["/" product-version]
product-version = token
Exemples :
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Les jetons de produit devraient (SHOULD) être courts et sans importance. Ils ne doivent pas (MUST NOT) être utilisés pour la publicité ou d'autres informations non essentielles. Bien que n'importe quel caractère de jeton puisse apparaître dans une version de produit, ce jeton devrait (SHOULD) être utilisé uniquement pour une version du produit (c'est-à-dire que les versions successives ne devraient différer que dans la valeur du jeton de version de produit).
3.9 Quality Values (Valeurs de Qualité)
La négociation de contenu HTTP (section 12) utilise des nombres "flottants" courts pour indiquer l'importance relative ("poids") de divers paramètres négociables. Les poids sont normalisés à des valeurs réelles entre 0 et 1, où 0 est la valeur minimale et 1 la maximale. Les applications HTTP/1.1 ne doivent pas (MUST NOT) générer de valeurs de qualité avec plus de trois décimales. La configuration utilisateur de ces valeurs devrait être limitée de manière similaire.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
Le concept de "valeur de qualité" s'applique à la sélection de tout contenu (voir section 14.1), jeu de caractères (section 14.2), encodage de contenu (section 14.3), langue (section 14.4) ou encodage de transfert (section 14.39). Cependant, pour des raisons de concision, le terme "valeur de qualité" utilisé dans cette section fait référence à l'une de ces caractéristiques associées à cette valeur de qualité.
3.10 Language Tags (Étiquettes de Langue)
Une étiquette de langue identifie une langue naturelle, telle que l'anglais ou le français, composée d'une ou plusieurs parties : une étiquette de langue principale et éventuellement une série de sous-étiquettes :
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Les espaces ne sont pas autorisés dans l'étiquette et toutes les étiquettes sont insensibles à la casse. L'espace de noms des étiquettes est géré par IANA. Les exemples d'étiquettes incluent :
en, en-US, en-cockney, i-cherokee, x-pig-latin
où toute étiquette principale à deux caractères est une abréviation de langue ISO-639 [34] et toute sous-étiquette initiale à deux caractères est un code de pays ISO-3166 [35]. (La dernière version hors ligne d'ISO 639 au moment de la rédaction de ce document est [35], mais on devrait s'attendre à ce que cette norme continue d'évoluer au fil du temps.)
3.11 Entity Tags (Étiquettes d'Entité)
Les étiquettes d'entité sont utilisées pour la comparaison entre plusieurs représentations de la même ressource demandée. Les étiquettes d'entité se composent d'une chaîne entre guillemets opaque, éventuellement préfixée par un indicateur de faiblesse (voir section 13.3.3).
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
Une "étiquette d'entité forte" (strong entity tag) peut être utilisée à tout moment où une étiquette d'entité est utilisée, quelles que soient les modifications de la valeur de l'entité. Une "étiquette d'entité faible" (weak entity tag) est utilisée uniquement pour une comparaison faible lorsque l'équivalence sémantique de la valeur de l'entité, plutôt que l'équivalence d'octets, est suffisante.
Une étiquette d'entité faible ne peut être utilisée que pour une comparaison faible. Une étiquette d'entité sans préfixe d'indicateur de faiblesse est une étiquette d'entité forte.
Les étiquettes d'entité doivent (MUST) être uniques pour deux entités d'une ressource particulière, à moins que la sémantique de ces entités ne soit équivalente.
3.12 Range Units (Unités de Plage)
HTTP/1.1 permet à un client de demander que seule une partie (plage) de l'entité de réponse soit transférée. HTTP/1.1 utilise les unités de plage dans les champs d'en-tête Range (section 14.35), Content-Range (section 14.16) et Accept-Ranges (section 14.5). Une entité peut être décomposée en sous-plages selon différentes unités structurelles.
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
La seule unité de plage dans HTTP/1.1 est "bytes". Les implémentations HTTP/1.1 peuvent (MAY) ignorer les spécifications d'unités de plage qu'elles ne comprennent pas.
HTTP/1.1 a été enregistré pour l'unité de plage "bytes". L'annexe inclut l'enregistrement de certaines autres unités de plage.