WDIFF

draft-ietf-http-v11-spec-03.txt --> draft-ietf-http-v11-spec-04.txt

HTTP Working Group R. Fielding, UC Irvine
INTERNET-DRAFT H. Frystyk, MIT/LCS
<draft-ietf-http-v11-spec-03.html>
<draft-ietf-http-v11-spec-04> T. Berners-Lee, MIT/LCS
J. Gettys, DEC
J. C. Mogul, DEC
Expires October 2, 3, 1996 May 2, June 3, 1996

Hypertext Transfer Protocol -- HTTP/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 in progress".

To learn the current status of any Internet-Draft, please check the
"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.

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). methods. 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 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".

3 Note to Readers of This Document

We believe this draft to be very close to consensus of the working group
in terms of functionality for HTTP/1.1, and the text substantially
correct. One final technical change NOT reflected in this draft is to
make persistent connections the default behavior for HTTP/1.1; editorial
changes to reflect this in the next, and we hope final draft, are being
circulated in the working group mailing list.

This draft has undergone extensive reorganization to improve
presentation. Let us know if there are remaining problems.

The terminology used in this draft has changed to reduce confusion.
While we are converging on a 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 that may occur to improve
the presentation of the specification, we do not expect to change the
name of any header field or parameter name.

There are a very few remaining issues indicated by Editor's Note: in
bold font.

Fielding, Frystyk, Berners-Lee, Gettys, Gettys and Mogul [Page 2]

4 1]

Table of Contents

HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1 HTTP/1.1................................1

1 Status of this Memo

2 Abstract

3 Note to Readers of This Document

4 Table of Contents

5 Introduction
5.1 Introduction.........................................................7
1.1 Purpose
5.2 ..........................................................7
1.2 Requirements
5.3 .....................................................7
1.3 Terminology
5.4 ......................................................8
1.4 Overall Operation
5.5 HTTP and MIME

6 ...............................................11

2 Notational Conventions and Generic Grammar
6.1 Grammar..........................13
2.1 Augmented BNF
6.2 ...................................................13
2.2 Basic Rules

7 .....................................................14

3 Protocol Parameters
7.1 Parameters.................................................16
3.1 HTTP Version
7.2 ....................................................16
3.2 Uniform Resource Identifiers
7.3 ....................................17
3.3 Date/Time Formats
7.4 ...............................................19
3.4 Character Sets
7.5 ..................................................21
3.5 Content Codings
7.6 .................................................21
3.6 Transfer Codings
7.7 ................................................22
3.7 Media Types
7.8 .....................................................24
3.8 Product Tokens
7.9 ..................................................26
3.9 Quality Values
7.10 ..................................................26
3.10 Language Tags
7.11 ..................................................26
3.11 Entity Tags
7.12 Variant IDs
7.13 Variant Sets
7.14 ....................................................27
3.12 Range Protocol Parameters

8 Units ....................................................28

4 HTTP Message
8.1 Message........................................................28
4.1 Message Types
8.2 ...................................................28
4.2 Message Headers
8.3 .................................................29
4.3 Message Body ....................................................29
4.4 Message Length ..................................................30
4.5 General Header Fields

9 Request
9.1 ...........................................31

5 Request.............................................................32
5.1 Request-Line
9.2 ....................................................32
5.2 The Resource Identified by a Request
9.3 ............................34
5.3 Request Header Fields

10 Response
10.1 ...........................................35

6 Response............................................................35
6.1 Status-Line
10.2 .....................................................36
6.2 Response Header Fields ..........................................38

7 Entity..............................................................38
7.1 Entity Header Fields ............................................38
7.2 Entity Body .....................................................39

8 Connections.........................................................40

Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

11 Entity
11.1 Entity Header Fields
11.2 Entity Body

8.1 Persistent Connections ..........................................40
8.2 Message Transmission Requirements ...............................43

9 Method Definitions..................................................44
9.2 OPTIONS .........................................................45
9.3 GET .............................................................46
9.4 HEAD ............................................................46
9.5 POST ............................................................47
9.6 PUT .............................................................47
9.7 DELETE ..........................................................48
9.8 TRACE ...........................................................49

10 Status Code Definitions
12.1 Definitions............................................49
10.1 Informational 1xx
12.2 ..............................................49
10.2 Successful 2xx
12.3 .................................................50
10.3 Redirection 3xx
12.4 ................................................52
10.4 Client Error 4xx
12.5 ...............................................55
10.5 Server Error 5xx

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 ...............................................59

11 Access Authentication
14.1 Authentication..............................................60
11.1 Basic Authentication Scheme
14.2 ....................................61
11.2 Digest Authentication Scheme

15 ...................................62

12 Content Negotiation................................................62
12.1 Server-driven Negotiation
15.1 ......................................63
12.2 Agent-driven Negotiation Facilities Defined in this Specification

16 .......................................64
12.3 Transparent Negotiation ........................................65

13 Caching in HTTP
16.1 Semantic Transparency
16.2 HTTP....................................................65
13.2 Expiration Model
16.3 ...............................................69
13.3 Validation Model
16.4 ...............................................75
13.4 Constructing Responses From Caches
16.5 .............................80
13.5 Caching and Generic Resources
16.6 Negotiated Responses ...................................82
13.6 Shared and Non-Shared Caches
16.7 Selecting a Cached Response
16.8 ...................................83
13.7 Errors or Incomplete Response Cache Behavior
16.9 Side Effects of GET and HEAD
16.10 ...................83
13.8 Invalidation After Updates or Deletions
16.11 ........................84
13.9 Write-Through Mandatory
16.12 Generic Resources and HTTP/1.0 Proxy Caches
16.13 ........................................85
13.10 Cache Replacement
16.14 Caching of Negative Responses
16.15 .............................................85
13.11 History Lists

17 Persistent Connections
17.1 Purpose
17.2 Overall Operation
17.3 Proxy Servers
17.4 Interaction with Security Protocols
17.5 Practical Considerations

18 .................................................85

14 Header Field Definitions
18.1 Definitions...........................................86
14.1 Accept
18.2 .........................................................86
14.2 Accept-Charset .................................................88
14.3 Accept-Encoding ................................................89
14.4 Accept-Language ................................................89
14.5 Accept-Ranges ..................................................90
14.6 Age ............................................................91
14.7 Allow ..........................................................91
14.8 Authorization ..................................................92
14.9 Cache-Control ..................................................92
14.10 Connection ....................................................99

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 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

14.11 Content-Base
18.13 ..................................................99
14.12 Content-Encoding
18.14 ..............................................99
14.13 Content-Language
18.15 .............................................100
14.14 Content-Length
18.16 ...............................................101
14.15 Content-Location
18.17 .............................................101
14.16 Content-MD5
18.18 ..................................................102
14.17 Content-Range
18.19 ................................................103
14.18 Content-Type
18.20 .................................................105
14.19 Date
18.21 .........................................................105
14.20 ETag
18.22 .........................................................106
14.21 Expires
18.23 ......................................................106
14.22 From
18.24 .........................................................107
14.23 Host
18.25 .........................................................107
14.24 If-Modified-Since
18.26 ............................................108
14.25 If-Match
18.27 If-NoneMatch
18.28 .....................................................109
14.26 If-None-Match ................................................110
14.27 If-Range
18.29 .....................................................112
14.28 If-Unmodified-Since
18.30 ..........................................112
14.29 Last-Modified
18.31 ................................................113
14.30 Location
18.32 .....................................................113
14.31 Max-Forwards
18.33 Persist
18.34 .................................................114
14.32 Pragma
18.35 .......................................................114
14.33 Proxy-Authenticate
18.36 ...........................................115
14.34 Proxy-Authorization
18.37 ..........................................115
14.35 Public
18.38 .......................................................116
14.36 Range
18.39 ........................................................116
14.37 Referer
18.40 ......................................................119
14.38 Retry-After
18.41 ..................................................119
14.39 Server
18.42 Title
18.43 .......................................................120
14.40 Transfer Encoding
18.44 ............................................120
14.41 Upgrade
18.45 ......................................................120
14.42 User-Agent
18.46 ...................................................121
14.43 Vary
18.47 .........................................................122
14.44 Via
18.48 ..........................................................123
14.45 Warning
18.49 ......................................................124
14.46 WWW-Authenticate

19 .............................................126

15 Security Considerations
19.1 Considerations...........................................126
15.1 Authentication of Clients
19.2 Safe Methods
19.3 .....................................126
15.2 Offering a Choice of Authentication Schemes ...................127
15.3 Abuse of Server Log Information
19.4 ...............................128
15.4 Transfer of Sensitive Information
19.5 .............................128
15.5 Attacks Based On File and Path Names

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

19.6 ..........................129
15.6 Personal Information
19.7 ..........................................130
15.7 Privacy Issues Connected to Accept headers
19.8 Headers ....................130
15.8 DNS Spoofing
19.9 ..................................................131
15.9 Location Headers and Spoofing

20 Acknowledgments

21 References

22 .................................131

16 Acknowledgments...................................................131

17 References........................................................133

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

18 Authors' Addresses

23 Appendices
23.1 Addresses................................................136

19 Appendices........................................................137
19.1 Internet Media Type message/http
23.2 ..............................137
19.2 Internet Media Type multipart/byteranges ......................138
19.3 Tolerant Applications
23.3 .........................................139
19.4 Differences Between HTTP Bodies Entities and RFC 1521 Internet Message
Bodies
23.4 Entities .......140
19.5 Changes from HTTP/1.0
23.5 .........................................142
19.6 Additional Features ...........................................143
19.7 Compatibility with Previous Versions ..........................147
19.8 Notes to RFC Editor and IANA ..................................149

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6]

1 Introduction
5.1

1.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 1945 [6] , improved the protocol by allowing messages to be in
the format of MIME-like entities, messages, 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
effects of hierarchical proxies , proxies, caching, the need for persistent connections
connections, and virtual hosts.. hosts. In addition, the proliferation of incompletely-
implemented
incompletely-implemented applications calling themselves "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". This
protocol is backwards-compatible with HTTP/1.0, but includes more stringent requirements than HTTP/1.0 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][20], as a location (URL) [4] or
name (URN) , for indicating the resource to which a method is to be
applied. Messages are passed in a format similar to that used by
Internet Mail and mail as defined by the Multipurpose Internet Mail Extensions
(MIME) .

HTTP is also used as a generic protocol for communication between user
agents and proxies/gateways to other Internet protocols, such as systems, including those
supported by the SMTP , [16], NNTP , [13], FTP , [18], Gopher , [2], and WAIS , allowing
[10] protocols. In this way, HTTP allows basic hypermedia access to
resources available from diverse applications and simplifying the
implementation of user agents.

5.2 applications.

1.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" means that the item is an
absolute requirement of the specification.

Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 7]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

SHOULD
This word or the adjective "recommended" means that there may exist
valid reasons in particular circumstances to ignore this item, but
the full implications should be understood and the case carefully
weighed before choosing a different course.

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" 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"; one that satisfies
all the MUST requirements but not all the SHOULD requirements for its
protocols is said to be "conditionally compliant".

5.3 compliant."

1.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 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 8 4 and
transmitted via the connection.

request
An HTTP request message message, as defined in section 9. 5.

response
An HTTP response message message, as defined in section 10. 6.

resource
A network data object or service that can be identified by a URI
(section 7.2). At any point URI, as
defined in time, a resource may be either a
plain resource, which corresponds to only one possible
representation, or a generic resource.

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 section 3.2. Resources may each be
identified by a unique URI, or by the combination of the generic
resource's URI and a variant-ID, available in multiple
languages, data formats, size, resolutions, or by the combination of the generic
resource's URI and some "content-negotiation" mechanism. In this
case, vary in other URIs may exist which identify a resource more
specifically.

plain resource
A resource that is not a generic resource. A plain resource is
always identified by a URI.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996 ways.

entity
The set of information transferred as the payload of a request or
response response.
An entity consists of metainformation in the form of
Entity-Header entity-header
fields and content in the form of an Entity-Body, entity-body, as described in
section 11.

resource entity
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 7.

Fielding, Frystyk, Berners-Lee, Gettys, and some other mechanism. Mogul [Page 8]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

representation
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 included with a resource variant. Note response that the set of variants
of a generic resource may change over time is subject to content
negotiation, as well. described in section 12. There may exist multiple
representations associated with a particular response status.

content negotiation
The mechanism for selecting the appropriate variant of a generic
resource representation 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 12. The representation
of the requested resource . A "strong entity
tag" is one that may entities in any response can be shared by two negotiated (including error
responses), as well as entities derived from resources.

variant
Each representation of a that resource only if
they are equivalent by octet equality. A "weak entity tag" is one that may be shared by two entities of corresponds to a resource if they are
equivalent and different
sequence of entities that could be substituted returned for each other with no
significant change in semantics. a requested resource
is termed a variant.

client
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 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 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 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.

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 on, with possible
translation, 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 must implement both the user agent. client
and server requirements of this specification.

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
An intermediary program which is acting as a blind relay between two

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 9]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 may include a cache, though a cache cannot be used by a server
that acts is acting as a tunnel.

cachable
A response is cachable if a cache is allowed to store a copy of the
response message for use in answering subsequent requests. The rules
for determining the cachability of HTTP responses are defined in
Section 16.
section 13. Even if a resource is cachable, there may be additional
constraints on when and if whether a cache can use the cached copy for a
particular request.

firsthand

first-hand
A response is firsthand first-hand if it comes directly and without unnecessary
delay from the origin server, perhaps via one or more proxies. A
response is also firsthand first-hand 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 a response is the time since it was generated sent 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.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

semantically transparent
A cache may use a fresh response without validating it, but "normally"
may that does not use a stale response without first validating it.
("Normally" means "unless configured to provide better performance at affect the expense semantics of transparency.")
Therefore, what expires is the cache's authority to use a cached
response, without validation, in its reply request and the
resulting response. A response is considered to a subsequent request.

semantically transparent
Ideally, an HTTP/1.1 cache would be "semantically transparent." That
is, use of unaffected by the
cache would not affect either the clients or when the
servers in any 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 a response equivalent to what it would
have received if it had made the same request directly to the origin server, at the same time.
server.

validator
An
A protocol element (e.g., an entity tag, tag or a Last-Modified time, which time) that
is used to find out whether a cache entry is a semantically transparent an equivalent copy of a
resource entity. A cache entry is semantically transparent if its
validator exactly matches the validator that the server would provide
for current instance of that resource
an entity.

5.4

1.4 Overall Operation

The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and protocol
version, followed by a MIME-like message containing request modifiers,
client information, and possible body content over a connection with a
server. The server responds with a status line, including the message's
protocol version and a success or error code, followed by a MIME-like
message containing server information, entity metainformation, and
possible entity body entity-body content. The relationship between HTTP and MIME is
described in appendix 19.4.

Most HTTP communication is initiated by a user agent and consists of a
request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).

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 part
of the message, and forwarding the reformatted request toward the server
identified by the URI. A gateway is a receiving agent, acting as a layer
above some other server(s) and, if necessary, translating the requests
to the underlying server's protocol. A tunnel acts as a relay point
between two connections without changing the messages; tunnels are used
when the communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents of
the messages.

request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 will 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 usefully 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 16. 13.

In fact, there are a wide variety of architectures and configurations of
caches and proxies currently being experimented with or deployed across
the World Wide Web; these systems include national hierarchies of proxy
caches to save transoceanic bandwidth, systems that broadcast or
multicast cache entries, organizations that distribute subsets of cached
data via CD-ROM, and so on. HTTP systems are used in corporate intranets
over high-bandwidth links, and for access via PDAs with low-power radio
links and intermittent connectivity. The goal of HTTP/1.1 is to support
the wide diversity of configurations already deployed while introducing
protocol constructs that meet the needs of those who build web
applications that require high reliability and, failing that, at least
reliable indications of failure.

HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 , 80, 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,

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

In HTTP/1.0, most implementations SHOULD implement persistent
connections (See section 17). Both clients and servers MUST be capable
of handling cases where either party closes the used a new connection prematurely,
due to user action, automated time-out, or program failure. for each
request/response exchange. In any
case,
the closing of the HTTP/1.1, a connection by either or both parties always
terminates the current request, regardless of its status.

5.5 HTTP and MIME
HTTP/1.1 uses many of the constructs defined may be used for MIME, as defined in RFC
1521 . Appendix 23.3 describes the ways in which the context of HTTP
allows one
or more request/response exchanges, although connections may be closed
for different use a variety of Internet Media Types than is typically found
in Internet mail, and gives the rationale for those differences.

6 reasons (see section 8.1).

2 Notational Conventions and Generic Grammar

6.1

2.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 "=". "="
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 (foo | bar) elem)" allows the token sequences
"elem foo elem" and "elem bar elem".

*rule
The character "*" preceding an element indicates repetition. The
full form is "<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
that "*(element)" allows any number, including zero; "1*element"
requires at least one; and "1*2element" allows one or two.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

[rule]
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".

N rule
Specific repetition: "<n>(element)" is equivalent to
"<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 " 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) " is permitted, but counts as only
two elements. Therefore, where at least one element is required, at
least one non-null element
MUST 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" 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 must exist between any two tokens, since they would
otherwise be interpreted as a single token. However, applications
SHOULD attempt to follow "common form" when generating HTTP
constructs, since there exist some implementations that fail to
accept anything beyond the common forms.

6.2

2.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. by
ANSI X3.4-1986 [21].

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 entity-body (see appendix 23.2 19.3 for tolerant
applications). The end-of-line marker within an Entity-Body entity-body is defined
by its associated media type, as described in section 7.7. 3.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, white space,
including folding, has the same semantics as SP.

LWS = [CRLF] 1*( SP | HT )

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words of
*TEXT MAY may contain octets characters from character sets other than US-ASCII ISO 8859-1
[22] only when encoded according to the rules of RFC 1522 . [14].

TEXT = <any OCTET except CTLs,
but including LWS>

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 Monday, June 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" 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 TEXT 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.

quoted-pair = "\" CHAR

3 Protocol Parameters

7.1

3.1 HTTP Version

HTTP uses a "<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 .

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Note that the major and minor numbers SHOULD MUST be treated as separate
integers and that each MAY 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 MUST be ignored by recipients and never
generated by senders. MUST NOT
be sent.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

Applications sending Full-Request Request or Full-Response Response messages, as defined by this
specification, MUST include an HTTP-Version of "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.

The HTTP version of an application is the highest HTTP version for which
the application is at least conditionally compliant.

Proxy and gateway applications MUST must be careful in when forwarding requests
that are received messages
in a format protocol versions different from that of the application's
native HTTP version. application. 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 actual 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 proxy/gateway's version MAY be upgraded
before being forwarded; the proxy/gateway's response to that request
MUST follow be in the server
requirements listed above. same major version as the request.

Note: Converting between versions of HTTP may involve addition or
deletion modification
of headers header fields required or forbidden by the version versions involved.
It is likely more involved than just changing the version
indicator.

7.2

3.2 Uniform Resource Identifiers

URIs have been known by many names: WWW addresses, Universal Document
Identifiers, Universal Resource Identifiers , and finally the
combination of Uniform Resource Locators (URL) and Names (URN) . As far
as HTTP is concerned, Uniform Resource Identifiers are simply formatted
strings which identify--via name, location, or any other characteristic--
a network characteristic-
-a resource.

7.2.1

3.2.1 General Syntax

URIs in HTTP can be represented in absolute form or relative to some
known base URI , 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.

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 ]

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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

escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&amp;" "&" | "=" | "+"
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.

The HTTP protocol does not place any a priori limit on the length of a
URI. Servers MUST be able to handle the URI of any resource they serve,
and SHOULD be able to handle URIs of unbounded length if they provide
GET-based forms that could generate such URIs. A server SHOULD return a status code of
414 Request-URI (Request-URI Too Large Long) status if a URI is longer than the server can handle. See
handle (see section 12.4.1.15. 10.4.15).

Note: Servers should be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy implementations
may not properly support these.

All client and proxy implementations MUST be able to handle a URI of
any finite length.

7.2.2 these lengths.

3.2.2 http URL

The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and semantics
for http URLs.

http_URL = "http:" "//" host [ ":" port ] [ abs_path ]

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 possible (see RFC 1900. 1900 [24]). If the abs_path is not present in
the URL, it MUST be given as "/" when used as a Request-URI for a
resource (section 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" URLs is obtained by converting any UPALPHA
characters in host to their LOALPHA equivalent (hostnames are case-
insensitive), eliding the [ ":" port ] if the port is 80, and replacing
an empty abs_path with "/".

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 5.1.2).

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client SHOULD
use a case-sensitive octet-by-octet comparison of the entire URIs, with
these exceptions:

Following the rules from section 7.2.2:

. A port that is empty or not given is equivalent to the default port 80.
for that URI;
. Comparisons of host names MUST be case-insensitive. case-insensitive;
. Comparisons of scheme names MUST be case-insensitive. case-insensitive;
. An empty abs_path is equivalent to an abs_path of "/" "/".
Characters except other than those in the reserved set "reserved" and the unsafe set "unsafe" sets (see
section 7.2) 3.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

3.3 Date/Time Formats

7.3.1

3.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, 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 (an update to RFC 822).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996 822
). The second format is in common use, but is based on the obsolete RFC

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

850 date format and lacks a four-digit year. HTTP/1.1 clients and
servers that parse the date value MUST accept all three formats, formats (for
compatibility with HTTP/1.0), though they MUST generate only generate the RFC
1123 format for representing date/time
stamps HTTP-date values in HTTP message header fields.

Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been generated sent 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" as the three-letter abbreviation for time zone,
and SHOULD MUST be assumed when reading the asctime format.

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"

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" problem).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 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.
. 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

3.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

7.4

3.4 Character Sets

