HTTP

  • Revision slug: HTTP
  • Revision title: HTTP
  • Revision id: 5598
  • Created:
  • Creator: teoli
  • Is current revision? No
  • Comment 175 words added

Revision Content

The Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents. It follows a classical client-server model, with a client opening a connection, making a request then waiting for a response until it receives it.

Though often based on a TCP/IP layer, it could be used on any connection-oriented transport layer.

A brief history of HTTP

Since his 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, was published what became, with some minor changes the HTTP/1.0 (finalized in RFC 1945 in may 1996). One major improvement was to allow the transmission of files of different types, like images, video, scripts, CSS document, etc., instead of only HTML files, using MIME types in conjunction with the Content-Type: header.

Since 1995, HTTP-NG was under development at the IETF and, what will become HTTP/1.1, see quickly wide usage, even it was officially standardize in RFC 2068 in 1997, with minor fixes in RFC 2616 in 1999.

HTTP/1.1 brought the ability to reuse of the connection for subsequent requests, greatly improving the performance of the protocol by lowering the latency between requests, especially useful with complex HTML document needing to fetch several of subsequent files, like images or style sheet. It also brought the Host header allowing a single server (listening on a specific port) to allow to receive requests for several websites, allowing the sharing of web servers by numerous websites.

Since then, the HTTP protocol evolved by adding new headers, allowing to define new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.

An HTTP session

As a client server protocol, an HTTP Session happened in three phases:

  1. The client establishes a TCP/IP connection (or another type of connection if the transport layer is not that protocol).
  2. The client sends its request then wait for the answer
  3. The server processes the request and send back one answer, containing an status code and the appropriate data for the answer.

Since HTTP/1.1, the connection is no more closed after the third phases, as the client is allowed to issues another request at this point: the second and third phases can therefore be done several times.

Establishing a connection

As HTTP is a client-server protocol, it is always the client that establishes a connection to the server. Opening a connection in HTTP is really establishing a connection in the underlying transport layer, usually TCP/IP.

Over TCP/IP, the standard port for an http server on a computer is port 80, though other may be found, like 8000, 8080. The URL of a page to fetch contains both the domain name and the port number, though this later can be omitted if it is port 80.

Note: model do not allows the server to send data to the client, without this one to issue the request. To work around this problem, web developers use several techniques: pinging periodically the server via the XMLHTTPRequest Javascript object, the HTML Websockets API or similar.

Sending a client request

Once the connection is established, the user-agent can send its request. A client request is formed of text directives, separated by CRLF, divided in three blocks:

  1. The first line consists of a request method followed by its parameters, often a relative URL, and the HTTP protocol version used.
  2. The subsequent lines represent each a specific HTTP headers giving the server information about what kind of data is appropriate (what language, what MIME types, ...) or data altering its behavior (like not sending an answer if it is already cached, ...). These HTTP headers form a block that end with an empty line.
  3. Then start the data block, which contains further data and is mainly used by the POST method.

Examples of requests:

  • Fetching the root page of developer.mozilla.org, i.e. http://developer.mozilla.org/, and indicates to the server that it would like the page in French, if possible:
    GET / HTTP/1.1
    Host: developer.mozilla.org
    Accept-Language: fr 
    
    

    Note the final empty line, separate 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 the empty line marking the ead of the headers is received.

  • Sending the result of the form:
    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
    

Structure of a server response

After the connected agent sent its request, the web server can handle it and finally sent a response back. Similarly to a client request, a server request is formed of text directives, separated by CRLF, though divided in three different blocks:

  1. The first line, the status line, consists of an acknowledgment of the HTTP version used followed by an status request (and its meaning in human-readable text).
  2. The subsequent lines represent each a specific HTTP headers giving the client  information about the data sent (type, data size, compression algorithm used, hints about caching, ...). Similarly to the block of HTTP headers for the client request, these HTTP headers form a block that end with an empty line.
  3. Then start the data block, which contains the data.

Examples of requests:

  • Successful reception of a web page:
    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)
    
    
  • Notification that the requested resource has been permanently moved:
    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 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 consists in 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>
     
    
    
  • Notification that the requested resource doesn't exists:
    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... (follows a site-customized page helping the user to find the missing resource)
    
    

Persistent connections

