[Note: This document has been edited to include only sections 1.4, 3.2, 4, 5.1, 6.1, 8.1.1, 9.3-9.7, 13.2, 14.21, 14.23, 14.36, 14.43 as specified in the SI540 syllabus.]
Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: 2068 J. Gettys
Category: Standards Track Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999
Hypertext Transfer Protocol -- HTTP/1.1
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers [47]. A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
Fielding, et al. Standards Track [Page 1]
RFC 2616 HTTP/1.1 June 1999
Table of Contents
1 Introduction ...................................................7
1.1 Purpose......................................................7
1.2 Requirements .................................................8
1.3 Terminology ..................................................8
1.4 Overall Operation ...........................................12
2 Notational Conventions and Generic Grammar ....................14
2.1 Augmented BNF ...............................................14
2.2 Basic Rules .................................................15
3 Protocol Parameters ...........................................17
3.1 HTTP Version ................................................17
3.2 Uniform Resource Identifiers ................................18
3.2.1 General Syntax ...........................................19
3.2.2 http URL .................................................19
3.2.3 URI Comparison ...........................................20
3.3 Date/Time Formats ...........................................20
3.3.1 Full Date ................................................20
3.3.2 Delta Seconds ............................................21
3.4 Character Sets ..............................................21
3.4.1 Missing Charset ..........................................22
3.5 Content Codings .............................................23
3.6 Transfer Codings ............................................24
3.6.1 Chunked Transfer Coding ..................................25
3.7 Media Types .................................................26
3.7.1 Canonicalization and Text Defaults .......................27
3.7.2 Multipart Types ..........................................27
3.8 Product Tokens ..............................................28
3.9 Quality Values ..............................................29
3.10 Language Tags ...............................................29
3.11 Entity Tags .................................................30
3.12 Range Units .................................................30
4 HTTP Message ..................................................31
4.1 Message Types ...............................................31
4.2 Message Headers .............................................31
4.3 Message Body ................................................32
4.4 Message Length ..............................................33
4.5 General Header Fields .......................................34
5 Request .......................................................35
5.1 Request-Line ................................................35
5.1.1 Method ...................................................36
5.1.2 Request-URI ..............................................36
5.2 The Resource Identified by a Request ........................38
5.3 Request Header Fields .......................................38
6 Response ......................................................39
6.1 Status-Line .................................................39
6.1.1 Status Code and Reason Phrase ............................39
6.2 Response Header Fields ......................................41
Fielding, et al. Standards Track [Page 2]
RFC 2616 HTTP/1.1 June 1999
7 Entity ........................................................42
7.1 Entity Header Fields ........................................42
7.2 Entity Body .................................................43
7.2.1 Type .....................................................43
7.2.2 Entity Length ............................................43
8 Connections ...................................................44
8.1 Persistent Connections ......................................44
8.1.1 Purpose ..................................................44
8.1.2 Overall Operation ........................................45
8.1.3 Proxy Servers ............................................46
8.1.4 Practical Considerations .................................46
8.2 Message Transmission Requirements ...........................47
8.2.1 Persistent Connections and Flow Control ..................47
8.2.2 Monitoring Connections for Error Status Messages .........48
8.2.3 Use of the 100 (Continue) Status .........................48
8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
9 Method Definitions ............................................51
9.1 Safe and Idempotent Methods .................................51
9.1.1 Safe Methods .............................................51
9.1.2 Idempotent Methods .......................................51
9.2 OPTIONS .....................................................52
9.3 GET .........................................................53
9.4 HEAD ........................................................54
9.5 POST ........................................................54
9.6 PUT .........................................................55
9.7 DELETE ......................................................56
9.8 TRACE .......................................................56
9.9 CONNECT .....................................................57
10 Status Code Definitions ......................................57
10.1 Informational 1xx ...........................................57
10.1.1 100 Continue .............................................58
10.1.2 101 Switching Protocols ..................................58
10.2 Successful 2xx ..............................................58
10.2.1 200 OK ...................................................58
10.2.2 201 Created ..............................................59
10.2.3 202 Accepted .............................................59
10.2.4 203 Non-Authoritative Information ........................59
10.2.5 204 No Content ...........................................60
10.2.6 205 Reset Content ........................................60
10.2.7 206 Partial Content ......................................60
10.3 Redirection 3xx .............................................61
10.3.1 300 Multiple Choices .....................................61
10.3.2 301 Moved Permanently ....................................62
10.3.3 302 Found ................................................62
10.3.4 303 See Other ............................................63
10.3.5 304 Not Modified .........................................63
10.3.6 305 Use Proxy ............................................64
10.3.7 306 (Unused) .............................................64
Fielding, et al. Standards Track [Page 3]
RFC 2616 HTTP/1.1 June 1999
10.3.8 307 Temporary Redirect ...................................65
10.4 Client Error 4xx ............................................65
10.4.1 400 Bad Request .........................................65
10.4.2 401 Unauthorized ........................................66
10.4.3 402 Payment Required ....................................66
10.4.4 403 Forbidden ...........................................66
10.4.5 404 Not Found ...........................................66
10.4.6 405 Method Not Allowed ..................................66
10.4.7 406 Not Acceptable ......................................67
10.4.8 407 Proxy Authentication Required .......................67
10.4.9 408 Request Timeout .....................................67
10.4.10 409 Conflict ............................................67
10.4.11 410 Gone ................................................68
10.4.12 411 Length Required .....................................68
10.4.13 412 Precondition Failed .................................68
10.4.14 413 Request Entity Too Large ............................69
10.4.15 414 Request-URI Too Long ................................69
10.4.16 415 Unsupported Media Type ..............................69
10.4.17 416 Requested Range Not Satisfiable .....................69
10.4.18 417 Expectation Failed ..................................70
10.5 Server Error 5xx ............................................70
10.5.1 500 Internal Server Error ................................70
10.5.2 501 Not Implemented ......................................70
10.5.3 502 Bad Gateway ..........................................70
10.5.4 503 Service Unavailable ..................................70
10.5.5 504 Gateway Timeout ......................................71
10.5.6 505 HTTP Version Not Supported ...........................71
11 Access Authentication ........................................71
12 Content Negotiation ..........................................71
12.1 Server-driven Negotiation ...................................72
12.2 Agent-driven Negotiation ....................................73
12.3 Transparent Negotiation .....................................74
13 Caching in HTTP ..............................................74
13.1.1 Cache Correctness ........................................75
13.1.2 Warnings .................................................76
13.1.3 Cache-control Mechanisms .................................77
13.1.4 Explicit User Agent Warnings .............................78
13.1.5 Exceptions to the Rules and Warnings .....................78
13.1.6 Client-controlled Behavior ...............................79
13.2 Expiration Model ............................................79
13.2.1 Server-Specified Expiration ..............................79
13.2.2 Heuristic Expiration .....................................80
13.2.3 Age Calculations .........................................80
13.2.4 Expiration Calculations ..................................83
13.2.5 Disambiguating Expiration Values .........................84
13.2.6 Disambiguating Multiple Responses ........................84
13.3 Validation Model ............................................85
13.3.1 Last-Modified Dates ......................................86
Fielding, et al. Standards Track [Page 4]
RFC 2616 HTTP/1.1 June 1999
13.3.2 Entity Tag Cache Validators ..............................86
13.3.3 Weak and Strong Validators ...............................86
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
13.3.5 Non-validating Conditionals ..............................90
13.4 Response Cacheability .......................................91
13.5 Constructing Responses From Caches ..........................92
13.5.1 End-to-end and Hop-by-hop Headers ........................92
13.5.2 Non-modifiable Headers ...................................92
13.5.3 Combining Headers ........................................94
13.5.4 Combining Byte Ranges ....................................95
13.6 Caching Negotiated Responses ................................95
13.7 Shared and Non-Shared Caches ................................96
13.8 Errors or Incomplete Response Cache Behavior ................97
13.9 Side Effects of GET and HEAD ................................97
13.10 Invalidation After Updates or Deletions ...................97
13.11 Write-Through Mandatory ...................................98
13.12 Cache Replacement .........................................99
13.13 History Lists .............................................99
14 Header Field Definitions ....................................100
14.1 Accept .....................................................100
14.2 Accept-Charset .............................................102
14.3 Accept-Encoding ............................................102
14.4 Accept-Language ............................................104
14.5 Accept-Ranges ..............................................105
14.6 Age ........................................................106
14.7 Allow ......................................................106
14.8 Authorization ..............................................107
14.9 Cache-Control ..............................................108
14.9.1 What is Cacheable .......................................109
14.9.2 What May be Stored by Caches ............................110
14.9.3 Modifications of the Basic Expiration Mechanism .........111
14.9.4 Cache Revalidation and Reload Controls ..................113
14.9.5 No-Transform Directive ..................................115
14.9.6 Cache Control Extensions ................................116
14.10 Connection ...............................................117
14.11 Content-Encoding .........................................118
14.12 Content-Language .........................................118
14.13 Content-Length ...........................................119
14.14 Content-Location .........................................120
14.15 Content-MD5 ..............................................121
14.16 Content-Range ............................................122
14.17 Content-Type .............................................124
14.18 Date .....................................................124
14.18.1 Clockless Origin Server Operation ......................125
14.19 ETag .....................................................126
14.20 Expect ...................................................126
14.21 Expires ..................................................127
14.22 From .....................................................128
Fielding, et al. Standards Track [Page 5]
RFC 2616 HTTP/1.1 June 1999
14.23 Host .....................................................128
14.24 If-Match .................................................129
14.25 If-Modified-Since ........................................130
14.26 If-None-Match ............................................132
14.27 If-Range .................................................133
14.28 If-Unmodified-Since ......................................134
14.29 Last-Modified ............................................134
14.30 Location .................................................135
14.31 Max-Forwards .............................................136
14.32 Pragma ...................................................136
14.33 Proxy-Authenticate .......................................137
14.34 Proxy-Authorization ......................................137
14.35 Range ....................................................138
14.35.1 Byte Ranges ...........................................138
14.35.2 Range Retrieval Requests ..............................139
14.36 Referer ..................................................140
14.37 Retry-After ..............................................141
14.38 Server ...................................................141
14.39 TE .......................................................142
14.40 Trailer ..................................................143
14.41 Transfer-Encoding..........................................143
14.42 Upgrade ..................................................144
14.43 User-Agent ...............................................145
14.44 Vary .....................................................145
14.45 Via ......................................................146
14.46 Warning ..................................................148
14.47 WWW-Authenticate .........................................150
15 Security Considerations .......................................150
15.1 Personal Information....................................151
15.1.1 Abuse of Server Log Information .........................151
15.1.2 Transfer of Sensitive Information .......................151
15.1.3 Encoding Sensitive Information in URI's .................152
15.1.4 Privacy Issues Connected to Accept Headers ..............152
15.2 Attacks Based On File and Path Names .......................153
15.3 DNS Spoofing ...............................................154
15.4 Location Headers and Spoofing ..............................154
15.5 Content-Disposition Issues .................................154
15.6 Authentication Credentials and Idle Clients ................155
15.7 Proxies and Caching ........................................155
15.7.1 Denial of Service Attacks on Proxies....................156
16 Acknowledgments .............................................156
17 References ..................................................158
18 Authors' Addresses ..........................................162
19 Appendices ..................................................164
19.1 Internet Media Type message/http and application/http ......164
19.2 Internet Media Type multipart/byteranges ...................165
19.3 Tolerant Applications ......................................166
19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
Fielding, et al. Standards Track [Page 6]
RFC 2616 HTTP/1.1 June 1999
19.4.1 MIME-Version ............................................167
19.4.2 Conversion to Canonical Form ............................167
19.4.3 Conversion of Date Formats ..............................168
19.4.4 Introduction of Content-Encoding ........................168
19.4.5 No Content-Transfer-Encoding ............................168
19.4.6 Introduction of Transfer-Encoding .......................169
19.4.7 MHTML and Line Length Limitations .......................169
19.5 Additional Features ........................................169
19.5.1 Content-Disposition .....................................170
19.6 Compatibility with Previous Versions .......................170
19.6.1 Changes from HTTP/1.0 ...................................171
19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
19.6.3 Changes from RFC 2068 ...................................172
20 Index .......................................................175
21 Full Copyright Statement ....................................176
1 Introduction
1.4 Overall Operation
The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request
modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code,
followed by a MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in appendix 19.4.
Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
A more complicated situation occurs when one or more intermediaries
are present in the request/response chain. There are three common
forms of intermediary: proxy, gateway, and tunnel. A proxy is a
forwarding agent, receiving requests for a URI in its absolute form,
rewriting all or part of the message, and forwarding the reformatted
request toward the server identified by the URI. A gateway is a
receiving agent, acting as a layer above some other server(s) and, if
necessary, translating the requests to the underlying server's
protocol. A tunnel acts as a relay point between two connections
without changing the messages; tunnels are used when the
communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents
of the messages.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections.
This distinction is important because some HTTP communication options
Fielding, et al. Standards Track [Page 12]
RFC 2616 HTTP/1.1 June 1999
may apply only to the connection with the nearest, non-tunnel
neighbor, only to the end-points of the chain, or to all connections
along the chain. Although the diagram is linear, each participant may
be engaged in multiple, simultaneous communications. For example, B
may be receiving requests from many clients other than A, and/or
forwarding requests to servers other than C, at the same time that it
is handling A's request.
Any party to the communication which is not acting as a tunnel may
employ an internal cache for handling requests. The effect of a cache
is that the request/response chain is shortened if one of the
participants along the chain has a cached response applicable to that
request. The following illustrates the resulting chain if B has a
cached copy of an earlier response from O (via C) for a request which
has not been cached by UA or A.
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
Not all responses are usefully cacheable, and some requests may
contain modifiers which place special requirements on cache behavior.
HTTP requirements for cache behavior and cacheable responses are
defined in section 13.
In fact, there are a wide variety of architectures and configurations
of caches and proxies currently being experimented with or deployed
across the World Wide Web. These systems include national hierarchies
of proxy caches to save transoceanic bandwidth, systems that
broadcast or multicast cache entries, organizations that distribute
subsets of cached data via CD-ROM, and so on. HTTP systems are used
in corporate intranets over high-bandwidth links, and for access via
PDAs with low-power radio links and intermittent connectivity. The
goal of HTTP/1.1 is to support the wide diversity of configurations
already deployed while introducing protocol constructs that meet the
needs of those who build web applications that require high
reliability and, failing that, at least reliable indications of
failure.
HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification.
Fielding, et al. Standards Track [Page 13]
RFC 2616 HTTP/1.1 June 1999
In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response exchanges, although connections may be
closed for a variety of reasons (see section 8.1).
3 Protocol Parameters
3.2 Uniform Resource Identifiers
URIs have been known by many names: WWW addresses, Universal Document
Identifiers, Universal Resource Identifiers [3], and finally the
combination of Uniform Resource Locators (URL) [4] and Names (URN)
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are
simply formatted strings which identify--via name, location, or any
other characteristic--a resource.
Fielding, et al. Standards Track [Page 18]
RFC 2616 HTTP/1.1 June 1999
3.2.1 General Syntax
URIs in HTTP can be represented in absolute form or relative to some
known base URI [11], depending upon the context of their use. The two
forms are differentiated by the fact that absolute URIs always begin
with a scheme name followed by a colon. For definitive information on
URL syntax and semantics, see "Uniform Resource Identifiers (URI):
Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
1738 [4] and RFC 1808 [11]). This specification adopts the
definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"host","abs_path", "rel_path", and "authority" from that
specification.
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
3.2.2 http URL
The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics
are that the identified resource is located at the server listening
for TCP connections on that port of that host, and the Request-URI
for the resource is abs_path (section 5.1.2). The use of IP addresses
in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
the abs_path is not present in the URL, it MUST be given as "/" when
used as a Request-URI for a resource (section 5.1.2). If a proxy
receives a host name which is not a fully qualified domain name, it
MAY add its domain to the host name it received. If a proxy receives
a fully qualified domain name, the proxy MUST NOT change the host
name.
Fielding, et al. Standards Track [Page 19]
RFC 2616 HTTP/1.1 June 1999
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default
port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
4 HTTP Message
4.1 Message Types
HTTP messages consist of requests from client to server and responses
from server to client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic
message format of RFC 822 [9] for transferring entities (the payload
of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
extra CRLF.
4.2 Message Headers
HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive. The field value MAY be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything
Fielding, et al. Standards Track [Page 31]
RFC 2616 HTTP/1.1 June 1999
beyond the common forms.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
4.3 Message Body
The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer-coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.41).
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
Fielding, et al. Standards Track [Page 32]
RFC 2616 HTTP/1.1 June 1999
entity, and thus MAY be added or removed by any application along the
request/response chain. (However, section 3.6 places restrictions on
when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for
requests and responses.
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.
For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length.
4.4 Message Length
The transfer-length of a message is the length of the message-body as
it appears in the message; that is, after any transfer-codings have
been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the following
(in order of precedence):
1.Any response message which "MUST NOT" include a message-body (such
as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in
the message.
2.If a Transfer-Encoding header field (section 14.41) is present and
has any value other than "identity", then the transfer-length is
defined by use of the "chunked" transfer-coding (section 3.6),
unless the message is terminated by closing the connection.
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
Fielding, et al. Standards Track [Page 33]
RFC 2616 HTTP/1.1 June 1999
header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
4.If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length. This media type
UST NOT be used unless the sender knows that the recipient can arse
it; the presence in a request of a Range header with ultiple byte-
range specifiers from a 1.1 client implies that the lient can parse
multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1,3 or 5 of
this section.
5.By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a response.)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given,
the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer-coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length cannot be determined
in advance.
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.
When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
4.5 General Header Fields
There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the
Fielding, et al. Standards Track [Page 34]
RFC 2616 HTTP/1.1 June 1999
message being transmitted.
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity-header fields.
5 Request
A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource,
the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
5.1 Request-Line
The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF is allowed
except in the final CRLF sequence.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Fielding, et al. Standards Track [Page 35]
RFC 2616 HTTP/1.1 June 1999
5.1.1 Method
The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an
Allow header field (section 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically. An
origin server SHOULD return the status code 405 (Method Not Allowed)
if the method is known by the origin server but not allowed for the
requested resource, and 501 (Not Implemented) if the method is
unrecognized or not implemented by the origin server. The methods GET
and HEAD MUST be supported by all general-purpose servers. All other
methods are OPTIONAL; however, if the above methods are implemented,
they MUST be implemented with the same semantics as those specified
in section 9.
5.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier (section 3.2) and
identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority
The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One
example would be
OPTIONS * HTTP/1.1
The absoluteURI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server
Fielding, et al. Standards Track [Page 36]
RFC 2616 HTTP/1.1 June 1999
specified by the absoluteURI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An example
Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.htmlHTTP/1.1
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
The authority form is only used by the CONNECT method (section 9.9).
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
followed by the remainder of the Request. Note that the absolute path
cannot be empty; if none is present in the original URI, it MUST be
given as "/" (the server root).
The Request-URI is transmitted in the format specified in section
3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
[42], the origin server MUST decode the Request-URI in order to
properly interpret the request. Servers SHOULD respond to invalid
Request-URIs with an appropriate status code.
A transparent proxy MUST NOT rewrite the "abs_path" part of the
received Request-URI when forwarding it to the next inbound server,
except as noted above to replace a null abs_path with "/".
Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI.
Fielding, et al. Standards Track [Page 37]
RFC 2616 HTTP/1.1 June 1999
6 Response
After receiving and interpreting a request message, a server responds
with an HTTP response message.
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
6.1 Status-Line
The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in section 10. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason-
Phrase.
Fielding, et al. Standards Track [Page 39]
RFC 2616 HTTP/1.1 June 1999
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received,
understood, and accepted
- 3xx: Redirection - Further action must be taken in order to
complete the request
- 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
- 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
Fielding, et al. Standards Track [Page 40]
RFC 2616 HTTP/1.1 June 1999
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.
8 Connections
8.1 Persistent Connections
8.1.1 Purpose
Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet. The use of inline images and
other associated data often require a client to make multiple
requests of the same server in a short amount of time. Analysis of
these performance problems and results from a prototype
implementation are available [26] [30]. Implementation experience and
measurements of actual HTTP/1.1 (RFC 2068) implementations show good
results [39]. Alternatives have also been explored, for example,
T/TCP [27].
Persistent HTTP connections have a number of advantages:
- By opening and closing fewer TCP connections, CPU time is saved
in routers and hosts (clients, servers, proxies, gateways,
tunnels, or caches), and memory used for TCP protocol control
blocks can be saved in hosts.
- HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a single TCP connection to
be used much more efficiently, with much lower elapsed time.
- Network congestion is reduced by reducing the number of packets
caused by TCP opens, and by allowing TCP sufficient time to
determine the congestion state of the network.
- Latency on subsequent requests is reduced since there is no time
spent in TCP's connection opening handshake.
- HTTP can evolve more gracefully, since errors can be reported
without the penalty of closing the TCP connection. Clients using
future versions of HTTP might optimistically try a new feature,
but if communicating with an older server, retry with old
semantics after an error is reported.
HTTP implementations SHOULD implement persistent connections.
9 Method Definitions
9.3 GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers
to a data-producing process, it is the produced data which shall be
returned as the entity in the response and not the source text of the
process, unless that text happens to be the output of the process.
The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network
usage by allowing cached entities to be refreshed without requiring
multiple requests or transferring data already held by the client.
The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field. A partial GET requests
that only part of the entity be transferred, as described in section
14.35. The partial GET method is intended to reduce unnecessary
network usage by allowing partially-retrieved entities to be
completed without transferring data already held by the client.
The response to a GET request is cacheable if and only if it meets
the requirements for HTTP caching described in section 13.
See section 15.1.3 for security considerations when used for forms.
Fielding, et al. Standards Track [Page 53]
RFC 2616 HTTP/1.1 June 1999
9.4 HEAD
The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method can
be used for obtaining metainformation about the entity implied by the
request without transferring the entity-body itself. This method is
often used for testing hypertext links for validity, accessibility,
and recent modification.
The response to a HEAD request MAY be cacheable in the sense that the
information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as
stale.
9.5 POST
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
- Annotation of existing resources;
- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
- Providing a block of data, such as the result of submitting a
form, to a data-handling process;
- Extending a database through an append operation.
The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity
is subordinate to that URI in the same way that a file is subordinate
to a directory containing it, a news article is subordinate to a
newsgroup to which it is posted, or a record is subordinate to a
database.
The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result.
Fielding, et al. Standards Track [Page 54]
RFC 2616 HTTP/1.1 June 1999
If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).
Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource.
POST requests MUST obey the message transmission requirements set out
in section 8.2.
See section 15.1.3 for security considerations.
9.6 PUT
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response. If an existing resource is modified,
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
to indicate successful completion of the request. If the resource
could not be created or modified with the Request-URI, an appropriate
error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be
treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
If the server desires that the request be applied to a different URI,
Fielding, et al. Standards Track [Page 55]
RFC 2616 HTTP/1.1 June 1999
it MUST send a 301 (Moved Permanently) response; the user agent MAY
then make its own decision regarding whether or not to redirect the
request.
A single resource MAY be identified by many different URIs. For
example, an article might have a URI for identifying "the current
version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI might result in
several other URIs being defined by the origin server.
HTTP/1.1 does not define how a PUT method affects the state of an
origin server.
PUT requests MUST obey the message transmission requirements set out
in section 8.2.
Unless otherwise specified for a particular entity-header, the
entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT.
9.7 DELETE
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot
be guaranteed that the operation has been carried out, even if the
status code returned from the origin server indicates that the action
has been completed successfully. However, the server SHOULD NOT
indicate success unless, at the time the response is given, it
intends to delete the resource or move it to an inaccessible
location.
A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted) if the action has not
yet been enacted, or 204 (No Content) if the action has been enacted
but the response does not include an entity.
If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be
treated as stale. Responses to this method are not cacheable.
13 Caching in HTTP
13.2 Expiration Model
13.2.1 Server-Specified Expiration
HTTP caching works best when caches can entirely avoid making
requests to the origin server. The primary mechanism for avoiding
requests is for an origin server to provide an explicit expiration
time in the future, indicating that a response MAY be used to satisfy
subsequent requests. In other words, a cache can return a fresh
response without first contacting the server.
Our expectation is that servers will assign future explicit
expiration times to responses in the belief that the entity is not
likely to change, in a semantically significant way, before the
expiration time is reached. This normally preserves semantic
transparency, as long as the server's expiration times are carefully
chosen.
Fielding, et al. Standards Track [Page 79]
RFC 2616 HTTP/1.1 June 1999
The expiration mechanism applies only to responses taken from a cache
and not to first-hand responses forwarded immediately to the
requesting client.
If an origin server wishes to force a semantically transparent cache
to validate every request, it MAY assign an explicit expiration time
in the past. This means that the response is always stale, and so the
cache SHOULD validate it before using it for subsequent requests. See
section 14.9.4 for a more restrictive way to force revalidation.
If an origin server wishes to force any HTTP/1.1 cache, no matter how
it is configured, to validate every request, it SHOULD use the "must-
revalidate" cache-control directive (see section 14.9).
Servers specify explicit expiration times using either the Expires
header, or the max-age directive of the Cache-Control header.
An expiration time cannot be used to force a user agent to refresh
its display or reload a resource; its semantics apply only to caching
mechanisms, and such mechanisms need only check a resource's
expiration status when a new request for that resource is initiated.
See section 13.13 for an explanation of the difference between caches
and history mechanisms.
13.2.2 Heuristic Expiration
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
worst-case constraints on their results. Since heuristic expiration
times might compromise semantic transparency, they ought to used
cautiously, and we encourage origin servers to provide explicit
expiration times as much as possible.
13.2.3 Age Calculations
In order to know if a cached entry is fresh, a cache needs to know if
its age exceeds its freshness lifetime. We discuss how to calculate
the latter in section 13.2.4; this section describes how to calculate
the age of a response or cache entry.
In this discussion, we use the term "now" to mean "the current value
of the clock at the host performing the calculation." Hosts that use
HTTP, but especially hosts running origin servers and caches, SHOULD
use NTP [28] or some similar protocol to synchronize their clocks to
a globally accurate time standard.
Fielding, et al. Standards Track [Page 80]
RFC 2616 HTTP/1.1 June 1999
HTTP/1.1 requires origin servers to send a Date header, if possible,
with every response, giving the time at which the response was
generated (see section 14.18). We use the term "date_value" to denote
the value of the Date header, in a form appropriate for arithmetic
operations.
HTTP/1.1 uses the Age response-header to convey the estimated age of
the response message when obtained from a cache. The Age field value
is the cache's estimate of the amount of time since the response was
generated or revalidated by the origin server.
In essence, the Age value is the sum of the time that the response
has been resident in each of the caches along the path from the
origin server, plus the amount of time it has been in transit along
network paths.
We use the term "age_value" to denote the value of the Age header, in
a form appropriate for arithmetic operations.
A response's age can be calculated in two entirely independent ways:
1. now minus date_value, if the local clock is reasonably well
synchronized to the origin server's clock. If the result is
negative, the result is replaced by zero.
2. age_value, if all of the caches along the response path
implement HTTP/1.1.
Given that we have two independent ways to compute the age of a
response when it is received, we can combine these as
corrected_received_age = max(now - date_value, age_value)
and as long as we have either nearly synchronized clocks or all-
HTTP/1.1 paths, one gets a reliable (conservative) result.
Because of network-imposed delays, some significant interval might
pass between the time that a server generates a response and the time
it is received at the next outbound cache or client. If uncorrected,
this delay could result in improperly low ages.
Because the request that resulted in the returned Age value must have
been initiated prior to that Age value's generation, we can correct
for delays imposed by the network by recording the time at which the
request was initiated. Then, when an Age value is received, it MUST
be interpreted relative to the time the request was initiated, not
Fielding, et al. Standards Track [Page 81]
RFC 2616 HTTP/1.1 June 1999
the time that the response was received. This algorithm results in
conservative behavior no matter how much delay is experienced. So, we
compute:
corrected_initial_age = corrected_received_age
+ (now - request_time)
where "request_time" is the time (according to the local clock) when
the request that elicited this response was sent.
Summary of age calculation algorithm, when a cache receives a
response:
/*
* age_value
* is the value of Age: header received by the cache with
* this response.
* date_value
* is the value of the origin server's Date: header
* request_time
* is the (local) time when the cache made the request
* that resulted in this cached response
* response_time
* is the (local) time when the cache received the
* response
* now
* is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
The current_age of a cache entry is calculated by adding the amount
of time (in seconds) since the cache entry was last validated by the
origin server to the corrected_initial_age. When a response is
generated from a cache entry, the cache MUST include a single Age
header field in the response with a value equal to the cache entry's
current_age.
The presence of an Age header field in a response implies that a
response is not first-hand. However, the converse is not true, since
the lack of an Age header field in a response does not imply that the
Fielding, et al. Standards Track [Page 82]
RFC 2616 HTTP/1.1 June 1999
response is first-hand unless all caches along the request path are
compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
the Age header field).
13.2.4 Expiration Calculations
In order to decide whether a response is fresh or stale, we need to
compare its freshness lifetime to its age. The age is calculated as
described in section 13.2.3; this section describes how to calculate
the freshness lifetime, and to determine if a response has expired.
In the discussion below, the values can be represented in any form
appropriate for arithmetic operations.
We use the term "expires_value" to denote the value of the Expires
header. We use the term "max_age_value" to denote an appropriate
value of the number of seconds carried by the "max-age" directive of
the Cache-Control header in a response (see section 14.9.3).
The max-age directive takes priority over Expires, so if max-age is
present in a response, the calculation is simply:
freshness_lifetime = max_age_value
Otherwise, if Expires is present in the response, the calculation is:
freshness_lifetime = expires_value - date_value
Note that neither of these calculations is vulnerable to clock skew,
since all of the information comes from the origin server.
If none of Expires, Cache-Control: max-age, or Cache-Control: s-
maxage (see section 14.9.3) appears in the response, and the response
does not include other restrictions on caching, the cache MAY compute
a freshness lifetime using a heuristic. The cache MUST attach Warning
113 to any response whose age is more than 24 hours if such warning
has not already been added.
Also, if the response does have a Last-Modified time, the heuristic
expiration value SHOULD be no more than some fraction of the interval
since that time. A typical setting of this fraction might be 10%.
The calculation to determine if a response has expired is quite
simple:
response_is_fresh = (freshness_lifetime > current_age)
Fielding, et al. Standards Track [Page 83]
RFC 2616 HTTP/1.1 June 1999
13.2.5 Disambiguating Expiration Values
Because expiration values are assigned optimistically, it is possible
for two caches to contain fresh values for the same resource that are
different.
If a client performing a retrieval receives a non-first-hand response
for a request that was already fresh in its own cache, and the Date
header in its existing cache entry is newer than the Date on the new
response, then the client MAY ignore the response. If so, it MAY
retry the request with a "Cache-Control: max-age=0" directive (see
section 14.9), to force a check with the origin server.
If a cache has two fresh responses for the same representation with
different validators, it MUST use the one with the more recent Date
header. This situation might arise because the cache is pooling
responses from other caches, or because a client has asked for a
reload or a revalidation of an apparently fresh cache entry.
13.2.6 Disambiguating Multiple Responses
Because a client might be receiving responses via multiple paths, so
that some responses flow through one set of caches and other
responses flow through a different set of caches, a client might
receive responses in an order different from that in which the origin
server sent them. We would like the client to use the most recently
generated response, even if older responses are still apparently
fresh.
Neither the entity tag nor the expiration value can impose an
ordering on responses, since it is possible that a later response
intentionally carries an earlier expiration time. The Date values are
ordered to a granularity of one second.
When a client tries to revalidate a cache entry, and the response it
receives contains a Date header that appears to be older than the one
for the existing entry, then the client SHOULD repeat the request
unconditionally, and include
Cache-Control: max-age=0
to force any intermediate caches to validate their copies directly
with the origin server, or
Cache-Control: no-cache
to force any intermediate caches to obtain a new copy from the origin
server.
Fielding, et al. Standards Track [Page 84]
RFC 2616 HTTP/1.1 June 1999
If the Date values are equal, then the client MAY use either response
(or MAY, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second,
if their expiration times overlap.
14 Header Field Definitions
14.21 Expires
The Expires entity-header field gives the date/time after which the
response is considered stale. A stale cache entry may not normally be
returned by a cache (either a proxy cache or a user agent cache)
unless it is first validated with the origin server (or with an
intermediate cache that has a fresh copy of the entity). See section
13.2 for further discussion of the expiration model.
The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.
The format is an absolute date and time as defined by HTTP-date in
section 3.3.1; it MUST be in RFC 1123 date format:
Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-
age directive (see section 14.9.3), that directive overrides the
Expires field.
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
To mark a response as "already expired," an origin server sends an
Expires date that is equal to the Date header value. (See the rules
for expiration calculations in section 13.2.4.)
Fielding, et al. Standards Track [Page 127]
RFC 2616 HTTP/1.1 June 1999
To mark a response as "never expires," an origin server sends an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.
The presence of an Expires header field with a date value of some
time in the future on a response that otherwise would by default be
non-cacheable indicates that the response is cacheable, unless
indicated otherwise by a Cache-Control header field (section 14.9).
14.23 Host
The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original
URI given by the user or referring resource (generally an HTTP URL,
Fielding, et al. Standards Track [Page 128]
RFC 2616 HTTP/1.1 June 1999
as described in section 3.2.2). The Host field value MUST represent
the naming authority of the origin server or gateway given by the
original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for
<http://www.w3.org/pub/WWW/>would properly include:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header
field.
See sections 5.2 and 19.6.1.1 for other requirements relating to
Host.
14.36 Referer
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Fielding, et al. Standards Track [Page 140]
RFC 2616 HTTP/1.1 June 1999
If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. See
section 15.1.3 for security considerations.
14.43 User-Agent
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3