HTTP uses the same definition of the term "character set" as that
described for MIME:

The term "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 mappings such as 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" is more commonly
referred to as a "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 .
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 -- the US-ASCII
and ISO-8859 character sets -- and other names specifically recommended
for use within MIME charset parameters.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
[19].

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

Although HTTP allows an arbitrary token to be used as a charset value,
any token that has a predefined value within the IANA Character Set
registry MUST represent the character set defined by that registry.
Applications SHOULD limit their use of character sets to those defined
by the 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.

7.5

3.5 Content Codings

Content coding values indicate an encoding transformation that has been
or can be applied to a resource an entity. Content codings are primarily used to
allow a document to be compressed or encrypted otherwise usefully transformed

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

without losing the identity of its underlying media type. Typically, type and without
loss of information. Frequently, the resource entity is stored in this encoding coded form,
transmitted directly, and only decoded before rendering or
analogous usage. by the recipient.

content-coding = "gzip" | "x-gzip"
| "compress" | "x-compress" | token

Note: For historical reasons, HTTP applications SHOULD consider "x-
gzip" and "x-compress" to be equivalent to "gzip" and "compress",
respectively.

All content-coding values are case-insensitive. HTTP/1.1 uses content-
coding values in the Accept-Encoding (section 18.3) 14.3) and Content-Encoding
(section 18.13) 14.12) 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

The Internet Assigned Numbers Authority (IANA) acts as a single
program MAY be capable of decoding multiple registry for
content-coding formats. Two
values are defined by this specification: value tokens. Initially, the registry contains the
following tokens:

gzip An encoding format produced by the file compression program "gzip"
(GNU zip) developed by Jean-loup Gailly. as described in RFC 1952 [25]. This format is typically a
Lempel-Ziv Lempel-
Ziv coding (LZ77) with a 32 bit CRC.

compress
The encoding format produced by the common UNIX file compression
program "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 For compatibility with previous implementations of
HTTP, applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.

deflate The "zlib" format defined in RFC 1950[31] in combination with
the Internet Assigned
Numbers Authority (IANA) as a central registry for content-coding value
tokens. Additional "deflate" compression mechanism described in RFC 1951[29].

New content-coding value tokens beyond the four defined
in this document (gzip x-gzip compress x-compress) SHOULD should be registered
with the IANA. To registered; to allow
interoperability between clients and servers, specifications of the
content coding algorithms used needed to implement a new value SHOULD should be
publicly available and adequate for independent implementation, and MUST
conform to the purpose of content coding defined in this section.

7.6

3.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 entity-body in
order to ensure safe transport "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 entity.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 18.43). 14.40).

Transfer codings are analogous to the Content-Transfer-Encoding values
of MIME , 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 message-bodies is the difficulty in determining the
exact body length (section 11.2.2), 7.2.2), or the desire to encrypt data over a
shared transport.

All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding , and MUST ignore 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

hex-no-zero = <HEX excluding "0">

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 and future headers that specify
they are allowed in footer>>

hex-no-zero = <HEX excluding "0">

Note that the chunks are *entity-header

The chunked encoding is ended by a zero-sized chunk, chunk followed by the
footer and
footer, which is terminated by an empty line. The purpose of the footer
is to provide an efficient way to supply information about an entity
that is generated dynamically; applications MUST NOT send header fields
in the footer which are not explicitly defined as being appropriate for
the footer, such as Content-MD5 or future extensions to HTTP for digital
signatures or other facilities.

An example process for decoding a Chunked-Body is presented in appendix 23.3.6.

7.7
19.4.6.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

3.7 Media Types

HTTP uses Internet Media Types in the Content-Type (section 18.19) 14.18) and
Accept (section 18.1) 14.1) header fields in order to provide open and
extensible data typing and type negotiation.

media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token

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 Linear white space (LWS) MUST NOT be generated
used between the type and subtype, nor between an attribute and its
value. Upon receipt
of a media type with an unrecognized parameter, a User agents that recognize the media-type MUST process (or
arrange to be processed by any external applications used to process
that type/subtype by the user agent SHOULD
treat agent) the media parameters for that MIME type
as if described by that type/subtype definition to the unrecognized parameter and its value were
not present.

Some inform the user
of any problems discovered.

Note: some older HTTP applications do not recognize media type
parameters.
HTTP/1.1 applications SHOULD When sending data to older HTTP applications,
implementations 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
required by that type/subtype definition.

Media-type values are registered with the Internet Assigned Number
Authority (IANA ). (IANA). The media type registration process is outlined in RFC
1590 . [17]. Use of non-registered media types is discouraged.

7.7.1

3.7.1 Canonicalization and Text Defaults

Internet media types are registered with a canonical form. In general,
an Entity-Body entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission; the exception is
"text" types, as defined in the next paragraph..

when paragraph.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

When in canonical form , form, media subtypes of the "text" type use CRLF as
the text line break. However, HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when if it is done consistently for an entire Entity-Body.. 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; entity-body; a bare CR or LF MUST NOT
be substituted for CRLF within any of the HTTP control structures (such
as header fields and multipart boundaries).

If an Entity-Body entity-body is encoded with a Content-Encoding, the underlying
data MUST be in a form defined above prior to being encoded.

The "charset" parameter is used with some media types to define the
character set (section 7.4) 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text" type
are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "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" 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.

7.7.2 value.

3.7.2 Multipart Types

MIME provides for a number of "multipart" types -- encapsulations of one
or more entities within a single message's Entity-Body. message-body. All multipart types share
a common syntax, as defined in 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 (even if the original
resource entity multipart contains
an epilogue. epilogue).

In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location header field
(section 14.15) SHOULD be included in the body-part of each enclosed
entity that can be identified by a URL.

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".

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 .

7.8 [15].

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

3.8 Product Tokens

Product tokens are used to allow communicating applications to identify
themselves via a simple product token, with an optional slash by software name and
version designator. version. Most fields using product
tokens also allow sub-
products 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.

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 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).

7.9

3.9 Quality Values

HTTP content negotiation (section 15) 12) uses short "floating point"
numbers to indicate the relative importance ("weight") of various
negotiable parameters. The weights are A weight is 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 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 ] )
| ( "1" [ "." 0*3("0") ] )

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 merely represent
relative degradation in perceived quality. Thus, a value of
"0.8" represents a 20% degradation from the optimum rather than a
statement of 80% desired quality.

7.10

3.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, Accept-Language and Content-Language
fields.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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
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 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 last
three tags above are not registered tags; all but the last are examples
of tags which could be registered in future.)

7.11

3.11 Entity Tags

Entity tags are quoted strings whose internal structure is not visible
to clients used for comparing two or caches. Entity more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag (section
14.20), If-Match (section 14.25), If-None-Match (section 14.26), and If-
Range (section 14.27) header fields. The definition of how they are used
and compared as cache validators is in
HTTP/1.1. section 13.3.3. An entity tag
consists of an opaque quoted string, possibly prefixed by a weakness
indicator.

entity-tag = strong-entity-tag | weak-entity-tag
| null-entity-tag
strong-entity-tag [ weak ] opaque-tag

weak = quoted-string
weak-entity-tag "W/"
opaque-tag = quoted-string "/W"
null-entity-tag = <"> <">

Note that the "/W" tag is considered part

A "strong entity tag" may be shared by two entities of a weak resource only
if they are equivalent by octet equality.

A "weak entity tag; it
MUST NOT tag," indicated by the "W/" prefix, may be removed shared by any cache or client.

There are two comparison functions on validators:

. The strong comparison function:
entities of a resource only if the entities are equivalent and could be
substituted for each other with no significant change in order to semantics. A
weak entity tag can only be considered equal,
both validators must used for weak comparison.

An entity tag MUST be identical in every way, and neither unique across all versions of all entities
associated with a particular resource. A given entity tag value may be
weak.
used for entities obtained by requests on different URIs without
implying anything about the equivalence of those entities.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

. The weak comparison function: in order

3.12 Range Units

HTTP/1.1 allows a client to request that only part (a range of) the
response entity be considered equal, both
validators must be identical included within the response. HTTP/1.1 uses range
units in every way, except for the presence
or absence of a "weak" tag.
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 entity, and always matching
the "current" validator of a resource entity that does not exist.

7.12 Variant IDs
A cache stores instances of resource entities, not instances of generic
resources per se. Therefore, the URI of a generic resource is not
sufficient for use as an identifier for 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.

Fielding, Frystyk, Berners-Lee, Gettys, (section 14.36), If-Range (section 14.27), and Mogul [Page 28]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

7.14.1 Range Units
A resource
Content-Range (section 14.17) header fields. An entity may be broken
down into subranges according to various structural units.

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
implementations may ignore ranges specified using other units.

7.14.2 Byte Ranges
Since all HTTP/1.1
has been designed to allow implementations of applications that do not
depend on knowledge of ranges.

4 HTTP entities are represented in Message

4.1 Message Types

HTTP messages as sequences of
bytes, the concept consist of a byte range is meaningful for any HTTP entity.
(However, not all clients and servers need requests from client to support byte-range
operations.)

Byte range specifications in HTTP apply server and responses
from server to client.

HTTP-message = Request | Response ; HTTP/1.1 messages

Request (section 5) and Response (section 6) messages use the sequence generic
message format of RFC 822 for transferring entities (the payload of bytes that
would be transferred by the protocol if no transfer-coding were being
applied.

This means that if Content-coding is applied to
message). Both types of message consist of a start-line, one or more
header fields (also known as "headers"), an empty line (i.e., a line
with nothing preceding the data, CRLF) indicating the byte
range specification applies to end of the resulting content-encoded byte
stream, not to header
fields, and an optional message-body.

generic-message = start-line
*message-header
CRLF
[ message-body ]

start-line = Request-Line | Status-Line

In the unencoded byte stream. It also means that interest of robustness, servers SHOULD ignore any empty line(s)
received where a Request-Line is expected. In other words, if the entity-body's media-type server
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, and the byte
range applies to reading the result of protocol stream at the those encodings.

A byte range operation may specify a single range beginning of bytes, or a set of
ranges within message and
receives a single entity.

ranges-specifier = byte-ranges-specifier

byte-ranges-specifier = bytes-unit "=" byte-range-set

byte-range-set CRLF first, it should ignore the CRLF.

Note: certain buggy HTTP/1.0 client implementations and/or scripts
generated extra CRLF's before/after a POST request. To restate what

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

is explicitly forbidden by the BNF, an HTTP/1.1 client must not
preface or follow a request with an extra CRLF.

4.2 Message Headers

HTTP header fields, which include general-header (section 4.5), request-
header (section 5.3), response-header (section 6.2), and entity-header
(section 7.1) fields, follow the same generic format as that given in
Section 3.1 of RFC 822 [9]. Each header field consists of a name
followed by a colon (":") and the field value. Field names are case-
insensitive. The field value may be preceded by any amount of LWS,
though a single SP is preferred. Header fields can be extended over
multiple lines by preceding each extra line with at least one SP or HT.
Applications SHOULD follow "common form" when generating HTTP
constructs, since there might exist some implementations that fail to
accept anything beyond the common forms.

message-header = 1#( byte-range-spec | suffix-byte-range-spec )

byte-range-spec field-name ":" [ field-value ] CRLF

field-name = first-byte-pos "-" [last-byte-pos]

first-byte-pos token
field-value = 1*DIGIT

last-byte-pos *( field-content | LWS )

field-content = 1*DIGIT <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>

The first-byte-pos value order in a byte-range-spec gives which header fields with differing field names are received
is not significant. However, it is "good practice" to send general-
header fields first, followed by request-header or response-header
fields, and ending with the byte-offset of entity-header fields.

Multiple message-header fields with the first byte same field-name may be present
in a range. The last-byte-pos value gives message if and only if the entire field-value for that header field
is defined as a comma-separated list [i.e., #(values)]. It MUST be
possible to combine the multiple header fields into one "field-name:
field-value" pair, without changing the byte-
offset semantics of the last byte in message, by
appending each subsequent field-value to the range; that is, first, each separated by a
comma. The order in which header fields with the byte positions
specified same field-name are inclusive. Byte offsets start at zero.

If the last-byte-pos value
received is present, it must be greater than or equal therefore significant to the first-byte-pos in that byte-range-spec, or interpretation of the byte-range-spec combined
field value, and thus a proxy MUST NOT change the order of these field
values when a message is
invalid. forwarded.

4.3 Message Body

The recipient message-body (if any) of an invalid byte-range-spec must ignore it. HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.40).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

If the last-byte-pos value is absent, it is assumed to

message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>

Transfer-Encoding MUST be equal used to the
current length indicate any transfer codings applied
by an application to ensure safe and proper transfer of the entity in bytes.

If the last-byte-pos value message.
Transfer-Encoding is larger than a property of the current length message, not of the entity, it is assumed to and
thus can be equal to the current length of added or removed by any application along the entity.

suffix-byte-range-spec = "-" suffix-length

suffix-length = 1*DIGIT

A suffix-byte-range-spec
request/response chain.

The rules for when a message-body is used to specify the suffix allowed in a message differ for
requests and responses.

The presence of a message-body in a request is signaled by the entity, inclusion
of a length given by Content-Length or Transfer-Encoding header field in the suffix-length value. (That is, this form
specifies request's
message-headers. A message-body MAY be included in a request only when
the last N bytes of request method (section 5.1.1) allows an entity.) If the entity entity-body.

For response messages, whether or not a message-body is shorter than included with a
message is dependent on both the specified suffix-length, request method and the entire entity is used.

Examples of byte-ranges-specifier values (assuming an entity response status
code (section 6.1.1). All responses to the HEAD request method MUST NOT
include a message-body, even though the presence of 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 entity-header fields
might lead one to believe they do. All 1xx (informational), 204 (no
content), and 9999):
bytes=0-0,-1

. Several legal but not canonical specifications 304 (not modified) responses MUST NOT include a message-
body. All other responses do include a message-body, although it may be
of the second 500
bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999

bytes=500-700,601-999

7.14.3 Content Ranges zero length.

4.4 Message Length

When a server returns message-body is included with a partial message, the length of that body
is determined by one of the following (in order of precedence):

1. Any response message which MUST NOT include a message-body (such as
the 1xx, 204, and 304 responses and any response to a client, it must describe
both HEAD request)
is always terminated by the extent first empty line after the header fields,
regardless of the range covered by entity-header fields present in the response, message.

2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then
the length is defined by the chunked encoding (section 3.6).

3. If a Content-Length header field (section 14.14) is present, its
value in bytes represents 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 message-body.

4. If the message uses the MIME "multipart/byteranges" Content-Type,
which is self-delimiting, then that defines the length. This Content-
Type MUST NOT be used unless the sender knows that the recipient can
parse it; the presence in a request of a Range header with multiple
byte-range specifiers implies that the client can parse
multipart/byteranges responses.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 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

5. By the
first and last byte of server closing the range.

A byte-content-range-spec whose last-byte-pos value is less than its
first-byte-pos value, or whose entity-length value is less than or equal connection. (Closing the connection cannot
be used to its last-byte-pos value, is invalid. The recipient of an invalid
byte-content-range-spec MUST ignore it and any content transferred along
with it.

Examples indicate the end of byte-content-range-spec values, assuming a request body, since that would leave
no possibility for 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

8 HTTP Message

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

Full-Request and Full-Response use the generic message format of RFC 822
for transferring entities. Both messages may include optional header
fields (also known as "headers") and an entity body. The entity body is
separated from the headers by a null line (i.e., send back a line response.)

For compatibility with nothing
preceding the CRLF).

8.2 Message Headers
HTTP header fields, which HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include General-Header (Section 8.3),
Request-
Header (Section 9.2), Response-Header (Section 10.2), and Entity-Header
(Section 11.1) fields, follow the same generic format as that given in
Section 3.1 of RFC 822 . Each a valid Content-Length header
field consists of unless the server is known to be HTTP/1.1 compliant. If a name followed
by request
contains a colon (":") message-body and the field value. Field names are case-insensitive.
The field value may be preceded by any amount of LWS, though a single SP Content-Length is preferred. Header fields can be extended over multiple lines by
preceding each extra line not given, the server
SHOULD respond with at least one SP or HT.

HTTP-header = field-name ":" [ field-value ] CRLF

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

field-name = token
field-value = *( field-content | LWS )

field-content = <the OCTETs making up 400 (bad request) if it cannot determine the field-value
and consisting length
of either *TEXT the message, or combinations
of token, tspecials, and quoted-string>

The order in which header fields with differing field names are received
is not significant. However, 411 (length required) if it is "good practice" wishes to send General-
Header fields first, followed by Request-Header or Response-Header
fields, and ending with insist on
receiving a valid Content-Length.

All HTTP/1.1 applications that receive entities MUST accept the Entity-Header fields.

Multiple HTTP-header fields with
"chunked" transfer coding (section 3.6), thus allowing this mechanism to
be used for messages when the same field-name may message length cannot be present determined in
advance.

Messages MUST NOT include both a
message if and only if the entire field-value for that Content-Length header field and the
"chunked" transfer coding. If both are received, the Content-Length MUST
be ignored.

When a Content-Length is
defined as given in a comma-separated list [i.e., #(values)]. It message where a message-body is
allowed, its field value MUST be possible
to combine the multiple header fields into one "field-name:
field-value"
pair, without changing exactly match the semantics number of the message, by appending each
subsequent field-value to the first, each separated by a comma. Thus,
the order OCTETs in which multiple header fields with the same field-name are
received may be significant to the interpretation of
message-body. HTTP/1.1 user agents MUST notify the combined
field-
value.

8.3 user when an invalid
length is received and detected.

4.5 General Header Fields

There are a few header fields which have general applicability for both
request and response messages, but which do not apply to the entity
being transferred. These headers header fields apply only to the message being
transmitted.

General-Header

General header 14.44

General-header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
header fields may be given the semantics of general header fields if all
parties in the communication recognize them to be general header general-header fields.
Unrecognized header fields are treated as Entity-Header entity-header fields.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

5 Request

A request message from a client to a server includes, within the first
line of that message, the method to be applied to the resource, the
identifier of the resource, and the protocol version in use. 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 9.1 5.1
*( General-Header general-header ; Section 8.3 4.5
| Request-Header request-header ; Section 9.2 5.3
| Entity-Header entity-header ) ; Section 11.1 7.1
CRLF
[ Entity-Body message-body ] ; Section 11.2

9.1 7.2

5.1 Request-Line

The Request-Line begins with a method token, followed by the Request-URI
and the protocol version, and ending with CRLF. The elements are
separated by SP characters. No CR or LF are allowed except in the final
CRLF sequence.

Request-Line = CRLF | Method SP Request-URI SP HTTP-Version CRLF

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

5.1.1 Method

The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive.

extension-method = token

The list of methods acceptable by a plain resource can be specified in
an Allow header field (section 18.7). However, the client is always
notified through the 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a plain
resource, as this which methods are allowed can change dynamically. Servers
SHOULD return the status code 405 (method not allowed) (Method Not Allowed) if the method is
known by the server but not allowed for the requested resource, and 501 (not implemented)
(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 response-header field (section 18.37). 14.35).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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 13.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

9.1.2 9.

5.1.2 Request-URI

The Request-URI is a Uniform Resource Identifier (section 7.2) 3.2) and
identifies the resource upon which to apply the request.

Request-URI = "*" | absoluteURI | abs_path

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 method used does not necessarily apply to a resource. One example
would be

OPTIONS * HTTP/1.1

The absoluteURI form is required when the request is being made to a
proxy. The proxy is requested to forward the request or service it from
a valid cache, and return the response.. 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 the absolute path of the
URI MUST be transmitted (see 7.2.1, section 3.2.1, abs_path) as the Request-URI, Request-
URI, and the network location of the URI (net_loc) MUST be transmitted
in a Host header field.. field. For example, a client wishing to retrieve the
resource above directly from the origin server would create a TCP
connection to port 80 of the host "www.w3.org" and send the lines:

GET /pub/WWW/TheProject.html HTTP/1.1
Host:www.w3.org
Host: www.w3.org

followed by the remainder of the Full-Request. 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).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

If a proxy receives a request without any path in the Request-URI and
the method 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 34]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

OPTIONS * HTTP/1.1
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 in the "% HEX HEX" encoding defined by RFC
1738 . format specified in section 3.2.1.
The origin server MUST decode the Request-URI in order to properly
interpret the request. Servers SHOULD respond to invalid Request-URIs
with an appropriate status code.

In requests that they forward, proxies MUST NOT rewrite the "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 MAY
transform "*", no matter what the Request-URI for internal processing purposes, but SHOULD
NOT send such a transformed Request-URI proxy does in forwarded requests. its internal
implementation.

Note: The main reason for this "no rewrite" rule is to make sure that prevents the form of
Request-URI is well specified, to enable future extensions without
fear that they will break in proxy from changing the face of some rewritings. Another
is that one consequence
meaning of rewriting the Request-URI is that
integrity or authentication checks by request when the origin server may fail; is improperly using a
non-reserved URL character for a reserved purpose, since
rewriting MUST be avoided in this case, it may as well be
proscribed in general. is not
feasible to fix all CGI scripts (or script authors) use URI syntax
correctly.

Implementers should be aware that some pre-
HTTP/1.1 pre-HTTP/1.1 proxies do some rewriting.

9.2 have
been known to rewrite the Request-URI.

5.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. field value. (But see section
19.5.1 for other requirements on Host support in HTTP/1.1.)

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:. request:

1. If Request-URI is an absoluteURI, the host is included in part of the
Request-URI. Request-
URI. Any Host header field value in the request MUST be ignored.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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.
field value.

3. If the request-URI is not an absoluteURI and no Host header field host as determined by rule 1 or 2 is present (or does not represent a valid host on that server), the
server, the response MUST be a 400 (Bad Request) error message.

