HTTP PDF

Network Working Group T.
Berners-Lee, MIT/LCS
Request for Comments: 1945 R. Fielding, UC Irvine
Category: Informational H. Frystyk, MIT/LCS
May 1996
French translation by V.G. FREMAUX / Ecole Internationale des Sciences du Traitement

de l'Information
(International Graduate School of Computer Sciences)
HyperText Transfer Protocol

HTTP/1.0
INTERNET
STANDARDS & OFFICIAL DOCUMENTS
Standard 8
Informational 4
Proposal 8
RFC 1945 - HTTP 1.0 / FR / VE:DOC OR:05/96 - FR:10/97
Note du Traducteur :
Le texte suivant est la traduction intgrale de la spcification HTTP 1.0, telle qu'dite par
les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document
a valeur informative, selon la procdure courante d'enregistrement des documents au sein
du W3C. Il n'a de ce fait pas valeur de "norme", et, s'il peut tre considr comme
document de rfrence, il ne peut par contre octroyer une lgitimit quelconque un
quelconque dveloppement, ni servir de preuve ni de garant d'une conformit quelle
qu'elle soit.
Statut de ce mmo
Ce mmo est une information destination de la communaut Internet. Il ne peut tre
considr comme une spcification officielle d'aucun protocole Internet. Sa distribution
n'est pas limite.
Note IESG:
L'IESG espre que ce document sera rapidement remplac par une norme officielle.
Contexte
L'Hypertext Transfer Protocol (HTTP) est un protocole de niveau application
suffisamment lger et rapide, pour la transmission de documents distribus et multimdia
travers un systme d'information multi-utilisateurs. Il s'agit d'un protocole gnrique,
orient objet, pouvant tre utilis pour de nombreuses tches, dans les serveurs de nom
et la gestion d'objets distribus par l'extension de ses mthodes de requte
(commandes). Une caractristique d'HTTP est son typage des reprsentations de
donnes, permettant la mise en oeuvre de systmes indpendants des donnes y tant
transfres.
HTTP a t utilis l'initiative du World-Wide Web depuis 1990. Cette spcification
dcrit le protocole de base rfrenc sous l'appellation "HTTP/1.0".
EISTI / Fremaux 2 W3C / Berners Lee

Table des Matires
1. Introduction .............................................................................................................................6
1.1 Objectif ..............................................................................................................................6
1.2 Terminologie ......................................................................................................................6
1.3 Fonctionnement global........................................................................................................8
1.4 HTTP et MIME .................................................................................................................9
2. Conventions de notation et Grammaire gnrique ...................................................................10
2.1 BNF tendue ....................................................................................................................10
2.2 Rgles de base..................................................................................................................11
3. Paramtres du protocole.........................................................................................................14
3.1 Numro de Version ..........................................................................................................14
3.2 Uniform Resource Identifiers............................................................................................15
3.2.1 General Syntax ..........................................................................................................15
3.2.2 URL http ...................................................................................................................16
3.3 Formats de temps et de date .............................................................................................16
3.4 Tables de caractres .........................................................................................................17
3.5 Indication d'encodage du contenu .....................................................................................18
3.6 Types de mdia.................................................................................................................19
3.6.1 Canonisation et texte par dfaut.................................................................................20
3.6.2 Types multiples "multipart"........................................................................................20
3.7 Produits............................................................................................................................21
4. Messages HTTP.....................................................................................................................22
4.1 Types de messages ...........................................................................................................22
4.2 En-ttes de messages........................................................................................................23
4.3 En tte gnrale................................................................................................................23
5. Request..................................................................................................................................24
5.1 Request-Line ....................................................................................................................24
5.1.1 Mthodes...................................................................................................................24
5.1.2 Request-URI .............................................................................................................25
5. En-tte de requte ..............................................................................................................26
6. Rponse .................................................................................................................................27
6.1 Ligne d'tat.......................................................................................................................27
6.1.1 Code d'tat et raison explicite ....................................................................................28
6.2 En-tte de rponse............................................................................................................29
7. Entits....................................................................................................................................30
7.1 En-tte d'entit .................................................................................................................30
7.2 Corps d'entit ...................................................................................................................30
7.2.1 Type..........................................................................................................................31
7.2.2 Longueur...................................................................................................................31
8. Dfinition des mthodes .........................................................................................................32
8.1 GET .................................................................................................................................32
8.2 HEAD..............................................................................................................................32
8.3 POST ...............................................................................................................................32
9. Dfinition des codes d'tat......................................................................................................34
9.1 Information 1xx................................................................................................................34
9.2 Succs 2xx .......................................................................................................................34
200 OK ..............................................................................................................................34

201 Cr ............................................................................................................................34
202 Accepte .....................................................................................................................35
204 Pas de contenu.............................................................................................................35
9.3 Redirection 3xx ................................................................................................................35
300 Choix multiples............................................................................................................35
301 Changement d'adresse dfinitive...................................................................................35
302 Changement d'adresse temporaire ................................................................................36
304 Non modifi.................................................................................................................36
9.4 Erreur client 4xx...............................................................................................................36
400 Requte incorrecte.......................................................................................................37
401 Non autoris................................................................................................................37
403 Interdit ........................................................................................................................37
404 Non trouv ..................................................................................................................37
9.5 Erreur serveur 5xx............................................................................................................37
500 Erreur serveur interne ..................................................................................................38
501 Non implment...........................................................................................................38
502 Erreur de routeur.........................................................................................................38
503 Service indisponible .....................................................................................................38
10. Dfinition des champs d'en-tte ............................................................................................39
10.1 Allow .............................................................................................................................39
10.2 Authorization .................................................................................................................39
10.3 Content-Encoding ..........................................................................................................40
10.4 Content-Length ..............................................................................................................40
10.5 Content-Type .................................................................................................................41
10.6 Date ...............................................................................................................................41
10.7 Expires ...........................................................................................................................41
10.8 From ..............................................................................................................................42
10.9 If-Modified-Since ...........................................................................................................43
10.10 Last-Modified...............................................................................................................43
10.11 Location .......................................................................................................................44
10.12 Pragma .........................................................................................................................44
10.13 Referer .........................................................................................................................45
10.14 Server...........................................................................................................................45
10.15 User-Agent...................................................................................................................46
10.16 WWW-Authenticate .....................................................................................................46
11. Authentification d'accs sous HTTP..................................................................................47
11.1 Modle d'authentification de base ...................................................................................48
12. Scurit................................................................................................................................50
12.1 Authentification des clients .............................................................................................50
12.2 Mthodes sres...............................................................................................................50
12.3 Abus de l'information Server Log Information ................................................................50
12.4 Transfert d'information sensible ......................................................................................51
12.5 Attaques sur les Fichiers et Rpertoires...........................................................................51
13. Crdits .................................................................................................................................53
14. Bibliographie........................................................................................................................55
15. Adresses des auteurs ............................................................................................................57
Appendices ................................................................................................................................58
A. Internet Media Type message/http .....................................................................................58
B. Applications tolrantes.......................................................................................................58

C. Relations avec les MIME ...................................................................................................59

C.1 Conversion vers la forme canonique .............................................................................59
C.2 Conversion de formats de dates....................................................................................59
C.3 Introduction du champ Content-Encoding ....................................................................60
C.4 Pas de champ Content-Transfer-Encoding....................................................................60
C.5 Champs d'en-tte HTTP dans des parties de corps Multipart ........................................60
D. Fonctions supplmentaires .................................................................................................60
D.1 Additional Request Methods........................................................................................60
D.2 Dfinitions d'autres champs d'en-tte............................................................................61

1. Introduction
1.1 Objectif
L'Hypertext Transfer Protocol (HTTP) est un protocole de niveau application
suffisamment lger et rapide, pour la transmission de documents distribus et multimdia
travers un systme d'information multi-utilisateurs. HTTP t utilis l'initiative du
Word-Wide Web ds 1990. Cette spcification dcrit les fonctionnalits le plus souvent
rencontres dans les implmentation "client/serveur HTTP/1.0". Elle est divise en deux
section. Les fonctions usuellement exploites de HTTP sont dcrites dans le corps de ce
document. Les autres fonctions, moins utilises sont listes dans l'annexe D.
Les systmes d'information pratiques ncessitent des fonctions plus volues que la
simple rcupration de donnes, 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 mthodes pour dfinir l'objet d'une requte. 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
mthode. 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 de communication gnrique 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 accs de base des
ressources hypermdia, et simplifiant l'implmentation d'interfaces utilisateur.
1.2 Terminologie
Cette spcification utilise un certain nombre de termes pour dsigner les participants et
les objets d'une communication HTTP.
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 squence structure
d'octets dfinie la Section 4 et transmis via la connexion.

Requte
Un message de requte HTTP (dfini en Section 5).
Rponse
Un message de rponse HTTP (dfini en Section 6).
Ressource
Un service ou objet du rseau pouvant tre identifi par une URI (Section 3.2).
Entit
Une reprsentation particulire de donnes, ou la rponse d'une ressource de type
service, incluse dans une requte ou une rponse. Une entit reprsente une
mtainformation sous la forme d'une en-tte et d'un contenu sous la forme d'un corps, ou
"body".
Client
Un programme applicatif dont la fonction principale est d'mettre des requtes.
Utilisateur
Le client qui a mis la requte. Celui-ci peut tre un navigateur, un diteur, un
"spiders" (robot d'exploration), ou autre utilitaire.
Serveur
Un programme applicatif acceptant des connexions dans le but traiter des requtes en
dlivrant une rponse.
Serveur origine
Le serveur dans laquelle se situe physiquement une ressource.
Proxy
Un programme intermdiaire qui cumule les fonctions de serveur et de client. Les
requtes sont soit traites en interne ou rpercutes, ventuellement converties, sur
d'autres serveurs. Un proxy doit interprter, puis reconstituer un message avant de le
remettre. Les proxies sont souvent utiliss comme portes d'accs ct utilisateur des
rseaux protgs par un "firewall" ou comme intermdiaire pour convertir des protocoles
non supports par l'utilisateur.
Gateway ou routeur
Un serveur jouant le rle d'intermdiaire pour d'autres serveurs. Contrairement un
Proxy, un routeur reoit les requtes comme s'il tait le serveur origine pour la ressource;
le client n'tant pas ncessairement conscient de "communiquer" avec un routeur. Les
routeurs sont souvent utiliss comme porte d'accs ct serveur d'un rseau protg par
"firewall" et comme convertisseur de protocole pour accder es ressources hberges
sur des systmes non-HTTP.
Tunnel
Un tunnel est un programme applicatif servant de relais "transparent" entre deux
connexions. Une fois actif, cet lment n'est plus considr comme faisant partie de la
connexion HTTP, bien qu'il soi issu d'une requte HTTP. Le tunnel cesse d'exister
lorsque les deux sens de la connexion ont t ferms. Les tunnels sont utiliss lorsqu'une
"porte" est ncessaire et que l'intermdiaire ne peut, ou ne doit pouvoir interprter la
communication.

Cache
Un espace de stockage local destin enregistrer les rponses et le sous-systme
contrlant ces enregistrements, leur relecture et leur effacement. Un cache enregistre des
rponses dans le but de diminuer le temps d'accs et la charge du rseau lors de
requtes identiques ultrieures. Tout client ou serveur peut implmenter 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
particulire, plutt qu' ses possibilits effectives. De mme tout serveur peut tre la
fois serveur origine, proxy, routeur, ou tunnel, changeant alors de comportement en
fonction des requtes reues.
1.3 Fonctionnement global

Le protocole HTTP est bas sur un paradigme requte/rponse. Un client tablit une
connexion vers un serveur et lui envoie une requte sous la forme d'une mthode, d'une
URI, du numro de version, suivi d'un message de type MIME contenant les modificateurs
de la requte, les informations sur le client, et ventuellement un corps. Le serveur
rpond par une ligne d'tat, incluant la version de protocole et un message de succs ou
d'erreur, suivi d'un message de type MIME contenant l'information sur le serveur,
metainformation, et le corps ventuel.
La plupart des communications HTTP sont inities par un utilisateur et consistent en
une requte devant tre applique (il s'agit d'une mthode) une ressource sur son
serveur origine. Dans le cas le plus simple, ceci peut tre ralis par une connexion
simple (v) entre l'utilisateur (UA) et le serveur origine (O).
Requte ------------------------>
UA -------------------v------------------- O
<----------------------- Rponse
Une situation plus complexe peut apparatre lorsque un ou plusieurs intermdiaires

sont prsents dans la chane de communication. On trouvera trois types d'intermdiaires:
les proxy, les routeurs, et les tunnels. Un proxy est un agent actif, recevant les requtes
destines une URI dans sa forme absolue, recomposant tout ou partie du message, et
rmettant la requte transforme destination de l'URI. Un serveur est un agent actif,
agissant en tant que "surcouche" par rapport d'autres serveurs et si ncessaire,
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 mme connexion, et de ce
fait sans modifier le message; les tunnels sont utiliss lorsque le message doit traverser
un intermdiaire (comme un "firewall") mme si celui-ci ne peut interprter le contenu des
messages.
Requte -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- Rponse
La figure ci-dessus montre le cas de trois intermdiaires (A, B, et C) entre l'utilisateur

et le serveur origine. Une requte ou rponse 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

mme passage par un tunnel, et accessible uniquement des extrmits, ou au contraire

toutes les connexions impliques dans la chane. Bien que ce schma soit linaire,
chaque participant peut tre engag dans plusieurs communications simultanes. Par
exemple, B peut tre en train de recevoir de nombreuses requtes de clients autres que
A, et mettre des requtes vers d'autres serveurs que C, tout en interprtant les requtes
issues de A.
Toute partie de communication n'tant pas un tunnel doit possder un cache pour le
stockage des requtes. L'intrt de cette pratique est que la chane requte/rponse peut
tre considrablement raccourcie si l'un des intermdiaires dispose dj 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 rponse prcdemment envoye par O (via C) et rpond
une requte identique de UA ( noter que dans cet exemple, ni UA ni A ne disposent de
cette mme rponse en cache).
Requte ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- Rponse
Toutes les rponses ne peuvent tre "caches", et certaines requtes peuvent utiliser
des modificateurs induisant un comportement particulier du cache. Certaines applications
HTTP/1.0 utilisent des heuristiques pour dcrire ce qui est ou non "cachable", mais ces
rgles ne sont pas standardises.
Sur Internet, les communications HTTP s'appuient principalement sur le protocole de
connexion TCP/IP. Le port utilis par dfaut est le port TCP 80 [15], d'autres ports
pouvant tre utiliss. Ceci n'exclut pas que HTTP puisse tre implment au dessus d'un
autre protocole d'Internet, ou sur d'autres types de rseau. HTTP ncessite seulement un
transport fiabilis; tout protocole garantissant la scurit de transmission peut tre utilis
pour supporter HTTP, la place qu'occupent les donnes des requtes et rponses
HTTP/1.0 dans les units de transmission de ces protocoles restant en dehors du
contexte de ce document.
Except pour des applications exprimentales, la pratique courante spcifie qu'une
connexion doit tre initie par un client avant transmission de la requte, et referme par
le serveur aprs dlivrance de la rponse. Les deux cts, client et serveur, doivent tre
prpars ce que la connexion soit coupe prmaturment, suite une action de
l'utilisateur, une temporisation automatique, ou une faute logicielle, et doivent apporter
une rponse prvisible cette situation. Dans tous les cas, la fermeture d'une connexion
qu'elle qu'en soit la raison est assimilable la conclusion de la requte, quel que soit
l'tat.
1.4 HTTP et MIME

HTTP/1.0 exploite un grand nombre d'implmentation prvues pour les MIME, tels que
dfinis dans la RFC 1521 [5]. L'appendice C dcrit comment HTTP l'utilisation des
"Internet Media Types" typiquement utiliss par la messagerie lectronique, et indique les
diffrences de comportement.

2. Conventions de notation et Grammaire gnrique
2.1 BNF tendue

Tous les mcanismes voqus sont dcrits en prose et sous forme Backus-Naur
tendue (BNF) similaire celle utilise dans la RFC 822 [7]. Les dveloppeurs devront
tre familiariss avec cette notation afin de comprendre cette spcification. La notation
Backus-Naur comprend les allgations suivantes :
nom = dfinition
Le nom d'une rgle est le nom lui-mme (sans "<" ni ">" englobants) et est spar de
sa dfinition par le symbole "=". Le caractre espace n'a de signification que lorsqu'un
retrait indique qu'une dfinition s'tend sur plusieurs lignes. Certaines rgles de base
sont en majuscules, comme SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Les ouvertures et
fermetures "<" et ">" ne sont utilises que lorsqu'une discrimination des rgles est
indispensable l'intrieur d'une dfinition.
"littral"
Un texte littral est entre doubles guillemets. Sauf mention contraire, la casse du texte
n'est pas considre.
rgle1 | rgle2
Les lments spars par une barre ("I") constituent une alternative, ex., "oui | non"
acceptera "oui" ou "non".
(rgle1 rgle2)
Les lments l'intrieur de parenthses sont considrs comme un seul lment.
Ainsi, "(elem (foo | bar) elem)" permet les squence "elem foo elem" et "elem bar elem".
*rgle
Le caractre "*" prcdent un lment indique sa rptition. La forme complte de
cette notation est "<n>*<m>element" indiquant au moins <n> et au plus <m>
occurrences de "element". Les valeurs par dfaut sont 0 et "infini". la syntaxe "*(element)"
signifie donc tout nombre d'occurrences y compris 0; "1*element" prcise au moins une
occurrence; et "1*2element" prcise une ou deux occurrences.
[rgle]
Les crochets prcisent un lment optionnel; "[foo bar]" vaut pour "*1(foo bar)".

Nrgle
Rptition prcise: "<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 chane de 3 caractres alphabtiques.
#rgle
Une syntaxe "#" est utilise, comme pour la syntaxe "*", pour dfinir des listes
d'lments. La forme complte en est "<n>#<m>element" indiquant au moins <n> et au
plus <m> elements, chacun spar par une ou plusieurs virgules (",") et des espaces
optionnels (LWS). Ceci rend la forme des listes trs lisible; une rgle du type "( *LWS
element *( *LWS "," *LWS element ))" peut tre vue comme "1#element". Lorsque cette
construction est utilise, les lments vides sont utiliss, mais ne contribue pas au
comptage des lments prsents. De ce fait, "(element), , (element)" est permis, mais
compte comme deux lments. Toutefois, dans les cas ou un lment au moins est
requis, cet lment doit tre non nul. Les valeurs par dfaut sont 0 et "infini" et donc
"#(element)" vaut pour tous les lments y compris 0; "1#element" vaut pour au moins un;
et "1#2element" permet un ou deux lments.
; commentaire
Un point virgule, distance d'un texte de rgle instaure un dbut de commentaire qui
va jusqu'au bout de la ligne. C'est un moyen pratique d'insrer des remarques ou
annotations en cours de spcification.
*LWS implicite
La grammaire dcrite par cette spcification est base sur le "mot". Sauf mention
contraire, tout nombre d'espaces (LWS) peut tre insr entre deux mots adjacents ou
"token", et entre un "token" et un dlimiteur (tspecials), sans changer l'interprtation. Il
doit exister au moins un dlimiteur (tspecials) entre deux mots, au risque de les voir
interprts comme un seul. Malgr tout, les constructions HTTP tendront utiliser la
"forme commune", certaines implmentations ne savent traiter autre chose que cette
forme.
2.2 Rgles de base

