RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS
Une requête d'un client vers un serveur inclue, dans sa première ligne, la méthode appliquée à la ressource, l'identificateur de cette ressource, et la version de protocole courante. Afin d'assurer la compatibilité descendante avec la version plus limitée HTTP/0.9 du protocole, deux formats seront valides pour exprimer une requête:
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.2
Si 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.
La ligne de requête commence par un nom de requête, suivie de l'URI visée, du numéro de version de protocole, et termine enfin par CRLF. Ces éléments sont séparés par des espaces. Aucun CR ni LF n'est autorisé excepté la séquence finale CRLF.
Ligne_requête = Méthode SP URI-visée SP Version-HTTP CRLF
Notez 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.
La méthode indiquée en tête de ligne est destinée à être appliquée à l'URI cible. Son nom dépend de la casse.
Méthode = "GET" ; Section 8.1
| "HEAD" ; Section 8.2
| "POST" ; Section 8.3
| nom_de_méthode
La 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.
L'URI visée est l'URI identifiant la ressource réseau à laquelle doit être appliquée la méthode.
URI-visée = URIabsolue | chem_abs
Ces 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:
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:
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.
Les champs d'en-tête de requête permettent de la transmission d'informations complémentaires sur la requête, et le client lui-même. Ces champs agissent comme "modificateurs" de la requête, utilisant une sémantique identique à celle des paramètres passés par un appel d'une méthode 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-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é.