Recipients of an HTTP/1.0 request lacking that lacks 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

5.3 Request Header Fields

The request header 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

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
to the parameters on a programming language method (procedure) invocation.

Request-Header

Request-Header 14.42

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 request-header fields if all
parties in the communication recognize them to be request header request-header fields.
Unrecognized header fields are treated as Entity-Header entity-header fields.

6 Response

After receiving and interpreting a request message, a server responds in
the form of
with an HTTP response message.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

Response = Full-Response

Full-Response = Status-Line ; Section 10.1 6.1
*( General-Header general-header ; Section 8.3 4.5
| Response-Header response-header ; Section 10.2 6.2
| Entity-Header entity-header ) ; Section 11.1 7.1
CRLF
[ Entity-Body message-body ] ; Section 11.2

10.1 7.2

6.1 Status-Line

The first line of a Full-Response 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

10.1.1

6.1.1 Status Code and Reason Phrase

The Status-Code element is a 3-digit integer result code of the attempt
to understand and satisfy the request. These codes are fully defined in
section 10. The Reason-Phrase is intended to give a short textual
description of the Status-Code. The Status-Code is intended for use by
automata and the Reason-Phrase is intended for the

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. 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

. 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 12.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]

extension-code = 3DIGIT

Reason-Phrase = *<TEXT, excluding CR, LF>

HTTP status codes are extensible. HTTP applications are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an unrecognized
response MUST NOT be cached. For example, if an unrecognized status code
of 431 is received by the client, it can safely assume that there was

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

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.

10.2

6.2 Response Header Fields

The response header 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

Response-Header 14.43

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 response-header fields if
all parties in the communication recognize them to be response header response-header
fields. Unrecognized header fields are treated as Entity-Header entity-header fields.

7 Entity
Full-Request

Request and Full-Response Response messages MAY transfer an entity within
some requests and responses. if not otherwise
restricted by the request method or response status code. An entity
consists of Entity-Header 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. entity-body, although some
responses will only include the entity-headers.

In this section, both sender and recipient refer to either the client or
the server, depending on who sends and who receives the entity.

11.1

7.1 Entity Header Fields
Entity-Header

Entity-header fields define optional metainformation about the Entity-
Body entity-
body or, if no body is present, about the resource identified by the
request.

Entity-Header

entity-header = Allow ; Section 18.7 14.7
| Content-Base ; Section 18.12 14.11
| Content-Encoding ; Section 18.3 14.12
| Content-Language ; Section 18.14 14.13

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

extension-header = HTTP-header message-header

The extension-header mechanism allows additional Entity-Header 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.

11.2

7.2 Entity Body

The entity body entity-body (if any) sent with an HTTP request or response is in a
format and encoding defined by the Entity-Header entity-header fields.

Entity-Body

entity-body = *OCTET

An entity body MUST ONLY be included with entity-body is only present in a request message when the
request method calls for one. The presence of an entity body in a
request message-body is signaled by the inclusion of a Content-Length and/or
Content-
Type header field
present, as described in the request message headers.

For response messages, whether or not an entity body is included with a
message section 4.3. The entity-body is dependent on both the request method and the response code.
All responses to the HEAD request method MUST NOT include a body, even
though obtained from
the presence of entity header fields message-body by decoding any Transfer-Encoding that may lead one have been
applied to believe they
do. All 1xx (informational), 204 (no content), ensure safe and 304 (not modified)
responses MUST NOT include a body. All other responses MUST include an
entity body or a Content-Length header field defined with a value proper transfer of
zero (0).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

11.2.1 the message.

7.2.1 Type

When an entity body entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type,
Content-Encoding, Content-Type and Transfer-Encoding. Content-
Encoding. These define a three-layer, two-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, data, 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 requested resource. There is a property of the message, not of the resource
entity. no default encoding.

Any HTTP/1.1 message containing an entity body 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, field, the recipient may 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".

11.2.2

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

7.2.2 Length
When an entity body is included with a message, the

The length of that body
may be determined in one of several ways. If a Content-Length header
field an entity-body is present, its value in bytes represents the length of the entity
body. Otherwise, message-body after any
transfer codings have been removed. Section 4.4 defines how the body length
of a message-body is determined by determined.

8 Connections

8.1 Persistent Connections

8.1.1 Purpose

Prior to persistent connections, a separate TCP connection was
established to fetch each URL, increasing the Transfer-Encoding
(if load on HTTP servers, and
causing congestion on the "chunked" transfer coding has been applied) or by Internet. The use of inline images and other
associated data often requires a client to make multiple requests of the
same server
closing the connection.

Note: Any response message which MUST NOT include an entity body
(such as the 1xx, 204, in a short amount of time. An excellent analysis of these
performance problems is available [30]; analysis and 304 responses results from a
prototype implementation are in [26].

Persistent HTTP connections have a number of advantages:

. By opening and any response closing fewer TCP connections, CPU time is saved,
and memory used for TCP protocol control blocks is also saved.
. HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a HEAD
request) single TCP connection to be
used much more efficiently, with much lower elapsed time.
. Network congestion is always terminated reduced by reducing the first empty line after the
header fields, regardless number of packets
caused by TCP opens, and by allowing TCP sufficient time to
determine the entity header fields present in
the message.

Closing congestion state of the connection cannot network.
. HTTP can evolve more gracefully; since errors can be used to indicate reported
without the end penalty of a request
body, since it leaves no possibility for closing the server to send back TCP connection. Clients using
future versions of HTTP might optimistically try a
response. For compatibility new feature, but
if communicating with HTTP/1.0 applications, HTTP/1.1
requests containing an entity body MUST include a valid Content-Length
header field unless the server older server, retry with old semantics
after an error is known to be HTTP/1.1 compliant. reported.
HTTP implementations SHOULD implement persistent connections.

8.1.2 Overall Operation

A significant difference between HTTP/1.1 servers MUST accept and earlier versions of HTTP
is that persistent connections are the "chunked" transfer coding (section
7.6), thus allowing this mechanism to be used for default behavior of any HTTP
connection. That is, unless otherwise indicated, the client may assume
that the server will maintain a request when
Content-Length is unknown.

If persistent connection.

Persistent connections provide a request contains an entity body mechanism by which a client and Content-Length is not
specified, the a
server SHOULD respond with 400 (bad request) if it cannot
determine can signal the length close of the request message's content, or with 411 a TCP connection. This signaling takes

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 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

place using the
"chunked" transfer coding. If both are received, Connection header field. Once a close has been signaled,
the Content-Length client MUST
be ignored.

When not send any more requests on that connection.

8.1.2.1 Negotiation
An HTTP/1.1 server MAY assume that a Content-Length is given in HTTP/1.1 client intends to maintain
a message where an entity body is
allowed, its field value MUST exactly match persistent connection unless a Connection header including the number of OCTETs
connection-token "close" was sent in the
entity body. HTTP/1.1 user agents MUST notify request. If the user when an invalid
length is received and detected.

12 Status Code Definitions
Each Status-Code is described below, server chooses
to close the connection immediately after sending the response, it
SHOULD send a Connection header including the connection-token close.

An HTTP/1.1 client MAY expect a description of which
method(s) connection to remain open, but would
decide to keep it can follow and any metainformation required in open based on whether the
response.

12.1 Informational 1xx
This class of status code indicates response from a provisional response, consisting
only of the Status-Line and optional headers, and is terminated by an
empty line. Since HTTP/1.0 did not define any 1xx status codes, servers
MUST NOT send server
contains a 1xx response to an HTTP/1.0 client except under
experimental conditions.

12.1.1.1 100 Continue
The client may continue Connection header with its request. This interim response is used
to inform the connection-token close. In case
the client does not want to maintain a connection for more than that
request, it SHOULD send a Connection header including the initial part of the request has been
received and has not yet been rejected by connection-
token close.

If either the server. The client SHOULD
continue by sending or the remainder of server sends the request or, if close token in the
Connection header, that request has
already been completed, ignore this response. The server MUST send a
final response after becomes the request has been completed.

12.1.1.2 101 Switching Protocols
The server understands last one for the connection.

Clients and servers SHOULD NOT assume that a persistent connection is willing to comply
maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See section 19.7.1 for more information on backwards
compatibility with HTTP/1.0 clients.

In order to remain persistent, all messages on the client's
request, via the Upgrade message header field (section 18.44), for connection must have
a
change in self-defined message length (i.e., one not defined by closure of the application protocol being used on this connection. The
connection), as described in section 4.4.

8.1.2.2 Pipelining
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server will switch protocols MUST send its responses to those defined by requests in the response's Upgrade
header field immediately after
same order that the empty line requests were received.

Clients which terminates the 101
response.

The protocol should only assume persistent connections and pipeline immediately
after connection establishment SHOULD be switched when prepared to retry their
connection if the first pipelined attempt fails. If a client does such a
retry, it MUST NOT pipeline before it knows the connection is advantageous to do so.
For example, switching
persistent. Clients MUST also be prepared to a newer version resend their requests if
the server closes the connection before sending all of HTTP the corresponding
responses.

8.1.3 Proxy Servers

It is advantageous over
older versions, and switching to a real-time, synchronous protocol may
be advantageous when delivering resources especially important that use such features.

12.2 Successful 2xx
This class proxies correctly implement the
properties of status code indicates that the client's request was
successfully received, understood, and accepted. Connection header field as specified in 14.2.1.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.2.1.1 200 OK
The request has succeeded.

The information returned proxy server MUST signal persistent connections separately with its
clients and the response is
dependent on the method used in the request, as follows:

GET
an entity corresponding origin servers (or other proxy servers) that it connects
to. Each persistent connection applies to the requested resource is sent in the
response;

HEAD
the response MUST only contain the header information and one transport link.

A proxy server MUST NOT establish a persistent connection with an
HTTP/1.0 client.

8.1.4 Practical Considerations

Servers will usually have some time-out value beyond which they will no Entity-
Body;

POST
longer maintain an entity describing or containing the result of the action;

TRACE
an entity containing the request message as received by the end
server;

otherwise,
an entity describing the result of the action;
If the entity corresponds to a resource, the response MAY include inactive connection. Proxy servers might make this a
Content-Location header field giving the actual location of
higher value since it is likely that plain
resource for later reference.

12.2.1.2 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 in client will be making more
connections through the entity same server. The use of persistent connections
places no requirements on the response, with the most specific URL length of this time-out for either the resource given by
client or the server.

When a Location header field. The origin client or server wishes to time-out it SHOULD
create the resource before returning this status code. If the action
cannot be carried out immediately, the server MUST include in the
response body issue a description of when the resource will be available;
otherwise, graceful
close on the server transport connection. Clients and servers SHOULD respond with 202 (Accepted).

12.2.1.3 202 Accepted
The request has been accepted both
constantly watch for processing, but the processing has not
been completed. The request MAY or MAY NOT eventually be acted upon, as
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.

The 202 response is intentionally non-committal. Its purpose is to 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 persist until the process is
completed. The entity returned with this response SHOULD include an
indication side of the request's current status transport close, and either a pointer respond
to it as appropriate. If a
status monitor client or some estimate of when the user can expect the request
to be fulfilled.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

12.2.1.4 203 Non-Authoritative Information
The returned metainformation in the Entity-Header is server does not detect the definitive
set as available from other
side's close promptly it could cause unnecessary resource drain on the origin
network.

A client, server, but is gathered from a local or
a third-party copy. The set presented proxy MAY be a subset or superset of close the
original version. transport connection at any
time. For example, including local annotation information
about the resource a client MAY result in have started to send a superset of the metainformation known
by new request at
the origin server. Use of this response code is not required and is
only appropriate when same time that the response would otherwise be 200 (OK).

12.2.1.5 204 No Content
The server has fulfilled the request but there is no new information decided to
send back. If close the client "idle"
connection. From the server's point of view, the connection is a user agent, being
closed while it SHOULD NOT change its
document view was idle, but from that which caused the client's point of view, a request to be generated. This
response
is primarily intended in progress.

This means that clients, servers, and proxies MUST be able to allow input for actions to take place
without causing a change to the user agent's active document view. The
response MAY include new metainformation in the form of entity headers,
which recover
from asynchronous close events. Client software SHOULD apply to the document currently in reopen the user agent's active
view.

The 204 response MUST NOT include an entity body,
transport connection and thus is always
terminated by the first empty line after the header fields.

12.2.1.6 205 Reset Content
The server has fulfilled retransmit the aborted request and the without user agent SHOULD reset the
document view which caused
interaction so long as the request to be generated. This response method is
primarily intended to allow input for actions to take place via idempotent (see section
9.1.2); other methods MUST NOT be automatically retried, although user
input, followed by
agents MAY offer a clearing of the form in which the input is given so
that human operator the user can easily initiate another input action. The response
MUST include a Content-Length with a value choice 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 MUST have included a Range header field (section 18.38)
indicating the desired range. The response MUST include a Content-Range
header field (section 18.18) indicating retrying the range included with request.
However, this
response. All entity header fields in the response MUST describe automatic retry SHOULD NOT be repeated if the
partial entity transmitted rather than what would have been transmitted
in second
request fails.

Servers SHOULD always respond to at least one request per connection, if
at all possible. Servers SHOULD NOT close a full response. In particular, the Content-Length header field connection in the response MUST match the actual number middle of OCTETs transmitted in the
entity body.
transmitting a response, unless a network or client failure is
suspected.

It is assumed suggested that clients which use persistent connections SHOULD
limit the client already has the complete
entity's header field data.

12.3 Redirection 3xx
This class number of status code indicates simultaneous connections that further action needs to be
taken by the user agent in order they maintain to fulfill the request. The action
required MAY be carried out by the user agent without interaction a
given server. A single-user client SHOULD maintain AT MOST 2 connections
with
the user if and only if the method used in the second request is GET any server or
HEAD. proxy. A user agent proxy SHOULD NOT automatically redirect a request more than
5 times, since such redirections usually indicate an infinite loop. use up to 2*N connections to
another server or proxy, where N is the number of simultaneously active

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43] 42]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.3.1.1 300 Multiple Choices
This status code is reserved for future use by a planned content
negotiation mechanism. HTTP/1.1 user agents receiving a 300 response
which includes a Location header field can treat this response as they
would treat a 303 (See Other) response. If no Location header field is
included, the appropriate action is

users. These guidelines are intended to display the entity enclosed in
the improve HTTP response to the user.

12.3.1.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI times and any
future references to this resource SHOULD be done using one
avoid congestion of the
returned URIs. Clients with link editing capabilities Internet or other networks.

8.2 Message Transmission Requirements

General requirements:

. HTTP/1.1 servers SHOULD
automatically re-link references to the Request-URI maintain persistent connections and use
TCP's flow control mechanisms to one or more of
the new references returned by resolve temporary overloads,
rather than terminating connections with the server, where possible. This response
is cachable unless indicated otherwise.

If 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
monitor the new URI network connection for an error status while it is a location, its URL MUST be given by
transmitting the Location
field in request. If the response. Unless client sees an error status, it was a HEAD request,
SHOULD immediately cease transmitting the Entity-Body of body. If the response SHOULD contain body is
being sent using a short hypertext note with "chunked" encoding, a hyperlink zero length chunk is used
to mark the new URI(s). end of the message. If the 301 status code is received in response to body was preceded by a request other than
GET or HEAD,
Content-Length header, the user agent client MUST NOT automatically redirect close the request
unless it can connection.
. An HTTP/1.1 (or later) client MUST be confirmed prepared to accept a 100
(Continue) status followed by the user, since this might change the
conditions under which the request was issued.

Note: When automatically redirecting a POST regular response.
. An HTTP/1.1 (or later) server that receives a request after receiving from a 301 status code, some existing
HTTP/1.0 user agents will
erroneously change (or earlier) client MUST NOT transmit the 100 (continue)
response; it into a GET request.

12.3.1.3 302 Moved Temporarily
The requested resource resides temporarily under a different URI. Since SHOULD either wait for the redirection may request to be altered on occasion, completed
normally (thus avoiding an interrupted request) or close the client SHOULD
connection prematurely.
Upon receiving a method subject to these requirements from an HTTP/1.1
(or later) client, an HTTP/1.1 (or later) server MUST either respond
with 100 (Continue) status and continue to use read from the Request-URI for future requests. This response is only
cachable if indicated by a Cache-Control input stream,
or Expires header field. respond with an error status. If it responds with an error status, it
MAY close the new URI is a location, its URL MUST be given by transport (TCP) connection or it MAY continue to read and
discard the Location
field in rest of the response. Unless request. It MUST NOT perform the requested
method if it was a HEAD request, returns an error status.

Clients SHOULD remember the Entity-Body version number of at least the most recently
used server; if an HTTP/1.1 client has seen an HTTP/1.1 or later
response SHOULD contain a short hypertext note with a hyperlink to from the new URI(s).

If server, and it sees the 302 connection close before
receiving any status code is received in response to a request other than
GET or HEAD, from the server, the client SHOULD retry the
request without user agent MUST NOT automatically redirect interaction so long as the request
unless it can method is
idempotent (see section 9.1.2); other methods MUST NOT be confirmed by automatically
retried, although user agents MAY offer a human operator the user, since this might change choice of
retrying the
conditions under which request.. If the client does retry the request, the client

. MUST first send the request was issued.

Note: When automatically redirecting a POST request after receiving header fields, and then
. MUST wait for the server to respond with either a 302 status code, some existing 100 (Continue)
response, in which case the client should continue, or with an
error status.
If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
the server, it should assume that the server implements HTTP/1.0 user agents or
older and will
erroneously change it into a GET request. not use the 100 (Continue) response. If in this case the

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44] 43]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.3.1.4 303 See Other
The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect

client sees the user agent to a selected resource. The new resource is not
a update reference for connection close before receiving any status from the original Request-URI. The 303 response is not
cachable, but
server, the response to client SHOULD retry the second request MAY be cachable. request. If the new URI is a location, its URL MUST be given by the Location
field in client does retry
the response. Unless it was a HEAD request, it should use the Entity-Body following "binary exponential backoff"
algorithm to be assured of
the response SHOULD contain obtaining a short hypertext note with reliable response:

1. Initiate a hyperlink new connection to the new URI(s).

12.3.1.5 304 Not Modified
If server
2. Transmit the client has performed request-headers
3. Initialize a conditional GET request and access is
allowed, but variable R to the document has not been modified since estimated round-trip time to the
server (e.g., based on the date and time
specified in it took to establish the If-Modified-Since field,
connection), or to a constant value of 5 seconds if the server MUST respond with
this status code and round-trip
time is not send an Entity-Body to available.
4. Compute T = R * (2**N), where N is the client. Header
fields contained in number of previous retries
of this request.
5. Wait either for an error response from the server, or for T seconds
(whichever comes first)
6. If no error response SHOULD only include information which is relevant to cache managers or which MAY have changed independently of received, after T seconds transmit the entity's Last-Modified date. Examples body
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 the 304 response. request.
7. If the new field values indicate client sees that the
cached entity differs connection is closed prematurely, repeat
from step 1 until the current resource entity (as would be
indicated by a change in Content-Length, Content-MD5, request is accepted, an error response is
received, or Content-
Version), then the cache MUST disregard the 304 response user becomes impatient and repeat terminates the
request without retry
process.
No matter what the server version, if an If-Modified-Since field.

The 304 response error status is received, the
client

. MUST NOT include an entity body, continue and thus is always
terminated by the first empty line after the header fields.

12.3.1.6 305 Use Proxy
The requested resource
. MUST be accessed through the proxy given by the
Location field in the response. In other 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 close the client connection if it has not already completed sending
the full request when a
4xx code is received, it SHOULD immediately cease sending data body including any encoding mechanism used to
transmit the
server. Except when responding to a HEAD request, body.
An HTTP/1.1 (or later) client that sees the server connection close after
receiving a 100 (Continue) but before receiving any other status SHOULD
include an entity containing an explanation of
retry the error situation, request, and
whether it is a temporary or permanent condition. These status codes are
applicable to any request method.

Note: If need not wait for 100 (Continue) response (but
MAY do so if this simplifies the client implementation).

9 Method Definitions

The set of common methods for HTTP/1.1 is sending data, server implementations using
TCP SHOULD defined below. Although this
set can be careful expanded, additional methods cannot be assumed to ensure share the
same semantics for separately extended clients and servers.

The Host request-header field (section 14.23) MUST accompany all
HTTP/1.1 requests.

9.1.1 Safe Methods

Implementers should be aware that the client acknowledges
receipt of software represents the packet(s) containing user in
their interactions over the response prior Internet, and should be careful to closing allow the
user to be aware of any actions they may take which may have an
unexpected significance to themselves or others.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45] 44]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

In particular, the input connection. If the client continues sending data to the
server after the close, the server's controller will send a reset
packet to the client, which may erase convention has been established that the client's unacknowledged
input buffers before they can be read GET and interpreted by HEAD
methods should never have the HTTP
application.

12.4.1.1 400 Bad Request
The request could not significance of taking an action other
than retrieval. These methods should be understood by the server due considered "safe." This allows
user agents to malformed
syntax. The client SHOULD NOT repeat represent other methods, such as POST, PUT and DELETE, in
a special way, so that the request without modifications.

12.4.1.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 18.46) containing is made aware of the fact that a challenge
applicable
possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the requested resource. server does not
generate side-effects as a result of performing a GET request; in fact,
some dynamic resources consider that a feature. The client MAY repeat important
distinction here is that the user did not request
with a suitable Authorization header field (section 18.8). If the
request already included Authorization credentials, then side-effects, so
therefore cannot be held accountable for them.

9.1.2 Idempotent Methods