Les rgles de base suivantes seront utilises tout au long de ce document dans les
squences de recherche. La table de caractres ASCII-US est dfinie par [17].
OCTET = <toute donne code sur 8 bits>

CHAR = <tout caractre ASCII-US (0 127)>
UPALPHA = <Tout caractre alphabtique ASCII-US majuscule
"A".."Z">
LOALPHA = <Tout caractre alphabtique ASCII-US minuscule
"a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <tout digit ASCII-US "0".."9">
CTL = <Tous caractre de contrle 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 dfinit la squence CR LF comme marqueur de fin de ligne pour tous les
lments except le corps de l'entit (voir Appendice B pour les tolrances). La fin de
ligne l'intrieur d'un corps d'entit dpend de son mdia, comme dcrit en Section 3.6.
CRLF = CR LF
Les en-ttes HTTP/1.0 peuvent tre rparties su plusieurs lignes si chaque nouvelle
ligne commence par un espace ou une tabulation horizontale. Une suite d'espace, mme
sur plusieurs lignes quivaut un espace simple.
LWS = [CRLF] 1*( SP | HT )
Cependant les en-ttes multilignes ne sont pas acceptes par toutes les applications,
et doivent de prfrence tre vites lors d'un codage HTTP/1.0.
La rgle TEXT est utilise pour dcrire des informations descriptives qui ne sont pas
senses tre interprtes. Les mots d'un lment *TEXT peuvent contenir d'autres
caractres que ceux de la table ASCII-US stricto sensu.
TEXT = <tout OCTET sauf CTL, hormis LWS qui reste

autoris>
Les rcepteurs d'un lment TEXT d'une en-tte contenant des octets hors de la table
ASCII-US supposeront qu'il s'agit de caractres ISO-8859-1.
Les caractres hexadcimaux peuvent tre utiliss dans certaines applications.
HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" |

"c" | "d" | "e" | "f" | DIGIT
De nombreux champs d'en-tte HTTP/1.0 sont forms de mots spars par des
espaces ou caractres spciaux. Ces caractres doivent tre entre guillemets lorsqu'ils
sont utiliss l'intrieur d'une valeur.
mot = token | chane entre guillemets

token = 1*<tout CHAR except CTLs ou tspecials>
tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
"\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
"}" | SP | HT
Les commentaires pourront tre insrs dans les en-ttes HTTP en les entourant de
parenthses. Les commentaires ne sont permis que dans les champs contenant le mot
"comment" dans leur dfinition. Dans tous les autres champs, les parenthses sont
interprtes comme faisant partie de l'expression.
comment = "(" *( ctext | comment ) ")"

ctext = <tout TEXT except "(" et ")">
Une chane sera interprte 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 squence d'chappement d'un caractre unique

n'est pas permis par le protocole HTTP/1.0

3. Paramtres du protocole
3.1 Numro de Version

HTTP utilise un schma de numrotation "<suprieure>.<infrieure>" pour indiquer la
version du protocole. Cette technique permet un metteur d'envoyer une indication sur
sa capacit comprendre une rponse, plutt que les fonctionnalits qu'il permet. Les
composants du message ne pourront altrer ce numro de version car ils n'affectent pas
le comportement de la communication et ne font qu'tendre les possibilits des champs
qui les contiennent. Le nombre <infrieur> est incrment lorsque les changements
apports au protocole ajoutent des fonctionnalits ne modifiant pas la rponse de
l'algorithme d'interprtation, mais qui peuvent ajouter des nouvelles syntaxes ou des
nouvelles fonctionnalits ct metteur. Le nombre <suprieur> est incrment lorsque le
format de message est chang.
La version d'un message HTTP est indiqu par un champ HTTP-Version dans la
premire ligne du message. Si la version n'est pas spcifie, le rcepteur prendra par
dfaut la version la plus restrictive: HTTP/0.9.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Notez que les nombres "suprieure" et "infrieure" doivent tre pris comme deux
entiers distincts et que chacun peut tre amen prendre une valeur suprieure 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 zros mentionns en tte de nombre doivent tre ignors par
le rcepteur, et ne devraient pas tre mis par l'metteur.
Ce document dfinit les versions 0.9 et 1.0 du protocole HTTP. Les applications
envoyant des "requtes pleines" ou "rponses pleines", et dfinies dans cette
spcification, doivent signaler une version HTTP-Version "HTTP/1.0".
Les serveurs HTTP/1.0 doivent:
n reconnatre le format de la ligne de requte HTTP/0.9 et HTTP/1.0

n comprendre toute requte mise sous les formats HTTP/0.9 ou HTTP/1.0;
n rpondre avec un message sur la mme version de protocole que celle mise dans la
requte client.
Les clients HTTP/1.0 doivent:

n reconnatre le format de ligne d'tat des rponses HTTP/1.0;

n comprendre toute rponse au format HTTP/0.9 ou HTTP/1.0.
Les applications des Proxy et routeurs doivent prendre certaines prcautions lorsqu'ils
retransmettent des requtes d'un format diffrent que celui de l'application native. Comme
la version de protocole indique les possibilits fonctionnelles de l'application de
l'metteur, un proxy/routeur ne doit jamais mettre de requte de niveau suprieur celui
de sa propre application HTTP; si une telle requte lui parvient, le proxy/routeur doit
dgrader le numro de version, ou renvoyer une erreur. Les requtes reues sur un
niveau infrieur peuvent tre releves au niveau de version de l'application native; la
rponse de ces proxies/routeurs doivent nanmoins suivre les rgles nonces ci-avant.
3.2 Uniform Resource Identifiers

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 chanes formates identifiant --via un nom, une
localisation, ou toute autre caractristiques -- une ressource rseau.
3.2.1 Syntaxe gnrale

Les URI dans HTTP peuvent tre reprsentes sous forme absolue, ou relativement
une autre URI connue [9], suivant le contexte. Les deux formes sont diffrencies par le
fait qu'une URI absolue commence toujours par un schme contenant un nom suivi du
caractre ":".
URI = (URIabsolue | URIrelative ) [ "#" fragment ]
URIabsolue = scheme ":" *( uchar | reserv )
URIrelative = chem_res | chem_abs | chem_rel
chem_res = "//" loc_res [ chem_abs ]

chem_abs = "/" chem_rel
chem_rel = [ chemin ] [ ";" params ] [ "?" requte ]
chemin = fsegment *( "/" segment )

fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )

param = *( pchar | "/" )
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )

loc_res = *( pchar | ";" | "?" )
requte = *( uchar | reserv )
fragment = *( uchar | reserv )
pchar = uchar | ":" | "@" | "&" | "=" | "+"

uchar = nonrserv | echap
nonrserv = ALPHA | DIGIT | sr | extra | national

chap = "%" HEX HEX

rserv = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
sr = "$" | "-" | "_" | "."
nonsr = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <tout OCTET hormis ALPHA, DIGIT, reserv, extra,
sr, et nonsr>
Pour une information dfinitive sur la syntaxe des URL voir les RFC 1738 [4] et
RFC 1808 [9]. La notation BNF inclue des caractres nationaux non permis dans les URL
valides telles que spcifies dans la RFC 1738, car les serveurs HTTP ne sont pas limits
l'ensemble de caractres non rservs pour le codage de la prtie relative du chemin
d'accs, et les proxies HTTP peuvent recevoir des requtes destinations d'URI autres
que celles dfinies dans la RFC 1738.
3.2.2 URL http

Le schme "http" est utilis pour localiser une ressource rseau via le protocole HTTP.
Cette section dfinit la syntaxe et la smantique des URL.
http_URL = "http:" "//" host [ ":" port ] [ chem_abs ]
host = <un nom Internet d'ordinateur valide ou une

adresse IP (sous forme numrique), comme dfinie
en Section 2.1 de la RFC 1123>
port = *DIGIT
Si le port est vide ou non spcifi, le port 80 est pris par dfaut. La smantique prcise
que cette ressource est localise sur le serveur acceptant les connexions TCP sur ce port
et sur cet ordinateur, l'URI de requte de la ressource en est le chemin d'accs absolu
chem_abs. Si chem_abs n'est pas prcis dans l'URL, il doit tre remplac par un "/"
lorsque l'URI de requte est utilise (Section 5.1.2).
Note : Bien que le protocole HTTP soit indpendant de la couche transport, l'URL http
identifie la ressource par son adresse TCP, Les ressources non TCP devant tre
atteintes via un autre schme d'URI.
La forme canonique d'une URL "http" est obtenue en convertissant tous les caractres
UPALPHA dans la chane "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 remplaant 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
dfinition de dates et d'units 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, obsolte depuis la RFC 1036
Sun Nov 6 08:49:37 1994 ; Format asctime() du C ANSI