Persistent connections were introduced in HTTP/1.1. They allows to transmit several requests on the same TCP connection (or on the specific connected transport layer if the HTTP is not build upon TCP/IP). This has several advantages:

  • as the connection can be reused, requests can be pipelined to save part of the connection latency;
  • by opening and closing fewer TCP connections, CPU time is saved;
  • network congestion is diminished by lowering the total amount of TCP packets (less opening and closing TCP packets);
  • the TCP stack has more time to detect network congestion and to adapt its sending and receiving windows;
  • HTTP is more evolutive: the cost for trying a features is considerably lowered as an error response won't lead to the closing of the connection anymore.

HTTP Requests Methods

Safe methods

A safe method is a method that doesn't have side-effects on the server. In other words, these indicates methods that are used only for retrieval of data. Any safe method is also idempotent. The safe HTTP methods are:

  • GET is the way to retrieve information identified by the request URI. This information may be generated on the fly and the GET may be conditional if any of the If-Modified-Since:, If-Unmodified-Since:, If-Match:, If-None-Match or If-Range HTTP headers are set. In that case the information is only sent back if the conditions are fulfilled.
  • HEAD which is identical to GET but without the message body sent.
Note: for the GET method, when the page is generated by a script on the server side, like with PHP, ASP, cgi-bin or any other data-accepting process, it is up to the web developer to ensure that the safe propriety is matched. For example, in an online shop, it is its duty that several identical GET do not lead to several orders. This may be done by using a reference for each order, reference passed within the request URI of the GET.

Idempotent methods

An idempotent method is a method that the side-effects on the server of several identical requests with these method is the same as the side-effects of one single request.

  • HEAD and GET, as any safe method is also idempotent, as a safe method shouldn't have side-effects on the server;
  • PUT is the way to upload information on the server. If the resource already exists is different, it is replaced, if it doesn't exists, it is created.
  • DELETE removes a resource from the server.

Others methods

  • OPTIONS
  • TRACE

HTTP Requests Methods in HTML Forms

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 at that point, only GET and POST method are allowed by the HTML specification.

Note: the choice of a GET or POST method for HTML forms is not neutral. The GET method being a safe method, it should be used only in case where no side-effect is to be expected; e.g. it shouldn't be used to transmit an order as this order is a side-effect. In all case where such side-effects is expected, the POST method should be used, as it is a merely idempotent method.

HTTP Response Codes

When answering a client request, the server sent back a three digits code which indicates if the request was successfully processed or not. These codes can be groups in five categories:

  • Informational responses (of the form 1xx), which form a class of codes indicating a provisional response. 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.
    Note: no information response code where defined in the HTTP/1.0 and they must not be used when this version of the protocol is used.
  • Success responses (of the form 2xx), which form a class of codes indicating that the client request has been successfully processed. 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.
  • Redirection responses (of the form 3xx), which form a class of codes indicating that the client request has moved and the server is not able to serve it. Most of theses responses contains some location information where to find the resource requested and user-agent often retrieve it then without further user interaction. The most common responses of these types 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 temporary moved to another place.
    Note: for webmasters, it is recommended to set up a 301 Moved Permanently redirection when moving pages to another URI. That allows users following links to still reach the resource and it also teach search engine 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 prevent it to make unnecessary requests to the original URI prior to fetch the resource itself.
  • Client error responses (of the form 4xx), which form a class of codes indicating that the request sent by the client is either invalid, incomplete or doesn't have enough rights to be performed. The most known is 404 Not Found which is sent back when the URI requested doesn't exists, but a few others are often presented to the end user like: 400 Bad Request 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 when the client request a resource that does exists but isn't allowed to be transmitted (like a directory content).
  • Server error responses (of the form 5), which form a class of codes indicating 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 a database non available.

A web developer shouldn't met many others response codes, but people building request using the XMLHTTPRequest function may hit less usual response codes.

HTTP Headers

HTTP Headers allowes the client and the server to pass additional information with the request or the response. A request header consist on its case-insensitive name followed by a semi-colon ':', then by its value (without CRLF in it). Leading whitespace before its value are ignored.

Headers are grouped according the occasion in which they may appear:

