est incrémenté lorsque le format de message est changé.
La version d'un message HTTP est indiqué par un champ HTTP-Version dans la première ligne du message. Si la version n'est pas spécifiée, le récepteur prendra par défaut la version la plus restrictive: HTTP/0.9.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Notez que les nombres "supérieure" et "inférieure" doivent être pris comme deux entiers distincts et que chacun peut être amené à prendre une valeur supérieure à un simple digit. Ainsi, HTTP/2.4 est une version plus basse que HTTP/2.13, à son tour plus basse que HTTP/12.3. Des zéros mentionnés en tête de nombre doivent être ignorés par le récepteur, et ne devraient pas être émis par l'émetteur.
Ce document définit les versions 0.9 et 1.0 du protocole HTTP. Les applications envoyant des "requêtes pleines" ou "réponses pleines", et définies dans cette spécification, doivent signaler une version HTTP-Version "HTTP/1.0".
Les serveurs HTTP/1.0 doivent:
- reconnaître le format de la ligne de requête HTTP/0.9 et HTTP/1.0
- comprendre toute requête émise sous les formats HTTP/0.9 ou HTTP/1.0;
- répondre avec un message sur la même version de protocole que celle émise dans la requête client.
Les clients HTTP/1.0 doivent:
- reconnaître le format de ligne d'état des réponses HTTP/1.0;
- comprendre toute réponse au format HTTP/0.9 ou HTTP/1.0.
Les applications des Proxy et routeurs doivent prendre certaines précautions lorsqu'ils retransmettent des requêtes d'un format différent que celui de l'application native. Comme la version de protocole indique les possibilités fonctionnelles de l'application de l'émetteur, un proxy/routeur ne doit jamais émettre de requête de niveau supérieur à celui de sa propre application HTTP; si une telle requête lui parvient, le proxy/routeur doit dégrader le numéro de version, ou renvoyer une erreur. Les requêtes reçues sur un niveau inférieur peuvent être relevées au niveau de version de l'application native; la réponse de ces proxies/routeurs doivent néanmoins suivre les règles énoncées ci-avant.
3.2 Uniform Resource Identifiers
Les URI sont connues sous de nombreux noms: adresses WWW, identificateur universel de document (Universal Document Identifiers), identificateur universel de ressource (Universal Resource Identifiers) [2], et finalement la combinaison d'une localisation uniforme de ressource (Uniform Resource Locators ou URL) [4] et d'un nom (Name - URN) [16]. Pour autant que le protocole HTTP est concerné, les Uniform Resource Identifiers sont simplement des chaînes formatées identifiant --via un nom, une localisation, ou toute autre caractéristiques -- une ressource réseau.
3.2.1 Syntaxe générale
Les URI dans HTTP peuvent être représentées sous forme absolue, ou relativement à une autre URI connue [9], suivant le contexte. Les deux formes sont différenciées par le fait qu'une URI absolue commence toujours par un schème contenant un nom suivi du caractère ":".
URI = (URIabsolue | URIrelative ) [ "#" fragment ]
URIabsolue = scheme ":" *( uchar | reserve )
URIrelative = chem_res | chem_abs | chem_rel
chem_res = "//" loc_res [ chem_abs ]
chem_abs = "/" chem_rel
chem_rel = [ chemin ] [ ";" params ] [ "?" requete ]
chemin = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
loc_res = *( pchar | ";" | "?" )
requete = *( uchar | reserve )
fragment = *( uchar | reserve )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = non_reserve | echap
non_réservé = ALPHA | DIGIT | sur | extra | national
echap = "%" HEX HEX
reserve = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
sur = "$" | "-" | "_" | "."
non_sur = CTL | SP | <"> | "#" | "%" | "<" | ">"
national =
Pour une information définitive sur la syntaxe des URL voir les RFC 1738 [4] et
RFC 1808 [9]. La notation BNF inclue des caractères nationaux non permis dans les URL valides telles que spécifiées dans la RFC 1738, car les serveurs HTTP ne sont pas limités à l'ensemble de caractères non réservés pour le codage de la prtie relative du chemin d'accès, et les proxies HTTP peuvent recevoir des requêtes à destinations d'URI autres que celles définies dans la RFC 1738.
3.2.2 URL http
Le schème "http" est utilisé pour localiser une ressource réseau via le protocole HTTP. Cette section définit la syntaxe et la sémantique des URL.
http_URL = "http:" "//" host [ ":" port ] [ chem_abs ]
host = [un nom Internet d'ordinateur valide ou une
adresse IP (sous forme numérique),
comme définie en Section 2.1 de la RFC 1123]
port = *DIGIT
Si le port est vide ou non spécifié, le port 80 est pris par défaut. La sémantique précise que cette ressource est localisée sur le serveur acceptant les connexions TCP sur ce port et sur cet ordinateur, l'URI de requête de la ressource en est le chemin d'accès absolu chem_abs. Si chem_abs n'est pas précisé dans l'URL, il doit être remplacé par un "/" lorsque l'URI de requête est utilisée (Section 5.1.2).
Note: Bien que le protocole HTTP soit indépendant de la couche transport, l'URL http identifie la ressource par son adresse TCP, Les ressources non TCP devant être atteintes via un autre schème d'URI.
La forme canonique d'une URL "http" est obtenue en convertissant tous les caractères UPALPHA dans la chaîne "host" par leur équivalent LOALPHA (les noms de host ne tiennent pas compte de la casse), en éludant le descriptif [ ":" port ] si le port vaut 80, et en remplaçant le chem_abs vide par un "/".
3.3 Formats de temps et de date
Les applications HTTP/1.0 ont historiquement reconnu trois formats distincts pour la définition de dates et d'unités temporelles:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, mis à jour par la RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, rendue obsolète depuis la RFC 1036
Sun Nov 6 08:49:37 1994 ; Format asctime() du C ANSI
Le premier format est préféré pour Internet pour une raison liée à la longueur fixe de ses sous-champs, définis par la RFC 1123 [6] (une mise à jour de la RFC 822 [7]). Le second format est d'usage commun, mais se base sur le format de date tel que défini par la RFC 850 [10] désormais obsolète, et présente l'inconvénient d'un champ d'année sur deux digits. Les clients et serveurs HTTP/1.0 doivent reconnaître les trois formats, même s'ils ne doivent jamais générer le troisième (convention du C).
Note: Les récepteurs de valeurs de date doivent avoir une implémentation robuste et de ce fait être capables de reconnaître des formats de date émanent d'applications non-HTTP, comme il peut leur en parvenir en postant ou récupérant des messages via proxy/routeur de et vers SMTP ou NNTP.
Tout index temporel HTTP/1.0 doit être représenté en temps universel (Universal Time - UT), connu aussi sous l'appellation Greenwich Mean Time (GMT), sans exception possible. Ceci est indiqué dans les deux premiers formats par l'inclusion du mot "GMT", abréviation en trois lettre du code de zone, et doit être supposé comme vrai à la lecture d'un temps asctime().
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = jsem "," SP date1 SP temps SP "GMT"
rfc850-date = joursem "," SP date2 SP temps SP "GMT"
asctime-date = jsem SP date3 SP temps SP 4DIGIT
date1 = 2DIGIT SP mois SP 4DIGIT
; jour mois an (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" mois "-" 2DIGIT
; jour-mois-an (e.g., 02-Jun-82)
date3 = mois SP ( 2DIGIT | ( SP 1DIGIT ))
; mois jour (e.g., Jun 2)
temps = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
jsem = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
joursem = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
mois = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
Note: Les contraintes au niveau du format de date HTTP ne sont valables qu'à l'intérieur du réseau de transmission. Les clients et serveurs ne sont pas obligés de respecter cette présentation pour l'affichage, la présentation de requête, l'accès, etc.
3.4 Tables de caractères
HTTP utilise la même définition du vocable "table de caractères" que celle utilisée par MIME:
Le terme "table de caractères" utilisé dans ce document se référe à une méthode utilisant une ou plusieurs tables pour convertir une séquence d'octets en caractères. Notez qu'une conversion inverse n'est pas forcément demandée, c'est à dire que tout octet peut ne pas être représenté par un caractère, et qu'à l'inverse, une chaîne de caractères peut très bien être représentable par plus d'une seule séquence d'octets. Cette définition permet un grand nombre de types de conversions, depuis celle, élémentaire, à une table comme l'ASCII-US jusqu'à des méthodes plus complexes à "commutation de tables" comme celles définies par l'ISO 2022. Cependant, la définition associée au nom d'une "table de caractère" MIME doit parfaitement et entièrement spécifier le passage des octets aux caractères. En particulier, le recours à des informations externes pour pouvoir assumer la conversion est interdit.
Note: Le terme "table de caractères" est aussi communément appelé "encodage". Cependant, comme HTTP et MIME partagent les mêmes définitions, il est important qu'ils partagent aussi la terminologie.
Les "tables de caractères" HTTP sont définies par des mots sans distinction de casse. L'ensemble complet de ces tables constitue le "registre de tables de l'IANA" (Character Set registry [15]). Cependant, comme ce "registre" ne définit pas un nom unique et définitif pour chacune de ces tables, nous avons défini ici les noms les plus couramment utilisés dans les entités HTTP. Ces "tables de caractères" incluent celles définies dans la RFC 1521 [5] -- ASCII-US [17] et ISO-8859 [18] -- ainsi que celles spécifiquement définies pour usage dans les paramètres de caractères MIME.
charset = "US-ASCII" | "ISO-8859-1" | "ISO-8859-2"
| "ISO-8859-3" | "ISO-8859-4" | "ISO-8859-5"
| "ISO-8859-6" | "ISO-8859-7" | "ISO-8859-8"
| "ISO-8859-9" | "ISO-2022-JP" | "ISO-2022-JP-2"
| "ISO-2022-KR" | "UNICODE-1-1" | "UNICODE-1-1-UTF-7"
| "UNICODE-1-1-UTF-8" | autre_nom
Bien qu'HTTP permette l'utilisation de tout nom arbitraire pour désigner une table de caractères, tout nom désignant déjà une des tables du registre IANA doit indiquer cette table précise. Il est conseillé que les applications s'en tiennent aux tables de caractères définies dans ce registre.
La table de caractère indiquée pour un corps d'entité doit être le plus petit dénominateur commun de l'ensemble des codes de caractères utilisés dans ce corps, sauf si l'on préfère systématiquement s'en tenir aux tables de base ASCII-US ou ISO-8859-1.
3.5 Indication d'encodage du contenu
Les valeurs de "codage de contenu" indiquent la nature de la transformation qui a été appliquée à une ressource. Cette information a été initialement définie pour pouvoir garder la trace d'un type de ressource compressée ou encryptée. Typiquement, la ressource est disponible sous forme encodée, et ne sera décodée qu'au moment de son utilisation.
content-coding = "x-gzip" | "x-compress" | transformation
Note: Pour des raisons de compatibilité future, les applications HTTP/1.0 doivent interpréter "gzip" et "compress" respectivement comme "x-gzip" et "x-compress".
Toute mention d'encodage est indépendante de la casse. L'HTTP/1.0 utilise les descripteurs d'encodage dans le champ Content-Encoding (Section 10.3) de l'en-tête. Le plus important est que cette information indique quel est le type de décodage que le récepteur devra utiliser pour exploiter la ressource. Notez qu'un même programme peut être capable de décoder plusieurs types d'encodage. Les deux valeurs définies dans cette spécification sont:
x-gzip
Un format de compression géré par le programme de compression "gzip" (GNU zip) développé par Jean-Loup Gailly. Ce codage est de type Lempel-Ziv (LZ77) avec CRC sur 32 bits.
x-compress
Un format de compression géré par le programme "compress" effectuant une compression adaptative de type Lempel-Ziv-Welch (LZW).
Note: L'utilisation de noms de programmes pour nommer des formats d'encodage n'est pas souhaitable et sera déconseillé dans le futur. Leur utilisation dans ce cas provient surtout d'une habitude historique, mais ce n'est pas une habitude à prendre.
3.6 Types de média
HTTP exploite les définition de types de média Internet Media Types [13] dans le champ Content-Type de l'en-tête (Section 10.5) afin de proposer une méthode de typage ouverte et évolutive.
media-type = type "/" soustype *( ";" paramètre )
type = nom_type
soustype = nom_soustype
Les paramètres suivent la description de type/soustype, sous la forme de paires attribut/valeur.
parametre = attribut "=" valeur
attribut = nom_attribut
valeur = nom_valeur | chaîne entre guillemets
Le type, sous-type et les noms d'attributs sont insensibles à la casse. Les valeurs associées aux attributs peuvent l'être ou ne pas l'être, suivant la sémantique du nom de l'attribut. les types et sous type ne peuvent être séparé par un LWS. Ceci est valable pour les paires attribut/valeur Lorsqu'un récepteur reçoit un paramètre irrecevable pour le type de média spécifié, il devra traiter le descripteur comme si cette paire attribut/valeur n'existait pas..
Certaines anciennes applications HTTP ne reconnaissent pas le type de média. Les applications HTTP/1.0 ne pourront définir le type que lorsque la spécification du contenu est indispensable.
Les valeurs admises de types de média sont définies par la Internet Assigned Number Authority (IANA [15]). Le processus d'enregistrement d'un type de média est spécifié dans la RFC 1590 [13]. L'usage de types non enregistrés est déconseillé.
3.6.1 Canonisation et texte par défaut
Les types de média Internet sont enregistrés sous une forme canonique. En principe, un corps d'entité transféré par HTTP doit être représenté dans sa forme canonique avant transmission. Si le corps a été encodé sous un codage spécifié par un Content-Encoding, il devait être sous sa forme canonique avant encodage.
Les sous types du type "text" utilisent dans leur forme canonique la séquence CRLF en tant que fin de ligne. Cependant, HTTP permet le transport de texte dans lequel un CR ou un LF seul représente la fin de ligne, tant que l'on reste à l'intérieur du corps de l'entité. Les applications HTTP doivent accepter des fins de ligne représentées par la séquence CRLF, par un CR seul, ou par un LF seul, dès qu'il s'agit d'un média "text".
De plus, si le média texte utilise une table de caractère dans laquelle les caractères 13 et 10 ne correspondent pas aux caractères CR et LF, comme c'est le cas pour certains codages multi-octets, HTTP permet l'usage de toute séquence de caractères désignés comme équivalents des CR et LF et faisant office de fins de ligne. Cette souplesse n'est permise par HTTP que dans le corps de l'entité; Un CRLF "légal" ne devra pas être remplacé par un CR seul ou un LF seul dans aucune des structures de contrôle HTTP (telles que les champs d'en-têtes ou les limites "multipart").
Le paramètre "charset" est utilisé avec certains types de média pour définir la table de caractères utilisée (Section 3.4) dans les données. Lorsque ce paramètre n'est pas explicitement renseigné, les sous-types du média "text" prennent par défaut la table de caractères "ISO-8859-1". Des données codées selon une autre table de caractères que "ISO-8859-1" ou ses sous-ensembles devra nécessairement entraîner une spécification explicite de ce codage, sous peine d'être ininterprétables par le récepteur.
Note: De nombreux serveurs HTTP actuels diffusent des données codées selon une table de caractères autre que "ISO-8859-1" et sans explicitation correcte. Cette attitude réduit l'interopérabilité propre du réseau et est fortement déconseillée. Pour compenser de manque de rigueur, certains utilisateurs HTTP proposent une option permettant de changer la table de caractères par défaut utilisée lorsque des données sont reçues sans explicitation de cette information.
3.6.2 Types multiples "multipart"
Le MIME définit un certain nombre de types "multipart" -- encapsulation de plusieurs entités dans un même corps d'entité. Les types "multipart" enregistrés par l'IANA [15] n'ont pas de signification particulière aux yeux d'HTTP/1.0, bien que les utilisateurs dussent être en mesure de pouvoir reconnaître chaque sous type de façon à correctement interpréter chaque sous partie du corps. Un utilisateur HTTP suivra les mêmes règles de comportement qu'un utilisateur MIME dans le cas d'une réception de données "multipart". Les serveurs HTTP ne sont pas sensé supposer que tous les clients HTTP puissent recevoir des données ainsi présentées.
Tous les types "multipart" partagent la même syntaxe et doivent spécifier un paramètres de "limite" dans la définition du type. Le corps du message fait lui-même partie du protocole et doit s'en tenir à la séquence CRLF pour représenter des sauts de lignes entre les parties. Chaque partie d'un document "multipart" peut elle même contenir des champs d'en-tête HTTP significatifs pour son contenu.
3.7 Produits
La spécification de produit permet à deux application en communication de s'identifier l'une à l'autre par un simple nom, suivi d'un "slash" ('/') et d'un numéro de version, tous deux optionnels. Les champs acceptant cette spécification permettent de lister des sous-éléments significatifs d'un produit, séparés par un espace. Par convention, les produits sont rangés par ordre d'importance dans le processus d'identification.
produit = nom_produit ["/" version]
version = numéro_de_version
Exemples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Les spécifications de produits doivent être concises et directes -- l'utilisation de ce champ à vocation publicitaire ou pour diffuser des informations non essentielles est strictement interdit. Le sous-champ de numéro de version accepte tout caractère valide pour des noms. Il est demandé de ne pas abuser de cette permissivité et de conserver ce champ pour l'indication de la version à l'exclusion de toute autre information.
Crédits : T. Berners-Lee, MIT/LCS, R. Fielding, UC Irvine, H. Frystyk, MIT/LCS,
Traduction : V.G. FREMAUX
Edition originale : Mai 1996 / Version FR: Septembre 1997