5. Request (Requête)
Un message de requête du client vers le serveur inclut, dans la première ligne de ce message, la méthode à appliquer à la ressource, l'identifiant de la ressource et la version du protocole utilisée.
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
5.1 Request-Line (Ligne de Requête)
La Request-Line commence par un jeton de méthode (method token), suivi du Request-URI et de la version du protocole, et se termine par un CRLF. Les éléments sont séparés par des caractères SP. Aucun CR ou LF n'est autorisé, sauf dans la séquence CRLF finale.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1 Method (Méthode)
Le jeton Method indique la méthode à exécuter sur la ressource identifiée par le Request-URI. La méthode est sensible à la casse.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
La liste des méthodes autorisées pour une ressource peut être spécifiée dans le champ d'en-tête Allow (section 14.7). Le code de retour de la réponse informe toujours le client si une méthode est actuellement autorisée sur une ressource, car l'ensemble des méthodes autorisées peut changer dynamiquement. Le serveur d'origine devrait (SHOULD) retourner le code d'état 405 (Method Not Allowed) si la méthode est reconnue par le serveur d'origine mais n'est pas autorisée pour la ressource demandée, et 501 (Not Implemented) si la méthode n'est pas reconnue ou n'est pas implémentée par le serveur d'origine. Tous les serveurs génériques doivent (MUST) prendre en charge les méthodes GET et HEAD. Toutes les autres méthodes sont optionnelles (OPTIONAL) ; cependant, si les méthodes ci-dessus sont implémentées, elles doivent (MUST) l'être avec la même sémantique que celle spécifiée dans la section 9.
5.1.2 Request-URI (URI de Requête)
Le Request-URI est un Uniform Resource Identifier (section 3.2) qui identifie la ressource à laquelle la requête doit être appliquée.
Request-URI = "*" | absoluteURI | abs_path | authority
Les quatre options du Request-URI dépendent de la nature de la requête. L'astérisque "*" signifie que la requête ne s'applique pas à une ressource particulière, mais au serveur lui-même, et n'est autorisée que lorsque la méthode utilisée ne s'applique pas nécessairement à une ressource. Un exemple est :
OPTIONS * HTTP/1.1
La forme absoluteURI est utilisée lorsque la requête est envoyée à un proxy. Le proxy est invité à transférer la requête ou à servir depuis un cache valide, et à retourner la réponse. Notez que le proxy peut (MAY) transférer la requête à un autre proxy ou directement au serveur spécifié par l'absoluteURI avant de transférer la requête au serveur entrant suivant. Pour éviter les boucles de requête, un proxy doit (MUST) être capable de reconnaître tous ses noms de serveur, y compris les alias, les variantes locales et l'adresse IP numérique. Un exemple de requête serait :
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Pour permettre la transition vers l'utilisation d'absoluteURI dans toutes les requêtes (futures versions HTTP), tous les serveurs HTTP/1.1 doivent (MUST) accepter la forme absoluteURI dans les requêtes, même si les clients HTTP/1.1 ne les généreront que lors de requêtes à un proxy.
La forme authority est utilisée uniquement par la méthode CONNECT (section 9.9).
La forme la plus courante de Request-URI est utilisée pour identifier une ressource sur un serveur d'origine ou une passerelle. Dans ce cas, le chemin absolu de l'URI doit (MUST) être transmis comme Request-URI, et l'emplacement réseau doit (MUST) être transmis dans un champ d'en-tête Host. Par exemple, un client souhaitant récupérer une ressource directement depuis le serveur d'origine créerait une connexion TCP au port 80 de l'hôte "www.w3.org" et enverrait les lignes :
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
suivi du reste de la requête. Notez que si aucun numéro de port n'est fourni, le port par défaut pour HTTP est supposé être 80.
Si un proxy reçoit une telle requête, il doit (MUST) ajouter le champ d'en-tête Host à la requête avant de la transférer, sauf s'il existe déjà. (Voir la section 14.23 pour plus de détails sur Host.)
Si le Request-URI commence par une barre oblique, il est traité comme un abs_path. Le destinataire doit (MUST) interpréter un abs_path vide comme si l'abs_path de l'absoluteURI était "/".
Tous les clients HTTP/1.1 doivent (MUST) inclure un champ d'en-tête Host lors de la génération de messages de requête HTTP/1.1. Si une requête HTTP/1.1 manque un champ d'en-tête Host, le serveur doit (MUST) répondre à cette requête avec 400 (Bad Request).
Voir la section 5.2 pour plus de détails sur les exigences du proxy.
5.2 The Resource Identified by a Request (La Ressource Identifiée par une Requête)
Les serveurs d'origine HTTP organisent généralement leurs ressources dans un certain espace de noms (namespace). Le Request-URI identifie une ressource dans cet espace de noms. Sur Internet, les serveurs d'origine HTTP sont généralement accessibles via un hôte Internet et sont identifiés (lorsqu'ils sont utilisés avec HTTP) comme des URI absolus utilisant le schéma "http" ou "https". Un serveur d'origine peut (MAY) prendre en charge un ou plusieurs espaces de noms et (lorsqu'il est utilisé avec HTTP) peut simultanément prendre en charge des URI d'un ou plusieurs schémas.
Considérez la Request-Line suivante :
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Le Request-URI identifie la ressource comme :
http://www.w3.org/pub/WWW/TheProject.html
Si cette requête arrive directement au serveur d'origine www.w3.org, le serveur devrait (SHOULD) effectuer l'opération sur la ressource située au chemin "/pub/WWW/TheProject.html" sur ce serveur.
Si cette requête arrive à un proxy, le Request-URI spécifie le serveur d'origine et le proxy devrait (SHOULD) contacter ce serveur (éventuellement en utilisant son propre cache, comme décrit dans la section 13). Notez que l'URI fourni par le client dans la requête peut différer de l'URI utilisé en interne par le serveur pour identifier la ressource.
La méthode exacte d'identification des ressources utilisée par un serveur d'origine sur Internet est hors du champ d'application de cette spécification. Cette spécification ne limite pas l'implémentation de HTTP en exigeant que l'implémentation utilise un système de fichiers basé sur des répertoires pour satisfaire les requêtes. Seul l'URI utilisé par HTTP pour identifier la ressource pour la requête donnée est utilisé.
5.3 Request Header Fields (Champs d'En-tête de Requête)
Les champs d'en-tête de requête permettent au client de transmettre des informations supplémentaires sur la requête et sur le client lui-même au serveur. Ces champs agissent comme des modificateurs de requête, avec une sémantique équivalente aux paramètres d'un appel de méthode dans un langage de programmation.
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
Les noms de champs d'en-tête de requête ne peuvent être étendus de manière fiable qu'en changeant la version du protocole. Cependant, de nouveaux champs d'en-tête ou expérimentaux peuvent être attribués aux valeurs de champ sans changer la version du protocole. Les champs d'en-tête non reconnus devraient (SHOULD) être traités comme des champs d'en-tête d'entité par le destinataire.