1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
---
title: HTTP
slug: Web/HTTP
tags:
- HTTP
- Headers
- NeedsTranslation
- TopicStub
- Web
- Web Development
translation_of: Web/HTTP
---
<p>{{ HTTPSidebar }} </p>
<p>L'<dfn>Hypertext Transfer Protocol (HTTP)</dfn> è un protocollo del <a class="external" href="http://en.wikipedia.org/wiki/Application_Layer" title="http://en.wikipedia.org/wiki/Application_Layer">livello di applicazione</a> per il trasferimento di ipertesti. È usato per le comunicazioni tra i web browser e i web server, <span class="tlid-translation translation"><span title="">sebbene in linea di principio possa essere utilizzato anche per altri scopi</span></span>. Segue un classico <a class="external" href="http://en.wikipedia.org/wiki/Client%E2%80%93server_model" title="http://en.wikipedia.org/wiki/Client–server_model">modello client-server</a>, con apertura di una conessione da parte del client, creazione di una richiesta e poi attesa della risposta da parte del server dopo aver ricevuto la richiesta. È anche un <a class="external" href="http://en.wikipedia.org/wiki/Stateless_protocol" title="http://en.wikipedia.org/wiki/Stateless_protocol">protocollo senza stato</a>, cioè il server non mantiene nessun tipo di dato (stato) delle richieste.</p>
<p>Sebbene spesso basato su un livello TCP/IP, può essere usato su qualsiasi <a class="external" href="http://en.wikipedia.org/wiki/Transport_Layer" title="http://en.wikipedia.org/wiki/Transport_Layer">livello di trasporto</a> orientato alle connessioni.</p>
<h2 class="Documentation" id="Documentation" name="Documentation">Documentazione</h2>
<dl>
<dt><a href="/en-US/docs/Web/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Header</a></dt>
<dd>I messaggi Header HTTP vengono utilizzati per descrivere con precisione la risorsa da recuperare o il comportamento del server o del client. Header con proprietà personalizzate possono essere aggiunti usando il prefisso 'X-'; altri sono elencati in un <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html" title="http://www.iana.org/assignments/message-headers/perm-headers.html">registro IANA</a>, il cui contenuto originale è stato definito in <a class="external" href="http://tools.ietf.org/html/rfc4229" title="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA mantiene anche un <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html" title="http://www.iana.org/assignments/message-headers/prov-headers.html">registro delle nuove proposte di messaggi Header HTTP</a>.</dd>
<dt><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookie</a></dt>
<dd>Come lavorano i cookie è stato definito nel <a class="external" href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>. Quando riceve una richiesta HTTP, un server può inviare un header <code>Set-Cookie</code> con la risposta. Successivamente, il valore del cookie viene inviato insieme a ogni richiesta effettuata sullo stesso server sotto forma di un'intestazione HTTP <code>Cookie</code>. Inoltre, è possibile specificare un ritardo di scadenza. È possibile specificare anche restrizioni a un dominio e un percorso specifici.</dd>
<dt><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Autenticazione di accesso di base</a></dt>
<dd>Nel contesto di una transazione HTTP, l'autenticazione di accesso di base è un metodo per un <a href="https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.userAgent" title="HTTP user agent">HTTP user agent</a> per fornire un nome utente e una password quando si effettua una richiesta.</dd>
<dt><a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">Pipelining HTTP FAQ</a></dt>
<dd>Pipelining HTTP/1.1 FAQ</dd>
<dt><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">Controllo accessi HTTP (CORS)</a></dt>
<dd><strong>Le richieste HTTP cross-site</strong> sono richieste <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> per risorse da un <strong>dominio diverso</strong> rispetto al dominio della risorsa che effettua la richiesta. Ad esempio, una risorsa caricata dal Dominio A (<code><span class="nowiki">http://domaina.example</span></code>) come una pagina Web HTML, effettua una richiesta per una risorsa sul Dominio B (<code><span class="nowiki">http://domainb.foo</span></code>), come un'immagine, usando l'elemento <code>img</code> (<code><span class="nowiki">http://domainb.foo/image.jpg</span></code>). Questo si verifica molto comunemente sul Web oggi: le pagine caricano un numero di risorse in modo cross-site, inclusi fogli di stile CSS, immagini e script e altre risorse.</dd>
<dt><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controllo del prefetching DNS</a></dt>
<dd>Firefox 3.5 esegue il <strong>prefetching DNS</strong>. Questa è una funzionalità con cui Firefox esegue proattivamente la risoluzione dei nomi di dominio su entrambi i link che l'utente può scegliere di seguire e gli URL per gli elementi a cui fa riferimento il documento, incluse immagini, CSS, JavaScript e così via. Questo prefetch viene eseguito in background, in modo che il DNS sia già stato risolto nel momento in cui gli elementi di riferimento sono effettivamente necessari. Ciò riduce la latenza quando, ad esempio, l'utente fa effettivamente clic su un collegamento.</dd>
<dt><a href="/en-US/docs/Web/HTTP/Response_codes" title="/en-US/docs/HTTP/HTTP_response_codes">Codici di risposta HTTP</a></dt>
<dd>I codici di risposta HTTP indicano se una specifica richiesta <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> è stata completata con successo. Le risposte sono raggruppate in cinque classi: risposte informative, risposte positive, reindirizzamenti, errori del client e errori del server.</dd>
</dl>
<h2 id="A_brief_history_of_HTTP">A brief history of HTTP</h2>
<p>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 '<span style="font-family: courier new;">?</span>' character.</p>
<p>Then, in 1992, a version was published that became, with some minor changes, 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 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 <a class="external" href="http://en.wikipedia.org/wiki/Mime_types" title="http://en.wikipedia.org/wiki/Mime_types">MIME types</a> in conjunction with the <code>Content-Type:</code> header.</p>
<p>In 1995, the <a class="external" href="http://www.ietf.org/" title="http://www.ietf.org/">IETF</a> 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 <a class="external" href="http://tools.ietf.org/html/rfc2068" title="http://tools.ietf.org/html/rfc2068">RFC 2068</a>, with minor fixes in <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> two years later.</p>
<p>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 <code>Host:</code> 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.</p>
<p>Since then, the HTTP protocol evolved by adding new <a href="/en/HTTP/Headers" title="en/HTTP/Headers">headers</a>, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.</p>
<p>HTTP/1.1 is currently being revised by the <a class="external" href="http://tools.ietf.org/wg/httpbis/" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a>.</p>
<ul>
</ul>
<h2 id="HTTP_request_methods">HTTP request methods</h2>
<p>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 <a href="/en/WebDAV" title="en/WebDAV">WebDAV</a>. The <a class="external" href="http://tools.ietf.org/wg/httpbis/" rel="external nofollow" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a> 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">501 Not implemented</a></span> response; if it knows the method but is configured not to answer it, it must return a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">405 Method not allowed</a></span> response. Two methods are required to be supported: HEAD and GET; all others are optional.</p>
<p>Two specific semantics are defined in the standard and are crucial for web developers: the <em>safety</em> property and the <em>idempotent</em> property.</p>
<h3 id="Safe_methods">Safe methods</h3>
<p>A <dfn>safe method</dfn> 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 <em>retrieval</em> of data. The safe HTTP methods defined in HTTP/1.1 are:</p>
<ul>
<li>GET, used to retrieve information identified by the request URI. This information may be generated on the fly or the GET may be conditional if any of the {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} or {{ httpheader("If-Range") }} HTTP headers are set. In that latter case the information is only sent back if all the conditions are fulfilled.</li>
<li>HEAD, which is identical to GET but without the message body sent.</li>
</ul>
<div class="note"><strong>Notes: </strong>
<ul>
<li>Any safe method is also <em>idempotent</em>.</li>
<li>Not having any side-effects means, for the GET method, that it <strong>must</strong> not be used to trigger an action outside the server, like an order in an e-commerce site. If a side-effect is wanted, a non-<em>idempotent</em> method should be used, like POST.</li>
<li>When a page is generated on the fly by a script, the script engine may calculate the page as if it was requested by a GET and then strip the data block. This does not cause problem as long as the GET as implemented in the script is <em>safe</em>, but if it has any side-effects (like triggering an order on an e-commerce site), the HEAD method will trigger it too. It is up to the web developer to ensure that both the GET and HEAD method are safely implemented.</li>
</ul>
</div>
<h3 id="Idempotent_methods">Idempotent methods</h3>
<p>An <dfn>idempotent method</dfn> 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.</p>
<ul>
<li>HEAD and GET, like any safe method, are also idempotent, as a safe method doesn't have side-effects on the server.</li>
<li>PUT is the way to upload a new resource on the server. If the resource already exists and is different, it is replaced; if it doesn't exist, it is created.</li>
<li>DELETE removes a resource from the server.</li>
</ul>
<h3 id="Other_methods">Other methods</h3>
<ul>
<li>POST is the way to trigger an action on the server. It has side-effects and can be used to trigger an order, to modify a database, to post a message in a forum, and so on.</li>
<li>OPTIONS is a request for communication options available on the chain between the client and the server (through eventual proxies); this method is typically sent before any <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">preflighted cross-origin request</a>, in order to know whether it is safe to do it.
<div class="note"><strong>Note:</strong> <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">Preflighted cross-origin requests</a> cannot be done on servers which don't allow or support the OPTIONS method.</div>
</li>
<li>TRACE is a kind of ping between the client and the server (through eventual proxies).</li>
</ul>
<p>Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.</p>
<p>The CONNECT method is defined in <a class="external" href="http://tools.ietf.org/html/rfc2817" title="http://tools.ietf.org/html/rfc2817">RFC 2817</a>.</p>
<h3 id="HTTP_Requests_Methods_in_HTML_Forms">HTTP Requests Methods in HTML Forms</h3>
<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 with these attributes; only GET and POST method are allowed by the HTML specification. See <a href="http://programmers.stackexchange.com/a/211790">this StackExchange answer why other HTTP request methods are not allowed by the HTML specification</a>.</p>
<div class="note"><strong>Note</strong>: The choice of a GET or POST method for HTML forms is not neutral. Because the GET method is 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 cases where no side-effect is expected; e.g., it shouldn't be used to transmit an order, as this order is a side-effect. In all cases where such side-effects are expected, the POST method should be used.</div>
<h2 id="HTTP_response_codes">HTTP response codes</h2>
<p>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:</p>
<ul>
<li><dfn>Informational responses</dfn> (of the form <code>1xx</code>) 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#100" title="en/HTTP/HTTP response codes#100">100 Continue</a></span> response, indicating that the client should continue to send its request.
<div class="note"><strong>Note:</strong> No information response codes were defined in the HTTP/1.0, and therefore they must not be sent back when this version of the protocol is used.</div>
</li>
<li><dfn>Success responses</dfn> (of the form <code>2xx</code>) are for successfully processed requests. The <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#200" title="en/HTTP/HTTP response codes#200">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/HTTP_response_codes#206" title="en/HTTP/HTTP response codes#206">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 <code>3xx</code>) 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">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/HTTP_response_codes#302" title="en/HTTP/HTTP response codes#302">302 Found</a></span> which indicates that the resource has been <em>temporarily</em> moved to another place.
<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/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> 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.</div>
</li>
<li><dfn>Client error responses</dfn> (of the form <code>4xx</code>) 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#404" title="en/HTTP/HTTP response codes#404">404 Not Found</a></span> which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#400" title="en/HTTP/HTTP response codes#400">400 Bad Request</a></span> 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 <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#403" title="en/HTTP/HTTP response codes#403">403 Forbidden</a></span>, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content).</li>
<li><dfn>Server error responses</dfn> (of the form <code>5xx</code>) indicate 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/HTTP_response_codes#500" title="en/HTTP/HTTP response codes#500">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/HTTP_response_codes#503" title="en/HTTP/HTTP response codes#503">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 the non-availability of a database.</li>
</ul>
<p>A web developer shouldn't encounter many other response codes, but people building requests using the <code><a href="/en/nsIXMLHttpRequest" title="en/XMLHttpRequest">XMLHTTPRequest</a></code> function may hit <a href="/en/HTTP/HTTP_response_codes" title="en/HTTP/HTTP response codes">less usual response codes</a>.</p>
<h3 id="More_on_redirection_responses">More on redirection responses</h3>
<p>Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a <code>javascript:</code> 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.</p>
<h2 id="HTTP_headers">HTTP headers</h2>
<p>HTTP headers allow 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.</p>
<p>Headers are grouped according the context 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 data eventually transmitted in the body. They therefore apply only to the message being transmitted. There are only a few of them and new ones cannot be added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.</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 can 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 {{ httpheader("If-Modified-Since") }}, user-preference information like {{ httpheader("Accept-Language") }} or {{ httpheader("Accept-Charset") }} or plain client information like {{ httpheader("User-Agent") }}. New request headers cannot officially be added without increasing the version number of the HTTP protocol. But, it is common for new request headers to be added if both the server and the client agree on their meaning. In that case, a client should not assume that they will be handled adequately by the server; unknown request headers are handled as <em>entity headers</em>.</dd>
<dt>Response headers</dt>
<dd>These headers give more information about the resource sent back, like its real location ({{ httpheader("Location") }}) or about the server itself, like its name and version ({{ httpheader("Server") }}). New response headers cannot be added without increasing the version number of the HTTP protocol. But, it is common for new response headers to be added if both the server and the client agree on their meaning. In that case, a server should not assume that they will be handled adequately by the client ; unknown response headers are handled as <em>entity headers</em>.</dd>
<dt>Entity headers</dt>
<dd>These headers give more information about the body of the entity, like its length ({{ httpheader("Content-Length") }}), an identifying hash ({{ httpheader("Content-MD5") }}), or its MIME-type ({{ httpheader("Content-Type") }}). New entity headers can be added without increasing the version number of the HTTP protocol.</dd>
</dl>
<p>Headers can also be grouped according to how caching and non-caching proxies handle them:</p>
<dl>
<dt>End-to-end headers</dt>
<dd>These headers must be transmitted to the final recipient of the message; that is, the server for a request message or the client for a response message. Such a header 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 headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.</dd>
</dl>
<p>In order to learn about the specific semantic of each header, see its entry in the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">comprehensive list of HTTP headers</a>.</p>
<h3 id="Useful_request_headers">Useful request headers</h3>
<p>Among the numerous <a href="/en/HTTP/Headers" title="en/HTTP/Headers">HTTP request headers</a>, several are especially useful when set correctly. If you are building your own requests, by using <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code> 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>, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.</p>
<dl>
<dt>Controlling the language of the resource</dt>
<dd>Most user-agents, like Firefox, allow the user to set a preference for the language for receiving a resource. The browser translate this into an {{ httpheader("Accept-Language") }} header. It is good practice for web developers, when building specific HTTP requests, to include such a 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 are refreshed via an <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code>:, 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.</dd>
</dl>
<h3 id="Useful_response_headers">Useful response headers</h3>
<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 specific importance and should be configured on the server</p>
<h4 id="Restricting_framing">Restricting framing</h4>
<p>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 <code><a href="/en/Security/CSP/CSP_policy_directives#frame-ancestors" title="en/The X-FRAME-OPTIONS response header">CSP frame-ancestors directive</a></code>. By setting it with the value <code>'none'</code>, 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 <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>
<h4 id="Compression">Compression</h4>
<p>Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like <a href="/en/CSS/CSS_Sprites" title="en/CSS/CSS Sprites">CSS Sprites</a>, 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 <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 formats can be efficiently compressed. Already-compressed media data, like JPEG images or most audio and video formats, do not shrink using another pass of compression. In fact, they often become larger due to the overhead of the compression method. It is important not to try to compress these resource types any further; there is no advantage in size and the compression/decompression mechanism is resource-intensive.</div>
<h4 id="Controlling_cache">Controlling cache</h4>
<p><a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">HTTP Caching</a> 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:</p>
<ul>
<li>Any static resource provides an {{ httpheader("Expires") }} response header that is set to far in the future. That way, the resource may stay in the cache until the user-agent flushes it for its own reasons (like reaching its cache size limit).
<div class="note"><strong>Note: </strong>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 {{ httpheader("Cache-control") }} response header. Theoretically, any HTTP request done through a <a href="/en/HTTP#Safe_Methods" title="en/HTTP#Safe Methods">safe method</a> (GET or HEAD) or even through a solely <a href="/en/HTTP#Idempotent_Methods" title="en/HTTP#Idempotent Methods">idempotent one</a> (DELETE, PUT) may be cached; but in practice careful study is needed to determine if the caching of the response may lead to inappropriate side-effects.</li>
</ul>
<h4 id="Setting_the_correct_MIME_types">Setting the correct MIME types</h4>
<p>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.</p>
<div class="note"><strong>Note: </strong>
<ul>
<li>On Apache, one can match file extensions with a given MIME type in the .htaccess using the <font face="Verdana,Helvetica,Arial"><span style="font-family: courier new;"><code>AddType</code></span> type directive like</font><code> AddType image/jpeg jpg.</code></li>
<li>Most web servers send unknown-type resources using the default <code>application/octet-stream</code> 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:
<ul>
<li>
<p>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 <code>application/x-rar-compressed </code>MIME type or some users won't be able to define a useful default action for them.</p>
</li>
<li>
<p>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 <a href="/En/Media_formats_supported_by_the_audio_and_video_elements" title="En/Media formats supported by the audio and video elements">use the correct MIME type for audio and video resources</a>.</p>
</li>
<li>
<p>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 <a class="external" href="http://en.wikipedia.org/wiki/Keyhole_Markup_Language" title="http://en.wikipedia.org/wiki/Keyhole_Markup_Language">Keyhole Markup Language</a>, which should be served as <code>application/vnd.google-earth.kml+xml </code>for an optimal user experience.</p>
</li>
</ul>
</li>
</ul>
</div>
<h2 id="See_also">See also</h2>
<ul>
<li><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controlling DNS prefetching</a></li>
<li>The <a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></li>
<li><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookies</a></li>
<li><a href="/en-US/docs/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Headers</a></li>
<li><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Basic access authentication</a></li>
<li><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></li>
</ul>
<p>{{ languages( { "ja": "ja/HTTP"} ) }}</p>
|