Le premier format est prfr pour Internet pour une raison lie la longueur fixe de
ses sous-champs, dfinis 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 dfini par
la RFC 850 [10] dsormais obsolte, et prsente l'inconvnient d'un champ d'anne sur
deux digits. Les clients et serveurs HTTP/1.0 doivent reconnatre les trois formats, mme
s'ils ne doivent jamais gnrer le troisime (convention du C).
Note : Les rcepteurs de valeurs de date doivent avoir une implmentation robuste et de ce
fait tre capables de reconnatre des formats de date manent d'applications non-
HTTP, comme il peut leur en parvenir en postant ou rcuprant des messages via
proxy/routeur de et vers SMTP ou NNTP.
Tout index temporel HTTP/1.0 doit tre reprsent 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",
abrviation 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'intrieur du
rseau de transmission. Les clients et serveurs ne sont pas obligs de respecter cette
prsentation pour l'affichage, la prsentation de requte, l'accs, etc.
3.4 Tables de caractres

HTTP utilise la mme dfinition du vocable "table de caractres" que celle utilise par
MIME:

Le terme "table de caractres" utilis dans ce document se rfre une mthode

utilisant une ou plusieurs tables pour convertir une squence d'octets en
caractres. Notez qu'une conversion inverse n'est pas forcment demande, c'est
dire que tout octet peut ne pas tre reprsent par un caractre, et qu'
l'inverse, une chane de caractres peut trs bien tre reprsentable par plus
d'une seule squence d'octets. Cette dfinition permet un grand nombre de types
de conversions, depuis celle, lmentaire, une table comme l'ASCII-US jusqu'
des mthodes plus complexes "commutation de tables" comme celles dfinies
par l'ISO 2022. Cependant, la dfinition associe au nom d'une "table de
caractre" MIME doit parfaitement et entirement spcifier le passage des octets
aux caractres. En particulier, le recours des informations externes pour pouvoir
assumer la conversion est interdit.
Note : Le terme "table de caractres" est aussi communment appel "encodage". Cependant,
comme HTTP et MIME partagent les mmes dfinitions, il est important qu'ils
partagent aussi la terminologie.
Les "tables de caractres" HTTP sont dfinies 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 dfinit pas un nom unique et
dfinitif pour chacune de ces tables, nous avons dfini ici les noms les plus couramment
utiliss dans les entits HTTP. Ces "tables de caractres" incluent celles dfinies dans la
RFC 1521 [5] -- ASCII-US [17] et ISO-8859 [18] -- ainsi que celles spcifiquement dfinies
pour usage dans les paramtres de caractres 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 dsigner une table de
caractres, tout nom dsignant dj une des tables du registre IANA doit indiquer cette
table prcise. Il est conseill que les applications s'en tiennent aux tables de caractres
dfinies dans ce registre.
La table de caractre indique pour un corps d'entit doit tre le plus petit
dnominateur commun de l'ensemble des codes de caractres utiliss dans ce corps,
sauf si l'on prfre systmatiquement 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
applique une ressource. Cette information a t initialement dfinie pour pouvoir
garder la trace d'un type de ressource compresse ou encrypte. Typiquement, la
ressource est disponible sous forme encode, et ne sera dcode 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
interprter "gzip" et "compress" respectivement comme "x-gzip" et "x-compress".
Toute mention d'encodage est indpendante de la casse. L'HTTP/1.0 utilise les

descripteurs d'encodage dans le champ Content-Encoding (Section 10.3) de l'en-tte. Le
plus important est que cette information indique quel est le type de dcodage que le
rcepteur devra utiliser pour exploiter la ressource. Notez qu'un mme programme peut
tre capable de dcoder plusieurs types d'encodage. Les deux valeurs dfinies dans
cette spcification sont:
x-gzip
Un format de compression gr par le programme de compression "gzip" (GNU zip)
dvelopp par Jean-Loup Gailly. Ce codage est de type Lempel-Ziv (LZ77) avec
CRC sur 32 bits.
x-compress
Un format de compression gr 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 dconseill 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 mdia

HTTP exploite les dfinition de types de mdia Internet Media Types [13] dans le
champ Content-Type de l'en-tte (Section 10.5) afin de proposer une mthode de typage
ouverte et volutive.
media-type = type "/" soustype *( ";" paramtre )

type = nom_type
soustype = nom_soustype
Les paramtres suivent la description de type/soustype, sous la forme de paires

attribut/valeur.
paramtre = attribut "=" valeur

attribut = nom_attribut
valeur = nom_valeur | chane ente guillemets
Le type, sous-type et les noms d'attributs sont insensibles la casse. Les valeurs
associes aux attributs peuvent l'tre ou ne pas l'tre, suivant la smantique du nom de
l'attribut. les types et sous type ne peuvent tre spar par un LWS. Ceci est valable pour
les paires attribut/valeur Lorsqu'un rcepteur reoit un paramtre irrecevable pour le type
de mdia spcifi, il devra traiter le descripteur comme si cette paire attribut/valeur
n'existait pas..
Certaines anciennes applications HTTP ne reconnaissent pas le type de mdia. Les
applications HTTP/1.0 ne pourront dfinir le type que lorsque la spcification du contenu
est indispensable.

Les valeurs admises de types de mdia sont dfinies par la Internet Assigned Number
Authority (IANA [15]). Le processus d'enregistrement d'un type de mdia est spcifi dans
la RFC 1590 [13]. L'usage de types non enregistrs est dconseill.
3.6.1 Canonisation et texte par dfaut

