Hypertext Transfer Protocol
RFC 2616 ( HTTP/1.1, 1999)
The Hypertext Transfer Protocol (HTTP, engl. " Hypertext transfer protocol " ) is a protocol for transmission of data over a network. It is mainly used to load web pages from the World Wide Web ( WWW) in a web browser.
HTTP is a member of the so-called application layer established network models. The application layer is addressed by application programs in the case of HTTP this is usually a Web browser. In the ISO / OSI model, the application layer corresponds to layers 5-7.
HTTP is a stateless protocol. A reliable carrying of session data can be implemented only at the application layer by a session through a session ID.
By extending its request methods, header information and HTTP status codes is not limited to hypertext, but is increasingly being used to exchange arbitrary data, it is also the basis of the specialized file transfer protocol WebDAV. HTTP communication is dependent on a reliable transport protocol for which is used in almost all cases, TCP.
Prehistory
As of 1989, developed Roy Fielding, Tim Berners -Lee and others at CERN, the European nuclear research center in Switzerland, the Hypertext Transfer Protocol, together with the concepts of URL and HTML, so that the foundations of the World Wide Web was created. First results of these efforts was the 1991 version of HTTP 0.9. The ultimate in May 1996 as RFC 1945 ( Request for Comments No. 1945) published requirement has become known as HTTP/1.0. 1999, a second request as RFC 2616 was published, reflecting the HTTP/1.1-Standard.
Construction
The communication units in HTTP between client and server are referred to as news, of which there are two different types: the request ( stands for Request ) from the client to the server and the response ( engl. Response) as a response from the server to the client.
Each message consists of two parts, the header ( engl. message header, in short: header or HTTP header called ) and the message body ( engl. message body, in short: Body). The message header contains information about the message body as encodings as used or the content type so that it can be correctly interpreted by the receiver. The message body contains the payload finally.
Operation
When enabled on a site without the link to the URL http://www.example.net/infotext.html, then to the computer with the host name www.example.net the request directed to return the resource / infotext.html.
The name is www.example.net this first implemented on the DNS protocol to an IP address. For the transmission is sent over TCP on the standard port 80 HTTP Server an HTTP GET request.
Request:
GET / HTTP/1.1 infotext.html
Host: www.example.net
Contains the link characters that are not allowed in the request are encoded % this.
Additional information such as information on the browser to the desired language, etc. can be transmitted via the header ( header ) in each HTTP communication.
Once the header with a blank line (or two consecutive line endings ) is completed, returns the computer running a web server ( on port 80 ), itself an HTTP response.
This consists of the header information of the server, a blank line and the actual content of the message, ie the file contents of the infotext.html file.
Transferring files are normally in page description languages such as (X ) HTML and all its additions, such as images, stylesheets (CSS ), scripts (JavaScript ), etc., which are attached to each other by a browser in a readable representation.
In principle, any file can be transferred in any format, with the " file" can also be generated dynamically and does not need to be present on the server as a physical file (eg with the use of CGI, SSI, JSP, PHP or ASP. NET).
Each line in the header is terminated by the newline
Answer:
HTTP/1.1 200 OK Server: Apache/1.3.29 (Unix) PHP/4.3.4 Content-Length: (size of infotext.html in bytes) Content-Language: en (according to RFC 3282 and RFC 1766 ) Connection: close Content-Type: text / html ( Content of infotext.html ) The server sends an error message and an error code if the information for any reason can not be sent, but status codes are also used when the query was successful, in the case of (mostly) 200 OK. The exact sequence of this process ( request and response ) is defined in the HTTP specification.
Protocol versions
Currently, two protocol versions HTTP/1.0 and HTTP/1.1 used. In HTTP/1.0 before each request a new TCP connection is established and closed by default after transmission of the response from the server again. In an HTML document, for example, ten images embedded, so eleven TCP connections are needed in total to build the page on a graphics-capable browser. In HTTP/1.1, a client through an additional header entry ( keep-alive ) express the desire not to carry out disconnection to use the connection again can (persistent connection). However, the support on the server side is optional and may cause problems in connection with the proxy. Using HTTP Pipelining multiple requests and responses per TCP connection can be sent in version 1.1. So only a TCP connection is required for the HTML document with ten pictures. Since the rate of TCP connections at the beginning by using the slow-start algorithm is quite low, so the charging time for the entire page is shortened significantly. In addition, broken transfers can be continued by HTTP/1.1.
For HTTP go information from previous requirements lost ( stateless protocol ). About cookies in the header information but applications can be realized, can assign the status information ( user entries, shopping carts ). This applications are possible that require status or session properties. Also, a user authentication. Usually, the information that is transmitted over HTTP to be read on all computers and routers, which are passed through the network. About the HTTPS transmission can also be encrypted.
One way to use HTTP/1.1 in chats is the use of the MIME type multipart / replace, in which the browser after sending a boundary code and a renewed Content -Length header field and a new content -type header field the contents of the browser window redraws.
With HTTP/1.1, it is also possible besides the fetching of data to transfer data to the server. Using the PUT method so Web designers can publish their pages directly via WebDAV via the web server, and using the DELETE method, it is possible for them to delete data from the server. In addition, HTTP/1.1 provides a TRACE method by which the way can be tracked and reviewed to the web server whether the data is transferred correctly there. This results in the possibility of the path to the web server on the different proxies to determine across, a traceroute on the application level.
HTTP request methods
RFC 5789 defines an additional PATCH method to modify resources, in contrast to the PUT method is the intention of uploading the complete resource.
RESTful Web Services use different request methods for the realization of Web services. In particular, for the HTTP request methods GET, POST, PUT / PATCH and DELETE are used.
WebDAV adds the following methods to add HTTP: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
Argument transmission
Often a user wants to send information to a website. These HTTP provides two basic ways:
The data to be transmitted may need to be URL encoded, that is reserved characters must be represented by "%
HTTP GET
Here, the value pairs parameters are determined by the sign? initiated in the URL. Often this procedure is used to transfer a list of parameters that should take into account the other party when processing a request. Often, this list consists of pairs of values that are separated by the '&' sign. The respective pairs of values are constructed in the form parameter name = parameter value. More rarely, the; used to separate entries in the list.
These pairs of values are in the form
Argument1 = value1 & arg2 = value2 beginning with? attached to the requested page.
This "knows" the server that the user wants to view the article in cats. The server processes the request, but does not send a file, but redirects the browser with a Location header to the correct page, for example with:
HTTP/1.0 200 OK Date: Fri, January 13, 2006 15:12:48 GMT Last-Modified: Tue, January 10, 2006 11:18:20 GMT Content-Language: en Content-Type: text / html; charset = utf -8 The cats ( Felidae ) are a family of the order Carnivora ( carnivores ) within the superfamily of felids ( Feloidea ). ... The data part is usually longer, only the protocol should be considered.
HTTP POST
Since the data is not in the URL can be sent by POST large amounts of data, such as images are transferred.
In the following example, the article Cats is requested again, but this time the browser used due to a modified HTML codes ( method = " POST" ), a POST request. The variables are not here in the URL, but separately in the body part, such as:
Each HTTP request is answered by the server with an HTTP status code. He gives, for example, information on whether the request was successfully processed, or tells the client, or about the browser, in the event of an error where ( eg Forwarding ) or as (eg authentication) he desired the information (if possible ) can be obtained.
The request has been processed and the response is sent back to the requester.
In addition to the status code of the header of the server response contains a description of the error in English speaking plain text. For example, a 404 error at the following headers can be seen:
HTTP/1.1 404 Not Found ... HTTP authentication
Determines the web server that are needed for a requested file username or password, it reports that the browser with the status code 401 Unauthorized WWW-Authenticate header and the. This verifies that the information is available, or presented to the user a dialog to be entered in the name and password, and sends them to the server. If the data corresponding to the page is sent to the browser. It is according to RFC 2617 distinguished in:
HTTP compression
To reduce the amount of data transmitted, a HTTP server compress his answers. A client must be notified at an inquiry, compression methods it can use. The purpose of the header Accept-Encoding (such as Accept-Encoding: gzip, deflate ). The server can then compress the response with a method supported by the client and are in the Content-Encoding header to the compression method used.
HTTP compression saves especially in textual data (HTML, CSS, Javascript) considerable amounts of data, as this will compress well. With already compressed data (about common formats for images, audio and video), the ( re- ) compression is useless and is therefore usually not used.
HTTP/2.0
The IETF working group HTTPbis deals with the revision of HTTP, which is to carry the version number 2.0. Google ( SPDY ) and Microsoft (HTTP Speed Mobility ) have each submitted their own proposals for HTTP/2.0 and partly already implemented in their browsers. A first draft, which largely leaned on SPDY, was published in November 2012 and has since been adapted in several steps.
With HTTP/2.0, the transfer should be accelerated and optimized. However, the new standard is to be fully backward compatible with HTTP/1.1.