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