Les types de mdia Internet sont enregistrs sous une forme canonique. En principe,
un corps d'entit transfr par HTTP doit tre reprsent dans sa forme canonique avant
transmission. Si le corps a t encod sous un codage spcifi 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 squence CRLF en
tant que fin de ligne. Cependant, HTTP permet le transport de texte dans lequel un CR ou
un LF seul reprsente la fin de ligne, tant que l'on reste l'intrieur du corps de l'entit.
Les applications HTTP doivent accepter des fins de ligne reprsentes par la squence
CRLF, par un CR seul, ou par un LF seul, ds qu'il s'agit d'un mdia "text".
De plus, si le mdia texte utilise une table de caractre dans laquelle les caractres 13
et 10 ne correspondent pas aux caractres CR et LF, comme c'est le cas pour certains
codages multi-octets, HTTP permet l'usage de toute squence de caractres dsigns
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 "lgal" ne devra pas tre
remplac par un CR seul ou un LF seul dans aucune des structures de contrle HTTP
(telles que les champs d'en-ttes ou les limites "multipart").
Le paramtre "charset" est utilis avec certains types de mdia pour dfinir la table de
caractres utilise (Section 3.4) dans les donnes. Lorsque ce paramtre n'est pas
explicitement renseign, les sous-types du mdia "text" prennent par dfaut la table de
caractres "ISO-8859-1". Des donnes codes selon une autre table de caractres que
"ISO-8859-1" ou ses sous-ensembles devra ncessairement entraner une spcification
explicite de ce codage, sous peine d'tre ininterprtables par le rcepteur.
Note : De nombreux serveurs HTTP actuels diffusent des donnes codes selon une table de
caractres autre que "ISO-8859-1" et sans explicitation correcte. Cette attitude rduit
l'interoprabilit propre du rseau et est fortement dconseille. Pour compenser de
manque de rigueur, certains utilisateurs HTTP proposent une option permettant de
changer la table de caractres par dfaut utilise lorsque des donnes sont reues sans
explicitation de cette information.
3.6.2 Types multiples "multipart"

MIME dfinit un certain nombre de types "multipart" -- encapsulation de plusieurs
entits dans un mme corps d'entit. Les types "multipart" enregistrs par l'IANA [15]
n'ont pas de signification particulire aux yeux d'HTTP/1.0, bien que les utilisateurs
dussent tre en mesure de pouvoir reconnatre chaque sous type de faon
correctement interprter chaque sous partie du corps. Un utilisateur HTTP suivra les
mmes rgles de comportement qu'un utilisateur MIME dans le cas d'une rception de
donnes "multipart". Les serveurs HTTP ne sont pas sens supposer que tous les clients
HTTP puissent recevoir des donnes ainsi prsentes.
Tous les types "multipart" partagent la mme syntaxe et doivent spcifier un
paramtres de "limite" dans la dfinition du type. Le corps du message fait lui-mme
partie du protocole et doit s'en tenir la squence CRLF pour reprsenter des sauts de

lignes entre les parties. Chaque partie d'un document "multipart" peut elle mme contenir
des champs d'en-tte HTTP significatifs pour son contenu.
3.7 Produits
La spcification 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 numro de version, tous
deux optionnels. Les champs acceptant cette spcification permettent de lister des sous-
lments significatifs d'un produit, spars par un espace. Par convention, les produits
sont rangs par ordre d'importance dans le processus d'identification.
produit = nom_produit ["/" version]

version = numro_de_version
Exemples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Les spcifications 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 numro de version accepte tout caractre 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.

4. Messages HTTP
4.1 Types de messages

Les messages HTTP consistent en des requtes mises par un utilisateur destination
d'un serveur, ou d'une rponse d'un serveur au destinataire.
HTTP-message = Requte_simple ; HTTP/0.9 messages

| Rponse_simple
| Requte_complte ; HTTP/1.0 messages
| Rponse_complte
Les requtes et rponses "compltes" utilisent le format de message dfini dans la

RFC 822 [7] concernant la transmission d'entits. Ces deux messages peuvent contenir
une en-tte optionnelle ainsi que le corps de l'entit. Le corps et l'en-tte de l'entit sont
spars par une ligne vide (soit une squence CRLFCRLF).
Requte_complte = Ligne_requte ; Section 5.1

*( En-tte_gnrale ; Section 4.3
| En-tte_requte ; Section 5.2
| En-tte_entit ) ; Section 7.1
CRLF
[ Corps_entit ] ; Section 7.2
Rponse_complte = Ligne-tat ; Section 6.1

| En-tte_rponse ; Section 6.2
CRLF
Les requte et rponse simple ne transportent jamais d'en-tte. Une seule requte est
de ce type : GET.
Requte_simple = "GET" SP URI-vise CRLF
Rponse_simple = [ Corps_entit ]

L'usage des requtes simples reste dconseill, car il ne permet pas au serveur de
dfinir le type de mdia dans sa rponse.
4.2 En-ttes de messages

Les champs d'en-ttes HTTP, dont l'en-tte_gnrale (Section 4.3), l'en-tte_requte
(Section 5.2), L'en-tte_rponse (Section 6.2), et l'en-tte_entit (Section 7.1), ont tous le
mme format gnrique dcrit dans le paragraphe 3.1 de la RFC 822 [7]. Chaque champ
d'en-tte consiste en un nom suivi immdiatement d'un deux-points (":"), un espace (SP),
et la valeur du paramtre. Les noms de champs sont insensibles la casse. Les champs
d'en-tte peuvent tre crits sur plusieurs lignes, condition que le premier caractres
des lignes suivantes soit SP ou HT. Cette pratique reste cependant dconseille.
HTTP-header = nom ":" SP [ valeur ] CRLF
nom = nom_de_champ
valeur = *( contenu | LWS )
contenu = <les OCTETs dcrivant la valeur, pouvant tre un

*TEXT ou combinaison de noms, caractres spciaux,
et chanes entre guillemets>
L'ordre dans lequel les champs d'en-tte sont reus n'a pas d'importance. Une "bonne
habitude" consistera toutefois envoyer les champs d'en-tte_gnrale en premier, suivi
des champs d'en-tte_requte ou d'en-tte_rponse, puis enfin les champs d'en-
tte_entit.
Lorsque plusieurs champs de mme nom doivent tre dfinis avec des valeurs
diffrentes, celles-ci doivent apparatre comme une liste spare par des virgules
[#(values)]. Il doit tre possible de combiner cette dfinition multiple partir des paires
individuelles "nom: valeur", sans changer la smantique du message, en ajoutant chaque
valeur la suite de la premire, en utilisant une virgule comme sparateur.
4.3 En tte gnrale

Certains champs d'en-tte ont une utilit aussi bien dans des requtes que dans des
rponses, en conservant la mme signification. Les informations dfinies dans ces
champs concernent le message lui-mme, et non l'entit qu'il transporte.
General-Header = Date ; Section 10.6

| Pragma ; Section 10.12
Des nouveaux noms de champs d'en-tte_gnrale ne peuvent tre introduits que

dans le cadre d'un changement de version du protocole. Cependant, de nouveaux
champs ou champs exprimentaux peuvent utiliser la smantique de champs d'en-
tte_gnrale, partir du moment ou les deux extrmits de la communication sont
d'accord pour le faire. Tout champ non reconnu sera considr comme un champ d'en-
tte_entit.

5. Requtes
Une requte d'un client vers un serveur inclue, dans sa premire ligne, la mthode
applique la ressource, l'identificateur de cette ressource, et la version de protocole
courante. Afin d'assurer la compatibilit descendante avec la version plus limite
HTTP/0.9 du protocole, deux formats seront valides pour exprimer une requte:
Request = Requte_simple | Requte_complte
Simple-Request = "GET" SP URI-vise CRLF
Requte_complte = Ligne-requte ; Section 5.1

| En-tte_requte ; Section 5.2
CRLF
[ Corps-entit ] ; Section 7.2
Si un serveur HTTP/1.0 reoit une requte simple, il devra rpondre par une rponse
simple HTTP/0.9. Un client HTTP/1.0 capable de recevoir une rponse_complte ne doit
jamais gnrer de requte_simple.
5.1 Ligne de requte

La ligne de requte commence par un nom de requte, suivie de l'URI vise, du
numro de version de protocole, et termine enfin par CRLF. Ces lments sont spars
par des espaces. Aucun CR ni LF n'est autoris except la squence finale CRLF.
Ligne_requte = Mthode SP URI-vise SP Version-HTTP CRLF
Notez que la diffrence entre une ligne de requte_simple et de requte_complte ne

rside que dans la prsence du numro de version HTTP, et dans la possibilit d'appeler
d'autres mthodes que GET.
5.1.1 Mthodes
La mthode indique en tte de ligne est destine tre applique l'URI cible. Son
nom dpend de la casse.
Mthode = "GET" ; Section 8.1

| "HEAD" ; Section 8.2

| "POST" ; Section 8.3
| nom_de_mthode
La liste de mthodes que peut accepter une ressource est dynamique; Le client est
avis de la disponibilit de la mthode mise par le code de retour du message de
rponse. Les serveurs renverront le code 501 (non implment) si la mthode est
inconnue, ou non implmente.
Les mthodes habituellement employes par les applications HTTP/1.0 sont dcrites
en dtail en Section 8.
5.1.2 URI-vise (Request-URI)

L'URI vise est l'URI identifiant la ressource rseau laquelle doit tre applique la
mthode.
URI-vise = URIabsolue | chem_abs
Ces deux options dpendent de la mthode appele.

Seule l'option URIabsolue est permise lorsque la requte est envoye un proxy. Le
proxy devra retransmettre la requte, et servir d'intermdiaire pour la rponse. Si la
requte est GET ou HEAD et la rponse prsente dans le cache du proxy, celui-ci pourra
utiliser cette rponse directement, si les conditions restrictives de "date d'expiration "
dans l'en-tte sont remplies. Notez que le proxy peut son tour retransmettre la requte
vers un autre proxy, ou directement vers le serveur origine. Afin d'viter qu'une requte
ne boucle, un proxy doit reconnaitre tous sesnoms de serveurs, y compris alias, variations
locales, et les adresses IP numriques. Voici un exemple de ligne de requte:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
La forme d'URI-vise 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 rcuprer la ressource
ci-dessus directement partir de son serveur origine crera 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 requte complte. Notez qe le chemin absolu ne peut tre vide; si la
ressource se trouve dans la racine (pas de chemin d'accs) le chemin spcifi devra
comporter au moins le caractre slash ("/").
L'URI-vise est transmise sous forme d'une chane encode, dans laquelle certains
caractres apparatront comme une squence d'chappement "% HEX HEX" telle que
dfinie par la RFC 1738 [4]. Le serveur origine devra dcoder cette chane afin d'accder
correctement la ressource.

5.2 En-tte de requte

Les champs d'en-tte de requte permettent de la transmission d'informations
complmentaires sur la requte, et le client lui-mme. Ces champs agissent comme
"modificateurs" de la requte, utilisant une smantique identique celle des paramtres
passs par un appel d'une mthode de langage de programmation de haut niveau.
Request-Header = Authorization ; Section 10.2

| From ; Section 10.8
| If-modified-since ; Section 10.9
| Referer ; Section 10.13
| User-agent ; Section 10.15
Des nouveaux noms de champs d'en-tte_requte ne peuvent tre introduits que dans
le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou
champs exprimentaux peuvent utiliser la smantique de champs d'en-tte_requte,
partir du moment ou les deux extrmits de la communication sont d'accord pour le faire.
Tout champ non reconnu sera considr comme un champ d'en-tte_entit.

6. Rponse
Une fois la requte reue et interprte, un serveur rpond par un message HTTP de
rponse.
Rponse = Rponse_simple | Rponse_complte
Rponse_simple = [ Corps_entit ]
Rponse_complte = Ligne_tat ; Section 6.1

| En-tte_rponse ; Section 6.2
CRLF
Une rponse_simple ne peut tre envoy qu'en rponse d'une requte_simple

HTTP/0.9 ou si le serveur ne supporte que la version limite de protocole HTTP/0.9. Si un
client met une requte_complte HTTP/1.0 et reoit une rponse ne commenant pas
par une ligne_tat, il devra conclure qu'il s'agit d'une rponse_simple et l'interprtera en
consquence. Notez qu'une rponse ne contient que le corps_entit, et se termine par la
fermeture de la connexion par le serveur.
6.1 Ligne d'tat

La premire ligne d'un message de rponse_complte est la ligne d'tat, constitue
d'une indication du numro de version du protocole, suivi du code numrique de la
rponse, suivi enfin d'une explicitation textuelle de cette rponse, chaque lment tant
spar par un espace. Aucun CR ni LF ne peuvent y apparatre l'exception de la
squence CRLF finale.
Ligne_tat = Version_HTTP SP Code_tat SP Raison CRLF
La ligne d'tat dbutant toujours par ce numro de version et le code de rponse:
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
(ex., "HTTP/1.0 200 "), la seule prsence de cette expression est suffisante pour
diffrentier une rponse_simple d'une rponse_complte mise en retour d'une requte

sousle protocole HTTP/1.0. Le format de rponse_simple n'interdit cependant pas qu'une

telle expression soit place en tte du corps d'entit, provoquant ainsi une erreur
d'interprtation de la part du rcepteur. Dans la pratique, la plupart des serveurs
HTTP/0.9 ne peuvent gnrer que des rponses de type "text/html", ce qui en principe,
limine le risque d'une telle confusion.
6.1.1 Code d'tat et raison explicite

L'lment code_tat est un nombre entier 3 chiffres indiquant le succs ou la cause
d'erreur de la transaction. L'lment "raison" est un commentaire textuel destin
identifier explicitement la cause d'erreur. Le code d'tat sera en gnral exploit par des
automates. La raison est destination de notre intellect humain.
Celle-ci n'est pas obligatoirement traite ni reporte par le client.
Le premier chiffre du code d'tat indique la classe gnrale de la rponse. Les deux
derniers n'ont pas de rle de classification particulier. Le premier chiffre peut prendre 5
valeurs:
1xx: Information - Non utilis, pour usage futur

2xx: Succs - L'action a t correctement reue, interprte, et excute.
3xx: Redirection - Une dcision supplmentaire doit tre prise pour terminer la
requte
4xx: Erreur Client - La requte prsente une erreur de forme et ne peut tre
satisfaite
5xx: Erreur Serveur - La requte est valide, mais le serveur ne peut la satisfaire
Les valeurs actuellement reconnues sous HTTP/1.0, et les phrases types d'explicitation
associes, sont prsentes ci-dessous. Ces phrases ne sont que recommandes -- elles
peuvent tre remplaces par des variations locales sans affecter le protocole. Ces codes
sont intgralement lists en section 9.
Code_tat = "200" ; OK OK
| "201" ; Created Cr
| "202" ; Accepted Accept
| "204" ; No Content Pas de contenu
| "301" ; Moved Permanently Changement dfinitif
| "302" ; Moved Temporarily Changement temporaire
| "304" ; Not Modified Non modifi
| "400" ; Bad Request Requte incorrecte
| "401" ; Unauthorized Non autoris
| "403" ; Forbidden Interdit
| "404" ; Not Found Non trouv
| "500" ; Internal Server Error Erreur interne serveur
| "501" ; Not Implemented Non implment
| "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 utiliss
dans la pratique courante. Les applications HTTP n'ont pas ncessairement connatre
la signification de tous les codes enregistrs, 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 numro de rponse non identifi comme le numro
x00 de la classe, indiquant ainsi la dfinition gnrique de la classe. Aucune rponse non
identifie ne peut tre enregistre en cache.
Par exemple, si un code "inconnu" 431 est reu par le client, celui-ci peut interprter sans
doute possible qu'un problme est survenu, et peut ragir comme s'il avait reu le code
400. Dans de tels cas, il est fortement conseill que l'application reporte le corps de
l'entit de rponse, dans la mesure o il y a de fortes chances que celui-ci contienne des
informations "en clair" sur la nature de l'erreur.
6.2 En-tte de rponse

Les champs d'en-tte de rponse vhiculent certaines informations complmentaires
concernant cette rponse, et qui ne peuvent tre mentionnes dans la ligne d'tat. Ces
champs donnent des informations sur le serveur lui-mme, et sur les actions mener par
la suite pour accder la ressource demande.
Response-Header = Location ; Section 10.11

| Server ; Section 10.14
| WWW-Authentificate ; Section 10.16
Des nouveaux noms de champs d'en-tte_rponse ne peuvent tre introduits que dans
le cadre d'un changement de version du protocole. Cependant, de nouveaux champs ou
champs exprimentaux peuvent utiliser la smantique de champs d'en-tte_rponse,
partir du moment ou les deux extrmits de la communication sont d'accord pour le faire.
Tout champ non reconnu sera considr comme un champ d'en-tte_entit.

7. Entits
Les messages de requte et de rponses contiennent gnralement une entit dans

laquelle est incluse des lments de requte ou de rponse. Une entit est dfinie par
une en-tte d'entit, et dans la plupart des cas par un corps d'entit. Dans ce qui suit
"l'metteur" et le "rcepteur" se rfrent tantt au client, tantt au serveur, suivant l'agent
qui met le message.
7.1 En-tte d'entit

Les champs d'en-tte d'entit vhiculent certaines mtainformations concernant le
corps d'entit, ou, si celui-ci n'existe pas, la ressource vise par la requte.
En-tte_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-tte
champ_en-tte = en-tte_HTTP
Le mcanisme d'extension de l'en-tte d'entit permet la dfinition d'autres champs,

ceux-ci n'tant pas obligatoirement reconnus par le rcepteur. Tout champ non identifi
doit tre ignor, ou, dans le cas d'un proxy, retransmis tel quel.
7.2 Corps d'entit

Le corps d'entit (s'il existe) envoy dans un message de requte ou de rponse HTTP
est dans un format et sous un encodage dfini par les champs d'en-tte d'entit.
Corps_entit = *OCTET
Un corps d'entit n'apparat dans un message de requte que dans la mesure ou le

type de requte le demande. La prsence de ce corps est signale par la prsence d'un
champ Content-Length dans les champs d'en-tte de la requte. Les requtes HTTP/1.0
contenant un corps doivent ncessairement prsenter un champ d'en-tte Content-Length
valide.

Dans les rponses, la prsence d'un corps d'entit est fonction la fois de la nature de
la requte pralable, et du code d'tat renvoy. Toute rponse une requte de type
HEAD ne peut contenir de corps d'entit, mme si les champs d'en-tte prsents
prtendent 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 rponses peuvent contenir un corps d'entit, ou dfaut, un champ
Content-Length spcifi zro (0).
7.2.1 Type
Lorsqu'un corps d'entit est prsent dans le message, le type de donnes incluses
dans ce corps est prcis par les champs d'en-tte Content-Type et Content-Encoding.
Ceux-ci dfinissent un modle d'encodage arborescent deux niveaux:
Corps_entit = Content-Encoding( Content-Type( donnes ) )
Le Content-Type le type de mdia des donnes de la ressource. Un champ Content-

Encoding peut tre utilis pour spcifier un traitement ou encodage supplmentaire
effectu sur le type de donnes, souvent dans un but de compression, et apparaissant
comme une proprit de la ressource. Par dfaut, aucun encodage n'est appliqu aux
donnes (la ressource est enregistre et directement accessible sous forme utilisable).
Tout message HTTP/1.0 contenant un corps d'entit doit au moins faire apparatre le
champ Content-Type dfinissant la nature des donnes de la ressource. Si et seulement
si aucun type de mdia n'est dfini (uniquement dans le cas o le champ Content-Type
n'existe pas, comme dans le cas de rponses simples), le rcepteur pourra tre amen
dterminer ce type par lui-mme, en inspectant le contenu des donnes, ou en se basant
sur l'extension utilise dans l'URL dfinissant l'accs la ressource. Si le mdia demeure
non identifiable, le type par dfaut "application/octet-stream".
7.2.2 Longueur
Lorsqu'un corps d'entit est prsent dans un message, la longueur de ce corps doit
tre explicite par l'un des deux moyens suivants. Si un champ Content-Length est
prsent, sa valeur associe reprsente la longueur en octets du corps d'entit.
Autrement, c'est la dconnexion par le serveur qui marque la fin du corps d'entit.
Cette dernire mthode ne peut tre utilise pour marquer la fin d'une requte, car la
possibilit doit tre laisse au serveur d'envoyer une rponse. C'est pourquoi le protocole
HTTP/1.0 prcise que toute requte contenant un corps d'entit doit mentionner sa
longueur dans un champ d'en-tte 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
dterminer la longueur de ce corps, ce dernier rpondra par un message de code 400
(erreur client).
Note : Certains anciens serveurs spcifient un champ Content-Length erron lorsque la

rponse contient des donnes dynamiquement gnres par le serveur. Il est signal
ici que cet tat de fait ne sera plus tolrable dans les nouvelles versions d'HTTP.

8. Dfinition des mthodes
L'ensemble des mthodes courantes d'HTTP/1.0 est dfini ci-dessous. Bien que cet
ensemble puisse tre complt, il est prcis ici que des mthodes additionnelles
implmentes par des clients ou serveurs distincts ne peuvent partager la mme
smantique que si leur fonction est identique.
8.1 GET
La mthode GET signifie "rcuprer" le contenu quel qu'il soit de la ressource (sous
forme d'une entit) identifie par l'URI-vise. Si l'URI-vise identifie un processus
gnrant dynamiquement des donnes, ce sont les donnes produites qui sont renvoyes
dans l'entit au lieu du source de l'excutable appel, sauf si ce texte lui-mme est la
sortie du processus.
La smantique de la mthode GET introduit une notion conditionnelle si la requte
inclue le champ d'en-tte If-Modified-Since. Une mthode GET conditionnelle ne rcupre
la ressource que si celle-ci a t modifie depuis la date associe au champ If-Modified-
Since, comme indiqu en Section 10.9. La mthode GET conditionnelle est utilise pour
rduire la charge du rseau en permettant des ressources en cache d'tre rafrachies
sans multiplier les requtes ou transfrer des donnes inutiles.
8.2 HEAD
La mthode HEAD est identique la mthode GET, sauf qu'elle ne demande pas la
transmission du corps d'entit de la ressource en retour. Seule les mtainformations
constituant l'en-tte HTTP de la ressource sont envoyes. Cette mthode permet de ne
demander que les informations concernant la ressource (au sens d'HTTP). Elle est
utilise des fins de tests d'hyperliens, vrification d'existence ou d'actualit d'une
ressource.
Il n'existe pas de mthode HEAD conditionnelle comme pour la mthode GET. Si un
champ d'en-tte If-Modified-Since est prsent dans une requte HEAD, il devra tre
ignor.
8.3 POST
La mthode POST est utilise pour indiquer au serveur de soumettre l'entit contenue
dans le message la ressource identifie par l'URI-vise. POST est destine fournir un
moyen uniforme pour les oprations suivantes:

Annotation de ressources existantes;

Envoi d'un message vers une dition en ligne, un groupe de nouvelles, une liste
d'adresse, ou listes similaires;
Fournir un bloc de donnes, par exemple, un rsultat de formulaire [3], un processus
de gestion de donnes;
Ajout d'lments une base de donnes.
La fonction effective de la mthode POST est dfinie par le serveur et dpend de l'URI
dsigne. L'entit "poste" est subordonne cette URI dans le mme sens qu'un fichier
est subordonn au rpertoire qui le contient, un article est subordonn au groupe de
nouvelles qui il a t post, ou un enregistrement une base de donnes.
La rsolution d'une mthode POST ne signifie pas forcment la cration d'une entit
sur le serveur origine, ni une possibilit d'accs futur ces informations. En d'autres
termes, le rsultat d'un POST n'est pas ncessairement une ressource associable une
URI. Dans ce cas, une rponse de code 200 (OK) ou 204 (pas de contenu) est la rponse
la plus approprie, suivant que la rponse contient ou non une entit pour dcrire le
rsultat.
Si une ressource a t cre sur le serveur origine, la rponse sera du type
201 (cr) et contiendra l'entit (de prfrence du type "text/html") qui dcrira les
informations sur la requte et contiendra une rfrence sur la nouvelle ressource.
Un champ Content-Length valide est demand dans toute requte POST HTTP/1.0. Un
serveur HTTP/1.0 rpondra par un message 400 (requte incorrecte) s'il ne peut
dterminer la longueur du contenu du message.
Les applications ne peuvent enregistrer en cache les rponses des requtes POST
dans la mesure o il n'est absolument pas certain qu'une rponse ultrieure mise dans
les mmes conditions produise le mme rsultat.

9. Dfinition des codes d'tat
Tous les codes d'tat actuellement valides sont dcrits ci-dessous, en prcisant quelle
mthode peut en tre l'origine, ainsi que les mtainformations fournir dans la rponse.
9.1 Information 1xx

Cette classe de rponse est actuellement rserve pour de futures applications, et
consiste en des messages avec une ligne d'tat, des champs d'en-ttes ventuels, et
termins par une ligne vide (CRLFCRLF).
HTTP/1.0 ne dfinit actuellement aucun de ces codes, lesquels ne constituent pas une
rponse valide des requtes HTTP/1.0. Il restent cependant exploitables titre
exprimental, dpassant le contexte de la prsente spcification.
9.2 Succs 2xx

Cette classe prcise que la requte du client a t correctement transmise, interprte,
et excute.
200 OK
La requte a abouti. L'information retourne en rponse dpend de la requte mise,
comme suit:
GET
Une entit correspondant l'URI vise par la requte est renvoye au client;
HEAD
La rponse au client ne doit contenir que les champs d'en-tte l'xclusion de tout
corps d'entit;
POST
Une entit dcrivant le rsultat de l'action entreprise.
201 Cr
La requte a abouti, et une nouvelle ressource rseau en rsulte.
La nouvelle ressource cre est accessible par l'URI(s) renvoye dans l'entit de la
rponse. La ressource doit tre cre avant que ce code ne soit envoy. Si la cration ne

peut pas tre opre immdiatement, le serveur devra indiquer dans la rponse quand la
ressource deviendra disponible ou retourner un message de type 202 (accepte).
Actuellement, seule la mthode POST peut conduire la cration d'une ressource.
202 Accepte
La requte a t reue et interprte correctement, mais son traitement n'est pas
termin. La requte peut ou ne peut tre rmise pendant le traitement, suivant que le
serveur autorise ou n'autorise pas un arrt du processus en cours. Il n'est pas possible de
rmettre un code d'tat dans ce type d'opration asynchrone.
La rponse 202 est intentionnellement non bloquante. Son rle est de permettre au
serveur d'accepter une requte d'un autre processus (par exemple d'un automate se
dclenchant dates fixes) sans que la connexion avec le client ne reste active pendant le
droulement du traitement. L'entit retourne par la rponse rendra compte de la requte,
et devra fournir un pointeur sur un composant d'information (tat courant du traitement),
ou donner une estimation de la date de conclusion probable dfinitive.
204 Pas de contenu

La requte a abouti et le serveur n'a rien envoyer en retour.
Un utilisateur recevant ce message n'aura pas rafrachir son affichage, et
maintiendra celui qui aura conduit l'mission de la requte. Cette rponse a t
instaure pour permettre un utilisateur de drouler des scripts ou autres actions sans
modifier l'affichage en cours. La rponse peut cependant contenir des mtainformations
dans des champs d'en-tte, concernant le document affich dans la fentre active de
l'utilisateur.
9.3 Redirection 3xx

Cette classe de messages prcise que le client doit provoquer une action
complmentaire pour que la requte puisse tre conduite jusqu' sa rsolution finale.
L'action peut tre dclenche par l'utilisateur final si et seulement si la mthode invoque
tait GET ou HEAD. Un client ne peut automatiquement rediriger une requte plus de 5
fois. Il est suppos, si cela arrive, que la redirection s'effectue selon une boucle infinie.
300 Choix multiples

Ce code n'est pas utilis directement par les applications HTTP/1.0 mais est dfini
pour servir de rponse par dfaut des codes 3xx non reconnus.
Il signifie en principe que la ressource vise est disponible en un ou plusieurs autres
points du rseau. Sauf dans le cas d'une requte de type HEAD, la rponse doit contenir
une entit dans laquelle sont listes les caractristiques et localisations de la ressource
demande, charge de l'utilisateur de choisir laquelle est la plus approprie. Si le
serveur affiche une prfrence de choix, il doit en inscrire l'URL dans un champ Location;
Certains clients utiliseront ce champ pour activer une redirection automatique.
301 Changement d'adresse dfinitive

La ressource demande est dsormais accessible via une autre URL, toute nouvelle
requte lui tant applique devant utiliser cette nouvelle URL. Les clients implmentant

une fonction de redirection automatique l'activeront et rmettront une requte avec l'URI
correcte, lorsque c'est possible.
La nouvelle URL sera indique dans le champ d'en-tte Location de la rponse. Sauf
dans le cas d'une requte de type HEAD, le corps d'entit de la rponse contiendra une
note succincte avec un hyperlien vers la nouvelle URL.
Si le code d'tat 301 est reu en rponse une requte POST, le client ne pourra
rediriger automatiquement la requte sans en avoir demand confirmation l'utilisateur.
En effet, il n'est pas dit que les conditions ayant t l'origine de la requte n'aient pas
chang.
Note: Certains clients, lorsqu'ils redirigent une requte POST, transforment par erreur cette
requte en une requte GET aprs rception d'un code 301.
302 Changement d'adresse temporaire

La ressource demande est actuellement et temporairement accessible via une autre
URL. La redirection n'tant pas dfinitive, le client continuera d'utiliser l'URI-vise
originale.
La nouvelle URL temporaire doit tre spcifie en rponse dans un champ Location.
Sauf dans le cas d'une requte de type HEAD, le corps d'entit de la rponse contiendra
une note succincte avec un hyperlien vers la nouvelle URI.
Si le code d'tat 302 est reu en rponse une requte POST, le client ne pourra
rediriger automatiquement la requte sans en avoir demand confirmation l'utilisateur.
En effet, il n'est pas dit que les conditions ayant t l'origine de la requte n'aient pas
chang.
Note : Certains clients, lorsqu'ils redirigent une requte POST, transforment par erreur cette
requte en une requte GET aprs rception d'un code 302.
304 Non modifi

Ce message est mis en retour d'une requte GET conditionnelle, lorsque l'accs la
ressource est permis, mais que celle-ci n'a pas t modifie depuis la date et l'heure
prcise dans le champ If-Modified-Since de la requte. Le serveur n'met aucune entit
lie ce message. L'en-tte contiendra des informations destination du gestionnaire de
cache, ou ayant t modifies sans que cela n'intervienne sur la date de dernire
modification de la ressource elle-mme. On y trouvera par exemple les champs: Date,
Server, et Expires. Un systme de cache recevant ce message devra remettre jour les
entits qu'il gre.
9.4 Erreur client 4xx

La classe 4xx de codes d'tat est dfinie pour rpondre au cas o il semble que le
client ait commis une erreur. Si le client n'a pas encore achev la transmission de sa
requte lorsqu'il reoit le code 4xx, alors il doit cesser toute transmission. Except
lorsque ce code rpond une requte de type HEAD, le serveur pourra y inclure une
entit explicitant la nature de l'erreur, et indiquant s'il s'agit d'une condition d'erreur
temporaire ou permanente. Ces codes sont valides pour tous les types de requte.

Note : Si le client met des donnes, les implmentations de TCP devront s'assurer que le
client a bien mis tous les accuss de rception des paquets transportant la rponse
avant de couper la connexion d'entre. Si le client continue d'envoyer des donnes
alors que le serveur a ferm la liaison, le TCP serveur mettra en retour un paquet RST
(reset), qui risque de stimuler un effacement prmatur de toutes les donnes reues
dans les tampons interne du TCP client (y compris les donnes concernant la rponse)
avant que celles-ci n'aient pu tre transmises l'application HTTP.
400 Requte incorrecte

La requte n'a pu tre reconnue par le serveur pour cause d'une syntaxe incorrecte.
Le client n'est pas sens mettre de nouveau cette requte sans l'avoir corrige au
pralable.
401 Non autoris

La requte demande ncessite une authentification de la part de l'utilisateur. La
rponse doit inclure un champ d'en-tte WWW-Authenticate (Section 10.16) indiquant la
demande d'authentification de la ressource. Le client est sens rpter la demande en
spcifiant un champ d'en-tte d'authentification correct (Section 10.2). Si la requte
comportait dj des donnes d'authentification, la rponse 401 indique les droits sont
actuellement insuffisants pour cette authentification. Si la rponse 401 contient la mme
demande que la rponse prcdente, et l'utilisateur a dj suivi le processus
d'identification au moins une fois, l'entit prsente dans la rponse doit tre prsente
l'utilisateur, dans la mesure o les informations qu'elle contient peuvent tre de nature
expliquer la faute. L'authentification des accs HTTP est dcrite en dtail en Section 11.
403 Interdit
Le serveur a compris la requte, mais refuse de la satisfaire.
Une dmarche d'authentification n'y fera rien et cette requte ne doit pas tre
renouvele. Si la mthode invoque est diffrente de HEAD et le serveur souhaite rendre
public la raison pour laquelle il refuse le traitement, il le fera dans l'entit lie cette
rponse. Ce code d'tat est souvent utilis lorsque le serveur ne souhaite pas s'tendre
sur les raisons pour lesquelles il refuse un accs, ou parce que c'est la seule rponse qui
convienne.
404 Non trouv

Le serveur n'a trouv aucune ressource correspondant l'URI-vise. Aucune indication
n'est donne pour savoir si l'erreur est temporaire ou permanente. Si le serveur ne dsire
pas donner les raisons de l'chec dans ce cas, il peut utiliser le message de code 403
la place de celui-ci.
9.5 Erreur serveur 5xx

Les rponses de code d'tat dbutant par un "5" indiquent une situation dans laquelle
le serveur sait qu'il est la cause de l'erreur, ou est incapable de fournir le service
demand, bien que la requte ait t correctement formule. Si le client reoit cette
rponse alors qu'il n'a pas encore termin d'envoyer des donnes, il doit cesser
immdiatement toute mission vers le serveur. Except lorsque la requte invoque est
de type HEAD, le serveur peut inclure une entit dcrivant les causes de l'erreur, et s'il

s'agit d'une condition permanente ou temporaire. Ces rponses s'appliquent quelque soit
la requte, et ne ncessitent pas de champs d'en-tte particuliers.
500 Erreur serveur interne

Le serveur a t en prsence d'un vnement inattendu, qui l'a empch de traiter la
requte correctement.
501 Non implment

Le serveur ne supporte pas les fonctionnalits requises pour satisfaire la requte. Ceci
est typique du cas o malgr une syntaxe conforme, le serveur ne reconnat pas la
mthode invoque, et ne peut l'appliquer sur aucune ressource.
502 Erreur de routeur

Ce serveur, agissant en tant que proxy ou routeur, a reu une rponse invalide de la
part du serveur amont contact pour satisfaire la requte.
503 Service indisponible

Les serveur ne peut momentanment traiter la requte, pour cause de surcharge ou de
maintenance. Ceci implique une condition de faute temporaire, qui peut disparatre aprs
un certain laps de temps .
Note : L'existence de ce code d'tat 503 n'implique pas que le serveur l'utilise ds qu'il est
surcharg. Certains serveurs dans cette situation refuseront tout bonnement la
connexion.

10. Dfinition des champs d'en-tte
Cette section dcrit la syntaxe et la smantique des champs d'en-tte essentiels

utiliss dans le cadre d'HTTP/1.0. Pour les champs gnraux et d'entit, l'metteur et le
rcepteur peuvent tour tour dsigner le client ou le serveur, suivant celui qui est
l'origine de la transaction.
10.1 Allow
Le champ Allow (entit) liste l'ensemble des mthodes supportes par la ressource
dsigne par l'URI-vise. La fonction de ce champ est simplement d'informer le rcepteur
sur les mthodes qu'il peut utiliser sur la ressource. Ce champ n'est pas autoris dans un
requte de type POST, et doit tre ignor s'il apparat dans ce dernier cas.
Allow = "Allow" ":" 1#mthode
Exemple:
Allow: GET, HEAD
Ce champ ne pourra prvenir le client de tenter d'appliquer d'autres mthodes que

celles acceptes par la ressource. Il n'est l qu' titre informatif. Les mthodes acceptes
sont dfinies par le serveur origine pour chaque requte reue.
Un proxy ne doit pas modifier le champ d'en-tte Allow mme s'il ne connat pas toutes
les mthodes spcifies, car l'utilisateur peut avoir sa disposition d'autres moyens de
communiquer avec le serveur origine.
Le champ d'en-tte Allow n'indique pas si les mthodes indiques sont implmentes
par le serveur (seulement si elles sont priori acceptables par la ressource).
10.2 Authorization
Un utilisateur dsireux de s'identifier auprs d'un serveuren gnral, mais pas
ncessairement, aprs rception d'une rponse 401peut le faire en incluant un champ
d'en-tte Authorization dans sa nouvelle requte. Ce champ contiendra les donnes
d'autentification de l'utilisateur pour la ressource considre.
Authorization = "Authorization" ":" donnes_identification

L'authentification de connexions HTTP est dcrite en Section 11. Si la requte est

authentifie, et un domaine d'accs attribu, les mmes paramtres d'authentification
seront reconnus pour toute autre ressource appartenant ce domaine.
Les rponses une requte contenant des donnes d'identification ne peut tre
enregistre en cache.
10.3 Content-Encoding
Le champ Content-Encoding (entit) est utilis pour complter l'information de type de
mdia. Lorsqu'il est prsent, il indique sous quel codage la ressource est enregistre, et
par voie de consquence, quel traitement doit tre opr sur l'entit pour pouvoir exploiter
celle ci sous son type de mdia original, dfini dans le champ d'en-tte Content-Type. Le
champ Content-Encoding a t l'origine intaur pour permettre la mise disposition de
ressource sous forme compresses, de sorte qu'il soit possible d'en connatre le type de
mdia d'origine.
Content-Encoding = "Content-Encoding" ":" type_codage
Les valeurs actuellement reconnues sont dcrites en Section 3.5. Exemple:
Content-Encoding: x-gzip
Le type d'encodage est une caractristique de la ressource identifie par l'URI-vise.

Typiquement, la ressource est enregistre encode, et le dcodage ne se fera qu'
l'utilisation finale de celle-ci.
10.4 Content-Length
Le champ d'en-tte Content-Length (entit) indique la taille du corps d'entit, sous la
forme d'un nombre d'octets exprim en dcimal, envoy au rcepteur. Dans le cas d'une
requte de type HEAD, il renvoie la taille du corps d'entit que le serveur aurait renvoy
si la ressource avait fait l'objet d'une requte GET.
Content-Length = "Content-Length" ":" 1*DIGIT
Exemple:
Content-Length: 3495
Les applications utiliseront ce champ pour transmettre la taille de l'entit jointe,

indpendamment du type de mdia de l'entit. Un champ Content-Length avec une valeur
valide est obligatoire dans toute requte HTTP/1.0 contenant un corps d'entit.
Toute valeur numrique suprieure ou gale zro est valide. La section 7.2.2 decrit
comment valuer la taille d'un corps d'entit de rponse, si ce champ est omis.
Note: La signification de ce champ est lgrement diffrente de celle de son quivalent MIME,
lequel est un champ optionnel dfini l'intrieur du type "message/external-body".
Pour HTTP, il doit tre prcis mme si la longueur du corps d'entit peut tre connu
avant la transmission.

10.5 Content-Type
Le champ d'en-tte Content-Type (entit) indique le type de mdia envoy au
rcepteur dans le corps d'entit, ou, si la mthode invoque est HEAD, le type de mdia
du corps d'entit qui aurait t envoy si la ressource avait fait l'objet d'une requte de
type GET.
Content-Type = "Content-Type" ":" type_de_mdia
Les types de mdia sont dfinis en Section 3.6. Exemple:
Content-Type: text/html
Une prsentation d'autres mthodes pour identifier le type de mdia est donne en
Section 7.2.1.
10.6 Date
Le champ d'en-tte Date (gnral) donne la date et l'heure laquelle le message a t
"rdig", et utilise la smantique de dates de la RFC 822. La valeur de ce champ est une
date dans un des formats HTTP dcrits la Section 3.3.
Date = "Date" ":" date_HTTP
Exemple:
Date: Tue, 15 Nov 1994 08:12:31 GMT
Si un message est reu en direct du client (pour les requtes) ou du serveur origine
(pour les rponses), on peut affirmer qu'il s'agit aussi de la date d'arrive au rcepteur.
En outre, dans la mesure o la date dlivre par l'origine est un paramtre
important pour tout ce qui touche la gestion des caches, il est vivement conseill que
les serveurs origine renseignent systmatiquement ce champ la constitution de tout
message. Les clients peuvent se limiter l'envoi d'une date lorsque la requte contient un
corps d'entit, comme dans le cas d'une requte POST, et encore cette pratique n'est pas
obligatoire. Un message reu et non dat se verra assigner une date par le rcepteur si
ce message doit tre enregistr en cache ou rerout via un protocole qui exige une Date.
En thorie, la date doit reprsenter l'instant juste avant l'mission. En pratique, c'est
la constitution du message que la date est inscrite.
10.7 Expires
Le champ d'en-tte Expires (entit) indique la date et l'heure partir de laquelle le
message doit tre considr comme obsolte. Ceci permet de suggrer la notion de
"validit temporaire" de l'information. Les applications ne doivent pas enregistrer ces
entits dans leur cache aprs la date spcifie. Le prsence d'un champ Expires ne
signifie pas que la ressource originale n'a pas chang ou n'existe plus cette date, avant,
ou aprs cette date. Cependant, tout serveur sachant, ou pouvant supposer que cette
ressource aura chang une certaine date devra de prfrence inclure un champ Expires

avec cette date. Le format de la date mentionne est une date absolue telle que dfinie
la Section 3.3.
Expires = "Expires" ":" date-HTTP
Exemple:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Si la date indique dans ce champ est gale ou antrieure la date mentionne dans
le champ date du mme en-tte, 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 rsultats de processus gnrateurs de donnes, les entits
produites se verront attribues un champ Expires renseign d'une faon correspondante
ce "dynamisme".
Le champ Expires ne peut pas tre utilis pour forcer un client rafrachir ou recharger
une ressource. Sa smantique ne concerne que les mcanismes de gestion du cache,
lesquels n'utilisent ce paramtre que pour savoir si le serveur peut encore utiliser
l'instance cache lorsqu'une requte destine ce document est nouveau prsente.
Les clients HTTP disposent souvent d'un mcanisme d'historique, implment sous
forme d'un bouton "Back" et/ou d'une liste de "documents prcdents", utiliss pour
recharger un document prcdemment charg pendant la session courante. Par dfaut, le
champ Expires n'influe pas sur ces mcanismes. Si l'entit est stocke par un tel
mcanisme, elle pourra tre recharge mme si sa date d'expiration est passe, sauf si
l'utilisateur a explicitement configur le client pour rgnrer les documents ayant expir.
Note : Il est encourag que les applications fassent preuve d'une certaine tolrance quant
des implmentations errones ou incompltes du champ Expires. Une valeur zro (0)
ou une date prsente sous un mauvais format signifient "expiration immdiate". Bien
que ces valeurs ne soient pas valides dans le cadre d'HTTP/1.0, une implmentation
tolrante est toujours souhaitable.
10.8 From
Le champ d'en-tte From (requte), si prsent, devra contenir l'adresse e-mail Internet
de l'utilisateur "humain" contrlant le client metteur de la requte. Cette adresse doit tre
code sous une forme utilisable par les machines, telle que dfinie dans la RFC 822 [7]
(et RFC 1123 [6]):
From = "From" ":" adresse_mail
Exemple:
From: webmaster@w3.org
Ce champ est exploit des fins de statistiques, et pour identifier la source de

requtes non valides ou non autorises. Il ne doit cependant pas tre utilis dans un
contexte de scurisation d'accs. Il doit tre interprt comme l'identification de la
personne ayant formul la requte, et qui accepte la responsabilit de la mthode

employe. En particulier, les robots devront renseigner ce champ afin que son
responsable d'exploitation puisse tre contact en cas de dysfonctionnement l'autre
extrmit.
L'adresse e-mail Internet dans ce champ doit tre spar de la mention du nom de
l'ordinateur d'o a t mis la requte. Par exemple, lorsque la requte a transit par
l'intermdiaire d'un proxy, l'adresse de la source originale doit y tre mentionne.
Note : Le client ne peut donner de valeur pour ce champ Form sans l'autorisation de
l'utilisateur, car cette information rentre dans le cadre de la protection des donnes
prives et des droits individuels. Il est fortement recommand que le client laisse le
choix l'utilisateur de pouvoir activer, dsactiver, et modifier la valeur mise dans ce
champ avant mission de toute requte.
10.9 If-Modified-Since
Le champ d'en-tte If-Modified-Since (requte) est utilis lors d'une requte de type
GET pour en mettre une forme conditionnelle: Si la ressource vise n'a pas t modifie
depuis la date mentionne dans ce champ, la copie de la ressource ne sera pas renvoye
par le serveur; En lieu et place, une rponse de type 304 (non modifi) sera renvoye
sans aucun corps d'entit associ.
If-Modified-Since = "If-Modified-Since" ":" date_HTTP
Exemple:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Une mthode GET conditionnelle requiert la transmission d'une ressource uniquement

si celle-ci a t modifie aprs la date indique dans le champ If-Modified-Since.
L'algorithme utilis pour dterminer cette condition prend en compte les cas suivants:
a) Si la rsolution de la requte conduit une rponse autre que 200 (OK), ou si la date
passe par le champ If-Modified-Since n'est pas valide, la rponse sera alors donne
comme si la mthode invoque tait un GET standard. Une date postrieure la date
courante du serveur est non valide.
b) Si la ressource a t modifie aprs la date If-Modified-Since, la rponse sera donne
comme dans le cas d'une mthode GET standard.
c) Si la ressource n'a pas t modifie depuis la date If-Modified-Since, et cette date est
valide, le serveur renverra une rponse 304 (non modifi).
Le but de cette implmentation est de permettre une remise jour efficace des
informations en cache, en rduisant au maximum les transactions rseau.
10.10 Last-Modified
Le champ d'en-tte Last-Modified (entit) indique la date et l'heure laquelle le
serveur pense que la ressource vise a t modifie pour la dernire fois. La smantique
exacte de ce champ dpend fortement de la manire dont le rcepteur va le comprendre:
Si le rcepteur dispose d'une copie de cette ressource d'une date infrieure celle

