Aller au contenu principal

Hypertext Transfer Protocol (HTTP/1.1) : Syntaxe et Routage des Messages

  • Statut: Proposed Standard
  • Publié: June 2014
  • Stream: IETF
  • Met à jour: RFC2817, RFC2818
  • Remplace: RFC2145, RFC2616
  • Remplacé par: RFC9110, RFC9112
  • Errata: Pas d'errata

Informations sur le document​

  • Numéro RFC : 7230
  • Titre : HTTP/1.1: Message Syntax and Routing
  • Publié : juin 2014
  • Auteurs : R. Fielding (Adobe), J. Reschke (greenbytes)
  • Statut : Standards Track
  • Rend obsolète : RFC 2616, RFC 2145
  • Met à jour : RFC 2817, RFC 2818

Résumé​

Le protocole de transfert hypertexte (HTTP, Hypertext Transfer Protocol) est un protocole de couche application sans état pour les systèmes d'information hypertexte distribués et collaboratifs.

Ce document fournit une vue d'ensemble de l'architecture HTTP et de sa terminologie associée, définit les schémas URI (Uniform Resource Identifier, identifiant de ressource uniforme) « http » et « https », définit la syntaxe des messages HTTP/1.1 et les exigences d'analyse, et décrit les préoccupations de sécurité associées pour les implémentations.

Table des matières​

Sections principales​

  1. Introduction

    • 1.1 Notation des exigences
    • 1.2 Notation syntaxique

  2. Architecture

    • 2.1 Messagerie client/serveur
    • 2.2 Diversité des implémentations
    • 2.3 Intermédiaires
    • 2.4 Caches
    • 2.5 Conformité et gestion des erreurs
    • 2.6 Versionnage du protocole
    • 2.7 Identifiants de ressources uniformes

  3. Format des messages

    • 3.1 Ligne de départ
    • 3.2 Champs d'en-tête
    • 3.3 Corps du message

  4. Codages de transfert

    • 4.1 Codage de transfert par morceaux (chunked)
    • 4.2 Codages de compression
    • 4.3 Champ d'en-tête TE
    • 4.4 Champ d'en-tête Trailer

  5. Routage des messages

    • 5.1 Identification d'une ressource cible
    • 5.2 Connexion entrante
    • 5.3 Cible de la requête
    • 5.4 Champ d'en-tête Host
    • 5.5 URI de requête effectif
    • 5.6 Association d'une réponse à une requête
    • 5.7 Transfert de messages

  6. Gestion des connexions

    • 6.1 Champ d'en-tête Connection
    • 6.2 Établissement
    • 6.3 Persistance
    • 6.4 Concurrence
    • 6.5 Échecs et délais d'attente
    • 6.6 Fermeture
    • 6.7 Champ d'en-tête Upgrade

  7. Extension de liste ABNF

  8. Considérations IANA

  9. Considérations de sécurité

Annexes​

  • Annexe A - Historique des versions HTTP
  • Annexe B - ABNF collecté
  • Références

Série de spécifications HTTP/1.1​

Le RFC 7230 est la première partie de la série de spécifications HTTP/1.1 :

  1. RFC 7230 - Syntaxe et routage des messages (ce document)
  2. RFC 7231 - Sémantique et contenu
  3. RFC 7232 - Requêtes conditionnelles
  4. RFC 7233 - Requêtes de plage
  5. RFC 7234 - Mise en cache
  6. RFC 7235 - Authentification

Concepts fondamentaux​

