In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request. Such persistent connections reduce request "latency perceptibly, because the client does not need to re-negotiate the TCP 3-Way-Handshake connection after the first request has been sent. Another positive side effect is that in general the connection becomes faster with time due to TCP's "slow-start-mechanism.
Version 1.1 of the protocol also made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced "chunked transfer encoding to allow content on persistent connections to be streamed rather than buffered. "HTTP pipelining further reduces lag time, allowing clients to send multiple requests before waiting for each response. Another addition to the protocol was "byte serving, where a server transmits just the portion of a resource explicitly requested by a client.
HTTP session state
HTTP is a "stateless protocol. A stateless protocol does not require the "HTTP server to retain information or status about each user for the duration of multiple requests. However, some "web applications implement states or "server side sessions using for instance "HTTP cookies or hidden "variables within "web forms.
The most popular way of establishing an encrypted HTTP connection is "HTTP Secure. Two other methods for establishing an encrypted HTTP connection also exist: "Secure Hypertext Transfer Protocol, and using the "HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.
The client and server communicate by sending plain-text ("ASCII) messages. The client sends requests to the server and the server sends responses.
The request message consists of the following:
- A request line (e.g., GET /images/logo.png HTTP/1.1, which requests a resource called /images/logo.png from the server).
- "Request header fields (e.g., Accept-Language: en).
- An empty line.
- An optional "message body.
The request line and other header fields must each end with <CR><LF> (that is, a "carriage return character followed by a "line feed character). The empty line must consist of only <CR><LF> and no other "whitespace. In the HTTP/1.1 protocol, all header fields except Host are optional.
A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification in RFC 1945.
The response message consists of the following:
- A status line which includes the "status code and reason message (e.g., HTTP/1.1 200 OK, which indicates that the client's request succeeded).
- "Response header fields (e.g., Content-Type: text/html).
- An empty line.
- An optional "message body.
The status line and other header fields must all end with <CR><LF>. The empty line must consist of only <CR><LF> and no other "whitespace. This strict requirement for <CR><LF> is relaxed somewhat within message bodies for consistent use of other system linebreaks such as <CR> or <LF> alone.
Below is a sample conversation between an HTTP client and an HTTP server running on "www.example.com, port 80. As mentioned in the previous sections, all the data is sent in a plain-text ("ASCII) encoding, using a "two-byte CR LF ('\r\n') line ending at the end of each line.
GET /index.html HTTP/1.1 Host: www.example.com
A client request (consisting in this case of the request line and only one header field) is followed by a blank line, so that the request ends with a double newline, each in the form of a "carriage return followed by a "line feed. The "Host" field distinguishes between various "DNS names sharing a single "IP address, allowing name-based "virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: UTF-8 Content-Length: 138 Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Server: Apache/220.127.116.11 (Unix) (Red-Hat/Linux) ETag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Connection: close <html> <head> <title>An Example Page</title> </head> <body> Hello World, this is a very simple HTML document. </body> </html>
The "ETag (entity tag) header field is used to determine if a cached version of the requested resource is identical to the current version of the resource on the server. Content-Type specifies the "Internet media type of the data conveyed by the HTTP message, while Content-Length indicates its length in bytes. The HTTP/1.1 "webserver publishes its ability to respond to requests for certain byte ranges of the document by setting the field Accept-Ranges: bytes. This is useful, if the client needs to have only certain portions of a resource sent by the server, which is called "byte serving. When Connection: close is sent, it means that the "web server will close the "TCP connection immediately after the transfer of this response.
Most of the header lines are optional. When Content-Length is missing the length is determined in other ways. Chunked transfer encoding uses a chunk size of 0 to mark the end of the content. Identity encoding without Content-Length reads content until the socket is closed.
A Content-Encoding like "gzip can be used to compress the transmitted data.
The "Gopher protocol was a content delivery protocol that was displaced by HTTP in the early 1990s. The "SPDY protocol is an alternative to HTTP developed at "Google, it is superseded by the new HTTP protocol, "HTTP/2.
- "Basic access authentication
- "Constrained Application Protocol – A semantically similar protocol to HTTP but used UDP or UDP-like messages targeted for devices with limited processing capability. Re-uses HTTP and other internet concepts like "Internet media type and web linking (RFC 5988)
- "Content negotiation
- "Curl-loader – HTTP/S loading and testing open-source software
- "Digest access authentication
- "Fiddler (software)
- "HTTP compression
- "HTTP/2 – developed by the IETF's Hypertext Transfer Protocol Bis (httpbis) working group.
- HTTP-MPLEX – A backwards compatible enhancement to HTTP to improve page and web object retrieval time in congested networks proposed by Robert Mattson
- "List of file transfer protocols
- "List of HTTP header fields
- "List of HTTP status codes
- "Representational state transfer (REST)
- "Variant object
- "Waka (protocol) – An HTTP replacement proposed by "Roy Fielding
- "Web cache
- Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol -- HTTP/1.1. "IETF. RFC 2616. https://tools.ietf.org/html/rfc2616.
- "Overall Operation". p. 12. sec. 1.4. RFC 2616. https://tools.ietf.org/html/rfc2616#section-1.4.
- Berners-Lee, Tim. "HyperText Transfer Protocol". "World Wide Web Consortium. Retrieved 31 August 2010.
- "Tim Berners-Lee. "The Original HTTP as defined in 1991". "World Wide Web Consortium. Retrieved 24 July 2010.
- Raggett, Dave. "Dave Raggett's Bio". "World Wide Web Consortium. Retrieved 11 June 2010.
- Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group". World Wide Web Consortium. Retrieved 29 September 2010.
- Raggett, Dave. "HTTP WG Plans". World Wide Web Consortium. Retrieved 29 September 2010.
- Simon Spero. "Progress on HTTP-NG". "World Wide Web Consortium. Retrieved 11 June 2010.
- "HTTP/1.1". Webcom.com Glossary entry. Retrieved 2009-05-29.["permanent dead link]
- Fielding, Roy T.; Reschke, Julian F. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Authentication. "IETF. RFC 7235. https://tools.ietf.org/html/rfc7235.
- Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Method Definitions". Hypertext Transfer Protocol -- HTTP/1.0. "IETF. pp. 30-32. sec. 8. RFC 1945. https://tools.ietf.org/html/rfc1945#section-8.
- "Method Definitions". pp. 51-57. sec. 9. RFC 2616. https://tools.ietf.org/html/rfc2616#section-9.
- Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.
- "POST". p. 54. sec. 9.5. RFC 2616. https://tools.ietf.org/html/rfc2616#section-9.5.
- "PUT". p. 55. sec. 9.6. RFC 2616. https://tools.ietf.org/html/rfc2616#section-9.6.
- "CONNECT". Hypertext Transfer Protocol -- HTTP/1.1. "IETF. June 1999. p. 57. sec. 9.9. RFC 2616. https://tools.ietf.org/html/rfc2616#section-9.9. Retrieved 23 February 2014.
- Khare, Rohit; Lawrence, Scott (May 2000). Upgrading to TLS Within HTTP/1.1. "IETF. RFC 2817. https://tools.ietf.org/html/rfc2817.
- "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". "US-CERT. 2002-05-17. Retrieved 2007-05-10.
- Dusseault, Lisa; Snell, James M. (March 2010). PATCH Method for HTTP. "IETF. RFC 5789. https://tools.ietf.org/html/rfc5789.
- "Method". p. 36. sec. 5.1.1. RFC 2616. https://tools.ietf.org/html/rfc2616#section-5.1.1.
- "Cross Site Tracing". "OWASP. Retrieved 2016-06-22.
- "Status-Line". p. 39. sec. 6.1. RFC 2616. https://tools.ietf.org/html/rfc2616#section-6.1.
- Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83. "ISBN "9781580531764.
- Zalewski, Michal. "Browser Security Handbook". Retrieved 30 April 2015.
- "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1". Retrieved 30 April 2015.
- "Mozilla Bug 276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". Retrieved 30 April 2015.
- "HTTP Message". p. 31. sec. 4. RFC 2616. https://tools.ietf.org/html/rfc2616#section-4.
- "Apache Week. HTTP/1.1". 090502 apacheweek.com
- "Canonicalization and Text Defaults". sec. 3.7.1. RFC 2616. https://tools.ietf.org/html/rfc2616#section-3.7.1.
- Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. "IETF. I-D draft-ietf-http-range-retrieval-00. https://tools.ietf.org/html/draft-ietf-http-range-retrieval-00.
- Nottingham, Mark (October 2010). Web Linking. "IETF. RFC 5988. https://tools.ietf.org/html/rfc5988.
- "Hypertext Transfer Protocol Bis (httpbis) – Charter". IETF. 2012.
|""||Wikimedia Commons has media related to HTTP.|
- "Change History for HTTP". W3.org. Retrieved 2010-08-01. A detailed technical history of HTTP.
- "Design Issues for HTTP". W3.org. Retrieved 2010-08-01. Design Issues by Berners-Lee when he was designing the protocol.
- "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01. list of other classic documents recounting the early protocol history