General headers
These headers apply to both requests and responses but are unrelated to the response. They do therefore apply only to the message being transmitted. They are only a few of them and new ones cannot been added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is Cache-Control:, Connection:, Date:, Pragma:, Trailer:, Transfer-Encoding:, Upgrade:, Via: and Warning:.
Request headers
These headers give more precise information about the resource to be fetched or about the client itself. Among them one find cache-related headers, transforming a GET method in a conditional GET, like If-Modified-Since:, user-preference information like Accept-Language: or Accept-Charset: or plain client information like User-Agent:. New request headers cannot be added without bumping the version number of the HTTP protocol. But, it is usual that new request headers are being added if both the server and the client do agree on their meaning. Therefore a client should not assume that they will be handled adequately by the server; unknown request headers are being handled as entity headers.
Response headers
These headers give more information about the resource sent back, like its real location (Location:) or about the server itself, like its name and version (Server:). New response headers cannot be added without bumping the version number of the HTTP protocol. But, it is usual that new response headers are being added if both the server and the client do agree on their meaning. Therefore a server should not assume that they will be handled adequately by the client ; unknown response headers are being handled as entity headers.
Entity headers
These headers give more information about the body of the entity, like its length (Content-Length:), a identifying hash (Content-MD5:) or its MIME-type (Content-Type:). New entity headers can be added without bumping the version number of the HTtP protocol. Note that non-standard entity headers must be prefixed with X.

They may also be grouped according the expected behavior of caching and non-caching proxies regarding them:

End-to-end headers
These headers must be transmitted to the final recipient of the message, being the server for a request message or the client for a response message. It means that intermediate proxies must retransmit it unmodified and also that caches must store it.
Hop-by-hop headers
These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such are headers are: Connection:, Keep-Alive:, Proxy-Authenticate:, Proxy-Authorization:, TE:, Trailers:, Transfer-Encoding: and Upgrade:. Note that only hop-by-hop headers may be given through the Connection: general header.

Though to learn about the specific semantic of each header, one should consult its entry in the comprehensive list of HTTP headers, a few of them that are especially useful to web developers and webmasters are described in context.

Useful request headers

Among the numerous HTTP request headers, several are useful when set correctly. If the browser agent often set them correctly, according to the preferences of its user, it is important to ensure their presence when building your own requests, by using XMLHTTPRequest or when writing an extension and sending custom HTTP requests via XPCOM.

Controlling the language of the resource
Most user-agent, like Firefox, allows the user to set his preference about in what language he wants to receive a resource. The browser translate this into an Accept-Language: header. It is good practice for web developers, when building specific HTTP requests, to include such header too.
Using conditional GET
Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage is refreshed via an XMLHTTPRequest:, it is a good idea to use the If-Modified-Since: header (and other similar ones) in order to fetch the new content only it has changed. It will lower the congestion of the network.

Useful response headers

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 several importance and should be configured

Restricting framing

Several cross-site scripting attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risks, modern browsers have introduced the X-Frame-Options: response header. By setting it with the value DENY, it prevents the browser to display 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.

Compression

Minimizing the amount of data transferred accelerate 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, resource requested by the client with an Accept-Encoding: request header are compressed using the appropriate method and sent back, with an Content-Encoding: response header. Setting these in Apache 2 servers is done by using the mod_deflate module.

Note: be aware that not all data format can be efficiently compressed. Already compressed media data, like JPEG images or most audio and video formats, will not shrink with another pass of compression. In fact, they will often be greater due to the overhead of the compression method. It is important not to try to compress these resource type any further, no gain of size will be made and the compression/decompression mechanism is resource-hungry.
Controlling cache

Caching prevents the same resource to be fetched several times, though it didn't change. Configuring the servers with the correct response headers allows the user-agent to cache adequately the data. In order to do that, be sure that:

  • any static resource provides an Expires: response header far in the future. That way they may stay in the cache until the user-agent flush it for its own reasons.
    On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires: ExpiresDefault "access plus 1 month".
  • any dynamic resource provides a Cache-control: response header. Theoretically, any HTTP request done with a safe-method (GET or HEAD) or even a solely idempotent one (POST, DELETE, PUT) may be cached; but, in practice careful study is needed to determine if the caching of the response may lead to unappropriate side-effects.
Controlling pipelining

Audio and video special cases

Revision Source