mentionne dans le champ Last-Modified, cette copie devra tre considre comme
obsolte.
Last-Modified = "Last-Modified" ":" date_HTTP
Exemple:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
La signification exacte de cette information dpend de l'implmentation de l'metteur et

de la ressource laquelle elle s'applique. Pour des fichiers, il s'agira de la date de
dernire modification donne par le gestionnaire de fichier du systme d'exploitation.
Pour des entits incluant des parties gnres dynamiquement, cette date peut tre plus
rcente que les dates de dernire modification de chacune de ses parties. Pour des
routeurs vers des bases de donnes, il pourra s'agir de la dernire tiquette de date
associe l'enregistrement. Pour des objets virtuels, il pourra s'agir de la dernire date
laquelle l'tat interne de l'objet a chang.
Un serveur origine ne doit pas envoyer de date Last-Modified postrieure 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.
10.11 Location
Le champ d'en-tte Location (rponse) renvoie la localisation exacte de la ressource
identifie par l'URI-vise de la requte. Pour des rponses 3xx, ce champ indique l'URL
"de prfrence" donne par le serveur pour la fonction de redirection automatique. Une
seule URI absolue peut tre mentionne la fois.
Location = "Location" ":" URI_absolue
Exemple:
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
10.12 Pragma
Le champ d'en-tte Pragma (gnrale) est utilis pour transmettre des directives
dpendantes de l'implmentation tous les agents de la chane de requte/rponse.
Toutes les directives Pragma spcifient un comportement particulier optionnel de la part
des agents vis vis du protocole; cependant, certains systmes ne pourront rpondre
toutes les directives.
Pragma = "Pragma" ":" 1#directive_pragma
directive_pragma = "no-cache" | pragma

