As per Relevance of the word resource, we have this rfc below:
Network Working Group R.
Request for Comments: 2616 UC
Obsoletes: 2068 J.
Category: Standards Track Compaq/W3
J.
H.
W3C/
L.
P.
T. Berners-
W3C/
June 1999
Hypertext Transfer Protocol -- HTTP/1.1
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The Hypertext Transfer Protocol (HTTP) is an application-
protocol for distributed, collaborative, hypermedia
systems. It is a generic, stateless, protocol which can be used
many tasks beyond its use for hypertext, such as name servers
distributed object management systems, through extension of
request methods, error codes and headers [47]. A feature of HTTP
the typing and negotiation of data representation, allowing
to be built independently of the data being transferred
HTTP has been in use by the World-Wide Web global
initiative since 1990. This specification defines the
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
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
1.1
The Hypertext Transfer Protocol (HTTP) is an application-
protocol for distributed, collaborative, hypermedia
systems. HTTP has been in use by the World-Wide Web
information initiative since 1990. The first version of HTTP
referred to as HTTP/0.9, was a simple protocol for raw data
across the Internet. HTTP/1.0, as defined by RFC 1945 [6],
the protocol by allowing messages to be in the format of MIME-
messages, containing metainformation about the data transferred
modifiers on the request/response semantics. However, HTTP/1.0
not sufficiently take into consideration the effects of
proxies, caching, the need for persistent connections, or
hosts. In addition, the proliferation of incompletely-
applications calling themselves "HTTP/1.0" has necessitated
protocol version change in order for two communicating
to determine each other's true capabilities
This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0
order to ensure reliable implementation of its features
Practical information systems require more functionality than
retrieval, including search, front-end update, and annotation.
allows an open-ended set of methods and headers that indicate
purpose of a request [47]. It builds on the discipline of
provided by the Uniform Resource Identifier (URI) [3], as a
(URL) [4] or name (URN) [20], for indicating the resource to which
Fielding, et al. Standards Track [Page 7]
RFC 2616 HTTP/1.1 June 1999
method is to be applied. Messages are passed in a format similar
that used by Internet mail [9] as defined by the
Internet Mail Extensions (MIME) [7].
HTTP is also used as a generic protocol for communication
user agents and proxies/gateways to other Internet systems,
those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
and WAIS [10] protocols. In this way, HTTP allows basic
access to resources available from diverse applications
1.2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [34].
An implementation is not compliant if it fails to satisfy one or
of the MUST or REQUIRED level requirements for the protocols
implements. An implementation that satisfies all the MUST or
level and all the SHOULD level requirements for its protocols is
to be "unconditionally compliant"; one that satisfies all the
level requirements but not all the SHOULD level requirements for
protocols is said to be "conditionally compliant."
1.3
This specification uses a number of terms to refer to the
played by participants in, and objects of, the HTTP communication
A transport layer virtual circuit established between two
for the purpose of communication
The basic unit of HTTP communication, consisting of a
sequence of octets matching the syntax defined in section 4
transmitted via the connection
An HTTP request message, as defined in section 5.
An HTTP response message, as defined in section 6.
Fielding, et al. Standards Track [Page 8]
RFC 2616 HTTP/1.1 June 1999
A network data object or service that can be identified by a URI
as defined in section 3.2. Resources may be available in
representations (e.g. multiple languages, data formats, size,
resolutions) or vary in other ways
The information transferred as the payload of a request
response. An entity consists of metainformation in the form
entity-header fields and content in the form of an entity-body,
described in section 7.
An entity included with a response that is subject to
negotiation, as described in section 12. There may exist
representations associated with a particular response status
content
The mechanism for selecting the appropriate representation
servicing a request, as described in section 12.
representation of entities in any response can be
(including error responses).
A resource may have one, or more than one, representation(s
associated with it at any given instant. Each of
representations is termed a `varriant'. Use of the term `variant
does not necessarily imply that the resource is subject to
negotiation
A program that establishes connections for the purpose of
requests
user
The client which initiates a request. These are often browsers
editors, spiders (web-traversing robots), or other end user tools
An application program that accepts connections in order
service requests by sending back responses. Any given program
be capable of being both a client and a server; our use of
terms refers only to the role being performed by the program for
particular connection, rather than to the program's
in general. Likewise, any server may act as an origin server
proxy, gateway, or tunnel, switching behavior based on the
of each request
Fielding, et al. Standards Track [Page 9]
RFC 2616 HTTP/1.1 June 1999
origin
The server on which a given resource resides or is to be created
An intermediary program which acts as both a server and a
for the purpose of making requests on behalf of other clients
Requests are serviced internally or by passing them on,
possible translation, to other servers. A proxy MUST
both the client and server requirements of this specification.
"transparent proxy" is a proxy that does not modify the request
response beyond what is required for proxy authentication
identification. A "non-transparent proxy" is a proxy that
the request or response in order to provide some added service
the user agent, such as group annotation services, media
transformation, protocol reduction, or anonymity filtering.
where either transparent or non-transparent behavior is
stated, the HTTP proxy requirements apply to both types
proxies
A server which acts as an intermediary for some other server
Unlike a proxy, a gateway receives requests as if it were
origin server for the requested resource; the requesting
may not be aware that it is communicating with a gateway
An intermediary program which is acting as a blind relay
two connections. Once active, a tunnel is not considered a
to the HTTP communication, though the tunnel may have
initiated by an HTTP request. The tunnel ceases to exist when
ends of the relayed connections are closed
A program's local store of response messages and the
that controls its message storage, retrieval, and deletion.
cache stores cacheable responses in order to reduce the
time and network bandwidth consumption on future,
requests. Any client or server may include a cache, though a
cannot be used by a server that is acting as a tunnel
A response is cacheable if a cache is allowed to store a copy
the response message for use in answering subsequent requests.
rules for determining the cacheability of HTTP responses
defined in section 13. Even if a resource is cacheable, there
be additional constraints on whether a cache can use the
copy for a particular request
Fielding, et al. Standards Track [Page 10]
RFC 2616 HTTP/1.1 June 1999
first-
A response is first-hand if it comes directly and
unnecessary delay from the origin server, perhaps via one or
proxies. A response is also first-hand if its validity has
been checked directly with the origin server
explicit expiration
The time at which the origin server intends that an entity
no longer be returned by a cache without further validation
heuristic expiration
An expiration time assigned by a cache when no explicit
time is available
The age of a response is the time since it was sent by,
successfully validated with, the origin server
freshness
The length of time between the generation of a response and
expiration time
A response is fresh if its age has not yet exceeded its
lifetime
A response is stale if its age has passed its freshness lifetime
semantically
A cache behaves in a "semantically transparent" manner,
respect to a particular response, when its use affects neither
requesting client nor the origin server, except to
performance. When a cache is semantically transparent, the
receives exactly the same response (except for hop-by-hop headers
that it would have received had its request been handled
by the origin server
A protocol element (e.g., an entity tag or a Last-Modified time
that is used to find out whether a cache entry is an
copy of an entity
upstream/
Upstream and downstream describe the flow of a message:
messages flow from upstream to downstream
Fielding, et al. Standards Track [Page 11]
RFC 2616 HTTP/1.1 June 1999
inbound/
Inbound and outbound refer to the request and response paths
messages: "inbound" means "traveling toward the origin server",
and "outbound" means "traveling toward the user agent
1.4 Overall
The HTTP protocol is a request/response protocol. A client sends
request to the server in the form of a request method, URI,
protocol version, followed by a MIME-like message containing
modifiers, client information, and possible body content over
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,
metainformation, and possible entity-body content. The
between HTTP and MIME is described in appendix 19.4.
Most HTTP communication is initiated by a user agent and consists
a request to be applied to a resource on some origin server. In
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-------------------
<----------------------- response
A more complicated situation occurs when one or more
are present in the request/response chain. There are three
forms of intermediary: proxy, gateway, and tunnel. A proxy is
forwarding agent, receiving requests for a URI in its absolute form
rewriting all or part of the message, and forwarding the
request toward the server identified by the URI. A gateway is
receiving agent, acting as a layer above some other server(s) and,
necessary, translating the requests to the underlying server'
protocol. A tunnel acts as a relay point between two
without changing the messages; tunnels are used when
communication needs to pass through an intermediary (such as
firewall) even when the intermediary cannot understand the
of the messages
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v-----
<------------------------------------- response
The figure above shows three intermediaries (A, B, and C) between
user agent and origin server. A request or response message
travels the whole chain will pass through four separate connections
This distinction is important because some HTTP communication
Fielding, et al. Standards Track [Page 12]
RFC 2616 HTTP/1.1 June 1999
may apply only to the connection with the nearest, non-
neighbor, only to the end-points of the chain, or to all
along the chain. Although the diagram is linear, each participant
be engaged in multiple, simultaneous communications. For example,
may be receiving requests from many clients other than A, and/
forwarding requests to servers other than C, at the same time that
is handling A's request
Any party to the communication which is not acting as a tunnel
employ an internal cache for handling requests. The effect of a
is that the request/response chain is shortened if one of
participants along the chain has a cached response applicable to
request. The following illustrates the resulting chain if B has
cached copy of an earlier response from O (via C) for a request
has not been cached by UA or A
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - -
<--------- response
Not all responses are usefully cacheable, and some requests
contain modifiers which place special requirements on cache behavior
HTTP requirements for cache behavior and cacheable responses
defined in section 13.
In fact, there are a wide variety of architectures and
of caches and proxies currently being experimented with or
across the World Wide Web. These systems include national
of proxy caches to save transoceanic bandwidth, systems
broadcast or multicast cache entries, organizations that
subsets of cached data via CD-ROM, and so on. HTTP systems are
in corporate intranets over high-bandwidth links, and for access
PDAs with low-power radio links and intermittent connectivity.
goal of HTTP/1.1 is to support the wide diversity of
already deployed while introducing protocol constructs that meet
needs of those who build web applications that require
reliability and, failing that, at least reliable indications
failure
HTTP communication usually takes place over TCP/IP connections.
default port is TCP 80 [19], but other ports can be used. This
not preclude HTTP from being implemented on top of any other
on the Internet, or on other networks. HTTP only presumes a
transport; any protocol that provides such guarantees can be used
the mapping of the HTTP/1.1 request and response structures onto
transport data units of the protocol in question is outside the
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
request/response exchange. In HTTP/1.1, a connection may be used
one or more request/response exchanges, although connections may
closed for a variety of reasons (see section 8.1).
2 Notational Conventions and Generic
2.1 Augmented
All of the mechanisms specified in this document are described
both prose and an augmented Backus-Naur Form (BNF) similar to
used by RFC 822 [9]. Implementors will need to be familiar with
notation in order to understand this specification. The augmented
includes the following constructs
name =
The name of a rule is simply the name itself (without
enclosing "<" and ">") and is separated from its definition by
equal "=" character. White space is only significant in
indentation of continuation lines is used to indicate a
definition that spans more than one line. Certain basic rules
in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
brackets are used within definitions whenever their presence
facilitate discerning the use of rule names
"literal
Quotation marks surround literal text. Unless stated otherwise
the text is case-insensitive
rule1 | rule
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element
Thus, "(elem (foo | bar) elem)" allows the token sequences "
foo elem" and "elem bar elem".
*
The character "*" preceding an element indicates repetition.
full form is "*element" indicating at least and at
occurrences of element. Default values are 0 and infinity
that "*(element)" allows any number, including zero; "1*element
requires at least one; and "1*2element" allows one or two
[rule
Square brackets enclose optional elements; "[foo bar]"
equivalent to "*1(foo bar)".
Fielding, et al. Standards Track [Page 14]
RFC 2616 HTTP/1.1 June 1999
N
Specific repetition: "(element)" is equivalent
"*(element)"; that is, exactly occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of
alphabetic characters
#
A construct "#" is defined, similar to "*", for defining lists
elements. The full form is "#element" indicating at
and at most elements, each separated by one or more
(",") and OPTIONAL linear white space (LWS). This makes the
form of lists very easy; a rule such
( *LWS element *( *LWS "," *LWS element ))
can be shown
1#
Wherever this construct is used, null elements are allowed, but
not contribute to the count of elements present. That is
"(element), , (element) " is permitted, but counts as only
elements. Therefore, where at least one element is required,
least one non-null element MUST be present. Default values are 0
and infinity so that "#element" allows any number, including zero
"1#element" requires at least one; and "1#2element" allows one
two
;
A semi-colon, set off some distance to the right of rule text
starts a comment that continues to the end of line. This is
simple way of including useful notes in parallel with
specifications
implied *
The grammar described by this specification is word-based.
where noted otherwise, linear white space (LWS) can be
between any two adjacent words (token or quoted-string),
between adjacent words and separators, without changing
interpretation of a field. At least one delimiter (LWS and/
separators) MUST exist between any two tokens (for the
of "token" below), since they would otherwise be interpreted as
single token
2.2 Basic
The following rules are used throughout this specification
describe basic parsing constructs. The US-ASCII coded character
is defined by ANSI X3.4-1986 [21].
Fielding, et al. Standards Track [Page 15]
RFC 2616 HTTP/1.1 June 1999
OCTET = sequence of data
CHAR = character (octets 0 - 127)>
UPALPHA =
LOALPHA =
ALPHA = UPALPHA |
DIGIT =
CTL =
(octets 0 - 31) and DEL (127)>
CR =
LF = linefeed (10)>
SP =
HT = horizontal-tab (9)>
<"> =
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for
protocol elements except the entity-body (see appendix 19.3
tolerant applications). The end-of-line marker within an entity-
is defined by its associated media type, as described in section 3.7.
CRLF = CR
HTTP/1.1 header field values can be folded onto multiple lines if
continuation line begins with a space or horizontal tab. All
white space, including folding, has the same semantics as SP.
recipient MAY replace any linear white space with a single SP
interpreting the field value or forwarding the message downstream
LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and
that are not intended to be interpreted by the message parser.
of *TEXT MAY contain characters from character sets other than ISO
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].
TEXT =
but including LWS
A CRLF is allowed in the definition of TEXT only as part of a
field continuation. It is expected that the folding LWS will
replaced with a single SP before interpretation of the TEXT value
Hexadecimal numeric characters are used in several protocol elements
HEX = "A" | "B" | "C" | "D" | "E" | "F
| "a" | "b" | "c" | "d" | "e" | "f" |
Fielding, et al. Standards Track [Page 16]
RFC 2616 HTTP/1.1 June 1999
Many HTTP/1.1 header field values consist of words separated by
or special characters. These special characters MUST be in a
string to be used within a parameter value (as defined in
3.6).
token = 1*
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP |
Comments can be included in some HTTP header fields by
the comment text with parentheses. Comments are only allowed
fields containing "comment" as part of their field value definition
In all other fields, parentheses are considered part of the
value
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext =
A string of text is parsed as a single word if it is quoted
double-quote marks
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = >
The backslash character ("\") MAY be used as a single-
quoting mechanism only within quoted-string and comment constructs
quoted-pair = "\"
3 Protocol
3.1 HTTP
HTTP uses a "." numbering scheme to indicate
of the protocol. The protocol versioning policy is intended to
the sender to indicate the format of a message and its capacity
understanding further HTTP communication, rather than the
obtained via that communication. No change is made to the
number for the addition of message components which do not
communication behavior or which only add to extensible field values
The number is incremented when the changes made to
protocol add features which do not change the general message
algorithm, but which may add to the message semantics and
additional capabilities of the sender. The number
incremented when the format of a message within the protocol
changed. See RFC 2145 [36] for a fuller explanation
Fielding, et al. Standards Track [Page 17]
RFC 2616 HTTP/1.1 June 1999
The version of an HTTP message is indicated by an HTTP-Version
in the first line of the message
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*
Note that the major and minor numbers MUST be treated as
integers and that each MAY be incremented higher than a single digit
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
MUST NOT be sent
An application that sends a request or response message that
HTTP-Version of "HTTP/1.1" MUST be at least conditionally
with this specification. Applications that are at least
compliant with this specification SHOULD use an HTTP-Version
"HTTP/1.1" in their messages, and MUST do so for any message that
not compatible with HTTP/1.0. For more details on when to
specific HTTP-Version values, see RFC 2145 [36].
The HTTP version of an application is the highest HTTP version
which the application is at least conditionally compliant
Proxy and gateway applications need to be careful when
messages in protocol versions different from that of the application
Since the protocol version indicates the protocol capability of
sender, a proxy/gateway MUST NOT send a message with a
indicator which is greater than its actual version. If a
version request is received, the proxy/gateway MUST either
the request version, or respond with an error, or switch to
behavior
Due to interoperability problems with HTTP/1.0 proxies
since the publication of RFC 2068[33], caching proxies MUST,
MAY, and tunnels MUST NOT upgrade the request to the highest
they support. The proxy/gateway's response to that request MUST be
the same major version as the request
Note: Converting between versions of HTTP may involve
of header fields required or forbidden by the versions involved
3.2 Uniform Resource
URIs have been known by many names: WWW addresses, Universal
Identifiers, Universal Resource Identifiers [3], and finally
combination of Uniform Resource Locators (URL) [4] and Names (URN
[20]. As far as HTTP is concerned, Uniform Resource Identifiers
simply formatted strings which identify--via name, location, or
other characteristic--a resource
Fielding, et al. Standards Track [Page 18]
RFC 2616 HTTP/1.1 June 1999
3.2.1 General
URIs in HTTP can be represented in absolute form or relative to
known base URI [11], depending upon the context of their use. The
forms are differentiated by the fact that absolute URIs always
with a scheme name followed by a colon. For definitive information
URL syntax and semantics, see "Uniform Resource Identifiers (URI):
Generic Syntax and Semantics," RFC 2396 [42] (which replaces
1738 [4] and RFC 1808 [11]). This specification adopts
definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"host","abs_path", "rel_path", and "authority" from
specification
The HTTP protocol does not place any a priori limit on the length
a URI. Servers MUST be able to handle the URI of any resource
serve, and SHOULD be able to handle URIs of unbounded length if
provide GET-based forms that could generate such URIs. A
SHOULD return 414 (Request-URI Too Long) status if a URI is
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI
above 255 bytes, because some older client or
implementations might not properly support these lengths
3.2.2 http
The "http" scheme is used to locate network resources via the
protocol. This section defines the scheme-specific syntax
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
are that the identified resource is located at the server
for TCP connections on that port of that host, and the Request-
for the resource is abs_path (section 5.1.2). The use of IP
in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]).
the abs_path is not present in the URL, it MUST be given as "/"
used as a Request-URI for a resource (section 5.1.2). If a
receives a host name which is not a fully qualified domain name,
MAY add its domain to the host name it received. If a proxy
a fully qualified domain name, the proxy MUST NOT change the
name
Fielding, et al. Standards Track [Page 19]
RFC 2616 HTTP/1.1 June 1999
3.2.3 URI
When comparing two URIs to decide if they match or not, a
SHOULD use a case-sensitive octet-by-octet comparison of the
URIs, with these exceptions
- A port that is empty or not given is equivalent to the
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 (
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding
For example, the following three URIs are equivalent
http://abc.com:80/~smith/home.
http://ABC.com/%7Esmith/home.
http://ABC.com:/%7esmith/home.
3.3 Date/Time
3.3.1 Full
HTTP applications have historically allowed three different
for the representation of date/time stamps
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime()
The first format is preferred as an Internet standard and
a fixed-length subset of that defined by RFC 1123 [8] (an update
RFC 822 [9]). The second format is in common use, but is based on
obsolete RFC 850 [12] date format and lacks a four-digit year
HTTP/1.1 clients and servers that parse the date value MUST
all three formats (for compatibility with HTTP/1.0), though they
only generate the RFC 1123 format for representing HTTP-date
in header fields. See section 19.3 for further information
Note: Recipients of date values are encouraged to be robust
accepting date values that may have been sent by non-
applications, as is sometimes the case when retrieving or
messages via proxies/gateways to SMTP or NNTP
Fielding, et al. Standards Track [Page 20]
RFC 2616 HTTP/1.1 June 1999
All HTTP date/time stamps MUST be represented in Greenwich Mean
(GMT), without exception. For the purposes of HTTP, GMT is
equal to UTC (Coordinated Universal Time). This is indicated in
first two formats by the inclusion of "GMT" as the three-
abbreviation for time zone, and MUST be assumed when reading
asctime format. HTTP-date is case sensitive and MUST NOT
additional LWS beyond that specifically included as SP in
grammar
HTTP-date = rfc1123-date | rfc850-date | asctime-
rfc1123-date = wkday "," SP date1 SP time SP "GMT
rfc850-date = weekday "," SP date2 SP time SP "GMT
asctime-date = wkday SP date3 SP time SP 4
date1 = 2DIGIT SP month SP 4
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed
| "Thu" | "Fri" | "Sat" | "Sun
weekday = "Monday" | "Tuesday" | "Wednesday
| "Thursday" | "Friday" | "Saturday" | "Sunday
month = "Jan" | "Feb" | "Mar" | "Apr
| "May" | "Jun" | "Jul" | "Aug
| "Sep" | "Oct" | "Nov" | "Dec
Note: HTTP requirements for the date/time stamp format apply
to their usage within the protocol stream. Clients and servers
not required to use these formats for user presentation,
logging, etc
3.3.2 Delta
Some HTTP header fields allow a time value to be specified as
integer number of seconds, represented in decimal, after the
that the message was received
delta-seconds = 1*
3.4 Character
HTTP uses the same definition of the term "character set" as
described for MIME
Fielding, et al. Standards Track [Page 21]
RFC 2616 HTTP/1.1 June 1999
The term "character set" is used in this document to refer to
method used with one or more tables to convert a sequence of
into a sequence of characters. Note that unconditional conversion
the other direction is not required, in that not all characters
be available in a given character set and a character set may
more than one sequence of octets to represent a particular character
This definition is intended to allow various kinds of
encoding, from simple single-table mappings such as US-ASCII
complex table switching methods such as those that use ISO-2022'
techniques. However, the definition associated with a MIME
set name MUST fully specify the mapping to be performed from
to characters. In particular, use of external profiling
to determine the exact mapping is not permitted
Note: This use of the term "character set" is more
referred to as a "character encoding." However, since HTTP
MIME share the same registry, it is important that the
also be shared
HTTP character sets are identified by case-insensitive tokens.
complete set of tokens is defined by the IANA Character Set
[19].
charset =
Although HTTP allows an arbitrary token to be used as a
value, any token that has a predefined value within the
Character Set registry [19] MUST represent the character set
by that registry. Applications SHOULD limit their use of
sets to those defined by the IANA registry
Implementors should be aware of IETF character set requirements [38]
[41].
3.4.1 Missing
Some HTTP/1.0 software has interpreted a Content-Type header
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a
parameter even when the charset is ISO-8859-1 and SHOULD do so
it is known that it will not confuse the recipient
Unfortunately, some older HTTP/1.0 clients did not deal properly
an explicit charset parameter. HTTP/1.1 recipients MUST respect
charset label provided by the sender; and those user agents that
a provision to "guess" a charset MUST use the charset from
Fielding, et al. Standards Track [Page 22]
RFC 2616 HTTP/1.1 June 1999
content-type field if they support that charset, rather than
recipient's preference, when initially displaying a document.
section 3.7.1.
3.5 Content
Content coding values indicate an encoding transformation that
been or can be applied to an entity. Content codings are
used to allow a document to be compressed or otherwise
transformed without losing the identity of its underlying media
and without loss of information. Frequently, the entity is stored
coded form, transmitted directly, and only decoded by the recipient
content-coding =
All content-coding values are case-insensitive. HTTP/1.1
content-coding values in the Accept-Encoding (section 14.3)
Content-Encoding (section 14.11) header fields. Although the
describes the content-coding, what is more important is that
indicates what decoding mechanism will be required to remove
encoding
The Internet Assigned Numbers Authority (IANA) acts as a registry
content-coding value tokens. Initially, the registry contains
following tokens
gzip An encoding format produced by the file compression
"gzip" (GNU zip) as described in RFC 1952 [25]. This format is
Lempel-Ziv coding (LZ77) with a 32 bit CRC
The encoding format produced by the common UNIX file
program "compress". This format is an adaptive Lempel-Ziv-
coding (LZW).
Use of program names for the identification of encoding
is not desirable and is discouraged for future encodings.
use here is representative of historical practice, not
design. For compatibility with previous implementations of HTTP
applications SHOULD consider "x-gzip" and "x-compress" to
equivalent to "gzip" and "compress" respectively
The "zlib" format defined in RFC 1950 [31] in combination
the "deflate" compression mechanism described in RFC 1951 [29].
Fielding, et al. Standards Track [Page 23]
RFC 2616 HTTP/1.1 June 1999
The default (identity) encoding; the use of no
whatsoever. This content-coding is used only in the Accept
Encoding header, and SHOULD NOT be used in the Content-
header
New content-coding value tokens SHOULD be registered; to
interoperability between clients and servers, specifications of
content coding algorithms needed to implement a new value SHOULD
publicly available and adequate for independent implementation,
conform to the purpose of content coding defined in this section
3.6 Transfer
Transfer-coding values are used to indicate an
transformation that has been, can be, or may need to be applied to
entity-body in order to ensure "safe transport" through the network
This differs from a content coding in that the transfer-coding is
property of the message, not of the original entity
transfer-coding = "chunked" | transfer-
transfer-extension = token *( ";" parameter )
Parameters are in the form of attribute/value pairs
parameter = attribute "="
attribute =
value = token | quoted-
All transfer-coding values are case-insensitive. HTTP/1.1
transfer-coding values in the TE header field (section 14.39) and
the Transfer-Encoding header field (section 14.41).
Whenever a transfer-coding is applied to a message-body, the set
transfer-codings MUST include "chunked", unless the message
terminated by closing the connection. When the "chunked" transfer
coding is used, it MUST be the last transfer-coding applied to
message-body. The "chunked" transfer-coding MUST NOT be applied
than once to a message-body. These rules allow the recipient
determine the transfer-length of the message (section 4.4).
Transfer-codings are analogous to the Content-Transfer-
values of MIME [7], which were designed to enable safe transport
binary data over a 7-bit transport service. However, safe
has a different focus for an 8bit-clean transfer protocol. In HTTP
the only unsafe characteristic of message-bodies is the difficulty
determining the exact body length (section 7.2.2), or the desire
encrypt data over a shared transport
Fielding, et al. Standards Track [Page 24]
RFC 2616 HTTP/1.1 June 1999
The Internet Assigned Numbers Authority (IANA) acts as a registry
transfer-coding value tokens. Initially, the registry contains
following tokens: "chunked" (section 3.6.1), "identity" (
3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate
(section 3.5).
New transfer-coding value tokens SHOULD be registered in the same
as new content-coding value tokens (section 3.5).
A server which receives an entity-body with a transfer-coding it
not understand SHOULD return 501 (Unimplemented), and close
connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client
3.6.1 Chunked Transfer
The chunked encoding modifies the body of a message in order
transfer it as a series of chunks, each with its own size indicator
followed by an OPTIONAL trailer containing entity-header fields.
allows dynamically produced content to be transferred along with
information necessary for the recipient to verify that it
received the full message
Chunked-Body = *
last-
chunk = chunk-size [ chunk-extension ]
chunk-data
chunk-size = 1*
last-chunk = 1*("0") [ chunk-extension ]
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name =
chunk-ext-val = token | quoted-
chunk-data = chunk-size(OCTET
trailer = *(entity-header CRLF
The chunk-size field is a string of hex digits indicating the size
the chunk. The chunked encoding is ended by any chunk whose size
zero, followed by the trailer, which is terminated by an empty line
The trailer allows the sender to include additional HTTP
fields at the end of the message. The Trailer header field can
used to indicate which header fields are included in a trailer (
section 14.40).
Fielding, et al. Standards Track [Page 25]
RFC 2616 HTTP/1.1 June 1999
A server using chunked transfer-coding in a response MUST NOT use
trailer for any header fields unless at least one of the following
true
a)the request included a TE header field that indicates "trailers"
acceptable in the transfer-coding of the response, as described
section 14.39; or
b)the server is the origin server for the response, the
fields consist entirely of optional metadata, and the
could use the message (in a manner acceptable to the origin server
without receiving this metadata. In other words, the origin
is willing to accept the possibility that the trailer fields
be silently discarded along the path to the client
This requirement prevents an interoperability failure when
message is being received by an HTTP/1.1 (or later) proxy
forwarded to an HTTP/1.0 recipient. It avoids a situation
compliance with the protocol would have necessitated a
infinite buffer on the proxy
An example process for decoding a Chunked-Body is presented
appendix 19.4.6.
All HTTP/1.1 applications MUST be able to receive and decode
"chunked" transfer-coding, and MUST ignore chunk-extension
they do not understand
3.7 Media
HTTP uses Internet Media Types [17] in the Content-Type (
14.17) and Accept (section 14.1) header fields in order to
open and extensible data typing and type negotiation
media-type = type "/" subtype *( ";" parameter )
type =
subtype =
Parameters MAY follow the type/subtype in the form of attribute/
pairs (as defined in section 3.6).
The type, subtype, and parameter attribute names are case
insensitive. Parameter values might or might not be case-sensitive
depending on the semantics of the parameter name. Linear white
(LWS) MUST NOT be used between the type and subtype, nor between
attribute and its value. The presence or absence of a parameter
be significant to the processing of a media-type, depending on
definition within the media type registry
Fielding, et al. Standards Track [Page 26]
RFC 2616 HTTP/1.1 June 1999
Note that some older HTTP applications do not recognize media
parameters. When sending data to older HTTP applications
implementations SHOULD only use media type parameters when they
required by that type/subtype definition
Media-type values are registered with the Internet Assigned
Authority (IANA [19]). The media type registration process
outlined in RFC 1590 [17]. Use of non-registered media types
discouraged
3.7.1 Canonicalization and Text
Internet media types are registered with a canonical form.
entity-body transferred via HTTP messages MUST be represented in
appropriate canonical form prior to its transmission except
"text" types, as defined in the next paragraph
When in canonical form, media subtypes of the "text" type use CRLF
the text line break. HTTP relaxes this requirement and allows
transport of text media with plain CR or LF alone representing a
break when it is done consistently for an entire entity-body.
applications MUST accept CRLF, bare CR, and bare LF as
representative of a line break in text media received via HTTP.
addition, if the text is represented in a character set that does
use octets 13 and 10 for CR and LF respectively, as is the case
some multi-byte character sets, HTTP allows the use of whatever
sequences are defined by that character set to represent
equivalent of CR and LF for line breaks. This flexibility
line breaks applies only to text media in the entity-body; a bare
or LF MUST NOT be substituted for CRLF within any of the HTTP
structures (such as header fields and multipart boundaries).
If an entity-body is encoded with a content-coding, the
data MUST be in a form defined above prior to being encoded
The "charset" parameter is used with some media types to define
character set (section 3.4) of the data. When no explicit
parameter is provided by the sender, media subtypes of the "text
type are defined to have a default charset value of "ISO-8859-1"
received via HTTP. Data in character sets other than "ISO-8859-1"
its subsets MUST be labeled with an appropriate charset value.
section 3.4.1 for compatibility problems
3.7.2 Multipart
MIME provides for a number of "multipart" types -- encapsulations
one or more entities within a single message-body. All
types share a common syntax, as defined in section 5.1.1 of RFC 2046
Fielding, et al. Standards Track [Page 27]
RFC 2616 HTTP/1.1 June 1999
[40], and MUST include a boundary parameter as part of the media
value. The message body is itself a protocol element and
therefore use only CRLF to represent line breaks between body-parts
Unlike in RFC 2046, the epilogue of any multipart message MUST
empty; HTTP applications MUST NOT transmit the epilogue (even if
original multipart contains an epilogue). These restrictions exist
order to preserve the self-delimiting nature of a multipart message
body, wherein the "end" of the message-body is indicated by
ending multipart boundary
In general, HTTP treats a multipart message-body no differently
any other media type: strictly as payload. The one exception is
"multipart/byteranges" type (appendix 19.2) when it appears in a 206
(Partial Content) response, which will be interpreted by some
caching mechanisms as described in sections 13.5.4 and 14.16. In
other cases, an HTTP user agent SHOULD follow the same or
behavior as a MIME user agent would upon receipt of a multipart type
The MIME header fields within each body-part of a multipart message
body do not have any significance to HTTP beyond that defined
their MIME semantics
In general, an HTTP user agent SHOULD follow the same or
behavior as a MIME user agent would upon receipt of a 