5. Request (Anfrage)
Eine Anfragenachricht vom Client zum Server enthält in der ersten Zeile dieser Nachricht die Methode, die auf die Ressource anzuwenden ist, den Bezeichner der Ressource und die verwendete Protokollversion.
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 (Anfragezeile)
Die Request-Line beginnt mit einem Methoden-Token (method token), gefolgt vom Request-URI und der Protokollversion, und endet mit einem CRLF. Die Elemente werden durch SP-Zeichen getrennt. Außer in der finalen CRLF-Sequenz sind keine CR oder LF erlaubt.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1 Method (Methode)
Das Method-Token gibt die Methode an, die auf der durch den Request-URI identifizierten Ressource ausgeführt werden soll. Die Methode ist case-sensitive.
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
Die Liste der für eine Ressource zulässigen Methoden kann im Allow-Header-Feld (Abschnitt 14.7) angegeben werden. Der Rückgabecode der Antwort informiert den Client immer darüber, ob eine Methode derzeit für eine Ressource zulässig ist, da sich die Menge der zulässigen Methoden dynamisch ändern kann. Der Origin-Server sollte (SHOULD) den Statuscode 405 (Method Not Allowed) zurückgeben, wenn die Methode vom Origin-Server erkannt wird, aber nicht für die angeforderte Ressource zulässig ist, und 501 (Not Implemented), wenn die Methode nicht erkannt oder nicht vom Origin-Server implementiert wird. Alle generischen Server müssen (MUST) die Methoden GET und HEAD unterstützen. Alle anderen Methoden sind optional (OPTIONAL); wenn jedoch die oben genannten Methoden implementiert sind, müssen (MUST) sie mit derselben Semantik wie in Abschnitt 9 angegeben implementiert werden.
5.1.2 Request-URI (Anfrage-URI)
Der Request-URI ist ein Uniform Resource Identifier (Abschnitt 3.2), der die Ressource identifiziert, auf die die Anfrage angewendet werden soll.
Request-URI = "*" | absoluteURI | abs_path | authority
Die vier Optionen des Request-URI hängen von der Art der Anfrage ab. Das Sternchen "*" bedeutet, dass die Anfrage nicht auf eine bestimmte Ressource angewendet wird, sondern auf den Server selbst, und ist nur zulässig, wenn die verwendete Methode nicht notwendigerweise auf eine Ressource angewendet wird. Ein Beispiel ist:
OPTIONS * HTTP/1.1
Die absoluteURI-Form wird verwendet, wenn die Anfrage an einen Proxy gesendet wird. Der Proxy wird aufgefordert, die Anfrage weiterzuleiten oder aus einem gültigen Cache zu bedienen und die Antwort zurückzugeben. Beachten Sie, dass der Proxy die Anfrage an einen anderen Proxy weiterleiten oder direkt an den durch den absoluteURI angegebenen Server weiterleiten kann (MAY), bevor er die Anfrage an den nächsten eingehenden Server weiterleitet. Um Anfrageschleifen zu vermeiden, muss (MUST) ein Proxy in der Lage sein, alle seine Servernamen zu erkennen, einschließlich Aliase, lokaler Varianten und numerischer IP-Adressen. Ein Beispiel für eine Anfrage wäre:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Um den Übergang zur Verwendung von absoluteURI in allen Anfragen zu ermöglichen (zukünftige HTTP-Versionen), müssen (MUST) alle HTTP/1.1-Server die absoluteURI-Form in Anfragen akzeptieren, auch wenn HTTP/1.1-Clients sie nur generieren, wenn sie Anfragen an einen Proxy stellen.
Die authority-Form wird nur von der CONNECT-Methode verwendet (Abschnitt 9.9).
Die häufigste Form des Request-URI wird verwendet, um eine Ressource auf einem Origin-Server oder Gateway zu identifizieren. In diesem Fall muss (MUST) der absolute Pfad des URI als Request-URI übertragen werden, und der Netzwerkstandort muss (MUST) in einem Host-Header-Feld übertragen werden. Zum Beispiel würde ein Client, der eine Ressource direkt vom Origin-Server abrufen möchte, eine TCP-Verbindung zu Port 80 des Hosts "www.w3.org" erstellen und die folgenden Zeilen senden:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
gefolgt vom Rest der Anfrage. Beachten Sie, dass der HTTP-Standardport 80 angenommen wird, wenn keine Portnummer angegeben ist.
Wenn ein Proxy eine solche Anfrage empfängt, muss (MUST) er das Host-Header-Feld zur Anfrage hinzufügen, bevor er sie weiterleitet, es sei denn, es ist bereits vorhanden. (Siehe Abschnitt 14.23 für weitere Details zu Host.)
Wenn der Request-URI mit einem Schrägstrich beginnt, wird er als abs_path behandelt. Der Empfänger muss (MUST) einen leeren abs_path so interpretieren, als ob der abs_path des absoluteURI "/" wäre.
Alle HTTP/1.1-Clients müssen (MUST) ein Host-Header-Feld einschließen, wenn sie HTTP/1.1-Anfragenachrichten generieren. Wenn einer HTTP/1.1-Anfrage ein Host-Header-Feld fehlt, muss (MUST) der Server auf diese Anfrage mit 400 (Bad Request) antworten.
Siehe Abschnitt 5.2 für weitere Details zu Proxy-Anforderungen.
5.2 The Resource Identified by a Request (Die durch eine Anfrage identifizierte Ressource)
HTTP-Origin-Server organisieren ihre Ressourcen normalerweise in einem bestimmten Namensraum (namespace). Der Request-URI identifiziert eine Ressource innerhalb dieses Namensraums. Im Internet sind HTTP-Origin-Server normalerweise über einen Internet-Host zugänglich und werden (wenn sie mit HTTP verwendet werden) als absolute URIs unter Verwendung des "http"- oder "https"-Schemas identifiziert. Ein Origin-Server kann (MAY) einen oder mehrere Namensräume unterstützen und (wenn er mit HTTP verwendet wird) möglicherweise gleichzeitig URIs eines oder mehrerer Schemas unterstützen.
Betrachten Sie die folgende Request-Line:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Der Request-URI identifiziert die Ressource als:
http://www.w3.org/pub/WWW/TheProject.html
Wenn diese Anfrage direkt beim Origin-Server www.w3.org ankommt, sollte (SHOULD) der Server die Operation auf der Ressource am Pfad "/pub/WWW/TheProject.html" auf diesem Server ausführen.
Wenn diese Anfrage bei einem Proxy ankommt, gibt der Request-URI den Origin-Server an, und der Proxy sollte (SHOULD) diesen Server kontaktieren (möglicherweise unter Verwendung seines eigenen Caches, wie in Abschnitt 13 beschrieben). Beachten Sie, dass der vom Client in der Anfrage bereitgestellte URI sich von dem URI unterscheiden kann, den der Server intern zur Identifizierung der Ressource verwendet.
Die genaue Methode der Ressourcenidentifizierung, die von einem Origin-Server im Internet verwendet wird, liegt außerhalb des Anwendungsbereichs dieser Spezifikation. Diese Spezifikation schränkt die Implementierung von HTTP nicht ein, indem sie verlangt, dass die Implementierung ein verzeichnisbasiertes Dateisystem verwendet, um Anfragen zu erfüllen. Nur der von HTTP verwendete URI zur Identifizierung der Ressource für die gegebene Anfrage wird verwendet.
5.3 Request Header Fields (Anfrage-Header-Felder)
Anfrage-Header-Felder ermöglichen es dem Client, zusätzliche Informationen über die Anfrage und über den Client selbst an den Server zu übergeben. Diese Felder fungieren als Anfrage-Modifikatoren mit einer Semantik, die den Parametern eines Methodenaufrufs in einer Programmiersprache entspricht.
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
Anfrage-Header-Feldnamen können nur durch Ändern der Protokollversion zuverlässig erweitert werden. Neue oder experimentelle Header-Felder können jedoch Feldwerten zugewiesen werden, ohne die Protokollversion zu ändern. Nicht erkannte Header-Felder sollten (SHOULD) vom Empfänger als Entitäts-Header-Felder behandelt werden.