<p>The <dfn>Hypertext Transfer Protocol (HTTP)</dfn> is an <a class=" external" href="http://en.wikipedia.org/wiki/Application_Layer" title="http://en.wikipedia.org/wiki/Application_Layer">application-layer</a> protocol for transmitting hypermedia documents. It follows a classical <a class=" external" href="http://en.wikipedia.org/wiki/Client%E2%80%93server_model" title="http://en.wikipedia.org/wiki/Client–server_model">client-server model</a>, with a client opening a connection, making a request then waiting for a response until it receives it.</p>
<p>Though often based on a TCP/IP layer, it could be used on any connection-oriented <a class=" external" href="http://en.wikipedia.org/wiki/Transport_Layer" title="http://en.wikipedia.org/wiki/Transport_Layer">transport layer</a>.</p>
<h3>A brief history of HTTP</h3>
<p>Since his 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 '<span style="font-family: Courier New;">?</span>' character.</p>
<p>Then, in 1992, was published what became, with some minor changes the HTTP/1.0 (finalized in <a class=" external" href="http://tools.ietf.org/html/rfc1945" title="http://tools.ietf.org/html/rfc1945">RFC 1945</a> in may 1996). One major improvement was to allow the transmission of files of different types, like images, video, scripts, CSS document, etc., instead of only HTML files, using MIME types in conjunction with the Content-Type: header.</p>
<p>Since 1995, HTTP-NG was under development at the <a class=" external" href="http://www.ietf.org/" title="http://www.ietf.org/">IETF</a> and, what will become HTTP/1.1, see quickly wide usage, even it was officially standardize in <a class=" external" href="http://tools.ietf.org/html/rfc2068" title="http://tools.ietf.org/html/rfc2068">RFC 2068</a> in 1997, with minor fixes in <a class=" external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> in 1999.</p>
<p>HTTP/1.1 brought the ability to reuse of the connection for subsequent requests, greatly improving the performance of the protocol by lowering the latency between requests, especially useful with complex HTML document needing to fetch several of subsequent files, like images or style sheet. It also brought the Host header allowing a single server (listening on a specific port) to allow to receive requests for several websites, allowing the sharing of web servers by numerous websites.</p>
<p>Since then, the HTTP protocol evolved by adding new <a href="/en/HTTP/Headers" title="en/HTTP/Headers">headers</a>, allowing to define new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.</p>
<h3>An HTTP session</h3>
<p>As a client server protocol, an HTTP Session happened in three phases:</p>
<ol> <li>The client establishes a TCP/IP connection (or another type of connection if the transport layer is not that protocol).</li> <li>The client sends its request then wait for the answer</li> <li>The server processes the request and send back one answer, containing an status code and the appropriate data for the answer.</li>
</ol>
<p>Since HTTP/1.1, the connection is no more closed after the third phases, as the client is allowed to issues another request at this point: the second and third phases can therefore be done several times.</p>
<h4>Establishing a connection</h4>
<p>As HTTP is a client-server protocol, it is always the client that establishes a connection to the server. Opening a connection in HTTP is really establishing a connection in the underlying transport layer, usually TCP/IP.</p>
<p>Over TCP/IP, the standard port for an http server on a computer is port 80, though other may be found, like 8000, 8080. The URL of a page to fetch contains both the domain name and the port number, though this later can be omitted if it is port 80.</p>
<div class="note"><strong>Note:</strong> model do not allows the server to send data to the client, without this one to issue the request. To work around this problem, web developers use several techniques: pinging periodically the server via the <a href="/en/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a> Javascript object, the HTML <a href="/en/Websockets_API" title="en/Websockets API">Websockets API</a> or similar.</div>
<h4>Sending a client request</h4>
<p>Once the connection is established, the user-agent can send its request. A client request is formed of text directives, separated by CRLF, divided in three blocks:</p>
<ol> <li>The first line consists of a request method followed by its parameters, often a relative URL, and the HTTP protocol version used.</li> <li>The subsequent lines represent each a specific HTTP headers giving the server information about what kind of data is appropriate (what language, what MIME types, ...) or data altering its behavior (like not sending an answer if it is already cached, ...). These HTTP headers form a block that end with an empty line.</li> <li>Then start the data block, which contains further data and is mainly used by the POST method.</li>
</ol>
<p>Examples of requests:</p>
<ul> <li>Fetching the root page of developer.mozilla.org, i.e. <a class="linkification-ext external" href="http://developer.mozilla.org/" title="Linkification: http://developer.mozilla.org/">http://developer.mozilla.org/</a>, and indicates to the server that it would like the page in French, if possible: <pre>GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr 