Methods may also have the 401
response indicates property of "idempotence" in that authorization has been refused for those
credentials. If (aside from
error or expiration issues) the 401 response contains results from N>0 identical requests is
the same challenge as the
prior response, for a single request. The methods GET, HEAD, PUT and the user agent has already attempted authentication
at least once, then the user SHOULD be presented the entity that was
given in the response, since that entity MAY include relevant diagnostic
information. HTTP access authentication is explained in section 14.

12.4.1.3 402 Payment Required
This code is reserved for future use.

12.4.1.4 403 Forbidden DELETE
share this property.

9.2 OPTIONS

The server understood OPTIONS method represents a request for information about the request, but is refusing to fulfill it.
Authorization will not help and
communication options available on the request SHOULD not be repeated. If request/response chain identified
by the request Request-URI. This method was not HEAD and allows the server wishes client to make public why
the request has not been fulfilled, it SHOULD describe determine the reason for
options and/or requirements associated with a resource, or the refusal in
capabilities of a server, without implying a resource action or
initiating a resource retrieval.

Unless the entity body. This status code server's response is commonly used when
the server does not wish to reveal exactly why an error, the request has been
refused, or when no other response MUST NOT include
entity information other than what can be considered as communication
options (e.g., Allow is applicable.

12.4.1.5 404 Not Found
The server has appropriate, but Content-Type is not). Responses
to this method are not found anything matching cachable.

If the Request-URI. No
indication Request-URI is given of whether an asterisk ("*"), the condition OPTIONS request is temporary or permanent.
If intended
to apply to the server does as a whole. A 200 response SHOULD include any
header fields which indicate optional features implemented by the server
(e.g., Public), including any extensions not wish to make defined by this information available
specification, in addition to the
client, the status code 403 (Forbidden) any applicable general or response-header
fields. As described in section 5.1.2, an "OPTIONS *" request can be used instead. The 410
(Gone) status code SHOULD be used if
applied through a proxy by specifying the destination server knows, through some
internally configurable mechanism, that an old resource is permanently
unavailable and has no forwarding address.

12.4.1.6 405 Method Not Allowed
The method specified in the Request-Line
Request-URI without any path information.

If the Request-URI is not allowed for an asterisk, the resource
identified by OPTIONS request applies only
to the Request-URI. The options that are available when communicating with that resource.
A 200 response MUST SHOULD include an Allow any header
containing a list of valid methods for fields which indicate optional
features implemented by the requested resource. 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

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46] 45]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.4.1.7 406 Not Acceptable
The resource identified by

fields. If the OPTIONS request is only capable of generating
response entities which have content characteristics not acceptable
according to passes through a proxy, the accept headers sent in proxy MUST
edit the request.

HTTP/1.1 servers are allowed response to return responses which are not
acceptable according exclude those options known to the accept headers sent in the request. In some
cases, this may even be preferable to sending a 406 response. User
agents are encouraged to inspect unavailable
through that proxy.

9.3 GET

The GET method means retrieve whatever information (in the headers form of an incoming response to
determine if it
entity) is acceptable. identified by the Request-URI. If the response Request-URI refers to a
data-producing process, it is the produced data which shall be returned
as the entity in the response and not acceptable, user
agents SHOULD interrupt the receipt source text of the response if doing so would
save network resources. If it is unknown whether an incoming response
would process,
unless that text happens to be acceptable, a user agent SHOULD temporarily stop receipt the output of
more data and query the user for a decision on furtheractions.

12.4.1.8 407 Proxy Authentication Required
This code is similar process.

The semantics of the GET method change to 401 (Unauthorized), but indicates a "conditional GET" if the
request message includes an If-Modified-Since , If-Unmodified-Since, If-
Match, If-None-Match, or If-Range header field. A conditional GET method
requests that the
client MUST first authenticate itself with entity be transferred only under the proxy. The proxy MUST
return a Proxy-Authenticate circumstances
described by the conditional header field (section 18.35) containing a
challenge applicable field(s). The conditional GET method
is intended to reduce unnecessary network usage by allowing cached
entities to be refreshed without requiring multiple requests or
transferring data already held by the proxy for the requested resource. client.

The client
MAY repeat semantics of the GET method change to a "partial GET" if the request with
message includes a suitable Proxy-Authorization Range header field
(section 18.36). HTTP access authentication is explained field. A partial GET requests that only
part of the entity be transferred, as described in section 14.

12.4.1.9 408 Request Timeout 14.36. The client did not produce a request within the time that the server was
prepared
partial GET method is intended to reduce unnecessary network usage by
allowing partially-retrieved entities to wait. The client MAY repeat the request without
modifications at any later time.

12.4.1.10 409 Conflict
The request could not be completed due without
transferring data already held by the client.

The response to a conflict with the current
state of the resource. This code GET request is cachable if and only allowed in situations where if it
is expected that the user MAY be able to resolve the conflict and
resubmit meets the request. The response body SHOULD include enough
information
requirements for the user HTTP caching described in section 13.

9.4 HEAD

The HEAD method is identical to recognize GET except that the source of server MUST NOT
return a message-body in the conflict.
Ideally, response. The metainformation contained in
the HTTP headers in response entity would include enough information for the
user or user-agent to fix the problem; however, that MAY not a HEAD request SHOULD be possible
and is not required.

Conflicts are most likely identical to occur
the information sent in response to a PUT GET request. If
versioning is being This method can be
used and for obtaining metainformation about the entity being PUT includes changes to a
resource which conflict with those made implied by an earlier (third-party)
request, the server MAY use
request without transferring the 409 entity-body itself. This method is
often used for testing hypertext links for validity, accessibility, and
recent modification.

The response to indicate a HEAD request may be cachable in the sense that it can't
complete the request. In this case,
information contained in the response entity SHOULD contain may be used to update a
list of previously
cached entity from that resource. If the differences between new field values indicate that
the two versions in a format defined by cached entity differs from the response Content-Type.

12.4.1.11 410 Gone
The requested resource is no longer available at the server and no
forwarding address is known. This condition SHOULD current entity (as would be considered
permanent. Clients with link editing capabilities SHOULD delete indicated
by a change in Content-Length, Content-MD5, ETag or Last-Modified), then
the cache MUST treat the cache entry as stale.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47] 46]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

references

9.5 POST

The POST method is used to request that the Request-URI after user approval. If the destination server does
not know, or has no facility to determine, whether or not the condition
is permanent, accept
the status code 404 (Not Found) SHOULD be used instead.
This response is cachable unless indicated otherwise.

The 410 response is primarily intended to assist entity enclosed in the task request as a new subordinate of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that
identified by the server owners desire that remote
links to that resource be removed. Such an event is common for limited-
time, promotional services and for resources belonging to individuals no
longer working at Request-URI in the server's site. It Request-Line. POST is not necessary to mark all
permanently unavailable resources as "gone" or designed to keep the mark for any
length of time -- that is left
allow a uniform method to cover the discretion following functions:

. Annotation of the server owner.

12.4.1.12 411 Length Required
The server refuses existing resources;

. Posting a message to accept the request without a defined Content-
Length. The client MAY repeat the request if it adds bulletin board, newsgroup, mailing list, or
similar group of articles;

. Providing a valid Content-
Length header field containing the length block of data, such as the entity body in the
request message.

12.4.1.13 412 Precondition Failed
The precondition given in one or more result of the request header fields
evaluated submitting a form,
to false when it was tested on a data-handling process;

. Extending a database through an append operation.
The actual function performed by the server. This response code
allows POST method is determined by the client to place preconditions
server and is usually dependent on the current resource
metainformation (header field data) and thus prevent Request-URI. The posted entity is
subordinate to that URI in the requested
method from being applied same way that a file is subordinate to a resource other than the one intended.

12.4.1.14 413 Request Entity Too Large
The server
directory containing it, a news article is refusing subordinate to process a request because it considers the
request entity newsgroup to be larger than
which it is willing posted, or able a record is subordinate to process. a database.

The
server SHOULD close action performed by the connection if POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is necessary to prevent the
client from continuing appropriate response status, depending on whether or
not the request. response includes an entity that describes the result.

If a resource has been created on the client manages to read origin server, the 413 response, it MUST honor it and response SHOULD reflect it to
be 201 (Created) and contain an entity which describes the user.

If this restriction is considered temporary, status of the server MAY include
request and refers to the new resource , and a
Retry-After Location header field to indicate that it is temporary and after what
time the client MAY try again.

12.4.1.15 414 Request-URI Too Long
The server is refusing (see
section 14.30).

Responses to service the request because this method are not cachable, unless the Request-URI is
longer than response includes
appropriate Cache-Control or Expires header fields. However, the server is willing 303
(See Other) response can be used to interpret. This rare condition is
only likely direct the user agent to occur when a client has improperly converted retrieve a
cachable resource.

POST
request to a GET request with long query information, when requests must obey the client
has descended into a URL "black hole" of redirection (e.g., a redirected
URL prefix message transmission requirements set out in
section 8.2.

9.6 PUT

The PUT method requests that points the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a suffix modified version
of itself), or when the server one residing on the origin server. If the Request-URI does not
point to an existing resource, and that URI is
under attack capable of being defined
as a new resource by the requesting user agent, the origin server can
create the resource with that URI. If a client attempting to exploit security holes present in
some servers using fixed-length buffers for reading or manipulating new resource is created, the
Request-URI.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48] 47]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.4.1.16 415 Unsupported Media Type
The

origin server is refusing to service the request because the entity body of MUST inform the request is in a format not supported by user agent via the requested 201 (Created) response.
If an existing resource for is modified, either the requested method.

12.5 Server Error 5xx
Response status 200 (OK) or 204 (No
Content) response codes beginning with the digit "5" SHOULD be sent to indicate cases in
which the server is aware that it has erred or is incapable successful completion
of
performing the request. If the client has resource could not completed be created or modified with
the request when
a 5xx code is received, it Request-URI, an appropriate error response SHOULD immediately cease sending data to be given that
reflects the
server. Except when responding to a HEAD request, nature of the server SHOULD
include an entity containing an explanation problem. The recipient of the error situation, and
whether entity MUST NOT
ignore any Content-* (e.g. Content-Range) headers that it is a temporary does not
understand or permanent condition. These implement and MUST return a 501 (Not Implemented) response codes
are applicable to any
in such cases.

If the request method passes through a cache and there are no required header
fields.

12.5.1.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it from
fulfilling the request.

12.5.1.2 501 Not Implemented
The server does not support the functionality required Request-URI identifies one
or more currently cached entities, those entries should be treated as
stale. Responses to fulfill the
request. This is the appropriate response when the server does this method are not
recognize cachable.

The fundamental difference between the request method POST and PUT requests is not capable
reflected in the different meaning of supporting it for any
resource.

12.5.1.3 502 Bad Gateway the Request-URI. The server, while acting as URI in a gateway or proxy, received an invalid
response from POST
request identifies the upstream server it accessed in attempting resource that will handle the enclosed entity.
That resource may be a data-accepting process, a gateway to fulfill some other
protocol, or a separate entity that accepts annotations. In contrast,
the request.

12.5.1.4 503 Service Unavailable
The server URI in a PUT request identifies the entity enclosed with the request
-- the user agent knows what URI is currently unable intended and the server MUST NOT
attempt to handle apply the request due to a temporary
overloading or maintenance of some other resource. If the server. The implication is server
desires that this
is a temporary condition which will the request be alleviated after some delay. If
known, applied to a different URI, it MUST send a
301 (Moved Permanently) response; the length of user agent MAY then make its own
decision regarding whether or not to redirect the delay request.

A single resource MAY be indicated in identified by many different URIs. For example,
an article may have a Retry-After
header.
If no Retry-After URI for identifying "the current version" which is given, the client SHOULD handle
separate from the response as it
would for URI identifying each particular version. In this case,
a 500 response.

Note: The existence of PUT request on a general URI may result in several other URIs being
defined by the 503 status code origin server.

HTTP/1.1 does not imply that define how a
server PUT method affects the state of an origin
server.

PUT requests must use it when becoming overloaded. Some servers obey the message transmission requirements set out in
section 8.2.

9.7 DELETE

The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY wish
to simply refuse be overridden by human
intervention (or other means) on the connection.

12.5.1.5 504 Gateway Timeout origin server. The server, while acting as a gateway or proxy, did not receive a timely
response client cannot be
guaranteed that the operation has been carried out, even if the status
code returned from the upstream origin server indicates that the action has been
completed successfully. However, the server SHOULD not indicate success
unless, at the time the response is given, it accessed in attempting intends to complete delete the request.
resource or move it to an inaccessible location.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49] 48]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

12.5.1.6 505 HTTP Version Not Supported
The server

A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted) if the action has not yet
been enacted, or 204 (No Content) if the response is OK but does not support,
include an entity.

If the request passes through a cache and the Request-URI identifies one
or refuses more currently cached entities, those entries should be treated as
stale. Responses to support, the HTTP protocol
version that was this method are not cachable.

9.8 TRACE

The TRACE method is used in to invoke a remote, application-layer loop-back
of the request message. The server is indicating
that it is unable or unwilling to complete final recipient of the request using SHOULD
reflect the same
major version as message received back to the client, client as described in section 7.1, other than
with this error message. the entity-body of a
200 (OK) response. The response SHOULD contain an entity
describing why that version final recipient is not supported and what other protocols
are supported by that server.

13 Method Definitions
The set either the origin server or
the first proxy or gateway to receive a Max-Forwards value of common methods for HTTP/1.1 is defined below. Although this
set can be expanded, additional methods cannot be assumed zero (0)
in the request (see section 14.31). A TRACE request MUST NOT include an
entity.

TRACE allows the client to share see what is being received at the
same semantics for separately extended clients other end
of the request chain and servers. use that data for testing or diagnostic
information. The Host request-header value of the Via header field (section 18.24) MUST accompany all
HTTP/1.1 requests.

13.1 OPTIONS
The OPTIONS method represents 14.44) is of
particular interest, since it acts as a request for information about the
communication options available on trace of the request/response chain identified
by request chain. Use
of the Request-URI. This method Max-Forwards header field allows the client to determine the
options and/or requirements associated with a resource, or limit the
capabilities length
of a server, without implying a resource action or
initiating a resource retrieval.

Unless the server's response request chain, which is useful for testing a chain of proxies
forwarding messages in an error, infinite loop.

If successful, the response 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 a Content-Length SHOULD contain the entire request message in
the entity-body, with a value Content-Type of zero (0). "message/http". Responses to
this method are not cachable.

If the Request-URI is an asterisk ("*"), the OPTIONS request MUST NOT be cached.

10 Status Code Definitions

Each Status-Code is intended
to apply to the server as described below, including a whole. A 200 response SHOULD include any
header fields description of which indicate optional features implemented by 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 9.1.2, an "OPTIONS *" request
method(s) it can be
applied through a proxy by specifying the destination server in the
Request-URI without follow and any path information.

If the Request-URI is not an asterisk, metainformation required in the OPTIONS request applies
response.

10.1 Informational 1xx

This class of status code indicates a provisional response, consisting
only
to of the options that are available when communicating with that
resource.
A 200 response SHOULD include any header fields which indicate Status-Line and optional
features implemented by the server headers, and applicable to that resource
(e.g., Allow), including any extensions not defined is terminated by this
specification, in addition to an
empty line. Since HTTP/1.0 did not define any applicable general or response header
fields. If the OPTIONS request passes through a proxy, the proxy 1xx status codes, servers
MUST
edit the NOT send a 1xx response to exclude those options known to be unavailable
through that proxy. an HTTP/1.0 client except under
experimental conditions.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50] 49]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

13.2 GET

10.1.1 100 Continue

The GET method means retrieve whatever information (in the form of an
entity) client may continue with its request. This interim response is identified by the Request-URI. If the Request-URI refers used
to a
data-producing process, it is inform the produced data which shall be returned
as client that the entity in initial part of the response request has been
received and has not yet been rejected by the source text of the process,
unless that text happens to be the output of the process. server. The semantics client SHOULD
continue by sending the remainder of the GET method change to a "conditional GET" request or, if the request message includes an If-Modified-Since header field. A
conditional GET method requests that the identified resource entity be
transferred only if it has been modified since the date given by the
If-
Modified-Since header, as described in section 18.25. The conditional
GET method is intended to reduce unnecessary network usage by allowing
cached entities to be refreshed without requiring multiple requests or
transferring data
already held by the client. been completed, ignore this response. The semantics of the GET method change to server MUST send a "partial GET" if
final response after the request
message includes a Range header field. A partial GET requests that only
part of the identified resource entity be transferred, as described in
section 18.38. has been completed.

10.1.2 101 Switching Protocols

The partial GET method server understands and is intended to reduce unnecessary
network usage by allowing partially-retrieved entities willing to be completed
without transferring data already held by comply with the client.

The response to a GET request may be cachable if and only if it meets client's
request, via the requirements Upgrade message header field (section 14.41), for HTTP caching described a
change in section 16.

13.3 HEAD the application protocol being used on this connection. The HEAD method is identical
server will switch protocols to GET except that those defined by the server MUST NOT
return any Entity-Body in response's Upgrade
header field immediately after the empty line which terminates the 101
response.

The metainformation contained in
the HTTP headers in response to a HEAD request SHOULD protocol should only be identical switched when it is advantageous to
the information sent in response do so.
For example, switching to a GET request. This method can be
used for obtaining metainformation about the resource entity identified
by the Request-URI without transferring the Entity-Body itself. This
method newer version of HTTP is often used for testing hypertext links for validity,
accessibility, advantageous over
older versions, and recent modification.

The response switching to a HEAD request real-time, synchronous protocol may
be cachable in the sense advantageous when delivering resources that use such features.

10.2 Successful 2xx

This class of status code indicates that the client's request was
successfully received, understood, and accepted.

10.2.1 200 OK

The request has succeeded. The information contained in returned with the response may be used to update a previously
cached entity from that resource. If is
dependent on the new field values indicate that method used in the cached request, for example:

GET an entity differs from corresponding to the current requested resource entity (as would be
indicated by a change is sent in Content-Length, Content-MD5, or Content-
Version), then the cache MUST mark
response;

HEAD the cache entry stale.

There is no "conditional HEAD" or "partial HEAD" request analogous entity-header fields corresponding to
those associated with the GET method. If an If-Modified-Since and/or
Range header field is included with a HEAD request, they SHOULD be
ignored.

13.4 POST
The requested resource
are sent in the response without any message-body;

POST method is used to request that an entity describing or containing the destination server accept result of the action;

TRACE an entity enclosed in containing the request message as a new subordinate of received by the resource end
server.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51] 50]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

identified by the Request-URI

10.2.2 201 Created

The request has been fulfilled and resulted in the Request-Line. POST is designed to
allow a uniform method to cover new resource being
created. The newly created resource can be referenced by 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 URI(s)
returned in the result entity of submitting a form
, to a data-handling process;

. Extending the response, with the most specific URL for
the resource given by a database through an append operation. Location header field. The actual function performed by origin server MUST
create the POST method is determined by resource before returning the 201 status code. If the action
cannot be carried out immediately, the server and is usually dependent on should respond with 202
(Accepted) response instead.

10.2.3 202 Accepted

The request has been accepted for processing, but the Request-URI. processing has not
been completed. The posted entity request MAY or MAY NOT eventually be acted upon, as
it MAY be disallowed when processing actually takes place. There is
subordinate to that URI in the same way that no
facility for re-sending a file status code from an asynchronous operation
such as this.

The 202 response is subordinate to a
directory containing it, a news article intentionally non-committal. Its purpose is subordinate to allow
a newsgroup server to
which it is posted, or accept a record request for some other process (perhaps a batch-
oriented process that is subordinate only run once per day) without requiring that
the user agent's connection to a database.

For compatibility with HTTP/1.0 applications, all POST requests MUST
include a valid Content-Length header field unless the server persist until the process is known
to be HTTP/1.1 compliant. When sending a POST request to
completed. The entity returned with this response SHOULD include an HTTP/1.1
server,
indication of the request's current status and either a client MUST use pointer to a valid Content-Length
status monitor or the "chunked"
Transfer-Encoding. The server SHOULD respond with a 400 (bad request)
message if it cannot determine the length some estimate of when the user can expect 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 be fulfilled.

10.2.4 203 Non-Authoritative Information

The returned metainformation in the entity-header is not require that the entity be created definitive
set as a
resource on available from the origin server server, but is gathered from a local or made accessible for future reference.
That is,
a third-party copy. The set presented MAY be a subset or superset of the action performed by
original version. For example, including local annotation information
about the POST method might not resource MAY result in a
resource that can be identified superset of the metainformation known
by a URI. In this case, either 200 (OK)
or 204 (no content) is the appropriate origin server. Use of this response status, depending on
whether or code is not required and is
only appropriate when the response includes an entity that describes the
result.

If a resource would otherwise be 200 (OK).

10.2.5 204 No Content

The server has been created on fulfilled the origin server, request but there is no new information to
send back. If the response client is a user agent, it SHOULD
be 201 (Created) and contain an entity (preferably of type "text/html") NOT change its
document view from that which describes the status of caused the request and refers to the new
resource.

Responses to this method are not cachable. However, the 303 (See Other)
response can be used sent. This
response is primarily intended to direct the user agent allow input for actions to retrieve take place
without causing a cachable
resource.

POST requests must obey change to the entity transmission requirements set out in
section 13.4.1.

13.4.1 SLUSHY: Entity Transmission Requirements
Editor's Note: user agent's active document view. The issues here around reliable transmission
response MAY include new metainformation in the form of large
entities to servers, particularly HTTP/1.0 servers, are complicated and
subtle, particularly since we'd like optimistic transmission entity-headers,
which SHOULD apply to be the document currently in the user agent's active
view.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52] 51]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