Termes clés​

  • Client : programme qui établit une connexion pour envoyer des requêtes HTTP
  • Serveur : programme qui accepte les connexions pour traiter les requêtes HTTP
  • Agent utilisateur (User Agent) : programme client qui initie les requêtes (navigateurs, robots d'exploration, etc.)
  • Serveur d'origine (Origin Server) : programme pouvant générer des réponses faisant autorité
  • Intermédiaire (Intermediary) : proxy, passerelle ou tunnel
  • Cache : stockage local des réponses précédentes

Structure des messages HTTP​

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

Exemple de requête​

GET /hello.txt HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept-Language: fr

Exemple de réponse​

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Content-Length: 51
Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

Caractéristiques importantes​

  1. Protocole sans état — chaque requête est traitée indépendamment
  2. Connexions persistantes — HTTP/1.1 utilise des connexions persistantes par défaut
  3. Codage de transfert par morceaux (Chunked Transfer Encoding) — permet d'envoyer des données sans connaître la longueur totale
  4. Prise en charge des intermédiaires — prend en charge les proxies, passerelles et tunnels
  5. Mise à niveau du protocole — prend en charge la mise à niveau vers d'autres protocoles (par exemple, WebSocket)

Considérations de sécurité​

  1. Validation des entrées — toujours valider et assainir les entrées utilisateur
  2. Limites de longueur — mettre en œuvre des limites sur la ligne de requête et les longueurs des champs d'en-tête
  3. Utiliser HTTPS — utiliser le chiffrement TLS pour les communications sensibles
  4. Prévenir le contrebande de requêtes (Request Smuggling) — suivre strictement les règles d'analyse des messages
  5. Sécurité des intermédiaires — gérer soigneusement les proxies et passerelles
  6. Protection de la vie privée — protéger les informations personnelles dans les journaux du serveur

Avis de droits d'auteur​

Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

Ce document est soumis au BCP 78 et aux dispositions légales de l'IETF Trust.

1. Introduction​

Le Hypertext Transfer Protocol (HTTP, Protocole de Transfert Hypertexte) est un protocole requête/réponse sans état qui fonctionne en échangeant des messages via une connexion de transport ou de couche session fiable. Ce document est la première partie d'une série de documents définissant HTTP/1.1.

Le contenu principal de ce document comprend :

  • Une vue d'ensemble de l'architecture HTTP et de sa terminologie associée
  • La définition des schémas "http" et "https" des Uniform Resource Identifier (URI, Identificateur de Ressource Uniforme)
  • Les exigences de syntaxe et d'analyse des messages HTTP/1.1
  • Les considérations de sécurité liées à l'implémentation

Les exigences de syntaxe et d'analyse des messages HTTP/1.1 ont été révisées par rapport à RFC 2616 pour améliorer l'interopérabilité et réduire les ambiguïtés connues. Ce document remplace certaines parties de RFC 2616 et est utilisé conjointement avec d'autres documents définissant la sémantique HTTP/1.1.

Les autres parties de HTTP sont définies dans les documents indépendants suivants :

  1. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content" [RFC7231] - définit les méthodes de requête, les codes d'état et d'autres éléments liés à la sémantique du protocole
  2. "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests" [RFC7232] - définit les mécanismes de requêtes conditionnelles
  3. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests" [RFC7233] - définit les requêtes et réponses partielles
  4. "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234] - définit les exigences et le contrôle de mise en cache
  5. "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235] - définit le cadre d'authentification des utilisateurs

1.1. Requirements Notation (Notation des Exigences)​

Les mots-clés "DOIT", "NE DOIT PAS", "REQUIS", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "OPTIONNEL" dans ce document doivent être interprétés comme décrit dans [RFC2119].

Les critères de conformité et les considérations sont décrits dans Section 2.5.

1.2. Syntax Notation (Notation Syntaxique)​

Cette spécification utilise la notation Augmented Backus-Naur Form (ABNF, Forme de Backus-Naur Augmentée) de [RFC5234] avec une extension de liste, définie dans Section 7, qui permet la définition compacte de listes séparées par des virgules en utilisant un opérateur #.

Les règles de base suivantes sont incluses par référence, telles que définies dans [RFC5234], Annexe B.1 : ALPHA (lettres), CR (retour chariot), CRLF (CR LF), CTL (contrôles), DIGIT (décimal 0-9), DQUOTE (guillemet double), HEXDIG (hexadécimal 0-9/A-F/a-f), HTAB (tabulation horizontale), LF (saut de ligne), OCTET (séquence de 8 bits de données), SP (espace) et VCHAR (caractère US-ASCII visible).

Par convention, les noms de règles ABNF préfixés par "obs-" désignent des règles de grammaire "obsolètes" qui apparaissent pour des raisons historiques.

2. Architecture (Architecture)​

HTTP a été conçu pour être un protocole de communication de niveau application sans état, qui peut être utilisé pour de nombreuses tâches au-delà de son utilisation pour l'hypertexte, telles que les serveurs de noms et les systèmes de gestion d'objets distribués, grâce à l'extension de ses méthodes de requête, codes d'erreur et en-têtes.

2.1. Client/Server Messaging (Messagerie Client/Serveur)​

HTTP est un protocole de requête/réponse sans état. Un client envoie une requête sous la forme d'un message de requête à un serveur. Le serveur répond avec un message de réponse.

La terminologie de "client" et "serveur" fait référence uniquement aux rôles que ces programmes assument pour une connexion particulière. Le même programme peut agir en tant que client sur certaines connexions et serveur sur d'autres.

2.2. Implementation Diversity (Diversité d'Implémentation)​

HTTP est conçu pour masquer les détails d'implémentation de ses participants. Par conséquent, HTTP peut être utilisé avec de nombreux protocoles de transport de couche inférieure différents.

2.3. Intermediaries (Intermédiaires)​

Les intermédiaires HTTP sont des composants qui se trouvent entre le client et le serveur et qui agissent comme des agents de transfert de messages.

Il existe trois types courants d'intermédiaires HTTP:

Proxy (Proxy)​

Un proxy est un agent de transfert de messages sélectionné par le client, généralement via la configuration locale, pour recevoir des requêtes pour certains types d'URI absolus et tenter de satisfaire ces requêtes via la traduction, si nécessaire.

Gateway (Passerelle)​

Une passerelle (également connue sous le nom de proxy inverse) est un agent de transfert de messages qui agit comme un serveur d'origine pour la requête entrante, mais qui traduit les requêtes reçues et les transmet en amont vers un autre serveur (ou serveurs).

Tunnel (Tunnel)​

Un tunnel agit comme un relais entre deux connexions sans changer les messages. Un tunnel cesse d'exister lorsque les deux extrémités de la connexion relayée sont fermées.

2.4. Caches (Caches)​

Un cache est un stockage local de messages de réponse et le sous-système qui contrôle leur stockage, récupération et suppression. Un cache stocke les réponses aux requêtes pour réduire le temps de réponse et la consommation de bande passante réseau lors des requêtes futures équivalentes.

2.5. Conformance and Error Handling (Conformité et Gestion des Erreurs)​

Le mot-clé "MUST" (DOIT), ou les termes "REQUIRED" (REQUIS) ou "SHALL" (DOIT), signifient qu'une définition est une exigence absolue de la spécification.

Le mot-clé "MUST NOT" (NE DOIT PAS), ou l'expression "SHALL NOT" (NE DOIT PAS), signifient qu'une définition est une interdiction absolue de la spécification.

Le mot-clé "SHOULD" (DEVRAIT), ou l'adjectif "RECOMMENDED" (RECOMMANDÉ), signifient qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent.

Le mot-clé "SHOULD NOT" (NE DEVRAIT PAS), ou l'expression "NOT RECOMMENDED" (NON RECOMMANDÉ), signifient que des raisons valables dans des circonstances particulières peuvent exister lorsque le comportement particulier est acceptable ou même utile.

Le mot-clé "MAY" (PEUT), ou l'adjectif "OPTIONAL" (FACULTATIF), signifient qu'un élément est véritablement facultatif.

2.6. Protocol Versioning (Versionnage du Protocole)​

HTTP utilise un schéma de numérotation de version "<major>.<minor>" pour indiquer les versions du protocole. Ce document définit HTTP/1.1.

2.7. Uniform Resource Identifiers (Identifiants de Ressources Uniformes)​

Les Uniform Resource Identifiers (URI) [RFC3986] sont utilisés dans HTTP pour identifier les ressources. Les références URI sont utilisées pour cibler les requêtes, indiquer les redirections et définir les relations.

URI-reference = <URI-reference, voir [RFC3986], Section 4.1>
absolute-URI  = <absolute-URI, voir [RFC3986], Section 4.3>
relative-part = <relative-part, voir [RFC3986], Section 4.2>
authority     = <authority, voir [RFC3986], Section 3.2>
uri-host      = <host, voir [RFC3986], Section 3.2.2>
port          = <port, voir [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, voir [RFC3986], Section 3.3>
segment       = <segment, voir [RFC3986], Section 3.3>
query         = <query, voir [RFC3986], Section 3.4>

2.7.1. http URI Scheme (Schéma URI http)​

Le schéma "http" est utilisé pour localiser les ressources réseau via le protocole HTTP.

http-URI = "http://" authority path-abempty [ "?" query ]
           [ "#" fragment ]

2.7.2. https URI Scheme (Schéma URI https)​

Le schéma "https" est utilisé pour localiser les ressources réseau via le protocole HTTP sur une connexion sécurisée.

https-URI = "https://" authority path-abempty [ "?" query ]
            [ "#" fragment ]

2.7.3. http and https URI Normalization and Comparison (Normalisation et Comparaison des URI http et https)​

Les URI HTTP et HTTPS sont comparés de la même manière que tous les autres URI.

3. Message Format (Format des Messages)​

Tous les messages HTTP se composent d'une ligne de départ, suivie d'une séquence d'octets de syntaxe similaire à l'Internet Message Format [RFC5322]: zéro ou plusieurs champs d'en-tête (collectivement appelés "en-têtes" ou "section d'en-tête"), une ligne vide indiquant la fin de la section d'en-tête, et un corps de message optionnel.

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

3.1. Start Line (Ligne de Départ)​

Un message HTTP commence par une ligne de départ (start-line).

start-line     = request-line / status-line

3.1.1. Request Line (Ligne de Requête)​

Une ligne de requête (request-line) commence par un jeton de méthode, suivi d'une cible de requête, d'une version de protocole et se termine par CRLF.

request-line   = method SP request-target SP HTTP-version CRLF
method         = token

3.1.2. Status Line (Ligne de Statut)​

La première ligne d'un message de réponse est la ligne de statut (status-line), composée de la version du protocole, d'un espace, d'un code de statut, d'un autre espace, d'une phrase de raison éventuellement vide, et se terminant par CRLF.

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

3.2. Header Fields (Champs d'En-tête)​

Chaque champ d'en-tête se compose d'un nom de champ insensible à la casse suivi d'un deux-points (":"), d'un espace blanc facultatif, de la valeur du champ et d'un espace blanc facultatif.

header-field   = field-name ":" OWS field-value OWS
field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text
obs-fold       = CRLF 1*( SP / HTAB )

3.2.1. Field Extensibility (Extensibilité des Champs)​

Les champs d'en-tête sont entièrement extensibles: il n'y a pas de limite au nombre de champs d'en-tête pouvant être utilisés dans un message.

3.2.2. Field Order (Ordre des Champs)​

L'ordre dans lequel les champs d'en-tête avec des noms de champs différents sont reçus n'est pas significatif.

3.2.3. Whitespace (Espaces Blancs)​

L'espace blanc facultatif (OWS) est utilisé uniquement pour améliorer la lisibilité.

OWS            = *( SP / HTAB )
RWS            = 1*( SP / HTAB )
BWS            = OWS

3.2.4. Field Parsing (Analyse des Champs)​

Les messages sont analysés en utilisant une approche générique indépendante des noms de champs individuels.

3.2.5. Field Limits (Limites de Champs)​

Les implémentations HTTP ne placent pas de limites prédéfinies sur la longueur de chaque champ d'en-tête ou sur la longueur de la section d'en-tête dans son ensemble.

3.2.6. Field Value Components (Composants de Valeur de Champ)​

La plupart des valeurs de champ d'en-tête HTTP sont définies en utilisant une grammaire commune de types de valeurs de champ.

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0"-"9" / "A"-"Z" / "^" / "_"
               / "`" / "a"-"z" / "|" / "~"
quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / "!" / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
comment        = "(" *( ctext / quoted-pair / comment ) ")"
ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

3.3. Message Body (Corps du Message)​

Le corps du message (message-body, si présent) d'un message HTTP est utilisé pour transporter la charge utile (payload) du message.

message-body = *OCTET

3.3.1. Transfer-Encoding​

L'en-tête Transfer-Encoding énumère les noms de codage de transfert correspondant à la séquence de codages de transfert qui ont été (ou seront) appliqués à la charge utile afin de former le corps du message.

Transfer-Encoding = 1#transfer-coding

Un serveur DOIT générer un code de statut 400 (Bad Request, Mauvaise Requête) pour toute requête reçue qui contient à la fois un en-tête Content-Length et un Transfer-Encoding.

3.3.2. Content-Length​

L'en-tête Content-Length fournit la longueur anticipée du corps du message en octets.

Content-Length = 1*DIGIT

3.3.3. Message Body Length (Longueur du Corps du Message)​

La longueur d'un corps de message est déterminée par l'un des éléments suivants (dans l'ordre de priorité):

  1. Toute réponse à une requête HEAD et toute réponse avec un code de statut 1xx (Informational, Informatif), 204 (No Content, Pas de Contenu) ou 304 (Not Modified, Non Modifié) est toujours terminée par la première ligne vide après les champs d'en-tête.

  2. Si un en-tête Transfer-Encoding est présent et que la valeur du codage de transfert chunked est la valeur finale, alors le corps du message consiste en un ou plusieurs chunks.

  3. Si un en-tête Content-Length est présent, sa valeur décimale en octets représente à la fois la longueur de la charge utile et la longueur du corps du message.

  4. Si le message utilise le codage de transfert "multipart/byteranges" et que l'en-tête Content-Length n'est pas autrement spécifié, alors ce type de média auto-délimité définit la longueur du corps du message.

  5. Par fermeture de la connexion par le serveur.

3.4. Handling Incomplete Messages (Gestion des Messages Incomplets)​

Un serveur qui reçoit un message de requête incomplet, généralement en raison d'une connexion fermée prématurément, DOIT répondre avec un code de statut 400 (Bad Request, Mauvaise Requête).

3.5. Message Parsing Robustness (Robustesse de l'Analyse des Messages)​

Bien que les exigences de ce document soient exprimées en termes de conformité stricte, les implémentations sont encouragées à être tolérantes lors de l'analyse.

4. Transfer Codings (Codages de Transfert)​

Les noms de codage de transfert (Transfer coding) sont utilisés pour indiquer les transformations de codage qui ont été, peuvent être ou doivent être appliquées au corps de charge utile afin d'assurer un "transfert sûr" sur le réseau.

transfer-coding    = "chunked"
                   / "compress"
                   / "deflate"
                   / "gzip"
                   / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

4.1. Chunked Transfer Coding (Codage de Transfert par Chunks)​

Le codage de transfert par chunks (chunked transfer coding) enveloppe le corps de charge utile dans une série de chunks, chacun avec son propre indicateur de taille, suivi d'une section de trailer optionnelle contenant des champs de trailer.

chunked-body   = *chunk
                 last-chunk
                 trailer-part
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF
chunk-data     = 1*OCTET

Le champ chunk-size (taille de chunk) est une chaîne de chiffres hexadécimaux indiquant la taille des données de chunk (en octets).

Un destinataire DOIT être capable d'analyser et de décoder le codage de transfert par chunks.

4.1.1. Chunk Extensions (Extensions de Chunk)​

Le codage de transfert par chunks permet d'inclure zéro ou plusieurs extensions de chunk (chunk extensions) dans chaque chunk.

chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token / quoted-string

4.1.2. Chunked Trailer Part (Partie Trailer du Chunk)​

Un trailer (remorque) permet à l'expéditeur d'inclure des champs d'en-tête supplémentaires à la fin d'un message par chunks afin de fournir des métadonnées qui pourraient être générées dynamiquement lors de l'envoi du corps du message.

trailer-part   = *( header-field CRLF )

Un expéditeur NE DOIT PAS générer de champ Transfer-Encoding, Content-Length ou Trailer dans un trailer.

4.1.3. Decoding Chunked (Décodage du Chunked)​

Le processus de décodage du codage de transfert par chunks peut être mis en œuvre comme suit (en utilisant du pseudo-code):

length := 0
read chunk-size, chunk-ext (if any), and CRLF
while (chunk-size > 0) {
   read chunk-data and CRLF
   append chunk-data to decoded-body
   length := length + chunk-size
   read chunk-size, chunk-ext (if any), and CRLF
}
read trailer field
while (trailer field is not empty) {
   if (trailer field is allowed to be sent in a trailer) {
      append trailer field to existing header fields
   }
   read trailer-field
}
Content-Length := length
Remove "chunked" from Transfer-Encoding

4.2. Compression Codings (Codages de Compression)​

Les trois noms de codage de compression suivants sont définis pour des raisons de compatibilité avec HTTP/1.0.

4.2.1. Compress Coding (Codage Compress)​

Le codage "compress" est un codage adaptatif Lempel-Ziv-Welch (LZW) [Welch] généralement produit par le programme de compression de fichiers UNIX "compress".

4.2.2. Deflate Coding (Codage Deflate)​

Le codage "deflate" est un format de données "zlib" [RFC1950] contenant un flux de données compressées "deflate" [RFC1951] qui utilise une combinaison de l'algorithme de compression Lempel-Ziv (LZ77) et du codage Huffman.

4.2.3. Gzip Coding (Codage Gzip)​

Le codage "gzip" est un codage LZ77 avec un contrôle de redondance cyclique (CRC) de 32 bits généralement produit par le programme de compression de fichiers gzip [RFC1952].

4.3. TE​

L'en-tête TE indique quels codages de transfert, autres que chunked, le client est prêt à accepter dans la réponse, et si le client est prêt à accepter des champs de trailer.

TE        = #t-codings
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
          / ( "1" [ "." 0*3("0") ] )

4.4. Trailer​

Si l'expéditeur sait quels champs d'en-tête seront envoyés dans la section de trailer du dernier chunk, alors l'expéditeur DEVRAIT envoyer un champ d'en-tête Trailer contenant une liste de ces noms de champs d'en-tête.

Trailer = 1#field-name

5. Message Routing (Routage des Messages)​

Le routage d'un message de requête HTTP est déterminé par le client sur la base de la ressource cible, de la configuration du proxy et de l'établissement ou de la réutilisation d'une connexion réseau.

5.1. Identifying a Target Resource (Identification d'une Ressource Cible)​

HTTP ne limite pas le nombre de ressources différentes pour lesquelles un seul serveur d'origine peut fournir des réponses faisant autorité, ni la portée de l'autorité d'une seule ressource, ni l'espace URI qu'une seule ressource peut référencer.

5.2. Connecting Inbound (Connexion Entrante)​

Une fois que le client a déterminé l'URI cible et le serveur d'origine ou proxy en examinant l'URI ou sa configuration, le client détermine où se connecter.

5.3. Request Target (Cible de Requête)​

Une fois qu'une connexion entrante vers la cible est établie, le client envoie un message de requête HTTP (Section 3) avec une start-line qui inclut une request-target (cible de requête) identifiant la ressource cible à laquelle la requête doit être appliquée.

request-target = origin-form
               / absolute-form
               / authority-form
               / asterisk-form

5.3.1. origin-form​

La forme de cible de requête la plus courante est "origin-form".

origin-form    = absolute-path [ "?" query ]

5.3.2. absolute-form​

Lors de l'envoi d'une requête à un proxy, à l'exception des requêtes CONNECT ou des requêtes OPTIONS à l'échelle du serveur (décrites ci-dessous), un client DOIT envoyer l'absolute-form de l'URI cible comme cible de requête.

absolute-form  = absolute-URI

5.3.3. authority-form​

La cible de requête authority-form est utilisée uniquement pour les requêtes CONNECT ([RFC7231], [Section 4.3.6]).

authority-form = authority

5.3.4. asterisk-form​

La cible de requête asterisk-form est utilisée uniquement pour les requêtes OPTIONS à l'échelle du serveur ([RFC7231], [Section 4.3.7]).

asterisk-form  = "*"

5.4. Host​

L'en-tête Host fournit les informations d'hôte et de port de l'URI cible dans une requête, permettant au serveur d'origine de distinguer les ressources servies sur une seule adresse IP.

Host = uri-host [ ":" port ]

Un client DOIT envoyer un champ d'en-tête Host dans tous les messages de requête HTTP/1.1.

5.5. Effective Request URI (URI de Requête Effectif)​

Si la cible de requête est sous forme absolute-form, alors l'effective request URI (URI de requête effectif) est la cible de requête.

5.6. Associating a Response to a Request (Association d'une Réponse à une Requête)​

HTTP ne comprend pas d'identificateur dans les réponses pour associer explicitement une réponse à une requête spécifique. Par conséquent, il s'appuie sur la connexion sous-jacente pour identifier quelle requête est associée à une réponse.

5.7. Message Forwarding (Transfert de Messages)​

Comme décrit dans la Section 2.3, les intermédiaires peuvent agir comme proxy d'un serveur sortant, comme passerelle agissant comme une représentation d'un serveur d'origine, ou comme tunnel agissant comme un relais de connexion.

5.7.1. Via​

L'en-tête Via indique la présence de protocoles et de destinataires intermédiaires entre le message de requête et le message de réponse.

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
received-by       = ( uri-host [ ":" port ] ) / pseudonym
pseudonym         = token

Chaque intermédiaire DOIT ajouter un champ d'en-tête Via avant de transférer le message.

5.7.2. Transformations (Transformations)​

Certains intermédiaires incluent des fonctionnalités de transformation de la charge utile ou de la sémantique des messages, qui peuvent être utiles pour certaines applications HTTP.

Un proxy NE DEVRAIT PAS modifier le contenu intentionnel (intent content) d'une requête, sauf si cela est explicitement demandé.

6. Connection Management (Gestion des Connexions)​

La transmission de messages HTTP est indépendante des protocoles de connexion de couche de transport ou de session sous-jacents. HTTP suppose uniquement un transport fiable pouvant fournir une livraison ordonnée des requêtes et des réponses.

6.1. Connection​

L'en-tête Connection permet à l'expéditeur de spécifier les options de contrôle souhaitées pour la connexion actuelle.

Connection        = 1#connection-option
connection-option = token

6.2. Establishment (Établissement)​

Le client est responsable de l'établissement d'une connexion au serveur. HTTP n'a pas d'exigence de tramage de messages pour établir ou identifier la connexion elle-même.

6.3. Persistence (Persistance)​

HTTP/1.1 utilise par défaut des "connexions persistantes" (persistent connections), permettant d'envoyer plusieurs requêtes et réponses sur une seule connexion. Les implémentations HTTP DEVRAIENT prendre en charge les connexions persistantes.

6.3.1. Retrying Requests (Nouvelle Tentative de Requêtes)​

Lors de la nouvelle tentative automatique d'une requête, la connexion peut échouer pendant la transmission du message de requête (ou pendant l'attente du message de réponse). Un client NE DEVRAIT PAS automatiquement réessayer une requête à moins qu'il puisse confirmer que la requête est idempotente ([RFC7231], [Section 4.2.2]) ou qu'il reçoive un message du serveur d'origine indiquant que le serveur n'a pas traité la requête avant l'échec de la connexion.

6.3.2. Pipelining (Pipeline)​

Un client qui prend en charge les connexions persistantes PEUT envoyer plusieurs requêtes en "pipeline" (c'est-à-dire, envoyer plusieurs requêtes sans attendre chaque réponse). Un serveur DOIT envoyer ses réponses à ces requêtes en pipeline dans le même ordre que les requêtes ont été reçues.

6.4. Concurrency (Concurrence)​

Un client DEVRAIT limiter le nombre de connexions simultanées qu'il établit vers un serveur.

6.5. Failures and Timeouts (Échecs et Délais d'Attente)​

Les serveurs ont généralement une valeur de délai d'attente après laquelle ils ne maintiendront plus une connexion inactive. Les serveurs proxy peuvent utiliser des valeurs de délai d'attente plus courtes pour préserver les ressources.

6.6. Tear-down (Fermeture)​

L'en-tête Connection (Section 6.1) fournit une option de connexion "close" que l'expéditeur utilise pour signaler que la connexion sera fermée après l'achèvement de la requête/réponse actuelle.

6.6.1. Retrying Requests (Nouvelle Tentative de Requêtes)​

Un client DEVRAIT réessayer une requête idempotente si la connexion est fermée après l'envoi de la requête (même si le client avait envoyé des requêtes précédemment sur cette connexion).

6.6.2. Closure (Clôture)​

Lorsqu'un serveur effectue une fermeture immédiate d'une connexion TCP, il existe un risque important que le client ne puisse pas lire la dernière réponse HTTP.

6.7. Upgrade (Mise à Niveau)​

L'en-tête Upgrade fournit un mécanisme simple pour passer de HTTP/1.1 à d'autres protocoles incompatibles.

Upgrade          = 1#protocol
protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Un serveur PEUT changer de protocole en envoyant une réponse 101 (Switching Protocols, Changement de Protocoles).

7. ABNF List Extension: #rule (Extension de Liste ABNF: #règle)​

Les règles de syntaxe définies dans la notation ABNF de [RFC5234] sont une structure commune pour les champs d'en-tête HTTP. Cette section définit la construction # utilisée pour définir des éléments de liste séparés par des virgules.

Une construction utilisant l'opérateur # fonctionne de la même manière que celle utilisant l'opérateur *, sauf qu'au moins un élément de liste est requis et que les éléments de liste sont séparés par une ou plusieurs virgules (",") et un espace blanc optionnel (OWS).

#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

Un expéditeur NE DEVRAIT PAS générer d'éléments de liste vides. Un expéditeur DOIT générer des listes avec au moins un élément non vide.

8. IANA Considerations (Considérations IANA)​

8.1. Header Field Registration (Enregistrement de Champs d'En-tête)​

Les champs d'en-tête HTTP sont enregistrés dans le registre "Message Headers" maintenu à http://www.iana.org/assignments/message-headers/.

Ce document définit les champs d'en-tête HTTP suivants, donc le registre "Permanent Message Header Field Names" a été mis à jour conformément à [RFC3864]:

Header Field NameProtocolStatusReference
ConnectionhttpstandardSection 6.1
Content-LengthhttpstandardSection 3.3.2
HosthttpstandardSection 5.4
TEhttpstandardSection 4.3
TrailerhttpstandardSection 4.4
Transfer-EncodinghttpstandardSection 3.3.1
UpgradehttpstandardSection 6.7
ViahttpstandardSection 5.7.1

8.2. URI Scheme Registration (Enregistrement de Schéma URI)​

L'IANA a mis à jour l'enregistrement des schémas URI "http" et "https" (définis à l'origine dans [RFC2617] et [RFC2818]) pour faire référence à cette spécification.

8.3. Internet Media Type application/http​

L'IANA a mis à jour l'enregistrement du type de média "application/http" (défini à l'origine dans [RFC2616]) pour faire référence à cette spécification.

8.4. Transfer Coding Registry (Registre de Codage de Transfert)​

Le registre des noms de codage de transfert est maintenu à http://www.iana.org/assignments/http-parameters/.

Ce document enregistre les codages de transfert suivants:

NameDescriptionReference
chunkedCodage de transfert par chunksSection 4.1
compressFormat de données UNIX "compress"Section 4.2.1
deflateFormat de données compressées "deflate"Section 4.2.2
gzipFormat de fichier GZIPSection 4.2.3

8.5. Content Coding Registry (Registre de Codage de Contenu)​

Le registre des noms de codage de contenu est maintenu à http://www.iana.org/assignments/http-parameters/.

8.6. Upgrade Token Registry (Registre de Jetons de Mise à Niveau)​

Le registre de jetons de mise à niveau HTTP définit l'espace de noms pour les noms utilisés dans l'en-tête Upgrade (Section 6.7).

9. Security Considerations (Considérations de Sécurité)​

Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des limitations de sécurité connues lors du déploiement de HTTP/1.1.

9.1. Establishing Authority (Établissement de l'Autorité)​

HTTP repose sur le concept de composant authority (autorité) d'un URI, qui inclut l'adresse IP ou le nom d'hôte d'un serveur d'origine et le numéro de port TCP.

Le besoin d'un mécanisme fiable pour établir l'autorité du serveur au sein de HTTP a conduit au développement de HTTPS (HTTP sur TLS), tel que défini dans [RFC2818].

9.2. Risks of Intermediaries (Risques des Intermédiaires)​

Par défaut, HTTP repose sur les attributs de sécurité du protocole de transport sous-jacent. En utilisant TLS, HTTP s'appuie sur TLS pour vérifier l'identité et fournir une protection de confidentialité et d'intégrité.

Cependant, TLS ne fournit une protection qu'au niveau de la couche transport. Les messages HTTP peuvent être lus ou modifiés par des intermédiaires qui ne sont pas des points d'extrémité sur le chemin de communication.

9.3. Attacks Based on File and Path Names (Attaques Basées sur les Noms de Fichiers et de Chemins)​

Les serveurs d'origine utilisent souvent une structure de répertoires de système de fichiers hiérarchique pour stocker les représentations de ressources et reflètent cette hiérarchie dans l'espace URI qu'ils servent.

Les implémentations doivent faire attention à la manière dont elles mappent les URI au système de fichiers.

9.4. Attacks Based on Command, Code, or Query Injection (Attaques Basées sur l'Injection de Commandes, de Code ou de Requêtes)​

Les serveurs d'origine utilisent fréquemment des paramètres fournis par le client (dans l'URI ou dans le corps du message), et ces paramètres sont parfois utilisés pour construire des requêtes, des commandes ou du code internes.

Les implémentations DOIVENT valider et assainir toutes les entrées.

9.5. Attacks via Protocol Element Length (Attaques via la Longueur des Éléments de Protocole)​

Étant donné que HTTP utilise des délimiteurs basés sur la longueur pour marquer les limites de divers éléments de protocole, y compris la ligne de requête, la ligne de statut, les champs d'en-tête et le corps du message, les implémentations doivent empêcher un attaquant de consommer des ressources excessives en envoyant des éléments de protocole excessivement grands.

9.5.1. Request Smuggling (Contrebande de Requêtes)​

Les attaques de contrebande de requêtes (request smuggling) exploitent les incohérences ou les ambiguïtés dans le tramage des messages HTTP.

Pour prévenir les attaques de contrebande de requêtes, les implémentations DOIVENT:

  • Respecter strictement les règles de tramage des messages, en particulier les règles de détermination de la longueur du corps du message définies dans la Section 3.3.3
  • Rejeter les messages contenant des informations de tramage incohérentes ou ambiguës

9.5.2. Response Splitting (Division de Réponse)​

Les attaques de division de réponse (response splitting) exploitent une vulnérabilité où une application ne valide pas correctement les entrées lors de la génération de réponses HTTP.

Les implémentations DOIVENT valider toutes les entrées.

9.6. Disclosure of Sensitive Information in URIs (Divulgation d'Informations Sensibles dans les URI)​

Les URI sont souvent enregistrés dans divers journaux système, historiques de navigateur et champs d'en-tête de référent. Par conséquent, les informations sensibles NE DEVRAIENT PAS être transmises dans les URI, en particulier dans les chaînes de requête.

9.7. Disclosure of Fragment after Redirects (Divulgation du Fragment après les Redirections)​

Bien que les identificateurs de fragment ne soient pas envoyés aux serveurs, si un URI contient un fragment et que cet URI est redirigé vers un autre site, le fragment d'origine peut être exposé au nouveau site après la redirection.

9.8. Disclosure of Product Information (Divulgation d'Informations sur les Produits)​

Les en-têtes Server et User-Agent contiennent généralement des informations sur le logiciel de l'expéditeur. Bien que ces informations puissent être utiles à des fins statistiques et pour identifier des problèmes d'interopérabilité, elles peuvent également être utilisées par un attaquant pour identifier des vulnérabilités logicielles.

9.9. Browser Fingerprinting (Empreinte Digitale du Navigateur)​

L'empreinte digitale du navigateur (browser fingerprinting) est une technique par laquelle un site Web peut utiliser diverses informations (y compris les champs d'en-tête HTTP) pour identifier ou suivre de manière unique un navigateur, même sans utiliser de cookies ou d'autres mécanismes de suivi explicites.

Acknowledgments (Remerciements)​

Nous remercions toutes les personnes qui ont contribué au développement de la spécification HTTP/1.1.

Nous remercions les nombreuses personnes qui ont contribué directement ou indirectement à la création de ce document:

  • Roy T. Fielding (éditeur principal de la spécification)
  • Julian Reschke (co-éditeur de la spécification)
  • Tous les membres du groupe de travail HTTP

Nous remercions également les auteurs de la spécification HTTP précédente ([RFC2616]): Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, Tim Berners-Lee.

Nous remercions tous les fournisseurs, développeurs et utilisateurs qui ont contribué à l'implémentation et aux tests de HTTP/1.1.

References (Références)​

Normative References (Références Normatives)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

  • [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

  • [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

  • [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

  • [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 2014.

  • [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

Informative References (Références Informatives)​

  • [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

  • [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.

  • [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.

  • [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.

  • [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

  • [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

  • [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997.

  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  • [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.

  • [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

  • [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.

  • [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

  • [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

  • [Welch] Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.

Appendix A. HTTP Version History (Historique des Versions HTTP)​

La politique de versionnage HTTP n'a pas changé depuis qu'elle a été introduite pour la première fois en 1990 dans le cadre de l'initiative d'information globale World-Wide Web. Cette politique de version vise à permettre à l'expéditeur d'indiquer le format d'un message et sa capacité à comprendre et participer à des communications ultérieures.

Le développement de HTTP/1.1 a pris plus de 10 ans, incluant deux spécifications différentes sur la voie de normalisation ([RFC2068] et [RFC2616]), ainsi que des décennies d'expérience en matière d'implémentation et de déploiement.

A.1. HTTP/0.9​

HTTP/0.9 était la première implémentation du protocole HTTP sur le World-Wide Web. C'était un protocole simple où une requête consistait en une seule ligne contenant uniquement la méthode et l'URI cible.

GET /hello.txt

A.1.1. HTTP/1.0​

HTTP/1.0 a documenté le format de message HTTP commun. Il a ajouté un numéro de version de protocole, un code de statut, et une section d'en-têtes pour les requêtes et les réponses.

La spécification HTTP/1.0 est définie dans [RFC1945].

A.1.2. HTTP/1.1​

HTTP/1.1 est un raffinement de HTTP/1.0, comprenant des descriptions détaillées des méthodes de requête, des codes de statut de réponse et des champs d'en-tête.

Les principales améliorations incluent:

  • Connexions persistantes: Les connexions sont persistantes par défaut
  • Codage de transfert par chunks: Permet l'envoi dynamique du corps du message
  • En-tête Host: Support de l'hébergement virtuel
  • Pipeline: Permet l'envoi de plusieurs requêtes en parallèle
  • Contrôle du cache: Mécanismes de mise en cache plus sophistiqués

HTTP/1.1 a été défini pour la première fois dans [RFC2068] (janvier 1997), puis mis à jour dans [RFC2616] (juin 1999).

A.2. Changes from RFC 2616 (Changements par rapport à RFC 2616)​

Ce document ([RFC7230]) remplace le précédent [RFC2616] et introduit de nombreuses clarifications et améliorations:

A.2.1. Architecture (Architecture)​

  • Clarification des rôles des intermédiaires (proxys, passerelles, tunnels)
  • Amélioration des définitions des agents utilisateurs et des serveurs d'origine

A.2.2. Message Syntax and Routing (Syntaxe et Routage des Messages)​

  • Clarification du tramage des messages
  • Clarification de l'interaction entre Transfer-Encoding et Content-Length
  • Description détaillée du codage de transfert par chunks

A.2.3. Connection Management (Gestion des Connexions)​

  • Clarification du comportement des connexions persistantes
  • Documentation des limitations du pipeline
  • Description détaillée de la réutilisation et de la fermeture des connexions

A.2.4. Security Considerations (Considérations de Sécurité)​

  • Documentation des attaques de contrebande de requêtes
  • Documentation des attaques de division de réponse
  • Ajout de conseils de sécurité concernant la longueur des éléments de protocole