pragma = nom_de_pragma [ "=" mot ]

Lorque la directive "no-cache" est prsente dans un message de requte, les

applications doivent rpercuter la requte jusqu'au serveur origine, mme si elles
disposent d'une copie de la ressource en cache. Ceci permet au client de forcer la
rcupration d'une "premire copie" d'une ressource. Ceci permet de plus de demander
au client une remise jour de copies caches, dans le cas o ces copies se sont avres
dfectueuses, ou obsoltes.
Les directives Pragma doivent tre rmises 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 chane de requte/rponse. Il n'est pas possible
de dfinir un pragma ne concernant qu'un intermdiaire donn dans la chane;
Cependant, toute directive non reconnue par l'un des rcepteurs sera ignore.
10.13 Referer
Le champ d'en-tte Referer (requte) permet au client d'indiquer, l'usage du serveur,
l'adresse (URI) de la ressource dans laquelle l'URI-vise a t trouve. Ceci permet au
serveur de gnrer et entretenir des listes de "rtro-liens" destines renseigner les
clients futurs sur des "sites intressants", ou but d'archivage et d'analyse, optimisation
de cache, etc. Il permet aussi l'analyse de liens obsoltes ou de type incorrect but de
maintenance. Le champ Referer ne doit pas tre inscrit si la source de l'URI-vise
provient d'une entit n'ayant pas d'URI propre, comme l'entre 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 donne, elle se rfrera relativement l'URI-vise. L'URI donne
en rfrence ne doit pas inclure de fragment.
Note : Dans la mesure o la rfrence d'un lien est une information qui peut avoir un
caractre priv, ou tre amene rvler une information prive, il est recommand de
laisser le choix l'utilisateur final de renseigner ou non ce champ. Par exemple, un
navigateur pourra disposer d'un commutateur qui permettra une navigation ouverte
ou anonyme, qui simultanment peut activer ou dsactiver l'mission des champs
Referer et Form.
10.14 Server
Le champ d'en-tte Server (rponse) contient des informations sur le logiciel utilis par
le serveur origine pour traiter la requte. Ce champ peut contenir plusieurs noms de
produits diffrents (Section 3.7) ainsi que des commentaires identifiant le serveur et des
"sous-composants" des applications. Par convention, les noms sont lists par ordre
d'importance, eu gard l'identification du produit utilis.
Server = "Server" ":" 1*( produit | commentaire )
Exemple:
Server: CERN/3.0 libwww/2.17

Si la rponse est transmise via un proxy, ce dernier ne doit pas ajouter ses propres
commentaires la liste.
Note : La rvlation du nom et de la version du logiciel serveur peut prsenter le risque de

permettre des attaques extrieures contre telle ou telle application dont les "portes
drobes" sont connues. Les dveloppeurs de serveurs auront tout intrt laisser
l'mission de cette information optionnelle.
10.15 User-Agent
Le champ d'en-tte User-Agent (requte) contient des informations sur l'utilisateur
metteur de la requte. Cette information est utilise des fins statistiques, pour tracer
des violations de protocole, et des fins de reconnaissance automatique d'utilisateur
permettant de formater la rponse de la manire la plus adapte. L'usage de ce champ,
bien que non indispensable, est cependant conseill. Le champ User-Agent peut
mentionner plusieurs noms de produits (Section 3.7) ainsi que des commentaires
identifiant le programme ou des sous-composants de ce programme dans la mesure o
ceux-ci peuvent tre significatifs pour le serveur. Par convention, ces informations sont
listes par ordre d'importance.
User-Agent = "User-Agent" ":" 1*( produit | commentaires )
Exemple:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Note : Certains proxies ajoutent leur propre information ce champ. Ceci est dconseill,
dans la mesure o le contenu final de ce champ peut alors devenir ambigu, voire
confus.
10.16 WWW-Authenticate
Le champ d'en-tte WWW-Authenticate (rponse) doit tre inclus dans des rponses
de type 401 (non autoris). La valeur du champ consiste en un ou plusieurs "modles"
d'identification pour l'URI-vise.
WWW-Authenticate = "WWW-Authenticate" ":" 1#modle
Le processus d'identification et d'authentification d'accs HTTP est dcrit en Section