normal situation. We would like it if we can redraft this section to be
simpler in the next draft

General requirements:

. HTTP/1.1 servers should maintain persistent connections and use
TCP's flow control mechanisms to resolve temporary overloads,
rather than terminating connections with the 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
monitor the network connection for 204 response MUST NOT include an error status while it message-body, and thus is
transmitting the request. If the client sees an error status, it
should immediately cease transmitting the body. If always
terminated by the body is
being sent using a "Chunked" encoding, a zero length chunk is used
to mark first empty line after the end of header fields.

10.2.6 205 Reset Content

The server has fulfilled the message. If request and the body was preceded by a
Content-length header, user agent SHOULD reset the client MUST close
document view which caused the connection.
. An HTTP/1.1 (or later) client MUST request to be prepared sent. This response is
primarily intended to accept a "100
Continue" status allow input for actions to take place via user
input, followed by a regular response.
. An HTTP/1.1 (or later) server clearing of the form in which the input is given so
that receives a request from a
HTTP/1.0 (or earlier) client the user can easily initiate another input action. The response
MUST NOT transmit include an entity.

10.2.7 206 Partial Content

The server has fulfilled the 100 (continue)
response; it SHOULD either wait partial GET request for the resource. The
request to be completed
normally (thus avoiding an interrupted request) or close the
connection prematurely.
Upon receiving must have included a method subject to these requirements from an HTTP/1.1
(or later) client, an HTTP/1.1 (or later) server Range header field (section 14.36)
indicating the desired range. The response MUST either immediately
respondwith 100 (continue) and continue to read from include a Content-Range
header field (section 14.17) indicating the input stream,
or respond with an error status. If it responds range included with an error status,
it MAY close this
response. The Content-Length header field in the transport (TCP) connection or it MAY continue to read
and discard response MUST match the rest
actual number of OCTETs transmitted in the request. It message-body.

A cache that does not support the Range and Content-Range headers MUST
NOT perform cache 206 (Partial) responses.

10.3 Redirection 3xx

This class of status code indicates that further action needs to be
taken by the requested
method if it returns an error status.

If an HTTP/1.1 client has seen an HTTP/1.1 or later response from the
server (clients SHOULD remember the version number of at least the most
recently used server), and it sees the connection close before receiving
any status from the server, the client SHOULD retry user agent in order to fulfill the request. If the
client does retry The action
required MAY be carried out by the request,

. it MUST first send user agent without interaction with
the request headers,
. user if and then MUST wait for only if the server to respond with either a 100
(continue) response, method used in which case the client should continue, second request is GET or
with an error status.
If an HTTP/1.1 client has not seen
HEAD. A user agent SHOULD NOT automatically redirect a request more than
5 times, since such redirections usually indicate an HTTP/1.1 infinite loop.

10.3.1 300 Multiple Choices

The requested resource is available in one or later response from more variants, each with
their own specific location, and agent-driven negotiation information
(section 12) is being provided so that the server, user (or user agent) can
select a preferred representation.

Unless it should assume that was a HEAD request, the server implements HTTP/1.0 or
older response SHOULD include an entity
containing a list of resource characteristics and will not use the 100 (Continue) response. If in this case the
client sees the connection close before receiving any status location(s) from which
the
server, user or user agent can choose the client SHOULD retry one most appropriate. The entity
format is specified by the request. If media type given in the client does retry Content-Type header
field. Depending upon the request, it should use format and the following "binary exponential backoff"
algorithm to be assured capabilities of obtaining a reliable response:

1.
Initiate a new connection to the server
2.
Transmit the request headers
3.
Initialize a variable R to the estimated round-trip time to the
server (e.g., based on the time it took to establish user agent,
selection of the most appropriate choice may be performed automatically.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53] 52]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

connection), or to a constant value of 5 seconds if the round-trip
time is

However, this specification does not available.
4.
Compute T = R * (2**N), where N is define any standard for such
automatic selection.

If the number of previous retries server has a preferred choice of this request.
5.
Wait either representation, it SHOULD
include the specific URL for an error response from that representation in the server, or Location field;
user agents MAY use the Location field value for T seconds
(whichever comes first)
6.
If no error automatic redirection.
This response is received, after T seconds transmit cachable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD be done using one of the body
returned URIs. Clients with link editing capabilities SHOULD
automatically re-link references to the Request-URI to one or more of
the request.
7. new references returned by the server, where possible. This response
is cachable unless indicated otherwise.

If client sees that the connection new URI is closed prematurely, repeat
from step 1 until a location, its URL SHOULD be given by the Location
field in the response. Unless the request is accepted, an error method was HEAD, the entity of
the response is
received, or SHOULD contain a short hypertext note with a hyperlink to
the user becomes impatient.
No matter what new URI(s).

If the server version, if an error 301 status code is received,

. received in response to a request other than
GET or HEAD, the client user agent MUST NOT continue and
. MUST close automatically redirect the connection if request
unless it has not already completed sending can be confirmed by the full request body including any encoding mechanism used to
transmit user, since this might change the body.
An HTTP/1.1 (or later) client that sees
conditions under which the connection close request was issued.

Note: When automatically redirecting a POST request after receiving
a 100 (continue) but before receiving any other 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.

10.3.3 302 Moved Temporarily

The requested resource resides temporarily under a different URI. Since
the redirection may be altered on occasion, the client SHOULD
retry continue
to use the request, and need not wait Request-URI for 100 (continue) future requests. This response (but
MAY do so is only
cachable if this simplifies the implementation).

13.5 PUT
The PUT method requests that indicated by a Cache-Control or Expires header field.

If the enclosed entity new URI is a location, its URL SHOULD be stored under given by the
supplied Request-URI. If Location
field in the Request-URI refers to an already existing
resource, response. Unless the request method was HEAD, the enclosed entity SHOULD be considered as a modified version of
the one residing on response SHOULD contain a short hypertext note with a hyperlink to
the origin server. new URI(s).

If the Request-URI does not
point to an existing resource, and that URI 302 status code is capable of being defined
as received in response to a new resource by request other than
GET or HEAD, the requesting user agent, agent MUST NOT automatically redirect the origin server request
unless it can
create the resource with that URI. If a new resource is created, be confirmed by the
origin server MUST inform user, since this might change the user agent via
conditions under which the 201 (created)
response.
If an request was issued.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

Note: When automatically redirecting a POST request after receiving
a 302 status code, some existing resource is modified, either the 200 (OK) or 204 (No
Content) HTTP/1.0 user agents will
erroneously change it into a GET request.

10.3.4 303 See Other

The response codes to the request can be found under a different URI and
SHOULD be sent retrieved using a GET method on that resource. This method
exists primarily to indicate successful completion allow the output of a POST-activated script to
redirect the request. If user agent to a selected resource. The new URI is not a
substitute reference for the resource could originally requested resource. The 303
response is not be created or modified with cachable, but the Request-URI, an appropriate error response to the second (redirected)
request MAY be cachable.

If the new URI is a location, its URL SHOULD be given that
reflects by the nature of Location
field in the problem.

If response. Unless the request passes through a cache and method was HEAD, the Request-URI identifies a
currently cached entity, that entity MUST be removed from of
the cache.
Responses response SHOULD contain a short hypertext note with a hyperlink to this method are not cachable.

The fundamental difference between
the POST new URI(s).

10.3.5 304 Not Modified

If the client has performed a conditional GET request and PUT requests access is
reflected in
allowed, but the different meaning of document has not been modified, the Request-URI. server SHOULD
respond with this status code. The URI in response MUST NOT contain a POST
request identifies the resource that will handle message-
body. Header fields contained in the enclosed entity as response MUST include any values
that, if an appendage. That resource may unconditional request had been made, might be a data-accepting process, a gateway
to some other protocol, or a separate different from
values sent with any prior response for the entity The response MUST
also include any values that accepts annotations.
In contrast, the URI in caches use for matching requests and
responses with cache entries. The response SHOULD NOT include header
fields whose values cannot possibly have changed, such as Content-Type.
Examples of relevant header fields include: Date, Server, Content-
Length, Content-MD5, Content-Version, Cache-Control, ETag, Vary and
Expires.

If a PUT request identifies the 304 response indicates an entity enclosed
with not currently cached, then the request --
cache MUST disregard the user agent knows what URI is intended response and the
server MUST NOT attempt to apply repeat the request to some other resource. If
the server desires that without the request be applied
conditional.

If a cache uses a received 304 response to update a different URI, it cache entry, the
cache MUST send a 301 (Moved Permanently) response; update the user agent MAY then
make its own decision regarding whether or not entry to redirect reflect any new field values given in the request.
response.

The 304 response MUST NOT include an message-body, and thus is always
terminated by the first empty line after the header fields.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

A single

10.3.6 305 Use Proxy

The requested resource MAY MUST be identified by many different URIs. For
example,
an article may have a URI for identifying "the current version" which is
separate from accessed through the URI identifying each particular version. In this
case,
a PUT request on a general URI may result in several other URIs being
defined proxy given by the origin server.

For compatibility with HTTP/1.0 applications, all PUT requests MUST
include a valid Content-Length header
Location field. The Location field unless gives the server URL of the proxy. The
recipient is known expected to be HTTP/1.1 compliant. When sending a PUT repeat the request to an HTTP/1.1
server, a via the proxy.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client MUST use
seems to have erred. Except when responding to a valid Content-Length or HEAD request, the "chunked"
Transfer-Encoding. The
server SHOULD respond with a 400 (bad request)
message if it cannot determine the length include an entity containing an explanation of the request message's
content, or with 411 (length required) if error
situation, and whether it wishes to insist on
receiving is a valid Content-Length.

The actual method for determining how the resource temporary or permanent condition. These
status codes are applicable to any request method. User agents SHOULD
display any included entity is placed, and
what happens to its predecessor, is defined entirely by the origin
server.

PUT requests must obey the entity transmission requirements set out in
section 13.4.1.

13.6 DELETE
The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on user.

Note: If the origin server. The client cannot is sending data, a server implementation using
TCP should be
guaranteed careful to ensure that the operation has been carried out, even if the status
code returned from client acknowledges
receipt of the origin server indicates that packet(s) containing the action has been
completed successfully. However, response, before the server SHOULD not indicate success
unless, at the time
closes the response is given, it intends to delete input connection. If the
resource or move it client continues sending data
to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an
entity describing server after the status, 202 (Accepted) if close, the action has not yet
been enacted, or 204 (No Content) if server's TCP stack will send a
reset packet to the response is OK but does not
include an entity.

If client, which may erase the request passes through a cache client's
unacknowledged input buffers before they can be read and
interpreted by the Request-URI identifies a
currently cached entity, that entity MUST HTTP application.

10.4.1 400 Bad Request

The request could not be removed from understood by the cache.
Responses server due to this method are not cachable.

13.7 TRACE malformed
syntax. The TRACE method is used to invoke a remote, application-layer
loop-back
of client SHOULD NOT repeat the request message. without modifications.

10.4.2 401 Unauthorized

The final recipient of the request SHOULD
reflect the message received back requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.43) containing a challenge
applicable to the requested resource. The client as MAY repeat the entity body of request
with a
200 (OK) response. The final recipient is either suitable Authorization header field (section 14.8). If the origin server or
request already included Authorization credentials, then the first proxy or gateway to receive a Max-Forwards value of zero (0)
in 401
response indicates that authorization has been refused for those
credentials. If the request (see section 18.32). A TRACE request MUST NOT include an
entity.

TRACE allows 401 response contains the client to see what is being received same challenge as the
prior response, and the user agent has already attempted authentication
at least once, then the other end
of user SHOULD be presented the request chain and use entity that data for testing or was
given in the response, since that entity MAY include relevant diagnostic
information. HTTP access authentication is explained in section 11.

10.4.3 402 Payment Required

This code is reserved for future use.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

information.

10.4.4 403 Forbidden

The value of server understood the Via header field (section 18.47) request, but is of
particular interest, since it acts as a trace of refusing to fulfill it.
Authorization will not help and the request chain. Use
of SHOULD NOT be repeated. If
the Max-Forwards header field allows request method was not HEAD and the client server wishes to limit the length
of make public why
the request chain, which is useful for testing a chain of proxies
forwarding messages in an infinite loop.

If successful, the response has not been fulfilled, it SHOULD contain describe the entire request message reason for
the refusal in the entity body, with a Content-Type of "message/http",
"application/http", or "text/plain". Responses to this method MUST NOT
be cached.

14 Access Authentication
HTTP provides a simple challenge-response authentication mechanism which
MAY be entity. This status code is commonly used by a when the
server does not wish to challenge a client reveal exactly why the request and by a client has been refused,
or when no other response is applicable.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or permanent.
If the server does not wish to
provide authentication information. It uses an extensible, case-
insensitive token make this information available to identify the authentication scheme, followed by a
comma-separated list of attribute-value pairs which carry
client, the parameters
necessary for achieving authentication via status code 403 (Forbidden) can be used instead. The 410
(Gone) status code SHOULD be used if the server knows, through some
internally configurable mechanism, that scheme.

auth-scheme = token

auth-param = token "=" quoted-string an old resource is permanently
unavailable and has no forwarding address.

10.4.6 405 Method Not Allowed

The 401 (Unauthorized) response message method specified in the Request-Line is used not allowed for the resource
identified by an origin server to
challenge the authorization of a user agent. This Request-URI. The response MUST include
a WWW-Authenticate an Allow header field
containing at least one challenge
applicable to a list of valid methods for the requested resource.

challenge = auth-scheme 1*SP realm *( "," auth-param )

realm = "realm" "=" realm-value
realm-value = quoted-string

The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge.

10.4.7 406 Not Acceptable

The realm value (case-
sensitive), in combination with resource identified by the canonical root URL request is only capable of generating
response entities which have content characteristics not acceptable
according to the server
being accessed, defines the protection space. These realms allow accept headers sent in the
protected resources on request.

Unless it was a server to be partitioned into HEAD request, the response SHOULD include an entity
containing a set list of
protection spaces, each with its own authentication scheme and/or
authorization database. The realm value is a string, generally assigned
by the origin server, available entity characteristics and location(s)
from which may have additional semantics specific to the authentication scheme.

A user agent that wishes to authenticate itself with a server--usually,
but not necessarily, after receiving a 401 or 411 response--MAY do so user agent can choose the one most appropriate.
The entity format is specified by
including an Authorization the media type given in the Content-
Type header field with field. Depending upon the request. The
Authorization field value consists of credentials containing format and the
authentication information capabilities of the
user agent for the realm agent, selection of the
resource being requested.

credentials = basic-credentials
| auth-scheme 0#auth-param

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]

INTERNET-DRAFT most appropriate choice may be performed
automatically. However, this specification does not define any standard
for such automatic selection.

Note: HTTP/1.1 Friday, May 03, 1996

The domain over servers are allowed to return responses which credentials can be automatically applied by a user
agent is determined by are
not acceptable according to the protection space. If a prior request has been
authorized, accept headers sent in the same credentials MAY request.
In some cases, this may even be reused for all other requests
within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, preferable to sending a single protection
space cannot extend outside 406
response. User agents are encouraged to inspect the scope headers of its server.

If the server does not wish an
incoming response to accept determine if it is acceptable. If the credentials sent with response
could be unacceptable, a
request, it user agent SHOULD return temporarily stop receipt
of more data and query the user for a decision on further actions.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized) response. (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The response proxy MUST include
return a WWW-Authenticate Proxy-Authenticate header field (section 14.33) containing the (possibly
new) a
challenge applicable to the requested resource and an entity
explaining proxy for the refusal. requested resource. The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms client
MAY be used, such as encryption at repeat the transport level or via
message encapsulation, and request with additional a suitable Proxy-Authorization header fields specifying field
(section 14.34). HTTP access authentication information. However, these additional mechanisms are is explained in section 11.

10.4.9 408 Request Timeout

The client did not
defined by this specification.

Proxies MUST be completely transparent regarding user agent
authentication. That is, they MUST forward produce a request within the WWW-Authenticate and
Authorization headers untouched, and MUST NOT cache time that the response server was
prepared to a
request containing Authorization.

HTTP/1.1 allows a wait. The client MAY repeat the request without
modifications at any later time.

10.4.10 409 Conflict

The request could not be completed due to pass authentication information to and from a proxy via conflict with the Proxy-Authenticate and Proxy-Authorization headers.

14.1 Basic Authentication Scheme
The "basic" authentication scheme is based on current
state of the model resource. This code is only allowed in situations where it
is expected 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 might be compared for equality with other realms on that server. The
server will service the request only if it can validate able to resolve the user-ID conflict and
password
resubmit the request. The response body SHOULD include enough
information for the protection space of user to recognize the Request-URI. There are no
optional authentication parameters.

Upon receipt source of an unauthorized request the conflict.
Ideally, the response entity would include enough information for a URI within the protection
space,
user or user-agent to fix the server SHOULD respond with problem; however, that may not be possible
and is not required.

Conflicts are most likely to occur in response to a challenge like the following:

WWW-Authenticate: Basic realm="WallyWorld"

where "WallyWorld" PUT request. If
versioning is being used and the string assigned entity being PUT includes changes to a
resource which conflict with those made by an earlier (third-party)
request, the server MAY use the 409 response to identify indicate that it can't
complete the
protection space request. In this case, the response entity SHOULD contain a
list of the Request-URI.

To receive authorization, differences between the client sends two versions in a format defined by
the user-ID response Content-Type.

10.4.11 410 Gone

The requested resource is no longer available at the server and password,
separated no
forwarding address is known. This condition SHOULD be considered
permanent. Clients with link editing capabilities SHOULD delete
references to the Request-URI after user approval. If the server does
not know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) SHOULD be used instead.
This response is cachable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web
maintenance by a single colon (":") character, within a base64 encoded
string in notifying the credentials.

basic-credentials = "Basic" SP basic-cookie recipient that the resource is
intentionally unavailable and that the server owners desire that remote
links to that resource be removed. Such an event is common for limited-

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

basic-cookie = <base64 [7] encoding of user-pass,
except not limited to 76 char/line>

user-pass = userid ":" password

userid = [ token ]

password = *TEXT

If the user agent wishes to send the user-ID "Aladdin"

time, promotional services and password
"open sesame", it would use for resources belonging to individuals no
longer working at the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

The basic authentication scheme server's site. It is a non-secure method of filtering
unauthorized access not necessary to mark all
permanently unavailable resources on an HTTP server. It is based on as "gone" or to keep the
assumption mark for any
length of time -- that is left to the connection between discretion of the server owner.

10.4.12 411 Length Required

The server refuses to accept the request without a defined Content-
Length. The client and MAY repeat the server can be
regarded as request if it adds a trusted carrier. As this is not generally true on an open
network, valid Content-
Length header field containing the basic authentication scheme should be used accordingly. In
spite length of this, clients SHOULD implement the scheme message-body in order to
communicate with servers that use it.

14.2 Digest Authentication Scheme the
request message.

10.4.13 412 Precondition Failed

The "digest" authentication scheme is [currently described precondition given in an expired
Internet-Draft, and this description will have to be improved to
reference a new draft one or include the old one].

15 Content Negotiation
A generic resource has multiple entities associated with it, all of
which are representations of the content more of the resource. Content
negotiation is request-header fields
evaluated to false when it was tested on the process of selecting server. This response code
allows the best representation when a
GET or HEAD request is made client to place preconditions on the generic resource. HTTP/1.1 has
provisions for two kinds of content negotiation: opaque negotiation current resource
metainformation (header field data) and
transparent negotiation.

With opaque negotiation, thus prevent the selection of requested
method from being applied to a resource other than the best representation one intended.

10.4.14 413 Request Entity Too Large

The server is
done by an algorithm located at the origin server, and unknown refusing to process a request because the
proxies and user agents involved. Selection request entity
is based on the contents of
particular header fields in larger than the request message, server is willing or on other information
pertaining able to process. The server may
close the request, like connection to prevent the network address of client from continuing the sending
client. A typical example of opaque negotiation would be the selection
of a text/html response in a particular language based on request.

If the contents
of condition is temporary, the Accept-Language request server SHOULD include a Retry-After
header field. A disadvantage of opaque
negotiation is field to indicate that it is temporary and after what time the request headers
client may not always contain enough
information try again.

10.4.15 414 Request-URI Too Long

The server is refusing to allow for selection. If service the Accept header

Accept: text/*: q=0.3, text/html, */*: q=0.5 request because the Request-URI is sent in
longer than the server is willing to interpret. This rare condition is
only likely to occur when a client has improperly converted a POST
request on to a generic resource which GET request with long query information, when the client
has descended into a video/mpeg and URL "black hole" of redirection (e.g., a
video/quicktime representation, the selection algorithm in the origin
server will either have redirected
URL prefix that points to make a default choice, suffix of itself), or return an error
response which allows when the user server is
under attack by a client attempting to decide on further actions. 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 58]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

With transparent negotiation,

10.4.16 415 Unsupported Media Type

The server is refusing to service the selection request because the entity of the best representation
request is done by a distributed algorithm which can perform computation steps in a format not supported by the origin server, requested resource for the
requested method.

10.5 Server Error 5xx

Response status codes beginning with the digit "5" indicate cases in proxies,
which the server is aware that it has erred or in is incapable of
performing the user agent. Transparent
negotiation guarantees that, if request. Except when responding to a HEAD request, the user agent supports
server SHOULD include an entity containing an explanation of the transparent
negotiation algorithm error
situation, and whether it is correctly configured, a temporary or permanent condition. User
agents SHOULD display any included entity to the user. These response
codes are applicable to any request will
always correctly yield either the video/mpeg representation, the
video/quicktime representation, or method.

10.5.1 500 Internal Server Error

The server encountered an error message indicating that unexpected condition which prevented it from
fulfilling the
resource cannot be displayed by request.

