Le texte suivant est la traduction intégrale de la spécification HTTP 1.0, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document a valeur informative, selon la procédure courante d'enregistrement des documents au sein du W3C. Il n'a de ce fait pas valeur de "norme", et, s'il peut être considéré comme document de référence, il ne peut par contre octroyer une légitimité quelconque à un quelconque développement, ni servir de preuve ni de garant d'une conformité quelle qu'elle soit.
Concernant les droits de traduction de ce texte : Toute reproduction de cette traduction est autorisée à titre personnel ou éducatif. Par contre, étant donné la quantité de travail que cette mise en œuvre représente, le traducteur se réserve le droit d'autoriser une reproduction partielle ou totale de cette traduction dans tout ouvrage à caractère commercial.
Statut de ce mémo
Ce mémo est une information à destination de la communauté Internet. Il ne peut être considéré comme une spécification officielle d'aucun protocole Internet. Sa distribution n'est pas limitée.
Note IESG
L'IESG espère que ce document sera rapidement remplacé par une norme officielle.
Contexte
L'Hypertext Transfer Protocol (HTTP) est un protocole de niveau application suffisamment léger et rapide, pour la transmission de documents distribués et multimédia à travers un système d'information multi-utilisateurs. Il s'agit d'un protocole générique, orienté objet, pouvant être utilisé pour de nombreuses tâches, dans les serveurs de nom et la gestion d'objets distribués par l'extension de ses méthodes de requête (commandes). Une caractéristique d'HTTP est son typage des représentations de données, permettant la mise en oeuvre de systèmes indépendants des données y étant transférées.
HTTP a été utilisé à l'initiative du World-Wide Web depuis 1990. Cette spécification décrit le protocole de base référencé sous l'appellation "HTTP/1.0".
Les systèmes d'information pratiques nécessitent des fonctions plus évoluées que la simple récupération de données, parmi lesquelles on trouve la possibilité d'effectuer des recherches, les fonctions de remise à jour, et d'annotation. HTTP permet d'utiliser un ensemble non exhaustif de méthodes pour définir l'objet d'une requête. Il s'appuie essentiellement sur la normalisation des Uniform Resource Identifier (URI) [2], soit sous forme de "site" (URL) [4] ou de noms (URN) [16], pour indiquer l'objet sur lequel porte la méthode. Les messages sont transmis sous une forme similaire à celle de la messagerie électronique (Mail) [7] et des extensions Multipurpose Internet Mail Extensions (MIME) [5]. HTTP est aussi un protocole e communication générique entre des "utilisateurs" et des routeurs/proxies vers d'autres protocoles, tels que SMTP [12], NNTP [11], FTP [14], Gopher [1], et WAIS [8], permettant une accès de base à des ressources hypermédia, et simplifiant l'implémentation d'interfaces utilisateur.
Connexion
Un circuit virtuel s'appuyant sur une couche de transport pour la communication d'information entre deux applications.
Message
L'unité de base d'une communication HTTP, consistant en une séquence structurée d'octets définie à la Section 4 et transmis via la connexion.
Requête
Un message de requête HTTP (défini en Section 5).
Réponse
Un message de réponse HTTP (défini en Section 6).
Ressource
Un service ou objet du réseau pouvant être identifié par une URI (Section 3.2).
Entité
Une représentation particulière de données, ou la réponse d'une ressource de type service, incluse dans une requête ou une réponse. Une entité représente une métainformation sous la forme d'une en-tête et d'un contenu sous la forme d'un corps, ou "body".
Client
Un programme applicatif dont la fonction principale est d'émettre des requêtes.
Utilisateur
Le client qui a émis la requête. Celui-ci peut être un navigateur, un éditeur, un "spiders" (robot d'exploration), ou autre utilitaire.
Utilisateur final
L'utilisateur humain pilotant le programme utilisateur.
Serveur
Un programme applicatif acceptant des connexions dans le but traiter des requêtes en délivrant une réponse.
Serveur origine
Le serveur dans laquelle se situe physiquement une ressource.
Proxy
Un programme intermédiaire qui cumule les fonctions de serveur et de client. Les requêtes sont soit traitées en interne ou répercutées, éventuellement converties, sur d'autres serveurs. Un proxy doit interpréter, puis reconstituer un message avant de le réemettre. Les proxies sont souvent utilisés comme portes d'accès côté utilisateur à des réseaux protégés par un "firewall" ou comme intermédiaire pour convertir des protocoles non supportés par l'utilisateur.
Gateway ou routeur
Un serveur jouant le rôle d'intermédiaire pour d'autres serveurs. Contrairement à un Proxy, un routeur reçoit les requêtes comme s'il était le serveur origine pour la ressource; le client n'étant pas nécessairement conscient de "communiquer" avec un routeur. Les routeurs sont souvent utilisés comme porte d'accès côté serveur d'un réseau protégé par "firewall" et comme convertisseur de protocole pour accéder à es ressources hébergées sur des systèmes non-HTTP.
Tunnel
Un tunnel est un programme applicatif servant de relais "transparent" entre deux connexions. Une fois actif, cet élément n'est plus considéré comme faisant partie de la connexion HTTP, bien qu'il soi issu d'une requête HTTP. Le tunnel cesse d'exister lorsque les deux sens de la connexion ont été fermés. Les tunnels sont utilisés lorsqu'une "porte" est nécessaire et que l'intermédiaire ne peut, ou ne doit pouvoir interpréter la communication.
Cache
Un espace de stockage local destiné à enregistrer les réponses et le sous-système contrôlant ces enregistrements, leur relecture et leur effacement. Un cache enregistre des réponses dans le but de diminuer le temps d'accès et la charge du réseau lors de requêtes identiques ultérieures. Tout client ou serveur peut implémenter un cache, bien que le serveur ne puisse exploiter ce cache, faisant office de tunnel.
Un programme pouvant aussi bien être serveur que client; l'utilisation que nous ferons de ces termes s'appliquera à la situation qu'à le programme vis à vis d'une connexion particulière, plutôt qu'à ses possibilités effectives. De même tout serveur peut être à la fois serveur origine, proxy, routeur, ou tunnel, changeant alors de comportement en fonction des requêtes reçues.
La plupart des communications HTTP sont initiées par un utilisateur et consistent en une requête devant être appliquée (il s'agit d'une méthode) à une ressource sur son serveur origine. Dans le cas le plus simple, ceci peut être réalisé par une connexion simple (v) entre l'utilisateur (UA) et le serveur origine (O).
Requête ------------------------> UA -------------------v------------------- O <----------------------- RéponseUne situation plus complexe peut apparaître lorsque un ou plusieurs intermédiaires sont présents dans la chaîne de communication. On trouvera trois types d'intermédiaires: les proxy, les routeurs, et les tunnels. Un proxy est un agent actif, recevant les requêtes destinées à une URI dans sa forme absolue, recomposant tout ou partie du message, et réémettant la requête transformée à destination de l'URI. Un serveur est un agent actif, agissant en tant que "surcouche" par rapport à d'autres serveurs et si nécessaire, traduisant le protocole à destination et en provenance du serveur visé. Un tunnel est un agent passif ne servant que de relais entre deux parties d'une même connexion, et de ce fait sans modifier le message; les tunnels sont utilisés lorsque le message doit traverser un intermédiaire (comme un "firewall") même si celui-ci ne peut interpréter le contenu des messages.
Requête --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- RéponseLa figure ci-dessus montre le cas de trois intermédiaires (A, B, et C) entre l'utilisateur et le serveur origine. Une requête ou réponse passant d'un bout à l'autre doit transiter par quatre connexions. Cette distinction est important car certaines options d'une communication HTTP peuvent ne s'appliquer qu'à la connexion la plus proche, sans même passage par un tunnel, et accessible uniquement des extrémités, ou au contraire à toutes les connexions impliquées dans la chaîne. Bien que ce schéma soit linéaire, chaque participant peut être engagé dans plusieurs communications simultanées. Par exemple, B peut être en train de recevoir de nombreuses requêtes de clients autres que A, et émettre des requêtes vers d'autres serveurs que C, tout en interprétant les requêtes issues de A.
Toute partie de communication n'étant pas un tunnel doit posséder un cache pour le stockage des requêtes. L'intérêt de cette pratique est que la chaîne requête/réponse peut être considérablement raccourcie si l'un des intermédiaires dispose déjà d'une instance de la ressource dans son cache. Le diagramme suivant montre le cas où B dispose dans son cache d'une copie d'une réponse précédemment envoyée par O (via C) et répond à une requête identique de UA (à noter que dans cet exemple, ni UA ni A ne disposent de cette même réponse en cache).
Requête ----------> UA -----v----- A -----v----- B - - - - - - C - - - - - - O <--------- RéponseToutes les réponses ne peuvent être "cachées", et certaines requêtes peuvent utiliser des modificateurs induisant un comportement particulier du cache. Certaines applications HTTP/1.0 utilisent des heuristiques pour décrire ce qui est ou non "cachable", mais ces règles ne sont pas standardisées.
Sur Internet, les communications HTTP s'appuient principalement sur le protocole de connexion TCP/IP. Le port utilisé par défaut est le port TCP 80 [15], d'autres ports pouvant être utilisés. Ceci n'exclut pas que HTTP puisse être implémenté au dessus d'un autre protocole d'Internet, ou sur d'autres types de réseau. HTTP nécessite seulement un transport fiabilisé; tout protocole garantissant la sécurité de transmission peut être utilisé pour supporter HTTP, la place qu'occupent les données des requêtes et réponses HTTP/1.0 dans les unités de transmission de ces protocoles restant en dehors du contexte de ce document.
Excepté pour des applications expérimentales, la pratique courante spécifie qu'une connexion doit être initiée par un client avant transmission de la requête, et refermée par le serveur après délivrance de la réponse. Les deux côtés, client et serveur, doivent être préparés à ce que la connexion soit coupée prématurément, suite à une action de l'utilisateur, une temporisation automatique, ou une faute logicielle, et doivent apporter une réponse prévisible à cette situation. Dans tous les cas, la fermeture d'une connexion qu'elle qu'en soit la raison est assimilable à la conclusion de la requête, quel que soit l'état.
nom = définition
Le nom d'une règle est le nom lui-même (sans "<" ni ">" englobants) et est séparé de sa définition par le symbole "=". Le caractère espace n'a de signification que lorsqu'un retrait indique qu'une définition s'étend sur plusieurs lignes. Certaines règles de base sont en majuscules, comme SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Les ouvertures et fermetures "<" et ">" ne sont utilisées que lorsqu'une discrimination des règles est indispensable à l'intérieur d'une définition.
"literal"
Un texte littéral est entre doubles guillemets. Sauf mention contraire, la casse du texte n'est pas considérée.
règle1 | règle2
Les éléments séparés par une barre ("I") constituent une alternative, ex., "oui | non" acceptera "oui" ou "non".
(règle1 règle2)
Les éléments à l'intérieur de parenthèses sont considérés comme un seul élément. Ainsi, "(elem (foo | bar) elem)" permet les séquence "elem foo elem" et "elem bar elem".
*règle
Le caractère "*" précédent un élément indique sa répétition. La forme complète de cette notation est "<n>* <m>element" indiquant au moins <n> et au plus <m> occurrences de "element". Les valeurs par défaut sont 0 et "infini". la syntaxe "*(element)" signifie donc tout nombre d'occurrences y compris 0; "1*element" précise au moins une occurrence; et "1*2element" précise une ou deux occurrences.
[règle]
Les crochets précisent un élément optionnel; "[foo bar]" vaut pour "*1(foo bar)".
Nrègle
Répétition précise: "<n>(element)" est équivalente à "<n>*<n>(element)"; c'est à dire, exactement <n> occurrences de (element). Ainsi 2DIGIT est un nombre de 2-digits, et 3ALPHA une chaîne de 3 caractères alphabétiques.
#règle
Une syntaxe "#" est utilisée, comme pour la syntaxe "*", pour définir des listes d'éléments. La forme complète en est "<n># <m>element" indiquant au moins <n> et au plus <m> elements, chacun séparé par une ou plusieurs virgules (",") et des espaces optionnels (LWS). Ceci rend la forme des listes très lisible; une règle du type "( *LWS element *( *LWS "," *LWS element ))" peut être vue comme "1#element". Lorsque cette construction est utilisée, les éléments vides sont utilisés, mais ne contribue pas au comptage des éléments présents. De ce fait, "(element), , (element)" est permis, mais compte comme deux éléments. Toutefois, dans les cas ou un élément au moins est requis, cet élément doit être non nul. Les valeurs par défaut sont 0 et "infini" et donc "#(element)" vaut pour tous les éléments y compris 0; "1#element" vaut pour au moins un; et "1#2element" permet un ou deux éléments.
; commentaire
Un point virgule, à distance d'un texte de règle instaure un début de commentaire qui va jusqu'au bout de la ligne. C'est un moyen pratique d'insérer des remarques ou annotations en cours de spécification.
*LWS implicite
La grammaire décrite par cette spécification est basée sur le "mot". Sauf mention contraire, tout nombre d'espaces (LWS) peut être inséré entre deux mots adjacents ou "token", et entre un "token" et un délimiteur (tspecials), sans changer l'interprétation. Il doit exister au moins un délimiteur (tspecials) entre deux mots, au risque de les voir interprétés comme un seul. Malgré tout, les constructions HTTP tendront à utiliser la "forme commune", certaines implémentations ne savent traiter autre chose que cette forme.
OCTET = [toute donnée codée sur 8 bits] CHAR = [tout caractère ASCII-US (0 à 127)> UPALPHA = [Tout caractère alphabétique ASCII-US majuscule "A".."Z"] LOALPHA = [Tout caractère alphabétique ASCII-US minuscule "a".."z"] ALPHA = UPALPHA | LOALPHA DIGIT = [tout digit ASCII-US "0".."9"] CTL = [Tous caractère de contrôle ASCII-US (0 à 31) et DEL (127)] CR = [CR ASCII-US, retour chariot (13)] LF = [LF ASCII-US, saut de ligne (10)] SP = [SP ASCCII-US, espace (32)] HT = [HT ASCII-US, tabulation horizontale (9)] <"> = [double guillemet ASCII-US (34)]HTTP/1.0 définit la séquence CR LF comme marqueur de fin de ligne pour tous les éléments excepté le corps de l'entité (voir Appendice B pour les tolérances). La fin de ligne à l'intérieur d'un corps d'entité dépend de son média, comme décrit en Section 3.6.
CRLF = CR LFLes en-têtes HTTP/1.0 peuvent être réparties su plusieurs lignes si chaque nouvelle ligne commence par un espace ou une tabulation horizontale. Une suite d'espace, même sur plusieurs lignes équivaut à un espace simple.
LWS = [CRLF] 1*( SP | HT )Cependant les en-têtes multilignes ne sont pas acceptées par toutes les applications, et doivent de préférence être évitées lors d'un codage HTTP/1.0.
La règle TEXT est utilisée pour décrire des informations descriptives qui ne sont pas sensées être interprétées. Les mots d'un élément *TEXT peuvent contenir d'autres caractères que ceux de la table ASCII-US stricto sensu.
TEXT = [tout OCTET sauf CTL, hormis LWS qui reste autorisé]Les récepteurs d'un élément TEXT d'une en-tête contenant des octets hors de la table ASCII-US supposeront qu'il s'agit de caractères ISO-8859-1.
Les caractères hexadécimaux peuvent être utilisés dans certaines applications.
HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGITDe nombreux champs d'en-tête HTTP/1.0 sont formés de mots séparés par des espaces ou caractères spéciaux. Ces caractères doivent être entre guillemets lorsqu'ils sont utilisés à l'intérieur d'une valeur.
mot = token | chaîne entre guillemets
token = 1*[tout CHAR excepté CTLs ou tspecials]
tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":"
| "\" | ["] | "/" | "[" | "]" | "?" | "=" | "{"
| "}" | SP | HT
Les commentaires pourront être
insérés dans les en-têtes HTTP en les entourant de parenthèses. Les commentaires
ne sont permis que dans les champs contenant le mot "comment" dans leur
définition. Dans tous les autres champs, les parenthèses sont interprétées comme
faisant partie de l'expression. comment = "(" *( ctext | comment ) ")"
ctext = [tout TEXT excepté "(" et ")"]Une chaîne sera interprétée comme un seul mot
si elle est entre double guillemets. quoted-string = ( <"> *(qdtext) <"> ) qdtext = [tout CHAR sauf <"> et CTL, hormis LWS qui est accepté]L'utilisation du backslash ("\") comme séquence d'échappement d'un caractère unique n'est pas permis par le protocole HTTP/1.0
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*DIGITNotez 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:
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 = "!" | "*" | "'" | "( 1000 " | ")" | "," 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.
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 = *DIGITSi 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 "/".
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" & 1000 nbsp; | "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.
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_nomBien qu'HTTP permette l'uti 1000 lisation 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.
content-coding = "x-gzip" | "x-compress" | transformationNote: 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
media-type = type "/" soustype *( ";" paramètre ) type = nom_type soustype = nom_soustypeLes 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 guillemetsLe 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é.
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.
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.
produit = nom_produit ["/" version] version = numéro_de_versionExemples:
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 laversion à l'exclusion de toute autre information.
HTTP-message = Requête_simple ; HTTP/0.9 messages | Réponse_simple | Requête_complète ; HTTP/1.0 messages | Réponse_complèteLes requêtes et réponses "complètes" utilisent le format de message défini dans la RFC 822 [7] concernant la transmission d'entités. Ces deux messages peuvent contenir une en-tête optionnelle ainsi que le corps de l'entité. Le corps et l'en-tête de l'entité sont séparés par une ligne vide (soit une séquence CRLFCRLF).
Requête_complète = Ligne_requête ; Section 5.1 *( En-tête_générale ; Section 4.3 | En-tête_requête ; Section 5.2 | En-tête_entité ) ; Section 7.1 CRLF [ Corps_entité ] ; Section 7.2
Réponse_complète = Lgne-état ; Section 6.1 *( En-tête_générale ; Section 4.3 | En-tête_réponse ; Section 6.2 | En-tête_entité ) ; Section 7.1 CRLF [ Corps_entité ] ; Section 7.2Les requête et réponse simple ne transportent jamais d'en-tête. Une seule requête est de ce type : GET.
Requête_simple &n 1000 bsp; = "GET" SP URI-visée CRLF Réponse_simple = [ Corps_entité ]L'usage des requêtes simples reste déconseillé, car il ne permet pas au serveur de définir le type de média dans sa réponse.
HTTP-header = nom ":" SP [ valeur ] CRLF nom = nom_de_champ valeur = *( contenu | LWS ) contenu = [les OCTETs décrivant la valeur, pouvant être un *TEXT ou combinaison de noms, caractères spéciaux, et chaînes entre guillemets]L'ordre dans lequel les champs d'en-tête sont reçus n'a pas d'importance. Une "bonne habitude" consistera toutefois à envoyer les champs d'en-tête_générale en premier, suivi des champs d'en-tête_requête ou d'en-tête_réponse, puis enfin les champs d'en-tête_entité.
Lorsque plusieurs champs de même nom doivent être définis avec des valeurs différentes, celles-ci doivent apparaître comme une liste séparée par des virgules [#(values)]. Il doit être possible de combiner cette définition multiple à partir des paires individuelles "nom: valeur", sans changer la sémantique du message, en ajoutant chaque valeur à la suite de la première, en utilisant une virgule comme séparateur.
General-Header = Date ; Section 10.6 | Pragma &nb 1000 sp; ; Section 10.12Des nouveaux noms de champs d'en-tête_générale ne peuvent être introduits que dans le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou champs expérimentaux peuvent utiliser la sémantique de champs d'en-tête_générale, à partir du moment ou les deux extrémités de la communication sont d'accord pour le faire. Tout champ non reconnu sera considéré comme un champ d'en-tête_entité.
Request = Requête_simple | Requête_complète Simple-Request = "GET" SP URI-visée CRLF Requête_complète = Ligne-requête ; Section 5.1 *( En-tête_générale ; Section 4.3 | En-tête_requête ; Section 5.2 | En-tête_entité ) ; Section 7.1 CRLF [ Corps-entité ] ; Section 7.2Si un serveur HTTP/1.0 reçoit une requête simple, il devra répondre par une réponse simple HTTP/0.9. Un client HTTP/1.0 capable de recevoir une réponse_complète ne doit jamais générer de requête_simple.
Ligne_requête = Méthode SP URI-visée SP Version-HTTP CRLFNotez que la différence entre une ligne de requête_simple et de requête_complète ne réside que dans la présence du numéro de version HTTP, et dans la possibilité d'appeler d'autres méthodes que GET.
Méthode = "GET" ; Section 8.1 | "HEAD" ; Section 8.2 | "POST" ; Section 8.3 | nom_de_méthodeLa liste de méthodes que peut accepter une ressource est dynamique; Le client est avisé de la disponibilité de la méthode émise par le code de retour du message de réponse. Les serveurs renverront le code 501 (non implémenté) si la méthode est inconnue, ou non implémentée.
Les méthodes habituellement employées par les applications HTTP/1.0 sont décrites en détail en Section 8.
URI-visée = URIabsolue | chem_absCes deux options dépendent de la méthode appelée.
Seule l'option URIabsolue est permise lorsque la requête est envoyée à un proxy. Le proxy devra retransmettre la requête, et servir d'intermédiaire pour la réponse. Si la requête est GET ou HEAD et la réponse présente dans le cache du proxy, celui-ci pourra utiliser cette réponse directement, si les conditions restrictives de "date d'expiration " dans l'en-tête sont remplies. Notez que le proxy peut à son tour retransmettre la requête vers un autre proxy, ou directement vers le serveur origine. Afin d'éviter qu'une requête ne boucle, un proxy doit reconnaitre tous sesnoms de serveurs, y compris alias, variations locales, et les adresses IP numériques. Voici un exemple de ligne de requête:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
La forme d'URI-visée la plus commune est celle qui identifie une ressource sur son serveur origine ou un routeur. Dans ce cas, seul le chemin absolu chem_abs est transmis (Cf. Section 3.2.1, chem_abs). Par exemple, un client souhaitant récupérer la ressource ci-dessus directement à partir de son serveur origine créera une connexion TCP sur le port 80 du host "www.w3.org" et émettra la ligne de commande:
GET /pub/WWW/TheProject.html HTTP/1.0
suivi du reste de la requête complète. Notez qe le chemin absolu ne peut être vide; si la ressource se trouve dans la racine (pas de chemin d'accès) le chemin spécifié devra comporter au moins le caractère slash("/").
L'URI-visée est transmise sous forme d'une chaîne encodée, dans laquelle certains caractères apparaîtront comme une séquence d'échappement "% HEX HEX" telle que définie par la RFC 1738 [4]. Le serveur origine devra décoder cette chaîne afin d'accéder correctement à la ressource.
Request-Header = Authorization ; Section 10.2 | From ; Section 10.8 | If-modified-since ; Section 10.9 | Referer ; Section 10.13 | User-agent ; Section 10.15Des nouveaux noms de champs d'en-tête_requête ne peuvent être introduits que dans le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou champs expérimentaux peuvent utiliser la sémantique de champs d'en-tête_requête, à partir du moment ou les deux extrémités de la communication sont d'accord pour le faire. Tout champ non reconnu sera considéré comme un champ d'en-tête_entité.
Réponse = Réponse_simple | Réponse_complète Réponse_simple = [ Corps_entité ] Réponse_complète = Ligne_état ; Section 6.1 *( En-tête_générale ; Section 4.3 | En-tête_réponse ; Section 6.2 &nbs 1000 p; | En-tête_entité ) ; Section 7.1 CRLF [ Corps_entité ] ; Section 7.2Une réponse_simple ne peut être envoyé qu'en réponse d'une requête_simple HTTP/0.9 ou si le serveur ne supporte que la version limitée de protocole HTTP/0.9. Si un client émet une requête_complète HTTP/1.0 et reçoit une réponse ne commençant pas par une ligne_état, il devra conclure qu'il s'agit d'une réponse_simple et l'interprétera en conséquence. Notez qu'une réponse ne contient que le corps_entité, et se termine par la fermeture de la connexion par le serveur.
Ligne_état = Version_HTTP SP Code_état SP Raison CRLFLa ligne d'état débutant toujours par ce numéro de version et le code de réponse:
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
(ex., "HTTP/1.0 200 "), la seule présence de cette expression est suffisante pour différentier une réponse_simple d'une réponse_complète émise en retour d'une requête sousle protocole HTTP/1.0. Le format de réponse_simple n'interdit cependant pas qu'une telle expression soit placée en tête du corps d'entité, provoquant ainsi une erreur d'interprétation de la part du récepteur. Dans la pratique, la plupart des serveurs HTTP/0.9 ne peuvent générer que des réponses de type "text/html", ce qui en principe, élimine le risque d'une telle confusion.
Le premier chiffre du code d'état indique la classe générale de la réponse. Les deux derniers n'ont pas de rôle de classification particulier. Le premier chiffre peut prendre 5 valeurs:
| Code | Classe< 1000 /font> | Usage |
| 1xx | Information | Non utilisé, pour usage futur |
| 2xx | Succès | L'action a été correctement reçue, interprétée, et exécutée. |
| 3xx | Redirection | Une décision supplémentaire doit être prise pour terminer la requête |
| 4xx | Erreur Client | La requête présente une erreur de forme et ne peut être satisfaite |
| 5xx | Erreur Serveur | La requête est valide, mais le serveur ne peut la satisfaire |
Les valeurs actuellement reconnues sous HTTP/1.0, et les phrases types d'explicitation associées, sont présentées ci-dessous. Ces phrases ne sont que recommandées -- elles peuvent être remplacées par des variations locales sans affecter le protocole. Ces codes sont intégralement listés en section 9.
Code_état = "200" ; OK OK | "201" ; Created Créé | "202" ; Accepted Accepté | "204" ; No Content Pas de contenu | "301" ; Moved Permanently Changement d'adresse définitif | "302" ; Moved Temporarily Changement temporaire | "304" ; Not Modified Non modifié | "400" ; Bad Request Requête incorrecte | "401" ; Unauthorized Non autorisé | "403" ; Forbidden Interdit | "404" ; Not 1000 Found Non trouvé | "500" ; Internal Server Error Erreur interne serveur | "501" ; Not Implemented Non implémenté | "502" ; Bad Gateway Erreur de routeur | "503" ; Service Unavailable Indisponible | autres_codes
autres_codes = 3DIGIT Raison = *[TEXT, sauf CR, LF]La liste des codes HTTP est extensible, mais seuls les codes ci-dessus sont utilisés dans la pratique courante. Les applications HTTP n'ont pas nécessairement à connaître la signification de tous les codes enregistrés, bien que ce soit souhaitable pour des raisons évidentes. Au minimum, les applications devront pouvoir comprendre le premier chiffre de ce code, et comprendre tout numéro de réponse non identifié comme le numéro x00 de la classe, indiquant ainsi la définition générique de la classe. Aucune réponse non identifiée ne peut être enregistrée en cache.
Par exemple, si un code "inconnu" 431 est reçu par le client, celui-ci peut interpréter sans doute possible qu'un problème est survenu, et peut réagir comme s'il avait reçu le code 400. Dans de tels cas, il est fortement conseillé que l'application reporte le corps de l'entité de réponse, dans la mesure où il y a de fortes chances que celui-ci contienne des informations "en clair" sur la nature de l'erreur.
Response-Header = Location ; Section 10.11 | Server ; Section 10.14 | WWW-Authentificate ; Section 10.16Des nouveaux noms de champs d'en-tête_réponse ne peuvent être introduits que dans le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou champs expérimentaux peuvent utiliser la sémantique de champs d'en-tête_réponse, à partir du moment ou les deux extrémités de la communication sont d'accord pour le faire. Tout champ non reconnu sera considéré comme un champ d'en-tête_entité.
7. Entités
Les messagesde requête et de réponses contiennent généralement une entité dans laquelle est incluse des éléments de requête ou de réponse. Une entité est définie par une en-tête d'entité, et dans la plupart des cas par un corps d'entité. Dans ce qui suit "l'émetteur" et le "récepteur" se réfèrent tantôt au client, tantôt au serveur, suivant l'agent qui émet le message.
En-tête_entité = Allow ; Section 10.1 | Content-Encoding ; Section 10.3 | Content-Length ; Section 10.4 | Content-Type ; Section 10.5 | Expires ; Section 10.7 | Last-Modified ; Section 10.10 | champ_en-tête champ_en-tête = en-tête_HTTPLe mécanisme d'extension de l'en-tête d'entité permet la définition d'autres champs, ceux-ci n'étant pas obligatoirement reconnus par le récepteur. Tout champ non identifié doit être ignoré, ou, dans le cas d'un proxy, retransmis tel quel.
Corps_entité = *OCTETUn corps d'entité n'apparaît dans un message de requête que dans la mesure ou le type de requête le demande. La présence de ce corps est signalée par la présence d'un champ Content-Length dans les champs d'en-tête de la requête. Les requêtes HTTP/1.0 contenant un corps doivent nécessairement présenter un champ d'en-tête Content-Length valide.
Dans les réponses, la présence d'un corps d'entité est fonction à la fois de la nature de la requête préalable, et du code d'état renvoyé. Toute réponse à une requête de type HEAD ne peut contenir de corps d'entité, même si les champs d'en-tête présents prétendent le contraire. Les codes d'état 1xx (informations), 204 (pas de contenu), et 304 (non modifié) supposent implicitement ou explicitement l'absence de tout corps d'entité. Toutes les autres réponses peuvent contenir un corps d'entité, ou à défaut, un champ Content-Length spécifié à zéro (0).
Corps_entité = Content-Encoding( Content-Type( données ) )Le Content-Type le type de média des données de la ressource. Un champ Content-Encoding peut être utilisé pour spécifier un traitement ou encodage supplémentaire effectué sur le type de données, souvent dans un but de compression, et apparaissant comme une propriété de la ressource. Par défaut, aucun encodage n'est appliqué aux données (la ressource est enregistrée et directement accessible sous forme utilisable).
Tout message HTTP/1.0 contenant un corps d'entité doit au moins faire apparaître le champ Content-Type définissant la nature des données de la ressource. Si et seulement si aucun type de média n'est défini (uniquement dans le cas où le champ Content-Type n'existe pas, comme dans le cas de réponses simples), le récepteur pourra être amené à déterminer ce type par lui-même, en inspectant le contenu des données, ou en se basant sur l'extension utilisée dans l'URL définissant l'accès à la ressource. Si le média demeure non identifiable, le type par défaut "application/octet-stream".
Cette dernière méthode ne peut être utilisée pour marquer la fin d'une requête, car la possibilité doit être laissée au serveur d'envoyer une réponse. C'est pourquoi le protocole HTTP/1.0 précise que toute requête contenant un corps d'entité doit mentionner sa longueur dans un champ d'en-tête Content-Length valide. Si tet est le cas, et que ce champ n'existe pas dans le message, et dans la mesure où le serveur ne peut calculer ou déterminer la longueur de ce corps, ce dernier répondra par un message de code 400 (erreur client).
La sémantique de la méthode GET introduit une notion conditionnelle si la requête inclue le champ d'en-tête If-Modified-Since. Une méthode GET conditionnelle ne récupère la ressource que si celle-ci a été modifiée depuis la date associée au champ If-Modified-Since, comme indiqué en Section 10.9. La méthode GET conditionnelle est utilisée pour réduire la charge du réseau en permettant à des ressources en cache d'être rafraîchies sans multiplier les requêtes ou transférer des données inutiles.
Il n'existe pas de méthode HEAD conditionnelle comme pour la méthode GET. Si un champ d'en-tête If-Modified-Since est présent dans une requête HEAD, il devra être ignoré.
La résolution d'une méthode POST ne signifie pas forcément la création d'une entité sur le serveur origine, ni une possibilité d'accès futur à ces informations. En d'autres termes, le résultat d'un POST n'est pas nécessairement une ressource associable à une URI. Dans ce cas, une réponse de code 200 (OK) ou 204 (pas de contenu) est la réponse la plus appropriée, suivant que la réponse contient ou non une entité pour décrire le résultat.
Si une ressource a été créée sur le serveur origine, la réponse sera du type 201 (créé) et contiendra l'entité (de préférence du type "text/html") qui décrira les informations sur la requête et contiendra une référence sur la nouvelle ressource.
Un champ Content-Length valide est demandé dans toute requête POST HTTP/1.0. Un serveur HTTP/1.0 répondra par un message 400 (requête incorrecte) s'il ne peut déterminer la longueur du contenu du message.
Les applications ne peuvent enregistrer en cache les réponses à des requêtes POST dans la mesure où il n'est absolument pas certain qu'une réponse ultérieure émise dans les mêmes conditions produise le même résultat.
HTTP/1.0 ne définit actuellement aucun de ces codes, lesquels ne constituent pas une réponse valide à des requêtes HTTP/1.0. Il restent cependant exploitables à titre expérimental, dépassant le contexte de la présente spécification.
GET
La nouvelle ressource créée est accessible par l'URI(s) renvoyée dans l'entité de la réponse. La ressource doit être créée avant que ce code ne soit envoyé. Si la création ne peut pas être opérée immédiatement, le serveur devra indiquer dans la réponse quand la ressource deviendra disponible ou retourner un message de type 202 (acceptée).
Actuellement, seule la méthode POST peut conduire à la création d'une ressource.
La réponse 202 est intentionnellement non bloquante. Son rôle est de permettre au serveur d'accepter une requête d'un autre processus (par exemple d'un automate se déclenchant à dates fixes) sans que la connexion avec le client ne reste active pendant le déroulement du traitement. L'entité retournée par la réponse rendra compte de la requête, et devra fournir un pointeur sur un composant d'information (état courant du traitement), ou donner une estimation de la date de conclusion probable définitive.
Un utilisateur recevant ce message n'aura pas à rafraîchir son affichage, et maintiendra celui qui aura conduit à l'émission de la requête. Cette réponse a été instaurée pour permettre à un utilisateur de dérouler des scripts ou autres actions sans modifier l'affichage en cours. La réponse peut cependant contenir des métainformations dans des champs d'en-tête, concernant le document affiché dans la fenêtre active de l'utilisateur.
Il signifie en principe que la ressource visée est disponible en un ou plusieurs autres points du réseau. Sauf dans le cas d'une requête de type HEAD, la réponse doit contenir une entité dans laquelle sont listées les caractéristiques et localisations de la ressource demandée, à charge de l'utilisateur de choisir laquelle est la plus appropriée. Si le serveur affiche une préférence de choix, il doit en inscrire l'URL dans un champ Location; Certains clients utiliseront ce champ pour activer une redirection automatique.
La nouvelle URL sera indiquée dans le champ d'en-tête Location de la réponse. Sauf dans le cas d'une requête de type HEAD, le corps d'entité de la réponse contiendra une note succincte avec un hyperlien vers la nouvelle URL.
Si le code d'état 301 est reçu en réponse à une requête POST, le client ne pourra rediriger automatiquement la requête sans en avoir demandé confirmation à l'utilisateur. En effet, il n'est pas dit que les conditions ayant été à l'origine de la requête n'aient pas changé.
La nouvelle URL temporaire doit être spécifiée en réponse dans un champ Location. Sauf dans le cas d'une requête de type HEAD, le corps d'entité de la réponse contiendra une note succincte avec un hyperlien vers la nouvelle URI.
Si le code d'état 302 est reçu en réponse à une requête POST, le client ne pourra rediriger automatiquement la requête sans en avoir demandé confirmation à l'utilisateur. En effet, il n'est pas dit que les conditions ayant été à l'origine de la requête n'aient pas changé.
Le client n'est pas sensé émettre de nouveau cette requête sans l'avoir corrigée au préalable.
Une démarche d'authentification n'y fera rien et cette requête ne doit pas être renouvelée. Si la méthode invoquée est différente de HEAD et le serveur souhaite rendre public la raison pour laquelle il refuse le traitement, il le fera dans l'entité liée à cette réponse. Ce code d'état est souvent utilisé lorsque le serveur ne souhaite pas s'étendre sur les raisons pour lesquelles il refuse un accès, ou parce que c'est la seule réponse qui convienne.
Allow = "Allow" ":" 1#méthodeExemple:
Allow: GET, HEAD
Ce champ ne pourra prévenir le client de tenter d'appliquer d'autres méthodes que celles acceptées par la ressource. Il n'est là qu'à titre informatif. Les méthodes acceptées sont définies par le serveur origine pour chaque requête reçue.
Un proxy ne doit pas modifier le champ d'en-tête Allow même s'il ne connaît pas toutes les méthodes spécifiées, car l'utilisateur peut avoir à sa disposition d'autres moyens de communiquer avec le serveur origine.
Le champ d'en-tête Allow n'indique pas si les méthodes indiquées sont implémentées par le serveur (seulement si elles sont à priori acceptables par la ressource).
Authorization = "Authorization" ":" données_identificationL'authentification de connexions HTTP est décrite en Section 11. Si la requête est authentifiée, et un domaine d'accès attribué, les mêmes paramètres d'authentification seront reconnus pour toute autre ressource appartenant à ce domaine.
Les réponses à une requête contenant des données d'identification ne peut être enregistrée en cache.
Content-Encoding = "Content-Encoding" ":" type_codageLes valeurs actuellement reconnues sont décrites en Section 3.5. Exemple:
Content-Encoding: x-gzip
Le type d'encodage est une caractéristique de la ressource identifiée par l'URI-visée. Typiquement, la ressource est enregistrée encodée, et le décodage ne se fera qu'à l'utilisation finale de celle-ci.
Content-Length = "Content-Length" ":" 1*DIGITExemple:
Content-Length: 3495
Les applications utiliseront ce champ pour transmettre la taille de l'entité jointe, indépendamment du type de média de l'entité. Un champ Content-Length avec une valeur valide est obligatoire dans toute requête HTTP/1.0 contenant un corps d'entité.
Toute valeur numérique supérieure ou égale à zéro est valide. La section 7.2.2 décrit comment évaluer la taille d'un corps d'entité de réponse, si ce champ est omis.
Content-Type = "Content-Type" ":" type_de_médiaLes types de média sont définis en Section 3.6. Exemple:
Content-Type: text/html
Une présentation d'autres méthodes pour identifier le type de média est donnée en Section 7.2.1.
Date = "Date" ":" date_HTTPExemple:
Date: Tue, 15 Nov 1994 08:12:31 GMT
Si un message est reçu en direct du client (pour les requêtes) ou du serveur origine (pour les réponses), on peut affirmer qu'il s'agit aussi de la date d'arrivée au récepteur. En outre, dans la mesure où la date - délivrée par l'origine - est un paramètre important pour tout ce qui touche à la gestion des caches, il est vivement conseillé que les serveurs origine renseignent systématiquement ce champ à la constitution de tout message. Les clients peuvent se limiter à l'envoi d'une date lorsque la requête contient un corps d'entité, comme dans le cas d'une requête POST, et encore cette pratique n'est pas obligatoire. Un message reçu et non daté se verra assigner une date par le récepteur si ce message doit être enregistré en cache ou rerouté via un protocole qui exige une Date.
En théorie, la date doit représenter l'instant juste avant l'émission. En pratique, c'est à la constitution du message que la date est inscrite.
Expires = "Expires" ":" date-HTTPExemple:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Si la date indiquée dans ce champ est égale ou antérieure à la date mentionnée dans le champ date du même en-tête, le serveur ou routeur, ou application ne devra pas enregistrer cette ressource dans son cache. Si la ressource est dynamique par nature, comme c'est le cas pour des résultats de processus générateurs de données, les entités produites se verront attribuées un champ Expires renseigné d'une façon correspondante à ce "dynamisme".
Le champ Expires ne peut pas être utilisé pour forcer un client à rafraîchir ou recharger une ressource. Sa sémantique ne concerne que les mécanismes de gestion du cache, lesquels n'utilisent ce paramètre que pour savoir si le serveur peut encore utiliser l'instance cachée lorsqu'une requête destinée à ce document est à nouveau présentée.
Les clients HTTP disposent souvent d'un mécanisme d'historique, implémenté sous forme d'un bouton "Back" et/ou d'une liste de "documents précédents", utilisés pour recharger un document précédemment chargé pendant la session courante. Par défaut, le champ Expires n'influe pas sur ces mécanismes. Si l'entité est stockée par un tel mécanisme, elle pourra être rechargée même si sa date d'expiration est passée, sauf si l'utilisateur a explicitement configuré le client pour régénérer les documents ayant expiré.
From = "From" ":" adresse_mailExemple:
From: webmaster@w3.org
Ce champ est exploité à des fins de statistiques, et pour identifier la source de requêtes non valides ou non autorisées. Il ne doit cependant pas être utilisé dans un contexte de sécurisation d'accès. Il doit être interprété comme l'identification de la personne ayant formulé la requête, et qui accepte la responsabilité de la méthode employée. En particulier, les robots devront renseigner ce champ afin que son responsable d'exploitation puisse être contacté en cas de dysfonctionnement à l'autre extrémité.
L'adresse e-mail Internet dans ce champ doit être séparé de la mention du nom de l'ordinateur d'où a été émis la requête. Par exemple, lorsque la requête a transité par l'intermédiaire d'un proxy, l'adresse de la source originale doit y être mentionnée.
If-Modified-Since = "If-Modified-Since" ":" date_HTTPExemple:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Une méthode GET conditionnelle requiert la transmission d'une ressource uniquement si celle-ci a été modifiée après la date indiquée dans le champ If-Modified-Since. L'algorithme utilisé pour déterminer cette condition prend en compte les cas suivants:
Last-Modified = "Last-Modified" ":" date_HTTPExemple:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
La signification exacte de cette information dépend de l'implémentation de l'émetteur et de la ressource à laquelle elle s'applique. Pour des fichiers, il s'agira de la date de dernière modification donnée par le gestionnaire de fichier du système d'exploitation. Pour des entités incluant des parties générées dynamiquement, cette date peut être plus récente que les dates de dernière modification de chacune de ses parties. Pour des routeurs vers des bases de données, il pourra s'agir de la dernière étiquette de date associée à l'enregistrement. Pour des objets virtuels, il pourra s'agir de la dernière date à laquelle l'état interne de l'objet a changé.
Un serveur origine ne doit pas envoyer de date Last-Modified postérieure à la date d'émission du message (date locale du serveur). Dans une telle éventualité, où la date à inscrire pointerait vers un instant futur, c'est la date d'émission du message qui doit être inscrite.
Location = "Location" ":" URI_absolueExemple:
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
Pragma = "Pragma" ":" 1#directive_pragma directive_pragma = "no-cache" | pragma pragma = nom_de_pragma [ "=" mot ]Lorsque la directive "no-cache" est présente dans un message de requête, les applications doivent répercuter la requête jusqu'au serveur origine, même si elles disposent d'une copie de la ressource en cache. Ceci permet au client de forcer la récupération d'une "première copie" d'une ressource. Ceci permet de plus de demander au client une remise à jour de copies cachées, dans le cas où ces copies se sont avérées défectueuses, ou obsolètes.
Les directives Pragma doivent être réémises par les routeurs ou proxies, quelle que soit leur signification à l'égard des applications, dans la mesure où ces directives concernent toutes les applications de la chaîne de requête/réponse. Il n'est pas possible de définir un pragma ne concernant qu'un intermédiaire donné dans la chaîne; Cependant, toute directive non reconnue par l'un des récepteurs sera ignorée. <h3> 10.13 RefererLe champ d'en-tête Referer (requête) permet au client d'indiquer, à l'usage du serveur, l'adresse (URI) de la ressource dans laquelle l'URI-visée a été trouvée. Ceci permet au serveur de générer et entretenir des listes de "rétro-liens" destinées à renseigner les clients futurs sur des "sites intéressants", ou à but d'archivage et d'analyse, optimisation de cache, etc. Il permet aussi l'analyse de liens obsolètes ou de type incorrect à but de maintenance. Le champ Referer ne doit pas être inscrit si la source de l'URI-visée provient d'une entité n'ayant pas d'URI propre, comme l'entrée de l'adresse via un clavier.
Referer = "Referer" ":" ( URI_absolue | URI_relative )Exemple:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Si une URI partielle est donnée, elle se référera relativement à l'URI-visée. L'URI donnée en référence ne doit pas inclure de fragment.
Server = "Server" ":" 1*( produit | commentaire )Exemple:
Server: CERN/3.0 libwww/2.17
Si la réponse est transmise via un proxy, ce dernier ne doit pas ajouter ses propres commentaires à la liste.
User-Agent = "User-Agent" ":" 1*( produit | commentaires )Exemple:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
WWW-Authenticate = "WWW-Authenticate" ":" 1#modèleLe processus d'identification et d'authentification d'accès HTTP est décrit en Section 11. Les applications utilisatrices doivent interpréter avec circonspection la valeur d'un champ WWW-Authenticate lorsqu'il présente plus d'un modèle d'authentification, ou si plusieurs champs WWW-Authenticate apparaissent dans l'en-tête, le contenu d'un modèle pouvant lui même apparaître comme une liste de paramètres séparés par une virgule.
Scheme-auth = nom_de_scheme param-auth = nom_param "=" chaîne entre guillemetsLe message de réponse 401 (non autorisé) est utilisé par un serveur origine pour soumettre le "modèle" d'authentification à un client. Cette réponse doit comporter un champ d'en-tête WWW-Authenticate proposant au moins un modèle valide pour la ressource à atteindre.
Modèle = scheme-auth 1*SP domaine_valide *( "," pa 1000 ram_auth ) domaine_valide = "realm" "=" espace_domaine espace-domaine = chaîne entre guillemetsL'attribut de domaine (indépendant de la casse) est requis dans tous les schèmes d'authentification qui soumettent un modèle. L'espace de domaine (indépendant de la casse), combiné à l'URL canonique du serveur origine, définit l'espace protégé. Cette technique permet de partitionner un serveur protégé en plusieurs sous ensembles, protégés individuellement, chacun avec leur propre modèle et leurs propres paramètres d'autorisation liées ou non à une base de donnée d'authentification. Le domaine accessible est exprimé sous forme de chaîne de caractères, en général donnée par le serveur origine, avec éventuellement une sémantique supplémentaire dépendant du modèle d'authentification.
Un utilisateur désireux de s'authentifier auprès d'un serveur - en général, mais pas nécessairement, après avoir reçu une réponse 401-peut le faire en spécifiant un champ Authorization dans l'en-tête de sa requête. La valeur dans le champ Authorization consiste contient l'accréditif nécessaire à l'accès au domaine autorisé pour la ressource visée.
accréditif = accréditif_de_base | ( modèle_authentification#paramètres )Le domaine accessible par un utilisateur utilisant cet accréditif est déterminé par les données de protection du serveur. Si une requête précédente à abouti à une autorisation d'accès, le même accréditif donnera accès au même domaine accessible durant un temps déterminé par le le modèle d'authentification, ses paramètres, et/ou les préférences utilisateur. Sauf mention explicite dans le modèle, un espace protégé ne peut sortir du cadre du serveur qui le gère.
Si le serveur refuse l'accès à une requête, il délivrera en retour une réponse 403 (accès interdit).
Le protocole HTTP n'exclut pas l'utilisation de schémas de protection additionnels, venant compléter ou remplacer le paradigme "modèle-accréditif". D'autres mécanismes, tels que le cryptage au niveau "transport" ou l'encapsulation de messages, peuvent être utilisés avec des champs d'en-tête additionnels véhiculant les informations d'authentification. Ces mécanismes ne sont toutefois pas décrits dans cette spécification.
Les proxies doivent être complètement transparents vis à vis du mécanisme d'authentification. C'est à dire qu'ils doivent retransmettre les champs WWW-Authenticate et Authorization tels que, et ne doivent pas enregistrer une réponse à un message contenant le champ Authorization dans leur cache. HTTP/1.0 ne fournit aucun moyen à un client de s'identifier vis à vis d'un proxy.
Sur toute réception d'une requête non autorisée visant une URI dans l'espace protégé, le serveur doit renvoyer une demande d'identification de forme:
WWW-Authenticate: Basic realm="WallyWorld"
dans laquelle "WallyWorld" est le nom symbolique de l'espace contenant l'URI-visée, attribué par le serveur.
Pour obtenir l'autorisation d'accès, le client enverra l'user-ID et le mot de passe, séparatés par un "deux-points" (":"), le tout encodé en base64 [5].
Accréditif_de_base = "Basic" SP cookie-basique cookie-basique = ["userID-mot_de_passe" encodé base64 [5], limité à 76 char/line] userID-mot_de_passe = [ nom_ID ] ":" *TEXTSi le client voulait utiliser l'user-ID "Aladdin" et le mot de passe "open sesame", il spécifierait le champ ainsi:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Le modèle de base ci-défini est une méthode non sécurisée de filtrage d'accès à des ressources données sur un serveur HTTP. Il suppose en effet que la connexion entre l'utilisateur et le serveur est un lien digne de confiance. Ceci n'est pas le cas sur des réseaux ouverts, et ce modèle doit être utilisé en connaissance de cause. Malgré cette faiblesse, les clients devront implémenter ce modèle afin de pouvoir communiquer avec les serveurs qui l'utilisent.
En particulier, il a été établi par convention que les méthodes GET et HEAD ne peuvent signifier autre chose qu'une demande de récupération de ressource. Ces méthodes peuvent être considérées comme "sûres". Ceci laisse la possibilité aux clients d'implémenter d'autres méthodes (ex. POST) sous une forme spécifique, mais toujours à condition que l'utilisateur puisse être averti qu'une action peu sûre ou potentiellement non conforme est requise.
Naturellement, il n'est pas possible de garantir que le serveur n'aura pas "d'effets de bord" lorsqu'il traite une requête GET; en fait, certaines ressources dynamiques tirent avantage de cette possibilité. La seule distinction de taille est que l'utilisateur qui émet une requête sûre de type GET n'a pas "dans l'intention" de provoquer ces effets de bord. Il ne peut donc en être tenu pour responsable.
Révéler la version exacte du logiciel serveur peut rendre celui-ci vulnérable aux attaques si le logiciel est réputé avoir des faiblesses en termes de sécurité. Le renseignement du champ Server doit de ce fait rester optionnel, et ne doit pas forcément être systématique.
Le champ Referer autorise 1000 l'étude d'un certain nombre d'informations à propos de la requête et permet de "remonter" une chaîne de liens. Bien que cette fonction soit très utile, il est possible néanmoins d'en abuser si les informations sur l'utilisateur ne sont pas dissociées de celles contenues dans le Referer. Même lorsque ces informations "personnelles" sont enlevées, le champ Referer peut parfois indiquer l'URI d'un document privé dont la publication n'est pas souhaitable.
L'information émise dans le champ From peut entrer en conflit avec la défense des droits privés, ou peut diminuer le degré de sécurité du serveur dans lequel la ressource est émise de ce fait, toute implémentation devra laisser la possibilité à l'utilisateur d'émettre, ne pas émettre, ou modifier les données dans ce champ. L'utilisateur devra être en mesure de configurer une valeur "par défaut" ou une "préférence utilisateur" pour les données dans ce champ.
Nous suggérons, mais n'imposons pas, qu'un interrupteur graphique soit implémenté sur l'interface utilisateur pour permettre ou interdire l'envoi des informations From et Referer.
Le HTTP protocole a évolué considérablement ces quatre dernières années. Il a bénéficié de la réflexion d'une large et dynamique communauté de développeurs - les nombreuses personnes qui ont participé aux groupes de travail du WWW - laquelle a été largement responsable du développement fulgurant d'HTTP et du World-Wide Web en général. Nous décernons à Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Håkon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, et Marc VanHeyningen une mention d'honneur pour la reconnaissance de leur efforts dans la définition des toutes premières spécifications ayant servi de base à la présente.
Paul Hoffman aura contribué aux sections informatives de ce document et aux Appendices C et D.
Ce document a bénéficié des nombreuses remarques et objections de la grande majorité des participants au HTTP-WG. Outre les personnes déjà mentionnées, les personnes suivantes ont collaboré à l'achèvement de cette spécification:
| Gary Adams | Harald Tveit Alvestrand | Keith Ball | Brian Behlendorf |
| Paul Burchard | Maurizio Codogno | Mike Cowlishaw | Roman Czyborra |
| Michael A. Dolan | John Franks | Jim Gettys | Marc Hedlund |
| Koen Holtman | Alex Hopmann | Bob Jernigan | Shel Kaphan |
| Martijn Koster | Dave Kristol | Daniel LaLiberte | Paul Leach |
| Albert Lunde | John C. Mallery | Larry Masinter | Mitra |
| Jeffrey Mogul | Gavin Nicol | Bill Perry | Jeffrey Perry |
| Owen Rees | Luigi Rizzo | David Robinson | Marc Salomon |
| Rich Salz | Jim Seidman | Chuck Shotton | Eric W. Sink |
| Simon E. Spero | Robert S. Thau | François Yergeau | Mary Ellen Zurko |
| Jean-Philippe Martin-Flatin |
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Roy T. Fielding
Department of Information and
Computer Science
University of California
Irvine, CA 92717-3425, U.S.A.
Fax: +1 (714) 824-4056
EMail:
fielding@ics.uci.edu
Henrik Frystyk
Nielsen
W3
Consortium
MIT
Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Media Type : 1000 message Media subtype : http Paramètres obligatoires: none Paramètres optionnels: version, msgtype
| version: | version du protocole HTTP utilisé pour le message courant (e.g., "1.0"). Si ce paramètre est absent, la version peut être déduite par analyse de la première ligne du corps. |
| msgtype: | Le type de message -- "request" ou "response". Si ce paramètre est absent, la version peut être déduite par analyse de la première ligne du corps. |
| Considérations d'encodage: | seulement "7bits", "8bits", ou "binary" permis |
| Considérations en termes de sécurité: | aucune |
Les clients devront faire preuve de tolérance dans l'interprétation de la ligne d'état. Les serveurs devront à leur tour se montrer ouverts dans l'interprétation de la ligne de Requête. En particulier, ils devront accepter tout nombre d'espaces ou de tabulations entre les champs, même lorsqu'un espace simple est requis.
La fin de ligne dans les en-têtes HTTP est marquée par la séquence CRLF. Cependant, nous conseillons aux applications interprétant de telles en-têtes de reconnaître une fin de ligne sur LF simple en ignorant le CR de tête.
A cette heure, nous espérons une révision de la RFC 1521. Cetterévision pourrait intégré quelques unes des pratiques utilisées par HTTP/1.0 mais ne faisant pas partie de la RFC 1521.
Cet appendice décrit les points spécifiques pour lesquels HTTP et la RFC 1521 diffèrent. Les proxies et routeurs dirigeant des messages HTTP vers un environnement MIME strict devront connaître ces différences et propose une conversion appropriée si nécessaire. A l'inverse Les proxies et routeurs accédant à un environnement HTTP à partir d'un environnement MIME strict, devront de même se charger de la conversion, et donc connaître ces différences.
La RFC 1521 impose que le contenu d'un message dont le Content-Type est "text" représente les fins de ligne par la séquence CRLF et interdise l'usage de CR ou de LF en dehors de ce contexte de fin de ligne. HTTP permet l'usage de séquences CRLF, de CR et LF seuls pour marquer la fin de ligne du texte dans le corps du document envoyé sous HTTP.
Là où c'est possible, un proxy ou un routeur du HTTP vers un environnement strictement RFC 1521 devra traduire toutes les fins de ligne du texte contenu dans ces documents concernés par la Section 3.6.1 dans ce document en forme canonique selon la RFC 1521: une séquence CRLF. Notez, cependant, que cette règle peut se compliquer dans le cas où un champ Content-Encoding est présent et par le fait qu'HTTP permettent l'utilisation de tables de caractères tant que le caractère 13 et 10 continuent à représenter les équivalents de CR et LF (comme c'est le cas pour certaines tables utilisant plusieurs octets par caractère).
Les proxies et routeurs depuis HTTP vers un protocole compatible MIME ont la responsabilité de s'assurer que le message envoyé est au format correct pour un transfert en toute sécurité sous ce protocole, cette sécurité étant naturellement limitée aux limitations propres du protocole utilisé. Un tel proxy ou routeur devra ajouter un Content-Transfer-Encoding approprié, de façon à présenter les données conformément aux attentes de ce protocole.
La méthode PUT demande à ce que l'entité jointe soit enregistrée par le serveur sous l'URI-visée. Si cette URI pointe vers une ressource déjà existante, l'entité jointe sera considérée comme une nouvelle version de celle jusqu'alors présente sur le serveur origine. Si l'URI-visée pointe sur une ressource inexistante, et à la condition que cette URI puisse être définie en tant que nouvelle ressource du serveur, ce dernier créera une nouvelle ressource sous cette URI.
La différence fondamentale entre les méthodes POST et PUT réside dans la signification donnée à l'URI-visée. Celle-ci, pour une méthode POST désigne la ressource "active" à laquelle l'entité doit être confiée dans le but d'un traitement. Cette ressource peut être un programme, un routeur ou un autre protocole, ou encore une entité acceptant des annotations. Par contre, L'URI précisée dans une méthode PUT nomme l'entité incluse dans la requête - Le client sait parfaitement de quelle URI il s'agit et le serveur n'applique la méthode à aucune autre ressource.
D.1.2 DELETE
La méthode DELETE demande au serveur de supprimer la ressource pointée par l'URI-visée.
D.1.3 LINK
La méthode LINK établit une ou plusieurs liaisons entre la ressource existante définie par l'URI-visée et d'autres ressources.
D.1.4 UNLINK
A contrario, cette méthode supprime des liaisons entre la ressource définie par l'URI-visée, et d'autres ressources qui lui sont liées.
Le champ d'en-tête Accept (requête) peut être utilisé pour définir une liste de types de média acceptés en réponse à la requête. L'astérisque "*" est utilisée pour grouper des types de média par classe, "*/*" indiquant tous les types de média, et "type/*" indiquant tous les sous-types du type "type". La gamme de types signalée par le client sert essentiellement à limiter les documents à des types acceptables par le client dans le contexte de la requête formulée.
D.2.2 Accept-Charset
Le champ d'en-tête Accept-Charset (requête) peut être utilisé pour former une liste de tables de caractères préférentielles, autres que les tables US-ASCII et ISO-8859-1 utilisées par défaut. Ce champ permet à un client de signaler à un serveur qu'il sait accepter d'autres représentations de texte que les représentations par défaut, et est donc en mesure d'exploiter des documents encodés avec ces tables, si le serveur sait les transmettre.
D.2.3 Accept-Encoding
Le champ d'en-tête Accept-Encoding (requête) est similaire au champ Accept, mais restreint la gamme de valeurs Content-Coding attendues dans une réponse.
D.2.4 Accept-Language Le champ d'en-tête Accept-Encoding (requête) est similaire au champ Accept, mais restreint la gamme de langues attendues dans une réponse.
D.2.5 Content-Language
Le champ d'en-tête Content-Language (entité) décrit la ou les langues naturelles des destinataires potentiels du corps d'entité. Notez que ceci n'a aucun lien avec les langues utilisées dans l'ensemble de l'entité.
D.2.6 Link
Le champ d'en-tête Link (entité) permet de décrire les liaisons entre l'entité jointe et d'autres ressources. Une entité peut se voir attribuer plusieurs valeurs pour le champ Link. Un champ Link, au niveau métainformation, indique typiquement des relations du type dépendance hiérarchique ou des chemins d'accès.
D.2.7 MIME-Version
Les messages HTTP peuvent inclure un champ unique d'en-tête générale indiquant quelle version du protocole MIME a été employé pour construire le message. L'utilisation de ce champ MIME-Version, tel que décrit par la RFC 1521 [5], peut indiquer si le message est compatible MIME. Malheureusement, certaines premières implémentations de serveurs HTTP/1.0 &e 578 acute;mettent ce champ sans réserve. Il est conseillé de l'ignorer.
D.2.8 Retry-After
Le champ d'en-tête Retry-After (réponse) peut être utilisé dans une réponse 503 (service indisponible) dans le but d'indiquer pendant combien de temps (estimé) le service restera indisponible aux requêtes du client. La valeur de ce champ peut être une date HTTP ou un nombre entier de secondes (en décimal) à partir de l'heure de la réponse.
D.2.9 Title
Le champ d'en-tête Title est purement informatif et donne le titre de l'entité.
D.2.10 URI
Le champ d'en-tête URI (entité) peut contenir toute ou partie des Uniform Resource Identifiers (Section 3.2) par laquelle la ressource définie par l'URI-visée peut être identifiée. Aucune garantie n'est cependant donnée que la ressource soit effectivement accessible par l'une des URI spécifiées.0