As per Relevance of the word resource, we have this rfc below:
Network Working Group R.
Request for Comments: 2068 UC
Category: Standards Track J.
J.
H.
T. Berners-
MIT/
January 1997
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
The Hypertext Transfer Protocol (HTTP) is an application-
protocol for distributed, collaborative, hypermedia
systems. It is a generic, stateless, object-oriented protocol
can be used for many tasks, such as name servers and
object management systems, through extension of its request methods
A feature of HTTP is the typing and negotiation of
representation, allowing systems to be built independently of
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".
Table of
1 Introduction.............................................7
1.1 Purpose ..............................................7
1.2 Requirements .........................................7
1.3 Terminology ..........................................8
1.4 Overall Operation ...................................11
2 Notational Conventions and Generic Grammar..............13
2.1 Augmented BNF .......................................13
2.2 Basic Rules .........................................15
3 Protocol Parameters.....................................17
3.1 HTTP Version ........................................17
Fielding, et. al. Standards Track [Page 1]
RFC 2068 HTTP/1.1 January 1997
3.2 Uniform Resource Identifiers ........................18
3.2.1 General Syntax ...................................18
3.2.2 http URL .........................................19
3.2.3 URI Comparison ...................................20
3.3 Date/Time Formats ...................................21
3.3.1 Full Date ........................................21
3.3.2 Delta Seconds ....................................22
3.4 Character Sets ......................................22
3.5 Content Codings .....................................23
3.6 Transfer Codings ....................................24
3.7 Media Types .........................................25
3.7.1 Canonicalization and Text Defaults ...............26
3.7.2 Multipart Types ..................................27
3.8 Product Tokens ......................................28
3.9 Quality Values ......................................28
3.10 Language Tags ......................................28
3.11 Entity Tags ........................................29
3.12 Range Units ........................................30
4 HTTP Message............................................30
4.1 Message Types .......................................30
4.2 Message Headers .....................................31
4.3 Message Body ........................................32
4.4 Message Length ......................................32
4.5 General Header Fields ...............................34
5 Request.................................................34
5.1 Request-Line ........................................34
5.1.1 Method ...........................................35
5.1.2 Request-URI ......................................35
5.2 The Resource Identified by a Request ................37
5.3 Request Header Fields ...............................37
6 Response................................................38
6.1 Status-Line .........................................38
6.1.1 Status Code and Reason Phrase ....................39
6.2 Response Header Fields ..............................41
7 Entity..................................................41
7.1 Entity Header Fields ................................41
7.2 Entity Body .........................................42
7.2.1 Type .............................................42
7.2.2 Length ...........................................43
8 Connections.............................................43
8.1 Persistent Connections ..............................43
8.1.1 Purpose ..........................................43
8.1.2 Overall Operation ................................44
8.1.3 Proxy Servers ....................................45
8.1.4 Practical Considerations .........................45
8.2 Message Transmission Requirements ...................46
9 Method Definitions......................................48
9.1 Safe and Idempotent Methods .........................48
Fielding, et. al. Standards Track [Page 2]
RFC 2068 HTTP/1.1 January 1997
9.1.1 Safe Methods .....................................48
9.1.2 Idempotent Methods ...............................49
9.2 OPTIONS .............................................49
9.3 GET .................................................50
9.4 HEAD ................................................50
9.5 POST ................................................51
9.6 PUT .................................................52
9.7 DELETE ..............................................53
9.8 TRACE ...............................................53
10 Status Code Definitions................................53
10.1 Informational 1xx ..................................54
10.1.1 100 Continue ....................................54
10.1.2 101 Switching Protocols .........................54
10.2 Successful 2xx .....................................54
10.2.1 200 OK ..........................................54
10.2.2 201 Created .....................................55
10.2.3 202 Accepted ....................................55
10.2.4 203 Non-Authoritative Information ...............55
10.2.5 204 No Content ..................................55
10.2.6 205 Reset Content ...............................56
10.2.7 206 Partial Content .............................56
10.3 Redirection 3xx ....................................56
10.3.1 300 Multiple Choices ............................57
10.3.2 301 Moved Permanently ...........................57
10.3.3 302 Moved Temporarily ...........................58
10.3.4 303 See Other ...................................58
10.3.5 304 Not Modified ................................58
10.3.6 305 Use Proxy ...................................59
10.4 Client Error 4xx ...................................59
10.4.1 400 Bad Request .................................60
10.4.2 401 Unauthorized ................................60
10.4.3 402 Payment Required ............................60
10.4.4 403 Forbidden ...................................60
10.4.5 404 Not Found ...................................60
10.4.6 405 Method Not Allowed ..........................61
10.4.7 406 Not Acceptable ..............................61
10.4.8 407 Proxy Authentication Required ...............61
10.4.9 408 Request Timeout .............................62
10.4.10 409 Conflict ...................................62
10.4.11 410 Gone .......................................62
10.4.12 411 Length Required ............................63
10.4.13 412 Precondition Failed ........................63
10.4.14 413 Request Entity Too Large ...................63
10.4.15 414 Request-URI Too Long .......................63
10.4.16 415 Unsupported Media Type .....................63
10.5 Server Error 5xx ...................................64
10.5.1 500 Internal Server Error .......................64
10.5.2 501 Not Implemented .............................64
Fielding, et. al. Standards Track [Page 3]
RFC 2068 HTTP/1.1 January 1997
10.5.3 502 Bad Gateway .................................64
10.5.4 503 Service Unavailable .........................64
10.5.5 504 Gateway Timeout .............................64
10.5.6 505 HTTP Version Not Supported ..................65
11 Access Authentication..................................65
11.1 Basic Authentication Scheme ........................66
11.2 Digest Authentication Scheme .......................67
12 Content Negotiation....................................67
12.1 Server-driven Negotiation ..........................68
12.2 Agent-driven Negotiation ...........................69
12.3 Transparent Negotiation ............................70
13 Caching in HTTP........................................70
13.1.1 Cache Correctness ...............................72
13.1.2 Warnings ........................................73
13.1.3 Cache-control Mechanisms ........................74
13.1.4 Explicit User Agent Warnings ....................74
13.1.5 Exceptions to the Rules and Warnings ............75
13.1.6 Client-controlled Behavior ......................75
13.2 Expiration Model ...................................75
13.2.1 Server-Specified Expiration .....................75
13.2.2 Heuristic Expiration ............................76
13.2.3 Age Calculations ................................77
13.2.4 Expiration Calculations .........................79
13.2.5 Disambiguating Expiration Values ................80
13.2.6 Disambiguating Multiple Responses ...............80
13.3 Validation Model ...................................81
13.3.1 Last-modified Dates .............................82
13.3.2 Entity Tag Cache Validators .....................82
13.3.3 Weak and Strong Validators ......................82
13.3.4 Rules for When to Use Entity Tags and Last
modified Dates..........................................85
13.3.5 Non-validating Conditionals .....................86
13.4 Response Cachability ...............................86
13.5 Constructing Responses From Caches .................87
13.5.1 End-to-end and Hop-by-hop Headers ...............88
13.5.2 Non-modifiable Headers ..........................88
13.5.3 Combining Headers ...............................89
13.5.4 Combining Byte Ranges ...........................90
13.6 Caching Negotiated Responses .......................90
13.7 Shared and Non-Shared Caches .......................91
13.8 Errors or Incomplete Response Cache Behavior .......91
13.9 Side Effects of GET and HEAD .......................92
13.10 Invalidation After Updates or Deletions ...........92
13.11 Write-Through Mandatory ...........................93
13.12 Cache Replacement .................................93
13.13 History Lists .....................................93
14 Header Field Definitions...............................94
14.1 Accept .............................................95
Fielding, et. al. Standards Track [Page 4]
RFC 2068 HTTP/1.1 January 1997
14.2 Accept-Charset .....................................97
14.3 Accept-Encoding ....................................97
14.4 Accept-Language ....................................98
14.5 Accept-Ranges ......................................99
14.6 Age ................................................99
14.7 Allow .............................................100
14.8 Authorization .....................................100
14.9 Cache-Control .....................................101
14.9.1 What is Cachable ...............................103
14.9.2 What May be Stored by Caches ...................103
14.9.3 Modifications of the Basic Expiration Mechanism 104
14.9.4 Cache Revalidation and Reload Controls .........105
14.9.5 No-Transform Directive .........................107
14.9.6 Cache Control Extensions .......................108
14.10 Connection .......................................109
14.11 Content-Base .....................................109
14.12 Content-Encoding .................................110
14.13 Content-Language .................................110
14.14 Content-Length ...................................111
14.15 Content-Location .................................112
14.16 Content-MD5 ......................................113
14.17 Content-Range ....................................114
14.18 Content-Type .....................................116
14.19 Date .............................................116
14.20 ETag .............................................117
14.21 Expires ..........................................117
14.22 From .............................................118
14.23 Host .............................................119
14.24 If-Modified-Since ................................119
14.25 If-Match .........................................121
14.26 If-None-Match ....................................122
14.27 If-Range .........................................123
14.28 If-Unmodified-Since ..............................124
14.29 Last-Modified ....................................124
14.30 Location .........................................125
14.31 Max-Forwards .....................................125
14.32 Pragma ...........................................126
14.33 Proxy-Authenticate ...............................127
14.34 Proxy-Authorization ..............................127
14.35 Public ...........................................127
14.36 Range ............................................128
14.36.1 Byte Ranges ...................................128
14.36.2 Range Retrieval Requests ......................130
14.37 Referer ..........................................131
14.38 Retry-After ......................................131
14.39 Server ...........................................132
14.40 Transfer-Encoding ................................132
14.41 Upgrade ..........................................132
Fielding, et. al. Standards Track [Page 5]
RFC 2068 HTTP/1.1 January 1997
14.42 User-Agent .......................................134
14.43 Vary .............................................134
14.44 Via ..............................................135
14.45 Warning ..........................................137
14.46 WWW-Authenticate .................................139
15 Security Considerations...............................139
15.1 Authentication of Clients .........................139
15.2 Offering a Choice of Authentication Schemes .......140
15.3 Abuse of Server Log Information ...................141
15.4 Transfer of Sensitive Information .................141
15.5 Attacks Based On File and Path Names ..............142
15.6 Personal Information ..............................143
15.7 Privacy Issues Connected to Accept Headers ........143
15.8 DNS Spoofing ......................................144
15.9 Location Headers and Spoofing .....................144
16 Acknowledgments.......................................144
17 References............................................146
18 Authors' Addresses....................................149
19 Appendices............................................150
19.1 Internet Media Type message/http ..................150
19.2 Internet Media Type multipart/byteranges ..........150
19.3 Tolerant Applications .............................151
19.4 Differences Between HTTP Entities
MIME Entities...........................................152
19.4.1 Conversion to Canonical Form ...................152
19.4.2 Conversion of Date Formats .....................153
19.4.3 Introduction of Content-Encoding ...............153
19.4.4 No Content-Transfer-Encoding ...................153
19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
19.4.6 Introduction of Transfer-Encoding ..............154
19.4.7 MIME-Version ...................................154
19.5 Changes from HTTP/1.0 .............................154
19.5.1 Changes to Simplify Multi-homed Web Servers
Conserve IP Addresses .................................155
19.6 Additional Features ...............................156
19.6.1 Additional Request Methods .....................156
19.6.2 Additional Header Field Definitions ............156
19.7 Compatibility with Previous Versions ..............160
19.7.1 Compatibility with HTTP/1.0
Connections............................................161
Fielding, et. al. Standards Track [Page 6]
RFC 2068 HTTP/1.1 January 1997
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, and
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 that indicate the purpose of
request. It builds on the discipline of reference provided by
Uniform Resource Identifier (URI) [3][20], as a location (URL) [4]
name (URN) , for indicating the resource to which a method is to
applied. Messages are passed in a format similar to that used
Internet mail as defined by the Multipurpose Internet Mail
(MIME).
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
This specification uses the same words as RFC 1123 [8] for
the significance of each particular requirement. These words are
This word or the adjective "required" means that the item is
absolute requirement of the specification
Fielding, et. al. Standards Track [Page 7]
RFC 2068 HTTP/1.1 January 1997
This word or the adjective "recommended" means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and the
carefully weighed before choosing a different course
This word or the adjective "optional" means that this item
truly optional. One vendor may choose to include the item
a particular marketplace requires it or because it enhances
product, for example; another vendor may omit the same item
An implementation is not compliant if it fails to satisfy one or
of the MUST requirements for the protocols it implements.
implementation that satisfies all the MUST and all the
requirements for its protocols is said to be "
compliant"; one that satisfies all the MUST requirements but not
the SHOULD requirements for its protocols is said to
"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.
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
Fielding, et. al. Standards Track [Page 8]
RFC 2068 HTTP/1.1 January 1997
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 `variant.' 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
origin
The server on which a given resource resides or is to be created
Fielding, et. al. Standards Track [Page 9]
RFC 2068 HTTP/1.1 January 1997
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
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 cachable 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 cachable if a cache is allowed to store a copy
the response message for use in answering subsequent requests.
rules for determining the cachability of HTTP responses
defined in section 13. Even if a resource is cachable, there
be additional constraints on whether a cache can use the
copy for a particular request
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
Fielding, et. al. Standards Track [Page 10]
RFC 2068 HTTP/1.1 January 1997
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
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.
Fielding, et. al. Standards Track [Page 11]
RFC 2068 HTTP/1.1 January 1997
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
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
may be engaged in multiple, simultaneous communications. For example
B 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
Fielding, et. al. Standards Track [Page 12]
RFC 2068 HTTP/1.1 January 1997
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - -
<--------- response
Not all responses are usefully cachable, and some requests
contain modifiers which place special requirements on cache behavior
HTTP requirements for cache behavior and cachable 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, but other ports can be used. This does
preclude HTTP from being implemented on top of any other protocol
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
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]. Implementers will need to be familiar with
notation in order to understand this specification. The augmented
includes the following constructs
Fielding, et. al. Standards Track [Page 13]
RFC 2068 HTTP/1.1 January 1997
name =
The name of a rule is simply the name itself (without any
"<" and ">") and is separated from its definition by the equal "="
character. Whitespace is only significant in that indentation
continuation lines is used to indicate a rule definition that
more than one line. Certain basic rules are in uppercase, such
SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are
within definitions whenever their presence will
discerning the use of rule names
"literal
Quotation marks surround literal text. Unless stated otherwise,
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)".
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 whitespace (LWS). This makes the
form of lists very easy; a rule such as "( *LWS element *( *LWS ","
*LWS element )) " can be shown as "1#element". Wherever
construct is used, null elements are allowed, but do not
Fielding, et. al. Standards Track [Page 14]
RFC 2068 HTTP/1.1 January 1997
to the count of elements present. That is, "(element), , (element
" is permitted, but counts as only two elements. Therefore,
at least one element is required, at least one non-null
must be present. Default values are 0 and infinity so
"#element" allows any number, including zero; "1#element"
at least one; and "1#2element" allows one or 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 whitespace (LWS) can be
between any two adjacent words (token or quoted-string),
between adjacent tokens and delimiters (tspecials),
changing the interpretation of a field. At least one
(tspecials) must exist between any two tokens, since they
otherwise be interpreted as a 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].
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)>
<"> =
Fielding, et. al. Standards Track [Page 15]
RFC 2068 HTTP/1.1 January 1997
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 headers 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
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
8859-1 [22] only when encoded according to the rules of RFC 1522
[14].
TEXT =
but including LWS
Hexadecimal numeric characters are used in several protocol elements
HEX = "A" | "B" | "C" | "D" | "E" | "F
| "a" | "b" | "c" | "d" | "e" | "f" |
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
token = 1*
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | 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 | comment ) ")"
ctext =
Fielding, et. al. Standards Track [Page 16]
RFC 2068 HTTP/1.1 January 1997
A string of text is parsed as a single word if it is quoted
double-quote marks
quoted-string = ( <"> *(qdtext) <"> )
qdtext = >
The backslash character ("\") may be used as a single-character
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
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
Applications sending Request or Response messages, as defined by
specification, MUST include an HTTP-Version of "HTTP/1.1". Use
this version number indicates that the sending application is
least conditionally compliant with this specification
The HTTP version of an application is the highest HTTP version
which the application is at least conditionally compliant
Fielding, et. al. Standards Track [Page 17]
RFC 2068 HTTP/1.1 January 1997
Proxy and gateway applications must 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 never 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, respond with an error, or switch to
behavior. Requests with a version lower than that of
proxy/gateway's version MAY be upgraded before being forwarded;
proxy/gateway's response to that request MUST be in the same
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 , and finally
combination of Uniform Resource Locators (URL) and Names (URN).
far as HTTP is concerned, Uniform Resource Identifiers are
formatted strings which identify--via name, location, or any
characteristic--a resource
3.2.1 General
URIs in HTTP can be represented in absolute form or relative to
known base URI, 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
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*
segment = *
params = param *( ";" param )
param = *( pchar | "/" )
Fielding, et. al. Standards Track [Page 18]
RFC 2068 HTTP/1.1 January 1997
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved |
unreserved = ALPHA | DIGIT | safe | extra |
escape = "%" HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national =
reserved, extra, safe, and unsafe
For definitive information on URL syntax and semantics, see RFC 1738
[4] and RFC 1808 [11]. The BNF above includes national characters
allowed in valid URLs as specified by RFC 1738, since HTTP
are not restricted in the set of unreserved characters allowed
represent the rel_path part of addresses, and HTTP proxies
receive requests for URIs not defined by RFC 1738.
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 should be cautious about depending on URI
above 255 bytes, because some older client or proxy
may 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
Fielding, et. al. Standards Track [Page 19]
RFC 2068 HTTP/1.1 January 1997
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = Internet host domain
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
port = *
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. The use of IP addresses in URL's
be avoided whenever possible (see RFC 1900 [24]). If the abs_path
not present in the URL, it MUST be given as "/" when used as
Request-URI for a resource (section 5.1.2).
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
o A port that is empty or not given is equivalent to the
port for that URI
o Comparisons of host names MUST be case-insensitive
o Comparisons of scheme names MUST be case-insensitive
o An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (
section 3.2) are equivalent to their ""%" HEX HEX" encodings
For example, the following three URIs are equivalent
http://abc.com:80/~smith/home.
http://ABC.com/%7Esmith/home.
http://ABC.com:/%7esmith/home.
Fielding, et. al. Standards Track [Page 20]
RFC 2068 HTTP/1.1 January 1997
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 (an update to
822). 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
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
All HTTP date/time stamps MUST be represented in Greenwich Mean
(GMT), without exception. This is indicated in the first two
by the inclusion of "GMT" as the three-letter abbreviation for
zone, and MUST be assumed when reading the asctime format
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
Fielding, et. al. Standards Track [Page 21]
RFC 2068 HTTP/1.1 January 1997
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
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
in the other direction is not required, in that not all
may be available in a given character set and a character set
provide more than one sequence of octets to represent a
character. This definition is intended to allow various kinds
character encodings, from simple single-table mappings such as US
ASCII to complex table switching methods such as those that use
2022's techniques. However, the definition associated with a
character set name MUST fully specify the mapping to be
from octets to characters. In particular, use of external
information 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 and
share the same registry, it is important that the terminology
be shared
Fielding, et. al. Standards Track [Page 22]
RFC 2068 HTTP/1.1 January 1997
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 MUST represent the character set defined
that registry. Applications SHOULD limit their use of character
to those defined by the IANA registry
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.12) 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 program "gzip
(GNU zip) as described in RFC 1952 [25]. This format is a 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).
Fielding, et. al. Standards Track [Page 23]
RFC 2068 HTTP/1.1 January 1997
Note: Use of program names for the identification of
formats is not desirable and should be discouraged for
encodings. Their use here is representative of historical practice
not good design. For compatibility with previous implementations
HTTP, applications should consider "x-gzip" and "x-compress" to
equivalent to "gzip" and "compress" respectively
deflate The "zlib" format defined in RFC 1950[31] in combination
the "deflate" compression mechanism described in RFC 1951[29].
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 =
All transfer-coding values are case-insensitive. HTTP/1.1
transfer coding values in the Transfer-Encoding header field (
14.40).
Transfer codings are analogous to the Content-Transfer-
values of MIME , 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
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 footer 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
Fielding, et. al. Standards Track [Page 24]
RFC 2068 HTTP/1.1 January 1997
Chunked-Body = *
"0"
chunk = chunk-size [ chunk-ext ]
chunk-data
hex-no-zero =
chunk-size = hex-no-zero *
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name =
chunk-ext-val = token | quoted-
chunk-data = chunk-size(OCTET
footer = *entity-
The chunked encoding is ended by a zero-sized chunk followed by
footer, which is terminated by an empty line. The purpose of
footer is to provide an efficient way to supply information about
entity that is generated dynamically; applications MUST NOT
header fields in the footer which are not explicitly defined as
appropriate for the footer, such as Content-MD5 or future
to HTTP for digital signatures or other facilities
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 transfer coding
they do not understand. A server which receives an entity-body with
transfer-coding it does not understand SHOULD return 501
(Unimplemented), and close the connection. A server MUST NOT
transfer-codings to an HTTP/1.0 client
3.7 Media
HTTP uses Internet Media Types in the Content-Type (section 14.18)
and Accept (section 14.1) header fields in order to provide open
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
Fielding, et. al. Standards Track [Page 25]
RFC 2068 HTTP/1.1 January 1997
parameter = attribute "="
attribute =
value = token | quoted-
The type, subtype, and parameter attribute names are case
insensitive. Parameter values may or may 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. User agents that recognize the media-
MUST process (or arrange to be processed by any external
used to process that type/subtype by the user agent) the
for that MIME type as described by that type/subtype definition
the and inform the user of any problems discovered
Note: 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). The media type registration process is outlined
RFC 2048 [17]. Use of non-registered media types is discouraged
3.7.1 Canonicalization and Text
Internet media types are registered with a canonical form.
general, an entity-body transferred via HTTP messages MUST
represented in the appropriate canonical form prior to
transmission; the exception is "text" types, as defined in the
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-Encoding, the
data MUST be in a form defined above prior to being encoded
Fielding, et. al. Standards Track [Page 26]
RFC 2068 HTTP/1.1 January 1997
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
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
content-type field if they support that charset, rather than
recipient's preference, when initially displaying a document
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 MIME [7], and
include a boundary parameter as part of the media type value.
message body is itself a protocol element and MUST therefore use
CRLF to represent line breaks between body-parts. Unlike in MIME,
epilogue of any multipart message MUST be empty; HTTP
MUST NOT transmit the epilogue (even if the original
contains an epilogue).
In HTTP, multipart body-parts MAY contain header fields which
significant to the meaning of that part. A Content-Location
field (section 14.15) SHOULD be included in the body-part of
enclosed entity that can be identified by a URL
In general, an HTTP user agent SHOULD follow the same or
behavior as a MIME user agent would upon receipt of a multipart type
If an application receives an unrecognized multipart subtype,
application MUST treat it as being equivalent to "multipart/mixed".
Note: The "multipart/form-data" type has been specifically
for carrying form data suitable for processing via the POST
method, as described in RFC 1867 [15].
Fielding, et. al. Standards Track [Page 27]
RFC 2068 HTTP/1.1 January 1997
3.8 Product
Product tokens are used to allow communicating applications
identify themselves by software name and version. Most fields
product tokens also allow sub-products which form a significant
of the application to be listed, separated by whitespace.
convention, the products are listed in order of their
for identifying the application
product = token ["/" product-version
product-version =
Examples
User-Agent: CERN-LineMode/2.15 libwww/2.17b
Server: Apache/0.8.4
Product tokens should be short and to the point -- use of them
advertising or other non-essential information is
forbidden. Although any token character may appear in a product
version, this token SHOULD only be used for a version
(i.e., successive versions of the same product SHOULD only differ
the product-version portion of the product value).
3.9 Quality
HTTP content negotiation (section 12) uses short "floating point
numbers to indicate the relative importance ("weight") of
negotiable parameters. A weight is normalized to a real number in
range 0 through 1, where 0 is the minimum and 1 the maximum value
HTTP/1.1 applications MUST NOT generate more than three digits
the decimal point. User configuration of these values SHOULD also
limited in this fashion
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
"Quality values" is a misnomer, since these values merely
relative degradation in desired quality
3.10 Language
A language tag identifies a natural language spoken, written,
otherwise conveyed by human beings for communication of
to other human beings. Computer languages are explicitly excluded
HTTP uses language tags within the Accept-Language and Content
Language fields
Fielding, et. al. Standards Track [Page 28]
RFC 2068 HTTP/1.1 January 1997
The syntax and registry of HTTP language tags is the same as
defined by RFC 1766 [1]. In summary, a language tag is composed of 1
or more parts: A primary language tag and a possibly empty series
subtags
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8
subtag = 1*8
Whitespace is not allowed within the tag and all tags are case
insensitive. The name space of language tags is administered by
IANA. Example tags include
en, en-US, en-cockney, i-cherokee, x-pig-
where any two-letter primary-tag is an ISO 639 language
and any two-letter initial subtag is an ISO 3166 country code. (
last three tags above are not registered tags; all but the last
examples of tags which could be registered in future.)
3.11 Entity
Entity tags are used for comparing two or more entities from the
requested resource. HTTP/1.1 uses entity tags in the ETag (
14.20), If-Match (section 14.25), If-None-Match (section 14.26),
If-Range (section 14.27) header fields. The definition of how
are used and compared as cache validators is in section 13.3.3.
entity tag consists of an opaque quoted string, possibly prefixed
a weakness indicator
entity-tag = [ weak ] opaque-
weak = "W/"
opaque-tag = quoted-
A "strong entity tag" may be shared by two entities of a
only if they are equivalent by octet equality
A "weak entity tag," indicated by the "W/" prefix, may be shared
two entities of a resource only if the entities are equivalent
could be substituted for each other with no significant change
semantics. A weak entity tag can only be used for weak comparison
An entity tag MUST be unique across all versions of all
associated with a particular resource. A given entity tag value
be used for entities obtained by requests on different URIs
implying anything about the equivalence of those entities
Fielding, et. al. Standards Track [Page 29]
RFC 2068 HTTP/1.1 January 1997
3.12 Range
HTTP/1.1 allows a client to request that only part (a range of)
response entity be included within the response. HTTP/1.1 uses
units in the Range (section 14.36) and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges
to various structural units
range-unit = bytes-unit | other-range-
bytes-unit = "bytes
other-range-unit =
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges specified using other units
HTTP/1.1 has been designed to allow implementations of
that do not depend on knowledge of ranges
4 HTTP
4.1 Message
HTTP messages consist of requests from client to server and
from server to client
HTTP-message = Request | Response ; HTTP/1.1
Request (section 5) and Response (section 6) messages use the
message format of RFC 822 [9] for transferring entities (the
of the message). Both types of message consist of a start-line,
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of
header fields, and an optional message-body
generic-message = start-
*message-
[ message-body ]
start-line = Request-Line | Status-
In the interest of robustness, servers SHOULD ignore any
line(s) received where a Request-Line is expected. In other words,
the server is reading the protocol stream at the beginning of
message and receives a CRLF first, it should ignore the CRLF
Fielding, et. al. Standards Track [Page 30]
RFC 2068 HTTP/1.1 January 1997
Note: certain buggy HTTP/1.0 client implementations generate
extra