10.5.2 501 Not Implemented

The server does not support the user agent.

15.1 Negotiation Facilities Defined in this Specification functionality required to fulfill the
request. This specification defines all protocol facilities for opaque
negotiation, but is the appropriate response when the server does not define
recognize the distributed algorithm request method and is not capable of supporting it for
transparent negotiation. This specification only defines any
resource.

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid
response from the basic
facilities (Vary, Alternates, Accept) upstream server it accessed in attempting to fulfill
the core protocol allowing
requests on transparently negotiated resources request.

10.5.4 503 Service Unavailable

The server is currently unable to be correctly handled
by HTTP/1.1 caches. All other information about transparent content
negotiation handle the request due to a temporary
overloading or maintenance of the server. The implication is that this
is found in a separate document[29]. temporary condition which will be alleviated after some delay. If
known, the length of the delay may be indicated in a generic resource Retry-After header.
If no Retry-After is opaquely negotiated, successful responses to
requests on given, the resource will always include a Vary header. If a
generic resource is transparently negotiated, successful responses to
requests on client SHOULD handle the resource will always include an Alternates header. If a
successful response contains an Alternates header, as it will also always
contain a Content-Location header. A future specification may allow a
combination of opaque and transparent negotiation that
would lead to the
inclusion of both a Vary header and an Alternates header in for a 500 response.

16 Caching in HTTP

Note: The World Wide Web is a distributed system, and so its performance can
be improved by the use existence of caches. These caches are typically placed at
proxies and in the clients themselves. The HTTP/1.1 protocol includes 503 status code does not imply that a
number of elements intended to make caching work as well as possible.
Because these elements are inextricable from other aspects of the
protocol, and because they interact with each other,
server must use it is useful to
describe the basic caching design of 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 be able to relax the goal of semantic transparency. The
HTTP/1.1 protocol allows origin servers, caches, and clients to
explicitly reduce transparency when necessary. However, because non-
transparent operation may confuse non-expert users, and may be
incompatible with certain server applications (such as those for
ordering merchandise), the protocol requires that transparency becoming overloaded. Some servers may not
be relaxed

. without an explicit protocol-level request (when relaxed by client
or origin server)
. without a means for warning wish
to simply refuse the end user (when relaxed by cache or
client) connection.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

Therefore, the HTTP/1.1 protocol provides these important elements:

1. Protocol features that provide full semantic transparency when this
is desired by all parties.
2. Protocol features that allow an origin server

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or end-user client to
explicitly request and control non-transparent operation.
3. Protocol features that allow proxy, did not receive a cache timely
response from the upstream server it accessed in attempting to attach warnings complete
the request.

10.5.6 505 HTTP Version Not Supported

The server does not support, or refuses to
responses support, the HTTP protocol
version that do not preserve semantic transparency.
A basic principle was used in the request message. The server is indicating
that it must be possible for the clients to detect
any potential breakdown of semantic transparency.

Caching would be useless if it did not significantly improve
performance. The goal of caching in HTTP/1.1 is unable or unwilling to eliminate complete the need to
send requests in many cases, and to eliminate request using the need to send full
responses same
major version as the client, as described in many section 3.1, other cases. The former reduces the number of network
round-trips required for many operations; we use an "expiration"
mechanism for than
with this purpose (see section 16.1.2). error message. The latter reduces
network bandwidth requirements; we use response SHOULD contain an entity
describing why that version is not supported and what other protocols
are supported by that server.

11 Access Authentication

HTTP provides a "validation" simple challenge-response authentication mechanism for this
purpose (see section 13.3).

The server, cache, or client implementer may which
MAY be faced with design
decisions not explicitly discussed in this specification. If used by a decision
may affect semantic transparency, the implementer ought server to err on the
side of maintaining transparency unless challenge a careful client request and complete analysis
shows significant benefits in breaking transparency.

16.1.1 Cache Correctness
If the cache can communicate with the origin-server, then by a correct
cache MUST respond client to a request with a response that meets all the
following conditions:

1. its end-to-end headers (see section 16.4.1) and entity-body value
are equivalent
provide authentication information. It uses an extensible, case-
insensitive token to what identify the server would have returned authentication scheme, followed by a
comma-separated list of attribute-value pairs which carry the parameters
necessary for achieving authentication via that
request if the resource had not been modified since the scheme.

auth-scheme = token

auth-param = token "=" quoted-string

The 401 (Unauthorized) response
was cached. This may be accomplished message is used by revalidating an origin server to
challenge the authorization of a user agent. This response
with MUST include
a WWW-Authenticate header field containing at least one challenge
applicable to the origin server, if is not fresh.
2. it requested resource.

challenge = auth-scheme 1*SP realm *( "," auth-param )

realm = "realm" "=" realm-value
realm-value = quoted-string

The realm attribute (case-insensitive) is "fresh enough" (see section 16.1.2). In the default case,
this means it meets the least restrictive freshness requirement of required for all
authentication schemes which issue a challenge. The realm value (case-
sensitive), in combination with the client, server, and cache canonical root URL (see section 18.10); if
5.1.2) of the origin- server so specifies, it is being accessed, defines the freshness requirement of protection space. These
realms allow the
origin- protected resources on a server alone.
3. it includes to be partitioned into
a warning if the freshness demand set of the client or the
origin-server is violated (see section 16.1.5 and 18.48).
4. it is the most up-to-date response appropriate to the request the
cache has seen (see section 16.2.6, 16.2.8, and 16.13).
If the cache can not communicate protection spaces, each with its own authentication scheme
and/or authorization database. The realm value is a string, generally
assigned by the origin server, then a correct
cache SHOULD respond as above if the response can be correctly served
from which may have additional semantics
specific to the cache; if not it MUST return an error or warning indicating
that there was a communication. authentication scheme.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

16.1.2 Cache-control Mechanisms
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
times and validators) are implicit directives

A user agent that wishes to caches. In some cases, authenticate itself with a server server--usually,
but not necessarily, after receiving a 401 or client may need to provide explicit directives to 411 response--MAY do so by
including an Authorization header field with the HTTP
caches. We use request. The
Authorization field value consists of credentials containing the Cache-Control header
authentication information of the user agent for this purpose. the realm of the
resource being requested.

credentials = basic-credentials
| auth-scheme #auth-param

The Cache-Control header allows domain over which credentials can be automatically applied by a client or server to transmit user
agent is determined by the protection space. If a variety
of directives in either prior request has been
authorized, the same credentials MAY be reused for all other requests or responses. These directives
typically override
within that protection space for a period of time determined by the default caching algorithms. As
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a general rule, if
there is any apparent conflict between header values, single protection
space cannot extend outside the most
restrictive interpretation should be applied (that is, scope of its server.

If the one that is
most likely server does not wish to preserve semantic transparency). However, in some cases,
Cache-Control directives are explicitly specified as weakening semantic
transparency (for example, "max-stale" or "public").

The Cache-Control directives are described in detail in section 18.10.

16.1.3 Warnings
Whenever accept the credentials sent with a cache returns
request, it SHOULD return a 401 (Unauthorized) response. The response that is not semantically
transparent, it must attach
MUST include a warning WWW-Authenticate header field containing the (possibly
new) challenge applicable to that effect, using a Warning
response header. This warning allows clients the requested resource and user agents an entity
explaining the refusal.

The HTTP protocol does not restrict applications to take
appropriate action.

Warnings may be used this simple
challenge-response mechanism for other purposes, both cache-related access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or via
message encapsulation, and
otherwise. The use of a warning, rather than an error status code,
distinguish with additional header fields specifying
authentication information. However, these responses from true failures.

Warnings additional mechanisms are always cachable, because not
defined by this specification.

Proxies MUST be completely transparent regarding user agent
authentication. That is, they never weaken MUST forward the transparency
of WWW-Authenticate and
Authorization headers untouched, and follow the rules found in section
14.8.

HTTP/1.1 allows a response. This means that warnings can be passed client to HTTP/1.0 caches
without danger; such caches will simply pass the warning along as authentication information to and from
a
entity header in proxy via the response.

Warnings are assigned numbers between 0 Proxy-Authenticate and 99. This specification
defines Proxy-Authorization headers.

11.1 Basic Authentication Scheme

The "basic" authentication scheme is based on the code numbers and meanings of each warning, allowing model that the user
agent must authenticate itself with a client
or cache to take automated action in some (but not all) cases.

Warnings also carry user-ID and a warning message text in any appropriate natural
language (perhaps based 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 client's Accept headers), request only if it can validate the user-ID and an optional
indication
password for the protection space of what language and character set the Request-URI. There are used.

Multiple warning messages may be attached to no
optional authentication parameters.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

Upon receipt of an unauthorized request for a response (either by URI within the
origin server or by a cache), including multiple warnings with protection
space, the same
code number. For example, a server may provide the same warning MAY respond with
texts in both English and Basque.

When multiple warnings are attached to a response, it may not be
practical or reasonable challenge like the following:

WWW-Authenticate: Basic realm="WallyWorld"

where "WallyWorld" is the string assigned by the server to display all identify the
protection space of them to the user. This version Request-URI.

To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 encoded
string in the credentials.

basic-credentials = "Basic" SP basic-cookie

basic-cookie = <base64 [7] encoding of HTTP does user-pass,
except not specify strict priority rules limited to 76 char/line>

user-pass = userid ":" password

userid = *<TEXT excluding ":">

password = *TEXT

Userids might be case sensitive.

If the user agent wishes to send the userid "Aladdin" and password "open
sesame", it would use the following header field:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

See section 15 for deciding security considerations associated with Basic
authentication.

11.2 Digest Authentication Scheme

Note for the RFC editor: This section is reserved for including the
Digest Authentication specification, or if the RFC editor chooses to
issue a single RFC rather than two RFC's, this section should be
deleted.

12 Content Negotiation

Most HTTP responses include an entity which
warnings contains information for
interpretation by a human user. Naturally, it is desirable to display supply the
user with the "best available" entity corresponding to the request.
Unfortunately for servers and in caches, not all users have the same
preferences for what order, but does suggest some
heuristics.

The Warning header is "best," and the currently defined warnings not all user agents are described in
section 18.48. equally
capable of rendering all entity types. For that reason, HTTP has
provisions for several mechanisms for "content negotiation" -- the

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61] 62]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

16.1.4 Explicit User Agent Warnings
Many user agents make it possible for users to override

process of selecting the basic
caching mechanisms. For example, best representation for a given response when
there are multiple representations available.

Note: This is not called "format negotiation" because the user agent alternate
representations may allow be of the user to
specify same media type, but use different
capabilities of 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" type, be in different languages, etc.

Any response containing an entity-body MAY be subject to every request. We recognize
that there negotiation,
including error responses.

There are two kinds of content negotiation which are possible in HTTP:
server-driven and agent-driven negotiation. These two kinds of
negotiation are orthogonal and thus may be situations which require such overrides, although user
agents SHOULD NOT default to any behavior contrary to the HTTP/1.1
specification. That is, the user should have to explicitly request
either non-transparent behavior, used separately or behavior that results in abnormally
ineffective caching.

If the user has overridden the basic caching mechanisms, the user agent
should explicitly indicate
combination. One method of combination, referred to as transparent
negotiation, occurs when a cache uses the user whenever this results agent-driven negotiation
information provided by the origin server in order to provide server-
driven negotiation for subsequent requests.

12.1 Server-driven Negotiation

If the
display selection of information that might not meet the server's transparency
requirements (in particular, if best representation for a response is made by an
algorithm located at the displayed entity server, it is known to be
stale). Since called server-driven negotiation.
Selection is based on the protocol normally allows available representations of the user agent to determine
if responses are stale or not, this indication need only be displayed
when this actually happens. The indication need not be a dialog box; response (the
dimensions over which it
could be an icon (for example, a picture can vary; e.g. language, content-coding, etc.)
and the contents of a rotting fish) particular header fields in the request message or some
on other visual indicator.

If the user has overridden information pertaining to the caching mechanisms in a way that would
abnormally reduce request (such as the effectiveness network
address of caches, the user agent should
continually display an indication (for example, a picture of currency in
flames) so that client).

Server-driven negotiation is advantageous when the user does not inadvertently consume excess resources
or suffer algorithm for
selecting from excessive latency.

16.1.5 Exceptions to the Rules and Warnings
In some cases, among the operator of a cache may choose available representations is difficult to configure it
describe to
return stale responses even when not requested by clients. This decision
not be made lightly, but may be necessary for reasons of availability the user agent, or
performance, especially when the cache is poorly connected server desires to send its "best
guess" to the origin
server. Whenever a cache returns a stale response, it MUST mark it as
such (using a Warning header). This allows the client software along with the first response (hoping to alert avoid the user that there may be
round-trip delay of a potential problem.

It also allows subsequent request if the user to take steps "best guess" is good
enough for the user). In order to obtain a firsthand or fresh
response, if improve the user so desires. For this reason, a cache MUST NOT
return a stale response if server's guess, the client explicitly requests user
agent MAY include request header fields (Accept, Accept-Language,
Accept-Encoding, etc.) which describe its preferences for such a first-hand
or fresh one, unless it
response.

Server-driven negotiation has disadvantages:

1. It is impossible to comply.

16.1.6 Client-controlled Behavior
While for the origin server (and to a lesser extent, intermediate caches, by
their contribution to the age accurately determine what might be
"best" for any given user, since that would require complete
knowledge of a response) are both the primary source capabilities of
expiration information, in some cases the client may need to control a
cache's decision about whether to return a cached response without
validating it. Clients do this using several directives of user agent and the Cache-
Control header.

A client's request may specify intended
use for the maximum age it is willing response (e.g., does the user want to accept
for an unvalidated response; specifying view it on screen
or print it on paper?).

2. Having the user agent describe its capabilities in every request can
be both very inefficient (given that only a value small percentage of
responses have multiple representations) and a potential violation of zero forces
the user's privacy.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62] 63]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

cache(s) to revalidate all responses. A client may also specify the
minimum time remaining before a response expires. Both of these options
increase constraints on

3. It complicates the behavior implementation of caches, an origin server and so cannot decrease
semantic transparency.

A client the
algorithms for generating responses to a request.

4. It may also specify that it will accept stale responses, up limit a public cache's ability to
some maximum amount of staleness. This loosens use the constraints on same response for
multiple user's requests.

HTTP/1.1 includes the
caches, and so may violate semantic transparency, but may be necessary
to support disconnected operation, or high availability in the 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 following request-header fields for enabling
server-driven negotiation through description of user agent capabilities
and user preferences: Accept (section 14.1), Accept-Charset (section
14.2), Accept-Encoding (section 14.3), Accept-Language (section 14.4),
and User-Agent (section 14.42). However, an origin server is not limited
to provide an explicit expiration time in these dimensions and MAY vary the future,
indicating that a response may be used to satisfy subsequent requests.
In other words, a cache can return a fresh response without first
contacting based on any aspect of the server.

Our expectation is that
request, including information outside the request-header fields or
within extension header fields not defined by this specification.

