Das Hypertext Transfer Protocol (HTTP) ist ein Anwendungsschicht-Protokoll zum Transportieren von Hypermedia Dokumenten, wie zum Beispiel HTML. Hauptsächlich wird es zur Kommunikation zwischen Webservern und Webbrowsern verwendet, jedoch könnte es theoretisch auch für andere Zwecke benutzt werden. Es folgt einem klassischen Client-Server-Modell, mit einem Client der die Verbindung eröffnet, indem er eine Anfrage macht und dann wartet, bis es eine Antwort erhält. Außerdem ist es ein zustandsloses Protokoll, was bedeutet, dass der Server keine Daten (Zustände) zwischen zwei Anfragen behält.
Obwohl oft auf einer TCP/IP Schicht aufgebaut, könnte es auch auf jede andere verlässliche, verbindungsorientierte Transportschicht aufbauen, sofern sie Nachrichten nicht leise verliert, wie es zum Beispiel bei UDP der Fall ist.
Set-Cookie Header mit der Antwort senden. Danach wird der Cookie-Wert zusammen mit jeder Anfrage an den gleichen Server in Form eines Cookie HTTP-Headers gesendet. Zusätzlich kann eine Verfallsverzögerung angegeben werden. Einschränkungen einer bestimmten Domäne und eines bestimmten Pfades können ebenfalls festgelegt werden.http://domaina.example) geladen wird, eine Anfrage durch Verwendung des img-Elements (http://domainb.foo/image.jpg) nach einem Bild, das auf Domain B (http://domainb.foo) liegt. Dies tritt heutzutage sehr häufig auf — Seiten laden eine Vielzahl an Ressourcen mittels Cross-site-Verfahren, einschließlich CSS-Stylesheets, Bildern, Skripten und anderen Ressourcen.Since its original conception, as a protocol with one single method (GET) and returning only HTML pages, the HTTP protocol went through several revisions. The first documented version was HTTP/0.9 in 1991, corresponding to the original version. Very simple, it has a rudimentary search capability via the HTML {{ HTMLElement("isindex") }} element and an extension of the URL using the '?' character.
Then, in 1992, a version was published that became, with some minor changes, HTTP/1.0 (finalized in RFC 1945 in May 1996). One major improvement over the previous version was the ability to transmit files of different types, like images, videos, scripts, CSS documents, and so on, instead of only HTML files: this is achieved by using MIME types in conjunction with the Content-Type: header.
In 1995, the IETF began developing a new version of HTTP, which would become HTTP/1.1. It quickly spread into wide usage, and it was officially standardized in 1997 in RFC 2068, with minor fixes in RFC 2616 two years later.
HTTP/1.1 brought the ability to reuse established connections for subsequent requests, greatly improving the performance of the protocol by lowering the latency between them; this is especially useful with complex HTML documents that need to fetch several subsequent files, like images or style sheets. It also brought the Host: header, which allows a single server, listening on a specific port, to receive requests for several websites; this paved the way for colocating numerous websites on one single server, greatly reducing the cost of hosting.
Since then, the HTTP protocol evolved by adding new headers, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.
HTTP/1.1 is currently being revised by the IETF HTTPbis Working Group.
Because HTTP is a client-server protocol, an HTTP session consists of three phases:
Starting with HTTP/1.1, the connection is no longer closed after the third phase, as the client is allowed to issue another request at this point: the second and third phases can therefore be done several times.
Because HTTP is a client-server protocol, it always is the client that establishes the connection. Opening a connection in HTTP really is establishing a connection in the underlying transport layer, usually TCP.
With TCP, the default port for an HTTP server on a computer is port 80, though others are often used, like 8000 or 8080. The URL of a page to fetch contains both the domain name and the port number, though the latter can be omitted if it is 80.
Once the connection is established, the user-agent can send its request. (A user-agent is typically a web browser, but need not be.) A client request consists of text directives, separated by CRLF (carriage return, followed by line feed), divided in three blocks:
GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
Note the final empty line, separating the data block from the headers block. As there is no Content-Length: HTTP header, the data block is empty and the server can process the request as soon as it receives the empty line marking the end of the headers.
POST /contact_form.php HTTP/1.1 Host: developer.mozilla.org Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
After the connected agent has sent its request, the web server handles it, and finally sends a response back. Similarly to a client request, a server response is formed of text directives, separated by CRLF, though divided in three different blocks:
HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
HTTP/1.1 301 Moved Permanently Server: Apache/2.2.3 (Red Hat) Content-Type: text/html; charset=iso-8859-1 Date: Sat, 09 Oct 2010 14:30:24 GMT Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p> <hr> <address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address> </body></html>
HTTP/1.1 404 Not Found Date: Sat, 09 Oct 2010 14:33:02 GMT Server: Apache Last-Modified: Tue, 01 May 2007 14:24:39 GMT ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1" Accept-Ranges: bytes Content-Length: 10732 Content-Type: text/html <!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
Persistent connections were introduced in HTTP/1.1. They allow transmitting several requests on the same TCP connection (or on the specific connected transport layer if the HTTP is not built upon TCP/IP). This has several advantages:
The request method indicates the action to be performed by the server. The HTTP/1.1 standard defines seven methods and allows other methods to be added later. Over the years, a few ones have been added in standards like WebDAV. The IETF HTTPbis Working Group is currently working on an IANA registry to list them all. If a server receives a request method that it doesn't know, it must return a 501 Not implemented response; if it knows the method but is configured not to answer it, it must return a 405 Method not allowed response. Two methods are required to be supported: HEAD and GET; all others are optional.
Two specific semantics are defined in the standard and are crucial for web developers: the safety property and the idempotent property.
A safe method is a method that doesn't have any side-effects on the server. In other words, this property means that the method must be used only for retrieval of data. The safe HTTP methods defined in HTTP/1.1 are:
An idempotent method is a method such that the side-effects on the server of several identical requests with the method are the same as the side-effects of one single request.
Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.
The CONNECT method is defined in RFC 2817.
In HTML, different HTTP request methods can be specified in the {{ htmlattrxref("method", "form") }} attribute of the {{ HTMLElement("form") }} element, but also to the {{ htmlattrxref("formmethod", "input") }} of the {{ HTMLElement("input") }} and {{ HTMLElement("button") }} elements. But not all HTTP methods can be used with these attributes; only GET and POST method are allowed by the HTML specification. See this StackExchange answer why other HTTP request methods are not allowed by the HTML specification.
When answering a client request, the server sends back a three-digit number indicating whether the request was successfully processed. These codes can be grouped in five categories:
1xx) are provisional responses. Most of the time neither the end user, nor the web developer or webmaster should have to bother with these. The most common is the 100 Continue response, indicating that the client should continue to send its request.
2xx) are for successfully processed requests. The 200 OK response is by far the most common of these responses, but the 206 Partial Content is also often seen when fetching a file or some media data like video or audio.3xx) indicate that the resource that the client requested has moved and the server is not able to serve it directly. Most of these responses contain some location information telling where to find the requested resource; user-agents often then retrieve it without further user interaction. The most common responses of this type are 301 Moved Permanently, indicating that the URI given is no longer valid and has been moved to another place, and 302 Found which indicates that the resource has been temporarily moved to another place.
301 Moved Permanently redirection when moving pages to another URI, during a site reorganization for example. That allows users following links to still reach the resource and it also teaches search engines and other services the new location of the resource, so that they can transfer their metadata to it. It is also important to add adequate cache headers to the 301 Moved Permanently response so that this information is cached by the client and prevents it from making unnecessary requests to the original URI prior to fetching the resource itself.4xx) indicate that the request sent by the client is either invalid, incomplete, or doesn't have enough rights to be performed. The most common such response is 404 Not Found which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like 400 Bad Request sent when the request isn't a valid HTTP request (as this shouldn't happen but may indicate a bug into the user agent or, less likely, the server) or 403 Forbidden, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content).5xx) indicate that the server had a problem handling the valid client request. The two most common such responses are 500 Internal Server Error, a generic error code indicating a bug in the server or 503 Service Unavailable indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or the non-availability of a database.A web developer shouldn't encounter many other response codes, but people building requests using the XMLHTTPRequest function may hit less usual response codes.
Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a javascript: URI are no longer performed. Instead, a bad connection error is presented. This helps avoid cross-site scripting attacks. See {{ bug(255119) }} if you want more details.
HTTP-Kopfdaten ermöglichen the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without CRLF in it). Leading white space before the value is ignored.
Headers are grouped according the context in which they may appear:
Kopfdaten können auch nach ihrer Handhabung durch puffernde und nicht-puffernde Proxys gruppiert werden:
In order to learn about the specific semantic of each header, see its entry in the comprehensive list of HTTP headers.
Among the numerous HTTP request headers, several are especially useful when set correctly. If you are building your own requests, by using XMLHTTPRequest or when writing an extension and sending custom HTTP requests via XPCOM, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.
XMLHTTPRequest:, it is a good idea to use the {{ httpheader("If-Modified-Since") }} header (and other similar ones) in order to fetch the new content only if it has changed. This approach lowers the burden on the network.The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the numerous HTTP response headers, several are of specific importance and should be configured on the server
Several cross-site scripting (XSS) attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risk, modern browsers have introduced the CSP frame-ancestors directive. By setting it with the value 'none', it prevents the browser from displaying this resource inside of a frame. Using it on critical resources (like those containing a formularies or critical information) will reduce the risk caused by XSS attacks. Note that this specific HTTP response header is not the only way to mitigate XSS risks; other techniques, like setting some Content Security Policies, may be helpful too.
Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like CSS Sprites, should be applied on the site itself, compression of data must be set at the web server level. If set, resources requested by the client with an {{ httpheader("Accept-Encoding") }} request header are compressed using the appropriate method and sent back with a {{ httpheader("Content-Encoding") }} response header. Setting these in Apache 2 servers is done by using the mod_deflate module.
HTTP Caching is a technique that prevents the same resource from being fetched several times if it hasn't change. Configuring the server with the correct response headers allows the user-agent to adequately cache the data. In order to do that, be sure that:
ExpiresDefault "access plus 1 month".The MIME type is the mechanism to tell the client the kind of document transmitted: the extension of a file name has no meaning on the web. It is therefore important that the server is correctly set up so that the correct MIME type is transmitted with each document: user-agents often use this MIME-type to determine what default action to do when a resource is fetched.
AddType type directive like AddType image/jpeg jpg.application/octet-stream MIME type; for security reasons, most browsers, like Firefox, do not allow setting a custom default action for such resources and force the user to store it to disk in order to use it. Some common cases of often incorrectly configured servers happens for the following file types:
Rar-encoded files. The ideal would be to be able to set the real type of the encoded files; this often is not possible (as it may not be known to the server and these files may contains several resource of different types). In that case, configure the server to send the application/x-rar-compressed MIME type or some users won't be able to define a useful default action for them.
Audio and video files. Only resources with the proper MIME Type will be recognized and played, using a {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to use the correct MIME type for audio and video resources.
Proprietary file types. Pay special attention when serving a proprietary file type. Be sure not to forget to add an x-prefixed type for it; otherwise, special handling won't be possible. This is especially true with resources using the Keyhole Markup Language, which should be served as application/vnd.google-earth.kml+xml for an optimal user experience.