view Side-By-Side changes
HTTP Working Group R. Fielding, UC Irvine
INTERNET-DRAFT H. Frystyk, MIT/LCS
<draft-ietf-http-v11-spec-02.txt>
<draft-ietf-http-v11-spec-03.html> T. Berners-Lee, MIT/LCS
J. Gettys, DEC
Jeffrey
J. C. Mogul, DEC
Expires September 23, October 2, 1996 April 23, May 2, 1996
Hypertext Transfer Protocol -- HTTP/1.1
1 Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as _work "work in progress_. progress".
To learn the current status of any Internet-Draft, please check the
_1id-abstracts.txt_
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to the
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the
working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about
HTTP and the applications which use HTTP should take place on the <www-
talk@w3.org> mailing list.
NOTE: This specification is for discussion purposes only. It is not
claimed to represent the consensus of the HTTP working group, and
contains a number of proposals that either have not been discussed
or are controversial. The working group is discussing significant
changes in many areas, including - support for caching, persistent
connections, range retrieval, content negotiation, MIME
compatibility, authentication, timing of the PUT operation.
2 Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level protocol
for distributed, collaborative, hypermedia information systems. It is a
generic, stateless, object-oriented protocol which can be used for many
tasks, such as name servers and distributed object management systems,
through extension of its request methods (commands). A feature of HTTP
is the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 1]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
HTTP has been in use by the World-Wide Web global information initiative
since 1990. This specification defines the protocol referred to as
_HTTP/1.1_.
"HTTP/1.1".
3 Note to Readers of This Document
This document is still organized
We believe this draft to minimize changes from the previous
draft, be very close to ease reviewers work consensus of the working group
in finding new material (and because terms of functionality for HTTP/1.1, and the
editor has not had time text substantially
correct. One final technical change NOT reflected in this draft is to reorganize it).. However,
make persistent connections the current
organization is now quite poor default behavior for new readers of this document. We
recommend that new readers of HTTP/1.1; editorial
changes to reflect this document not read it in the current
order of presentation, but may want to skip ahead after reading sections
1-9 and read sections 11, 12 13 next, and 14 before reading section 10 which
defines the header field definitions. Section 10 itself is now also not we hope final draft, are being
circulated in alphabetical order, again, to avoid renumbering sections to be able the working group mailing list.
This draft has undergone extensive reorganization to easily compare between drafts.
If you improve
presentation. Let us know if there are reading the version of remaining problems.
The terminology used in this document showing revision markup,
note that we've tried draft has changed to preserve significant changes from the previous
version, though reduce confusion.
While we are converging on a few shared set of terminology and definitions,
it is possible there will be a final set of terminology adopted in the
next draft. Despite any terminology changes may have slipped through unmarked. We make
no guarantees that all changes have revision marks, though we've tried
to preserve them as an aid may occur to those who wish improve
the presentation of the specification, we do not expect to check a specific change
has been reflected in this draft.
Note that some sections the
name of any header field or parameter name.
There are still marked as SLUSHY and a very few are marked
FLUID; these are still undergoing drafting.
Note that text remaining issues indicated by Editor's Note: in
bold in the text are as yet incompletely resolved
issues. Opinions are solicited_ font.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 2]
4 Table of Contents
HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1................................1 HTTP/1.1
1 Status of this Memo....................................................1
Abstract...............................................................1 Memo
2 Abstract
3 Note to Readers of This Document.......................................2 Document
4 Table of Contents......................................................3
1. Introduction........................................................9
1.1 Contents
5 Introduction
5.1 Purpose ..........................................................9
1.2
5.2 Requirements .....................................................9
1.3
5.3 Terminology .....................................................10
1.4
5.4 Overall Operation ...............................................12
1.4
5.5 HTTP and MIME ...................................................14
2.
6 Notational Conventions and Generic Grammar.........................14
2.1 Grammar
6.1 Augmented BNF ...................................................14
2.2
6.2 Basic Rules .....................................................16
3.
7 Protocol Parameters................................................18
3.1 Parameters
7.1 HTTP Version ....................................................18
3.2
7.2 Uniform Resource Identifiers ....................................19
3.2.1 General Syntax ...............................................19
3.2.2 http URL .....................................................21
3.3
7.3 Date/Time Formats ...............................................22
3.3.1 Full Date ....................................................22
3.3.2 Delta Seconds ................................................24
3.4
7.4 Character Sets ..................................................24
3.5
7.5 Content Codings .................................................25
3.6
7.6 Transfer Codings ................................................26
3.7
7.7 Media Types .....................................................27
3.7.1 Canonicalization and Text Defaults ...........................28
3.7.2 Multipart Types ..............................................29
3.8
7.8 Product Tokens ..................................................29
3.9
7.9 Quality Values ..................................................30
3.10
7.10 Language Tags ..................................................30
3.12 Full Date Values ...............................................31
3.13 Opaque Validators ..............................................31
3.14
7.11 Entity Tags
7.12 Variant IDs ....................................................32
3.15 Validator Sets .................................................32
3.16
7.13 Variant Sets ...................................................32
3.17 HTTP
7.14 Range Protocol Parameters Related to Ranges .....................32
3.17.1SLUSHY Range Units ...........................................32
3.17.2 SLUSHY Byte Ranges ..........................................33
3.17.3 SLUSHY: Content Ranges ......................................34
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
4.
8 HTTP Message.......................................................35
4.1 Message
8.1 Message Types ...................................................35
4.2
8.2 Message Headers .................................................36
4.3
8.3 General Header Fields ...........................................37
5. Request............................................................38
5.1
9 Request
9.1 Request-Line ....................................................38
5.1.1 Method .......................................................38
5.1.2 Request-URI ..................................................39
5.2
9.2 The Resource Identified by a Request
9.3 Request Header Fields ...........................................41
6. Response...........................................................42
6.1
10 Response
10.1 Status-Line .....................................................43
6.1.1 Status Code and Reason Phrase ................................43
6.2
10.2 Response Header Fields ..........................................46
7. Entity.............................................................46
7.1
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
11 Entity
11.1 Entity Header Fields ............................................46
7.2
11.2 Entity Body .....................................................47
7.2.1 Type .........................................................48
7.2.2 Length .......................................................48
8. Method Definitions.................................................49
8.1 OPTIONS .........................................................49
8.2 GET .............................................................50
8.3 HEAD ............................................................50
8.4 POST ............................................................51
8.4.1 SLUSHY: Entity Transmission Requirements .....................52
8.5 PUT .............................................................53
8.9 DELETE ..........................................................54
8.12 TRACE ..........................................................54
9.
12 Status Code Definitions............................................55
9.1 Definitions
12.1 Informational 1xx ...............................................55
9.2
12.2 Successful 2xx ..................................................56
9.3
12.3 Redirection 3xx .................................................58
9.4
12.4 Client Error 4xx ................................................60
9.5
12.5 Server Error 5xx ................................................63
10. Header Field Definitions..........................................65
10.1 Accept .........................................................65
10.2 Accept-Charset .................................................67
10.3 Accept-Encoding ................................................67
10.4 Accept-Language ................................................68
10.5 Allow ..........................................................69
10.6 Authorization ..................................................70
10.7 Cache-Control ..................................................70
Check: is this true? ...............................................72
10.7.1 SLUSHY: Restrictions on What is Cachable ....................72
10.7.2 Restrictions On What May be Stored by a Cache ...............73
10.7.3 Modifications of the
13 Method Definitions
13.1 OPTIONS
13.2 GET
13.3 HEAD
13.4 POST
13.5 PUT
13.6 DELETE
13.7 TRACE
14 Access Authentication
14.1 Basic Expiration Mechanism .............73
10.7.4 SLUSHY: Controls over cache revalidation and reload .........74
10.7.5 FLUID: Restrictions on use count and demographic reporting ..76
10.7.6 Miscellaneous restrictions ..................................77
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
10.8 Connection .....................................................77
10.8.1 Persist ......................................................78
10.9 Content-Base ...................................................78
10.10 Content-Encoding ..............................................78
10.11 Content-Language ..............................................79
10.12 Content-Length ................................................80
10.13 Content-MD5 ...................................................80
10.14 SLUSHY Content-Range ..........................................82
10.14.1 MIME multipart/byteranges content-type .....................82
10.14.2 Additional rules for Content-Range .........................83
10.15 Content-Type ..................................................83
10.16 Content-Location ..............................................84
10.17 Date ..........................................................84
10.19 SLUSHY Expires ................................................85
10.20 Via ...........................................................86
10.21 From ..........................................................88
10.22 Host ..........................................................88
10.23 If-Modified-Since .............................................89
10.25 Last-Modified .................................................90
10.27 Location ......................................................91
10.29 Pragma ........................................................91
10.30 Proxy-Authenticate ............................................92
10.31 Proxy-Authorization ...........................................92
10.32 Public ........................................................93
10.33 Range .........................................................93
10.34 Referer .......................................................94
10.36 Retry-After ...................................................95
10.37 Server ........................................................95
10.38 Title .........................................................95
10.39 Transfer Encoding .............................................96
10.41 Upgrade .......................................................96
10.43 User-Agent ....................................................97
10.44 WWW-Authenticate ..............................................98
10.45 Max-Forwards ..................................................98
10.46 Age ...........................................................99
10.47 CVal ..........................................................99
10.48 If-Invalid ....................................................99
10.49 If-Valid .....................................................100
10.50 If-Unmodified-Since ..........................................101
10.51 Warning ......................................................102
10.52 Vary .........................................................103
10.53 Alternates ...................................................106
10.54 SLUSHY: Accept-Ranges ........................................107
10.55 SLUSHY: Range-If .............................................107
11. Access Authentication............................................108
11.1 Basic Authentication Scheme ...................................109
11.2 Digest Authentication Scheme ..................................110
12. Content Negotiation..............................................111
12.1 Negotiation facilities defined in this specification .........111
13 Caching in HTTP...................................................112
13.1 Semantic Transparency .........................................112
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
13.2 Authentication Scheme
14.2 Digest Authentication Scheme
15 Content Negotiation
15.1 Negotiation Facilities Defined in this Specification
16 Caching in HTTP
16.1 Semantic Transparency
16.2 Expiration Model ..............................................113
13.2.1 Server-Specified Expiration ................................113
13.2.2 Limitations on the Effect of Expiration Times ..............114
13.2.3 Heuristic Expiration .......................................114
13.2.4 Client-controlled Behavior .................................114
13.2.5 Exceptions to the Rules and Warnings .......................115
13.2.6 Age Calculations ...........................................115
13.2.7 Expiration Calculations ....................................117
13.2.8 UT Mandatory ................................................118
13.3
16.3 Validation Model ..............................................118
13.3.1 Last-modified Dates ........................................119
13.3.2 Opaque Validators ..........................................119
13.3.3 Weak and Strong Validators .................................120
13.3.4 Rules for When to Use Opaque Validators and Last-modified
Dates .............................................................122
13.3.5 SLUSHY: Non-validating conditionals ........................123
13.3.6 FLUID: Other Issues ........................................123
13.4 Cache-control Mechanisms ......................................123
13.5 Warnings ......................................................124
13.6 Explicit Indications Regarding User-specified Overrides .......124
13.7
16.4 Constructing Responses From Caches ............................125
13.7.1 End-to-end and Hop-by-hop Headers ..........................125
13.7.2 Non-modifiable Headers .....................................126
13.7.3 Combining Headers ..........................................126
13.7.4 Combining Byte Ranges ......................................126
13.7.5 SLUSHY: Scope of Expiration ................................127
13.8
16.5 Caching and Content Negotiation ...............................127
13.8.1 Use of the Vary header .....................................127
13.8.2 SLUSHY: Use of the Alternates header .......................128
13.8.3 Use of Variant-IDs .........................................128
13.8.4 Use of Selecting Opaque Validators .........................129
13.10 Generic Resources
16.6 Shared and Non-Shared Caches .................................130
13.11 SLUSHY: Miscellaneous Considerations .........................130
13.11.1 Detecting Firsthand Responses .............................130
13.11.2 Disambiguating Expiration values ..........................130
13.11.3 Disambiguating Multiple Responses .........................131
13.12 SLUSHY: Cache Keys ...........................................131
13.12.1 Non-varying Resources .....................................132
13.12.2 SLUSHY: Varying Resources .................................132
13.12.3 SLUSHY: Key-Matching Procedure ............................133
13.12.4 Canonicalization of URIs ..................................134
13.13 FLUID: Cache-Related Problems Not Addressed in HTTP/1.1 ......134
13.14 Cache Operation When Receiving
16.7 Selecting a Cached Response
16.8 Errors or Incomplete Responses 134
13.14.1 Caching and Status Codes ..................................135
13.14.2 Handling of Retry-After ...................................135
13.15 FLUID: Compatibility With Earlier Versions of HTTP ...........135
13.16 SLUSHY: Response Cache Behavior
16.9 Side Effects of GET and HEAD .........................135
13.17 SLUSHY:
16.10 Invalidation After Updates or Deletions ..............136
13.18
16.11 Write-Through Mandatory ......................................136
13.19 Interoperability of Varying
16.12 Generic Resources with and HTTP/1.0 Proxy Caches .............................................................136
13.20
16.13 Cache Replacement for Varying Resources ......................137
13.22 FLUID: Network Partitions ....................................138
13.23 FLUID:
16.14 Caching of Negative Responses .........................138
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
13.24
16.15 History Lists ................................................138
14
17 Persistent Connections............................................138
14.1 Connections
17.1 Purpose .......................................................138
14.2
17.2 Overall Operation .............................................139
14.2.3 Negotiation ................................................139
14.2.4 Pipe-lining ................................................139
14.2.5 Delimiting Entity-Bodies ...................................139
14.3
17.3 Proxy Servers .................................................140
14.4
17.4 Interaction with Security Protocols ...........................140
14.5
17.5 Practical Considerations ......................................140
15.
18 Header Field Definitions
18.1 Accept
18.2 Accept-Charset
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
18.3 Accept-Encoding
18.4 Accept-Language
18.5 Accept-Ranges
18.6 Age
18.7 Allow
18.8 Alternates
18.9 Authorization
18.10 Cache-Control
18.11 Connection
18.12 Content-Base
18.13 Content-Encoding
18.14 Content-Language
18.15 Content-Length
18.16 Content-Location
18.17 Content-MD5
18.18 Content-Range
18.19 Content-Type
18.20 Date
18.21 ETag
18.22 Expires
18.23 From
18.24 Host
18.25 If-Modified-Since
18.26 If-Match
18.27 If-NoneMatch
18.28 If-Range
18.29 If-Unmodified-Since
18.30 Last-Modified
18.31 Location
18.32 Max-Forwards
18.33 Persist
18.34 Pragma
18.35 Proxy-Authenticate
18.36 Proxy-Authorization
18.37 Public
18.38 Range
18.39 Referer
18.40 Retry-After
18.41 Server
18.42 Title
18.43 Transfer Encoding
18.44 Upgrade
18.45 User-Agent
18.46 Vary
18.47 Via
18.48 Warning
18.49 WWW-Authenticate
19 Security Considerations..........................................141
15.1 Considerations
19.1 Authentication of Clients .....................................141
15.2
19.2 Safe Methods ..................................................142
15.3
19.3 Abuse of Server Log Information ...............................143
15.4
19.4 Transfer of Sensitive Information .............................143
15.5
19.5 Attacks Based On File and Path Names ..........................143
15.6
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
19.6 Personal Information ..........................................144
15.7
19.7 Privacy issues connected Issues Connected to Accept headers ....................144
15.8
19.8 DNS Spoofing ..................................................145
15.9 SLUSHY:
19.9 Location Headers and Spoofing .........................145
16. Acknowledgments..................................................145
17. References.......................................................147
18.
20 Acknowledgments
21 References
22 Authors' Addresses...............................................150
Appendices...........................................................151
A. Addresses
23 Appendices
23.1 Internet Media Type message/http..................................151
B. message/http
23.2 Tolerant Applications.............................................152
C. Applications
23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message
Bodies
.....................................................................152
C.1 Conversion to Canonical Form ...................................153
C.2 Conversion of Date Formats .....................................153
C.3 Introduction of Content-Encoding ...............................153
C.4 No Content-Transfer-Encoding ...................................154
C.5 HTTP Header Fields in Multipart Body-Parts .....................154
C.6 Introduction of Transfer-Encoding ..............................154
C.7 MIME-Version ...................................................155
D.
23.4 Changes from HTTP/1.0.............................................155
D.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses ..........................................................155
E. Additional Features...............................................156
E.1 Additional Request Methods .....................................156
E.1.1 PATCH .......................................................156
E.1.2 LINK ........................................................157
E.1.3 UNLINK ......................................................157
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 7]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
E.2 Additional Header Field Definitions ............................157
E.2.1 Content-Version .............................................157
E.2.2 Derived-From ................................................158
E.2.3 Link ........................................................158
E.2.4 URI .........................................................159
E.2.5 Compatibility with HTTP/1.0 Persistent Connections ..........160
F.1 Compatibility with Previous Versions ...........................160
G. Proxy Cache Implementation Guidelines ...........................161
G.1 Support for Content Negotiation by Proxy Caches ................161
G.2 Propagation of Changes in Opaque Selection ....................163
G.3 SLUSHY: State ..................................................163
G.4 FLUID: Cache Replacement Algorithms ............................163
G.5 FLUID: Bypassing in Caching Hierarchies ........................164
23.5 Additional Features
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8]
1. 6]
5 Introduction
1.1
5.1 Purpose
The Hypertext Transfer Protocol (HTTP) is an application-level protocol
for distributed, collaborative, hypermedia information systems. HTTP has
been in use by the World-Wide Web global information initiative since
1990. The first version of HTTP, referred to as HTTP/0.9, was a simple
protocol for raw data transfer across the Internet. HTTP/1.0, as defined
by RFC xxxx [6], , improved the protocol by allowing messages to be in the
format of MIME-like entities, containing metainformation about the data
transferred and modifiers on the request/response semantics. However,
HTTP/1.0 does not sufficiently take into consideration the effect of
hierarchical proxies and , caching, the desire need for persistent connections and
virtual hosts, and a number of other details that slipped through
the cracks of existing implementations. hosts.. In addition, the proliferation of incompletely-implemented incompletely-
implemented applications calling themselves _HTTP/1.0_ "HTTP/1.0" has necessitated
a protocol version change in order for two communicating applications to
determine each other's true capabilities.
This specification defines the protocol referred to as _HTTP/1.1_. "HTTP/1.1". This
protocol is backwards-compatible with HTTP/1.0, but includes more
stringent requirements in order to ensure reliable implementation of its
features.
Practical information systems require more functionality than simple
retrieval, including search, front-end update, and annotation. HTTP
allows an open-ended set of methods that indicate the purpose of a
request. It builds on the discipline of reference provided by the
Uniform Resource Identifier (URI) [3], , as a location (URL) [4] or name (URN) [20],
,
for indicating the resource on to which a method is to be applied. Messages
are passed in a format similar to that used by Internet Mail [9] and the
Multipurpose Internet Mail Extensions (MIME)
[7]. .
HTTP is also used as a generic protocol for communication between user
agents and proxies/gateways to other Internet protocols, such as SMTP
[16], ,
NNTP [13], , FTP [18], , Gopher [2], , and WAIS [10], , allowing basic hypermedia access to
resources available from diverse applications and simplifying the
implementation of user agents.
1.2
5.2 Requirements
This specification uses the same words as RFC 1123 [8] for defining the
significance of each particular requirement. These words are:
MUST
This word or the adjective _required_ "required" means that the item is an
absolute requirement of the specification.
SHOULD
This word or the adjective _recommended_ "recommended" means that there may
exist
valid reasons in particular circumstances to ignore this item, but
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 9]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
the full implications should be understood and the case carefully
weighed before choosing a different course.
MAY
This word or
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 7]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
MAY
This word or the adjective _optional_ "optional" means that this item is
truly
optional. One vendor may choose to include the item because a
particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more of
the MUST requirements for the protocols it implements. An implementation
that satisfies all the MUST and all the SHOULD requirements for its
protocols is said to be _unconditionally compliant_; "unconditionally compliant"; one that satisfies
all the MUST requirements but not all the SHOULD requirements for its
protocols is said to be _conditionally compliant_.
1.3 "conditionally compliant".
5.3 Terminology
This specification uses a number of terms to refer to the roles played
by participants in, and objects of, the HTTP communication.
connection
A transport layer virtual circuit established between two
application programs
for the purpose of communication.
message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 section 8 and
transmitted via the connection.
request
An HTTP request message (as as defined in Section 5). section 9.
response
An HTTP response message (as as defined in Section 6). section 10.
resource
A network data object or service that can be identified by a URI
(Section 3.2).
entity
A particular
(section 7.2). At any point in time, a resource may be either a
plain resource, which corresponds to only one possible
representation, rendition, encoding, or presentation
of a generic resource. Resources
generic resource
A resource that is a set of closely related representations of the
same document, form, applet, etc. A generic resource is always
identified by a URI. The individual representations may each be
identified by a unique URI, or by the combination of the generic
resource's URI and a variant-ID, or by the combination of the generic
resource's URI and some "content-negotiation" mechanism. In this
case, other URIs may exist which identify a resource more
specifically.
plain resource
A resource that is not supporting content negotiation are
bound to a single entity. Resources supporting content negotiation generic resource. A plain resource is
always identified by a URI.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10] 8]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
are bound to a set of one or more entities, whose membership may
vary over time.
entity instance
The definite value set of information transferred as the payload of an entity at a given
point in time. The HTTP protocol transfers
entity instances in request or
response
messages. An entity instance is transferred as consists of metainformation in the form of entity headers
Entity-Header fields and content in the form of an Entity-Body, as
described in section 11.
resource entity body.
A specific representation, rendition, encoding, or presentation of a
network data object or service, either a plain resource or a specific
member of a generic resource. A resource entity might be identified
by a URI, or by the combination of a URI and a variant-ID, or by the
combination of a URI and some other mechanism. An plain resource MUST
be bound to a single resource entity at any instant in time.
variant
A resource entity that is a member of at least one generic resource.
Sometimes called a resource variant. Note that the set of variants
of a generic resource may change over time as well.
content negotiation
The mechanism for selecting the appropriate variant of a generic
resource when servicing a request, as described in section 15.
entity tag
An opaque string associated with an entity and used to distinguish it
from other entities of the requested resource . A "strong entity
tag" is one that may be shared by two entities of a resource only if
they are equivalent by octet equality. A "weak entity tag" is one
that may be shared by two entities of a resource if they are
equivalent and could be substituted for each other with no
significant change in semantics. A given entity tag value may be
used for entities obtained by requests on different URIs without
implying anything about the equivalence of these entities.
client
An application program that establishes connections for the purpose
of sending requests.
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections in order to service
requests by sending back responses. Any given program MAY be capable
of being both a client and a server; our use of these terms refers
only to the role being performed by the program for a particular
connection, rather than to the program's capabilities in general.
Likewise, any server MAY act as an origin server, proxy, gateway, or
tunnel, switching behavior based on the nature of each request.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 9]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
proxy
An intermediary program which acts as both a server and a client for
the purpose of making requests on behalf of other clients. Requests
are serviced internally or by passing them, them on, with possible
translation, on to other servers. A proxy MUST interpret and, if
necessary, rewrite a request message before forwarding it. Proxies
are often used as client-side portals through network firewalls and
as helper applications for handling requests via protocols not
implemented by the user agent.
gateway
A server which acts as an intermediary for some other server. Unlike
a proxy, a gateway receives requests as if it were the origin server
for the requested resource; the requesting client may not be aware
that it is communicating with a gateway. Gateways are often used as
server-side portals through network firewalls and as protocol
translators for access to resources stored on non-HTTP systems.
tunnel
A tunnel is an
An intermediary program which is acting as a blind
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 relay between two
connections. Once active, a tunnel is not considered a party to the
HTTP communication, though the tunnel may have been initiated by an
HTTP request. The tunnel ceases to exist when both ends of the
relayed connections are closed. Tunnels are used when a portal is
necessary and the intermediary cannot, or should not, interpret the
relayed communication.
cache
A program's local store of response messages and the subsystem that
controls its message storage, retrieval, and deletion. A cache stores
cachable responses in order to reduce the response time and network
bandwidth consumption on future, equivalent requests. Any client or
server MAY include a cache, though a cache cannot be used by a server while it is
that acts acting as a tunnel.
Any given program MAY be capable
cachable
A response is cachable if a cache is allowed to store a copy of being both the
response message for use in answering subsequent requests. The rules
for determining the cachability of HTTP responses are defined in
Section 16. Even if a client resource is cachable, there may be additional
constraints on when and if a server;
our cache can use the cached copy for a
particular request.
firsthand
A response is firsthand if it comes directly and without unnecessary
delay from the origin server, perhaps via one or more proxies. A
response is also firsthand if its validity has just been checked
directly with the origin server.
explicit expiration time
The time at which the origin server intends that an entity should no
longer be returned by a cache without further validation.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
heuristic expiration time
An expiration time assigned by a cache when no explicit expiration
time is available.
age
The age of these terms refers only a response is the time since it was generated by, or
successfully validated with, the origin server.
freshness lifetime
The length of time between the generation of a response and its
expiration time.
fresh
A response is fresh if its age has not yet exceeded its freshness
lifetime.
stale
A response is stale if its age has passed its freshness lifetime. A
cache may use a fresh response without validating it, but "normally"
may not use a stale response without first validating it.
("Normally" means "unless configured to provide better performance at
the role being performed by expense of transparency.")
Therefore, what expires is the
program for cache's authority to use a particular connection, rather than cached
response, without validation, in its reply to a subsequent request.
semantically transparent
Ideally, an HTTP/1.1 cache would be "semantically transparent." That
is, use of the program's
capabilities cache would not affect either the clients or the
servers in general. Likewise, any server MAY act as an way except to improve performance. When a client makes
a request via a semantically transparent cache, it receives exactly
the same entity headers and entity body it would have received if it
had made the same request to the origin server, proxy, gateway, at the same time.
validator
An entity tag, or tunnel, switching behavior based on a Last-Modified time, which is used to find out
whether a cache entry is a semantically transparent copy of a
resource entity. A cache entry is semantically transparent if its
validator exactly matches the
nature validator that the server would provide
for current instance of each request.
1.4 that resource entity.
5.4 Overall Operation
The HTTP protocol is based on a request/response paradigm. protocol. A client sends a
request to the server in the form of a request method, URI, and protocol
version, followed by a MIME-like message containing request modifiers,
client information, and possible body content over a connection with a
server. The server responds with a status line, including the message's
protocol version and a success or error code, followed by a MIME-like
message containing server information, entity metainformation, and
possible entity body content.
Most HTTP communication is initiated by a user agent and consists of a
request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
A more complicated situation occurs when one or more intermediaries are
present in the request/response chain. There are three common forms of
intermediary: proxy, gateway, and tunnel. A proxy is a forwarding
agent,
receiving requests for a URI in its absolute form, rewriting all or
parts part
of the message, and forwarding the reformatted request toward the server
identified by the URI. A gateway is a receiving agent, acting as a layer
above some other server(s) and, if necessary, translating the requests
to the underlying server's protocol. A tunnel acts as a relay point
between two connections without changing the messages; tunnels are used
when the communication needs to pass through an intermediary (such
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 as a
firewall) even when the intermediary cannot understand the contents of
the messages.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that travels
the whole chain MUST pass through four separate connections. This
distinction is important because some HTTP communication options may
apply only to the connection with the nearest, non-tunnel neighbor, only
to the end-points of the chain, or to all connections along the chain.
Although the diagram is linear, each participant may be engaged in
multiple, simultaneous communications. For example, B may be receiving
requests from many clients other than A, and/or forwarding requests to
servers other than C, at the same time that it is handling A's request.
Any party to the communication which is not acting as a tunnel may
employ an internal cache for handling requests. The effect of a cache is
that the request/response chain is shortened if one of the participants
along the chain has a cached response applicable to that request. The
following illustrates the resulting chain if B has a cached copy of an
earlier response from O (via C) for a request which has not been cached
by UA or A.
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
Not all responses are cachable, and some requests may contain modifiers
which place special requirements on cache behavior. HTTP requirements
for cache behavior and cachable responses are defined in Section 13.
On the Internet, section 16.
HTTP communication generally usually takes place over TCP/IP connections. The
default port is TCP 80 [19], , but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on the
Internet, or on other networks. HTTP only presumes a reliable
transport;
any protocol that provides such guarantees can be used; the mapping of
the HTTP/1.1 request and response structures onto the transport data
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
units of the protocol in question is outside the scope of this
specification.
However, HTTP/1.1 implementations SHOULD implement persistent
connections (See section 14). 17). Both clients and servers MUST be capable
of handling cases where either party closes the connection prematurely,
due to user action, automated time-out, or program failure. In any
case,
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
the closing of the connection by either or both parties always
terminates the current request, regardless of its status.
1.4
5.5 HTTP and MIME
HTTP/1.1 uses many of the constructs defined for MIME, as defined in RFC
1521 [7]. . Appendix C 23.3 describes the ways in which the context of HTTP
allows for different use of Internet Media Types than is typically found
in Internet mail, and gives the rationale for those differences.
2.
6 Notational Conventions and Generic Grammar
2.1
6.1 Augmented BNF
All of the mechanisms specified in this document are described in both
prose and an augmented Backus-Naur Form (BNF) similar to that used by
RFC 822 [9]. . Implementers will need to be familiar with the notation in
order to understand this specification. The augmented BNF includes the
following constructs:
name = definition
The name of a rule is simply the name itself (without any enclosing
"<" and ">") and is separated from its definition by the equal
character "=". Whitespace is only significant in that indentation
of continuation lines is used to indicate a rule definition that
spans more than one line. Certain basic rules are in uppercase,
such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are
used within definitions whenever their presence will facilitate
discerning the use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise, the
text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("I") 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 "(elem (foo | bar) elem)_ elem)" allows the token sequences _elem "elem
foo elem_ elem" and _elem "elem bar elem_. elem".
*rule
The character _*_ "*" preceding an element indicates repetition. The
full form is _<n>*<m>element_ "<n>*<m>element" indicating at least <n> and at most
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
<m> occurrences of element. Default values are 0 and infinity so
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
that _*(element)_ "*(element)" allows any number, including zero; _1*element_ "1*element"
requires at least one; and _1*2element_ "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; _[foo bar]_ "[foo bar]" is
equivalent to _*1(foo bar)_. "*1(foo bar)".
N rule
Specific repetition: _<n>(element)_ "<n>(element)" is equivalent to
_<n>*<n>(element)_;
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
#rule
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m>element" "<n>#<m>element " indicating at least
<n> and at most <m> elements, each separated by one or more commas
(",") and optional linear whitespace (LWS). This makes the usual
form of lists very easy; a rule such as "( *LWS element *( *LWS
","
*LWS element ))" )) " can be shown as "1#element". Wherever this
construct is used, null elements are allowed, but do not contribute
to the count of elements present. That is, "(element), , (element)" (element)
" is permitted, but counts as only two elements. Therefore, where
at least one element is required, at least one non-null element
MUST be present. Default values are 0 and infinity so that "#(element)"
"#(element) " allows any number, including zero; "1#element"
requires at least one; and _1#2element_ "1#2element" allows one or two.
; comment
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 a
simple way of including useful notes in parallel with the
specifications.
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear whitespace (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent tokens and delimiters (tspecials), without
changing the interpretation of a field. At least one delimiter
(tspecials) MUST exist between any two tokens, since they would
otherwise be interpreted as a single token. However, applications
SHOULD attempt to follow _common form_ "common form" when generating HTTP
constructs, since there exist some implementations that fail to
accept anything beyond the common forms.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
2.2
6.2 Basic Rules
The following rules are used throughout this specification to describe
basic parsing constructs. The US-ASCII coded character set is defined by
[21]. by.
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker for
all protocol elements except the Entity-Body (see Appendix B appendix 23.2 for
tolerant applications). The end-of-line marker within an Entity-Body is
defined by its associated media type, as described in Section 3.7. section 7.7.
CRLF = CR LF
HTTP/1.1 headers can be folded onto multiple lines if the continuation
line begins with a space or horizontal tab. All linear whitespace,
including folding, has the same semantics as SP.
LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words of
*TEXT MAY contain octets from character sets other than US-ASCII only
when encoded according to the rules of RFC 1522 [14]. .
TEXT = <any OCTET except CTLs,
but including LWS>
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Recipients of header field TEXT containing octets outside the US-ASCII
character set range MAY assume that they represent ISO-8859-1 characters
if there is no other encoding indicated by an RFC 1522 mechanism.
Hexadecimal numeric characters are used in several protocol elements.
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS or
special characters. These special characters MUST be in a quoted string
to be used within a parameter value.
word = token | quoted-string
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
Comments can be included in some HTTP header fields by surrounding the
comment text with parentheses. Comments are only allowed in fields
containing _comment_ "comment" as part of their field value definition. In all
other fields, parentheses are considered part of the field value.
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any CHAR except <"> and CTLs,
but including LWS>
The backslash character (_\_) ("\") may be used as a single-character quoting
mechanism only within quoted-string and comment constructs.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
quoted-pair = "\" CHAR
3.
7 Protocol Parameters
3.1
7.1 HTTP Version
HTTP uses a _<major>.<minor>_ "<major>.<minor>" numbering scheme to indicate versions of
the protocol. The protocol versioning policy is intended to allow the
sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version number
for the addition of message components which do not affect communication
behavior or which only add to extensible field values. The <minor>
number is incremented when the changes made to the protocol add features
which do not change the general message parsing algorithm, but which may
add to the message semantics and imply additional capabilities of the
sender. The <major> number is incremented when the format of a message
within the protocol is changed.
The version of an HTTP message is indicated by an HTTP-Version field in
the first line of the message. If the protocol version is not specified,
the recipient MUST assume that the message is in the simple HTTP/0.9
format [6]. .
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers SHOULD be treated as separate
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 is lower
than HTTP/12.3. Leading zeros SHOULD be ignored by recipients and never
generated by senders.
Applications sending Full-Request or Full-Response messages, as defined
by this specification, MUST include an HTTP-Version of _HTTP/1.1_. "HTTP/1.1". Use
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
of this version number indicates that the sending application is at
least conditionally compliant with this specification.
Proxy and gateway applications MUST be careful in forwarding requests
that are received in a format different than from that of the application's
native HTTP version. Since the protocol version indicates the protocol
capability of the sender, a proxy/gateway MUST never send a message with
a version indicator which is greater than its native version; if a
higher version request is received, the proxy/gateway MUST either
downgrade the request version, respond with an error, or switch to
tunnel behavior. Requests with a version lower than that of the
application's native format MAY be upgraded before being forwarded; the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
proxy/gateway's response to that request MUST follow the server
requirements listed above.
Note: Converting between versions of HTTP may involve addition or
deletion of headers required or forbidden by the version involved.
It is likely more involved than just changing the version
indicator.
3.2
7.2 Uniform Resource Identifiers
URIs have been known by many names: WWW addresses, Universal Document
Identifiers, Universal Resource Identifiers [3], , and finally the
combination of Uniform Resource Locators (URL) [4] and Names (URN) [20]. . As far
as HTTP is concerned, Uniform Resource Identifiers are simply formatted
strings which identify--via name, location, or any other
characteristic--a characteristic--
a network resource.
3.2.1
7.2.1 General Syntax
URIs in HTTP can be represented in absolute form or relative to some
known base URI [11], , depending upon the context of their use. The two forms
are differentiated by the fact that absolute URIs always begin with a
scheme name followed by a colon.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
absoluteURI = scheme ":" *( uchar | reserved )
relativeURI = net_path | abs_path | rel_path
net_path = "//" net_loc [ abs_path ] abs_path
= "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
params = param *( ";" param )
param = *( pchar | "/" )
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
pchar = uchar | ":" | "@" | "&" "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "." | "+"
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
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 not allowed in
valid URLs as specified by RFC 1738, since HTTP servers are not
restricted in the set of unreserved characters allowed to represent the
rel_path part of addresses, and HTTP proxies may receive requests for
URIs not defined by RFC 1738.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
The HTTP protocol does not place any a-priori a priori limit on the length of a
URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server SHOULD
return a status code of
414 Request-URI Too Large
if a URI is longer than the server can handle. See section 9.4. 12.4.1.15.
Note: Servers SHOULD should be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy 414 Request-URI Too Large implementations
may not properly support these.
All client and proxy implementations MUST be able to handle a URI of
any finite length.
3.2.2
7.2.2 http URL
The _http_ "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and semantics
for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
port = *DIGIT
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
If the port is empty or not given, port 80 is assumed. The semantics are
that the identified resource is located at the server listening for TCP
connections on that port of that host, and the Request-URI for the
resource is abs_path. The use of IP addresses in URL's SHOULD be
avoided whenever possible. See RFC 1900[24]. 1900. If the abs_path is not
present in the URL, it MUST be given as _/_ "/" when used as a Request-URI
for a resource (Section 5.1.2). (section 9.1.2).
Note: Although the HTTP protocol is independent of the transport
layer protocol, the http URL only identifies resources by their TCP
location, and thus non-TCP resources MUST be identified by some
other URI scheme.
The canonical form for _http_ "http" URLs is obtained by converting any UPALPHA
characters in host to their LOALPHA equivalent (hostnames are case-
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
insensitive), eliding the [ ":" port ] if the port is 80, and replacing
an empty abs_path with _/_.
3.3 "/".
7.2.3 URI Canonicalization
A cache, when comparing two URIs to decide if they match or not, a cache
MUST use a case-sensitive octet-by-octet comparison of the entire URIs,
with these exceptions:
Following the rules from section 7.2.2:
. A port that is empty or not given is equivalent to port 80.
. 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 except those in the reserved set and the unsafe set (see
section 7.2) are equivalent to their ""%" HEX HEX" encodings.
For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
7.3 Date/Time Formats
3.3.1
7.3.1 Full Date
HTTP applications have historically allowed three different formats 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, made obsolete obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents a
fixed-length subset of that defined by RFC 1123 [8] (an update to RFC
822 [9]). 822).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
The second format is in common use, but is based on the obsolete RFC
850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and
servers that parse the date value MUST accept all three formats, though
they MUST only generate only the RFC 1123 format for representing date/time
stamps in HTTP message fields.
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been generated by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
All HTTP date/time stamps MUST be represented in Universal Time (UT),
also known as Greenwich Mean Time (GMT), without exception. This is
indicated in the first two formats by the inclusion of _GMT_ "GMT" as the
three-letter abbreviation for time zone, and SHOULD be assumed when
reading the asctime format.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
HTTP-date = rfc1123-date | rfc850-date | asctime-date
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 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 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 only
to their usage within the protocol stream. Clients and servers are
not required to use these formats for user presentation, request
logging, etc.
Additional rules for requirements on parsing and representation of dates
and other potential problems with date representations include:
. HTTP/1.1 clients and caches should assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact in
the past (this helps solve the _year 2000_ "year 2000" problem).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
. An HTTP/1.1 implementation may internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the proper
value.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
3.3.2
. All expiration-related calculations must be done in Universal Time
(GMT). The local time zone MUST NOT influence the calculation or
comparison of an age or expiration time.
. If an HTTP header incorrectly carries a date value with a time zone
other than GMT, it must be converted into GMT using the most
conservative possible conversion.
7.3.2 Delta Seconds
Some HTTP header fields allow a time value to be specified as an integer
number of seconds, represented in decimal, after the time that the
message was received. This format SHOULD only be used to represent short
time periods or periods that cannot start until receipt of the message.
delta-seconds = 1*DIGIT
3.4
7.4 Character Sets
HTTP uses the same definition of the term _character set_ "character set" as that
described for MIME:
The term _character set_ "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of octets
into a sequence of characters. Note that unconditional conversion
in the other direction is not required, in that not all characters
may be available in a given character set and a character set may
provide more than one sequence of octets to represent a particular
character. This definition is intended to allow various kinds of
character encodings, from simple single-
table single-table mappings such as US-ASCII US-
ASCII to complex table switching methods such as those that use ISO
2022's techniques. However, the definition associated with a MIME
character set name MUST fully specify the mapping to be performed
from octets to characters. In particular, use of external profiling
information to determine the exact mapping is not permitted.
Note: This use of the term _character set_ "character set" is more commonly
referred to as a _character encoding._ "character encoding." However, since HTTP and MIME
share the same registry, it is important that the terminology also
be shared.
HTTP character sets are identified by case-insensitive tokens. The
complete set of tokens is defined by the IANA Character Set registry
[19]. .
However, because that registry does not define a single, consistent
token for each character set, we define here the preferred names for
those character sets most likely to be used with HTTP entities. These
character sets include those registered by RFC 1521 [7] -- the US-ASCII [21]
and ISO-8859 [22] character sets -- and other names specifically recommended
for use within MIME charset parameters.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24] 21]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7"
| "UNICODE-1-1-UTF-8" | token
registry [19] MUST represent the character set defined by that registry.
Applications SHOULD limit their use of character sets to those defined
by the IANA registry.
_ _ is more commonly
Although HTTP allows an arbitrary token to be used as a charset value, | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
any token that has a predefined value within the IANA Character Set Note: This use of
registry MUST represent the term character set
referred to as a _character encoding._ However, since HTTP and
MIME share the same registry, it is important defined by that registry.
Applications SHOULD limit their use of character sets to those defined
by the
terminology also be shared. IANA registry.
The character set of an entity body SHOULD be labeled as the lowest
common denominator of the character codes used within that body, with
the exception that no label is preferred over the labels US-ASCII or
ISO-8859-1.
3.5
7.5 Content Codings
Content coding values indicate an encoding transformation that has been
or can be applied to a resource. resource entity. Content codings are primarily
used to allow a document to be compressed or encrypted without losing
the identity of its underlying media type. Typically, the resource
entity is stored in this encoding and only decoded before rendering or
analogous usage.
content-coding = "gzip" | "x-gzip"
| "compress" | "x-compress" | token
Note: For historical reasons, HTTP applications SHOULD consider
_x-gzip_ "x-
gzip" and
_x-compress_ "x-compress" to be equivalent to _gzip_ "gzip" and _compress_, "compress",
respectively.
All content-coding values are case-insensitive. HTTP/1.1 uses content-
coding values in the Accept-Encoding (Section 10.3) (section 18.3) and
Content-Encoding
(Section 10.10)
(section 18.13) header fields. Although the value describes the
content-
coding, what is more important is that it indicates what decoding
mechanism will be required to remove the encoding. Note that a single
program MAY be capable of decoding multiple content-coding formats. Two
values are defined by this specification:
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
gzip
An encoding format produced by the file compression program _gzip_ "gzip"
(GNU zip) developed by Jean-loup Gailly[25]. Gailly. This format is typically a
Lempel-Ziv coding (LZ77) with a 32 bit CRC.
compress
The encoding format produced by the file compression program
_compress_.
"compress". This format is an adaptive Lempel-Ziv-Welch coding
(LZW).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
Note: Use of program names for the identification of encoding
formats is not desirable and should be discouraged for future
encodings. Their use here is representative of historical practice,
not good design.
HTTP defines a registration process which uses the Internet Assigned
Numbers Authority (IANA) as a central registry for content-coding value
tokens. Additional content-coding value tokens beyond the four defined
in this document (gzip x-gzip compress x-compress) SHOULD be registered
with the IANA. To allow interoperability between clients and servers,
specifications of the content coding algorithms used to implement a new
value SHOULD be publicly available and adequate for independent
implementation, and MUST conform to the purpose of content coding
defined in this section.
3.6
7.6 Transfer Codings
Transfer coding values are used to indicate an encoding transformation
that has been, can be, or may need to be applied to an Entity-Body in
order to ensure safe transport through the network. This differs from a
content coding in that the transfer coding is a property of the
message,
not of the original resource. resource entity.
transfer-coding = "chunked" | transfer-extension
transfer-extension = token
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
coding values in the Transfer-Encoding header field (Section 10.39). (section 18.43).
Transfer codings are analogous to the Content-Transfer-Encoding values
of MIME [7], , which were designed to enable safe transport of binary data
over a 7-bit transport service. However, _safe transport_ "safe transport" has a
different focus for an 8bit-clean transfer protocol. In HTTP, the only
unsafe characteristic of message bodies is the difficulty in determining
the exact body length (Section 7.2.2), (section 11.2.2), or the desire to encrypt data
over a shared transport.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
All HTTP/1.1 applications MUST be able to receive and decode the
_chunked_
"chunked" transfer coding , and MUST ignore chunked transfer coding extensions
they do not understand. A server which receives a an entity-body with a
transfer-coding it does not understand SHOULD return
501(Unimplemented),
and close the connection. A server MUST NOT send transfer-codings to a
client that were not defined in the version of HTTP used in the client's
request. Clients sending entity-bodies with transfer-codings SHOULD must
be prepared for the connection to be closed if the server doesn't
understand the transfer-coding. The chunked encoding modifies the body
of a message in order to transfer it as a series of chunks, each with
its own size indicator, followed by an optional footer containing
entity-header fields. This allows dynamically-produced content to be
transferred along with the information necessary for the recipient to
verify that it has received the full message.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
chunk-size = hex-no-zero *HEX
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
footer = *< Content-MD5 *<<Content-MD5 and future headers that specify
they are allowed in footer>>
hex-no-zero = <HEX excluding "0">
Note that the chunks are ended by a zero-sized chunk, followed by the
footer and terminated by an empty line. An example process for decoding
a Chunked-Body is presented in Appendix C.5.
3.7 appendix 23.3.6.
7.7 Media Types
HTTP uses Internet Media Types [17] in the Content-Type (Section 10.15) (section 18.19) and
Accept (Section 10.1) (section 18.1) header fields in order to provide open and
extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Parameters may follow the type/subtype in the form of attribute/value
pairs.
parameter = attribute "=" value
attribute = token
value = token | quoted-string
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. LWS MUST NOT be generated between the
type and subtype, nor between an attribute and its value. Upon receipt
of a media type with an unrecognized parameter, a user agent SHOULD
treat the media type as if the unrecognized parameter and its value were
not present.
Some older HTTP applications do not recognize media type parameters.
HTTP/1.1 applications SHOULD only use media type parameters when they
are necessary to define the content of a message.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
Media-type values are registered with the Internet Assigned Number
Authority (IANA [19]). ). The media type registration process is outlined in
RFC 1590 [17]. . Use of non-registered media types is discouraged.
3.7.1
7.7.1 Canonicalization and Text Defaults
Internet media types are registered with a canonical form. In general,
an Entity-Body transferred via HTTP MUST be represented in the
appropriate canonical form prior to its transmission. If transmission; the body has
been encoded with a Content-Encoding, exception is
"text" types, as defined in the underlying data SHOULD be next paragraph..
when in canonical form prior to being encoded.
Media , media subtypes of the _text_ "text" type use CRLF as
the text line break when
in canonical form. break. However, HTTP allows the transport of text media
with plain CR or LF alone representing a line break when used if it is done
consistently
within the Entity-Body. for an entire Entity-Body.. HTTP applications MUST accept
CRLF, bare CR, and bare LF as being representative of a line break in
text media received via HTTP.
In HTTP.In addition, if the text media is
represented in a character set that does not use octets 13 and 10 for CR
and LF respectively, as is the case for some multi-byte character sets,
HTTP allows the use of whatever octet sequences are defined by that
character set to represent the equivalent of CR and LF for line breaks.
This flexibility regarding line breaks applies only to text media in the
Entity-Body; a bare CR or LF
SHOULD MUST NOT be substituted for CRLF within any
of the HTTP control structures (such as header fields and multipart
boundaries).
If an Entity-Body is encoded with a Content-Encoding, the underlying
data MUST be in a form defined above prior to being encoded.
The _charset_ "charset" parameter is used with some media types to define the
character set (Section 3.4) (section 7.4) of the data. When no explicit charset
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
parameter is provided by the sender, media subtypes of the _text_ "text" type
are defined to have a default charset value of _ISO-8859-1_ "ISO-8859-1" when
received via HTTP. Data in character sets other than _ISO-8859-1_ "ISO-8859-1" or its
subsets MUST be labeled with an appropriate charset value in order to be
consistently interpreted by the recipient.
Note: Many current HTTP servers provide data using charsets other
than _ISO-8859-1_ "ISO-8859-1" without proper labeling. This situation reduces
interoperability and is not recommended. To compensate for this,
some HTTP user agents provide a configuration option to allow the
user to change the default interpretation of the media type
character set when no charset parameter is given.
3.7.2
7.7.2 Multipart Types
MIME provides for a number of _multipart_ "multipart" types -- encapsulations of one
or more entities within a single message's Entity-Body. All multipart
types share a common syntax, as defined in Section section 7.2.1 of RFC 1521 [7] ,
and MUST include a boundary parameter as part of the media type value.
The message body is itself a protocol element and MUST therefore use
only CRLF to represent line breaks between body-parts. Unlike in RFC
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
1521, the epilogue of any multipart message MUST be empty; HTTP
applications MUST NOT transmit the epilogue even if the original
resource entity contains an epilogue.
In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part.
In general, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type. If
an application receives an unrecognized multipart subtype, the
application MUST treat it as being equivalent to _multipart/mixed_. "multipart/mixed".
Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST request
method, as described in RFC 1867 [15].
3.8 .
7.8 Product Tokens
Product tokens are used to allow communicating applications to identify
themselves via a simple product token, with an optional slash and
version designator. Most fields using product tokens also allow sub-
products which form a significant part of the application to be listed,
separated by whitespace. By convention, the products are listed in order
of their significance for identifying the application.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
product = token ["/" product-version]
product-version = token
Examples:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Product tokens SHOULD should be short and to the point -- use of them for
advertising or other non-essential information is explicitly forbidden.
Although any token character may appear in a product-version, this token
SHOULD only be used for a version identifier (i.e., successive versions
of the same product SHOULD only differ in the product-version portion of
the product value).
3.9
7.9 Quality Values
HTTP content negotiation (Section 12) (section 15) uses short _floating point_ "floating point"
numbers to indicate the relative importance (_weight_) ("weight") of various
negotiable parameters. The weights are normalized to a real number in
the range 0 through 1, where 0 is the minimum and 1 the maximum value.
In order to discourage misuse of this feature, HTTP/1.1 applications
MUST not NOT generate more than three digits after the decimal point. User
configuration of these values SHOULD also be limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "." 0*3DIGIT )
| ( "1" [ "." 0*3("0") ] )
_Quality values_
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
"Quality values" is a slight misnomer, since these values actually
measure relative degradation in perceived quality. Thus, a value of
_0.8_
"0.8" represents a 20% degradation from the optimum rather than a
statement of 80% quality.
3.10
7.10 Language Tags
A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information to
other human beings. Computer languages are explicitly excluded. HTTP
uses language tags within the Accept-Language, and Content-Language
fields.
The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [1]. . In summary, a language tag is composed of 1 or
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
more parts: A primary language tag and a possibly empty series of
subtags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Whitespace is not allowed within the tag and all tags are case-
insensitive. The namespace name space of language tags is administered by the
IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
where any two-letter primary-tag is an ISO 639 language abbreviation and
any two-letter initial subtag is an ISO 3166 country code. The (The last
three tags above are not registered tags, tags; all but the last are examples
of tags which could be registered in future.
3.12 Full Date Values
Contents moved to section 3.3.
3.13 Opaque Validators
Opaque validators future.)
7.11 Entity Tags
Entity tags are quoted strings whose internal structure is not visible
to clients or caches.
opaque-validator Entity tags are used as cache validators in
HTTP/1.1.
entity-tag = strong-opaque-validator strong-entity-tag | weak-opaque-validator weak-entity-tag
| null-validator
strong-opaque-validator null-entity-tag
strong-entity-tag = quoted-string
weak-opaque-validator
weak-entity-tag = quoted-string "/W"
null-validator
null-entity-tag = <"> <">
Note that the _/W_ "/W" tag is considered part of a weak opaque
validator; entity tag; it
MUST NOT be removed by any cache or client.
There are two comparison functions on opaque validators:
. The strong comparison function: in order to be considered equal,
both validators must be identical in every way, and neither may be
weak.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
. The weak comparison function: in order to be considered equal, both
validators must be identical in every way, except for the presence
or absence of a _weak_ "weak" tag.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
The weak comparison function MAY be used for simple (non-subrange) GET
requests. The strong comparison function MUST be used in all other
cases.
The null validator is a special value, defined as never matching the
current validator of an existing resource, resource entity, and always matching
the
_current_ "current" validator of a resource entity that does not exist.
3.14
7.12 Variant IDs
Variant-IDs are used to identify specific entities (variants)
A cache stores instances of resource entities, not instances of generic
resources per se. Therefore, the URI of a
varying resource; see section 13.8.3 for how they are used.
variant-id = quoted-string
Variant-IDs are compared using string octet-equality; case generic resource is
significant.
3.15 Validator Sets
Validator sets are used not
sufficient for doing conditional retrievals on varying
resources; see section 13.8.4.
validator-set = 1#validator-set-item
validator-set-item = opaque-validator
3.16 Variant Sets
Validator sets are used use as an identifier for doing conditional retrievals on varying
resources; see section 13.8.3.
variant-set = 1#variant-set-item
variant-set-item = opaque-validator ";" variant-id
3.17 HTTP Protocol Parameters Related to Ranges
This section defines a specific resource entity. In
certain interactions between a cache and an origin server, it is
convenient to encode that identifier using a more compact
representation than the full set of selecting request headers (which may
not even be possible if the selection criteria are not known to the
cache).
For these reasons, the HTTP protocol provides an optional mechanism for
identifying a specific entity source of a generic resource, called a
variant-ID.
Variant-IDs are used to identify specific variants of a generic
resource; see section 16.5.3 for how they are used.
variant-id = quoted-string
Variant-IDs are compared using string octet-equality; case is
significant.
All responses from generic resources SHOULD include variant-IDs. If
these are not present, the resource author can expect caches to
correctly handle requests on the generic resource, but cannot expect the
caching to be efficient.
7.13 Variant Sets
Validator sets are used for doing conditional retrievals on generic
resources; see section 16.5.3.
variant-set = 1#variant-set-item
variant-set-item = opaque-validator ";" variant-id
7.14 Range Protocol Parameters
This section defines certain HTTP protocol parameters used in range
requests and related responses.
3.17.1SLUSHY
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
7.14.1 Range Units
A resource entity may be broken down into subranges according to various
structural units.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
range-unit = bytes-unit | other-range-unit
bytes-unit = "bytes"
other-range-unit = token
The only range unit defined by HTTP/1.1 is . "bytes". HTTP/1.1 range-unit = bytes-unit other-range-unit _bytes_
implementations may ignore ranges specified using other units. other-
range-unit = token
3.17.2 SLUSHY
7.14.2 Byte Ranges
Since all HTTP entities are represented in HTTP messages as sequences of
bytes, the concept of a byte range is meaningful for any HTTP entity.
(However, not all clients and servers need to support byte-range
operations.)
Byte range specifications in HTTP apply to the sequence of bytes that
would be transferred by the protocol if no transfer-encoding transfer-coding were being
applied.
This means that if Content-encoding Content-coding is applied to the data, the byte
range specification applies to the resulting content-
encoded content-encoded byte
stream, not to the unencoded byte stream. It also means that if
the entity-body's media-type is a composite type (e.g., multipart/*
and message/rfc822), then the composite's body-parts may have their
own content-encoding and content-
transfer-encoding, content-transfer-encoding, and the byte
range applies to the result of the those encodings.
A byte range operation may specify a single range of bytes, or a set of
ranges within a single entity.
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
The first-byte-pos value in a byte-range-spec gives the byte-offset of
the first byte in a range. The last-byte-pos value gives the byte-
offset of the last byte in the range; that is, the byte positions
specified are inclusive. Byte offsets start at zero.
If the last-byte-pos value is present, it must be greater than or equal
to the first-byte-pos in that byte-range-spec, or the byte-range-spec is
invalid. The recipient of an invalid byte-range-spec must ignore it.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33] 29]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
If the last-byte-pos value is absent, it is assumed to be equal to the
current length of the entity in bytes.
If the last-byte-pos value is larger than the current length of the
entity, it is assumed to be equal to the current length of the entity.
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT
A suffix-byte-range-spec is used to specify the suffix of the entity, of
a length given by the suffix-length value. (That is, this form
specifies the last N bytes of an entity.) If the entity is shorter than
the specified suffix-length, the entire entity is used.
Examples of byte-ranges-specifier values (assuming an entity of length
10000):
. The first 500 bytes (byte offsets 0-499, inclusive):
bytes=0-499
. The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999
. The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500
. Or
bytes=9500-
. The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1
. Several legal but not canonical specifications of the second 500
bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999
bytes=500-700,601-999
3.17.3 SLUSHY:
7.14.3 Content Ranges
When a server returns a partial response to a client, it must describe
both the extent of the range covered by the response, and the length of
the entire entity.
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP first-byte-pos "-"
last-byte-pos "/" entity-length
entity-length = 1*DIGIT
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34] 30]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Unlike byte-ranges-specifier values, a byte-content-range-spec may only
specify one range, and must contain absolute byte positions for both the
first and last byte of the range.
A byte-content-range-spec whose last-byte-pos value, value is less than its
first-byte-pos value, or whose entity-length value is less than or equal
to its last-byte-pos value, is invalid. The recipient of an invalid byte-
content-range-spec must
byte-content-range-spec MUST ignore it and any content transferred along
with it.
Examples of byte-content-range-spec values, assuming that the entity
contains a total of 1234 bytes:
. The first 500 bytes:
bytes 0-499/1234
. The second 500 bytes:
bytes 500-999/1234
. All except for the first 500 bytes:
bytes 500-1233/1234
. The last 500 bytes:
bytes 734-1233/1234
4.
8 HTTP Message
4.1
8.1 Message Types
HTTP messages consist of requests from client to server and responses
from server to client.
HTTP-message = Full-Request ; HTTP/1.1 messages
| Full-Response
| NULL-Request
A NULL-Request (an empty line where a request would normally be
expected) MUST be ignored. Clients SHOULD NOT send a NULL-Request, but
there are some error and testing circumstances in which a NULL-Request
might be sent by mistake and MUST NOT cause failure on the server.
NULL-Request = CRLF
Full-Request and Full-Response use the generic message format of RFC 822
[9]
for transferring entities. Both messages may include optional header
fields (also known as _headers_) "headers") and an entity body. The entity body is
separated from the headers by a null line (i.e., a line with nothing
preceding the CRLF).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
4.2
8.2 Message Headers
HTTP header fields, which include General-Header (Section 4.3), 8.3),
Request-
Header ( General-Header (Section 5.2), 9.2), Response-Header Section 6.2), (Section 10.2), and Entity-Header
(Section 7.1) 11.1) fields, follow the same generic format as that given in
Section 3.1 of RFC 822 [9]. . Each header field consists of a name followed
by a colon (":") and the field value. Field names are case-
insensitive. case-insensitive.
The field value may be preceded by any amount of LWS, though a single SP
is preferred. Header fields can be extended over multiple lines by
preceding each extra line with at least one SP or HT.
HTTP-header = field-name ":" [ field-value ] CRLF
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36] 31]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
HTTP-header = field-name ":" [ field-value ] CRLF
and consisting of either *TEXT or combinations
The order in which header fields with differing field names are received
_
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
The order in which header fields with differing field names are received
is not significant. However, it is good practice_ "good practice" to send General-
Header fields first, followed by Request-Header or Response-Header
fields, and ending with the Entity-Header fields.
Multiple HTTP-header fields with the same field-name may be present in a
message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It MUST be possible
to combine the multiple header fields into one _field-name: field-value_ "field-name:
field-value"
pair, without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. Thus,
the order in which multiple header fields with the same field-name are
received may be significant to the interpretation of the combined
field-
value.
4.3
8.3 General Header Fields
There are a few header fields which have general applicability for both
request and response messages, but which do not apply to the entity
being transferred. These headers apply only to the message being
transmitted.
General-Header = Cache-Control ; Section 10.8 18.10
| Connection ; Section 10.9 18.11
| Date ; Section 10.17 18.20
| Via ; Section 10.20 18.47
| Keep-Alive ; Section 10.24 23.5.2.5.1
| Pragma ; Section 10.29 18.34
| Upgrade ; Section 10.41 18.44
General header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
header fields may be given the semantics of general header fields if all
parties in the communication recognize them to be general header
fields.
Unrecognized header fields are treated as Entity-Header fields.
5.
9 Request
A request message from a client to a server includes, within the first
line of that message, the method to be applied to the resource, the
identifier of the resource, and the protocol version in use. For
backwards compatibility with the more limited HTTP/0.9 protocol, there
are two valid formats for an HTTP request:
Request = Full-Request
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
Full-Request = Request-Line ; Section 5.1 9.1
*( General-Header ; Section 4.3 8.3
| Request-Header ; Section 5.2 9.2
| Entity-Header ) ; Section 7.1 11.1
CRLF
[ Entity-Body ] ; Section 7.2
NULL-Request = CRLF
A NULL-Request MUST be ignored.
5.1 11.2
9.1 Request-Line Request = Full-Request | NULL-Request
The Request-Line begins with a method token, followed by the
Request-URI
and the protocol version, and ending with CRLF. The elements are
separated by SP characters. No CR or LF are allowed except in the final
CRLF sequence.
Request-Line = CRLF | Method SP Request-URI SP HTTP-Version CRLF
5.1.1
In the interest of robustness, HTTP/1.1 servers SHOULD ignore null
request lines (ones that comprise just CRLF). An HTTP/1.1 client MUST
NOT preface a request with CRLF.
9.1.1 Method
The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Method = "OPTIONS" ; Section 13.1
| "GET" ; Section 13.2
| "HEAD" ; Section 8.3 13.3
| "POST" ; Section 8.4 13.4
| "PUT" ; Section 8.5 13.5
| "DELETE" ; Section 13.6
| "TRACE" ; Section 8.12 13.7
| extension-method
extension-method = token
The list of methods acceptable by a specific plain resource can be specified in
an Allow ). header field (section 18.7). However, the client is always Section 8.1 Section 8.2 in an header field (Section 10.5
notified through the return code of the response whether a method is
currently allowed on a specific plain resource, as this can change dynamically.
Servers SHOULD return the status code 405 (method not allowed) if the
method is known by the server but not allowed for the requested
resource, and 501 (not implemented) if the method is unrecognized or not
implemented by the server. The list of methods known by a server can be
listed in a Public response header field
(Section 10.32). (section 18.37).
The methods GET and HEAD MUST be supported by all general-purpose
servers. Servers which provide Last-Modified dates for resources MUST
also support the conditional GET method. All other methods are
optional;
however, if the above methods are implemented, they MUST be implemented
with the same semantics as those specified in Section 8.
5.1.2 section 13.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
9.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) (section 7.2) and
identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, HTTP/1.1 servers MUST accept the absoluteURI form in
requests, even though HTTP/1.1 clients will not normally generate them.
Versions of HTTP after HTTP/1.1 may require absoluteURIs everywhere,
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
after HTTP/1.1 or later have become the dominant implementations.
The three options for Request-URI are dependent on the nature of the
request. The asterisk _*_ "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed when
the Method used does not necessarily apply to a resource. One example
would be
OPTIONS * HTTP/1.1
The absoluteURI form is only allowed to an origin server if the client
knows the server supports HTTP/1.1 or later. If the absoluteURI form is
used, any Host request-header included with the request MUST be ignored.
The absoluteURI form is required when the request is being made to a
proxy. The proxy is requested to forward the request and return the
response. If the request is GET or HEAD and a prior response is cached,
the proxy may use the cached message if service it passes any restrictions in
the Cache-Control from
a valid cache, and Expires header fields. return the response.. Note that the proxy MAY forward
the request on to another proxy or directly to the server specified by
the absoluteURI. In order to avoid request loops, a proxy MUST be able
to recognize all of its server names, including any aliases, local
variations, and the numeric IP address. An example Request-Line would
be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form
in requests, even though HTTP/1.1 clients will only generate them in
requests to proxies. The Host request-header field MUST be ignored in
requests using an absoluteURL as the Request-URI.
The most common form of Request-URI is that used to identify a resource
on an origin server or gateway. In this case, only case the absolute path of the
URI is MUST be transmitted (see Section 3.2.1, abs_path). 7.2.1, abs_path) as the Request-URI, and
the network location of the URI (net_loc) MUST be transmitted in a Host
header field.. For example, a client wishing to retrieve the resource
above directly from the origin server would create a TCP connection to
port 80 of the host _www.w3.org_ "www.w3.org" and send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1
Host:www.w3.org
followed by the remainder of the Full-Request. Note that the absolute
path cannot be empty; if none is present in the original URI, it MUST be
given as _/_ "/" (the server root).
If a proxy receives a request without any path in the Request-URI and
the method used specified is capable of supporting the asterisk form of
request, then the last proxy on the request chain MUST forward the
request with
_*_ "*" as the final Request-URI. For example, the request
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
would be forwarded by the proxy as
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40] 34]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
would be forwarded by the proxy as
OPTIONS * HTTP/1.1
_www.ics.uci.edu_.
is transmitted as an encoded string, where some
Host: www.ics.uci.edu:8001
after connecting to port 8001 of host "www.ics.uci.edu".
The Request-URI is transmitted as an encoded string, where some
characters may be escaped using the _% "% HEX HEX_ HEX" encoding defined by RFC
1738 [4]. . The origin server MUST decode the Request-URI in order to
properly interpret the request. In requests that they forward, proxies
MUST NOT rewrite the _abs_path_ "abs_path" part of a Request-URI in any way except
as noted above to replace a null abs_path with _*_. "*". Illegal
Request-URIs
SHOULD be responded to with an appropriate status code. (Proxies Proxies MAY
transform the Request-URI for internal processing purposes, but SHOULD
NOT send such a transformed Request-URI in forwarded requests.
Transformations for use in cache updates and lookups are subject to
additional requirements; see section 13 on caching.
The main reason for this rule is to make sure that the form of Request-URIs
Request-URI is well specified, to enable future extensions without
fear that they will break in the face of some rewritings. Another
is that one consequence of rewriting the Request-URI is that
integrity or authentication checks by the server may fail; since
rewriting MUST be avoided in this case, it may as well be
proscribed in general.
Note: servers writers SHOULD Implementers should be aware that some existing pre-
HTTP/1.1 proxies do some rewriting.
5.2
9.2 The Resource Identified by a Request
HTTP/1.1 origin servers SHOULD be aware that the exact resource
identified by an Internet request is determined by examining both the
Request-URI and the Host header field. An origin server that does not
allow resources to differ by the requested host MAY ignore the Host
header field. An origin server that does differentiate resources based
on the host requested (sometimes referred to as virtual hosts or vanity
hostnames) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:.
1. If Request-URI is an absoluteURI, the host is included in the
Request-URI. Any Host header field in the request MUST be
ignored.
2. If the Request-URI is not an absoluteURI, and the request includes
a Host header field, the host is determined by the Host header
field.
3. If the request-URI is not an absoluteURI and no Host header field
is present (or does not represent a valid host on that server),
the response MUST be a 400 (Bad Request) error message.
Recipients of an HTTP/1.0 request lacking a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what exact
resource is being requested.
9.3 Request Header Fields
The request header fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics
equivalent
to the parameters on a programming language method (procedure)
invocation.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41] 35]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
to the parameters on a programming language method (procedure)
invocation.
Request-Header = Accept ; Section 10.1 18.1
| Accept-Charset ; Section 10.2 18.2
| Accept-Encoding ; Section 10.3 18.3
| Accept-Language ; Section 10.4 18.4
| Authorization ; Section 10.6 18.8
| From ; Section 10.21 18.23
| Host ; Section 10.22 18.24
| If-Modified-Since ; Section 10.23 18.25
| If-Range ; Section 18.28
| Proxy-Authorization ; Section 10.31 18.36
| Range ; Section 10.33 18.38
| Referer ; Section 10.34 18.39
| User-Agent ; Section 10.43 18.45
| Max-Forwards ; Section 10.45 18.32
Request-Header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
header fields MAY be given the semantics of request header fields if all
parties in the communication recognize them to be request header
fields.
Unrecognized header fields are treated as Entity-Header fields.
6.
10 Response
After receiving and interpreting a request message, a server responds in
the form of an HTTP response message.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Response = Full-Response
Full-Response = Status-Line ; Section 6.1 10.1
*( General-Header ; Section 4.3 8.3
| Response-Header ; Section 6.2 10.2
| Entity-Header ) ; Section 7.1 11.1
CRLF
[ Entity-Body ] ; Section 7.2
6.1 11.2
10.1 Status-Line
The first line of a Full-Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP
characters.
No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1
10.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the attempt of the protocol version followed by a numeric status code and its The Status-Code
to understand and satisfy the request. The Reason-Phrase is intended to
give a short textual description of the Status-Code. The Status-Code is
intended for use by automata and the Reason-Phrase is intended for the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
human user. The client is not required to examine or display the
Reason-
Phrase.
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5 values
for the first digit:
. 1xx: Informational - Request received, continuing process
. 2xx: Success - The action was successfully received, understood,
and accepted
. 3xx: Redirection - Further action must be taken in order to
complete the request
. 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
. 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for HTTP/1.1,
and an example set of corresponding Reason-Phrase's, are presented
below. The reason phrases listed here are only recommended -- they may
be replaced by local equivalents without affecting the protocol. These
codes are fully defined in Section 9.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996 section 12.
Status-Code = "100" ; Continue
| "101" ; Switching Protocols
| "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "203" ; Non-Authoritative Information
| "204" ; No Content
| "205" ; Reset Content
| "206" ; Partial Content
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request URI Too Large
| "415" ; Unsupported Media Type
| "416" ; None Acceptable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible. HTTP applications are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an unrecognized
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
response MUST not NOT be cached. For example, if an unrecognized status code
of 431 is received by the client, it can safely assume that there was
something wrong with its request and treat the response as if it had
received a 400 status code. In such cases, user agents SHOULD present to
the user the entity returned with the response, since that entity is
likely to include human-readable information which will explain the
unusual status.
6.2
10.2 Response Header Fields
The response header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to the resource identified by the Request-URI.
Response-Header = Location ; Section 10.27 18.31
| Proxy-Authenticate ; Section 10.30 18.35
| Public ; Section 10.32 18.37
| Retry-After ; Section 10.36 18.40
| Server ; Section 10.37 18.41
| WWW-Authenticate ; Section 10.44 18.46
Response-Header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
header fields MAY be given the semantics of response header fields if
all parties in the communication recognize them to be response header
fields. Unrecognized header fields are treated as Entity-Header fields.
7.
11 Entity
Full-Request and Full-Response messages MAY transfer an entity within
some requests and responses. An entity consists of Entity-Header fields
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
and (usually) an Entity-Body. In this section, both sender and recipient
refer to either the client or the server, depending on who sends and who
receives the entity.
7.1
11.1 Entity Header Fields
Entity-Header fields define optional metainformation about the Entity-
Body or, if no body is present, about the resource identified by the
request.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Entity-Header = Allow ; Section 10.5 18.7
| Content-Base ; Section 10.9 18.12
| Content-Encoding ; Section 10.10 18.3
| Content-Language ; Section 10.11 18.14
| Content-Length ; Section 10.12 18.15
| Content-Location ; Section 10.16 18.16
| Content-MD5 ; Section 10.13 0
| Content-Range ; Section 10.14 18.18
| Content-Type ; Section 10.15 18.19
| Expires ; Section 10.19 18.22
| Last-Modified ; Section 10.25 18.30
| Title ; Section 10.38 18.42
| Transfer-Encoding ; Section 10.39 18.43
| extension-header
extension-header = HTTP-header
The extension-header mechanism allows additional Entity-Header fields to
be defined without changing the protocol, but these fields cannot be
assumed to be recognizable by the recipient. Unrecognized header fields
SHOULD be ignored by the recipient and forwarded by proxies.
7.2
11.2 Entity Body
The entity body (if any) sent with an HTTP request or response is in a
format and encoding defined by the Entity-Header fields.
Entity-Body = *OCTET
An entity body is MUST ONLY be included with a request message only when the
request method calls for one. The presence of an entity body in a
request is signaled by the inclusion of a Content-Length and/or Content-Type
Content-
Type header field in the request message headers.
For response messages, whether or not an entity body is included with a
message is dependent on both the request method and the response code.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
All responses to the HEAD request method MUST not NOT include a body, even
though the presence of entity header fields may lead one to believe they
do. All 1xx (informational), 204 (no content), and 304 (not modified)
responses MUST not NOT include a body. All other responses MUST include an
entity body or a Content-Length header field defined with a value of
zero (0).
7.2.1
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
11.2.1 Type
When an entity body is included with a message, the data type of that
body is determined via the header fields Content-Type,
Content-Encoding,
and Transfer-Encoding. These define a three-layer, ordered encoding
model:
entity-body :=
Transfer-Encoding( Content-Encoding( Content-Type( data ) ) )
The default for both encodings is none (i.e., the identity function).
Content-Type specifies the media type of the underlying data. Content-
Encoding may be used to indicate any additional content codings applied
to the type, usually for the purpose of data compression, that are a
property of the resource entity requested. Transfer-Encoding may be
used to indicate any additional transfer codings applied by an
application to ensure safe and proper transfer of the message. Note that Transfer-
Encoding
Transfer-Encoding is a property of the message, not of the resource. resource
entity.
Any HTTP/1.1 message containing an entity body SHOULD include a
Content-
Type header field defining the media type of that body. If and only if
the media type is not given by a Content-Type header, the recipient may
attempt to guess the media type via inspection of its content and/or the
name extension(s) of the URL used to identify the resource. If the media
type remains unknown, the recipient SHOULD treat it as type
_application/octet-stream_.
7.2.2
"application/octet-stream".
11.2.2 Length
When an entity body is included with a message, the length of that body
may be determined in one of several ways. If a Content-Length header
field is present, its value in bytes represents the length of the entity
body. Otherwise, the body length is determined by the Transfer-Encoding
(if the _chunked_ "chunked" transfer coding has been applied) or by the server
closing the connection.
Note: Any response message which MUST NOT include an entity body
(such as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity header fields present in
the message.
Closing the connection cannot be used to indicate the end of a request
body, since it leaves no possibility for the server to send back a
response. For compatibility with HTTP/1.0 applications, HTTP/1.1
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
requests containing an entity body MUST include a valid Content-Length
header field unless the server is known to be HTTP/1.1 compliant.
HTTP/1.1 servers MUST accept the _chunked_ "chunked" transfer coding (Section 3.6
), (section
7.6), thus allowing this mechanism to be used for a request when Content-
Length
Content-Length is unknown.
If a request contains an entity body and Content-Length is not
specified, the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the request message's content, or with 411
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
(length required) if it wishes to insist on receiving a valid Content-
Length.
Messages MUST NOT include both a Content-Length header field and the
_chunked_
"chunked" transfer coding. If both are received, the Content-Length MUST
be ignored.
When a Content-Length is given in a message where an entity body is
allowed, its field value MUST exactly match the number of OCTETs in the
entity body. HTTP/1.1 user agents MUST notify the user when an invalid
length is received and detected.
8. Method
12 Status Code Definitions
The set of common methods for HTTP/1.1
Each Status-Code is defined below. Although this
set described below, including a description of which
method(s) it can be expanded, additional methods cannot be assumed to share the
same semantics for separately extended clients follow and servers.
The Host request-header field (Section 10.22) MUST accompany all
HTTP/1.1 requests.
8.1 OPTIONS
The OPTIONS method represents a request for information about the
communication options available on the request/response chain identified
by any metainformation required in the Request-URI.
response.
12.1 Informational 1xx
This method allows the client to determine the
options and/or requirements associated with a resource, or the
capabilities class of status code indicates a server, without implying a resource action or
initiating a resource retrieval.
Unless provisional response, consisting
only of the server's response Status-Line and optional headers, and is terminated by an error, the response
empty line. Since HTTP/1.0 did not define any 1xx status codes, servers
MUST NOT include
entity information other than what can be considered as communication
options (e.g., Allow is appropriate, but Content-Type is not) and MUST
include send a Content-Length 1xx response to an HTTP/1.0 client except under
experimental conditions.
12.1.1.1 100 Continue
The client may continue with a value of zero (0). Responses its request. This interim response is used
to this
method are not cachable.
If inform the Request-URI is an asterisk (_*_), client that the initial part of the OPTIONS request is intended
to apply to has been
received and has not yet been rejected by the server as a whole. A 200 response server. The client SHOULD include any
header fields which indicate optional features implemented
continue by sending the remainder of the server
(e.g., Public), including any extensions not defined by this
specification, in addition to any applicable general or response header
fields. As described in Section 5.1.2, an _OPTIONS *_ request can be
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
applied through a proxy by specifying or, if the destination request has
already been completed, ignore this response. The server in the
Request-URI without any path information.
If the Request-URI is not an asterisk, MUST send a
final response after the OPTIONS request applies only has been completed.
12.1.1.2 101 Switching Protocols
The server understands and is willing to the options that are available when communicating comply with that resource.
A 200 response SHOULD include any the client's
request, via the Upgrade message header fields which indicate optional
features implemented by field (section 18.44), for a
change in the application protocol being used on this connection. The
server and applicable will switch protocols to that resource
(e.g., Allow), including any extensions not those defined by this
specification, in addition to any applicable general or response header
fields. If the OPTIONS request passes through a proxy, response's Upgrade
header field immediately after the proxy MUST
edit empty line which terminates the response 101
response.
The protocol should only be switched when it is advantageous to exclude those options known do so.
For example, switching to a newer version of HTTP is advantageous over
older versions, and switching to a real-time, synchronous protocol may
be unavailable
through advantageous when delivering resources that proxy.
8.2 GET use such features.
12.2 Successful 2xx
This class of status code indicates that the client's request was
successfully received, understood, and accepted.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
12.2.1.1 200 OK
The request has succeeded. The GET method means retrieve whatever information (in returned with the form of an
entity) response is identified by the Request-URI. If
dependent on the Request-URI refers to a
data-producing process, it is method used in the produced data which shall be returned request, as the follows:
GET
an entity corresponding to the requested resource is sent in the
response;
HEAD
the response MUST only contain the header information and not no Entity-
Body;
POST
an entity describing or containing the source text result of the process,
unless that text happens to be action;
TRACE
an entity containing the output of request message as received by the process.
The semantics end
server;
otherwise,
an entity describing the result of the GET method change action;
If the entity corresponds to a _conditional GET_ if resource, the
request message includes an If-Modified-Since response MAY include a
Content-Location header field. A
conditional GET method requests that field giving the identified actual location of that plain
resource be
transferred only if it for later reference.
12.2.1.2 201 Created
The request has been modified since the date given by the If-
Modified-Since header, as described fulfilled and resulted in Section 10.23. a new resource being
created. The conditional
GET method is intended to reduce unnecessary network usage by allowing
cached entities to newly created resource can be refreshed without requiring multiple requests or
transferring data already held referenced by the client.
The semantics URI(s)
returned in the entity of the GET method change to a _partial GET_ if response, with the request
message includes most specific URL for
the resource given by a Range Location header field. A partial GET requests that only
part of the identified The origin server SHOULD
create the resource before returning this status code. If the action
cannot be transferred, as described carried out immediately, the server MUST include in
Section 10.33. The partial GET method is intended to reduce unnecessary
network usage by allowing partially-retrieved entities to be completed
without transferring data already held by the client.
The
response to body a GET description of when the resource will be available;
otherwise, the server SHOULD respond with 202 (Accepted).
12.2.1.3 202 Accepted
The request may has been accepted for processing, but the processing has not
been completed. The request MAY or MAY NOT eventually be cachable if and only if acted upon, as
it meets
the requirements MAY be disallowed when processing actually takes place. There is no
facility for HTTP caching described in Section 13.
8.3 HEAD re-sending a status code from an asynchronous operation
such as this.
The HEAD method 202 response is intentionally non-committal. Its purpose is identical to GET except allow
a server to accept a request for some other process (perhaps a batch-
oriented process that is only run once per day) without requiring that
the user agent's connection to the server MUST not
return any Entity-Body in persist until the response. process is
completed. The metainformation contained in
the HTTP headers in entity returned with this response to a HEAD request SHOULD be identical to include an
indication of the information sent in response request's current status and either a pointer to a GET request. This method can be
used for obtaining metainformation about the resource identified by
status monitor or some estimate of when the
Request-URI without transferring user can expect the Entity-Body itself. This method is
often used for testing hypertext links for validity, accessibility, and
recent modification. request
to be fulfilled.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50] 42]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
12.2.1.4 203 Non-Authoritative Information
The response to a HEAD request may be cachable returned metainformation in the sense that Entity-Header is not the
information contained in definitive
set as available from the response may origin server, but is gathered from a local or
a third-party copy. The set presented MAY be used to update a previously
cached entity from that resource. If the new field values indicate that subset or superset of the cached entity differs from
original version. For example, including local annotation information
about the current resource (as would be
indicated by a change MAY result in Content-Length, Content-MD5, or Content-
Version), then a superset of the cache MUST discard metainformation known
by the cached entity.
There origin server. Use of this response code is no _conditional HEAD_ or _partial HEAD_ request analogous to
those associated with the GET method. If an If-Modified-Since and/or
Range header field not required and is included with a HEAD request, they SHOULD
only appropriate when the response would otherwise be
ignored.
8.4 POST 200 (OK).
12.2.1.5 204 No Content
The POST method is used to request that the destination server accept
the entity enclosed in has fulfilled the request as a but there is no new subordinate of the resource
identified by information to
send back. If the Request-URI in client is a user agent, it SHOULD NOT change its
document view from that which caused the Request-Line. POST request to be generated. This
response is designed primarily intended to allow input for actions to take place
without causing a uniform method change to cover the following functions:
. Annotation of existing resources;
. Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles;
. Providing a block of data, such as user agent's active document view. The
response MAY include new metainformation in the result of submitting a form
[5], of entity headers,
which SHOULD apply to a data-handling process;
. Extending a database through an append operation.
The actual function performed by the POST method document currently in the user agent's active
view.
The 204 response MUST NOT include an entity body, and thus is determined always
terminated by the first empty line after the header fields.
12.2.1.6 205 Reset Content
The server has fulfilled the request and is usually dependent on the Request-URI. The posted entity is
subordinate to that URI in user agent SHOULD reset the same way that a file is subordinate
document view which caused the request to a
directory containing it, a news article be generated. This response is subordinate
primarily intended to a newsgroup allow input for actions to
which it is posted, or take place via user
input, followed by a record clearing of the form in which the input is subordinate to a database.
For compatibility with HTTP/1.0 applications, all POST requests given so
that the user can easily initiate another input action. The response
MUST include a valid Content-Length header field unless the server is known
to be HTTP/1.1 compliant. When sending with a POST value of zero (0) and no entity
body.
12.2.1.7 206 Partial Content
The server has fulfilled the partial GET request for the resource. The
request to an HTTP/1.1
server, a client MUST use have included a valid Content-Length or Range header field (section 18.38)
indicating the _chunked_
Transfer-Encoding. desired range. The server SHOULD respond response MUST include a Content-Range
header field (section 18.18) indicating the range included with this
response. All entity header fields in the response MUST describe the
partial entity transmitted rather than what would have been transmitted
in a 400 (bad request)
message if it cannot determine full response. In particular, the length Content-Length header field in
the response MUST match the actual number of OCTETs transmitted in the request message's
content, or with 411 (length required) if it wishes to insist on
receiving a valid Content-Length.
A successful POST does not require
entity body. It is assumed that the entity client already has the complete
entity's header field data.
12.3 Redirection 3xx
This class of status code indicates that further action needs to be created as a
resource on
taken by the origin server or made accessible for future reference.
That is, user agent in order to fulfill the request. The action performed
required MAY be carried out by the POST user agent without interaction with
the user if and only if the method might not result used in a
resource that can be identified by a URI. In this case, either 200 (ok)
or 204 (no content) is the appropriate response status, depending on
whether second request is GET or not the response includes
HEAD. A user agent SHOULD NOT automatically redirect a request more than
5 times, since such redirections usually indicate an entity that describes the
result. infinite loop.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51] 43]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
If
12.3.1.1 300 Multiple Choices
This status code is reserved for future use by a resource has been created on the origin server, the response SHOULD
be 201 (created) and contain an entity (preferably of type _text/html_) planned content
negotiation mechanism. HTTP/1.1 user agents receiving a 300 response
which describes the status of the request and refers to the new
resource.
Responses to includes a Location header field can treat this method are not cachable. However, the 303 (see other) response can be used to direct as they
would treat a 303 (See Other) response. If no Location header field is
included, the user agent appropriate action is to retrieve a cachable
resource.
POST requests must obey display the entity transmission requirements set out enclosed in
section 8.4.1.
8.4.1 SLUSHY: Entity Transmission Requirements
The following rules apply to any method that is subject
the response to the two-phase
mechanism.
Upon receiving such user.
12.3.1.2 301 Moved Permanently
The requested resource has been assigned a method from an HTTP/1.1 (or later) client, an
HTTP/1.1 (or later) server immediately either respond with _100
Continue_ new permanent URI and continue any
future references to read from this resource SHOULD be done using one of the input stream, or respond with an
error status. If it responds
returned URIs. Clients with an error status, it MAY close the
transport (TCP) connection or it MAY continue link editing capabilities SHOULD
automatically re-link references to read and discard the
rest Request-URI to one or more of
the request. It MUST not perform new references returned by the requested action if
returns an error status.
HTTP/1.1 servers are encouraged to maintain persistent connections and
use TCP's flow control mechanisms to resolve temporary overloads, rather
than terminating connections with server, where possible. This response
is cachable unless indicated otherwise.
If the expectation that clients will
retry. The latter technique can exacerbate network congestion.
An HTTP/1.1 (or later) client doing new URI is a PUT-like method SHOULD monitor location, its URL MUST be given by the
network connection for an error status while Location
field in the response. Unless it is transmitting was a HEAD request, the body Entity-Body of
the request including any encoding mechanism used response SHOULD contain a short hypertext note with a hyperlink to transmit
the
body. new URI(s).
If the client sees an error status, 301 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the request
unless it SHOULD immediately cease
transmitting can be confirmed by the body. If user, since this might change the body
conditions under which the request was proceeded by issued.
Note: When automatically redirecting a Content-length
header, POST request after receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
12.3.1.3 302 Moved Temporarily
The requested resource resides temporarily under a different URI. Since
the redirection may be altered on occasion, the client MUST either close SHOULD continue
to use the connection or Request-URI for future requests. This response is only
cachable if indicated by a Cache-Control or Expires header field.
If the body new URI is
being sent using a Chunked encoding, use a 0 length chunk, to mark the
end of the message.
An HTTP/1.1 (or later) client location, its URL MUST be prepared to accept a 100 Continue
status followed given by a regular the Location
field in the response.
An HTTP/1.1 (or later) client that sees Unless it was a HEAD request, the connection close before
receiving any status from Entity-Body of
the server response SHOULD retry the request, but if it
does so, it MUST use the two-phase mechanism. In the two-phase
mechanism, the client first sends contain a short hypertext note with a hyperlink to
the request headers, then waits for new URI(s).
If the server 302 status code is received in response to respond with either a 100 Continue, in which case the
client SHOULD continue, request other than
GET or an error status, in which case HEAD, the client user agent MUST NOT continue and MUST close the connection if it has not already
completed sending automatically redirect the full request body including any encoding mechanism
used to transmit the body.
If
unless it can be confirmed by the client knows that user, since this might change the server is an HTTP/1.1 (or later) server,
because of
conditions under which the server protocol version returned with request was issued.
Note: When automatically redirecting a previous POST request after receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52] 44]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
on the same persistent connection [alternatively: within the past <N>
hours], it MUST wait for a response. If the client believes that
12.3.1.4 303 See Other
The response to the
server is request can be found under a 1.0 or earlier server, it different URI and
SHOULD continue transmitting
its request after waiting at least [5] seconds for be retrieved using a status response.
An HTTP/1.1 (or later) client GET method on that sees the connection close after
receiving a _100 Continue_ but before receiving any other status SHOULD
retry the request, and need not use the two-phase resource. This method (but MAY do so
if this simplifies
exists primarily to allow the implementation).
An HTTP/1.1 (or later) server that receives a request from output of a 1.0 (or
earlier) client MUST NOT transmit the _100 Continue_ response; it SHOULD
either wait for the request POST-activated script to be completed normally (thus avoiding an
interrupted request) or close
redirect the connection prematurely.
8.5 PUT user agent to a selected resource. The PUT method requests that the enclosed entity be stored under new resource is not
a update reference for the
supplied original Request-URI. If The 303 response is not
cachable, but the Request-URI refers response to an already existing
resource, the enclosed entity SHOULD second request MAY be considered as a modified version
of the one residing on the origin server. cachable.
If the Request-URI does not
point to an existing resource, and that new URI is capable of being defined
as a new resource location, its URL MUST be given by the requesting user agent, the origin server can
create Location
field in the resource with that URI. If response. Unless it was a new resource is created, the
origin server MUST inform the user agent via HEAD request, the 201 (created) response.
If an existing resource is modified, either Entity-Body of
the 200 (ok) or 204 (no
content) response codes SHOULD be sent contain a short hypertext note with a hyperlink to indicate successful completion
of
the request. new URI(s).
12.3.1.5 304 Not Modified
If the resource could client has performed a conditional GET request and access is
allowed, but the document has not be created or been modified with
the Request-URI, an appropriate error response SHOULD be given that
reflects the nature of the problem.
If since the request passes through a cache date and time
specified in the Request-URI identifies a
currently cached entity, that entity MUST be removed from If-Modified-Since field, the cache.
Responses to server MUST respond with
this method are status code and not cachable.
The fundamental difference between send an Entity-Body to the POST and PUT requests is
reflected client. Header
fields contained in the different meaning response SHOULD only include information which
is relevant to cache managers or which MAY have changed independently of
the Request-URI. The URI entity's Last-Modified date. Examples of relevant header fields
include: Date, Server, Content-Length, Content-MD5, Content-Version,
Cache-Control and Expires.
A cache SHOULD update its cached entity to reflect any new field values
given in a POST
request identifies the resource 304 response. If the new field values indicate that will handle the enclosed
cached entity as
an appendage. That differs from the current resource may entity (as would be
indicated by a data-accepting process, a gateway
to some other protocol, change in Content-Length, Content-MD5, or a separate entity that accepts annotations.
In contrast, Content-
Version), then the URI in a PUT request identifies cache MUST disregard the entity enclosed
with 304 response and repeat the
request -- the user agent knows what URI is intended without an If-Modified-Since field.
The 304 response MUST NOT include an entity body, and thus is always
terminated by the
server first empty line after the header fields.
12.3.1.6 305 Use Proxy
The requested resource MUST NOT attempt to apply be accessed through the request to some proxy given by the
Location field in the response. In other resource. words, this is a proxy
redirect.
12.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the client
seems to have erred. If the server desires that client has not completed the request be applied to when a different URI,
4xx code is received, it
MUST send SHOULD immediately cease sending data to the
server. Except when responding to a 301 (moved permanently) response; HEAD request, the user agent MAY then
make its own decision regarding server SHOULD
include an entity containing an explanation of the error situation, and
whether it is a temporary or not permanent condition. These status codes are
applicable to redirect any request method.
Note: If the request.
A single resource MAY be identified by many different URIs. For example,
an article may have a URI for identifying _the current version_ which client is
separate from sending data, server implementations using
TCP SHOULD be careful to ensure that the URI identifying each particular version. In this case,
a PUT request on a general URI may result in several other URIs being
defined by client acknowledges
receipt of the origin server. packet(s) containing the response prior to closing
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53] 45]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
For compatibility with HTTP/1.0 applications, all PUT requests MUST
include a valid Content-Length header field unless
the server is known
to be HTTP/1.1 compliant. When input connection. If the client continues sending a PUT request data to an HTTP/1.1
server, a client MUST use a valid Content-Length or the _chunked_
Transfer-Encoding. The
server SHOULD respond with a 400 (bad request)
message if it cannot determine after the length of close, the request message's
content, or with 411 (length required) if it wishes to insist on
receiving server's controller will send a valid Content-Length.
The actual method for determining how the resource is placed, and what
happens reset
packet to its predecessor, is defined entirely the client, which may erase the client's unacknowledged
input buffers before they can be read and interpreted by the origin server. If HTTP
application.
12.4.1.1 400 Bad Request
The request could not be understood by the entity being PUT was derived from an existing resource which
included a Content-Version header field, server due to malformed
syntax. The client SHOULD NOT repeat the new entity request without modifications.
12.4.1.2 401 Unauthorized
The request requires user authentication. The response MUST include a
Derived-From
WWW-Authenticate header field corresponding (section 18.46) containing a challenge
applicable to the value of requested resource. The client MAY repeat the original
Content-Version request
with a suitable Authorization header field. Multiple Derived-From values may be field (section 18.8). If the
request already included if Authorization credentials, then the entity was derived from multiple resources with Content-
Version information. Applications are encouraged to use these fields 401
response indicates that authorization has been refused for
constructing versioning relationships those
credentials. If the 401 response contains the same challenge as the
prior response, and resolving version conflicts.
PUT requests must obey the user agent has already attempted authentication
at least once, then the user SHOULD be presented the entity transmission requirements set out that was
given in the response, since that entity MAY include relevant diagnostic
information. HTTP access authentication is explained in section 8.4.1.
8.9 DELETE 14.
12.4.1.3 402 Payment Required
This code is reserved for future use.
12.4.1.4 403 Forbidden
The DELETE method requests that the origin server delete understood the resource
identified by request, but is refusing to fulfill it.
Authorization will not help and the Request-URI. This method MAY request SHOULD not be overridden by human
intervention (or other means) on repeated. If
the origin server. The client cannot be
guaranteed that request method was not HEAD and the operation server wishes to make public why
the request has not been carried out, even if fulfilled, it SHOULD describe the reason for
the refusal in the entity body. This status code returned from is commonly used when
the origin server indicates that does not wish to reveal exactly why the action request has been
completed successfully. However, the
refused, or when no other response is applicable.
12.4.1.5 404 Not Found
The server SHOULD has not indicate success
unless, at the time found anything matching the response Request-URI. No
indication is given, it intends to delete given of whether the
resource condition is temporary or move it permanent.
If the server does not wish to an inaccessible location.
A successful response make this information available to the
client, the status code 403 (Forbidden) can be used instead. The 410
(Gone) status code SHOULD be 200 (OK) used if the response includes server knows, through some
internally configurable mechanism, that an
entity describing the status, 202 (accepted) if the action old resource is permanently
unavailable and has not yet
been enacted, or 204 (no content) if no forwarding address.
12.4.1.6 405 Method Not Allowed
The method specified in the response Request-Line is OK but does not
include an entity.
If the request passes through a cache and allowed for the Request-URI identifies a
currently cached entity, that entity MUST be removed from resource
identified by the cache.
Responses to this method are not cachable.
8.12 TRACE Request-URI. The TRACE method is used to invoke response MUST include an Allow header
containing a remote, application-layer loop back
of the request message. The final recipient list of valid methods for the request SHOULD
reflect the message received back to the client as the entity body of a
200 (OK) response. The final recipient is either the origin server or
the first proxy or gateway to receive a Max-Forwards value of zero (0)
in the request (see Section 10.45). A TRACE request MUST NOT include an
entity body and MUST include a Content-Length header field with a value
of zero (0). requested resource.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54] 46]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
TRACE allows the client to see what is being received at the other end
of the request chain and use that data for testing or diagnostic
information.
12.4.1.7 406 Not Acceptable
The value of the Via header field (Section 10.20) is of
particular interest, since it acts as a trace of resource identified by the request chain. Use is only capable of generating
response entities which have content characteristics not acceptable
according to the Max-Forwards header field allows accept headers sent in the client request.
HTTP/1.1 servers are allowed to return responses which are not
acceptable according to limit the length
of accept headers sent in the request chain, which is useful for testing request. In some
cases, this may even be preferable to sending a chain 406 response. User
agents are encouraged to inspect the headers of proxies
forwarding messages in an infinite loop. incoming response to
determine if it is acceptable. If successful, the response is not acceptable, user
agents SHOULD contain the entire request message in interrupt the entity body, with a Content-Type receipt of _message/http_,
_application/http_, or _text/plain_. Responses to this method MUST NOT
be cached.
9. Status Code Definitions
Each Status-Code the response if doing so would
save network resources. If it is described below, including unknown whether an incoming response
would be acceptable, a description user agent SHOULD temporarily stop receipt of which
method(s) it can follow
more data and any metainformation required in query the
response.
9.1 Informational 1xx user for a decision on furtheractions.
12.4.1.8 407 Proxy Authentication Required
This class of status code is similar to 401 (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The proxy MUST
return a provisional response, consisting
only of Proxy-Authenticate header field (section 18.35) containing a
challenge applicable to the Status-Line and optional headers, and proxy for the requested resource. The client
MAY repeat the request with a suitable Proxy-Authorization header field
(section 18.36). HTTP access authentication is terminated by an
empty line. Since HTTP/1.0 explained in section 14.
12.4.1.9 408 Request Timeout
The client did not define any 1xx status codes, servers
MUST NOT send produce a 1xx response request within the time that the server was
prepared to an HTTP/1.0 client except under
experimental conditions.
100 Continue wait. The client may continue MAY repeat the request without
modifications at any later time.
12.4.1.10 409 Conflict
The request could not be completed due to a conflict with its request. the current
state of the resource. This interim response code is used
to inform the client only allowed in situations where it
is expected that the initial part of user MAY be able to resolve the request has been
received conflict and has not yet been rejected by
resubmit the server. request. The client response body SHOULD
continue by sending include enough
information for the remainder user to recognize the source of the request or, if conflict.
Ideally, the request has
already been completed, ignore this response. The server MUST send a
final response after the request has been completed.
101 Switching Protocols
The server understands entity would include enough information for the
user or user-agent to fix the problem; however, that MAY not be possible
and is willing not required.
Conflicts are most likely to comply with the client's
request, via the Upgrade message header field (Section 10.41), for a
change occur in the application protocol response to a PUT request. If
versioning is being used on this connection. The
server will switch protocols and the entity being PUT includes changes to a
resource which conflict with those defined made by an earlier (third-party)
request, the response's Upgrade
header field immediately after the empty line which terminates server MAY use the 101
response.
The protocol should only be switched when it is advantageous to do so.
For example, switching 409 response to indicate that it can't
complete the request. In this case, the response entity SHOULD contain a newer version
list of HTTP the differences between the two versions in a format defined by
the response Content-Type.
12.4.1.11 410 Gone
The requested resource is advantageous over
older versions, no longer available at the server and switching to a real-time, synchronous protocol may no
forwarding address is known. This condition SHOULD be advantageous when delivering resources that use such features. considered
permanent. Clients with link editing capabilities SHOULD delete
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55] 47]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
9.2 Successful 2xx
This class of status code indicates that
references to the client's request was
successfully received, understood, and accepted.
200 OK
The request Request-URI after user approval. If the server does
not know, or has succeeded. The information returned with no facility to determine, whether or not the response condition
is
dependent on permanent, the method status code 404 (Not Found) SHOULD be used in the request, as follows:
GET
an entity corresponding to the requested resource instead.
This response is sent in cachable unless indicated otherwise.
The 410 response is primarily intended to assist the
response;
HEAD task of web
maintenance by notifying the response MUST only contain recipient that the header information resource is
intentionally unavailable and no Entity-
Body;
POST
an entity describing or containing the result of that the action;
TRACE server owners desire that remote
links to that resource be removed. Such an entity containing event is common for limited-
time, promotional services and for resources belonging to individuals no
longer working at the request message server's site. It is not necessary to mark all
permanently unavailable resources as received by the end
server;
otherwise,
an entity describing "gone" or to keep the result mark for any
length of time -- that is left to the action;
If discretion of the entity corresponds server owner.
12.4.1.12 411 Length Required
The server refuses to a resource, accept the response request without a defined Content-
Length. The client MAY include repeat the request if it adds a
Content-Location valid Content-
Length header field giving containing the actual location length of that
specific resource for later reference.
201 Created
The request has been fulfilled and resulted in a new resource being
created. The newly created resource can be referenced by the URI(s)
returned entity body in the entity
request message.
12.4.1.13 412 Precondition Failed
The precondition given in one or more of the response, with request header fields
evaluated to false when it was tested on the most specific URL for server. This response code
allows the resource given by client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a Location header field. resource other than the one intended.
12.4.1.14 413 Request Entity Too Large
The server is refusing to process a request because it considers the
request entity to be larger than it is willing or able to process. The origin
server SHOULD
create close the resource before using this Status-Code. connection if that is necessary to prevent the
client from continuing the request.
If the action cannot
be carried out immediately, client manages to read the server 413 response, it MUST include in the response body
a description of when honor it and
SHOULD reflect it to the resource will be available; otherwise, user.
If this restriction is considered temporary, the server SHOULD respond with 202 (accepted).
202 Accepted
The request has been accepted for processing, but the processing has not
been completed. The request MAY or MAY NOT eventually be acted upon, as include a
Retry-After header field to indicate that it MAY be disallowed when processing actually takes place. There is no
facility for re-sending a status code from an asynchronous operation
such as this. temporary and after what
time the client MAY try again.
12.4.1.15 414 Request-URI Too Long
The 202 response server is intentionally non-committal. Its purpose refusing to service the request because the Request-URI is
longer than the server is willing to allow interpret. This rare condition is
only likely to occur when a server client has improperly converted a POST
request to accept a GET request for some other process (perhaps with long query information, when the client
has descended into a batch-
oriented process that is only run once per day) without requiring URL "black hole" of redirection (e.g., a redirected
URL prefix that
the user agent's connection points to a suffix of itself), or when the server persist until the process is
under attack by a client attempting to exploit security holes present in
some servers using fixed-length buffers for reading or manipulating the
Request-URI.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56] 48]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
completed.
12.4.1.16 415 Unsupported Media Type
The entity returned with this response SHOULD include an
indication of the request's current status and either a pointer server is refusing to a
status monitor or some estimate of when the user can expect service the request
to be fulfilled.
203 Non-Authoritative Information
The returned metainformation in the Entity-Header is not because the definitive
set as available from entity body of
the origin server, but request is gathered from a local or
a third-party copy. The set presented MAY be in a subset or superset of the
original version. For example, including local annotation information
about format not supported by the requested resource MAY result in a superset of for
the metainformation known
by requested method.
12.5 Server Error 5xx
Response status codes beginning with the origin server. Use of this response code is not required and is
only appropriate when digit "5" indicate cases in
which the response would otherwise be 200 (OK).
204 No Content
The server is aware that it has fulfilled the request but there erred or is no new information to
send back. incapable of
performing the request. If the client is a user agent, it SHOULD has not change its
document view from that which caused completed the request to be generated. This
response is primarily intended to allow input for actions to take place
without causing when
a change to the user agent's active document view. The
response MAY include new metainformation in the form of entity headers,
which 5xx code is received, it SHOULD apply immediately cease sending data to the document currently in
server. Except when responding to a HEAD request, the user agent's active
view.
The 204 response MUST not server SHOULD
include an entity body, containing an explanation of the error situation, and thus
whether it is always
terminated by the first empty line after the a temporary or permanent condition. These response codes
are applicable to any request method and there are no required header
fields.
205 Reset Content
12.5.1.1 500 Internal Server Error
The server has fulfilled the request and the user agent SHOULD reset the
document view encountered an unexpected condition which caused prevented it from
fulfilling the request to be generated. This response is
primarily intended to allow input for actions to take place via user
input, followed by a clearing of request.
12.5.1.2 501 Not Implemented
The server does not support the form in which functionality required to fulfill the input
request. This is given so
that the user can easily initiate another input action. The appropriate response
MUST include a Content-Length with a value of zero (0) and no entity
body.
206 Partial Content
The when the server has fulfilled does not
recognize the partial GET request method and is not capable of supporting it for the any
resource.
12.5.1.3 502 Bad Gateway
The
request MUST have included server, while acting as a Range header field (Section 10.33)
indicating gateway or proxy, received an invalid
response from the desired range. upstream server it accessed in attempting to fulfill
the request.
12.5.1.4 503 Service Unavailable
The response MUST include server is currently unable to handle the request due to a Content-Range
header field (Section 10.14) indicating temporary
overloading or maintenance of the range included with server. The implication is that this
response. All entity header fields in
is a temporary condition which will be alleviated after some delay. If
known, the response MUST describe length of the
partial entity transmitted rather than what would have been transmitted delay MAY be indicated in a full response. In particular, Retry-After
header.
If no Retry-After is given, the Content-Length header field in client SHOULD handle the response MUST match the actual number as it
would for a 500 response.
Note: The existence of OCTETs transmitted in the
entity body. It is assumed 503 status code does not imply that a
server must use it when becoming overloaded. Some servers MAY wish
to simply refuse the client already has connection.
12.5.1.5 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a timely
response from the upstream server it accessed in attempting to complete
entity's header field data.
the request.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57] 49]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
207 Range Out Of Bounds
12.5.1.6 505 HTTP Version Not Supported
The server has determined that the requested range(s) are does not present support, or refuses to support, the HTTP protocol
version that was used in the requested resource, and so there request message. The server is no content indicating
that it is unable or unwilling to return. This
status code should be handled by complete the client request using the same as 204 No Content.
This could be a compatibility problem if there is an installed
base. If treating this status code
major version as the generic 2xx code by
such implementations would lead to client, as described in section 7.1, other than
with this error message. The response SHOULD contain an error, it will have to be
replace entity
describing why that version is not supported and what other protocols
are supported by 204.
9.3 Redirection 3xx
This class of status code indicates that further action needs to server.
13 Method Definitions
The set of common methods for HTTP/1.1 is defined below. Although this
set can be
taken by the user agent in order expanded, additional methods cannot be assumed to fulfill share the request.
same semantics for separately extended clients and servers.
The action
required MAY be carried out by Host request-header field (section 18.24) MUST accompany all
HTTP/1.1 requests.
13.1 OPTIONS
The OPTIONS method represents a request for information about the user agent without interaction with
communication options available on the user if and only if request/response chain identified
by the Request-URI. This method used in allows the second request is GET client to determine the
options and/or requirements associated with a resource, or
HEAD. A user agent SHOULD NOT automatically redirect the
capabilities of a request more than
5 times, since such redirections usually indicate an infinite loop.
300 Multiple Choices
This status code is reserved for future use by server, without implying a planned content
negotiation mechanism. HTTP/1.1 user agents receiving resource action or
initiating a 300 resource retrieval.
Unless the server's response
which includes a Location header field can treat this is an error, the response MUST NOT include
entity information other than what can be considered as they
would treat communication
options (e.g., Allow is appropriate, but Content-Type is not) and MUST
include a 303 (See Other) response. Content-Length with a value of zero (0). Responses to this
method are not cachable.
If no Location header field the Request-URI is
included, an asterisk ("*"), the appropriate action OPTIONS request is intended
to display the entity enclosed in
the response apply to the user.
301 Moved Permanently
The requested resource has been assigned server as a new permanent URI and any
future references to this resource SHOULD be done using one of the
returned URIs. Clients with link editing capabilities whole. A 200 response SHOULD
automatically re-link references to include any
header fields which indicate optional features implemented by the Request-URI server
(e.g., Public), including any extensions not defined by this
specification, in addition to one any applicable general or more of
the new references returned by the server, where possible. This response
is cachable unless indicated otherwise.
If the new URI is a location, its URL MUST header
fields. As described in section 9.1.2, an "OPTIONS *" request can be given
applied through a proxy by specifying the Location
field destination server in the response. Unless it was a HEAD request, the Entity-Body of
the response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
Request-URI without any path information.
If the 301 status code Request-URI is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect not an asterisk, the OPTIONS request
unless it can be confirmed by the user, since this might change applies only
to the
conditions under options that are available when communicating with that
resource.
A 200 response SHOULD include any header fields which indicate optional
features implemented by the server and applicable to that resource
(e.g., Allow), including any extensions not defined by this
specification, in addition to any applicable general or response header
fields. If the OPTIONS request was issued.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into passes through a GET request.
302 Moved Temporarily proxy, the proxy MUST
edit the response to exclude those options known to be unavailable
through that proxy.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58] 50]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
13.2 GET
The requested resource resides temporarily under a different URI. Since
the redirection MAY be altered on occasion, the client SHOULD continue
to use GET method means retrieve whatever information (in the Request-URI for future requests. This response form of an
entity) is only
cachable if indicated identified by a Cache-Control or Expires header field. the Request-URI. If the new URI is Request-URI refers to a location, its URL MUST
data-producing process, it is the produced data which shall be given by returned
as the Location
field entity in the response. Unless it was a HEAD request, response and not the Entity-Body source text of the response SHOULD contain a short hypertext note with a hyperlink process,
unless that text happens to be the new URI(s).
If output of the 302 status code is received in response process.
The semantics of the GET method change to a "conditional GET" if the
request other than message includes an If-Modified-Since header field. A
conditional GET or HEAD, the user agent MUST NOT automatically redirect method requests that the request
unless it can identified resource entity be confirmed by the user,
transferred only if it has been modified since this might change the
conditions under which date given by the request was issued.
303 See Other
If-
Modified-Since header, as described in section 18.25. The response to the request can be found under a different URI and
SHOULD be retrieved using a conditional
GET method on that resource. This method
exists primarily is intended to allow reduce unnecessary network usage by allowing
cached entities to be refreshed without requiring multiple requests or
transferring data already held by the output client.
The semantics of a POST-activated script to
redirect the user agent GET method change to a selected resource. The new resource is not "partial GET" if the request
message includes a update reference for Range header field. A partial GET requests that only
part of the original Request-URI. identified resource entity be transferred, as described in
section 18.38. The 303 response partial GET method is not
cachable, but intended to reduce unnecessary
network usage by allowing partially-retrieved entities to be completed
without transferring data already held by the client.
The response to the second a GET request MAY may be cachable.
If cachable if and only if it meets
the new URI requirements for HTTP caching described in section 16.
13.3 HEAD
The HEAD method is a location, its URL MUST be given by identical to GET except that the Location
field server MUST NOT
return any Entity-Body in the response. Unless it was a HEAD request, the Entity-Body of The metainformation contained in
the HTTP headers in response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).
Note: When automatically redirecting a POST HEAD request after
receiving a 302 status code, some existing HTTP/1.0 user agents
will erroneously change it into SHOULD be identical to
the information sent in response to a GET request.
304 Not Modified
If This method can be
used for obtaining metainformation about the client has performed a conditional GET request and access is
allowed, but resource entity identified
by the document has not been modified since Request-URI without transferring the date Entity-Body itself. This
method is often used for testing hypertext links for validity,
accessibility, and time
specified recent modification.
The response to a HEAD request may be cachable in the If-Modified-Since field, the server MUST respond with
this status code and not send an Entity-Body to sense that the client. Header
fields
information contained in the response SHOULD only include information which
is relevant may be used to cache managers or which MAY have changed independently of
the entity's Last-Modified date. Examples of relevant header fields
include: Date, Server, Content-Length, Content-MD5, Content-Version,
Cache-Control and Expires.
A cache SHOULD update its a previously
cached entity to reflect any new field values
given in the 304 response. from that resource. If the new field values indicate that
the cached entity differs from the current resource entity (as would be
indicated by a change in Content-Length, Content-MD5, or Content-Version), Content-
Version), then the cache MUST disregard the 304 response and repeat mark the cache entry stale.
There is no "conditional HEAD" or "partial HEAD" request without analogous to
those associated with the GET method. If an If-Modified-Since field. and/or
Range header field is included with a HEAD request, they SHOULD be
ignored.
13.4 POST
The POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the resource
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59] 51]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
The 304 response MUST NOT include an entity body, and thus is always
terminated by the first empty line after the header fields.
305 Use Proxy
The requested resource MUST be accessed through the proxy given
identified by the
Location field Request-URI in the response. In other words, this is a proxy
redirect.
9.4 Client Error 4xx
The 4xx class of status code Request-Line. POST is intended for cases in which the client
seems designed to have erred. If the client has not completed the request when
allow a
4xx code is received, it SHOULD immediately cease sending data uniform method to cover the
server. Except when responding following functions:
. Annotation of existing resources;
. Posting a message to a HEAD request, the server SHOULD
include an entity containing an explanation bulletin board, newsgroup, mailing list, or
similar group of articles;
. Providing a block of data, such as the error situation, and
whether it is result of submitting a temporary or permanent condition. These status codes are
applicable form
, to any request method.
Note: If a data-handling process;
. Extending a database through an append operation.
The actual function performed by the client POST method is sending data, determined by the
server implementations and is usually dependent on
TCP SHOULD be careful the Request-URI. The posted entity is
subordinate to ensure that URI in the client acknowledges
receipt of the packet(s) same way that a file is subordinate to a
directory containing the response prior it, a news article is subordinate to
closing the input connection. If the client continues sending
data a newsgroup to
which it is posted, or a record is subordinate to a database.
For compatibility with HTTP/1.0 applications, all POST requests MUST
include a valid Content-Length header field unless the server after the close, the server's controller will
send is known
to be HTTP/1.1 compliant. When sending a reset packet POST request to an HTTP/1.1
server, a client MUST use a valid Content-Length or the client, which may erase the client's
unacknowledged input buffers before they can be read and
interpreted by the HTTP application.
400 Bad Request "chunked"
Transfer-Encoding. The request could not be understood by the server due to malformed
syntax. The client SHOULD not repeat respond with a 400 (bad request)
message if it cannot determine the length of the request without modifications.
401 Unauthorized
The request requires user authentication. The response MUST include message's
content, or with 411 (length required) if it wishes to insist on
receiving a
WWW-Authenticate header field (Section 10.44) containing valid Content-Length.
A successful POST does not require that the entity be created as a challenge
applicable to
resource on the requested resource. The client MAY repeat origin server or made accessible for future reference.
That is, the request
with action performed by the POST method might not result in a suitable Authorization header field (Section 10.6). If
resource that can be identified by a URI. In this case, either 200 (OK)
or 204 (no content) is the
request already included Authorization credentials, then appropriate response status, depending on
whether or not the 401 response indicates includes an entity that authorization describes the
result.
If a resource has been refused for those
credentials. If created on the origin server, the 401 response contains SHOULD
be 201 (Created) and contain an entity (preferably of type "text/html")
which describes the same challenge as status of the
prior response, request and refers to the user agent has already attempted authentication
at least once, then new
resource.
Responses to this method are not cachable. However, the user SHOULD 303 (See Other)
response can be presented used to direct the entity that was
given in user agent to retrieve a cachable
resource.
POST requests must obey the response, since that entity MAY include relevant diagnostic
information. HTTP access authentication is explained transmission requirements set out in Section 11.
402 Payment Required
This code is reserved for future use.
section 13.4.1.
13.4.1 SLUSHY: Entity Transmission Requirements
Editor's Note: The issues here around reliable transmission of large
entities to servers, particularly HTTP/1.0 servers, are complicated and
subtle, particularly since we'd like optimistic transmission to be the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60] 52]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
403 Forbidden
The server understood the request, but is refusing
normal situation. We would like it if we can redraft this section to fulfill it.
Authorization will not help and the request SHOULD not be repeated. If
simpler in the request method was not HEAD next draft
General requirements:
. HTTP/1.1 servers should maintain persistent connections and the server wishes use
TCP's flow control mechanisms to make public why resolve temporary overloads,
rather than terminating connections with the request has not been fulfilled, it expectation that
clients will retry. The latter technique can exacerbate network
congestion.
. An HTTP/1.1 (or later) client doing a PUT-like method SHOULD describe
monitor the reason network connection for
the refusal in the entity body. This an error status code while it is commonly used when
the server does not wish to reveal exactly why
transmitting the request has been
refused, or when no other response is applicable.
404 Not Found
The server has not found anything matching request. If the Request-URI. No
indication is given of whether client sees an error status, it
should immediately cease transmitting the condition is temporary or permanent. body. If the server does not wish to make this information available to the
client, the status code 403 (forbidden) can be used instead. The 410
(gone) status code SHOULD be body is
being sent using a "Chunked" encoding, a zero length chunk is used if
to mark the server knows, through some
internally configurable mechanism, that an old resource is permanently
unavailable and has no forwarding address.
405 Method Not Allowed
The method specified in end of the Request-Line is not allowed for message. If the resource
identified body was preceded by the Request-URI. The response MUST include an Allow header
containing a list of valid methods for
Content-length header, the requested resource.
406 Not Acceptable
The resource identified by client MUST close the request is only capable of generating
response entities which have content characteristics not acceptable
according connection.
. An HTTP/1.1 (or later) client MUST be prepared to the accept headers sent in the request. a "100
Continue" status followed by a regular response.
. An HTTP/1.1 servers are allowed to return responses which are not
acceptable according to (or later) server that receives a request from a
HTTP/1.0 (or earlier) client MUST NOT transmit the accept headers sent in 100 (continue)
response; it SHOULD either wait for the request. In some
cases, this may even request to be preferable over sending completed
normally (thus avoiding an interrupted request) or close the
connection prematurely.
Upon receiving a 406 response. User
agents are encouraged method subject to inspect the headers of these requirements from an incoming response HTTP/1.1
(or later) client, an HTTP/1.1 (or later) server MUST either immediately
respondwith 100 (continue) and continue to
determine if it is acceptable. read from the input stream,
or respond with an error status. If it responds with an error status,
it MAY close the response is not acceptable, user
agents SHOULD interrupt transport (TCP) connection or it MAY continue to read
and discard the receipt rest of the response request. It MUST NOT perform the requested
method if doing so would
save network resources. If it is unknown whether returns an incoming error status.
If an HTTP/1.1 client has seen an HTTP/1.1 or later response
would be acceptable, a user agent from the
server (clients SHOULD temporarily stop receipt remember the version number of
more data at least the most
recently used server), and query it sees the user for a decision on further
actions.
407 Proxy Authentication Required
This code is similar to 401 (unauthorized), but indicates that connection close before receiving
any status from the server, the client SHOULD retry the request. If the
client does retry the request,
. it MUST first authenticate itself with send the proxy. The proxy request headers,
. and then MUST
return a Proxy-Authenticate header field (Section 10.30) containing a
challenge applicable to the proxy wait for the requested resource. The client
MAY repeat the request server to respond with either a suitable Proxy-Authorization header field
(Section 10.31). HTTP access authentication is explained 100
(continue) response, in Section 11.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61]
INTERNET-DRAFT which case the client should continue, or
with an error status.
If an HTTP/1.1 Monday, April 22, 1996
408 Request Timeout
The client did has not produce a request within seen an HTTP/1.1 or later response from
the time server, it should assume that the server was
prepared to wait. The client MAY repeat implements HTTP/1.0 or
older and will not use the request without
modifications at 100 (Continue) response. If in this case the
client sees the connection close before receiving any later time.
409 Conflict
The request could not status from the
server, the client SHOULD retry the request. If the client does retry
the request, it should use the following "binary exponential backoff"
algorithm to be completed due assured of obtaining a reliable response:
1.
Initiate a new connection to the server
2.
Transmit the request headers
3.
Initialize a conflict with variable R to the current
state of estimated round-trip time to the resource. This code is only allowed in situations where it
is expected that
server (e.g., based on the user MAY be able time it took to resolve establish the conflict
Fielding, Frystyk, Berners-Lee, Gettys, and
resubmit Mogul [Page 53]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
connection), or to a constant value of 5 seconds if the round-trip
time is not available.
4.
Compute T = R * (2**N), where N is the number of previous retries
of this request. The response body SHOULD include enough
information
5.
Wait either for an error response from the user to recognize server, or for T seconds
(whichever comes first)
6.
If no error response is received, after T seconds transmit the source body
of the conflict.
Ideally, request.
7.
If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response entity would include enough information for is
received, or the user or user-agent becomes impatient.
No matter what the server version, if an error status is received,
. the client MUST NOT continue and
. MUST close the connection if it has not already completed sending
the full request body including any encoding mechanism used to fix
transmit the problem; however, body.
An HTTP/1.1 (or later) client that MAY not be possible sees the connection close after
receiving a 100 (continue) but before receiving any other status SHOULD
retry the request, and is need not required.
Conflicts are most likely to occur in wait for 100 (continue) response to a (but
MAY do so if this simplifies the implementation).
13.5 PUT request. If
versioning is being used and
The PUT method requests that the enclosed entity being PUT includes changes to a
resource which conflict with those made by an earlier (third-party)
request, be stored under the server MAY use
supplied Request-URI. If the 409 response Request-URI refers to indicate that it can't
complete the request. In this case, an already existing
resource, the response enclosed entity SHOULD contain be considered as a
list modified version
of the differences between one residing on the two versions in a format origin server. If the Request-URI does not
point to an existing resource, and that URI is capable of being defined
as a new resource by the response Content-Type.
410 Gone
The requested requesting user agent, the origin server can
create the resource with that URI. If a new resource is no longer available at created, the
origin server and no
forwarding address MUST inform the user agent via the 201 (created)
response.
If an existing resource is known. This condition modified, either the 200 (OK) or 204 (No
Content) response codes SHOULD be considered
permanent. Clients with link editing capabilities SHOULD delete
references sent to indicate successful completion
of the Request-URI after user approval. request. If the server does resource could not know, or has no facility to determine, whether be created or not the condition
is permanent, modified with
the status code 404 (not found) Request-URI, an appropriate error response SHOULD be used instead.
This response is cachable unless indicated otherwise.
The 410 response is primarily intended to assist given that
reflects the task nature of web
maintenance by notifying the recipient that problem.
If the resource is
intentionally unavailable request passes through a cache and that the server owners desire that remote
links to Request-URI identifies a
currently cached entity, that resource entity MUST be removed. Such an event is common for limited-
time, promotional services and for resources belonging to individuals no
longer working at removed from the server's site. It is not necessary to mark all
permanently unavailable resources as _gone_ or cache.
Responses to keep this method are not cachable.
The fundamental difference between the mark for any
length of time -- that POST and PUT requests is left to
reflected in the discretion different meaning of the server owner.
411 Length Required Request-URI. The server refuses URI in a POST
request identifies the resource that will handle the enclosed entity as
an appendage. That resource may be a data-accepting process, a gateway
to accept some other protocol, or a separate entity that accepts annotations.
In contrast, the request without URI in a defined Content-
Length. The client MAY repeat PUT request identifies the entity enclosed
with the request if it adds a valid Content-
Length header field containing -- the length of user agent knows what URI is intended and the entity body in
server MUST NOT attempt to apply the request message.
412 Precondition Failed
The precondition given in one or more of to some other resource. If
the server desires that the request header fields
evaluated be applied to false when a different URI, it was tested on
MUST send a 301 (Moved Permanently) response; the server. This response code user agent MAY then
make its own decision regarding whether or not to redirect the request.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62] 54]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
allows the client to place preconditions on the current
A single resource
metainformation (header field data) and thus prevent the requested
method MAY be identified by many different URIs. For
example,
an article may have a URI for identifying "the current version" which is
separate from being applied to the URI identifying each particular version. In this
case,
a resource PUT request on a general URI may result in several other than URIs being
defined by the origin server.
For compatibility with HTTP/1.0 applications, all PUT requests MUST
include a valid Content-Length header field unless the one intended.
413 Request Entity Too Large
The server is refusing known
to process be HTTP/1.1 compliant. When sending a PUT request because it considers the
request entity to be larger than it is willing an HTTP/1.1
server, a client MUST use a valid Content-Length or able to process. the "chunked"
Transfer-Encoding. The server SHOULD close the connection respond with a 400 (bad request)
message if that is necessary to prevent the
client from continuing the request.
If it cannot determine the client manages to read length of the 413 response, it MUST honor it and
SHOULD reflect request message's
content, or with 411 (length required) if it wishes to the user.
If this restriction is considered temporary, the server MAY include insist on
receiving a
Retry-After header field to indicate that it valid Content-Length.
The actual method for determining how the resource entity is temporary placed, and after
what
time the client MAY try again.
414 Request-URI Too Large
The server is refusing happens to service its predecessor, is defined entirely by the request because origin
server.
PUT requests must obey the Request-URI is
longer than entity transmission requirements set out in
section 13.4.1.
13.6 DELETE
The DELETE method requests that the origin server is willing to interpret. delete the resource
identified by the Request-URI. This rare condition is
only likely to occur when a client has improperly converted a POST
request to a GET request with long query information, when method MAY be overridden by human
intervention (or other means) on the origin server. The client
has descended into a URL _black hole_ of redirection (e.g., a redirected
URL prefix cannot be
guaranteed that points to a suffix of itself), or when the operation has been carried out, even if the status
code returned from the origin server is
under attack by a client attempting to exploit security holes present in
some servers using fixed-length buffers for reading or manipulating indicates that the action has been
completed successfully. However, the
Request-URI.
415 Unsupported Media Type
The server SHOULD not indicate success
unless, at the time the response is refusing given, it intends to service delete the request because
resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an
entity body of describing the request is in a format not supported by status, 202 (Accepted) if the requested resource for action has not yet
been enacted, or 204 (No Content) if the requested method.
416 None Acceptable
This status code is reserved for future use by a planned content
negotiation mechanism. HTTP/1.1 user agents receiving a 416 response
which includes is OK but does not
include an entity.
If the request passes through a Location header can treat this response as they would
treat cache and the Request-URI identifies a 303 (See Other) response. If no Location header is included,
currently cached entity, that entity MUST be removed from the
appropriate action cache.
Responses to this method are not cachable.
13.7 TRACE
The TRACE method is used to display invoke a remote, application-layer
loop-back
of the entity enclosed in request message. The final recipient of the response request SHOULD
reflect the message received back to the user.
9.5 Server Error 5xx
Response status codes beginning with client as the digit _5_ indicate cases in
which entity body of a
200 (OK) response. The final recipient is either the origin server is aware that it has erred or is incapable
the first proxy or gateway to receive a Max-Forwards value of
performing zero (0)
in the request. If request (see section 18.32). A TRACE request MUST NOT include an
entity.
TRACE allows the client has not completed to see what is being received at the other end
of the request when chain and use that data for testing or diagnostic
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 63] 55]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
a 5xx code
information. The value of the Via header field (section 18.47) is received, of
particular interest, since it SHOULD immediately cease sending data to acts as a trace of the
server. Except when responding request chain. Use
of the Max-Forwards header field allows the client to a HEAD request, limit the server SHOULD
include an entity containing an explanation length
of the error situation, and
whether it request chain, which is useful for testing a temporary or permanent condition. These chain of proxies
forwarding messages in an infinite loop.
If successful, the response codes
are applicable to any SHOULD contain the entire request message in
the entity body, with a Content-Type of "message/http",
"application/http", or "text/plain". Responses to this method and there are no required header
fields.
500 Internal Server Error
The MUST NOT
be cached.
14 Access Authentication
HTTP provides a simple challenge-response authentication mechanism which
MAY be used by a server encountered to challenge a client request and by a client to
provide authentication information. It uses an unexpected condition extensible, case-
insensitive token to identify the authentication scheme, followed by a
comma-separated list of attribute-value pairs which prevented it from
fulfilling carry the request.
501 Not Implemented parameters
necessary for achieving authentication via that scheme.
auth-scheme = token
auth-param = token "=" quoted-string
The 401 (Unauthorized) response message is used by an origin server does not support the functionality required to fulfill
challenge the
request. authorization of a user agent. This is the appropriate response when the server does not
recognize MUST include
a WWW-Authenticate header field containing at least one challenge
applicable to the request method and is not capable of supporting it for any requested resource.
502 Bad Gateway
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
The server, while acting as realm attribute (case-insensitive) is required for all
authentication schemes which issue a gateway or proxy, received an invalid
response from challenge. The realm value (case-
sensitive), in combination with the canonical root URL of the upstream server it accessed in attempting to fulfill
being accessed, defines the request.
503 Service Unavailable
The protection space. These realms allow the
protected resources on a server to be partitioned into a set of
protection spaces, each with its own authentication scheme and/or
authorization database. The realm value is currently unable a string, generally assigned
by the origin server, which may have additional semantics specific to handle
the request due authentication scheme.
A user agent that wishes to authenticate itself with a temporary
overloading server--usually,
but not necessarily, after receiving a 401 or maintenance 411 response--MAY do so by
including an Authorization header field with the request. The
Authorization field value consists of credentials containing the server.
authentication information of the user agent for the realm of the
resource being requested.
credentials = basic-credentials
| auth-scheme 0#auth-param
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
The implication is that this
is a temporary condition domain over which will credentials can be alleviated after some delay. If
known, automatically applied by a user
agent is determined by the length of protection space. If a prior request has been
authorized, the delay same credentials MAY be indicated in reused for all other requests
within that protection space for a Retry-After header.
If no Retry-After is given, period of time determined by the client SHOULD handle
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the response as it
would for authentication scheme, a 500 response.
Note: The existence single protection
space cannot extend outside the scope of its server.
If the 503 status code server does not imply that a
server must use it when becoming overloaded. Some servers MAY wish to simply refuse accept the connection.
504 Gateway Timeout
The server, while acting as credentials sent with a gateway or proxy, did not receive
request, it SHOULD return a timely 401 (Unauthorized) response. The response from the upstream server it accessed in attempting
MUST include a WWW-Authenticate header field containing the (possibly
new) challenge applicable to complete the request.
505 HTTP Version Not Supported requested resource and an entity
explaining the refusal.
The server HTTP protocol does not support, or refuses restrict applications to support, this simple
challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the HTTP protocol
version that was used in transport level or via
message encapsulation, and with additional header fields specifying
authentication information. However, these additional mechanisms are not
defined by this specification.
Proxies MUST be completely transparent regarding user agent
authentication. That is, they MUST forward the WWW-Authenticate and
Authorization headers untouched, and MUST NOT cache the response to a
request message. containing Authorization.
HTTP/1.1 allows a client to pass authentication information to and from
a proxy via the Proxy-Authenticate and Proxy-Authorization headers.
14.1 Basic Authentication Scheme
The server "basic" authentication scheme is indicating based on the model that the user
agent must authenticate itself with a user-ID and a password for each
realm. The realm value should be considered an opaque string which can
only be compared for equality with other realms on that server. The
server will service the request only if it is unable or unwilling to complete can validate the user-ID and
password for the protection space of the Request-URI. There are no
optional authentication parameters.
Upon receipt of an unauthorized request using for a URI within the same
major version as protection
space, the client, as described in Section 3.1, other than
with this error message. The response server SHOULD contain an entity
describing why that version respond with a challenge like the following:
WWW-Authenticate: Basic realm="WallyWorld"
where "WallyWorld" is not supported the string assigned by the server to identify the
protection space of the Request-URI.
To receive authorization, the client sends the user-ID and what other protocols
are supported password,
separated by that server. a single colon (":") character, within a base64 encoded
string in the credentials.
basic-credentials = "Basic" SP basic-cookie
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64] 57]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
10. Header Field Definitions
This section defines the syntax and semantics
basic-cookie = <base64 [7] encoding of all standard HTTP/1.1
header fields. For Entity-Header fields, both sender and recipient refer user-pass,
except not limited to either 76 char/line>
user-pass = userid ":" password
userid = [ token ]
password = *TEXT
If the client or user agent wishes to send the server, depending on who sends user-ID "Aladdin" and who
receives password
"open sesame", it would use the entity.
10.1 Accept following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
The Accept request-header field can be used basic authentication scheme is a non-secure method of filtering
unauthorized access to specify certain media
types which are acceptable for resources on an HTTP server. It is based on the response. Accept headers can be used
to indicate
assumption that the request is specifically limited to a small set of
desired types, as in connection between the case of client and the server can be
regarded as a request for trusted carrier. As this is not generally true on an in-line image.
The field MAY open
network, the basic authentication scheme should be folded onto several lines and more than one occurrence used accordingly. In
spite of this, clients SHOULD implement the field is allowed, scheme in order to
communicate with the semantics being the same as if all the
entries had been in one field value.
Accept = "Accept" ":" #(
media-range
[ ( ":" | ";" )
range-parameter
*( ";" range-parameter ) ]
| extension-token )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
range-parameter = ( "q" "=" qvalue )
| extension-range-parameter
extension-range-parameter = ( token "=" token )
extension-token = token servers that use it.
14.2 Digest Authentication Scheme
The asterisk _*_ character "digest" authentication scheme is used [currently described in an expired
Internet-Draft, and this description will have to group media types into ranges, be improved to
reference a new draft or include the old one].
15 Content Negotiation
A generic resource has multiple entities associated with _*/*_ indicating all media types and _type/*_ indicating it, all
subtypes of that type. The range-parameter q
which are representations of the content of the resource. Content
negotiation is used to indicate the
media type quality factor for process of selecting the range, which represents best representation when a
GET or HEAD request is made on the user's
preference generic resource. HTTP/1.1 has
provisions for that range two kinds of media types. The default value content negotiation: opaque negotiation and
transparent negotiation.
With opaque negotiation, the selection of the best representation is q=1. In
Accept headers generated
done by HTTP/1.1 clients, an algorithm located at the character separating
media-ranges from range-parameters SHOULD be a _:_. HTTP/1.1 servers
SHOULD be tolerant origin server, and unknown to the
proxies and user agents involved. Selection is based on the contents of use
particular header fields in the request message, or on other information
pertaining to the request, like the network address of the _;_ separator by HTTP/1.0 clients.
The sending
client. A typical example
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Accept: audio/*: q=0.2, audio/basic
SHOULD of opaque negotiation would be interpreted as _I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down selection
of a text/html response in quality._
If no Accept a particular language based on the contents
of the Accept-Language request header field. A disadvantage of opaque
negotiation is present, then it is assumed that the client
accepts all media types. If Accept request headers are present, and if may not always contain enough
information to allow for selection. If the
server cannot send Accept header
Accept: text/*: q=0.3, text/html, */*: q=0.5
is sent in a response request on a generic resource which is acceptable according to has a video/mpeg and a
video/quicktime representation, the
Accept headers, then selection algorithm in the origin
server SHOULD send will either have to make a default choice, or return an error
response with which allows the
406 (not acceptable) status code, though user to decide on further actions.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
With transparent negotiation, the sending selection of an unacceptable
response is also allowed.
A more elaborate example the best representation
is
Accept: text/plain: q=0.5, text/html,
text/x-dvi: q=0.8, text/x-c
Verbally, this would be interpreted as _text/html and text/x-c are done by a distributed algorithm which can perform computation steps
in the
preferred media types, but if they do not exist, then send origin server, in proxies, or in the text/x-
dvi entity, and user agent. Transparent
negotiation guarantees that, if that does not exist, send the text/plain entity._
Media ranges can be overridden by more specific media ranges or specific
media types. If more than one media range applies to a given type, the
most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;level=1, */*
have user agent supports the following precedence:
1) text/html;level=1
2) text/html
3) text/*
4) */*
The media type quality factor associated with a given type transparent
negotiation algorithm and is determined
by finding correctly configured, the media range with request will
always correctly yield either the highest precedence which matches
that type. For example,
Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
*/*:q=0.5
would cause video/mpeg representation, the following values to be associated:
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
text/html;level=1 = 1
image/jpeg = 0.5
text/html;level=3 = 0.7
Note: A user agent MAY be provided with a default set of quality
values for certain media ranges. However, unless
video/quicktime representation, or an error message indicating that the user agent
is a closed system which
resource cannot interact with other rendering text/html = 0.7 text/plain = 0.3
agents, this default set SHOULD be configurable displayed by the user.
10.2 Accept-Charset
The Accept-Charset request-header field can be used to indicate what
character sets are acceptable user agent.
15.1 Negotiation Facilities Defined in this Specification
This specification defines all protocol facilities for opaque
negotiation, but does not define the response. distributed algorithm for
transparent negotiation. This field allows
clients capable of understanding more comprehensive or special-purpose
character sets to signal that capability to a server which is capable of
representing documents specification only defines the basic
facilities (Vary, Alternates, Accept) in those character sets. The ISO-8859-1 character
set can be assumed to be acceptable the core protocol allowing
requests on transparently negotiated resources to all user agents.
Accept-Charset = "Accept-Charset" ":"
1#( charset [ ";" "q" "=" qvalue ] )
Character set values are described in Section 3.4. Each charset may be
given an associated quality value which represents the user's preference
for that charset. The default value is q=1. An example correctly handled
by HTTP/1.1 caches. All other information about transparent content
negotiation is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 found in a separate document[29].
If no Accept-Charset header a generic resource is present, opaquely negotiated, successful responses to
requests on the default is that any
character set is acceptable. resource will always include a Vary header. If an Accept-Charset header is present, and
if the server cannot send a response which
generic resource is acceptable according transparently negotiated, successful responses to
requests on the Accept-Charset header, then the server SHOULD send resource will always include an error Alternates header. If a
successful response
with the 406 (not acceptable) status code, though the sending of contains an
unacceptable response is Alternates header, it will also allowed.
10.3 Accept-Encoding
The Accept-Encoding request-header field is similar always
contain a Content-Location header. A future specification may allow a
combination of opaque and transparent negotiation that would lead to Accept, but
restricts the content-coding values (Section 3.5) which are acceptable
inclusion of both a Vary header and an Alternates header in the a response.
Fielding, Frystyk, Berners-Lee, Gettys,
16 Caching in HTTP
The World Wide Web is a distributed system, and Mogul [Page 67]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
An example of so its use is
Accept-Encoding: compress, gzip
If no Accept-Encoding header is present in a request, the server MAY
assume that performance can
be improved by the client will accept any content coding. If an Accept-
Encoding header is present, use of caches. These caches are typically placed at
proxies and if in the server cannot send clients themselves. The HTTP/1.1 protocol includes a response
which is acceptable according
number of elements intended to make caching work as well as possible.
Because these elements are inextricable from other aspects of the Accept-Encoding header, then the
server SHOULD send an error response
protocol, and because they interact with the 406 (not acceptable)
status code.
10.4 Accept-Language
The Accept-Language request-header field each other, it is similar useful to Accept, but
restricts
describe the set basic caching design of natural languages that are preferred as a HTTP separately from the detailed
descriptions of methods, headers, response codes, etc.
16.1 Semantic Transparency
Requirements for performance, availability, and disconnected operation
require us to the request.
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) )
| "*" )
Each language-range MAY be given an associated quality value which
represents an estimate of able to relax the user's comprehension goal of the languages
specified by that range. semantic transparency. The quality value defaults
HTTP/1.1 protocol allows origin servers, caches, and clients to _q=1_ (100%
comprehension).For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: _I prefer Danish, but will accept British English (with 80%
comprehension)
explicitly reduce transparency when necessary. However, because non-
transparent operation may confuse non-expert users, and other types of English(with 70% comprehension)._ A
language-range matches a language-tag if it exactly equals the tag, or
if it exactly equals a prefix (a sub-sequence starting at the first
character) of may be
incompatible with certain server applications (such as those for
ordering merchandise), the tag such protocol requires that the first tag character following the
prefix is _-_. The special range _*_, if present in the Accept-Language
field, matches every tag transparency may not matched
be relaxed
. without an explicit protocol-level request (when relaxed by any other ranges present in the
Accept-Language field.
Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is
always true that if a user understands a language with client
or origin server)
. without a certain
tag, then this means for warning the end user will also understand all languages with tags (when relaxed by cache or
client)
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68] 59]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
for which this tag is a prefix. The prefix rule simply allows
Therefore, the use of prefix tags if HTTP/1.1 protocol provides these important elements:
1. Protocol features that provide full semantic transparency when this
is the case.
The language quality factor assigned desired by all parties.
2. Protocol features that allow an origin server or end-user client to
explicitly request and control non-transparent operation.
3. Protocol features that allow a language-tag by the Accept-
Language field is the quality value of the longest language-range in the
field cache to attach warnings to
responses that matches the language-range. If no language-range in the
field matches the tag, the language quality factor assigned is 0. If no
Accept-Language header do not preserve semantic transparency.
A basic principle is present in the request, the server SHOULD
assume that all languages are equally acceptable. If an Accept-Language
header is present, then all languages which are assigned a quality
factor greater than 0 are acceptable. If the server cannot generate a
response it must be possible for an audience capable the clients to detect
any potential breakdown of understanding at least one
acceptable language, it can send a response that uses one or more un-
accepted languages.
It may semantic transparency.
Caching would be contrary useless if it did not significantly improve
performance. The goal of caching in HTTP/1.1 is to eliminate the privacy expectations of need to
send requests in many cases, and to eliminate the user need to send an
Accept-Language header with full
responses in many other cases. The former reduces the complete linguistic preferences number of the
user in every request. For network
round-trips required for many operations; we use an "expiration"
mechanism for this purpose (see section 16.1.2). The latter reduces
network bandwidth requirements; we use a discussion of "validation" mechanism for this issue, see Section 14.7
.
Note: As intelligibility is highly dependent on the individual
user, it is recommended that
purpose (see section 13.3).
The server, cache, or client applications make implementer may be faced with design
decisions not explicitly discussed in this specification. If a decision
may affect semantic transparency, the choice
of linguistic preference available implementer ought to err on the user.
side of maintaining transparency unless a careful and complete analysis
shows significant benefits in breaking transparency.
16.1.1 Cache Correctness
If the choice is
not made available, then cache can communicate with the Accept-Language header field origin-server, then a correct
cache MUST
not be given in respond to a request with a response that meets all the request.
10.5 Allow
The Allow entity-header field lists
following conditions:
1. its end-to-end headers (see section 16.4.1) and entity-body value
are equivalent to what the set of methods supported by server would have returned for that
request if the resource identified by had not been modified since the Request-URI. The purpose of this field is
strictly to inform response
was cached. This may be accomplished by revalidating the recipient of valid methods associated response
with the
resource. An Allow header field MUST be present in a 405 (method not
allowed) response. The Allow header field origin server, if is not permitted in a request
using fresh.
2. it is "fresh enough" (see section 16.1.2). In the POST method, default case,
this means it meets the least restrictive freshness requirement of
the client, server, and thus SHOULD be ignored cache (see section 18.10); if the origin-
server so specifies, it is received as
part the freshness requirement of the
origin-
server alone.
3. it includes a POST entity.
Allow = "Allow" ":" 1#method
Example warning if the freshness demand of use:
Allow: GET, HEAD, PUT
This field cannot prevent a client from trying other methods. However, the indications given by client or the Allow header field value SHOULD be
followed. The actual set of allowed methods
origin-server is violated (see section 16.1.5 and 18.48).
4. it is defined by the origin
server at most up-to-date response appropriate to the time of each request.
Fielding, Frystyk, Berners-Lee, Gettys, request the
cache has seen (see section 16.2.6, 16.2.8, and Mogul [Page 69]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
The Allow header field MAY be provided with a PUT request to recommend
the methods to be supported by the new or modified resource. The server
is not required to support these methods and SHOULD include an Allow
header in the response giving the actual supported methods.
A proxy MUST not modify 16.13).
If the Allow header field even if it does cache can not
understand all the methods specified, since the user agent MAY have
other means of communicating communicate with the origin server.
The Allow header field does not indicate what methods are implemented at
the server level. Servers MAY use the Public response header field
(Section 10.32) to describe what methods are implemented on the server
as a whole.
10.6 Authorization
A user agent that wishes to authenticate itself with a server--usually,
but not necessarily, after receiving a 401 response--MAY do so by
including an Authorization request-header field with the request. The
Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the
resource being requested.
Authorization = "Authorization" ":" credentials
HTTP access authentication is described in Section 11. If a request is
authenticated and a realm specified, the same credentials SHOULD be
valid for all other requests within this realm.
When server, then a shared correct
cache (see section 13.10) receives a request containing an
Authorization field, it MUST NOT return the corresponding response SHOULD respond as a
reply to any other request, unless one of the following specific
exceptions holds:
1. If the response includes the _proxy-revalidate_ Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but a proxy cache MUST first revalidate it with
the origin server, using the request headers from the new request
to allow the origin server to authenticate the new request.
2. If the response includes the _must-revalidate_ Cache-Control
directive, above if the cache MAY use that response in replying to a
subsequent request, but all caches MUST first revalidate it with
the origin server, using the request headers can be correctly served
from the new request
to allow the origin server to authenticate the new request.
3. If the response includes the _public_ Cache-Control directive, cache; if not it
may be returned in reply to any subsequent request.
10.7 Cache-Control
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the request/response return an error or warning indicating
that there was a communication.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70] 60]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
chain.
16.1.2 Cache-control Mechanisms
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
times and validators) are implicit directives to caches. In some cases,
a server or client may need to provide explicit directives specify behavior intended to prevent caches from
adversely interfering with the request HTTP
caches. We use the Cache-Control header for this purpose.
The Cache-Control header allows a client or response. . server to transmit a variety
of directives in either requests or responses. These directives
typically override the default caching algorithms. Cache directives are
unidirectional in that the presence of a directive in As a request does not
imply that general rule, if
there is any apparent conflict between header values, the same directive most
restrictive interpretation should be given in applied (that is, the response.
Cache one that is
most likely to preserve semantic transparency). However, in some cases,
Cache-Control directives must be passed through by a proxy are explicitly specified as weakening semantic
transparency (for example, "max-stale" or gateway
application, regardless of their significance to that application, since
the "public").
The Cache-Control directives may be applicable to all recipients along the
request/response chain. It are described in detail in section 18.10.
16.1.3 Warnings
Whenever a cache returns a response that is not possible semantically
transparent, it must attach a warning to specify that effect, using a cache-directive Warning
response header. This warning allows clients and user agents to take
appropriate action.
Warnings may be used for a specific cache.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = "public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "only-if-cached"
| "max-age" "=" delta-seconds
| "max-stale" "=" delta-seconds
| "min-fresh" "=" delta-seconds
| "min-vers" "=" HTTP-Version other purposes, both cache-related and perhaps
| "max-uses" "=" 1*DIGIT
| "use-count" "=" 1*DIGIT
When
otherwise. The use of a directive appears without any 1#field-name parameter, the
directive applies to warning, rather than an error status code,
distinguish these responses from true failures.
Warnings are always cachable, because they never weaken the entire request or transparency
of a response. When This means that warnings can be passed to HTTP/1.0 caches
without danger; such caches will simply pass the warning along as a
directive appears with a 1#field-name parameter, it applies only to
entity header in the
named field or fields, response.
Warnings are assigned numbers between 0 and not to 99. This specification
defines the rest code numbers and meanings of the request each warning, allowing a client
or response.
This mechanism supports extensibility; implementations of future
versions of the HTTP protocol may apply these directives cache to header
fields take automated action in some (but not defined all) cases.
Warnings also carry a warning message text in HTTP/1.1.
The cache-control directives can be broken down into these general
categories:
. Restrictions any appropriate natural
language (perhaps based on what is cachable; these may only be imposed by the
origin server.
. Restrictions on client's Accept headers), and an optional
indication of what language and character set are used.
Multiple warning messages may be stored by attached to a cache; these may be imposed response (either by either the
origin server or the end-user client.
. Modifications of the basic expiration mechanism; these may be
imposed by either a cache), including multiple warnings with the origin same
code number. For example, a server or may provide the end-user client.
. Controls over cache revalidation same warning with
texts in both English and reload; these Basque.
When multiple warnings are attached to a response, it may only not be
imposed by an end-user client.
. Restrictions on
practical or reasonable to display all of them to the number user. This version
of times a cache entry may be used, HTTP does not specify strict priority rules for deciding which
warnings to display and
related demographic reporting mechanisms. in what order, but does suggest some
heuristics.
The Warning header and the currently defined warnings are described in
section 18.48.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71] 61]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
. Miscellaneous restrictions
Caches never add or remove Cache-Control directives to requests or
responses.
Check: is this true?
10.7.1 SLUSHY: Restrictions on What is Cachable
Unless specifically constrained by a Cache-Control directive, a caching
system may always store a successful response as a cache entry, may
return it without validation if it is fresh, and may return it after
successful validation. If there is neither a cache validator nor an
explicit expiration time associated with a response, we do not expect
16.1.4 Explicit User Agent Warnings
Many user agents make it possible for users to be cached, but certain caches may violate this expectation (for override the basic
caching mechanisms. For example, when little or no network connectivity is available) as long as
they explicit mark their responses using the Warning mechanism describe
in section 10.51.
Note that some HTTP/1.0 caches are known to violate this
expectation without providing any Warning.
However, in some cases it user agent may be inappropriate for a cache allow the user to retain a
resource value,
specify that cached entities (even explicitly stale ones) are never
validated. Or the user agent might habitually add "Cache-Control: max-
stale=3600" or "Cache-Control: reload" to return it in response to a subsequent every request.
This We recognize
that there may be because absolute semantic transparency is deemed necessary
by situations which require such overrides, although user
agents SHOULD NOT default to any behavior contrary to the service author, or because of security HTTP/1.1
specification. That is, the user should have to explicitly request
either non-transparent behavior, or privacy considerations.
Certain Cache-Control directives are therefore provided so behavior that results in abnormally
ineffective caching.
If the
server can user has overridden the basic caching mechanisms, the user agent
should explicitly indicate to the user whenever this results in the
display of information that certain resources, or portions thereof, may might not meet the server's transparency
requirements (in particular, if the displayed entity is known to be cached regardless of other considerations.
Note that section 10.6
stale). Since the protocol normally prevents a shared cache from saving and
returning a response allows the user agent to a previous request determine
if that request included an
Authorization header.
The following Cache-Control response directives add responses are stale or remove
restrictions on what is cachable:
public
Overrides the restriction in section 10.6 that prevents not, this indication need only be displayed
when this actually happens. The indication need not be a shared
cache from saving and returning dialog box; it
could be an icon (for example, a response to picture of a previous request if
that request included an Authorization header. However, any rotting fish) or some
other
constraints on visual indicator.
If the user has overridden the caching still apply.
private
Indicates mechanisms in a way that all or parts would
abnormally reduce the effectiveness of caches, the response message are intended for
a single user and MUST NOT be cached by a shared cache. This allows agent should
continually display an origin server to state that the specified parts indication (for example, a picture of currency in
flames) so that the response
are intended for only one user and are does not a valid response for
requests by other users. applicable inadvertently consume excess resources
or suffer from excessive latency.
16.1.5 Exceptions to responses the Rules and must not be
generated by clients. A private (non-shared) Warnings
In some cases, the operator of a cache may ignore this
directive.
Note: choose to configure it to
return stale responses even when not requested by clients. This usage of the word _private_ only controls where the
response decision
not be made lightly, but may cached, and cannot ensure the privacy be necessary for reasons of the
message content. Note in particular that HTTP/1.0 caches will
not recognize or obey this directive.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
no-cache
indicates that all availability or parts of
performance, especially when the response message cache is poorly connected to the origin
server. Whenever a cache returns a stale response, it MUST NOT be
cached. mark it as
such (using a Warning header). This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to the client
requests.
Note: HTTP/1.0 caches will not recognize or obey this directive.
TBS: precedence relations between public, private, and no-cache.
10.7.2 Restrictions On What May be Stored by a Cache
The _no-store_ directive applies software to alert
the entire message, and user that there may be sent
either in a response or in a request. If sent in a request, a cache MUST
NOT store any part of either this request or any response potential problem.
It also allows the user to it. If sent
in take steps to obtain a firsthand or fresh
response, if the user so desires. For this reason, a cache MUST NOT store any part of either this
return a stale response
or if the request that elicited it. This directive applies to both non-
shared and shared caches.
Even when this directive is associated with a response, users may client explicitly store such requests a response outside of first-hand
or fresh one, unless it is impossible to comply.
16.1.6 Client-controlled Behavior
While the caching system (e.g.,
with origin server (and to a _Save As_ dialog). History buffers may store such responses as
part of lesser extent, intermediate caches, by
their normal operation.
The purpose of this directive is contribution to meet the stated requirements age of
certain users and service authors who a response) are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the use primary source of this directive may improve privacy
expiration information, in some
cases, we caution that it is NOT in any way a reliable or sufficient
mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not
recognize or obey this directive, malicious or compromised caches may
not recognize or obey this directive, and all communications networks
may be vulnerable to eavesdropping.
The _min-vers_ directive applies to cases the entire message, and client may be sent
either in a response or in a request. If sent in need to control a request,
cache's decision about whether to return a cache
whose HTTP version number is less than the specified version MUST NOT
store any part of either this request or any cached response to without
validating it. If sent in
a response, a cache whose HTTP version number is less than the specified
version MUST NOT store any part of either Clients do this response or using several directives of the Cache-
Control header.
A client's request
that elicited it, nor may any cache transmit a stored (non-firsthand)
copy of specify the response maximum age it is willing to any client with accept
for an unvalidated response; specifying a lower HTTP version number.
This directive applies to both non-shared and shared caches, and is made
mandatory to allow for future protocol extensions that may affect
caching.
Note that the lowest version that can be sensibly included in a
_min-vers_ directive is HTTP/1.1, since HTTP/1.0 caches do not
obey it.
10.7.3 Modifications of the Basic Expiration Mechanism
The expiration time value of a resource may be specified by the origin server
using the Expires header (see section TBS). Alternatively, it may be
specified using zero forces the _max-age_ directive in a response.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73] 62]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
If
cache(s) to revalidate all responses. A client may also specify the
minimum time remaining before a response includes both an Expires header expires. Both of these options
increase constraints on the behavior of caches, and a max-age: directive, so cannot decrease
semantic transparency.
A client may also specify that it will accept stale responses, up to
some maximum amount of staleness. This loosens the max-age: directive overrides constraints on the Expires header, even if
caches, and so may violate semantic transparency, but may be necessary
to support disconnected operation, or high availability in the Expires
header face of
poor connectivity.
16.2 Expiration Model
16.2.1 Server-Specified Expiration
HTTP caching works best when caches can entirely avoid making requests
to the origin server. The primary mechanism for avoiding requests is more restrictive. This rule allows for
an origin server to
provide, for a given response, a longer provide an explicit expiration time to an HTTP/1.1
(or later) cache than to an HTTP/1.0 cache. This in the future,
indicating that a response may be useful if
certain HTTP/1.0 caches improperly calculate ages or expiration times,
perhaps due to badly unsynchronized clocks.
Other directives allow an end-user client used to modify satisfy subsequent requests.
In other words, a cache can return a fresh response without first
contacting the basic server.
Our expectation is that servers will assign future explicit expiration
mechanism, making it either stricter or looser. These directives may be
specified on a request:
max-age Indicates
times to responses in the belief that the client entity is willing not likely to accept
change, in a response whose
age is no greater than semantically significant way, before the specified expiration time in seconds. Unless _max-stale_ is also included,
reached. This normally preserves semantic transparency, as long as the client is not willing
server's expiration times are carefully chosen.
If an origin server wishes to accept force a stale response.
This directive overrides any policy of semantically transparent cache to
validate every request, it may assign an explicit expiration time in the cache.
min-fresh Indicates
past. This means that the client is willing to accept a response
whose freshness lifetime is no less than its current age plus the
specified time in seconds. That is, always stale, and so the client wants cache
SHOULD validate it before using it for subsequent requests. (See
section 18.10.4 for a more restrictive way to force revalidation).
Note that a firsthand response
will still MUST always be fresh for at least returned to the specified number
requesting client, independent of seconds.
max-stale Indicates that its expiration time, unless the
connection to the client is willing lost.
If an origin server wishes to accept a response that
has exceeded its expiration time by force any HTTP/1.1 cache, no more than matter how it
is configured, to validate every request, it should use the specified number of
seconds. If a cache returns a stale response in response to such a
request, it MUST mark it as stale "must-
revalidate" Cache-Control directive. See section 18.10.
Servers specify explicit expiration times using the Warning header.
Note that HTTP/1.0 caches will ignore these directives.
If a cache returns a stale response, either because of a max-stale
directive on a request, or because the cache is configured to override Expires
header, or the expiration time max-age directive of a response, the cache MUST attach a Warning
header to Cache-Control header.
16.2.2 Limitations on the stale response, using Warning 10 (Response is stale).
10.7.4 SLUSHY: Controls over cache revalidation and reload
Sometimes an end-user client may want or need Effect of Expiration Times
An expiration time cannot be used to insist that force a cache
revalidate its cache entry with the origin server (and not just with the
next cache along the path user agent to the origin server), refresh its
display or to reload a resource entity; its cache
entry from the origin server. End-to-end revalidation may be necessary
if either the cache or the origin server has overestimated the semantics apply only to caching
mechanisms, and such mechanisms need only check a resource's expiration time of the cached response. End-to-end reload may be
necessary if the response value has become corrupted
status when a new request for some reason,
and the fact that its validator is up-to-date resource is irrelevant.
End-to-end revalidation may be requested either when the client does not
have its own local cached copy, in which case we call it _unspecified
end-to-end revalidation_, or when the client does initiated.
User agents often have a local cached
copy, in history mechanisms, such as "Back" buttons and
history lists, which case we call it _specific end-to-end revalidation._
The client can specify these three kinds of action using Cache-Control
request directives: be used to redisplay an entity retrieved
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74] 63]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
End-to-end reload The request includes _Cache-Control: no-cache_ or, for
compatibility with HTTP/1.0 clients, _Pragma: no-cache_. No field names
may be included with the _no-cache_ directive
earlier in a request. The server
MUST NOT use a cached copy when responding to such a request.
Specific end-to-end revalidation The request includes _Cache-Control:
max-age=0_, which forces each cache along the path session. By default, an expiration time does not apply to
history mechanisms. If the origin server
to revalidate its own entry, entity is still in storage, a history
mechanism should display it even if any, with the next cache or server. The
initial request includes a cache-validating conditional with entity has expired, unless the
client's current validator.
Unspecified end-to-end revalidation The request includes _Cache-Control:
max-age=0_, which forces each cache along
user has specifically configured the path agent to the refresh expired history
documents.
16.2.3 Heuristic Expiration
Since origin server
to revalidate its own entry, if any, with servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as the next cache or server. Last-Modified
time)
to estimate a plausible expiration time. The
initial request HTTP/1.1 specification does
not include provide specific algorithms, but does impose worst-case constraints
on their results. Since heuristic expiration times may compromise
semantic transparency, they should be used cautiously, and we encourage
origin servers to provide explicit expiration times as much as
possible.
16.2.4 Age Calculations
In order to know if a cache-validating conditional; the
first cache along the path (if any) that holds a cache cached entry for this
resource includes a cache-validating conditional with its current
validator.
Note that HTTP/1.0 caches will ignore these directives, except
perhaps for _Pragma: no-cache_.
When an intermediate cache is forced, by means of fresh, a _max-age=0_
directive, cache needs to revalidate know if
its own cache entry, and the client has
supplied age exceeds its own validator in the request, the supplied validator may
differ from freshness lifetime. We discuss how to calculate the validator currently stored with
latter in section 0; this section describes how to calculate the age of
a response or cache entry.
In this
case, the cache may discussion, we use either validator in making its own request
without affecting semantic transparency.
However, the choice term "now" to mean "the current value of validator may affect performance. The best
approach is for
the intermediate cache to use its own validator when
making its request. If clock at the server replies with 304 (Not Modified), then host performing the cache calculation." All HTTP
implementations, but especially origin servers and caches, should return its now validated copy use
NTP [RFC1305] or some similar protocol to synchronize their clocks to the client with a 200
(OK) response. If the server replies with
globally accurate time standard.
Also note that HTTP/1.1 requires origin servers to send a new Entity-body and cache
validator, however, Date header
with every response, giving the intermediate cache should compare time at which the returned
validator with response was
generated. We use the one provided in term "date_value" to denote a representation of
the client's request, using value of the
strong comparison function. If Date header, in a form appropriate for arithmetic
operations.
HTTP/1.1 uses the client's validator is equal "Age" response header to help convey age information
between caches. The Age header value is the
origin server's, then sender's estimate of the intermediate cache simply returns 304 (Not
Modified). Otherwise, it returns
amount of time since the new Entity-body with a 200 (OK)
response.
If a request includes response was generated at the _no-cache_ directive, it should not include
_fresh-min_, _max-stale_, or _max-age_. origin server. In some cases, such as times
the case of extremely poor network connectivity, a
client may want a cache to return only those responses cached response that it currently has stored, and not to reload or revalidate been revalidated with the origin server. To
do this,
server, the client may include Age value is based on the _only-if-cached_ directive in a
request. If it receives this directive, a cache SHOULD either respond
using a cached time of revalidation, not of the
original response.
In essence, the Age value that is consistent with the other constraints sum of the request, or respond with a 504 (Gateway Timeout) status. However, if
a group time that the response has
been resident in each of the caches is being operated as along the path from the origin
server, plus the amount of time it has been in transit along network
paths.
We use the term "age_value" to denote a unified system with good
internal connectivity, such representation of the value of
the Age header, in a request MAY form appropriate for arithmetic operations.
An response's age can be forwarded within that group
of caches. calculated in two entirely independent ways:
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75] 64]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
directive, which has a similar effect,
1. now - date_value, if the protocol also includes a
mechanism for local clock is reasonably well
synchronized to the origin server to require revalidation of a cache entry
on any subsequent use. When server's clock. If the _must-revalidate_ directive result is present
in a response received
negative, this is replaced by a cache, that cache MUST NOT use zero.
2. age_value, if all of the value
after it becomes stale to respond caches along the response path implement
HTTP/1.1.
Given that we have two independent ways to compute the age of a subsequent request without first
revalidating response
when it with the origin server. (I.e., the cache must do an end-
to-end revalidation every time.)
The _must-revalidate_ directive is necessary to support reliable
operation for cookies received, we can combine these as
corrected_received_age = max(now - date_value, age_value)
and certain other protocol features. In all
circumstances an as long as we have either nearly synchronized clocks or
all-HTTP/1.1
paths, one gets a reliable (conservative) result.
Note that this correction is applied at each HTTP/1.1 cache MUST obey along the _must-revalidate_
directive; in particular,
path, so that if the there is an HTTP/1.0 cache cannot reach in the origin server
for any reason, it MUST generate a 504 (Gateway Timeout) response. Note
that HTTP/1.0 caches will ignore this directive.
Servers should send path, the _must-revalidate_ directive if and only if
failure to revalidate a request on correct
received age is computed as long as the entity could result receiving cache's clock is
nearly in
significantly incorrect operation, such as a silently unexecuted
financial transaction. Recipients MUST NOT take any automated action
that violates this directive, sync. We don't need end-to-end clock synchronization
(although
it is good to have), and MUST NOT automatically provide an
unvalidated copy there is no explicit clock synchronization
step.
Because of network-imposed delays, some significant interval may pass
from the entity if revalidation fails.
Although this time that a server generates a response, and the time it is not recommended, user agents operating under severe
connectivity constraints may violate
received at the next outbound cache or client. If uncorrected, this directive but if so, MUST
explicitly warn
delay could result in improperly low ages.
Because the user request that an unvalidated response has resulted in the returned Age value must have
been provided.
The warning initiated prior to that Age value's generation, we can correct for
delays imposed by the network by recording the time at which the request
was initiated. Then, when an Age value is received, it MUST be provided on each unvalidated access, and SHOULD
require explicit user confirmation.
The _proxy-revalidate_ directive has
interpreted relative to the same meaning as time the _must-
revalidate_ directive, except that it does request was initiated, not apply to user-agent
caches. This directive is meant to support digest authentication.
10.7.5 FLUID: Restrictions on use count and demographic reporting the time
that the response was received. This section algorithm results in conservative
behavior no matter how much delay is highly debatable and experienced. So, we compute:
corrected_initial_age = corrected_received_age
+ (now - request_time)
where "request_time" is likely to be removed the time (according to a
separate I.D.
The _max-uses_ the local clock) when the
request that elicited this response directive allows was sent.
Summary of age calculation algorithm, when a cache to use a response at
most receives a certain limited number of times. For example, _max-uses=10_
means that the response should be returned in reply to response:
/*
* age_value
* is the current
request, and may be returned in reply to no more than nine subsequent
requests (subject to other caching constraints), unless revalidated.
A cache may subdivide its remaining use-count among several value of its own
clients. For example, if the incoming response includes _max-uses=10_, Age: header received by the recipient may forward this as two responses, each cache with _max-uses=5_.
The idea
* this response.
* date_value
* is that the total number value of uses allowed in a cache hierarchy
should not exceed the specified limit. (The heuristics a cache uses to
sub-allocate its max-uses value are beyond origin server's Date: header
* request_time
* is the scope of (local) time when the HTTP spec.)
The _use-count_ request directive allows a cache to tell a server how
many times it has actually used made the cache entry specified request
* that resulted in this cached response
* response_time
* is the (local) time when the cache received the
* response
* now
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76] 65]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
associated request. If
* is the current (local) time
*/
apparent_age = max(0, now - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = now - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
When a cache receives a use-count value from one of
its clients, and it has sends a corresponding cache entry, response, it should must add the
incoming use-count to its local count.
When a cache removes an entry, it MAY first send a HEAD request on the
associated URI, including its use-count value, to inform corrected_initial_age
the server amount of time that the actual use-count. If response was resident locally. It must then
transmit this total age, using the server has sent a max-uses limit, Age header, to the
cache SHOULD perform this notification.
A cache next recipient
cache.
Note that a client can usually tell if a response is willing firsthand by
comparing the Date to perform such notifications its local request-time, and hoping that is
willing to obey the max-uses limit SHOULD send
clocks are not badly skewed.
16.2.5 Expiration Calculations
In order to decide whether a ``use-count=0''
directive on response is fresh or stale, we need to
compare its first (non-conditional) request on a resource. This
informs the server that the cache intends freshness lifetime to use these two directives in
the manner its age. The age is calculated as
described here.
10.7.6 Miscellaneous restrictions
In certain circumstances, an intermediate cache (proxy) may find it
useful in section 16.2.4; this section describes how to convert calculate the encoding of an entity body. For example,
freshness lifetime, and to determine if a proxy
might response has expired.
We use a compressed content-coding to transfer the body term "expires_value" to denote a client
on a slow link.
Because end-to-end authentication representation of entity bodies and/or entity headers
relies on the specific encoding value
of these values, such transformations
may cause authentication failures. Therefore, the Expires header, in a form appropriate for arithmetic operations.
We use the term "max_age_value" to denote an intermediate cache MUST
NOT change appropriate representation
of the encoding number of an entity body if seconds carried by the response includes max-age directive of the
_no-transform_ directive.
10.8 Connection
HTTP version 1.1 provides Cache-
Control header in a new request and response header field called
_Connection_. This header field allows the client and server to specify
options which should only exist over that particular connection and MUST
NOT be communicated by proxies over further connections. (see section 18.11).
The connection
header field MAY have multiple tokens separated by commas (referred to
as connection-tokens).
HTTP version 1.1 proxies MUST parse the Connection header field and for
every connection-token max-age directive takes priority over Expires, so if max-age is
present in this field, remove a corresponding header
field from the request before response, the request calculation is forwarded. The use of a
connection option simply:
freshness_lifetime = max_age_value
Otherwise, if Expires is specified by present in the presence response, the calculation is:
freshness_lifetime = expires_value - date_value
Note that neither of a connection token these calculations is vulnerable to clock skew,
since all of the information comes from the origin server.
If neither Expires nor Cache-Control max-age appears in the Connection header field, not by response,
and the corresponding additional header
field (which may response does not be present).
When include other restrictions on caching, the
cache MAY compute a client wishes to establish freshness lifetime using a persistent connection it heuristic. This heuristic
is subject to certain limitations; the minimum value may be zero, and
the maximum value MUST send be no more than 24 hours.
Also, if the response does have a
_Persist_ connection-token:
Connection: persist
The Connection header has Last-Modified time, the following grammar: heuristic
expiration value SHOULD be no more than some fraction of the interval
since that time. A typical setting of this fraction might be 10%.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 77] 66]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Connection-header = "Connection" ":"
connection-token 0#( "," connection-token )
When the Persist connection-token has been transmitted with a request or
a response a Persist header field MAY also be included. The 10.8.1 Persist Persist
header field takes the following form:
Persist-header = "Persist" ":" 0#pers-param
pers-param = param-name "=" value
The Persist header itself is optional, and is used only calculation to determine if a parameter response has expired is being sent. HTTP/1.1 does not define any parameters.
If the Persist header quite simple:
response_is_fresh = (freshness_lifetime > current_age)
16.2.6 Scope of Expiration
HTTP/1.1's expiration model is sent, the corresponding connection token MUST
be transmitted. The Persist header MUST be ignored if received without
the connection token.
10.9 Content-Base
The Content-Base entity-header field may be used that as soon as any variant of a URI
becomes stale, all variants becomes stale as well. Thus, "freshness"
applies to specify all the base variants of URI, rather than any particular variant.
Dates and expires etc. apply to any cached variant that a proxy might
have with a URI
for resolving relative URLs within and not just the one particular entity.
Editor's note: This header field is
described as "Base" restriction may be dropped in RFC 1808 [11], which the next draft; there
are still discussions about whether this restriction is expected to be revised
soon.
Content-Base = "Content-Base" ":" absoluteURI
If no Content-Base field needed.
16.2.7 Disambiguating Expiration Values
Because expiration values are assigned optimistically, it is present, possible
that two caches may contain fresh values for the base URI of an same resource that are
different.
If a client performing a retrieval receives a non-firsthand response for
a resource entity is
defined either by that was already fresh in its Content-Location or the URI used to initiate own cache, and the
request, Date
header in that order of precedence. Note, however, that its existing cache entry is newer than the base URI
of Date on the contents within new
response, then the entity body may be redefined within that
entity body.
10.10 Content-Encoding
The Content-Encoding entity-header field is used as client MAY ignore the response. If so, it MAY retry
the request with a modifier "Cache-Control: max-age=0" directive (see section
18.10), to force a check with the
media-type. When present, its value indicates what additional content
codings have been applied to origin server.
If a cache that is pooling cached responses from other caches sees two
fresh responses for the resource, and thus what decoding
mechanisms MUST same resource entity with different validators,
it SHOULD use the one with the newer Date header.
16.2.8 Disambiguating Multiple Responses
Because a client may be applied receiving responses via multiple paths, so that
some responses flow through one set of caches and other responses flow
through a different set of caches, a client may receive responses in an
order different from that in which the origin server generated them. We
would like the client to obtain use the media-type referenced
by most recently generated response, even
if older responses are still apparently fresh.
Neither the Content-Type header field. Content-Encoding entity tag nor the expiration value can impose an ordering
on responses, since it is primarily used possible that a later response intentionally
carries an earlier expiration time. However, the HTTP/1.1 specification
requires the transmission of Date headers on every response, and the
Date values are ordered to
allow a document granularity of one second.
If a client performs a request for a resource entity that it already has
in its cache, and the response it receives contains a Date header that
appears to be compressed without losing older than the identity of one it already has in its
underlying media type.
Content-Encoding = "Content-Encoding" ":" 1#content-coding cache, then the
client SHOULD repeat the request unconditionally, and include
Cache-Control: max-age=0
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 78] 67]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Content codings are defined in Section 3.5. An example of its use is
Content-Encoding: gzip
The Content-Encoding is a characteristic of the resource identified by
the Request-URI. Typically, the resource is stored
to force any intermediate caches to validate their copies directly with this encoding
and is only decoded before rendering
the origin server, or analogous usage.
If multiple encodings have been applied
Cache-Control: no-cache
to force any intermediate caches to obtain a resource, the content
codings MUST be listed in the order in which they were applied.
Additional information about new copy from the encoding parameters MAY be provided by
other Entity-Header fields not defined by this specification.
10.11 Content-Language
The Content-Language entity-header field describes origin
server. This prevents certain paradoxes arising from the natural
language(s) use of multiple
caches.
If the intended audience for Date values are equal, then the enclosed entity. Note that
this client may not be equivalent to all the languages used within the entity.
Content-Language = "Content-Language" ":" 1#language-tag
Language tags are defined in Section 3.10. The primary purpose of
Content-Language use either response
(or may, if it is to allow being extremely prudent, request a selective consumer to identify and
differentiate resources according new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the consumer's own preferred
language. Thus, if the body content is intended only for same second, if
their expiration times overlap.
16.3 Validation Model
When a Danish-
literate audience, the appropriate field is
Content-Language: dk
If no Content-Language is specified, the default is cache has a stale entry that it would like to use as a response
to a client's request, it first has to check with the content origin server (or
possibly an intermediate cache with a fresh response) to see if its
cached entry is
intended for all language audiences. This may mean that still usable. We call this "validating" the sender does cache
entry.
Since we do not consider it want to be specific have to any natural language, or that pay the
sender does overhead of retransmitting the
full response if the cached entry is good, and we do not know want to pay the
overhead of an extra round trip if the cached entry is invalid, the
HTTP/1.1 protocol supports the use of conditional methods.
The key protocol features for which language supporting conditional methods are those
concerned with "cache validators." When an origin server generates a
full response, it attaches some sort of validator to it, which is intended.
Multiple languages MAY be listed kept
with the cache entry. When a client (end-user or cache) makes a
conditional request for content that is intended a resource for
multiple audiences. For example, which it has a rendition of cache entry, it
includes the _Treaty of
Waitangi,_ presented simultaneously associated validator in the original Maori and English
versions, would call request.
The server then checks that validator against the current validator for
Content-Language: mi, en
However, just because multiple languages are present within an
the resource entity, and, if they match, it responds with a special
status code (usually, "304 Not Modified") and no entity body.
Otherwise,
it returns a full response (including entity body). Thus, we avoid
transmitting the full response if the validator matches, and we avoid an
extra round trip if it does not mean match.
Note: the comparison functions used to decide if validators match
are defined in section 16.3.3.
In HTTP/1.1, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special header
(which includes the validator) that implicitly turns the method
(usually, GET) into a conditional.
The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is intended for multiple linguistic audiences. An
example would be possible to request either that a beginner's language primer, such as _A First Lesson
method be performed if and only if the validators match, or if and only
if the validators do not match.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79] 68]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
in Latin,_ which is clearly intended to
Note: a response that lacks a cache validator may still be used by an English-literate
audience. In cached,
and served from cache until it expires, unless this case, is explicitly
prohibited by a Cache-Control directive. However, a cache cannot do
a conditional retrieval if it does not have a cache validator for
the Content-Language should only include _en_.
Content-Language MAY be applied to any media type -- entity, which means it SHOULD will not be
limited to textual documents.
10.12 Content-Length
The Content-Length entity-header field indicates refreshable after it
expires.
16.3.1 Last-modified Dates
In HTTP/1.0, the size of only cache validator is the Entity-
Body, in decimal number of octets, sent to Last-Modified time carried
by a response. Clients validate entities using the recipient or, in If-Modified-Since
header. In simple terms, a cache entry is considered to be valid if the case
of
actual resource entity has not been modified since the HEAD method, original response
was generated.
16.3.2 Entity Tags
HTTP/1.1 introduces the size possibility of using an "opaque" validator,
called an "entity tag," for situations where the Entity-Body that would have been
sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example Last-Modified date is
Content-Length: 3495
Applications SHOULD use this field
not appropriate. This may include server implementations where it is not
convenient to indicate store modification dates, or where the size one-second
resolution of HTTP date values is insufficient, or where the Entity-
Body origin
server wishes to be transferred, regardless of avoid certain paradoxes that may arise from the media type use of the entity. A
valid Content-Length field value is required on all HTTP/1.1 request
messages containing an
modification dates.
An entity body.
Any Content-Length greater than or equal to zero tag is simply a valid value.
Section 7.2.2 describes how to determine the length string of an Entity-Body if
a Content-Length octets whose internal structure is
not given.
Note: The meaning of this field is significantly different from
the corresponding definition in MIME, where known to clients or caches. Caches store entity tags and return them
when making conditional requests. Also, when a cache receives a
conditional request for a resource for which it is an optional
field used within the _message/external-body_ content-type. In
HTTP, has a fresh cache
entry,
it SHOULD be used whenever may compare entity tags using strict octet-equality. Otherwise,
entity tags have no semantic value to clients or caches.
To preserve compatibility with HTTP/1.0 clients and caches, and because
the entity's length can Last-Modified date may be
determined prior to being transferred.
10.13 Content-MD5 useful for purposes other than cache
validation, HTTP/1.1 servers SHOULD send Last-Modified whenever
feasible.
The Content-MD5 entity-header field is an MD5 digest of the entity-body,
as defined headers used to convey entity tags are described in RFC 1864 [23], for the purpose of providing an end-to-end
message integrity check (MIC) of sections Error!
Reference source not found., Error! Reference source not found., 18.26,
and 18.46.
16.3.3 Weak and Strong Validators
Since both origin servers and caches will compare two validator values
to decide if they represent the entity-body. (Note: an MIC is good
for detecting accidental modification of same or different resource entities, one
normally would expect that if the entity-body resource entity (the entity body or
any entity headers) changes in transit, but any way, then the associated validator
would change as well. If this is true, then we call this validator a
"strong validator."
However, there may be cases when a server prefers to change the
validator only on semantically significant changes, and not proof against malicious attacks.)
ContentMD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> when
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80] 69]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
The Content-MD5 header may be generated by an origin server to function
as an integrity check
insignificant aspects of the entity-body. Only origin-servers may
generate resource entity change. A validator that
does not always change when the Content-MD5 header field; proxies and gateways MUST NOT
generate it, as this would defeat its value as an end-to-end integrity
check. Any recipient resource changes is a "weak validator."
One can think of the entity-body, including gateways and proxies,
MAY check a strong validator as one that changes whenever the digest value in this header field matches that
bits of an entity changes, while a weak value changes whenever the
entity-body
meaning of an entity changes. Alternatively, one can think of a strong
validator as received.
The MD5 digest part of an identifier for a specific entity, while a weak
validator is computed based on the content part of the entity body,
including any Content-Encoding an identifier for a set of semantically equivalent
entities.
Note: One example of a strong validator is an integer that has been applied, but not including
any Transfer-Encoding. If the is
incremented in stable storage every time an entity is received changed.
An entity's modification time, if represented with one-second
resolution, could be a Transfer-
Encoding, weak validator, since it is possible that encoding must
the resource entity may be removed prior to checking modified twice during a single second.
Entity tags are normally "strong validators," but the Content-
MD5 value against protocol provides
a mechanism to tag an entity tag as "weak."
A "use" of a validator is either when a client generates a request and
includes the received validator in a validating header field, or when a server
compares two validators.
Strong validators are usable in any context. Weak validators are only
usable in contexts that do not depend on exact equality of an entity.
This has
For example, either kind is usable for a conditional GET of a full
entity. However, only a strong validator is usable for a sub-range
retrieval, since otherwise the result client may end up with an internally
inconsistent entity body.
The only function that the digest HTTP/1.1 protocol defines on validators is computed
comparison. There are two validator comparison functions, depending on
whether the octets of comparison context allows the
entity body exactly as, and use of weak validators or
not:
. The strong comparison function: in the order that, they would be sent if no
Transfer-Encoding were being applied.
HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* considered equal,
both validators must be identical in every way, and message/rfc822), neither may be
weak.
. The weak comparison function: in order to be considered equal, both
validators must be identical in every way, but this
does not change how either or both of
them may be tagged as "weak" without affecting the digest result.
The weak comparison function SHOULD be used for simple (non-subrange)
GET requests. The strong comparison function MUST be used in all other
cases.
An entity tag is computed strong unless it is explicitly tagged as defined in weak. Section
16.3 gives the preceding
paragraph.
Note: There are several consequences of this. The entity-body syntax for composite types many contain many body-parts, each with its
own MIME and HTTP headers (including Content-MD5, Content-
Transfer-Encoding, and Content-Encoding headers). If entity tags.
A Last-Modified time, when used as a body-part
has validator in a Content-Transfer-Encoding or Content-Encoding header, request, is
implicitly weak unless it is assumed possible to deduce that the content of the body-part has had the
encoding applied, and the body-part it is included in strong, using
the Content-
MD5 digest as is -- i.e., after the application. Also, the HTTP
Transfer-Encoding header makes no sense within body-parts; if it
is present, it is ignored -- i.e. treated as ordinary text.
Note: while the definition of Content-MD5 following rules:
. The validator is exactly being compared by an origin server to the same
for HTTP as in RFC 1864 actual
current validator for MIME entity-bodies, there are
several ways in which the application of Content-MD5 to HTTP
entity-bodies differs from its application to MIME entity-
bodies. One is that HTTP, unlike MIME, does not use Content-
Transfer-Encoding, and does use Transfer-Encoding entity and,
Fielding, Frystyk, Berners-Lee, Gettys, and Content-
Encoding. Another is that HTTP more frequently uses binary
content types than MIME, so it is worth noting Mogul [Page 70]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
. That origin server reliably knows that in such
cases, the byte order used to compute associated entity did
not change twice during the digest second covered by the presented
validator. or
. The validator is about to be used by a client in an If-Modified-
Since or If-Unmodified-Since header, because the
transmission byte order defined client has a cache
entry for the type. Lastly, HTTP
allows transmission of text types with any of several line break
conventions associated entity, and not just
. That cache entry includes a Date value, which gives the canonical form using CR-LF.
Conversion of all line breaks to CR-LF should not be done time when
the origin server generated the original response, and
. The presented Last-Modified time is at least 60 seconds before
computing or checking the digest:
Date value. or
. The validator is being compared by an intermediate cache to the line break convention used
validator stored in its cache entry for the text actually transmitted should be left unaltered entity, and
. That cache entry includes a Date value, which gives the time when
computing
the digest.
Fielding, Frystyk, Berners-Lee, Gettys, origin server generated the original response, and Mogul [Page 81]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
10.14 SLUSHY Content-Range
. The Content-Range header presented Last-Modified time is sent with a partial entity body to specify
where in at least 60 seconds before the full entity body
Date value.
This method relies on the partial body should be inserted. It
also indicates fact that if two different responses were
generated by the total size origin server during the same second, but both had the
same Last-Modified time, then at least one of those responses would have
a Date value equal to its Last-Modified time. The arbitrary 60-second
limit guards against the entity.
Content-Range = "Content-Range" ":" content-range-spec
When an HTTP message includes possibility that the content Date and Last-Modified
values are generated from different clocks, or at somewhat different
times during the preparation of the response. An implementation may use
a single range (for
example, value larger than 60 seconds, if it is believed that 60 seconds is too
short.
If a response client wishes to perform a request for sub-range retrieval on a single range, or to request value for which
it has only a
set of ranges that overlap without any holes), Last-Modified time and no opaque validator, it may do this content
only if the Last-Modified time is
transmitted with a Content-Range header, and a Content-length header
showing strong in the number of bytes actually transferred.
For example, sense described here.
A cache or origin server receiving a cache-conditional request, other
than a full-body GET request, must use the strong comparison function to
evaluate the condition.
These rules allow HTTP/1.1 caches and clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-range: 21010-47021/47022
Content-length: 26012
Content-type: image/gif
10.14.1 MIME multipart/byteranges content-type
servers.
16.3.4 Rules for When an HTTP message includes the content of multiple ranges (for
example, a response to Use Entity Tags and Last-modified Dates
We adopt a request set of rules and recommendations for multiple non-overlapping ranges),
these are transmitted as a multipart MIME message. The multipart MIME
content-type used origin servers,
clients,
and caches regarding when various validator types should be used, and
for this purpose what purposes.
HTTP/1.1 origin servers:
. SHOULD send an entity tag validator unless performance
considerations support the use of weak entity tags, or unless it is defined in this specification
unfeasible to
be "multipart/byteranges".
The MIME multipart/byteranges content-type includes two or more parts,
each with its own Content-type and Content-Range fields. The parts are
separated using send a MIME boundary parameter.
For example: strong entity tag.
. MAY send a weak entity tag instead of a strong one.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82] 71]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
HTTP/1.0 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...the second range...
--THIS_STRING_SEPARATES_
10.14.2 Additional rules for Content-Range
A client that cannot decode a MIME multipart/byteranges message should
. MAY send no entity tag if it is not ask for multiple byte-ranges in a single request.
When feasible to generate one.
. SHOULD send a client requests multiple byte-ranges in one request, Last-Modified value if it is feasible to send one,
unless the server
SHOULD return them risk of a breakdown in the order semantic transparency that they appeared could
result from using this date in an If-Modified-Since header would
lead to serious problems.
In other words, the request.
If the preferred behavior for an HTTP/1.1 origin server ignores a byte-range-spec because it is invalid, or
because it specifies
to send both a range that starts beyond the end of the entity,
it may omit the corresponding Content-Range field strong entity tag and partial a Last-Modified value.
In order to be legal, a strong entity
body.
If none of tag MUST change whenever the byte-range-spec values
associated entity value changes in a request specify part of the
current any way. A weak entity (i.e., start before the last byte of the entity), then tag SHOULD
change whenever the associated entity changes in a semantically
significant way.
Note: in order to provide semantically transparent caching, an
origin server should return avoid reusing a status specific strong entity tag
value for two different resource entities, or reusing a specific
weak entity tag value for two semantically different instances of 207 (Range Out Of Bounds).
10.15 Content-Type
The Content-Type entity-header field indicates the media type a
resource entity. Cache entries may persist for arbitrarily long
periods, regardless of the
Entity-Body sent expiration times, so it may be inappropriate
to the recipient or, in the case of the HEAD method,
the media type expect that would have been sent had the request been a GET.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
Content-Type = "Content-Type" ":" media-type
Media types are defined cache will never again attempt to validate an
entry using a validator that it obtained at some point in Section 3.7. An example of the field is
Further discussion of methods for identifying the media type of past.
HTTP/1.1 clients:
. If an entity is tag has been provided in Section 7.2.1. Content-Type: text/html; charset=ISO-8859-4
10.16 Content-Location
The Content-Location entity-header field is used to define the location
of the specific resource associated with by the origin server, MUST use
that entity enclosed tag in any cache-conditional request (using If-Match or
If-NoneMatch).
. If only a Last-Modified value has been provided by the
message. A server origin
server, SHOULD provide use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
. If only a Content-Location if, when including Last-Modified value has been provided by an entity HTTP/1.0
origin server, MAY use that value in response to a GET request on subrange cache-conditional
requests (using If-Unmodified-Since:). The user agent should
provide a negotiated resource, the
entity corresponds way to disable this, in case of difficulty.
. If both an entity tag and a specific, non-negotiated location which can be
accessed via Last-Modified value have been provided
by the Content-Location URI. A server origin server, SHOULD provide a
Content-Location with any 200 (OK) response which was internally (not
visible to the client) redirected use both validators in cache-
conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches
to respond appropriately.
An HTTP/1.1 cache, upon receiving a resource other than request, MUST use the one
identified by most
restrictive validator when deciding whether the request and for which correct interpretation of that
resource MAY require knowledge of its actual location. The recipient MAY
make future requests on this location instead of on client's cache entry
matches the Request-URI.
Content-Location = "Content-Location" ":" absoluteURI
If no Content-Base header field cache's own cache entry. This is present, the value of Content-
Location also defines the base URL for the entity (see Section 10.9).
Note: Since the Content-Location field re-interprets only an issue when the source
of
request contains both an entity, recipients must take care in not allowing entity tag and a
_spoofed_ location to deny access to the real resource. This is
described in Section 15.9.
10.17 Date last-modified-date validator
(If-Modified-Since or If-Unmodified-Since).
A note on rationale: The Date general-header field represents the date general principle behind these rules is
that HTTP/1.1 servers and time at which the
message was originated, having the same semantics clients should transmit as orig-date in RFC
822. The field value is an HTTP-date, much non-
redundant information as described in Section 3.3.
Date = "Date" ":" HTTP-date
An example is available in their responses and
requests. HTTP/1.1 systems receiving this information will make the
most conservative assumptions about the validators they receive.
HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or used by these systems will support
transparent and efficient caching, and so HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 84] 72]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Date: Tue, 15 Nov 1994 08:12:31 GMT
If
use of a message is received via direct connection with Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
should not provide one.
16.3.5 Non-validating Conditionals
The principle behind entity tags is that only the user agent (in service author knows
the case semantics of requests) or the origin server (in a resource well enough to select an appropriate cache
validation mechanism, and the case specification of responses),
then the date any validator comparison
function more complex than byte-equality would open up a can be assumed to be the current date at the receiving
end. However, since the date--as it is believed by the origin--is
important of worms.
Thus, comparisons of any other headers (except Last-Modified, for evaluating cached responses, origin servers SHOULD always
include a Date header. Clients SHOULD only send
compatibility with HTTP/1.0) are never used for purposes of validating a Date header field in
messages that include
cache entry.
16.4 Constructing Responses From Caches
The purpose of an entity body, as HTTP cache is to store information received in
response to requests, for use in responding to future requests. In many
cases, a cache simply returns the case appropriate parts of the PUT and POST
requests, and even then it is optional. A received message which does
not have a Date header field SHOULD be assigned one by response to the recipient
requester. However, if the message will be cached by that recipient or gatewayed via cache holds a protocol
which requires cache entry based on a Date.
In theory, the date SHOULD represent the moment just before the entity previous
response, it may have to combine parts of a new response with what is generated. In practice,
held in the date can be generated at any time during cache entry.
16.4.1 End-to-end and Hop-by-hop Headers
For the message origination without affecting its semantic value.
Note: An earlier version purpose of this document incorrectly specified
that this field SHOULD contain defining the creation date behavior of the enclosed
Entity-Body. This has been changed caches and non-caching
proxies, we divide HTTP headers into two categories:
. End-to-end headers, which must be transmitted to reflect actual (and
proper) usage.
Origin servers MUST send the ultimate
recipient of a Date field in every request or response. However, if End-to-end headers in responses
must be stored as part of a cache receives a entry and transmitted in any
response without formed from a Date field, it SHOULD attach one
with the cache's best estimate of the time at cache entry.
. Hop-by-hop headers, which the response was
originally generated.
The format of the Date is an absolute date are meaningful only for a single
transport-level connection, and time as are not stored by caches or
forwarded by proxies.
The following HTTP/1.1 headers are hop-by-hop headers:
. Connection
. Keep-Alive
. Upgrade
. Public
. Proxy-Authenticate
. Transfer-Encoding
All other headers defined by HTTP-
date HTTP/1.1 are end-to-end headers.
Hop-by-hop headers introduced in Section 3.3; it future versions of HTTP MUST be listed
in RFC1123-date format.
10.19 SLUSHY Expires
The Expires entity-header field gives a Connection header, as described in section 18.11.
16.4.2 Non-modifiable Headers
Some features of the date/time after which HTTP/1.1 protocol, such as Digest Authentication,
depend on the
entity should be considered stale. value of certain end-to-end headers. A stale cache entry may not normally
be returned by a cache (either a proxy cache or non-
caching proxy SHOULD NOT modify an end-user cache) end-to-end header unless it is first validated with the origin server (or with an
intermediate cache that has a fresh copy of the resource). See section
13.2 for further discussion of the expiration model.
The presence
definition of an Expires field does not imply that the original
resource will change or cease to exist at, before, header requires or after that time.
The format is an absolute date and time as defined by HTTP-date in
Section 3.3; it MUST be in rfc1123-date format:
Expires = "Expires" ":" HTTP-date specifically allows that.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 85] 73]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
An example
A cache or non-caching proxy MUST NOT modify any of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: the following fields
in a request or response, nor may it add any of these fields if not
already present:
. Content-Type
. Content-Encoding
. Content-Length
. Expires
. Last-Modified
. Content-Range
. Content-Location
Warning: unnecessary modification of end-to-end headers may cause
authentication failures if stronger authentication mechanisms are
introduced in later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
16.4.3 Combining Headers
When a response includes cache makes a Cache-Control field with the max-
age directive, that directive overrides the Expires field.
HTTP/1.1 clients validating request to a server, and caches MUST treat other invalid date formats,
especially including the value _0_, as in server
provides a 304 Not Modified response, the past (i.e., _already
expired_).
To mark cache must construct a
response as _already expired,_ an origin server should use an
Expires date that is equal to send to the Date header value. (See requesting client. The cache uses the rules for
expiration calculations entity-
body stored in section 13.2.7.)
To mark a response the cache entry as _never expires,_ an origin server should use
Expires date approximately one year from the time entity-body of this outgoing
response. It uses the response is
generated. HTTP/1.1 servers should end-to-end headers from the incoming response, not send Expires dates more than one
year in
from the future.
10.20 Via
The Via general-header field MUST be used by gateways and proxies cache entry. Unless it decides to
indicate the intermediate protocols and recipients between remove the user
agent and cache entry, it
must also replace the server on requests, and between end-to-end headers stored with the origin server and cache entry
with those received in the
client on responses. It is analogous to incoming response.
In other words, the _Received_ field complete set of RFC 822
[9]and is intended to be used for tracking message forwards, avoiding
request loops, and identifying end-to-end headers received in the protocol capabilities of
incoming response overrides all senders
along end-to-end headers stored with the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token cache
entry. The received-protocol indicates cache may add Warning headers (see section 18.48) to this
set.
A cache MUST preserve the protocol version order of the message all headers as received in an
incoming response.
These rule allows an origin server to completely control the response
seen by the server or client along each segment of a cache when the cache revalidates an entry, and
may be necessary for preserving semantic transparency or for certain
kinds of security mechanisms or future extensions.
16.4.4 Combining Byte Ranges
A response may transfer only a subrange of the bytes of an entity,
either because the request included one or more Range specifications, or
because a connection was broken prematurely. After several such
transfers, a cache may have received several ranges of the same entity.
If a cache has a stored non-empty set of subranges for an entity, and an
incoming response transfers another subrange, the cache MAY combine the
new subrange with the existing set if both the following conditions are
met:
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 86] 74]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
request/response chain. The received-protocol version is appended to
the Via field value when
. Both the message is forwarded so that information
about incoming response and the protocol capabilities of upstream applications remains visible
to all recipients. cache entry must have a cache
validator.
. The protocol-name two cache validators must match using the strong comparison
function (see section 16.3.3).
If either requirement is optional if and not meant, the cache must use only if it would be _HTTP_. The
received-by field is normally the host most
recent partial response (based on the Date values transmitted with every
response, and optional port number of a
recipient server or client that subsequently forwarded using the message.
However, incoming response if these values are equal or
missing), and must discard the real host is considered other partial information.
16.5 Caching and Generic Resources
Generic resources interacts with caching in several ways:
. A generic resource (one subject to content negotiation) may be sensitive information, it
MAY be replaced by
bound to more than one entity. Each of these entities is called a pseudonym. If
"variant" of the port is not given, it MAY be
assumed to resource.
. The request-URI may be the default port only one part of the received-protocol.
Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each recipient MUST append their information
such that cache key.
16.5.1 Vary Header Use
Origin servers may respond to requests for generic resources use the end result is ordered according
Vary header (see section 18.46 for a full description) to inform the sequence
cache which header fields of
forwarding applications.
Comments MAY be the request were used to select the variant
returned in the Via header field response. A cache can use that response to identify reply to a
subsequent request only if the software of two requests not only specify the recipient proxy or gateway, analogous to same
URI, but also have the User-Agent and Server
header fields. However, same value for all comments headers specified in the Via field are optional and
MAY be removed by any recipient prior to forwarding Vary
response-header.
The Vary header may also inform the message.
For example, a request message could be sent from an HTTP/1.0 user agent
to an internal proxy code-named _fred_, which uses HTTP/1.1 cache that the variant was selected
using criteria not limited to forward the request headers; in this case, the
response MUST NOT be used in a reply to a public proxy at nowhere.com, which completes subsequent request except if
the cache relays the new request by forwarding it to the origin server at www.ics.uci.edu. The
request received by www.ics.uci.edu would then have in a conditional
request, and the following Via
header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies origin server responds with 304 (Not Modified) and gateways used as
includes the same variant-ID (see 13.8.3).
16.5.2 Alternates Header Use
The Alternates header is present in the HTTP/1.1 to enable caching of
entities from the planned content negotiation facilities. If a portal through cache
receives an Alternates header in a network firewall SHOULD
NOT, by default, forward response from the names and ports of hosts within origin server (and
implement these planned facilities), it should act as if the
firewall region. response
carried a "Vary:{accept-headers}" header. This information SHOULD only means that the response
may be propagated if
explicitly enabled. If not enabled, returned in reply to a subsequent request with Accept-* headers
identical to those in the received-by host of any host
behind current request.
16.5.3 Variant-ID Use
If an origin server chooses to use the firewall SHOULD variant-ID mechanism, it assigns
a variant-ID (see section 7.12) to each distinct resource entity
(variant). This assignment can only be replaced made by an the origin server. It
then returns the appropriate pseudonym for
that host.
For organizations variant-ID with each response that have strong privacy requirements for hiding
internal structures, applies
to a proxy MAY combine an ordered subsequence of Via specific resource entity (variant), using the ETag header field entries with identical received-protocol values into a
single such entry. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy (see
Error! Reference source not found.).
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 87] 75]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, Friday, May 03, 1996
Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values.
Note: The Via header field replaces the Forwarded header field
which was present
When sending an entity derived from a particular variant in earlier drafts of this specification.
10.21 From
The From request-header field, if given, SHOULD contain a response,
an Internet e-
mail address for the human user who controls the requesting user agent.
The address origin server SHOULD be machine-usable, as defined by mailbox include a variant-ID identifying the variant in RFC 822
[9] (as updated by RFC 1123 [8]):
From = "From" ":" mailbox
An example is:
From: webmaster@w3.org
This
the ETag header field MAY (see section Error! Reference source not found.). This
variant-ID can be used for logging purposes cache replacement and as in conditional requests
on the generic resource. When a means cache receives a successful response
with a variant-ID, it SHOULD use this information to replace any
existing cache entries for
identifying the source of invalid or unwanted requests. It SHOULD NOT be
used as an insecure form same variant of access protection. The interpretation the corresponding URI.
That is, it forms a cache key using the URI of
this field is that the request is being performed on behalf and the
variant-ID of the
person given, who accepts responsibility for response. If this key matches the method performed. In
particular, robot agents key of an existing
cache entry, it SHOULD include this header so that replace the person
responsible for running existing entry with the robot can be contacted if problems occur on new response
(subject to all of the receiving end.
The Internet e-mail address in this field MAY be separate from the
Internet host which issued the request. For example, when other rules on caching). See section Error!
Reference source not found. for more details on update.
When a cache performs a conditional request is
passed through on a proxy the original issuer's address SHOULD be used.
Note: The client SHOULD not send the From header field without
the user's approval, as generic resource, and
it may conflict with the user's privacy
interests has one or their site's security policy. It is strongly
recommended that the user be able to disable, enable, and modify
the value of this field at any time prior to a request.
10.22 Host
The Host request-header field specifies the Internet host and port
number of more cache entries for the resource being requested, as obtained from the original
URL given by that include variant-
IDs, the user or referring resource (generally an HTTP URL, as
described in Section 3.2.2). The Host field value cache MUST represent transmit the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 88]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
network location of (cache-validator, variant-ID) tuples in
the origin server or gateway given by conditional request, using the original
URL. variant-set mechanism (see section
7.13). This allows tells the origin server or gateway to differentiate between
internally-ambiguous URLs, such as which variants are currently in the root _/_ URL of a server for
multiple host names on
requester's cache.
The client MAY choose to transmit only a single IP address.
Host = "Host" ":" host [ ":" port ] ; see Section 3.2.2
_host_ without any trailing port information implies the default port
for subset of the service requested (e.g., _80_ (cache-
validator, variant-ID) tuples corresponding to its cache entries
for an HTTP URL). For example, this resource.
When a
request on the origin server for <http://www.w3.org/pub/WWW/> MUST
include:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
The header field MUST be included in all HTTP/1.1 request messages A Host
on the Internet (i.e., on any message corresponding to receives a conditional request for a
URL which that includes an Internet host address for the service being
requested). If the Host field is not already present, an HTTP/1.1 proxy
MUST add a Host field to variant-
set, and the request message prior server is able to forwarding it on
the Internet. All Internet-based HTTP/1.1 servers MUST respond reply with a
400 status code to any HTTP/1.1 request message which lacks a Host
header field.
10.23 If-Modified-Since
The If-Modified-Since request-header field an appropriate variant
(either
because it is used with the GET method
to make origin server, or because it conditional: if is an intermediate cache
that can properly implement the requested resource variant selection algorithm), once it
has not been modified
since selected the time specified in this field, a copy variant it should examine the elements of the resource will not
be returned from supplied
variant-set. If one of these matches the server; instead, a 304 (not modified) response will
be returned without any Entity-Body.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
An example variant-ID of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A GET method with an If-Modified-Since header selected
variant, and no Range header
requests that the identified resource be transferred only if it has been
modified since the date given by the If-Modified-Since header. The
algorithm for determining this includes cache validators match, the following cases:
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 89]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
a)
If the request would normally result in anything other than server SHOULD reply with
a 200
(ok) status, or if 304 (Not Modified) response, including the passed If-Modified-Since date is invalid, variant-ID of the
response is exactly selected
variant. Otherwise, the same server should reply as for a normal GET. A date which is
later than the server's current time is invalid.
b)
If if the resource has been modified since request were
unconditional.
The server may optionally use the If-Modified-Since date, variant-set information in its
selection algorithm. For example, if the response selection algorithm yields
several variants with equal preference, and one of these is exactly the same as for a normal GET.
c)
If already in
the resource has not been modified since a valid If-Modified-Since
date, requester's cache, the server MUST return a 304 (not modified) response.
The purpose of this feature could select that variant and avoid an
extra data transfer. This is to allow efficient updates of cached
information with a minimum amount of transaction overhead.
Note that performance optimization; otherwise, the Range request-header field modifies
variant-selection mechanism is orthogonal to the meaning variant-ID mechanism.
16.6 Shared and Non-Shared Caches
For reasons of
If-Modified-Since; see section 13.9 for full details.
Note that If-Modified-Since security and privacy, it is ignored for varying resources.
Note necessary to make a
distinction between "shared" and "non-shared" caches. A non-shared cache
is one that If-Modified-Since times are interpreted is accessible only to a single user. Accessibility in this
case SHOULD be enforced by the server,
whose clock may not appropriate security mechanisms. All other
caches are considered to be synchronized with "shared." Other sections of this
specification place certain constraints on the client.
Note that if a client uses an arbitrary date operation of shared
caches in the If-Modified-
Since header instead order to prevent loss of privacy or failure of access controls
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76]
INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
16.7 Selecting a date taken from the Last-Modified
header Cached Response
When a cache receives a request it tries to see if it has a cached
response appropriate for the same that request, using the client should be aware of the
fact that matching rules in this date
section. If such a response exists, then the cache can decide if it is interpreted
fresh enough (using the expiration model in section 16.1.2 and the server's understanding
freshness requirements of time. The client should consider unsynchronized clocks and
rounding problems due to origin-server expressed in the different representations
Cache-Control headers of time
between the client request and server. This includes cached response) to return in
reply to the possibility of
race conditions if request.
If on a cache lookup there are two or more fresh entries that appear to
match the document has changed between request, then the time it one with the most recent Date value MUST be
used.
16.7.1 Plain Resources
If the cached response was first for a plain resource (that is, the response
includes no Vary or Alternates headers), it matches if the Request-URI
of the request and matches the If-Modified-Since date Request-URI of a subsequent
request, and the possibility of clock-skew-related problems if the If-Modified-Date date is derived from request that caused
the client's clock
without correction cached response to be stored. Request-URIs match if their canonical
forms (see section 7.2.3) are equal.
16.7.2 Generic Resources
If the server's clock. Corrections cached response was for
different time bases between client and server are at best
approximate due to network latency.
10.25 Last-Modified
The Last-Modified entity-header field indicates the date and time at
which the sender believes the a generic resource was last modified. The exact
semantics of this field are defined in terms of how (that is, the recipient SHOULD
interpret it: response
includes Vary, or Alternates headers), it matches if the recipient has a copy Request-URI of this resource which is
older than
the date given by request matches the Last-Modified field, Request-URI of the request that copy SHOULD caused the
cached response to be considered stale.
Last-Modified = "Last-Modified" ":" HTTP-date
Fielding, Frystyk, Berners-Lee, Gettys, stored, and Mogul [Page 90]
INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996
An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
The exact meaning of this the selecting request header field depends on the implementation
values of the sender and the nature request match those of the original resource. For files, it may be
just request that caused the file system last-modified time. For entities with dynamically
included parts, it may cached
response to be stored. (See section 18.46 on Vary, which defines the most recent of
canonical form for selecting request headers and the set of last-modify
times matching rules for its component parts. For database gateways, it may be
them.)
If the
last-update time stamp of response contains "Vary: {other}", then the record. For virtual objects, it selecting request
header field values for its request are defined as never matching a set
of request headers.
16.8 Errors or In