11. Les applications utilisatrices doivent interprter avec circonspection la valeur d'un
champ WWW-Authenticate lorsqu'il prsente plus d'un modle d'authentification, ou si
plusieurs champs WWW-Authenticate apparaissent dans l'en-tte, le contenu d'un
modle pouvant lui mme apparatre comme une liste de paramtres spars par une
virgule.

11. Authentification d'accs sous HTTP
HTTP propose un mcanisme simple de "modle-accrditif" pour permettre un

serveur de fournir un modle d'identification et d'authentification un client, et un client
de s'authentifier pour une requte particulire. Ce mcanisme utilise un systme de noms
extensible et indpendant de la casse, dans le but d'identifier le schma
d'authentification, suivie d'une liste de paires "attribut/valeur" spares par des virgules,
destines transmettre les paramtres ncessaires pour achever l'authentification.
Scheme-auth = nom_de_scheme
param-auth = nom_param "=" chane entre guillemets
Le message de rponse 401 (non autoris) est utilis par un serveur origine pour
soumettre le "modle" d'authentification un client. Cette rponse doit comporter un
champ d'en-tte WWW-Authenticate proposant au moins un modle valide pour la
ressource atteindre.
Modle = scheme-auth 1*SP domaine_valide *( "," param-

auth )
domaine_valide = "realm" "=" espace_domaine

espace-domaine = chane entre guillemets
L'attribut de domaine (indpendant de la casse) est requis dans tous les schmes
d'authentification qui soumettent un modle. L'espace de domaine (indpendant de la
casse), combin l'URL canonique du serveur origine, dfinit l'espace protg. Cette
technique permet de partitionner un serveur protg en plusieurs sous ensembles,
protgs individuellement, chacun avec leur propre modle et leurs propres paramtres
d'autorisation lies ou non une base de donne d'authentification. Le domaine
accessible est exprim sous forme de chane de caractres, en gnral donne par le
serveur origine, avec ventuellement une smantique supplmentaire dpendant du
modle d'authentification.
Un utilisateur dsireux de s'authentifier auprs d'un serveur en gnral, mais pas
ncessairement, aprs avoir reu une rponse 401peut le faire en spcifiant un champ
Authorization dans l'en-tte de sa requte. La valeur dans le champ Authorization
consiste contient l'accrditif ncessaire l'accs au domaine autoris pour la ressource
vise.

accrditif = accrditif_de_base | ( modle_authentification#paramtres

)
Le domaine accessible par un utilisateur utilisant cet accrditif est dtermin par les
donnes de protection du serveur. Si une requte prcdente abouti une autorisation
d'accs, le mme accrditif donnera accs au mme domaine accessible durant un temps
dtermin par le modle d'authentification, ses paramtres, et/ou les prfrences
utilisateur. Sauf mention explicite dans le modle, un espace protg ne peut sortir du
cadre du serveur qui le gre.
Si le serveur refuse l'accs une requte, il dlivrera en retour une rponse 403
(accs interdit).
Le protocole HTTP n'exclut pas l'utilisation de schmas de protection additionnels,
venant complter ou remplacer le paradigme "modle-accrditif". D'autres mcanismes,
tels que le cryptage au niveau "transport" ou l'encapsulation de messages, peuvent tre
utiliss avec des champs d'en-tte additionnels vhiculant les informations
d'authentification. Ces mcanismes ne sont toutefois pas dcrits dans cette spcification.
Les proxies doivent tre compltement transparents vis vis du mcanisme
d'authentification. C'est dire qu'ils doivent retransmettre les champs WWW-Authenticate
et Authorization tels que, et ne doivent pas enregistrer une rponse 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.
11.1 Modle d'authentification de base

Le modle dit "de base" demande un utilisateur de s'authentifier par un user-ID et un
mot de passe pour chaque "domaine d'accs". La donne d'authentification doit
reprsenter comme une chane non visible, pouvant seulement tre compare d'autres
accrditifs de rfrence par le serveur concern. Le serveur n'autorisera l'accs que si et
l'user-ID, et le mot de passe correspondent un schme d'authentification dfini pour le
domaine auquel appartient l'URI-vise. Il n'y a pas de paramtres optionnels pour ce
modle.
Sur toute rception d'une requte non autorise visant une URI dans l'espace protg,
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-vise,

attribu par le serveur.
Pour obtenir l'autorisation d'accs, le client enverra l'user-ID et le mot de passe,

sparats par un "deux-points" (":"), le tout encod en base64 [5].
Accrditif_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 ] ":" *TEXT

Si le client voulait utiliser l'user-ID "Aladdin" et le mot de passe "open sesame", il

spcifierait le champ ainsi:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Le modle de base ci-dfini est une mthode non scurise de filtrage d'accs des
ressources donnes 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
rseaux ouverts, et ce modle doit tre utilis en connaissance de cause. Malgr cette
faiblesse, les clients devront implmenter ce modle afin de pouvoir communiquer avec
les serveurs qui l'utilisent.

12. Scurit
Cette section est une information destination des dveloppeurs d'applications,

hbergeurs de donnes, et des utilisateurs, concernant les limites de scurisation
atteintes par HTTP/1.0 tel que dcrit dans ce document. La discussion suivante ne
prtend pas apporter de solution oprationnelle aux dfauts qui y sont rvls, bien que
quelques suggestions y soient faites pour rduire le risque informatique.
12.1 Authentification des clients

Comme le mentionne la Section 11.1, le modle d'authentification "de base" n'est pas
une mthode infaillible pour prvenir des accs non autoriss. Il ne peut non plus
empcher la transmission du corps d'entit "en clair" sur le rseau physique utilis
comme porteuse. HTTP/1.0 n'interdit aucunement l'emploi d'autres modles, ou autres
mcanismes de protection afin d'accrotre la scurit de transmission.
12.2 Mthodes sres

Les diteurs de logiciels clients doivent garder l'esprit que leur application reprsente
l'utilisateur dans ses interactions avec Internet, et doivent de ce fait s'assurer que
l'utilisateur sera averti de toute action que l'application peut entamer, et susceptible
d'avoir un rsultat inattendu, tant pour eux que pour les tiers.
En particulier, il a t tabli par convention que les mthodes GET et HEAD ne
peuvent signifier autre chose qu'une demande de rcupration de ressource. Ces
mthodes peuvent tre considres comme "sres". Ceci laisse la possibilit aux clients
d'implmenter d'autres mthodes (ex. POST) sous une forme spcifique, mais toujours
condition que l'utilisateur puisse tre averti qu'une action peu sre 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 requte GET; en fait, certaines ressources dynamiques tirent
avantage de cette possibilit. La seule distinction de taille est que l'utilisateur qui met
une requte sre de type GET n'a pas "dans l'intention" de provoquer ces effets de bord.
Il ne peut donc en tre tenu pour responsable.
12.3 Abus de l'information Server Log Information

Un serveur a toute possibilit de stocker des donnes personnelles contenues dans les
requtes telles qu'adresses et modles d'accs ou en dduire et archiver des conclusions

personnelles sur les gots, les tendances ou les centres d'intrt des utilisateurs. Ces
informations sont par nature typiquement confidentielles et peuvent tomber sous le coup
de la loi dans certains pays (NdT: typiquement dans le cadre de la loi "informatique et
liberts", dans la mesure o un archivage systmatique et une interprtation
"sociologique" nominative sont raliss). Les personnes utilisant le protocole HTTP pour
diffuser des donnes ont la responsabilit de s'assurer que toute information reue
pouvant identifier et classifier les visiteurs ne puissent tre communique sans l'accord
de ces derniers.
12.4 Transfert d'information sensible

Comme tout protocole de transmission de donne de base, HTTP ne peut contrler la
nature des informations transmises. Il n'est pas non plus possible priori de dterminer la
"sensibilit" de certaines portions de donnes transmises dans le cadre d'une requte
quelle qu'elle soit. C'est pourquoi les applications devront prendre en charge la plus
grande part du contrle de ces informations en lieu et place du diffuseur. Trois champs
d'en-tte sont particulirement concerns par cette notion: Server, Referer et From.
Rvler la version exacte du logiciel serveur peut rendre celui-ci vulnrable aux
attaques si le logiciel est rput avoir des faiblesses en termes de scurit. Le
renseignement du champ Server doit de ce fait rester optionnel, et ne doit pas forcment
tre systmatique.
Le champ Referer autorise l'tude d'un certain nombre d'informations propos de la
requte et permet de "remonter" une chane de liens. Bien que cette fonction soit trs
utile, il est possible nanmoins d'en abuser si les informations sur l'utilisateur ne sont pas
dissocies de celles contenues dans le Referer. Mme lorsque ces informations
"personnelles" sont enleves, 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 dfense des
droits privs, ou peut diminuer le degr de scurit du serveur dans lequel la ressource
est mise de ce fait, toute implmentation devra laisser la possibilit l'utilisateur
d'mettre, ne pas mettre, ou modifier les donnes dans ce champ. L'utilisateur devra
tre en mesure de configurer une valeur "par dfaut" ou une "prfrence utilisateur" pour
les donnes dans ce champ.
Nous suggrons, mais n'imposons pas, qu'un interrupteur graphique soit implment
sur l'interface utilisateur pour permettre ou interdire l'envoi des informations From et
Referer.
12.5 Attaques sur les Fichiers et Rpertoires