HTTP/1.1 origin servers will assign future explicit expiration
times to responses MUST include an appropriate Vary header field
(section 14.43) in any response based on server-driven negotiation. The
Vary header field describes the belief that dimensions over which the entity is not likely to
change, in a semantically significant way, before response might
vary (i.e. the expiration time is
reached. This normally preserves semantic transparency, as long as dimensions over which the
server's expiration times are carefully chosen.

If an origin server wishes to force a semantically transparent cache to
validate every request, picks its "best
guess" response from multiple representations).

HTTP/1.1 public caches MUST recognize the Vary header field when it may assign an explicit expiration time is
included in the
past. This means that the a response is always stale, and so obey the cache
SHOULD validate it before using it for subsequent requests. (See requirements described in section 18.10.4 for a more restrictive way to force revalidation).

Note
13.5 that a firsthand response MUST always be returned to describes the
requesting client, independent interactions between caching and content
negotiation.

12.2 Agent-driven Negotiation

With agent-driven negotiation, selection of its expiration time, unless the
connection to the client best representation for
a response is lost.

If performed by the user agent after receiving an initial
response from the origin server wishes to force any HTTP/1.1 cache, no matter how it server. Selection is configured, to validate every request, it should use based on a list of the "must-
revalidate" Cache-Control directive. See section 18.10.

Servers specify explicit expiration times using either
available representations of the Expires
header, or response included within the max-age directive header
fields (this specification reserves the keyword Alternates, to be
defined in a separate specification [27]) or entity-body of the Cache-Control header.

16.2.2 Limitations on initial
response, with each representation identified by its own URI. Selection
from among the Effect of Expiration Times
An expiration time cannot representations may be used to force a performed automatically (if the
user agent to refresh its
display is capable of doing so) or reload a resource entity; its semantics apply only to caching
mechanisms, and such mechanisms need only check a resource's expiration
status when manually by the user selecting
from a new request for that resource generated (possibly hypertext) menu.

Agent-driven negotiation is initiated.

User agents often have history mechanisms, such advantageous when the response would vary
over commonly-used dimensions (such as "Back" buttons type, language, or encoding),
when the origin server is unable to determine a user agent's
capabilities from examining the request, and
history lists, which can be generally when public
caches are used to redisplay an entity retrieved

Fielding, Frystyk, Berners-Lee, Gettys, distribute server load and Mogul [Page 63]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

earlier in a session. By default, an expiration time does not apply to
history mechanisms. If reduce network usage.

Agent-driven negotiation suffers from the entity is still in storage, disadvantage of needing a history
mechanism should display it even if the entity has expired, unless the
user has specifically configured the agent
second request to refresh expired history
documents.

16.2.3 Heuristic Expiration
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that use other header values (such as obtain the Last-Modified
time)
to estimate a plausible expiration time. The HTTP/1.1 best alternate representation. This second
request is only efficient when caching is used. In addition, this
specification does not provide specific algorithms, but define any mechanism for supporting automatic

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

selection, though it also does impose worst-case constraints
on their results. Since heuristic expiration times may compromise
semantic transparency, they should be not prevent any such mechanism from being
developed as an extension and used cautiously, within HTTP/1.1.

HTTP/1.1 defines the 300 (Multiple Choices) and we encourage
origin servers 406 (Not Acceptable)
status codes for enabling agent-driven negotiation when the server is
unwilling or unable to provide explicit expiration times as much as
possible.

16.2.4 Age Calculations
In order to know if a cached entry varying response using server-driven
negotiation.

12.3 Transparent Negotiation

Transparent negotiation is fresh, a cache needs to know if
its age exceeds its freshness lifetime. We discuss how to calculate the
latter in section 0; this section describes how to calculate the age of a response or cache entry.

In this discussion, we use the term "now" to mean "the current value combination of
the clock at the host performing the calculation." All HTTP
implementations, but especially origin servers both server-driven and caches, should use
NTP [RFC1305] or some similar protocol to synchronize their clocks to a
globally accurate time standard.

Also note that HTTP/1.1 requires origin servers to send
agent-driven negotiation. When a Date header cache is supplied with every response, giving the time at which the response was
generated. We use the term "date_value" to denote a representation of
the value of the Date header, in a form appropriate for arithmetic
operations.

HTTP/1.1 uses the "Age" response header to help convey age information
between caches. The Age header value is the sender's estimate of the
amount
list of available representations of time since the response was generated at the origin server. In (as in agent-driven
negotiation) and the case dimensions of a cached response that has been revalidated with the origin
server, variance are completely understood by
the Age value is based on cache, then the time cache becomes capable of revalidation, not performing server-driven
negotiation on behalf of the
original response.

In essence, the Age value is origin server for subsequent requests on
that resource.

Transparent negotiation has the sum advantage of distributing the time
negotiation work that the response has
been resident in each would otherwise be required of the caches along the path from the origin
server, plus server
and also removing the amount second request delay of time it has been in transit along network
paths.

We use agent-driven negotiation
when the term "age_value" cache is able to denote a representation of the value of correctly guess the Age header, in a form appropriate right response.

This specification does not define any mechanism for arithmetic operations.

An response's age can be calculated in two entirely independent ways:

Fielding, Frystyk, Berners-Lee, Gettys, transparent
negotiation, though it also does not prevent any such mechanism from
being developed as an extension and Mogul [Page 64]

INTERNET-DRAFT used within HTTP/1.1. An HTTP/1.1 Friday, May 03, 1996

1. now - date_value, if
cache performing transparent negotiation MUST include a Vary header
field in the local clock is reasonably well
synchronized response (defining the dimensions of its variance) to
ensure correct interoperation with all HTTP/1.1 clients. The agent-
driven negotiation information supplied by the origin server's clock. If server SHOULD be
included with the result is
negative, this transparently negotiated response.

13 Caching in HTTP

HTTP is replaced typically used for distributed information systems, where
performance can be improved by zero.
2. age_value, if all of the caches along the response path implement
HTTP/1.1.
Given that we have two independent ways to compute the age use of a response
when it is received, we can combine these as

corrected_received_age = max(now - date_value, age_value)

and as long as we have either nearly synchronized clocks or
all-HTTP/1.1
paths, one gets a reliable (conservative) result.

Note that this correction is applied at each caches. The HTTP/1.1 cache along the
path, so that if there is an HTTP/1.0 cache in the path, the correct
received age is computed
protocol includes a number of elements intended to make caching work as long
well as possible. Because these elements are inextricable from other
aspects of the receiving cache's clock is
nearly in sync. We don't need end-to-end clock synchronization
(although protocol, and because they interact with each other, it
is good useful to have), and there is no explicit clock synchronization
step.

Because describe the basic caching design of network-imposed delays, some significant interval may pass HTTP separately from
the time that a server generates a response, and the time detailed descriptions of methods, headers, response codes, etc.

Caching would be useless if it did not significantly improve
performance. The goal of caching in HTTP/1.1 is
received at to eliminate the next outbound cache or client. If uncorrected, this
delay could result need to
send requests in improperly low ages.

Because many cases, and to eliminate the request that resulted need to send full
responses in many other cases. The former reduces the returned Age value must have
been initiated prior to that Age value's generation, number of network
round-trips required for many operations; we can correct use an "expiration"
mechanism for
delays imposed by the this purpose (see section 13.2). The latter reduces

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

network by recording bandwidth requirements; we use a "validation" mechanism for this
purpose (see section 13.3).

Requirements for performance, availability, and disconnected operation
require us to be able to relax the time at which goal of semantic transparency. The
HTTP/1.1 protocol allows origin servers, caches, and clients to
explicitly reduce transparency when necessary. However, because non-
transparent operation may confuse non-expert users, and may be
incompatible with certain server applications (such as those for
ordering merchandise), the protocol requires that transparency may be
relaxed

. only by an explicit protocol-level request
was initiated. Then, when relaxed by client
or origin server
. only with an Age value is received, it MUST be
interpreted relative explicit warning to the time end user when relaxed by cache
or client
Therefore, the HTTP/1.1 protocol provides these important elements:

1. Protocol features that provide full semantic transparency when this
is required by all parties.
2. Protocol features that allow an origin server or end-user client to
explicitly request was initiated, and control non-transparent operation.
3. Protocol features that allow a cache to attach warnings to
responses that do not preserve the time requested approximation of
semantic transparency.
A basic principle is that it must be possible for the response was received. This algorithm results clients to detect
any potential relaxation of semantic transparency.

Note: The server, cache, or client implementer may be faced with
design decisions not explicitly discussed in conservative
behavior no matter how much delay is experienced. So, we compute:

corrected_initial_age = corrected_received_age
+ (now - request_time)

where "request_time" is this specification. If
a decision may affect semantic transparency, the time (according implementer ought
to err on the local clock) when the
request that elicited this response was sent.

Summary side of age calculation algorithm, when a cache receives maintaining transparency unless a response:

/*
* age_value
* is careful and
complete analysis shows significant benefits in breaking
transparency.

13.1.1 Cache Correctness

If the value of Age: header received by cache can communicate with the origin-server, then a correct
cache MUST respond to a request with
* this response.
* date_value
* is a response that meets one of the
following conditions:

1. Its end-to-end headers (see section 13.4.1) and entity-body value of
are equivalent to what the origin server's Date: header
* request_time
* is server would have returned for that
request if the (local) time when resource had not been modified since the cache made response
was cached, by revalidating the request
* that resulted in this cached response
* response_time
* with the origin server, if
is not fresh.
2. It is "fresh enough" (see section 13.2). In the (local) time when default case, this
means it meets the least restrictive freshness requirement of the
client, server, and cache received (see section 14.9); if the
* response
* now origin-server

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65] 66]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

* 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 sends a response,

so specifies, it must add to the corrected_initial_age is the amount freshness requirement of time that the response was resident locally. origin-server
alone.
3. It must then
transmit this total age, using includes a warning if the Age header, to freshness demand of the next recipient
cache.

Note that a client can usually tell if a response or the
origin-server is violated (see section 13.1.5 and 14.45).
and it is firsthand by
comparing the Date most up-to-date response appropriate to its local request-time, the request the
cache has (see section 13.2.5, 13.2.6, and hoping that 13.10).

If the
clocks are cache can not badly skewed.

16.2.5 Expiration Calculations
In order to decide whether communicate with the origin server, then a response is fresh or stale, we need to
compare its freshness lifetime to its age. The age is calculated correct
cache SHOULD respond as
described in section 16.2.4; this section describes how to calculate the
freshness lifetime, and to determine above if a the response has expired.

We use can be correctly served
from the term "expires_value" to denote cache; if not it MUST return an error or warning indicating
that there was a representation of communication failure.

13.1.2 Warnings

Whenever a cache returns a response that is neither first-hand nor
"fresh enough" (in the value sense of the Expires header, condition 2 in 13.1.1), it must attach a form
warning to that effect, using a Warning response-header. This warning
allows clients to take appropriate action.

Warnings may be used for arithmetic operations.
We other purposes, both cache-related and
otherwise. The use the term "max_age_value" to denote an appropriate representation of a warning, rather than an error status code,
distinguish these responses from true failures.

Warnings are always cachable, because they never weaken the number of seconds carried by the max-age directive transparency
of the Cache-
Control header in a response (see section 18.11).

The max-age directive takes priority over Expires, so if max-age is
present in a response, the calculation is simply:

freshness_lifetime = max_age_value

Otherwise, if Expires is present in the response, the calculation is:

freshness_lifetime = expires_value - date_value

Note response. This means that neither of these calculations is vulnerable warnings can be passed to clock skew,
since all of the information comes from HTTP/1.0 caches
without danger; such caches will simply pass the origin server.

If neither Expires nor Cache-Control max-age appears warning along as a
entity-header in the response, response.

Warnings are assigned numbers between 0 and 99. This specification
defines the response does code numbers and meanings of each currently assigned
warnings, allowing a client or cache to take automated action in some
(but not include other restrictions all) cases.

Warnings also carry a warning text. The text may be in any appropriate
natural language (perhaps based on caching, the
cache MAY compute a freshness lifetime using a heuristic. This heuristic client's Accept headers), and
include an optional indication of what character set is subject to certain limitations; the minimum value used.

Multiple warnings may be zero, and attached to a response (either by the maximum value MUST be no more than 24 hours.

Also, if origin
server or by a cache), including multiple warnings with the response does have same code
number. For example, a Last-Modified time, server may provide the heuristic
expiration value SHOULD same warning with texts in
both English and Basque.

When multiple warnings are attached to a response, it may not be no more than some fraction
practical or reasonable to display all of them to the interval
since that time. A typical setting user. This version
of this fraction might be 10%. HTTP does not specify strict priority rules for deciding which
warnings to display and in what order, but does suggest some heuristics.

The Warning header and the currently defined warnings are described in
section 14.45.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66] 67]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

13.1.3 Cache-control Mechanisms

The calculation to determine if a response has expired is quite simple:

response_is_fresh = (freshness_lifetime > current_age)

16.2.6 Scope of Expiration
HTTP/1.1's basic cache mechanisms in HTTP/1.1 (server-specified expiration model is that as soon as any variant of a URI
becomes stale, all variants becomes stale as well. Thus, "freshness"
applies to all the variants of URI, rather than any particular variant.
Dates
times and expires etc. apply validators) are implicit directives to any cached variant that a proxy might
have with caches. In some cases,
a URI and not just the one particular entity.

Editor's note: This restriction server or client may be dropped in need to provide explicit directives to the next draft; there
are still discussions about whether this restriction is needed.

16.2.7 Disambiguating Expiration Values
Because expiration values are assigned optimistically, it is possible
that two caches may contain fresh values for HTTP
caches. We use the same resource that are
different.

If a client performing a retrieval receives a non-firsthand response Cache-Control header for
a resource entity that was already fresh in its own cache, and the Date this purpose.

The Cache-Control header in its existing cache entry is newer than the Date on the new
response, then the client MAY ignore the response. If so, it MAY retry
the request with allows a "Cache-Control: max-age=0" directive (see section
18.10), client or server to force transmit a check with variety
of directives in either requests or responses. These directives
typically override the origin server.

If default caching algorithms. As a cache that general rule, if
there is pooling cached responses from other caches sees two
fresh responses for any apparent conflict between header values, the same resource entity with different validators,
it SHOULD use most
restrictive interpretation should be applied (that is, the one with the newer Date header.

16.2.8 Disambiguating Multiple Responses
Because a client may be receiving responses via multiple paths, so that is
most likely to preserve semantic transparency). However, in some responses flow through one set of caches and other responses flow
through a different set cases,
Cache-Control directives are explicitly specified as weakening the
approximation of caches, a client may receive responses semantic transparency (for example, "max-stale" or
"public").

The Cache-Control directives are described in an
order different from that detail in which the origin server generated them. We
would like the client section 14.9.

13.1.4 Explicit User Agent Warnings

Many user agents make it possible for users to use override the most recently generated response, even
if older responses are still apparently fresh.

Neither basic
caching mechanisms. For example, the entity tag nor user agent may allow the expiration value can impose an ordering
on responses, since it is possible user to
specify that a later response intentionally
carries an earlier expiration time. However, the HTTP/1.1 specification
requires cached entities (even explicitly stale ones) are never
validated. Or the transmission of Date headers on user agent might habitually add "Cache-Control: max-
stale=3600" or "Cache-Control: reload" to every response, and the
Date values are ordered request. The user should
have to a granularity of one second.

If a client performs a explicitly request for a resource entity either non-transparent behavior, or behavior
that it already has results in its cache, and the response it receives contains a Date header that
appears to be older than abnormally ineffective caching.

If the one it already user has in its cache, then the
client SHOULD repeat overridden the request unconditionally, and include

Cache-Control: max-age=0

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 67]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

to force any intermediate caches to validate their copies directly with basic caching mechanisms, the origin server, or

Cache-Control: no-cache

to force any intermediate caches user agent
should explicitly indicate to obtain a new copy from the origin
server. This prevents certain paradoxes arising from user whenever this results in the use
display of multiple
caches.

If information that might not meet the Date values are equal, then the client may use either response
(or may, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second, server's transparency
requirements (in particular, if
their expiration times overlap.

16.3 Validation Model
When a 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 origin server (or
possibly an intermediate cache with a fresh response) to see if its
cached entry displayed entity is still usable. We call this "validating" the cache
entry.
Since we do not want to have known to pay the overhead of retransmitting be
stale). Since the
full response if protocol normally allows the cached entry is good, and we do not want user agent to pay the
overhead of an extra round trip determine
if the cached entry is invalid, the
HTTP/1.1 protocol supports the use of conditional methods.

The key protocol features for supporting conditional methods responses are those
concerned with "cache validators." When an origin server generates stale or not, this indication need only be displayed
when this actually happens. The indication need not be a
full response, dialog box; it attaches some sort
could be an icon (for example, a picture of validator to it, which is kept
with the cache entry. When a client (end-user rotting fish) or cache) makes a
conditional request for a resource for which it some
other visual indicator.

If the user has a cache entry, it
includes overridden the associated validator caching mechanisms in the request.

The server then checks a way that validator against would
abnormally reduce the current validator for effectiveness of caches, 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 user agent should
continually display an indication (for example, a full response (including entity body). Thus, we avoid
transmitting the full response if picture of currency in
flames) so that the validator matches, and we avoid an
extra round trip if it user does not match.

Note: the comparison functions used inadvertently consume excess resources
or suffer from excessive latency.

13.1.5 Exceptions 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 Rules and negative senses Warnings

In some cases, the operator of cache-
validating conditions. That is, a cache may choose to configure it is possible to request either that a
method be performed if and only if the validators match, or if and only
if the validators do
return stale responses even when not match. requested by clients. This decision

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

Note: a response that lacks a cache validator

should not be made lightly, but may still be cached,
and served from necessary for reasons of
availability or performance, especially when the cache until it expires, unless this is explicitly
prohibited by a Cache-Control directive. However, poorly
connected to the origin server. Whenever a cache cannot do returns a conditional retrieval if stale
response, it does not have MUST mark it as such (using a cache validator for Warning header). This allows
the entity, which means it will not client software to alert the user that there may be refreshable after it
expires.

16.3.1 Last-modified Dates
In HTTP/1.0, a potential
problem.

It also allows the only user to take steps to obtain a first-hand or fresh
response. For this reason, a cache validator SHOULD NOT return a stale response if
the client explicitly requests a first-hand or fresh one, unless it is
impossible to comply for technical or policy reasons.

13.1.6 Client-controlled Behavior

While the Last-Modified time carried origin server (and to a lesser extent, intermediate caches, by
their contribution to the age of a response. response) are the primary source of
expiration information, in some cases the client may need to control a
cache's decision about whether to return a cached response without
validating it. Clients validate entities do this using several directives of the If-Modified-Since Cache-
Control header. In simple terms, a cache entry

A client's request may specify the maximum age it is considered willing to be valid if accept
of an unvalidated response; specifying a value of zero forces the
actual resource entity has not been modified since
cache(s) to revalidate all responses. A client may also specify the original
minimum time remaining before a response
was generated.

16.3.2 Entity Tags
HTTP/1.1 introduces expires. Both of these options
increase constraints on the possibility behavior of using an "opaque" validator,
called an "entity tag," for situations where caches, and so cannot further
relax the Last-Modified date is
not appropriate. This cache's approximation of semantic transparency.

A client may include server implementations where also specify that it is not
convenient will accept stale responses, up to store modification dates,
some maximum amount of staleness. This loosens the constraints on the
caches, and so may violate the origin server's specified constraints on
semantic transparency, but may be necessary to support disconnected
operation, or where high availability in the one-second
resolution face of poor connectivity.

13.2 Expiration Model

13.2.1 Server-Specified Expiration

HTTP date values is insufficient, or where caching works best when caches can entirely avoid making requests
to the origin server. The primary mechanism for avoiding requests is for
an origin server wishes to avoid certain paradoxes that may arise from provide an explicit expiration time in the use of
modification dates.

An entity tag is simply future,
indicating that a string of octets whose internal structure is
not known response may be used to clients or caches. Caches store entity tags and return them
when making conditional satisfy subsequent requests. Also, when
In other words, a cache receives a
conditional request for a resource for which it has can return a fresh cache
entry,
it 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 response without first
contacting the Last-Modified date may be useful for purposes other than cache
validation, HTTP/1.1 server.

Our expectation is that servers SHOULD send Last-Modified whenever
feasible.

The headers used will assign future explicit expiration
times to convey entity tags are described responses in sections Error!
Reference source not found., Error! Reference source the belief that the entity is 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 likely to decide if they represent the same or different resource entities, one
normally would expect that if the resource entity (the entity body or
any entity headers) changes
change, in 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 when way, before the expiration time is

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 69]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

insignificant aspects of the resource entity change. A validator that
does not always change when the resource changes is a "weak validator."

One can think of a strong validator

reached. This normally preserves semantic transparency, as long as one that changes whenever the
bits of an entity changes, while
server's expiration times are carefully chosen.

The expiration mechanism applies only to responses taken from a weak value changes whenever cache
and not to first-hand responses forwarded immediately to the
meaning of an entity changes. Alternatively, one can think of a strong
validator as part of an identifier for a specific entity, while a weak
validator is part of requesting
client.

If an identifier for origin server wishes to force a set of semantically equivalent
entities.

Note: One example of a strong validator is an integer that is
incremented in stable storage transparent cache to
validate every time an entity is changed.

An entity's modification time, if represented with one-second
resolution, could be a weak validator, since request, it is possible may assign an explicit expiration time in the
past. This means that the resource entity may be modified twice during a single second.

Entity tags are normally "strong validators," but response is always stale, and so the protocol provides cache
SHOULD validate it before using it for subsequent requests. See section
14.9.4 for a mechanism more restrictive way to tag force revalidation.

If an entity tag as "weak."

A "use" of a validator origin server wishes to force any HTTP/1.1 cache, no matter how
it is configured, to validate every request, it should use the "must-
revalidate" Cache-Control directive (see section 14.9).

Servers specify explicit expiration times using either when the Expires
header, or the max-age directive of the Cache-Control header.

An expiration time cannot be used to force a client generates user agent to refresh its
display or reload a request resource; its semantics apply only to caching
mechanisms, and
includes the validator in such mechanisms need only check a validating header field, or resource's expiration
status when a server
compares two validators.

Strong validators are usable in any context. Weak validators are only
usable in contexts new request for that do not depend on exact equality of an entity.
For example, either kind resource is usable initiated. See section
13.11 for a conditional GET explanation of a full
entity. However, only a strong validator is usable for a sub-range
retrieval, since otherwise the client may end up with an internally
inconsistent entity body.

The only function difference between caches and history
mechanisms.

13.2.2 Heuristic Expiration

Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
algorithms that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison functions, depending on
whether the comparison context allows the use of weak validators or
not:

. The strong comparison function: in order other header values (such as the Last-Modified time)
to be considered equal,
both validators must be identical in every way, and neither may be
weak.
. estimate a plausible expiration time. The weak comparison function: in order to be considered equal, both
validators must be identical in every way, HTTP/1.1 specification does
not provide specific algorithms, but either or both of
them does impose worst-case constraints
on their results. Since heuristic expiration times may be tagged as "weak" without affecting the result.
The weak comparison function SHOULD be used for simple (non-subrange)
GET requests. The strong comparison function MUST compromise
semantic transparency, they should be used in all other
cases.

An entity tag is strong unless it is explicitly tagged cautiously, and we encourage
origin servers to provide explicit expiration times as weak. Section
16.3 gives the syntax for entity tags.

A Last-Modified time, when used much as a validator in a request, is
implicitly weak unless it is possible possible.

13.2.3 Age Calculations

In order to deduce that it know if a cached entry is strong, using fresh, a cache needs to know if
its age exceeds its freshness lifetime. We discuss how to calculate the following rules:

. The validator is being compared by an origin server
latter in section 13.2.4; this section describes how to calculate the actual
age of a response or cache entry.

In this discussion, we use the term "now" to mean "the current validator for value of
the entity and, clock at the host performing the calculation." All HTTP
implementations, but especially origin servers and caches, should use

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

. That origin server reliably knows

NTP [28] or some similar protocol to synchronize their clocks to a
globally accurate time standard.

Also note that HTTP/1.1 requires origin servers to send a Date header
with every response, giving the associated entity did
not change twice during time at which the second covered by response was
generated. We use the presented
validator. or

. The validator is about term "date_value" to be used by a client in an If-Modified-
Since or If-Unmodified-Since header, because denote the client has value of the Date
header, in a cache
entry form appropriate for arithmetic operations.

HTTP/1.1 uses the associated entity, and
. That cache entry includes a Date value, which gives Age response-header to help convey age information
between caches. The Age header value is the sender's estimate of the
amount of time when since the origin server response was generated at the original response, and
. The presented Last-Modified time origin server. In
the case of a cached response that has been revalidated with the origin
server, the Age value is at least 60 seconds before based on the
Date value. or

. The validator time of revalidation, not of the
original response.

In essence, the Age value is being compared by an intermediate cache to the
validator stored sum of the time that the response has
been resident in its cache entry for each of the entity, and
. That cache entry includes a Date value, which gives caches along the time when path from the origin server generated
server, plus the original response, and
. The presented Last-Modified amount of time is at least 60 seconds before it has been in transit along network
paths.

We use the
Date value.
This method relies on term "age_value" to denote the fact that if value of the Age header, in a
form appropriate for arithmetic operations.

A response's age can be calculated in two different responses were
generated by entirely independent ways:

1. now minus date_value, if the local clock is reasonably well
synchronized to the origin server during server's clock. If the same second, but both had result is
negative, the
same Last-Modified time, then at least one result is replaced by zero.
2. age_value, if all of those responses would the caches along the response path implement
HTTP/1.1.
Given that we have
a Date value equal two independent ways to its Last-Modified time. The arbitrary 60-second
limit guards against compute the age of a response
when it is received, we can combine these as

corrected_received_age = max(now - date_value, age_value)

and as long as we have either nearly synchronized clocks or all-HTTP/1.1
paths, one gets a reliable (conservative) result.

Note that this correction is applied at each HTTP/1.1 cache along the possibility
path, so that if there is an HTTP/1.0 cache in the Date and Last-Modified
values are generated from different clocks, or at somewhat different
times during path, the preparation of correct
received age is computed as long as the response. An implementation may use
a value larger than 60 seconds, if it receiving cache's clock is believed that 60 seconds
nearly in sync. We don't need end-to-end clock synchronization (although
it is too
short.

If a client wishes good to perform a sub-range retrieval on a value for which
it has only a Last-Modified time have), and there is no opaque validator, it explicit clock synchronization
step.

Because of network-imposed delays, some significant interval may do this
only if pass
from the Last-Modified time is strong in the 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
servers.

16.3.4 Rules for When to Use Entity Tags and Last-modified Dates
We adopt a set of rules and recommendations for origin servers,
clients,
and caches regarding when various validator types should be used, server generates a response and
for 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 time it is
unfeasible to send a strong entity tag.
. MAY send a weak entity tag instead of a strong one.
received at the next outbound cache or client. If uncorrected, this
delay could result in improperly low ages.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

. MAY send no entity tag if it is not feasible to generate one.
. SHOULD send a Last-Modified value if it is feasible to send one,
unless

Because the risk of a breakdown in semantic transparency request that could
result from using this date resulted in an If-Modified-Since header would
lead to serious problems.
In other words, the preferred behavior for an HTTP/1.1 origin server is
to send both a strong entity tag and a Last-Modified value.

In order returned Age value must have
been initiated prior to be legal, a strong entity tag MUST change whenever that Age value's generation, we can correct for
delays imposed by the
associated entity value changes in any way. A weak entity tag SHOULD
change whenever network by recording the associated entity changes in a semantically
significant way.

Note: in order to provide semantically transparent caching, time at which the request
was initiated. Then, when an
origin server should avoid reusing a specific strong entity tag
value for two different resource entities, or reusing a specific
weak entity tag Age value for two semantically different instances of a
resource entity. Cache entries may persist for arbitrarily long
periods, regardless of expiration times, so is received, it may MUST be inappropriate
interpreted relative to the time the request was initiated, not the time
that the response was received. This algorithm results in conservative
behavior no matter how much delay is experienced. So, we compute:

corrected_initial_age = corrected_received_age
+ (now - request_time)

where "request_time" is the time (according to expect the local clock) when the
request that elicited this response was sent.

Summary of age calculation algorithm, when a cache will never again attempt to validate an
entry using receives a validator that it obtained at some point in the past.

HTTP/1.1 clients:

. If an entity tag has been provided by response:

/*
* age_value
* is the origin server, MUST use
that entity tag in any cache-conditional request (using If-Match or
If-NoneMatch).
. If only a Last-Modified value has been provided of Age: header received by the origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
. If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that cache with
* this response.
* date_value
* is the value in subrange cache-conditional
requests (using If-Unmodified-Since:). The user agent should
provide a way to disable this, in case of difficulty.
. If both an entity tag and a Last-Modified value have been provided
by the origin server, SHOULD 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 request, MUST use server's Date: header
* request_time
* is the most
restrictive validator (local) time when deciding whether the client's cache entry
matches made the cache's own cache entry. This request
* that resulted in this cached response
* response_time
* is only an issue the (local) time when the
request contains both an entity tag and a last-modified-date validator
(If-Modified-Since or If-Unmodified-Since).

A note on rationale: The general principle behind these rules cache received the
* response
* now
* is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

When a cache sends a response, it must add to the corrected_initial_age
the amount of time that HTTP/1.1 servers and clients should the response was resident locally. It must then
transmit as much non-
redundant information as this total age, using the Age header, to the next recipient
cache.

Note that a client cannot reliably tell that a response is available first-
hand, but the presence of an Age header indicates that a response
is definitely not first-hand. Also, if the Date in their responses and
requests. HTTP/1.1 systems receiving this information will make a response is
earlier than the
most conservative assumptions about client's local request time, 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 response is
probably not first-hand (in the absence of serious clock skew).

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in

13.2.4 Expiration Calculations

In order to decide whether a serious problem, then HTTP/1.1 origin servers
should not provide one.

16.3.5 Non-validating Conditionals response is fresh or stale, we need to
compare its freshness lifetime to its age. The principle behind entity tags age is that only calculated as
described in section 13.2.3; this section describes how to calculate the
freshness lifetime, and to determine if a response has expired. In the service author knows
discussion below, the semantics values can be represented in any form appropriate
for arithmetic operations.

We use the term "expires_value" to denote the value of a resource well enough the Expires
header. We use the term "max_age_value" to select denote an appropriate cache
validation mechanism, and the specification of any validator comparison
function more complex than byte-equality would open up a can value
of worms.
Thus, comparisons the number of any other headers (except Last-Modified, for
compatibility with HTTP/1.0) are never used for purposes seconds carried by the max-age directive of validating the Cache-
Control header in a
cache entry.

16.4 Constructing Responses From Caches response (see section 14.10.

The purpose of an HTTP cache max-age directive takes priority over Expires, so if max-age is to store information received in
response to requests, for use
present in responding to future requests. In many
cases, a cache simply returns response, the appropriate parts calculation is simply:

freshness_lifetime = max_age_value

Otherwise, if Expires is present in the response, the calculation is:

freshness_lifetime = expires_value - date_value

Note that neither of a response these calculations is vulnerable to clock skew,
since all of the
requester. However, if information comes from the origin server.

If neither Expires nor Cache-Control: max-age appears in the response,
and the response does not include other restrictions on caching, the
cache holds MAY compute a cache entry based on freshness lifetime using a previous
response, it may have heuristic. If the value
is greater than 24 hours, the cache must attach Warning 13 to combine parts of a new any
response with what whose age is
held in more than 24 hours if such warning has not already
been added.

Also, if the cache entry.

16.4.1 End-to-end and Hop-by-hop Headers
For response does have a Last-Modified time, the purpose heuristic
expiration value SHOULD be no more than some fraction of defining the behavior interval
since that time. A typical setting of caches and non-caching
proxies, we divide HTTP headers into two categories:

. End-to-end headers, which must this fraction might be transmitted 10%.

The calculation to the ultimate
recipient of a request or response. End-to-end headers in responses
must be stored as part of determine if a cache entry and transmitted in any response formed from a cache entry.
. Hop-by-hop headers, which has expired is quite simple:

response_is_fresh = (freshness_lifetime > current_age)

13.2.5 Disambiguating Expiration Values

Because expiration values are meaningful only assigned optimistically, it is possible
for a single
transport-level connection, and are not stored by two 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/1.1 to contain fresh values for the same resource that are end-to-end headers.

Hop-by-hop headers introduced in future versions of HTTP MUST be listed
in
different.

If a Connection header, as described client performing a retrieval receives a non-first-hand response
for a request that was already fresh in section 18.11.

16.4.2 Non-modifiable Headers
Some features of the HTTP/1.1 protocol, such as Digest Authentication,
depend on the value of certain end-to-end headers. A cache or non-
caching proxy SHOULD NOT modify an end-to-end header unless its own cache, and the
definition of that Date
header requires or specifically allows that. in its existing cache entry is newer than the Date on the new

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

response, then the client MAY ignore the response. If so, it MAY retry
the request with a "Cache-Control: max-age=0" directive (see section
14.9), to force a check with the origin server.

If a cache or non-caching proxy has two fresh responses for the same representation with
different validators, it MUST NOT modify any of use the following fields
in one with the more recent Date
header. This situation may arise because the cache is pooling responses
from other caches, or because a request client has asked for a reload or response, nor a
revalidation of an apparently fresh cache entry.

13.2.6 Disambiguating Multiple Responses

Because a client may it add any be receiving responses via multiple paths, so that
some responses flow through one set of these fields if not
already present:

. Content-Type
. Content-Encoding
. Content-Length
. Expires
. Last-Modified
. Content-Range
. Content-Location
Warning: unnecessary modification caches and other responses flow
through a different set of end-to-end headers caches, a client may cause
authentication failures receive responses in an
order different from that in which the origin server sent them. We would
like the client to use the most recently generated response, even if stronger authentication mechanisms
older responses are
introduced in still apparently fresh.

Neither the entity tag nor the expiration value can impose an ordering
on responses, since it is possible that a later versions response intentionally
carries an earlier expiration time. However, the HTTP/1.1 specification
requires the transmission of HTTP. Such authentication
mechanisms may rely Date headers on every response, and the
Date values are ordered to a granularity of header fields not listed here.

16.4.3 Combining Headers one second.

When a cache makes a validating request client tries to revalidate a server, cache entry, and the server
provides a 304 Not Modified response, the cache must construct a response it
receives contains a Date header that appears to send to be older than the requesting client. The cache uses one
for the entity-
body stored in existing entry, then the cache entry as client SHOULD repeat the entity-body of this outgoing
response. It uses request
unconditionally, and include

Cache-Control: max-age=0

to force any intermediate caches to validate their copies directly with
the end-to-end headers origin server, or

Cache-Control: no-cache

to force any intermediate caches to obtain a new copy from the incoming response, not
from origin
server.

If the cache entry. Unless Date values are equal, then the client may use either response
(or may, if it decides is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to remove choose
deterministically between responses generated during the same second, if
their expiration times overlap.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

13.3 Validation Model

When a cache entry, has a stale entry that it
must also replace the end-to-end headers stored would like to use as a response
to a client's request, it first has to check with the origin server (or
possibly an intermediate cache entry with those received in a fresh response) to see if its
cached entry is still usable. We call this "validating" the incoming response.

In other words, cache entry.
Since we do not want to have to pay the complete set overhead of end-to-end headers received in retransmitting the
incoming
full response overrides all end-to-end headers stored with if the cache
entry. The cache may add Warning headers (see section 18.48) cached entry is good, and we do not want to this
set.

A cache MUST preserve pay the order
overhead of all headers as received in an
incoming response.

These rule allows an origin server to completely control extra round trip if the response
seen by cached entry is invalid, the client
HTTP/1.1 protocol supports the use of conditional methods.

The key protocol features for supporting conditional methods are those
concerned with "cache validators." When an origin server generates a cache when
full response, it attaches some sort of validator to it, which is kept
with the cache revalidates an entry, and
may be necessary for preserving semantic transparency or for certain
kinds of security mechanisms entry. When a client (end-user or future extensions.

16.4.4 Combining Byte Ranges
A response may transfer only cache) makes a subrange of the bytes of an entity,
either because the
conditional request included one or more Range specifications, or
because for a connection was broken prematurely. After several such
transfers, resource for which it has a cache may have received several ranges of entry, it
includes the same entity.

If a cache has a stored non-empty set of subranges for an entity, and an
incoming response transfers another subrange, associated validator in the cache MAY combine request.

The server then checks that validator against the
new subrange with current validator for
the existing set entity, and, if both the following conditions are
met:

Fielding, Frystyk, Berners-Lee, Gettys, they match, it responds with a special status code
(usually, 304 (Not Modified)) and Mogul [Page 74]

INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996

. Both no entity-body. Otherwise, it returns
a full response (including entity-body). Thus, we avoid transmitting the incoming
full response if the validator matches, and we avoid an extra round trip
if it does not match.

Note: the cache entry must have a cache
validator.
. The two cache comparison functions used to decide if validators must match using the strong comparison
function (see
are defined in section 16.3.3).
If either requirement is not meant, 13.3.3.

In HTTP/1.1, a conditional request looks exactly the cache must use only same as a normal
request for the most
recent partial response (based on same resource, except that it carries a special header
(which includes the Date values transmitted with every
response, and using validator) that implicitly turns the incoming response method
(usually, GET) into a conditional.

The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is possible to request either that a
method be performed if these values are equal or
missing), and must discard the other partial information.

16.5 Caching only if a validator matches or if and Generic Resources
Generic resources interacts with caching in several ways:

. A generic resource (one subject to content negotiation) only if
no validators match.

Note: a response that lacks a validator may still be
bound to more than one entity. Each of these entities cached, and
served from cache until it expires, unless this is called explicitly
prohibited by a Cache-Control directive. However, a
"variant" of the resource.
. The request-URI may be only one part of the cache key.

16.5.1 Vary Header Use
Origin servers may respond to requests for generic resources use the
Vary header (see section 18.46 for cannot do
a full description) to inform conditional retrieval if it does not have a validator for the
cache
entity, which header fields of the request were means it will not be refreshable after it expires.

13.3.1 Last-modified Dates

The Last-Modified entity-header field value is often used to select the variant
returned in the response. A as a cache can use that response to reply to
validator. In simple terms, a
subsequent request only cache entry is considered to be valid if
the two requests entity has not only specify the same
URI, but also have the same value for all headers specified in been modified since the Vary
response-header. Last-Modified value.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

13.3.2 Entity Tag Cache Validators

The Vary header may also inform the ETag entity-header field value, an entity tag, provides for an
"opaque" cache that validator. This may allow more reliable validation in
situations where it is inconvenient to store modification dates, where
the variant was selected
using criteria one-second resolution of HTTP date values is not limited sufficient, or
where the origin server wishes to avoid certain paradoxes that may arise
from the request headers; use of modification dates.

Entity Tags are described in this case, the
response MUST NOT be section 3.11. The headers used with entity
tags are described in a reply sections 14.20, 14.25, 14.26 and 14.43.

13.3.3 Weak and Strong Validators

Since both origin servers and caches will compare two validators to a subsequent request except
decide if they represent the cache relays the new request to same or different entities, one normally
would expect that if the origin server entity (the entity-body or any entity-headers)
changes in a conditional
request, and any way, then the origin 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 responds with 304 (Not Modified) prefers to change the
validator only on semantically significant changes, and
includes not when
insignificant aspects of the same variant-ID (see 13.8.3).

16.5.2 Alternates Header Use
The Alternates header entity change. A validator that does not
always change when the resource changes is present in a "weak validator."

Entity tags are normally "strong validators," but the HTTP/1.1 protocol provides
a mechanism to enable caching tag an entity tag as "weak." One can think of
entities from the planned content negotiation facilities. If a cache
receives strong
validator as one that changes whenever the bits of an Alternates header in entity changes,
while a response from weak value changes whenever the origin server (and
implement these planned facilities), it should act meaning of an entity changes.
Alternatively, one can think of a strong validator as part of an
identifier for a specific entity, while a weak validator is part of an
identifier for a set of semantically equivalent entities.

Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed.

An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that
the response
carried resource may be modified twice during a "Vary:{accept-headers}" header. This means single second.

Support for weak validators is optional; however, weak validators
allow for more efficient caching of equivalent objects; for
example, a hit counter on a site is probably good enough if it is
updated every few days or weeks, and any value during that the response
may be returned in reply period
is likely "good enough" to be equivalent.

A "use" of a subsequent request with Accept-* headers
identical to those in the current request.

16.5.3 Variant-ID Use
If an origin server chooses to use the variant-ID mechanism, it assigns validator is either when a variant-ID (see section 7.12) to each distinct resource entity
(variant). This assignment can only be made by the origin server. It
then returns the appropriate variant-ID with each response that applies
to client generates a specific resource entity (variant), using request and
includes the ETag validator in a validating header (see
Error! Reference source not found.). field, or when a server
compares two validators.

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75] 76]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

When sending an entity derived from a particular variant

Strong validators are usable in a response,
an origin server SHOULD include a variant-ID identifying the variant any context. Weak validators are only
usable in
the ETag header (see section Error! Reference source contexts that do not found.). This
variant-ID can be used for cache replacement and in conditional requests depend on the generic resource. When exact equality of an entity.
For example, either kind is usable for a cache receives conditional GET of a successful response
with full
entity. However, only a variant-ID, it SHOULD use this information to replace any
existing cache entries strong validator is usable for the same variant of the corresponding URI.
That is, it forms a cache key using the URI of sub-range
retrieval, since otherwise the request and client may end up with an internally
inconsistent entity.

The only function that the
variant-ID of HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison functions, depending on
whether the response. If this key matches comparison context allows the key use of an existing
cache entry, it SHOULD replace the existing entry with the new response
(subject weak validators or not:

. The strong comparison function: in order to all be considered equal,
both validators must be identical in every way, and neither may be
weak.
. The weak comparison function: in order to be considered equal, both
validators must be identical in every way, but either or both of
them may be tagged as "weak" without affecting the result.
The weak comparison function MAY be used for simple (non-subrange) GET
requests. The strong comparison function MUST be used in all other rules on caching). See section Error!
Reference source not found.
cases.

An entity tag is strong unless it is explicitly tagged as weak. Section
14.20 gives the syntax for more details on update.

When a cache performs entity tags.

A Last-Modified time, when used as a conditional request on validator in a generic resource, and request, is
implicitly weak unless it has one or more cache entries for the resource is possible to deduce that include variant-
IDs, it is strong, using
the cache MUST transmit following rules:

. The validator is being compared by an origin server to the (cache-validator, variant-ID) tuples in actual
current validator for the conditional request, using entity and,
. That origin server reliably knows that the variant-set mechanism (see section
7.13). This tells associated entity did
not change twice during the server which variants are currently in second covered by the
requester's cache. presented
validator.
or

. The client MAY choose to transmit only a subset of the (cache-
validator, variant-ID) tuples corresponding validator is about to its cache entries
for this resource.

When be used by a server receives client in an If-Modified-
Since or If-Unmodified-Since header, because the client has a conditional request that cache
entry for the associated entity, and
. That cache entry includes a variant-
set, and Date value, which gives the time when
the origin server sent the original response, and
. The presented Last-Modified time is able to reply with an appropriate variant
(either
because it is at least 60 seconds before the origin server,
Date value.
or because it

. The validator is being compared by an intermediate cache
that can properly implement to the variant selection algorithm), once it
has selected
validator stored in its cache entry for the variant it should examine entity, and
. That cache entry includes a Date value, which gives the elements of time when
the supplied
variant-set. If one of these matches origin server sent the variant-ID of original response, and
. The presented Last-Modified time is at least 60 seconds before the selected
variant,
Date value.

Fielding, Frystyk, Berners-Lee, Gettys, and if Mogul [Page 77]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

This method relies on the cache validators match, fact that if two different responses were sent
by the origin server SHOULD reply with
a 304 (Not Modified) response, including during the same second, but both had the variant-ID 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 selected
variant. Otherwise, possibility that the server should reply as if Date and Last-Modified values
are generated from different clocks, or at somewhat different times
during the request were
unconditional.

The server preparation of the response. An implementation may optionally use the variant-set information in its
selection algorithm. For example, a
value larger than 60 seconds, if the selection algorithm yields
several variants with equal preference, it is believed that 60 seconds is too
short.

If a client wishes to perform a sub-range retrieval on a value for which
it has only a Last-Modified time and one of these no opaque validator, it may do this
only if the Last-Modified time is already strong in the requester's cache, the sense described here.

A cache or origin server could select that variant and avoid an
extra data transfer. This is receiving a performance optimization; otherwise, cache-conditional request, other
than a full-body GET request, MUST use the
variant-selection mechanism is orthogonal strong comparison function to
evaluate the variant-ID mechanism.

16.6 Shared condition.

These rules allow HTTP/1.1 caches and Non-Shared Caches
For reasons clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0
servers.

13.3.4 Rules for When to Use Entity Tags and Last-modified Dates

We adopt a set of security rules and privacy, recommendations for origin servers, clients,
and caches regarding when various validator types should be used, and
for what purposes.

HTTP/1.1 origin servers:

. SHOULD send a entity tag validator unless it is necessary not feasible to make
generate one.
. MAY send a
distinction between "shared" and "non-shared" caches. A non-shared cache weak entity tag instead of a strong entity tag, if
performance considerations support the use of weak entity tags, or
if it is one unfeasible to send a strong entity tag .
. SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would
lead to serious problems.
In other words, the preferred behavior for an HTTP/1.1 origin server is accessible only
to send both a single user. Accessibility in this
case SHOULD be enforced by appropriate security mechanisms. All other
caches are considered strong entity tag and a Last-Modified value.

In order to be "shared." Other sections of this
specification place certain constraints on legal, a strong entity tag MUST change whenever the operation of shared
caches
associated entity value changes in any way. A weak entity tag SHOULD
change whenever the associated entity changes in a semantically
significant way.

Note: in order to prevent loss of privacy provide semantically transparent caching, an
origin server must avoid reusing a specific strong entity tag value
for two different entities, or failure of access controls reusing a specific weak entity tag

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76] 78]

INTERNET-DRAFT HTTP/1.1 Friday, May Monday, June 03, 1996

16.7 Selecting a Cached Response
When

value for two semantically different entities. Cache entries may
persist for arbitrarily long periods, regardless of expiration
times, so it may be inappropriate to expect that a cache receives a request it tries will never
again attempt to see if it has validate an entry using a cached
response appropriate for validator that request, using it
obtained at some point in the matching rules past.

HTTP/1.1 clients:

. If an entity tag has been provided by the origin server, MUST use
that entity tag in this
section. any cache-conditional request (using If-Match or
If-None-Match).
. If such only a response exists, then Last-Modified value has been provided by the cache can decide if it is
fresh enough origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using the expiration model If-Modified-Since).
. If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that value in section 16.1.2 and the
freshness requirements of client and origin-server expressed subrange cache-conditional
requests (using If-Unmodified-Since:). The user agent should
provide a way to disable this, in the
Cache-Control headers case of the request difficulty.
. If both an entity tag and cached response) to return a Last-Modified value have been provided
by the origin server, SHOULD use both validators in
reply cache-
conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches
to the request.
If on respond appropriately.
An HTTP/1.1 cache, upon receiving a cache lookup there are two or more fresh entries that appear to
match the request, then the one with the most recent Date value MUST be
used.
16.7.1 Plain Resources
If the cached response was for a plain resource (that is, the response
includes no Vary or Alternates headers), it matches if use the Request-URI
of most
restrictive validator when deciding whether the request client's cache entry
matches the Request-URI of the of cache's own cache entry. This is only an issue when the
request contains both an entity tag and a last-modified-date validator
(If-Modified-Since or If-Unmodified-Since).

A note on rationale: The general principle behind these rules is
that caused
the cached response to be stored. Request-URIs match if HTTP/1.1 servers and clients should transmit as much non-
redundant information as is available in their canonical
forms (see section 7.2.3) are equal.

16.7.2 Generic Resources
If responses and
requests. HTTP/1.1 systems receiving this information will make the cached response was for a generic resource (that is,
most conservative assumptions about the response
includes Vary, validators they receive.

HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or Alternates headers), it matches if 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 Request-URI
use of a 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.

13.3.5 Non-validating Conditionals

The principle behind entity tags is that only the request matches service author knows
the Request-URI semantics of the request that caused the
cached response a resource well enough to be stored, select an appropriate cache
validation mechanism, and the selecting request header field
values specification of the request match those any validator comparison
function more complex than byte-equality would open up a can of the request that caused the cached
response to be stored. (See section 18.46 on Vary, which defines the
canonical form for selecting request worms.
Thus, comparisons of any other headers and the matching rules for
them.)
If the response contains "Vary: {other}", then the selecting request
header field values (except Last-Modified, for its request

Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79]

INTERNET-DRAFT HTTP/1.1 Monday, June 03, 1996

compatibility with HTTP/1.0) are defined as never matching a set used for purposes of request headers.

16.8 Errors or Incomplete Response Cache Behavior
A validating a
cache that receives entry.

13.4 Constructing Responses From Caches

The purpose of an incomplete HTTP cache is to store information received in
response (for example, with fewer
bytes of data than specified to requests, for use in responding to future requests. In many
cases, a Content-length: header) may store the
response. However, the cache MUST treat this as a partial response.
Partial responses may be combined as described in section 16.4.4; simply returns the
result might be a full response or might still be partial. A cache MUST
NOT return appropriate parts of a partial response to a client without explicitly marking it
as such, using the 206 (Partial Content) status code. A
requester. However, if the cache MUST NOT
return holds a partial response using cache entry based on a status code previous
response, it may have to combine parts of 200 (OK).

A cache that receives a new response with a zero-length Entity-body what is
held in the cache entry.

13.4.1