Jump to content

List of HTTP header fields: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 95: Line 95:
In the rare event that you specifically do not want a resource to be stored to disk anywhere - perhaps the resource is highly sensitive and you don't want it to appear in backups or to be written to insecure permanent storage - you can use the header <code>Cache-Control: no-store</code>. This does not guarantee that the resource will not be written, but instructs the browser to make a best effort not to write it, or in the worst case, that it does not remain on disk.
In the rare event that you specifically do not want a resource to be stored to disk anywhere - perhaps the resource is highly sensitive and you don't want it to appear in backups or to be written to insecure permanent storage - you can use the header <code>Cache-Control: no-store</code>. This does not guarantee that the resource will not be written, but instructs the browser to make a best effort not to write it, or in the worst case, that it does not remain on disk.


The <code>Pragma: no-cache</code> header is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses (e.g. some versions of IE, but only when using https), but the HTTP/1.1 rfc specifically warns against relying on it.
The <code>Pragma: no-cache</code> header is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses (e.g. some versions of IE, but only when using https), but the HTTP/1.1 rfc specifically warns against relying on this behaviour.


==References==
==References==

Revision as of 13:13, 3 December 2008

HTTP Headers form the core of an HTTP request, and are very important in an HTTP response. They define various characteristics of the data that is requested or the data that has been provided.

This is an incomplete list of some of the HTTP headers defined in RFC 2616 and RFC 2109 for HTTP/1.1

Requests

Header Description Example
Accept Content-Types that are acceptable Accept: text/plain
Accept-Charset Character sets that are acceptable Accept-Charset: iso-8859-5
Accept-Encoding Acceptable encodings Accept-Encoding: compress, gzip
Accept-Language Acceptable languages for response Accept-Language: da [1]
Accept-Ranges Allows the server to indicate its acceptance of range requests for a resource Accept-Ranges: bytes
Authorization Authentication credentials for HTTP authentication Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control Used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain Cache-Control: no-cache
Connection What type of connection the user-agent would prefer Connection: close
Cookie an HTTP cookie previously sent by the server with Set-Cookie (below) Cookie: $Version=1; UserId=JohnDoe
Date The date and time that the message was sent Date: Tue, 15 Nov 1994 08:12:31 GMT
Host The domain name of the server (for virtual hosting), mandatory since HTTP/1.1 Host: en.wikipedia.org
If-Modified-Since Allows a 304 Not Modified to be returned if content is unchanged If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match Allows a 304 Not Modified to be returned if content is unchanged, see HTTP ETag If-None-Match: "737060cd8c284d8af7ad3082f209582d"
Referer A common misspelling of referrer, this is the address of the previous web page from which a link to the currently requested page was followed. Referer: http://en.wikipedia.org/wiki/Main_Page
User-Agent The user agent string of the user agent User-Agent: Mozilla/5.0 (Linux; X11; UTF-8)

Responses

Header Description Example
Accept-Ranges What partial content range types this server supports Accept-Ranges: bytes
Age The age the object has been in a proxy cache in seconds Age: 12
Allow Valid actions for a specified resource. To be used for a 405 Method not allowed Allow: GET, HEAD
Cache-Control Tells all caching mechanisms from server to client whether they may cache this object Cache-Control: no-cache
Content-Encoding The type of encoding used on the data Content-Encoding: gzip
Content-Language The language the content is in Content-Language: da
Content-Length The length of the response body in 8-bit bytes Content-Length: 348
Content-Location An alternate location for the returned data Content-Location: /index.htm
Content-Disposition An opportunity to raise a "File Download" dialogue box for a known MIME type Content-Disposition: attachment; filename=fname.ext
Content-MD5 An MD5 sum of the content of the response Content-MD5: 3167b9c13ad2b6d36946493fc47976c8
Content-Range Where in a full body message this partial message belongs Content-Range: bytes 21010-47021/47022
Content-Type The mime type of this content Content-Type: text/html; charset=utf-8
Date The date and time that the message was sent Date: Tue, 15 Nov 1994 08:12:31 GMT
ETag An identifier for a specific version of a resource, often a Message Digest, see ETag ETag: 737060cd8c284d8af7ad3082f209582d
Expires Gives the date/time after which the response is considered stale Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified The last modified date for the requested object, in RFC 2822 format Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Location Used in redirection Location: http://www.w3.org/pub/WWW/People.html
Server A name for the server Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie an HTTP cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

Effects of selected HTTP headers

Avoiding Caching

If the server responds with Cache-Control: no-cache then a web browser or other caching system must not use the response to satisfy subsequent responses without first checking with the originating server. This header is part of HTTP/1.1, and is ignored by some caches and browsers. To make sure that an object is not cached, it is therefore sensible to also set the Expires HTTP 1.0 header to a value earlier than the response date (e.g. -1). This is interpreted as an instruction not to cache by HTTP/1.0 caches and browsers.

The fact that a resource is not to be cached is no guarantee that it will not be written to disk. In particular, the HTTP/1.1 definition draws a distinction between history stores and caches. If you use navigation buttons to go back to a previous page a browser may still show you a page that has been stored on disk in the history store, even if it has been instructed not to cache that page. This is correct behaviour according to the specification. Many user agents (including both Firefox and IE) will show different behaviour with regards to loading something from history store and loading something from its cache depending on whether the protocol is http or https.

In the rare event that you specifically do not want a resource to be stored to disk anywhere - perhaps the resource is highly sensitive and you don't want it to appear in backups or to be written to insecure permanent storage - you can use the header Cache-Control: no-store. This does not guarantee that the resource will not be written, but instructs the browser to make a best effort not to write it, or in the worst case, that it does not remain on disk.

The Pragma: no-cache header is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses (e.g. some versions of IE, but only when using https), but the HTTP/1.1 rfc specifically warns against relying on this behaviour.

References

See also

External links