</pre> <p>Note the final empty line, separate 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 the empty line marking the ead of the headers is received.</p> </li> <li>Sending the result of the form:<br> <pre>POST /contact_form.php HTTP/1.1
Host: developer.mozilla.org
Content-Length: 64
Content-Type: application/x-www-form-urlencoded

name=Joe%20User&amp;request=Send%20me%20one%20of%20your%20catalogue
</pre> </li>
</ul>
<h4>Structure of a server response</h4>
<p>After the connected agent sent its request, the web server can handle it and finally sent a response back. Similarly to a client request, a server request is formed of text directives, separated by CRLF, though divided in three different blocks:</p>
<ol> <li>The first line, the <em>status line</em>, consists of an acknowledgment of the HTTP version used followed by an status request (and its meaning in human-readable text).</li> <li>The subsequent lines represent each a specific HTTP headers giving the client  information about the data sent (type, data size, compression algorithm used, hints about caching, ...). Similarly to the block of HTTP headers for the client request, these HTTP headers form a block that end with an empty line.</li> <li>Then start the data block, which contains the data.</li>
</ol>
<p>Examples of requests:</p>
<ul> <li>Successful reception of a web page: <pre>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

&lt;!DOCTYPE html... <em><strong>(here comes the 29769 bytes of the requested web page)</strong></em>