Les implmentations des serveurs origine HTTP devront veiller restreindre la
transmission des documents demands par une requte HTTP aux seuls documents
autoriss par l'administration systme. Si un serveur HTTP traduit les URI HTTP
directement en appels systme de fichiers, le serveur devra veiller ne pas livrer de
documents destins autre chose qu'un client HTTP. Par exemple, Unix, Microsoft
Windows, et d'autres systmes d'exploitation utilisent ".." comme accs symbolique au
rpertoire de niveau suprieur. Sur un tel systme, un serveur HTTP doit refuser une telle
construction dans l'URI-vise, interdisant ainsi l'accs potentiel des donnes qui ne
sont pas senses tre diffuses par un serveur HTTP. De mme, tous les fichiers usage
interne au serveur (fichiers de contrle d'accs, de configuration, et codes script) doivent

tre protgs contre toute diffusion, dans la mesure o ils peuvent contenir des
informations essentielles et confidentielles. L'exprience a montr que des imperfections
mineures du logiciel serveur ont pu conduire un rel risque en terme de scurit.

13. Crdits
Cette spcification utilise abondamment le format BNF tendu et les constructions

gnriques dfinies par David H. Crocker pour la RFC 822 [7]. De plus, elle rutilise de
nombreuses dfinitions tablies par Nathaniel Borenstein et Ned Freed pour la dfinition
des MIME [5]. Nous esprons que cette utilisation permettra de lever les confusions entre
la smantique HTTP/1.0 et les formats de message du service "courrier lectronique".
Le HTTP protocole a volu considrablement ces quatre dernires annes. Il a
bnfici de la rflexion d'une large et dynamique communaut de dveloppeurs les
nombreuses personnes qui ont particip aux groupes de travail du WWW laquelle a t
largement responsable du dveloppement fulgurant d'HTTP et du World-Wide Web en
gnral. Nous dcernons Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob
Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Hkon 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 dfinition des toutes premires
spcifications ayant servi de base la prsente.
Paul Hoffman aura contribu aux sections informatives de ce document et aux
Appendices C et D.
Ce document a bnfici des nombreuses remarques et objections de la grande
majorit des participants au HTTP-WG. Outre les personnes dj mentionnes, les
personnes suivantes ont collabor l'achvement de cette spcification:
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
Franois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin

14. Bibliographie
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and
B. Alberti, "The Internet Gopher Protocol: A distributed document
search and retrieval protocol", RFC 1436, University of Minnesota,
March 1993.
[2] Berners-Lee, T., "Universal Resource Identifiers in WWW: A Unifying
Syntax for the Expression of Names and Addresses of Objects on the
Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
[3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language - 2.0",
RFC 1866, MIT/W3C, November 1995.
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
December 1994.
[5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
September 1993.
[6] Braden, R., "Requirements for Internet hosts - application and
support", STD 3, RFC 1123, IETF, October 1989.
[7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages",
STD 11, RFC 822, UDEL, August 1982.
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and
M. Grinbaum. "WAIS Interface Protocol Prototype Functional
Specification." (v1.5), Thinking Machines Corporation, April 1990.
[9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
Irvine, June 1995.
[10]
Horton, M., and R. Adams, "Standard for interchange of USENET
messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell Laboratories, Center
for Seismic Studies, December 1987.
[11]
Kantor, B., and P. Lapsley, "Network News Transfer Protocol: A Proposed
Standard for the Stream-Based Transmission of News", RFC 977, UC San
Diego, UC Berkeley, February 1986.
[12]
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/ISI,

August 1982.
[13]
Postel, J., "Media Type Registration Procedure", RFC 1590, USC/ISI,
March 1994.
[14]
Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC
959, USC/ISI, October 1985.
[15]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/ISI, October 1994.
[16]
Sollins, K., and L. Masinter, "Functional Requirements for Uniform
Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, December 1994.
[17]
US-ASCII. Coded Character Set - 7-Bit American Standard Code for
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[18]
ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.

15. Adresses des auteurs
Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
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

Appendices
Ces appendices ont t ajouts par souci d'information Ils ne forment pas partie
intgrante de la spcification HTTP/1.0.
A. Internet Media Type message/http

Outre la dfinition du protocole HTTP/1.0, ce document sert la spcification de
l'Internet Media Type "message/http". La spcification suivante est enregistre auprs de
l'IANA [13].
Media Type : message
Media subtype : http
Paramtres obligatoires: none
Paramtres optionnels: version, msgtype
version: Version du protocole HTTP utilis pour le message courant (e.g., "1.0"). Si ce
paramtre est absent, la version peut tre dduite par analyse de la premire ligne du
corps.
msgtype: Le type de message -- "request" ou "response". Si ce paramtre est absent, la

version peut tre dduite par analyse de la premire ligne du corps.
Considrations d'encodage: seulement "7bits", "8bits", ou "binary" permis
Considrations en termes de scurit: aucune
B. Applications tolrantes
Bien que ce document donne toutes les spcifications pour la gnration de messages
HTTP/1.0, toutes les applications ne prsenteront pas une implmentation correcte. Nous
recommandons de ce fait que les applications oprationnelles puissent tolrer certaines
dviation de ce protocole, dans la mesure o celles-ci gardent un caractre univoque.
Les clients devront faire preuve de tolrance dans l'interprtation de la ligne d'tat. Les
serveurs devront leur tour se montrer ouverts dans l'interprtation de la ligne de

Requte. En particulier, ils devront accepter tout nombre d'espaces ou de tabulations

entre les champs, mme lorsqu'un espace simple est requis.
La fin de ligne dans les en-ttes HTTP est marque par la squence CRLF.
Cependant, nous conseillons aux applications interprtant de telles en-ttes de
reconnatre une fin de ligne sur LF simple en ignorant le CR de tte.
C. Relations avec les MIME

HTTP/1.0 utilise de nombreuses syntaxes dj employes pour le Mail Internet (RFC
822 [7]) et entre autres les Multipurpose Internet Mail Extensions (MIME [5]) permettant
aux entits d'tre transmises sous une grande quantit de formes tout en respectant le
principe d'volutivit. Cependant, la RFC 1521 concerne le mail, et HTTP implmente
certaines fonctions d'une faon diffrente de la RFC 1521. Ces diffrences ont t
soigneusement contrles afin d'optimiser la transmission en mode binaire, pour ouvrir le
champ d'application offert par des nouveaux types de mdia, pour faciliter la comparaison
de dates, tout en restant compatibles avec des serveurs et clients HTTP antrieurs.
A cette heure, nous esprons une rvision de la RFC 1521. Cette rvision pourrait
intgr quelques unes des pratiques utilises par HTTP/1.0 mais ne faisant pas partie de
la RFC 1521.
Cet appendice dcrit les points spcifiques pour lesquels HTTP et la RFC 1521
diffrent. Les proxies et routeurs dirigeant des messages HTTP vers un environnement
MIME strict devront connatre ces diffrences et propose une conversion approprie si
ncessaire. A l'inverse Les proxies et routeurs accdant un environnement HTTP
partir d'un environnement MIME strict, devront de mme se charger de la conversion, et
donc connatre ces diffrences.
C.1 Conversion vers la forme canonique

La RFC 1521 impose qu'une entit Internet Mail soit convertie dans sa forme
canonique avant d'tre transmise, (Appendice G de la RFC 1521 [5]). La Section 3.6.1 de
ce document dcrit toutes les formes admises du sous-type "texte" transmis sous HTTP.
La RFC 1521 impose que le contenu d'un message dont le Content-Type est "text"
reprsente les fins de ligne par la squence CRLF et interdise l'usage de CR ou de LF en
dehors de ce contexte de fin de ligne. HTTP permet l'usage de squences 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 concerns par la Section 3.6.1 dans ce document en forme canonique selon
la RFC 1521: une squence CRLF. Notez, cependant, que cette rgle peut se compliquer
dans le cas o un champ Content-Encoding est prsent et par le fait qu'HTTP permettent
l'utilisation de tables de caractres tant que le caractre 13 et 10 continuent reprsenter
les quivalents de CR et LF (comme c'est le cas pour certaines tables utilisant plusieurs
octets par caractre).
C.2 Conversion de formats de dates

HTTP/1.0 utilise un ensemble de formats de date restreint (Section 3.3) pour simplifier
l'implmentation des comparaisons de date. Les proxies et routeurs agissant partir
d'autres protocoles devront s'assurer que tout champ d'en-tte de Date dans un message

reste conforme l'un des formats reconnus par HTTP/1.0, et rcriront les dates si
ncessaire.
C.3 Introduction du champ Content-Encoding

La RFC 1521 n'introduit aucun concept quivalent au champ d'en-tte Content-
Encoding dfini par HTTP/1.0. Comme celui-ci fait fonction de modificateur du type de
mdia, les proxies et routeurs depuis HTTP vers des protocoles compatibles MIME
doivent soit changer la valeur indique dans le champ Content-Type, soit analyser le
corps d'entit avant de faire suivre le message. (Certaines implmentations
exprimentales du champ Content-Type pour la messagerie Internet ont utilis une valeur
";conversions=<content-coding>" pour obtenir une fonction similaire celle procure par
le champ Content-Encoding. Ce paramtre n'est pas officiel dans la RFC 1521.)
C.4 Pas de champ Content-Transfer-Encoding

HTTP n'exploite pas le champ Content-Transfer-Encoding (CTE) utilis par la RFC
1521. Les proxies et routeurs depuis un protocole MIME vers un protocole HTTP devront
supprimer tout CTE l'exclusion ventuellement du CTE "identity" ("quoted-printable" ou
"base64") avant de faire suivre le message vers un client HTTP client.
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 scurit sous ce protocole, cette scurit tant naturellement limite aux
limitations propres du protocole utilis. Un tel proxy ou routeur devra ajouter un Content-
Transfer-Encoding appropri, de faon prsenter les donnes conformment aux
attentes de ce protocole.
C.5 Champs d'en-tte HTTP dans des parties de corps Multipart

Sous RFC 1521, la plupart des champs d'en-tte placs dans les sous-parties d'un
corps Multipart sont en gnral ignors sauf si le nom du champ dbute par "Content-".
En HTTP/1.0, les sous-parties de corps Multipart peuvent contenir tout champ d'en-tte
HTTP dont la signification est pertinente pour cette partie de message.
D. Fonctions supplmentaires
Cet appendice liste quelques lments de protocole parfois employs dans certaines
implmentations HTTP, mais qui ne sont pas considres comme "lgitimes" par la
plupart des applications HTTP/1.0. Les dveloppeurs ont un intrt connatre ces
fonctions, mais ne peuvent tre srs de leur prsence effective, ni de leur implmentation
par d'autres applications HTTP/1.0.
D.1 Mthodes de requtes supplmentaires
D.1.1 PUT
La mthode PUT demande ce que l'entit jointe soit enregistre par le serveur sous
l'URI-vise. Si cette URI pointe vers une ressource dj existante, l'entit jointe sera
considre comme une nouvelle version de celle jusqu'alors prsente sur le serveur
origine. Si l'URI-vise pointe sur une ressource inexistante, et la condition que cette
URI puisse tre dfinie en tant que nouvelle ressource du serveur, ce dernier crera une
nouvelle ressource sous cette URI.

La diffrence fondamentale entre les mthodes POST et PUT rside dans la

signification donne l'URI-vise. Celle-ci, pour une mthode POST dsigne la
ressource "active" laquelle l'entit doit tre confie 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 prcise dans une mthode PUT
nomme l'entit incluse dans la requte Le client sait parfaitement de quelle URI il s'agit
et le serveur n'applique la mthode aucune autre ressource.
D.1.2 DELETE
La mthode DELETE demande au serveur de supprimer la ressource pointe par l'URI-
vise.
D.1.3 LINK
La mthode LINK tablit une ou plusieurs liaisons entre la ressource existante dfinie
par l'URI-vise et d'autres ressources.
D.1.4 UNLINK
A contrario, cette mthode supprime des liaisons entre la ressource dfinie par l'URI-
vise, et d'autres ressources qui lui sont lies.
D.2 Dfinitions d'autres champs d'en-tte
D.2.1 Accept
Le champ d'en-tte Accept (requte) peut tre utilis pour dfinir une liste de types de
mdia accepts en rponse la requte. L'astrisque "*" est utilise pour grouper des
types de mdia par classe, "*/*" indiquant tous les types de mdia, et "type/*" indiquant
tous les sous-types du type "type". La gamme de types signale par le client sert
essentiellement limiter les documents des types acceptables par le client dans le
contexte de la requte formule.
D.2.2 Accept-Charset
Le champ d'en-tte Accept-Charset (requte) peut tre utilis pour former une liste de
tables de caractres prfrentielles, autres que les tables US-ASCII et ISO-8859-1
utilises par dfaut. Ce champ permet un client de signaler un serveur qu'il sait
accepter d'autres reprsentations de texte que les reprsentations par dfaut, et est donc
en mesure d'exploiter des documents encods avec ces tables, si le serveur sait les
transmettre.
D.2.3 Accept-Encoding
Le champ d'en-tte Accept-Encoding (requte) est similaire au champ Accept, mais
restreint la gamme de valeurs Content-Coding attendues dans une rponse.
D.2.4 Accept-Language
Le champ d'en-tte Accept-Encoding (requte) est similaire au champ Accept, mais
restreint la gamme de langues attendues dans une rponse.
D.2.5 Content-Language

Le champ d'en-tte Content-Language (entit) dcrit la ou les langues naturelles des

destinataires potentiels du corps d'entit. Notez que ceci n'a aucun lien avec les langues
utilises dans l'ensemble de l'entit.
D.2.6 Link
Le champ d'en-tte Link (entit) permet de dcrire 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 mtainformation, indique typiquement des relations du
type dpendance hirarchique ou des chemins d'accs.
D.2.7 MIME-Version
Les messages HTTP peuvent inclure un champ unique d'en-tte gnrale indiquant
quelle version du protocole MIME a t employ pour construire le message. L'utilisation
de ce champ MIME-Version, tel que dcrit par la RFC 1521 [5], peut indiquer si le
message est compatible MIME. Malheureusement, certaines premires implmentations
de serveurs HTTP/1.0 mettent ce champ sans rserve. Il est conseill de l'ignorer.
D.2.8 Retry-After
Le champ d'en-tte Retry-After (rponse) peut tre utilis dans une rponse 503
(service indisponible) dans le but d'indiquer pendant combien de temps (estim) le
service restera indisponible aux requtes du client. La valeur de ce champ peut tre une
date HTTP ou un nombre entier de secondes (en dcimal) partir de l'heure de la
rponse.
D.2.9 Title
Le champ d'en-tte Title est purement informatif et donne le titre de l'entit.
D.2.10 URI
Le champ d'en-tte URI (entit) peut contenir toute ou partie des Uniform Resource
Identifiers (Section 3.2) par laquelle la ressource dfinie par l'URI-vise peut tre
identifie. Aucune garantie n'est cependant donne que la ressource soit effectivement
accessible par l'une des URI spcifies.

HTTP PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HTTP PDF

Transféré par

Droits d'auteur :

Formats disponibles

Network Working Group T.

French translation by V.G. FREMAUX / Ecole Internationale des Sciences du Traitement

HyperText Transfer Protocol

EISTI / Fremaux 2 W3C / Berners Lee

Table des Matires

EISTI / Fremaux 3 W3C / Berners Lee

EISTI / Fremaux 4 W3C / Berners Lee

C. Relations avec les MIME ...................................................................................................59

EISTI / Fremaux 5 W3C / Berners Lee

EISTI / Fremaux 6 W3C / Berners Lee

EISTI / Fremaux 7 W3C / Berners Lee

1.3 Fonctionnement global

Une situation plus complexe peut apparatre lorsque un ou plusieurs intermdiaires

La figure ci-dessus montre le cas de trois intermdiaires (A, B, et C) entre l'utilisateur

EISTI / Fremaux 8 W3C / Berners Lee

mme passage par un tunnel, et accessible uniquement des extrmits, ou au contraire

1.4 HTTP et MIME

EISTI / Fremaux 9 W3C / Berners Lee

2. Conventions de notation et Grammaire gnrique

2.1 BNF tendue

EISTI / Fremaux 10 W3C / Berners Lee

2.2 Rgles de base

OCTET = <toute donne code sur 8 bits>

EISTI / Fremaux 11 W3C / Berners Lee

LWS = [CRLF] 1*( SP | HT )

TEXT = <tout OCTET sauf CTL, hormis LWS qui reste

HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" |

mot = token | chane entre guillemets

comment = "(" *( ctext | comment ) ")"

quoted-string = ( <"> *(qdtext) <"> )

EISTI / Fremaux 12 W3C / Berners Lee

L'utilisation du backslash ("\") comme squence d'chappement d'un caractre unique

EISTI / Fremaux 13 W3C / Berners Lee

3.1 Numro de Version

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

n reconnatre le format de la ligne de requte HTTP/0.9 et HTTP/1.0

Les clients HTTP/1.0 doivent:

EISTI / Fremaux 14 W3C / Berners Lee

n reconnatre le format de ligne d'tat des rponses HTTP/1.0;

3.2 Uniform Resource Identifiers

3.2.1 Syntaxe gnrale

URI = (URIabsolue | URIrelative ) [ "#" fragment ]

URIabsolue = scheme ":" *( uchar | reserv )

URIrelative = chem_res | chem_abs | chem_rel

chem_res = "//" loc_res [ chem_abs ]

chemin = fsegment *( "/" segment )

params = param *( ";" param )

scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )

pchar = uchar | ":" | "@" | "&" | "=" | "+"

EISTI / Fremaux 15 W3C / Berners Lee

chap = "%" HEX HEX

3.2.2 URL http

http_URL = "http:" "//" host [ ":" port ] [ chem_abs ]

host = <un nom Internet d'ordinateur valide ou une

3.3 Formats de temps et de date

EISTI / Fremaux 16 W3C / Berners Lee

HTTP-date = rfc1123-date | rfc850-date | asctime-date

rfc1123-date = jsem "," SP date1 SP temps SP "GMT"

date1 = 2DIGIT SP mois SP 4DIGIT

temps = 2DIGIT ":" 2DIGIT ":" 2DIGIT

jsem = "Mon" | "Tue" | "Wed"

joursem = "Monday" | "Tuesday" | "Wednesday"

mois = "Jan" | "Feb" | "Mar" | "Apr"

HTTP-Version = "HTTP" "/" 1DIGIT "." 1DIGIT

"HTTP/" 1DIGIT "." 1DIGIT SP 3DIGIT SP