</pre> </li> <li>Notification that the requested resource has been permanently moved: <pre>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: <a class="linkification-ext" href="https://developer.mozilla.org/" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a> <strong><em>(this is the</em><em> new link to the resource; it is expected that the user-agent fetch it)</em></strong>
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 <em>(<strong>the content consists in a default page to display if the user-agent is not able to follow the link</strong></em>

&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;
&lt;html&gt;&lt;head&gt;
&lt;title&gt;301 Moved Permanently&lt;/title&gt;
&lt;/head&gt;&lt;body&gt;
&lt;h1&gt;Moved Permanently&lt;/h1&gt;
&lt;p&gt;The document has moved &lt;a href="<a class="linkification-ext" href="https://developer.mozilla.org/" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a>"&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;hr&gt;
&lt;address&gt;Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80&lt;/address&gt;
&lt;/body&gt;&lt;/html&gt;
 

</pre> </li> <li>Notification that the requested resource doesn't exists: <pre>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

&lt;!DOCTYPE html... <strong><em>(follows a site-customized page helping the user to find the missing resource)</em></strong>

</pre> </li>
</ul>
<h4>Persistent connections</h4>
<p>Persistent connections were introduced in HTTP/1.1. They allows to transmit several requests on the same TCP connection (or on the specific connected transport layer if the HTTP is not build upon TCP/IP). This has several advantages:</p>
<ul> <li>as the connection can be reused, requests can be <a href="/en/HTTP_Pipelining_FAQ" title="en/HTTP Pipelining FAQ">pipelined</a> to save part of the connection latency;</li> <li>by opening and closing fewer TCP connections, CPU time is saved;</li> <li>network congestion is diminished by lowering the total amount of TCP packets (less opening and closing TCP packets);</li> <li>the TCP stack has more time to detect network congestion and to adapt its sending and receiving windows;</li> <li>HTTP is more evolutive: the cost for trying a features is considerably lowered as an error response won't lead to the closing of the connection anymore.</li>
</ul>
<h3>HTTP Requests Methods</h3>
<h4>Safe methods</h4>
<p>A safe method is a method that doesn't have side-effects on the server. In other words, these indicates methods that are used only for <em>retrieval</em> of data. Any safe method is also idempotent. The safe HTTP methods are:</p>
<ul> <li>GET is the way to retrieve information identified by the request URI. This information may be generated on the fly and the GET may be conditional if any of the If-Modified-Since:, If-Unmodified-Since:, If-Match:, If-None-Match or If-Range HTTP headers are set. In that case the information is only sent back if the conditions are fulfilled.</li> <li>HEAD which is identical to GET but without the message body sent.</li>
</ul>
<div class="note"><strong>Note: </strong>for the GET method, when the page is generated by a script on the server side, like with PHP, ASP, cgi-bin or any other data-accepting process, it is up to the web developer to ensure that the safe propriety is matched. For example, in an online shop, it is its duty that several identical GET do not lead to several orders. This may be done by using a reference for each order, reference passed within the request URI of the GET.</div>
<h4>Idempotent methods</h4>
<p>An idempotent method is a method that the side-effects on the server of several identical requests with these method is the same as the side-effects of one single request.</p>
<ul> <li>HEAD and GET, as any safe method is also idempotent, as a safe method shouldn't have side-effects on the server;</li> <li>PUT is the way to upload information on the server. If the resource already exists is different, it is replaced, if it doesn't exists, it is created.</li> <li>DELETE removes a resource from the server.</li>
</ul><h4>Others methods</h4>
<ul> <li>OPTIONS</li> <li>TRACE</li>
</ul>
<h4>HTTP Requests Methods in HTML Forms</h4>
<p>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 at that point, only GET and POST method are allowed by the HTML specification.</p>
<div class="note"><strong>Note</strong>: the choice of a GET or POST method for HTML forms is not neutral. The GET method being a <a href="/en/HTTP#Safe_methods" title="https://developer.mozilla.org/en/HTTP#Safe_methods">safe method</a>, it should be used only in case where no side-effect is to be expected; e.g. it shouldn't be used to transmit an order as this order is a side-effect. In all case where such side-effects is expected, the POST method should be used, as it is a merely <a href="/en/HTTP#Idempotent_methods" title="https://developer.mozilla.org/en/HTTP#Idempotent_methods">idempotent method</a>.</div><h3>HTTP Response Codes</h3>
<p>When answering a client request, the server sent back a three digits code which indicates if the request was successfully processed or not. These codes can be groups in five categories:</p>
<ul> <li><dfn>Informational responses</dfn> (of the form 1xx), which form a class of codes indicating a provisional response. 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 <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#100-Continue" title="en/HTTP/Response Code#100-Continue">100 Continue</a></span> response, indicating that the client should continue to send its request. <div class="note"><strong>Note:</strong> no information response code where defined in the HTTP/1.0 and they must not be used when this version of the protocol is used.</div> </li> <li><dfn>Success responses</dfn> (of the form 2xx), which form a class of codes indicating that the client request has been successfully processed. The <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#200-OK" title="en/HTTP/Response Code#200-OK">200 OK</a></span> response is by far the most common of these responses, but the <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#206-Partial-Content" title="en/HTTP/Response Code#206-Partial-Content">206 Partial Content</a></span> is also often seen when fetching a file or some media data like video or audio.</li> <li><dfn>Redirection responses</dfn> (of the form 3xx), which form a class of codes indicating that the client request has moved and the server is not able to serve it. Most of theses responses contains some location information where to find the resource requested and user-agent often retrieve it then without further user interaction. The most common responses of these types are <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#301-Moved-Permanently" title="en/HTTP/Response Code#301-Moved-Permanently">301 Moved Permanently</a></span>, indicating that the URI given is no longer valid and has been moved to another place, and <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#302-Found" title="en/HTTP/Response Code#302-Found">302 Found</a></span> which indicates that the resource has been <em>temporary</em> moved to another place.<br> <div class="note"><strong>Note:</strong> for webmasters, it is recommended to set up a <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#301-Moved-Permanently" title="en/HTTP/Response Code#301-Moved-Permanently">301 Moved Permanently</a></span> redirection when moving pages to another URI. That allows users following links to still reach the resource and it also teach search engine 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 <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#301-Moved-Permanently" title="en/HTTP/Response Code#301-Moved-Permanently">301 Moved Permanently</a></span> response so that this information is cached by the client and prevent it to make unnecessary requests to the original URI prior to fetch the resource itself.</div> </li> <li><dfn>Client error responses</dfn> (of the form 4xx), which form a class of codes indicating that the request sent by the client is either invalid, incomplete or doesn't have enough rights to be performed. The most known is <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#404-Not-Found" title="en/HTTP/Response Code#404-Not-Found">404 Not Found</a></span> which is sent back when the URI requested doesn't exists, but a few others are often presented to the end user like: <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#400-Bad-Request" title="en/HTTP/Response Code#400-Bad-Request">400 Bad Request</a></span> 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 <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#403-Forbidden" title="en/HTTP/Response Code#403-Forbidden">403 Forbidden</a></span> when the client request a resource that does exists but isn't allowed to be transmitted (like a directory content).</li> <li><dfn>Server error responses</dfn> (of the form 5), which form a class of codes indicating that the server had a problem handling the valid client request. The two most common such responses are <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#500-Internal-Server-Error" title="en/HTTP/Response Code#500-Internal-Server-Error">500 Internal Server Error</a></span>, a generic error code indicating a bug in the server or <span style="font-family: Courier New;"><a href="/en/HTTP/Response_Code#503-Service-Unavailable" title="en/HTTP/Response Code#503-Service-Unavailable">503 Service Unavailable</a></span> indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or a database non available.</li>
</ul>
<p>A web developer shouldn't met many others response codes, but people building request using the <code><a href="/en/XMLHttpRequest" title="en/XMLHttpRequest">XMLHTTPRequest</a></code> function may hit <a href="/en/HTTP/Response_codes" title="en/HTTP/Response codes">less usual response codes</a>.</p><h3>HTTP Headers</h3>
<p>HTTP Headers allowes the client and the server to pass additional information with the request or the response. A request header consist on its case-insensitive name followed by a semi-colon ':', then by its value (without CRLF in it). Leading whitespace before its value are ignored.</p>
<p>Headers are grouped according the occasion in which they may appear:</p>
<dl> <dt>General headers</dt> <dd>These headers apply to both requests and responses but are unrelated to the response. They do therefore apply only to the message being transmitted. They are only a few of them and new ones cannot been added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is <span style="font-family: Times New Roman;">Cache-Control:</span>, <span style="font-family: Times New Roman;">Connection:</span>, <span style="font-family: Times New Roman;">Date:</span>, <span style="font-family: Times New Roman;">Pragma:</span>, <span style="font-family: Times New Roman;">Trailer:</span>, <span style="font-family: Times New Roman;">Transfer-Encoding:</span>, <span style="font-family: Times New Roman;">Upgrade:</span>, <span style="font-family: Times New Roman;">Via:</span> and <span style="font-family: Times New Roman;">Warning:</span>.</dd> <dt>Request headers</dt> <dd>These headers give more precise information about the resource to be fetched or about the client itself. Among them one find <a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">cache-related headers</a>, transforming a GET method in a conditional GET, like <span style="font-family: Times New Roman;">If-Modified-Since:</span>, user-preference information like <span style="font-family: Times New Roman;">Accept-Language:</span> or <span style="font-family: Times New Roman;">Accept-Charset:</span> or plain client information like <span style="font-family: Times New Roman;">User-Agent:</span>. New request headers cannot be added without bumping the version number of the HTTP protocol. But, it is usual that new request headers are being added if both the server and the client do agree on their meaning. Therefore a client should not assume that they will be handled adequately by the server; unknown request headers are being handled as entity headers.</dd> <dt>Response headers</dt> <dd>These headers give more information about the resource sent back, like its real location (<span style="font-family: Times New Roman;">Location:</span>) or about the server itself, like its name and version (<span style="font-family: Times New Roman;">Server:</span>). New response headers cannot be added without bumping the version number of the HTTP protocol. But, it is usual that new response headers are being added if both the server and the client do agree on their meaning. Therefore a server should not assume that they will be handled adequately by the client ; unknown response headers are being handled as entity headers.</dd> <dt>Entity headers</dt> <dd>These headers give more information about the body of the entity, like its length (<span style="font-family: Times New Roman;">Content-Length:</span>), a identifying hash (<span style="font-family: Times New Roman;">Content-MD5:</span>) or its MIME-type (<span style="font-family: Times New Roman;">Content-Type:</span>). New entity headers can be added without bumping the version number of the HTtP protocol. Note that non-standard entity headers must be prefixed with <span style="font-family: Times New Roman;">X</span>.</dd>
</dl>
<p>They may also be grouped according the expected behavior of caching and non-caching proxies regarding them:</p>
<dl> <dt>End-to-end headers</dt> <dd>These headers must be transmitted to the final recipient of the message, being the server for a request message or the client for a response message. It means that intermediate proxies must retransmit it unmodified and also that caches must store it.</dd> <dt>Hop-by-hop headers</dt> <dd>These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such are headers are: <span style="font-family: Times New Roman;">Connection:</span>, <span style="font-family: Times New Roman;">Keep-Alive:</span>, <span style="font-family: Times New Roman;">Proxy-Authenticate:</span>, <span style="font-family: Times New Roman;">Proxy-Authorization:</span>, <span style="font-family: Times New Roman;">TE:</span>, <span style="font-family: Times New Roman;">Trailers:</span>, <span style="font-family: Times New Roman;">Transfer-Encoding:</span> and <span style="font-family: Times New Roman;">Upgrade:</span>. Note that only hop-by-hop headers may be given through the <span style="font-family: Times New Roman;">Connection:</span> general header.</dd>
</dl>
<p>Though to learn about the specific semantic of each header, one should consult its entry in the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">comprehensive list of HTTP headers</a>, a few of them that are especially useful to web developers and webmasters are described in context.</p>
<h4>Useful request headers</h4>
<p>Among the numerous <a href="/en/HTTP/Headers" title="en/HTTP/Headers">HTTP request headers</a>, several are useful when set correctly. If the browser agent often set them correctly, according to the preferences of its user, it is important to ensure their presence when building your own requests, by using <a href="/en/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a> or when writing an extension and sending <a href="/en/Setting_HTTP_request_headers" title="en/Setting HTTP request headers">custom HTTP requests via XPCOM</a>.</p>
<dl> <dt>Controlling the language of the resource</dt> <dd>Most user-agent, like Firefox, allows the user to set his preference about in what language he wants to receive a resource. The browser translate this into an <span style="font-family: Times New Roman;">Accept-Language:</span> header. It is good practice for web developers, when building specific HTTP requests, to include such header too.</dd> <dt>Using conditional GET</dt> <dd>Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage is refreshed via an <a href="/en/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a>:, it is a good idea to use the <span style="font-family: Times New Roman;">If-Modified-Since:</span> header (and other similar ones) in order to fetch the new content only it has changed. It will lower the congestion of the network.</dd>
</dl>
<h4>Useful response headers</h4>
<p>The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">numerous HTTP response headers</a>, several are of several importance and should be configured</p>
<h5>Restricting framing</h5>
<p>Several cross-site scripting attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risks, modern browsers have introduced the <a href="/en/The_X-FRAME-OPTIONS_response_header" title="en/The X-FRAME-OPTIONS response header"><span style="font-family: Times New Roman;">X-Frame-Options:</span> response header</a>. By setting it with the value <code>DENY</code>, it prevents the browser to display 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 <a href="/en/Security/CSP/Introducing_Content_Security_Policy" title="en/Security/CSP/Introducing Content Security Policy">Content Security Policies</a>, may be helpful too.</p>
<h5>Compression</h5>
<p>Minimizing the amount of data transferred accelerate 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, resource requested by the client with an <span style="font-family: Times New Roman;">Accept-Encoding:</span> request header are compressed using the appropriate method and sent back, with an <span style="font-family: Times New Roman;">Content-Encoding:</span> response header. Setting these in Apache 2 servers is done by using the <a class=" external" href="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html" title="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html">mod_deflate module</a>.</p>
<div class="note"><strong>Note:</strong> be aware that not all data format can be efficiently compressed. Already compressed media data, like JPEG images or most audio and video formats, will not shrink with another pass of compression. In fact, they will often be greater due to the overhead of the compression method. It is important not to try to compress these resource type any further, no gain of size will be made and the compression/decompression mechanism is resource-hungry.</div>
<h5>Controlling cache</h5>
<p>Caching prevents the same resource to be fetched several times, though it didn't change. Configuring the servers with the correct response headers allows the user-agent to cache adequately the data. In order to do that, be sure that:</p>
<ul> <li>any static resource provides an <span style="font-family: Times New Roman;">Expires:</span> response header far in the future. That way they may stay in the cache until the user-agent flush it for its own reasons. <div class="note">On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires: <code>ExpiresDefault "access plus 1 month"</code>.</div> </li> <li>any dynamic resource provides a <span style="font-family: Times New Roman;">Cache-control:</span> response header. Theoretically, any HTTP request done with a safe-method (GET or HEAD) or even a solely idempotent one (POST, DELETE, PUT) may be cached; but, in practice careful study is needed to determine if the caching of the response may lead to unappropriate side-effects.</li>
</ul><h5>Controlling pipelining</h5>
<h3>Audio and video special cases</h3>
Revert to this revision