WDIFF

draft-ietf-http-v11-spec-01.txt --> draft-ietf-http-v11-spec-02.txt

HTTP Working Group R. Fielding, UC Irvine
INTERNET-DRAFT H. Frystyk, MIT/LCS
<draft-ietf-http-v11-spec-01.txt>
<draft-ietf-http-v11-spec-02.txt> T. Berners-Lee, MIT/LCS
J. Gettys, DEC
Jeffrey C. Mogul, DEC
Expires in six months January 19, September 23, 1996 April 23, 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 obsoleted made obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work _work in
progress". progress_.

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt"
_1id-abstracts.txt_ listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited. Please send comments to the
HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the
working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about
HTTP and the applications which use HTTP should take place on the <www-talk@w3.org> <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 logic bags, -
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). A feature of HTTP
is the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

HTTP has been in use by the World-Wide Web global information initiative
since 1990. This specification defines the protocol referred to as "HTTP/1.1".
_HTTP/1.1_.

Note to Readers of This Document
This document is still organized to minimize changes from the previous
draft, to ease reviewers work in finding new material (and because the
editor has not had time to reorganize it).. However, the current
organization is now quite poor for new readers of this document. We
recommend that new readers of this document not read it in the current
order of presentation, but may want to skip ahead after reading sections
1-9 and read sections 11, 12 13 and 14 before reading section 10 which
defines the header field definitions. Section 10 itself is now also not
in alphabetical order, again, to avoid renumbering sections to be able
to easily compare between drafts.

If you are reading the version of this document showing revision markup,
note that we've tried to preserve significant changes from the previous
version, though a few changes may have slipped through unmarked. We make
no guarantees that all changes have revision marks, though we've tried
to preserve them as an aid to those who wish to check a specific change
has been reflected in this draft.

Note that some sections are still marked as SLUSHY and a few are marked
FLUID; these are still undergoing drafting.

Note that text in bold in the text are as yet incompletely resolved
issues. Opinions are solicited_

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

Table of Contents

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

Status of this Memo....................................................1

Abstract...............................................................1

Note to Readers of This Document.......................................2

Table of Contents......................................................3

1. Introduction Introduction........................................................9
1.1 Purpose ..........................................................9
1.2 Requirements .....................................................9
1.3 Terminology .....................................................10
1.4 Overall Operation ...............................................12
1.4 HTTP and MIME ...................................................14

2. Notational Conventions and Generic Grammar Grammar.........................14
2.1 Augmented BNF ...................................................14
2.2 Basic Rules .....................................................16

3. Protocol Parameters Parameters................................................18
3.1 HTTP Version ....................................................18
3.2 Uniform Resource Identifiers ....................................19
3.2.1 General Syntax ...............................................19
3.2.2 http URL .....................................................21
3.3 Date/Time Formats ...............................................22
3.3.1 Full Date ....................................................22
3.3.2 Delta Seconds ................................................24
3.4 Character Sets ..................................................24
3.5 Content Codings .................................................25
3.6 Transfer Codings ................................................26
3.7 Media Types .....................................................27
3.7.1 Canonicalization and Text Defaults ...........................28
3.7.2 Multipart Types ..............................................29
3.8 Product Tokens ..................................................29
3.9 Quality Values ..................................................30
3.10 Language Tags
3.11 Logic Bags ..................................................30
3.12 Full Date Values ...............................................31
3.13 Opaque Validators ..............................................31
3.14 Variant IDs ....................................................32
3.15 Validator Sets .................................................32
3.16 Variant Sets ...................................................32
3.17 HTTP Protocol Parameters Related to Ranges .....................32
3.17.1SLUSHY Range Units ...........................................32
3.17.2 SLUSHY Byte Ranges ..........................................33
3.17.3 SLUSHY: Content Ranges ......................................34

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

4. HTTP Message Message.......................................................35
4.1 Message Types ...................................................35
4.2 Message Headers .................................................36
4.3 General Header Fields ...........................................37

5. Request Request............................................................38
5.1 Request-Line ....................................................38
5.1.1 Method .......................................................38
5.1.2 Request-URI ..................................................39
5.2 Request Header Fields ...........................................41

6. Response Response...........................................................42
6.1 Status-Line .....................................................43
6.1.1 Status Code and Reason Phrase ................................43
6.2 Response Header Fields ..........................................46

7. Entity Entity.............................................................46
7.1 Entity Header Fields ............................................46
7.2 Entity Body .....................................................47
7.2.1 Type .........................................................48
7.2.2 Length .......................................................48

8. Method Definitions Definitions.................................................49
8.1 OPTIONS .........................................................49
8.2 GET .............................................................50
8.3 HEAD ............................................................50
8.4 POST ............................................................51
8.4.1 SLUSHY: Entity Transmission Requirements .....................52
8.5 PUT
8.6 PATCH
8.7 COPY
8.8 MOVE .............................................................53
8.9 DELETE
8.10 LINK
8.11 UNLINK ..........................................................54
8.12 TRACE
8.13 WRAPPED ..........................................................54

9. Status Code Definitions Definitions............................................55
9.1 Informational 1xx ...............................................55
9.2 Successful 2xx ..................................................56
9.3 Redirection 3xx .................................................58
9.4 Client Error 4xx ................................................60
9.5 Server Error 5xx ................................................63

10. Header Field Definitions Definitions..........................................65
10.1 Accept .........................................................65
10.2 Accept-Charset .................................................67
10.3 Accept-Encoding ................................................67
10.4 Accept-Language ................................................68
10.5 Allow ..........................................................69
10.6 Authorization ..................................................70
10.7 Base
10.8 Cache-Control
10.9 ..................................................70
Check: is this true? ...............................................72
10.7.1 SLUSHY: Restrictions on What is Cachable ....................72
10.7.2 Restrictions On What May be Stored by a Cache ...............73
10.7.3 Modifications of the Basic Expiration Mechanism .............73
10.7.4 SLUSHY: Controls over cache revalidation and reload .........74
10.7.5 FLUID: Restrictions on use count and demographic reporting ..76
10.7.6 Miscellaneous restrictions ..................................77

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

10.8 Connection
10.9.1 Persistent Connections .....................................................77
10.8.1 Persist ......................................................78
10.9 Content-Base ...................................................78
10.10 Content-Encoding ..............................................78
10.11 Content-Language ..............................................79
10.12 Content-Length ................................................80
10.13 Content-MD5 ...................................................80
10.14 SLUSHY Content-Range ..........................................82
10.14.1 MIME multipart/byteranges content-type .....................82
10.14.2 Additional rules for Content-Range .........................83
10.15 Content-Type ..................................................83
10.16 Content-Version Content-Location ..............................................84
10.17 Date
10.18 Derived-From ..........................................................84
10.19 SLUSHY Expires ................................................85
10.20 Forwarded Via ...........................................................86
10.21 From ..........................................................88
10.22 Host ..........................................................88
10.23 If-Modified-Since
10.24 Keep-Alive .............................................89
10.25 Last-Modified
10.26 Link .................................................90
10.27 Location
10.28 MIME-Version ......................................................91
10.29 Pragma ........................................................91
10.30 Proxy-Authenticate ............................................92
10.31 Proxy-Authorization ...........................................92
10.32 Public ........................................................93
10.33 Range .........................................................93
10.34 Referer
10.35 Refresh .......................................................94
10.36 Retry-After ...................................................95
10.37 Server ........................................................95
10.38 Title .........................................................95
10.39 Transfer Encoding
10.40 Unless .............................................96
10.41 Upgrade
10.42 URI .......................................................96
10.43 User-Agent ....................................................97
10.44 WWW-Authenticate ..............................................98
10.45 Max-Forwards ..................................................98
10.46 Age ...........................................................99
10.47 CVal ..........................................................99
10.48 If-Invalid ....................................................99
10.49 If-Valid .....................................................100
10.50 If-Unmodified-Since ..........................................101
10.51 Warning ......................................................102
10.52 Vary .........................................................103
10.53 Alternates ...................................................106
10.54 SLUSHY: Accept-Ranges ........................................107
10.55 SLUSHY: Range-If .............................................107

11. Access Authentication Authentication............................................108
11.1 Basic Authentication Scheme ...................................109
11.2 Digest Authentication Scheme ..................................110

12. Content Negotiation Negotiation..............................................111
12.1 Preemptive Negotiation

13. facilities defined in this specification .........111

13 Caching

14. Security in HTTP...................................................112
13.1 Semantic Transparency .........................................112

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

13.2 Expiration Model ..............................................113
13.2.1 Server-Specified Expiration ................................113
13.2.2 Limitations on the Effect of Expiration Times ..............114
13.2.3 Heuristic Expiration .......................................114
13.2.4 Client-controlled Behavior .................................114
13.2.5 Exceptions to the Rules and Warnings .......................115
13.2.6 Age Calculations ...........................................115
13.2.7 Expiration Calculations ....................................117
13.2.8 UT Mandatory ................................................118
13.3 Validation Model ..............................................118
13.3.1 Last-modified Dates ........................................119
13.3.2 Opaque Validators ..........................................119
13.3.3 Weak and Strong Validators .................................120
13.3.4 Rules for When to Use Opaque Validators and Last-modified
Dates .............................................................122
13.3.5 SLUSHY: Non-validating conditionals ........................123
13.3.6 FLUID: Other Issues ........................................123
13.4 Cache-control Mechanisms ......................................123
13.5 Warnings ......................................................124
13.6 Explicit Indications Regarding User-specified Overrides .......124
13.7 Constructing Responses From Caches ............................125
13.7.1 End-to-end and Hop-by-hop Headers ..........................125
13.7.2 Non-modifiable Headers .....................................126
13.7.3 Combining Headers ..........................................126
13.7.4 Combining Byte Ranges ......................................126
13.7.5 SLUSHY: Scope of Expiration ................................127
13.8 Caching and Content Negotiation ...............................127
13.8.1 Use of the Vary header .....................................127
13.8.2 SLUSHY: Use of the Alternates header .......................128
13.8.3 Use of Variant-IDs .........................................128
13.8.4 Use of Selecting Opaque Validators .........................129
13.10 Shared and Non-Shared Caches .................................130
13.11 SLUSHY: Miscellaneous Considerations .........................130
13.11.1 Detecting Firsthand Responses .............................130
13.11.2 Disambiguating Expiration values ..........................130
13.11.3 Disambiguating Multiple Responses .........................131
13.12 SLUSHY: Cache Keys ...........................................131
13.12.1 Non-varying Resources .....................................132
13.12.2 SLUSHY: Varying Resources .................................132
13.12.3 SLUSHY: Key-Matching Procedure ............................133
13.12.4 Canonicalization of URIs ..................................134
13.13 FLUID: Cache-Related Problems Not Addressed in HTTP/1.1 ......134
13.14 Cache Operation When Receiving Errors or Incomplete Responses 134
13.14.1 Caching and Status Codes ..................................135
13.14.2 Handling of Retry-After ...................................135
13.15 FLUID: Compatibility With Earlier Versions of HTTP ...........135
13.16 SLUSHY: Side Effects of GET and HEAD .........................135
13.17 SLUSHY: Invalidation After Updates or Deletions ..............136
13.18 Write-Through Mandatory ......................................136
13.19 Interoperability of Varying Resources with HTTP/1.0 Proxy
Caches .............................................................136
13.20 Cache Replacement for Varying Resources ......................137
13.22 FLUID: Network Partitions ....................................138
13.23 FLUID: Caching of Negative Responses .........................138

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

13.24 History Lists ................................................138

14 Persistent Connections............................................138
14.1 Purpose .......................................................138
14.2 Overall Operation .............................................139
14.2.3 Negotiation ................................................139
14.2.4 Pipe-lining ................................................139
14.2.5 Delimiting Entity-Bodies ...................................139
14.3 Proxy Servers .................................................140
14.4 Interaction with Security Protocols ...........................140
14.5 Practical Considerations ......................................140

15. Security Considerations..........................................141
15.1 Authentication of Clients
14.2 .....................................141
15.2 Safe Methods
14.3 ..................................................142
15.3 Abuse of Server Log Information
14.4 ...............................143
15.4 Transfer of Sensitive Information

15. Acknowledgments .............................143
15.5 Attacks Based On File and Path Names ..........................143
15.6 Personal Information ..........................................144
15.7 Privacy issues connected to Accept headers ....................144
15.8 DNS Spoofing ..................................................145
15.9 SLUSHY: Location Headers and Spoofing .........................145

16. References Acknowledgments..................................................145

17. References.......................................................147

18. Authors' Addresses

Appendix Addresses...............................................150

Appendices...........................................................151

A. Internet Media Type message/http
Appendix message/http..................................151

B. Tolerant Applications
Appendix Applications.............................................152

C. Relationship to MIME Differences Between HTTP Bodies and RFC 1521 Internet Message Bodies
.....................................................................152
C.1 Conversion to Canonical Form
C.1.1 Representation of Line Breaks
C.1.2 Default Character Set ...................................153
C.2 Conversion of Date Formats .....................................153
C.3 Introduction of Content-Encoding ...............................153
C.4 No Content-Transfer-Encoding ...................................154
C.5 HTTP Header Fields in Multipart Body-Parts .....................154
C.6 Introduction of Transfer-Encoding
Appendix ..............................154
C.7 MIME-Version ...................................................155

D. Changes from HTTP/1.0.............................................155
D.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses ..........................................................155

E. Additional Features...............................................156
E.1 Additional Request Methods .....................................156
E.1.1 PATCH .......................................................156
E.1.2 LINK ........................................................157
E.1.3 UNLINK ......................................................157

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

E.2 Additional Header Field Definitions ............................157
E.2.1 Content-Version .............................................157
E.2.2 Derived-From ................................................158
E.2.3 Link ........................................................158
E.2.4 URI .........................................................159
E.2.5 Compatibility with HTTP/1.0

1. Introduction

1.1 Purpose

The Hypertext Transfer Protocol (HTTP) is an application-level
protocol Persistent Connections ..........160
F.1 Compatibility with Previous Versions ...........................160
G. Proxy Cache Implementation Guidelines ...........................161
G.1 Support for distributed, collaborative, Content Negotiation by Proxy Caches ................161
G.2 Propagation of Changes in Opaque Selection ....................163
G.3 SLUSHY: State ..................................................163
G.4 FLUID: Cache Replacement Algorithms ............................163
G.5 FLUID: Bypassing in Caching Hierarchies ........................164

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

1. Introduction
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 [6], improved the protocol by allowing messages to be in the
format of MIME-like entities, containing metainformation about the data
transferred and modifiers on the request/response semantics. However,
HTTP/1.0 does not sufficiently take into consideration the effect of
hierarchical proxies and caching, the desire for persistent connections
and virtual hosts, and a number of other details that slipped through
the cracks of existing implementations. In addition, the proliferation
of incompletely-
implemented incompletely-implemented applications calling themselves "HTTP/1.0" _HTTP/1.0_
has necessitated a protocol version change in order for two
communicating applications to determine each other's true capabilities.

This specification defines the protocol referred to as "HTTP/1.1". _HTTP/1.1_. This
protocol is backwards-compatible with HTTP/1.0, but includes more
stringent requirements in order to ensure reliable implementation of its
features.

Practical information systems require more functionality than simple
retrieval, including search, front-end update, and annotation. HTTP
allows an open-ended set of methods to be used to that indicate the purpose of a
request. It builds on the discipline of reference provided by the
Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name
(URN) [20], for indicating the resource on which a method is to be
applied. Messages are passed in a format similar to that used by
Internet Mail [9] and the Multipurpose Internet Mail Extensions (MIME)
[7].

HTTP is also used as a generic protocol for communication between user
agents and proxies/gateways to other Internet protocols, such as SMTP
[16], NNTP [13], FTP [18], Gopher [2], and WAIS [10], allowing basic

hypermedia access to resources available from diverse applications and
simplifying the implementation of user agents.

1.2 Requirements
This specification uses the same words as RFC 1123 [8] for defining the

significance of each particular requirement. These words are:

must

MUST
This word or the adjective "required" _required_ means that the item is an
absolute requirement of the specification.

should

SHOULD
This word or the adjective "recommended" _recommended_ means that there may exist
valid reasons in particular circumstances to ignore this item, but
Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 9]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

the full implications should be understood and the case carefully
weighed before choosing a different course.

may

MAY
This word or the adjective "optional" _optional_ means that this item is truly
optional. One vendor may choose to include the item because a
particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more of
the must MUST requirements for the protocols it implements. An implementation
that satisfies all the must MUST and all the should SHOULD requirements for its
protocols is said to be "unconditionally
compliant"; _unconditionally compliant_; one that satisfies
all the must MUST requirements but not all the should SHOULD requirements for its
protocols is said to be
"conditionally compliant". _conditionally 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
application programs for the purpose of communication.

message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 and

transmitted via the connection.

request
An HTTP request message (as defined in Section 5).

response
An HTTP response message (as defined in Section 6).

resource
A network data object or service which that can be identified by a URI
(Section 3.2).

entity
A particular representation representation, rendition, encoding, or rendition presentation
of a data resource, or
reply from resource. Resources not supporting content negotiation are
bound to a service resource, that single entity. Resources supporting content negotiation

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

are bound to a set of one or more entities, whose membership may be enclosed within
vary over time.

entity instance
The definite value of an entity at a given
point in time. The HTTP protocol transfers
entity instances in request or response message.
messages. An entity consists of instance is transferred as
metainformation in the form of entity headers
and content in the form of an entity body.

client
An application program that establishes connections for the purpose
of sending requests.

user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.

server
An application program that accepts connections in order to service
requests by sending back responses.

origin server
The server on which a given resource resides or is to be created.

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, with possible
translation, on to other servers. A proxy must MUST interpret and, if
necessary, rewrite a request message before forwarding it. Proxies
are often used as client-side portals through network firewalls and
as helper applications for handling requests via protocols not
implemented by the user agent.

gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client may
not be aware that it is communicating with a gateway. Gateways are
often used as server-side portals through network firewalls and as
protocol translators for access to resources stored on non-HTTP
systems.

tunnel
A tunnel is an intermediary program which is acting as a blind
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

relay between two connections. Once active, a tunnel is not
considered a party to the HTTP communication, though the tunnel may
have been initiated by an HTTP request. The tunnel ceases to exist
when both ends of the relayed connections are closed. Tunnels are
used when a portal is necessary and the intermediary cannot, or
should not, interpret the relayed communication.

cache
A program's local store of response messages and the subsystem that
controls its message storage, retrieval, and deletion. A cache
stores cachable responses in order to reduce the response time and
network bandwidth consumption on future, equivalent requests. Any
client or server may MAY include a cache, though a cache cannot be used
by a server while it is acting as a tunnel.
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.

1.4 Overall Operation
The HTTP protocol is based on a request/response paradigm. A client
establishes a connection with a server and
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. 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 body content.

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

request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain

A more complicated situation occurs when one or more intermediaries are
present in the request/response chain. There are three common forms of
intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent,
receiving requests for a URI in its absolute form, rewriting all or
parts of the message, and forwarding the reformatted request toward the
server identified by the URI. A gateway is a receiving agent, acting as
a layer above some other server(s) and, if necessary, translating the
requests to the underlying server's protocol. A tunnel acts as a relay
point between two connections without changing the messages; tunnels are
used when the communication needs to pass through an intermediary (such
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

as a firewall) even when the intermediary cannot understand the contents
of the messages.

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

The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that travels
the whole chain must MUST pass through four separate connections. This
distinction is important because some HTTP communication options may
apply only to the connection with the nearest, non-tunnel neighbor, only
to the end-points of the chain, or to all connections along the chain.
Although the diagram is linear, each participant may be engaged in
multiple, simultaneous communications. For example, B may be receiving
requests from many clients other than A, and/or forwarding requests to
servers other than C, at the same time that it is handling A's request.

Any party to the communication which is not acting as a tunnel may
employ an internal cache for handling requests. The effect of a cache is
that the request/response chain is shortened if one of the participants
along the chain has a cached response applicable to that request. The
following illustrates the resulting chain if B has a cached copy of an
earlier response from O (via C) for a request which has not been cached
by UA or A.

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

Not all responses are cachable, and some requests may contain modifiers
which place special requirements on cache behavior. HTTP requirements
for cache behavior and cachable responses are defined in Section 13.

On the Internet, HTTP communication generally takes place over TCP/IP
connections. The default port is TCP 80 [19], but other ports can be

used. This does not preclude HTTP from being implemented on top of any
other protocol on the Internet, or on other networks. HTTP only presumes
a reliable transport; any protocol that provides such guarantees can be used, and
used; the mapping of the HTTP/1.1 request and response structures onto
the transport data units of the protocol in question is outside the
scope of this specification.

For most implementations, each connection is established by the
client prior to the request and closed by the server after sending
the response.

However, this is not a feature of the protocol and is
not required by this specification. HTTP/1.1 implementations SHOULD implement persistent
connections (See section 14). Both clients and servers must MUST be capable
of handling cases where either party closes the connection prematurely,
due to user action, automated time-out, or program failure. In any case,

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

the closing of the connection by either or both parties always
terminates the current request, regardless of its status.

1.4 HTTP and MIME
HTTP/1.1 uses many of the constructs defined for MIME, as defined in RFC
1521 [7]. Appendix C describes the ways in which the context of HTTP

allows for different use of Internet Media Types than is typically found
in Internet mail, and gives the rationale for those differences.

2. Notational Conventions and Generic Grammar

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]. Implementors Implementers will need to be familiar with the notation in

order to understand this specification. The augmented BNF includes the
following constructs:

name = definition
The name of a rule is simply the name itself (without any enclosing
"<" and ">") and is separated from its definition by the equal
character "=". Whitespace is only significant in that indentation
of continuation lines is used to indicate a rule definition that
spans more than one line. Certain basic rules are in uppercase,
such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are
used within definitions whenever their presence will facilitate
discerning the use of rule names.

"literal"
Quotation marks surround literal text. Unless stated otherwise, the
text is case-insensitive.

rule1 | rule2
Elements separated by a bar ("I") are alternatives, e.g., "yes |
no" will accept yes or no.

(rule1 rule2)
Elements enclosed in parentheses are treated as a single element.
Thus, "(elem _(elem (foo | bar) elem)" elem)_ allows the token sequences "elem _elem
foo elem" elem_ and "elem _elem bar elem". elem_.

*rule
The character "*" _*_ preceding an element indicates repetition. The
full form is "<n>*<m>element" _<n>*<m>element_ indicating at least <n> and at most
<m> occurrences of element. Default values are 0 and infinity so
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

that "*(element)" _*(element)_ allows any number, including zero;
"1*element" _1*element_
requires at least one; and "1*2element" _1*2element_ allows one or two.

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

N rule
Specific repetition: "<n>(element)" _<n>(element)_ is equivalent to
"<n>*<n>(element)";
_<n>*<n>(element)_; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.

#rule
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m>element" 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)"
allows any number, including zero; "1#element" requires at least
one; and
"1#2element" _1#2element_ allows one or two.

; comment
A semi-colon, set off some distance to the right of rule text,
starts a comment that continues to the end of line. This is a
simple way of including useful notes in parallel with the
specifications.

implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear whitespace (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent tokens and delimiters (tspecials), without
changing the interpretation of a field. At least one delimiter
(tspecials) must MUST exist between any two tokens, since they would
otherwise be interpreted as a single token. However, applications should
SHOULD attempt to follow "common
form" _common form_ when generating HTTP
constructs, since there exist some implementations that fail to
accept anything beyond the common forms.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

2.2 Basic Rules
The following rules are used throughout this specification to describe
basic parsing constructs. The US-ASCII coded character set is defined by
[21].

OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>

HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker for
all protocol elements except the Entity-Body (see Appendix B for

tolerant applications). The end-of-line marker within an Entity-Body is
defined by its associated media type, as described in Section 3.7.

CRLF = CR LF

HTTP/1.1 headers can be folded onto multiple lines if the continuation
line begins with a space or horizontal tab. All linear whitespace,
including folding, has the same semantics as SP.

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

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

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

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Recipients of header field TEXT containing octets outside the US-ASCII
character set range may 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 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

Comments can be included in some HTTP header fields by surrounding the
comment text with parentheses. Comments are only allowed in fields
containing "comment" _comment_ as part of their field value definition. In all
other fields, parentheses are considered part of the field value.

comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">

A string of text is parsed as a single word if it is quoted using
double-quote marks.

quoted-string = ( <"> *(qdtext) <"> )

qdtext = <any CHAR except <"> and CTLs,
but including LWS>

The backslash character ("\") (_\_) may be used as a single-character quoting
mechanism only within quoted-string and comment constructs.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

quoted-pair = "\" CHAR

Braces are used to delimit an attribute-value bag, which may
consist of a set, list, or recursively defined tokens and quoted
strings. The bag semantics are defined by its context and the bag
name, which may be a Uniform Resource Identifier (Section 3.2) in
some fields.

bag = "{" bagname 1*LWS *bagitem "}"
bagname = token | URI
bagitem = bag | token | quoted-string

3. Protocol Parameters

3.1 HTTP Version
HTTP uses a "<major>.<minor>" _<major>.<minor>_ numbering scheme to indicate versions of
the protocol. The protocol versioning policy is intended to allow the
sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version number
for the addition of message components which do not affect communication
behavior or which only add to extensible field values. The <minor>
number is incremented when the changes made to the protocol add features
which do not change the general message parsing algorithm, but which may
add to the message semantics and imply additional capabilities of the
sender. The <major> number is incremented when the format of a message
within the protocol is changed.

The version of an HTTP message is indicated by an HTTP-Version field in
the first line of the message. If the protocol version is not specified,
the recipient must MUST assume that the message is in the simple HTTP/0.9
format [6].

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

Note that the major and minor numbers should SHOULD 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 SHOULD be ignored by recipients and never
generated by senders.

Applications sending Full-Request or Full-Response messages, as defined
by this specification, must MUST include an HTTP-Version of
"HTTP/1.1". _HTTP/1.1_. Use
of this version number indicates that the sending application is at
least conditionally compliant with this specification.

HTTP/1.1 servers must:

o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
1.1 requests;

o understand any valid request in the format of HTTP/0.9, 1.0, or
1.1;

o respond appropriately with a message in the same major version
used by the client.

HTTP/1.1 clients must:

o recognize the format of the Status-Line for HTTP/1.0 and 1.1
responses;

o understand any valid response in the format of HTTP/0.9, 1.0,
or 1.1.

Proxy and gateway applications must MUST be careful in forwarding requests
that are received in a format different than that of the application's
native HTTP version. Since the protocol version indicates the protocol
capability of the sender, a proxy/gateway
must MUST never send a message with
a version indicator which is greater than its native version; if a
higher version request is received, the proxy/gateway must MUST either
downgrade the request version, respond with an error, or switch to
tunnel behavior. Requests with a version lower than that of the
application's native format may MAY be upgraded before being forwarded; the
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

proxy/gateway's response to that request must MUST follow the server
requirements listed above.

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

3.2 Uniform Resource Identifiers
URIs have been known by many names: WWW addresses, Universal Document
Identifiers, Universal Resource Identifiers [3], and finally the

combination of Uniform Resource Locators (URL) [4] and Names (URN) [20].

As far as HTTP is concerned, Uniform Resource Identifiers are simply
formatted strings which identify--via name, location, or any other
characteristic--a network resource.

3.2.1 General Syntax
URIs in HTTP can be represented in absolute form or relative to some
known base URI [11], depending upon the context of their use. The two

forms are differentiated by the fact that absolute URIs always begin
with a scheme name followed by a colon.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

URI = ( absoluteURI | relativeURI ) [ "#" fragment ]

absoluteURI = scheme ":" *( uchar | reserved )

relativeURI = net_path | abs_path | rel_path

net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]

path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar

params = param *( ";" param )
param = *( pchar | "/" )

escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "." | "+"
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>

For definitive information on URL syntax and semantics, see RFC 1738 [4]

and RFC 1808 [11]. The BNF above includes national characters not

allowed in valid URLs as specified by RFC 1738, since HTTP servers are
not restricted in the set of unreserved characters allowed to represent
the rel_path part of addresses, and HTTP proxies may receive requests
for URIs not defined by RFC 1738.

3.2.2 http URL

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific 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

if a URI is longer than the server can handle. See section 9.4.

Note: Servers SHOULD be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy 414 Request-URI Too Large
implementations may not properly support these.

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

3.2.2 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 ]

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

If the port is empty or not given, port 80 is assumed. The semantics are
that the identified resource is located at the server listening for TCP
connections on that port of that host, and the Request-URI for the
resource is abs_path. The use of IP addresses in URL's SHOULD be
avoided whenever possible. See RFC 1900[24]. If the abs_path is not

present in the URL, it must MUST be given as "/" _/_ when used as a Request-URI
for a resource (Section 5.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 MUST be identified by
some other URI scheme.

The canonical form for "http" _http_ URLs is obtained by converting any UPALPHA
characters in host to their LOALPHA equivalent (hostnames are case-insensitive), case-

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

insensitive), eliding the [ ":" port ] if the port is 80, and replacing
an empty abs_path with "/". _/_.

3.3 Date/Time Formats

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 made obsolete by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

The first format is preferred as an Internet standard and represents a
fixed-length subset of that defined by RFC 1123 [8] (an update to RFC

822 [9]). The second format is in common use, but is based on the

obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1

clients and servers that parse the date value must MUST accept all three
formats, though they must MUST only generate the RFC 1123 format for
representing date/time stamps in HTTP message fields.

Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been generated by non-HTTP
applications, as is sometimes the case when retrieving or
posting messages via proxies/gateways to SMTP or NNTP.

All HTTP date/time stamps must MUST be represented in Universal Time (UT),
also known as Greenwich Mean Time (GMT), without exception. This is
indicated in the first two formats by the inclusion of
"GMT" _GMT_ as the
three-letter abbreviation for time zone, and should SHOULD be assumed when
reading the asctime format.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

HTTP-date = rfc1123-date | rfc850-date | asctime-date

rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT

date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)

time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59

wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"

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).
. An HTTP/1.1 implementation may internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the proper
value.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

3.3.2 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 SHOULD only be used to represent short
time periods or periods that cannot start until receipt of the message.

delta-seconds = 1*DIGIT

3.4 Character Sets
HTTP uses the same definition of the term "character set" _character set_ as that
described for MIME:

The term "character set" _character set_ is used in this document to refer to a
method used with one or more tables to convert a sequence of
octets into a sequence of characters. Note that unconditional
conversion in the other direction is not required, in that not
all characters may be available in a given character set and a
character set may provide more than one sequence of octets to
represent a particular character. This definition is intended to
allow various kinds of character encodings, from simple
single-table single-
table mappings such as US-ASCII 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 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 are is defined by the IANA Character Set registry
[19]. However, because that registry does not define a single,

consistent token for each character set, we define here the preferred
names for those character sets most likely to be used with HTTP
entities. These character sets include those registered by RFC 1521 [7]

-- the US-ASCII [21] and ISO-8859 [22] character sets -- and other names

specifically recommended for use within MIME charset parameters.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"

registry [19] MUST represent the character set defined by that registry.

Applications SHOULD limit their use of character sets to those defined
by the IANA registry.

_ _ is more commonly Although HTTP allows an arbitrary token to be used as a charset value, | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" any token that has a predefined value within the IANA Character Set registry [19] must represent the character set
defined by that registry. Applications should limit their use of
character sets to those defined by the IANA registry. Note: This use of the term "character set" is more commonly character set
referred to as a "character encoding." _character encoding._ However, since HTTP and
MIME share the same registry, it is important that the
terminology also be shared.

The character set of an entity body SHOULD be labeled as the lowest
common denominator of the character codes used within that body, with
the exception that no label is preferred over the labels US-ASCII or
ISO-8859-1.

3.5 Content Codings
Content coding values are used to indicate an encoding transformation that has been
or can be applied to a resource. Content codings are primarily used to
allow a document to be compressed or encrypted without losing the
identity of its underlying media type. Typically, the resource is stored
in this encoding and only decoded before rendering or analogous usage.

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

Note: For historical reasons, HTTP applications should SHOULD consider "x-gzip"
_x-gzip_ and "x-compress"
_x-compress_ to be equivalent to "gzip" _gzip_ and "compress", _compress_,
respectively.

All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding content-
coding values in the Accept-Encoding (Section 10.3) and Content-Encoding

(Section 10.10) header fields. Although the value describes the content-coding, content-

coding, what is more important is that it indicates what decoding
mechanism will be required to remove the encoding. Note that a single
program may MAY be capable of decoding multiple content-coding formats. Two
values are defined by this specification:

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

gzip
An encoding format produced by the file compression program
"gzip" _gzip_
(GNU zip) developed by Jean-loup Gailly. Gailly[25]. This format is

typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC. Gzip is
available from the GNU project at
<URL:ftp://prep.ai.mit.edu/pub/gnu/>.

compress
The encoding format produced by the file compression program
"compress".
_compress_. This format is an adaptive Lempel-Ziv-Welch coding
(LZW).
Note: Use of program names for the identification of encoding
formats is not desirable and should be discouraged for future
encodings. Their use here is representative of historical
practice, not good design.

HTTP defines a registration process which uses the Internet Assigned
Numbers Authority (IANA) as a central registry for content-coding value
tokens. Additional content-coding value tokens beyond the four defined
in this document (gzip x-gzip compress x-compress) SHOULD be registered
with the IANA. To allow interoperability between clients and servers,
specifications of the content coding algorithms used to implement a new
value SHOULD be publicly available and adequate for independent
implementation, and MUST conform to the purpose of content coding
defined in this section.

3.6 Transfer Codings
Transfer coding values are used to indicate an encoding transformation
that has been, can be, or may need to be applied to an Entity-Body in
order to ensure safe transport through the network. This differs from a
content coding in that the transfer coding is a property of the message,
not of the original resource.

transfer-coding = "chunked" | transfer-extension

transfer-extension = token

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
coding values in the Transfer-Encoding header field (Section 10.39).

Transfer codings are analogous to the Content-Transfer-Encoding values
of MIME [7], which were designed to enable safe transport of binary data

over a 7-bit transport service. However, "safe
transport" _safe transport_ has a
different focus for an 8bit-clean transfer protocol. In HTTP, the only
unsafe characteristic of message bodies is the difficulty in determining
the exact body length (Section 7.2.2), or the desire to encrypt data

over a shared transport.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

All HTTP/1.1 applications must MUST be able to receive and decode the
"chunked"
_chunked_ transfer coding. coding , and MUST ignore chunked extensions they do
not understand. 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.

Chunked-Body = *chunk
"0" CRLF
footer
CRLF

chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF

chunk-size = hex-no-zero *HEX
chunk-data
chunk-ext = chunk-size(OCTET)

footer *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = *<Entity-Header, excluding Content-Length
and Transfer-Encoding> 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 ended by a zero-sized chunk, followed by the
footer and terminated by an empty line. An example process for decoding
a Chunked-Body is presented in Appendix C.5.

3.7 Media Types
HTTP uses Internet Media Types [17] in the Content-Type (Section 10.15)

and Accept (Section 10.1) header fields in order to provide open and

extensible data typing and type negotiation. For
mail applications, where there is no type negotiation between
sender and recipient, it is reasonable to put strict limits on the
set of allowed media types. With HTTP, where the sender and
recipient can communicate directly, applications are allowed more
freedom in the use of non-registered types. The following grammar
for media types is a superset of that for MIME because it does not
restrict itself to the official IANA and x-token types.

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

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Parameters may follow the type/subtype in the form of attribute/value
pairs.

parameter = attribute "=" value
attribute = token
value = token | quoted-string

The type, subtype, and parameter attribute names are case-insensitive.
Parameter values may or may not be case-sensitive, depending on the
semantics of the parameter name. LWS should not MUST NOT be generated between the
type and subtype, nor between an attribute and its value.

If Upon receipt
of a given media-type value has been registered by media type with an unrecognized parameter, a user agent SHOULD
treat the IANA, any
use of that value must be indicative of media type as if the registered data format.
Although unrecognized parameter and its value were
not present.

Some older HTTP allows the applications do not recognize media type parameters.
HTTP/1.1 applications SHOULD only use of non-registered media types, such
usage must not conflict with the IANA registry. Data providers type parameters when they
are
strongly encouraged necessary to register their media types define the content of a message.

Media-type values are registered with IANA via the
procedures Internet Assigned Number
Authority (IANA [19]). The media type registration process is outlined

in RFC 1590 [17].

All media-type's registered by IANA must be preferred over
extension tokens. However, HTTP does not limit applications to the
use Use of officially registered non-registered media types, nor does it encourage the
use of an "x-" prefix for unofficial types outside of explicitly
short experimental use between consenting applications. is discouraged.

3.7.1 Canonicalization and Text Defaults

Media
Internet media types are registered in with a canonical form. In general, entity
bodies
an Entity-Body transferred via HTTP must MUST be represented in the
appropriate canonical form prior to its transmission. If the body has
been encoded
via with a Content-Encoding and/or Transfer-Encoding, Content-Encoding, the underlying data must SHOULD be in
canonical form prior to that encoding. However, HTTP modifies
the canonical form requirements for media being encoded.

Media subtypes of primary the _text_ type "text"
and for "application" types consisting of text-like records.

HTTP redefines use CRLF as the text line break when
in canonical form form. However, HTTP allows the transport of text media to allow multiple
octet sequences to indicate with
plain CR or LF alone representing a text line break. In addition to break when used consistently
within the
preferred form of CRLF, Entity-Body. HTTP applications must MUST accept a CRLF, bare CR, and
bare CR or LF alone as representing being representative of a single line break in text media.
Furthermore, media received
via HTTP.

In addition, if the text media is represented in a character set
which 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 sequence(s) is sequences are defined by that character set to represent the
equivalent of CRLF, bare CR, CR and bare LF. It is
assumed that any recipient capable of using such a character set
will know the appropriate octet sequence LF for representing line
breaks within that character set.

Note: breaks. This interpretation of flexibility regarding line
breaks applies only to text media in the
contents of an Entity-Body and only after any
Transfer-Encoding and/or Content-Encoding has been removed.
All other HTTP constructs use CRLF exclusively to indicate Entity-Body; a
line break. Content and transfer codings define their own
line break requirements.

A recipient bare CR or LF
SHOULD NOT be substituted for CRLF within any of an HTTP text entity should translate the received
entity line breaks to the local line break conventions before
saving the entity external to the application HTTP control
structures (such as header fields and its cache;
whether this translation takes place immediately upon receipt of
the entity, or only when prompted by the user, multipart boundaries).

The _charset_ parameter is entirely up used with some media types to define the individual application.

HTTP also redefines the default
character set for text media in an
entity body. If a textual media type defines a (Section 3.4) of the data. When no explicit charset

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

parameter
with a registered default value is provided by the sender, media subtypes of "US-ASCII", HTTP changes the
default _text_ type
are defined to be "ISO-8859-1". Since the ISO-8859-1 [22] character set
is have a superset of US-ASCII [21], this does not affect the
interpretation default charset value of entity bodies which only contain octets within
the US-ASCII _ISO-8859-1_ when
received via HTTP. Data in character set (0 - 127). The presence of a sets other than _ISO-8859-1_ or its
subsets MUST be labeled with an appropriate charset
parameter value in a Content-Type header field overrides order to be
consistently interpreted by the
default.

It recipient.

Note: Many current HTTP servers provide data using charsets
other than _ISO-8859-1_ without proper labeling. This situation
reduces interoperability and is recommended that not recommended. To compensate
for this, some HTTP user agents provide a configuration option
to allow the character set of an entity body be
labelled as user to change the lowest common denominator default interpretation of the
media type character codes
used within a document, with the exception that set when no label charset parameter is
preferred over the labels US-ASCII or ISO-8859-1. given.

3.7.2 Multipart Types
MIME provides for a number of "multipart" _multipart_ types -- encapsulations of one
or more entities within a single message's Entity-Body. All multipart
types share a common syntax, as defined in Section 7.2.1 of RFC 1521 [7], [7]

, and must MUST include a boundary parameter as part of the media type value.
The message body is itself a protocol element and must MUST therefore use
only CRLF to represent line breaks between body-parts. Unlike in MIME, RFC
1521, the epilogue of any multipart message
must MUST be empty; HTTP
applications must not MUST NOT transmit the epilogue even if the original
resource contains an epilogue.

In HTTP, multipart body-parts may MAY contain header fields which are
significant to the meaning of that part. A URI entity-header field
(Section 10.42) should be included in the body-part for each
enclosed entity that can be identified by a URI.

In general, an HTTP user agent should SHOULD follow the same or similar
behavior as a MIME user agent would upon receipt of a multipart type. The following subtypes have been defined:

multipart/mixed

The mixed subtype is used when there are no additional semantics
implied beyond the fact that one or more entities are
encaspsulated. HTTP servers should not use this type to send
groups of entities if it is possible for those entities to be
individually retrieved and cached.

multipart/alternative

The alternative subtype implies that each of the parts is an
alternative format for the same information; the user agent
should present only the part most preferred by the user. HTTP
servers should use some form of content negotiation (Section 12)
instead of this type.

multipart/digest

The digest subtype implies that each of the parts is a message
(normally of type "message/rfc822") and thus the whole entity is
a collected sequence of message traffic. This type does not have
any special significance for HTTP.

multipart/form-data

The form-data subtype is defined by RFC 1867 [15] for use in
submitting the data that comes about from filling-in a form.

multipart/parallel

The parallel subtype implies that the parts should be presented
simultaneously by the user agent. This media type would be
appropriate for situations where simultaneous presentation is an
important aspect of the information, such as for audio-annotated
slides.

Note: This document does not define what is meant by
"simultaneous presentation". That is, HTTP does not provide
any means of synchronization between the parts in messages
of type "multipart/parallel".

Other multipart subtypes may be registered by IANA [19] according
to the procedures defined in RFC 1590 [17]. If
an application receives an unrecognized multipart subtype, the
application must MUST treat it as being equivalent to "multipart/mixed". _multipart/mixed_.

Note: The "multipart/form-data" type has been specifically
defined for carrying form data suitable for processing via the
POST request method, as described in RFC 1867 [15].

3.8 Product Tokens
Product tokens are used to allow communicating applications to identify
themselves via a simple product token, with an optional slash and
version designator. Most fields using product tokens also allow subproducts sub-
products which form a significant part of the application to be listed,
separated by whitespace. By convention, the products are listed in order
of their significance for identifying the application.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

product = token ["/" product-version]
product-version = token

Examples:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

Product tokens should SHOULD be short and to the point -- use of them for
advertizing
advertising or other non-essential information is explicitly forbidden.
Although any token character may appear in a product-version, this token should
SHOULD only be used for a version identifier (i.e., successive versions
of the same product should SHOULD only differ in the product-version portion of
the product value).

3.9 Quality Values
HTTP content negotiation (Section 12) uses short "floating point" _floating point_

numbers to indicate the relative importance ("weight") (_weight_) of various
negotiable parameters. The weights are normalized to a real number in
the range 0 through 1, where 0 is the minimum and 1 the maximum value.
In order to discourage misuse of this feature, HTTP/1.1 applications must
MUST not generate more than three digits after the decimal point. User
configuration of these values should SHOULD also be limited in this fashion.

qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "." 0*3DIGIT )
| ( "1" [ "." 0*3("0") ] )

"Quality values"

_Quality values_ is a slight misnomer, since these values actually
measure relative degradation in perceived quality. Thus, a value of
"0.8"
_0.8_ represents a 20% degradation from the optimum rather than a
statement of 80% quality.

3.10 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,
Content-Language, and URI-header Content-Language
fields.

The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

more parts: A primary language tag and a possibly empty series of
subtags:

language-tag = primary-tag *( "-" subtag )

primary-tag = 1*8ALPHA
subtag = 1*8ALPHA

Whitespace is not allowed within the tag and all tags are
case-insensitive. case-
insensitive. The namespace 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.

In the context of the Accept-Language header (Section 10.4), a
language tag is The last
three tags above are not to registered tags, but examples of tags which
could be interpreted as a single token, as per RFC
1766, but as a hierarchy. A server should consider that it has a
match when a language tag received registered in an Accept-Language header
matches the initial portion of future.

3.12 Full Date Values
Contents moved to section 3.3.

3.13 Opaque Validators
Opaque validators are quoted strings whose internal structure is not
visible to clients or caches.

opaque-validator = strong-opaque-validator | weak-opaque-validator
| null-validator
strong-opaque-validator = quoted-string
weak-opaque-validator = quoted-string "/W"
null-validator = <"> <">

Note that the language _/W_ tag is considered part of a document. An
exact match should weak opaque
validator; it MUST NOT be preferred. This interpretation allows a
browser to send, for example:

Accept-Language: en-US, en; ql=0.95

when the intent is removed by any cache or client.

There are two comparison functions on opaque validators:

. The strong comparison function: in order to access, be considered equal,
both validators must be identical in every way, and neither may be
weak.
. The weak comparison function: in order of preference, documents to be considered equal, both
validators must be identical in
US-English ("en-US"), 'plain' every way, except for the presence
or 'international' English ("en"), absence of a _weak_ tag.
Fielding, Frystyk, Berners-Lee, Gettys, and any Mogul [Page 31]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The weak comparison function MAY be used for simple (non-subrange) GET
requests. The strong comparison function MUST be used in all other variant
cases.

The null validator is a special value, defined as never matching the
current validator of English (initial "en-").

Note: Using an existing resource, and always matching the language tag as
_current_ validator of a hierarchy resource that does not imply
that all languages with a common prefix will be understood
by those fluent in one or more of those languages; it simply
allows the user exist.

3.14 Variant IDs
Variant-IDs are used to request this commonality when it is true
for that user.

3.11 Logic Bags

A logic bag is identify specific entities (variants) of a binary logic expression tree represented in prefix
notation
varying resource; see section 13.8.3 for how they are used.

variant-id = quoted-string

Variant-IDs are compared using the generic bag syntax. Logic bags string octet-equality; case is
significant.

3.15 Validator Sets
Validator sets are used by for doing conditional retrievals on varying
resources; see section 13.8.4.

validator-set = 1#validator-set-item
validator-set-item = opaque-validator

3.16 Variant Sets
Validator sets are used for doing conditional retrievals on varying
resources; see section 13.8.3.

variant-set = 1#variant-set-item
variant-set-item = opaque-validator ";" variant-id

3.17 HTTP
in the Unless (Section 10.40) header field as expressions Protocol Parameters Related to Ranges
This section defines certain HTTP protocol parameters used in range
requests and related responses.

3.17.1SLUSHY Range Units
A resource may be
tested against the requested resource's header field
metainformation.

logic-bag = "{" expression "}"

expression = ( log-op 1*logic-bag )
| ( rel-op 1*field-tuple )
| ( "def" 1*field-name )

log-op broken down into subranges according to various
structural units.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

bytes-unit = "and" | "or" | "xor" | "not"
rel-op "bytes"

The only range unit defined by HTTP/1.1 is . HTTP/1.1 range-unit = "eq" | "ne" | "lt" | "le" | "ge" | "gt" | "in"

field-tuple bytes-unit other-range-unit _bytes_
implementations may ignore ranges specified using other units. other-
range-unit = "{" field-name ( bag | token | quoted-string ) "}"

The recursive structure

3.17.2 SLUSHY Byte Ranges
Since all HTTP entities are represented in HTTP messages as sequences of
bytes, the concept of a logic bag allows a complex expression
tree byte range is meaningful for any HTTP entity.
(However, not all clients and servers need to support byte-range
operations.)

Byte range specifications in HTTP apply to the sequence of bytes that
would be formed transferred by joining together subexpressions with logical
operators. Expressions with relational operators are used to
compare the requested resource's corresponding metainformation
(header field values) protocol if no transfer-encoding were being
applied.

This means that if Content-encoding is applied to those inside the expression field-tuples.
For example,

{or {ne {Content-MD5 "Q2hlY2sgSW50ZWdyaXR5IQ=="}}
{ne {Content-Length 10036}}
{ne {Content-Version "12.4.8"}}
{gt {Last-Modified "Mon, 04 Dec 1995 01:23:45 GMT"}}}

The expression is evaluated recursively by depth-first traversal
and bottom-up evaluation of data, the subexpressions until a true or
false value can be determined. Multiple operands
byte range specification applies to an operator
imply a conjunctive ("and") expression; e.g.,

{eq {A "a"} {B "b"} {C "c"}}

is equivalent the resulting content-
encoded byte stream, not to

{and {eq {A "a"}} {eq {B "b"}} {eq {C "c"}}}

Each expression is evaluated as defined by the operator:

and True unencoded byte stream. It also
means that if all of the operands evaluate true.

or True if any of entity-body's media-type is a composite type
(e.g., multipart/* and message/rfc822), then the operands evaluate true.

xor True if one composite's
body-parts may have their own content-encoding and content-
transfer-encoding, and only one operand evaluates true.

not True if all of the operands evaluate false.

eq True if all field-tuple values exactly match byte range applies to the resource's
corresponding field values.

ne True if all field-tuple values do not match result of
the resource's
corresponding field values.

lt True if, for each field-tuple, those encodings.

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

ranges-specifier = byte-ranges-specifier

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

byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )

byte-range-spec = first-byte-pos "-" [last-byte-pos]

first-byte-pos = 1*DIGIT

last-byte-pos = 1*DIGIT

The first-byte-pos value in a byte-range-spec gives the resource's corresponding
field byte-offset of
the first byte in a range. The last-byte-pos value is less than gives the one given byte-
offset of the last byte in the expression.

le True if, for each field-tuple, range; that is, the resource's corresponding
field byte positions
specified are inclusive. Byte offsets start at zero.

If the last-byte-pos value is less present, it must be greater than or equal
to the one given first-byte-pos in that byte-range-spec, or the
expression.

ge True if, for each field-tuple, byte-range-spec is
invalid. The recipient of an invalid byte-range-spec must ignore it.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

If the resource's corresponding
field last-byte-pos value is greater than or absent, it is assumed to be equal to the one given in
current length of the
expression.

gt True if, for each field-tuple, entity in bytes.

If the resource's corresponding
field last-byte-pos value is greater larger than the one given in current length of the expression.

in True if, for each field-tuple,
entity, it is assumed to be equal to the resource's corresponding
field value contains current length of the component value given in entity.

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

suffix-length = 1*DIGIT

A suffix-byte-range-spec is used to specify the
expression.

def True if, for each field-name operand, suffix of the resource defines a
value for that field.

A field-tuple consists entity, of
a field-name (assumed to be an HTTP
header field name, though not constrained to those defined length given by the suffix-length value. (That is, this
specification) and form
specifies the field-value component which last N bytes of an entity.) If the entity is to be
compared against shorter than
the resource's field value. specified suffix-length, the entire entity is used.

Examples of byte-ranges-specifier values (assuming an entity of length
10000):

. The actual method first 500 bytes (byte offsets 0-499, inclusive):
bytes=0-499

. The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999

. The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500

. Or
bytes=9500-

. The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1

. Several legal but not canonical specifications of
comparison (e.g., byte equivalence, substring matching, numeric
order, substructure containment, etc.) is defined by the logical
definition second 500
bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999

bytes=500-700,601-999

3.17.3 SLUSHY: Content Ranges
When a server returns a partial response to a client, it must describe
both the extent of the operator range covered by the response, and the type length of field-value allowed for
that field-name. Server implementors
the entire entity.

content-range-spec = byte-content-range-spec

byte-content-range-spec = bytes-unit SP first-byte-pos "-"

last-byte-pos "/" entity-length

entity-length = 1*DIGIT

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Unlike byte-ranges-specifier values, a byte-content-range-spec may only
specify one range, and must use an appropriate
comparison function contain absolute byte positions for each type both the
first and last byte of field-value given in this
specification. 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 its
last-byte-pos value, is invalid. The default functions for unrecognized fields are
numeric comparison (for values consisting recipient of 1*DIGIT) an invalid byte-
content-range-spec must ignore it and lexical
comparison (for all others).

Except for "ne", any comparison to content transferred along with
it.

Examples of byte-content-range-spec values, assuming that the entity
contains a field not defined by total of 1234 bytes:

. The first 500 bytes:
bytes 0-499/1234

. The second 500 bytes:
bytes 500-999/1234

. All except for the
resource evaluates to false. first 500 bytes:
bytes 500-1233/1234

. The last 500 bytes:
bytes 734-1233/1234

4. HTTP Message

4.1 Message Types
HTTP messages consist of requests from client to server and responses
from server to client.

HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.1 messages
| Full-Response

Full-Request
| NULL-Request

A NULL-Request (an empty line where a request would normally be
expected) MUST be ignored. Clients SHOULD NOT send a NULL-Request, but
there are some error and Full-Response testing circumstances in which a NULL-Request
might be sent by mistake and MUST NOT cause failure on the server.

NULL-Request = CRLF

Full-Request and Full-Response use the generic message format of RFC 822
[9] for transferring entities. Both messages may include optional header

fields (also known as "headers") _headers_) and an entity body. The entity body is
separated from the headers by a null line (i.e., a line with nothing
preceding the CRLF).

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Full-Request = Request-Line ; Section 5.1

*( General-Header ; Section 4.3

| Request-Header ; Section 5.2

| Entity-Header ) ; Section 7.1

CRLF
[ Entity-Body ] ; Section 7.2

Full-Response = Status-Line ; Section 6.1

*( General-Header ; Section 4.3

| Response-Header ; Section 6.2

| Entity-Header ) ; Section 7.1

CRLF
[ Entity-Body ] ; Section 7.2

Simple-Request and Simple-Response do not allow the use of any
header information and are limited to a single request method (GET).

Simple-Request = "GET" SP Request-URI CRLF

Simple-Response = [ Entity-Body ]

Use of the Simple-Request format is discouraged because it prevents
the client from using content negotiation and the server from
identifying the media type of the returned entity.

4.2 Message Headers
HTTP header fields, which include General-Header (Section 4.3),
Request-Header Request-

Header ( General-Header (Section 5.2), Response-Header (Section 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. 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.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

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

and consisting of either *TEXT or combinations

The order in which header fields with differing field names are received
_ field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations of token, tspecials, and quoted-string>

The order in which header fields are received is not significant. However, it is "good practice" good practice_ to send General-Header General-
Header fields first, followed by Request-Header or Response-Header fields prior to
fields, and ending with the Entity-Header fields.

Multiple HTTP-header fields with the same field-name may be present in a
message if and only if the entire field-value for that header field is
defined as a comma-separated list [i.e., #(values)]. It
must MUST be possible
to combine the multiple header fields into one
"field-name: field-value" _field-name: field-value_
pair, without changing the semantics of the message, by appending each
subsequent field-value to the first, each separated by a comma. Thus,
the order in which multiple header fields with the same field-name are
received may be significant to the interpretation of the combined field-
value.

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

General-Header = Cache-Control ; Section 10.8

| Connection ; Section 10.9

| Date ; Section 10.17

| Forwarded Via ; Section 10.20

| Keep-Alive ; Section 10.24

| MIME-Version ; Section 10.28
| Pragma ; Section 10.29

| Upgrade ; Section 10.41

General header field names can be extended reliably only in combination
with a change in the protocol version. However, new or experimental
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

header fields may be given the semantics of general header fields if all
parties in the communication recognize them to be general header fields.
Unrecognized header fields are treated as Entity-Header fields.

5. 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 = Simple-Request | Full-Request

Simple-Request = "GET" SP Request-URI CRLF

Full-Request = Request-Line ; Section 5.1

*( General-Header ; Section 4.3

| Request-Header ; Section 5.2

| Entity-Header ) ; Section 7.1

CRLF
[ Entity-Body ] ; Section 7.2

If an HTTP/1.1 server receives a Simple-Request, it must respond
with an HTTP/0.9 Simple-Response. An HTTP/1.1 client must never
generate a Simple-Request.

NULL-Request = CRLF

A NULL-Request MUST be ignored.

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

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

Note that the difference between a Simple-Request and the
Request-Line of a Full-Request is the presence of the HTTP-Version
field and the availability of methods other than GET.

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.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Method = "OPTIONS" ; Section 8.1

| "GET" ; Section 8.2

| "HEAD" ; Section 8.3

| "POST" ; Section 8.4

| "PUT" ; Section 8.5

| "WRAPPED" ; Section 8.13
| extension-method

extension-method = token

The list of methods acceptable by a specific resource can be specified in an
Allow header field (Section 10.5). ). However, the client is always Section 8.1 Section 8.2 in an header field (Section 10.5

notified through the return code of the response whether a method is
currently allowed on a specific resource, as this can change
dynamically. Servers should SHOULD return the status code 405 (method not
allowed) if the method is known by the server but not allowed for the
requested resource, and 501 (not implemented) if the method is
unrecognized or not implemented by the server. The list of methods known
by a server can be listed in a Public response header field
(Section 10.32).

The methods GET and HEAD must MUST be supported by all general-purpose
servers. Servers which provide Last-Modified dates for resources
must MUST
also support the conditional GET method. All other methods are optional;
however, if the above methods are implemented, they must MUST be implemented
with the same semantics as those specified in Section 8.

5.1.2 Request-URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) and

identifies the resource upon which to apply the request.

Request-URI = "*" | absoluteURI | abs_path

To allow for transition to absoluteURIs in all requests in future
versions of HTTP, HTTP/1.1 servers MUST accept the absoluteURI form in
requests, even though HTTP/1.1 clients will not normally generate them.
Versions of HTTP after HTTP/1.1 may require absoluteURIs everywhere,
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

after HTTP/1.1 or later have become the dominant implementations. The
three options for Request-URI are dependent on the nature of the
request. The asterisk "*" _*_ means that the request does not apply to a
particular resource, but to the server itself, and is only allowed when
the Method used does not necessarily apply to a resource. One example
would be

OPTIONS * HTTP/1.1

The absoluteURI form is only allowed to an origin server if the client
knows the server supports HTTP/1.1 or later. If the absoluteURI form is
used, any Host request-header included with the request MUST be ignored.
The absoluteURI form is required when the request is being made to a
proxy. The proxy is requested to forward the request and return the
response. If the request is GET or HEAD and a prior response is cached,
the proxy may use the cached message if it passes any restrictions in
the Cache-Control and Expires header fields. Note that the proxy may 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
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

The most common form of Request-URI is that used to identify a resource
on an origin server or gateway. In this case, only the absolute path of
the URI is transmitted (see Section 3.2.1, abs_path). For example, a

client wishing to retrieve the resource above directly from the origin
server would create a TCP connection to port 80 of the host "www.w3.org" _www.w3.org_
and send the line: lines:

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

followed by the remainder of the Full-Request. Note that the absolute
path cannot be empty; if none is present in the original URI, it must MUST be
given as "/" _/_ (the server root).

If a proxy receives a request without any path in the Request-URI and
the method used is capable of supporting the asterisk form of request,
then the last proxy on the request chain must MUST forward the request with "*"
_*_ as the final Request-URI. For example, the request

OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

would be forwarded by the proxy as

OPTIONS * HTTP/1.1

_www.ics.uci.edu_.

is transmitted as an encoded string, where some after connecting to port 8001 of host "www.ics.uci.edu". The Request-URI is transmitted as an encoded string, where some
characters may be escaped using the "% hex hex" _% HEX HEX_ encoding defined by RFC
1738 [4]. The origin server must MUST decode the Request-URI in order to

properly interpret the request.

5.2 Request Header Fields

The request header fields allow In requests that they forward, proxies
MUST NOT rewrite the client _abs_path_ part of a Request-URI in any way except
as noted above to pass additional
information about replace a null abs_path with _*_. Illegal Request-URIs
SHOULD be responded to with an appropriate status code. (Proxies MAY
transform the request, Request-URI for internal processing purposes, but SHOULD
NOT send such a transformed Request-URI in forwarded requests.
Transformations for use in cache updates and about the client itself, lookups are subject to the
server. These fields act as request modifiers, with semantics
equivalent
additional requirements; see section 13 on caching. The main reason for
this rule is to make sure that the parameters on a form of Request-URIs is well
specified, to enable future extensions without fear that they will break
in the face of some rewritings. Another is that one consequence of
rewriting the Request-URI is that integrity or authentication checks by
the server may fail; since rewriting MUST be avoided in this case, it
may as well be proscribed in general.

Note: servers writers SHOULD be aware that some existing proxies
do some rewriting.

5.2 Request Header Fields
The request header fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics equivalent
to the parameters on a programming language method (procedure)
invocation.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Request-Header = Accept ; Section 10.1

| Accept-Charset ; Section 10.2

| Accept-Encoding ; Section 10.3

| Accept-Language ; Section 10.4

| Authorization ; Section 10.6

| From ; Section 10.21

| Host ; Section 10.22

| If-Modified-Since ; Section 10.23

| Proxy-Authorization ; Section 10.31

| Range ; Section 10.33

| Referer ; Section 10.34

| Unless User-Agent ; Section 10.40 10.43

| User-Agent Max-Forwards ; Section 10.43 10.45

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

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

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Response = Simple-Response | Full-Response

Simple-Response = [ Entity-Body ]

Full-Response = Status-Line ; Section 6.1

*( General-Header ; Section 4.3

| Response-Header ; Section 6.2

| Entity-Header ) ; Section 7.1

CRLF
[ Entity-Body ] ; Section 7.2

A Simple-Response should only be sent in response to an HTTP/0.9
Simple-Request or if the server only supports the more limited
HTTP/0.9 protocol. If a client sends an HTTP/1.1 Full-Request and
receives a response that does not begin with a Status-Line, it
should assume that the response is a Simple-Response and parse it
accordingly. Note that the Simple-Response consists only of the
entity body and is terminated by the server closing the connection.

6.1 Status-Line
The first line of a Full-Response message is the Status-Line, consisting of the protocol version followed by a numeric status
code and its

associated textual phrase, with each element separated by SP characters.
No CR or LF is allowed except in the final CRLF sequence.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Since a status line always begins with the protocol version and
status code

"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

(e.g., "HTTP/1.1 200 "), the presence of that expression is
sufficient to differentiate a Full-Response from a Simple-Response.
Although the Simple-Response format may allow such an expression to
occur at the beginning of an entity body, and thus cause a
misinterpretation of the message if it was given in response to a
Full-Request, most HTTP/0.9 servers are limited to responses of
type "text/html" and therefore would never generate such a response.

6.1.1 Status Code and Reason Phrase

The Status-Code
element is a 3-digit integer result code of the attempt of the protocol version followed by a numeric status code and its The Status-Code
to understand and satisfy the request. The Reason-Phrase is intended to
give a short textual description of the Status-Code. The Status-Code is
intended for use by automata and the Reason-Phrase is intended for the
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

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

. 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for HTTP/1.1,
and an example set of corresponding Reason-Phrase's, are presented
below. The reason phrases listed here are only recommended -- they may
be replaced by local equivalents without affecting the protocol. These
codes are fully defined in Section 9.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

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 MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an unrecognized
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

response must MUST not be cached. For example, if an unrecognized status code
of 431 is received by the client, it can safely assume that there was
something wrong with its request and treat the response as if it had
received a 400 status code. In such cases, user agents should SHOULD present to
the user the entity returned with the response, since that entity is
likely to include human-readable information which will explain the
unusual status.

6.2 Response Header Fields
The response header fields allow the server to pass additional
information about the response which cannot be placed in the
Status-Line. Status-
Line. These header fields are not intended to give information about an Entity-Body returned in the response, but server and about
further access to the resource or identified by the server itself.

Response-Header= Request-URI.

Response-Header = Location ; Section 10.27

| Proxy-Authenticate ; Section 10.30

| Public ; Section 10.32

| Retry-After ; Section 10.36

| Server ; Section 10.37

| WWW-Authenticate ; Section 10.44

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

7. Entity
Full-Request and Full-Response messages may MAY transfer an entity within
some requests and responses. An entity consists of Entity-Header fields
and (usually) an Entity-Body. In this section, both sender and recipient
refer to either the client or the server, depending on who sends and who
receives the entity.

7.1 Entity Header Fields
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.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Entity-Header = Allow ; Section 10.5

| Content-Base ; Section 10.9

| Content-Encoding ; Section 10.10

| Content-Language ; Section 10.11

| Content-Length ; Section 10.12

| Content-Location ; Section 10.16

| Content-MD5 ; Section 10.13

| Content-Range ; Section 10.14

| Content-Type ; Section 10.15

| Content-Version ; Section 10.16
| Derived-From ; Section 10.18
| Expires ; Section 10.19

| Last-Modified ; Section 10.25

| Link ; Section 10.26
| Title ; Section 10.38

| Transfer-Encoding ; Section 10.39

| URI-header ; Section 10.42
| extension-header

extension-header=HTTP-header

extension-header = HTTP-header

The extension-header mechanism allows additional Entity-Header fields to
be defined without changing the protocol, but these fields cannot be
assumed to be recognizable by the recipient. Unrecognized header fields should
SHOULD be ignored by the recipient and forwarded by proxies.

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

Entity-Body = *OCTET

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

For response messages, whether or not an entity body is included with a
message is dependent on both the request method and the response code.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

All responses to the HEAD request method must MUST not include a body, even
though the presence of entity header fields may lead one to believe they
do. All 1xx (informational), 204 (no content), and 304 (not modified)
responses must MUST not include a body. All other responses must MUST include an
entity body or a Content-Length header field defined with a value of
zero (0).

7.2.1 Type
When an entity body is included with a message, the data type of that
body is determined via the header fields Content-Type, Content-Encoding,
and Transfer-Encoding. These define a three-layer, ordered encoding
model:

entity-body :=
Transfer-Encoding( Content-Encoding( Content-Type( data ) ) )

The default for both encodings is none (i.e., the identity function).
Content-Type specifies the media type of the underlying data. Content-Encoding Content-
Encoding may be used to indicate any additional content codings applied
to the type, usually for the purpose of data compression, that are a
property of the resource requested. Transfer-Encoding may be used to
indicate any additional transfer codings applied by an application to
ensure safe and proper transfer of the message. Note that Transfer-Encoding Transfer-
Encoding is a property of the message, not of the resource.

Any HTTP/1.1 message containing an entity body should SHOULD include a
Content-Type 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,
as is the case for Simple-Response messages, the recipient may
attempt to guess the media type via inspection of its content and/or the
name extension(s) of the URL used to identify the resource. If the media
type remains unknown, the recipient should SHOULD treat it as type "application/octet-stream".
_application/octet-stream_.

7.2.2 Length
When an entity body is included with a message, the length of that body
may be determined in one of several ways. If a Content-Length header
field is present, its value in bytes represents the length of the entity
body. Otherwise, the body length is determined by the Transfer-Encoding
(if the "chunked" _chunked_ transfer coding has been
applied), by the Content-Type (for multipart types with an explicit
end-of-body delimiter), applied) or by the server
closing the connection.

Note: Any response message which must not MUST NOT include an entity body
(such as the 1xx, 204, and 304 responses and any response to a
HEAD request) is always terminated by the first empty line after
the header fields, regardless of the entity header fields
present in the message.

Closing the connection cannot be used to indicate the end of a request
body, since it leaves no possibility for the server to send back a
response. For compatibility with HTTP/1.0 applications, HTTP/1.1
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

requests containing an entity body must MUST include a valid Content-Length
header field unless the server is known to be HTTP/1.1 compliant.
HTTP/1.1 servers must MUST accept the "chunked" _chunked_ transfer coding (Section 3.6) and multipart media types
(Section 3.7.2), 3.6

), thus allowing either this mechanism to be used for a request when Content-Length Content-
Length is unknown.

If a request contains an entity body and Content-Length is not
specified, the server should SHOULD respond with 400 (bad request) if it cannot
determine the length of the request message's content, or with 411
(length required) if it wishes to insist on receiving a valid Content-Length. Content-
Length.

Messages must not MUST NOT include both a Content-Length header field and the "chunked"
_chunked_ transfer coding. If both are received, the Content-Length must MUST
be ignored.

When a Content-Length is given in a message where an entity body is
allowed, its field value must MUST exactly match the number of OCTETs in the
entity body. HTTP/1.1 user agents must MUST notify the user when an invalid
length is received and detected.

8. Method Definitions
The set of common methods for HTTP/1.1 is defined below. Although this
set can be expanded, additional methods cannot be assumed to share the
same semantics for separately extended clients and servers.

The semantics of Host request-header field (Section 10.22) MUST accompany all methods may be affected by the presence of an
Unless request header field, as described in Section 10.40.

HTTP/1.1 requests.

8.1 OPTIONS
The OPTIONS method represents a request for information about the
communication options available on the request/response chain identified
by the Request-URI. This method allows the client to determine the
options and/or requirements associated with a resource, or the
capabilities of a server, without implying a resource action or
initiating a resource retrieval.

Unless the server's response is an error, the response must not 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 MUST
include a Content-Length with a value of zero (0). Responses to this
method are not cachable.

If the Request-URI is an asterisk ("*"), (_*_), the OPTIONS request is intended
to apply to the server as a whole. A 200 response should SHOULD include any
header fields 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 5.1.2, an "OPTIONS *" _OPTIONS *_ request can be

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

applied through a proxy by specifying the destination server in the
Request-URI without any path information.

If the Request-URI is not an asterisk, the OPTIONS request applies only
to the options that are available when communicating with that resource.
A 200 response should SHOULD include any header fields which indicate optional
features implemented by the server and applicable to that resource
(e.g., Allow), including any extensions not defined by this
specification, in addition to any applicable general or response header
fields. If the OPTIONS request passes through a proxy, the proxy must MUST
edit the response to exclude those options known to be unavailable
through that proxy.

8.2 GET
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI. If the Request-URI refers to a
data-producing process, it is the produced data which shall be returned
as the entity in the response and not the source text of the process,
unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" _conditional GET_ if the
request message includes an If-Modified-Since header field. A
conditional GET method requests that the identified resource be
transferred only if it has been modified since the date given by the If-Modified-Since If-
Modified-Since header, as described in Section 10.23. The conditional

GET method is intended to reduce unnecessary network usage by allowing
cached entities to be refreshed without requiring multiple requests or
transferring data already held by the client.

The semantics of the GET method change to a "partial GET" _partial GET_ if the request
message includes a Range header field. A partial GET requests that only
part of the identified resource be transferred, as described in
Section 10.33. The partial GET method is intended to reduce unnecessary

network usage by allowing partially-retrieved entities to be completed
without transferring data already held by the client.

The response to a GET request may be cachable if and only if it meets
the requirements for HTTP caching described in Section 13.

8.3 HEAD
The HEAD method is identical to GET except that the server must MUST not
return any Entity-Body in the response. The metainformation contained in
the HTTP headers in response to a HEAD request should SHOULD be identical to
the information sent in response to a GET request. This method can be
used for obtaining metainformation about the resource identified by the
Request-URI without transferring the Entity-Body itself. This method is
often used for testing hypertext links for validity, accessibility, and
recent modification.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The response to a HEAD request may be cachable in the sense that the
information contained in the response may be used to update a previously
cached entity from that resource. If the new field values indicate that
the cached entity differs from the current resource (as would be
indicated by a change in Content-Length, Content-MD5, or Content-Version), Content-
Version), then the cache must MUST discard the cached entity.

There is no "conditional HEAD" _conditional HEAD_ or "partial HEAD" _partial HEAD_ request analogous 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 SHOULD be
ignored.

8.4 POST
The POST method is used to request that the destination server accept
the entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed to
allow a uniform method to cover the following functions:

. Annotation of existing resources;

. Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles;

. Providing a block of data, such as the result of submitting a form
[5], to a data-handling process;

. Extending a database through an append operation.
The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted entity is
subordinate to that URI in the same way that a file is subordinate to a
directory containing it, a news article is subordinate to a newsgroup to
which it is posted, or a record is subordinate to a database.

HTTP/1.1 allows for a two-phase process to occur in accepting and
processing a POST request. If the media type of the posted entity
is not "application/x-www-form-urlencoded" [5], an HTTP/1.1 client
must pause between sending the message header fields (including the
empty line signifying the end of the headers) and sending the
message body; the duration of the pause is five (5) seconds or
until a response is received from the server, whichever is shorter.
If no response is received during the pause period, or if the
initial response is 100 (continue), the client may continue sending
the POST request. If the response indicates an error, the client
must discontinue the request and close the connection with the
server after reading the response.

Upon receipt of a POST request, the server must examine the header
fields and determine whether or not the client should continue its
request. If any of the header fields indicate the request is
insufficient or unacceptable to the server (i.e., will result in a
4xx or 5xx response), or if the server can determine the response
without reading the entity body (e.g., a 301 or 302 response due to
an old Request-URI), the server must send that response immediately
upon its determination. If, on the other hand, the request appears
(at least initially) to be acceptable and the client has indicated
HTTP/1.1 compliance, the server must transmit an interim 100
response message after receiving the empty line terminating the
request headers and continue processing the request. After
processing has finished, a final response message must be sent to
indicate the actual result of the request. A 100 response should
not be sent in response to an HTTP/1.0 request except under
experimental conditions, since an HTTP/1.0 client may mistake the
100 response for the final response.

For compatibility with HTTP/1.0 applications, all POST requests
must MUST
include a valid Content-Length header field unless the server is known
to be HTTP/1.1 compliant. When sending a POST request to an HTTP/1.1
server, a client must MUST use at least one of: a valid
Content-Length, a multipart Content-Type, Content-Length or the "chunked" _chunked_
Transfer-Encoding. The server should SHOULD respond with a 400 (bad request)
message if it cannot determine the length of the request message's
content, or with 411 (length required) if it wishes to insist on
receiving a valid Content-Length.

The client can suggest one or more URIs for the new resource by
including a URI header field in the request. However, the server
should treat those URIs as advisory and may store the entity under
a different URI, additional URIs, or without any URI.

The client may apply relationships between the new resource and
other existing resources by including Link header fields, as
described in Section 10.26. The server may use the Link information
to perform other operations as a result of the new resource being
added. For example, lists and indexes might be updated. However, no
mandatory operation is imposed on the origin server. The origin
server may also generate its own or additional links to other
resources.

A successful POST does not require that the entity be created as a
resource on the origin server or made accessible for future reference.
That is, the action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200 (ok)
or 204 (no content) is the appropriate response status, depending on
whether or not the response includes an entity that describes the
result.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

If a resource has been created on the origin server, the response
should SHOULD
be 201 (created) and contain an entity (preferably of type
"text/html") _text/html_)
which describes the status of the request and refers to the new
resource.

Responses to this method are not cachable. However, the 303 (see other)
response can be used to direct the user agent to retrieve a cachable
resource.

8.5 PUT

The PUT method

POST requests that must obey the enclosed entity be stored under
the supplied Request-URI. If the Request-URI refers transmission requirements set out in
section 8.4.1.

8.4.1 SLUSHY: Entity Transmission Requirements
The following rules apply to any method that is subject to an already
existing resource, the enclosed entity should be considered as two-phase
mechanism.

Upon receiving such a
modified version of the one residing on the origin server. If the
Request-URI does not method from an HTTP/1.1 (or later) client, an
HTTP/1.1 (or later) server immediately either respond with _100
Continue_ and continue to read from the input stream, or respond with an
error status. If it responds with an error status, it MAY close the
transport (TCP) connection or it MAY continue to read and discard the
rest of the request. It MUST not perform the requested action if
returns an error status.

HTTP/1.1 servers are encouraged to maintain persistent connections and
use TCP's flow control mechanisms to resolve temporary overloads, rather
than terminating connections with 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 an error status while it is transmitting the body
of the request including any encoding mechanism used to transmit the
body. If the client sees an error status, it SHOULD immediately cease
transmitting the body. If the body was proceeded by a Content-length
header, the client MUST either close the connection or if the body is
being sent using a Chunked encoding, use a 0 length chunk, to mark the
end of the message.

An HTTP/1.1 (or later) client MUST be prepared to accept a 100 Continue
status followed by a regular response.

An HTTP/1.1 (or later) client that sees the connection close before
receiving any status from the server SHOULD retry the request, but if it
does so, it MUST use the two-phase mechanism. In the two-phase
mechanism, the client first sends the request headers, then waits for
the server to respond with either a 100 Continue, in which case the
client SHOULD continue, or an error status, in which case the client
MUST NOT continue and MUST close the connection if it has not already
completed sending the full request body including any encoding mechanism
used to transmit the body.

If the client knows that the server is an HTTP/1.1 (or later) server,
because of the server protocol version returned with a previous request
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

on the same persistent connection [alternatively: within the past <N>
hours], it MUST wait for a response. If the client believes that the
server is a 1.0 or earlier server, it SHOULD continue transmitting
its request after waiting at least [5] seconds for a status response.

An HTTP/1.1 (or later) client that sees the connection close after
receiving a _100 Continue_ but before receiving any other status SHOULD
retry the request, and need not use the two-phase method (but MAY do so
if this simplifies the implementation).

An HTTP/1.1 (or later) server that receives a request from a 1.0 (or
earlier) client MUST NOT transmit the _100 Continue_ response; it SHOULD
either wait for the request to be completed normally (thus avoiding an
interrupted request) or close the connection prematurely.

8.5 PUT
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version
of the one residing on the origin server. If the Request-URI does not
point to an existing resource, and that URI is capable of being defined
as a new resource by the requesting user agent, the origin server can
create the resource with that URI. If a new resource is created, the
origin server must MUST inform the user agent via the 201 (created) response.
If an existing resource is modified, either the 200 (ok) or 204 (no
content) response codes
should SHOULD be sent to indicate successful completion
of the request. If the resource could not be created or modified with
the Request-URI, an appropriate error response should SHOULD be given that
reflects the nature of the problem.

If the request passes through a cache and the Request-URI identifies a
currently cached entity, that entity must MUST be removed from the cache.
Responses to this method are not cachable.

The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a POST
request identifies the resource that will handle the enclosed entity as
an appendage. That resource may be a data-accepting process, a gateway
to some other protocol, or a separate entity that accepts annotations.
In contrast, the URI in a PUT request identifies the entity enclosed
with the request -- the user agent knows what URI is intended and the
server must not MUST NOT attempt to apply the request to some other resource. If
the server desires that the request be applied to a different URI, it must
MUST send a 301 (moved permanently) response; the user agent may MAY then
make its own decision regarding whether or not to redirect the request.

A single resource may MAY be identified by many different URIs. For example,
an article may have a URI for identifying "the _the current
version" version_ which is
separate from the URI identifying each particular version. In this case,
a PUT request on a general URI may result in several other URIs being
defined by the origin server. The user
agent should be informed of these URIs via one or more URI

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

For compatibility with HTTP/1.0 applications, all PUT requests MUST
include a valid Content-Length header
fields in field unless the response. server is known
to be HTTP/1.1 allows for compliant. When sending a two-phase process to occur in accepting and
processing a PUT request. An HTTP/1.1 client must pause between
sending the message header fields (including the empty line
signifying the end of the headers) and sending the message body;
the duration of the pause is five (5) seconds or until a response
is received from the server, whichever is shorter. If no response
is received during the pause period, or if the initial response is
100 (continue), the client may continue sending the PUT request. If
the response indicates an error, the client must discontinue the
request and close the connection with the server after reading the
response.

Upon receipt of a PUT request, the server must examine the header
fields and determine whether or not the client should continue its
request. If any of the header fields indicate the request is
insufficient or unacceptable to the server (i.e., will result in a
4xx or 5xx response), or if the server can determine the response
without reading the entity body (e.g., a 301 or 302 response due to
an old Request-URI), the server must send that response immediately
upon its determination. If, on the other hand, the request appears
(at least initially) to be acceptable and the client has indicated
HTTP/1.1 compliance, the server must transmit an interim 100
response message after receiving the empty line terminating the
request headers and continue processing the request. After
processing has finished, a final response message must be sent to
indicate the actual result of the request. A 100 response should
not be sent in response to an HTTP/1.0 request except under
experimental conditions, since an HTTP/1.0 client may mistake the
100 response for the final response.

For compatibility with HTTP/1.0 applications, all PUT requests must
include a valid Content-Length header field unless the server is
known to be HTTP/1.1 compliant. When sending a PUT request PUT request to an HTTP/1.1
server, a client must MUST use at least one of: a valid
Content-Length, a multipart Content-Type, Content-Length or the "chunked" _chunked_
Transfer-Encoding. The server should SHOULD respond with a 400 (bad request)
message if it cannot determine the length of the request message's
content, or with 411 (length required) if it wishes to insist on
receiving a valid Content-Length.

The client can create or modify relationships between the enclosed
entity and other existing resources by including Link header
fields, as described in Section 10.26. As with POST, the server may
use the Link information to perform other operations as a result of
the request. However, no mandatory operation is imposed on the
origin server. The origin server may generate its own or additional
links to other resources.

The actual method for determining how the resource is placed, and what
happens to its predecessor, is defined entirely by the origin server. If version control is implemented by the origin server,
then Link relationships should be defined by the server to help
identify and control revisions to a resource. If
the entity being PUT was derived from an existing resource which
included a Content-Version header field, the new entity must MUST include a
Derived-From header field corresponding to the value of the original
Content-Version header field. Multiple Derived-From values may be
included if the entity was derived from multiple resources with Content-Version Content-
Version information. Applications are encouraged to use these fields for
constructing versioning relationships and resolving version conflicts.

8.6 PATCH

The PATCH method is similar to

PUT except that requests must obey the entity contains
a list of differences between transmission requirements set out in
section 8.4.1.

8.9 DELETE
The DELETE method requests that the original version of origin server delete the resource
identified by the Request-URI and Request-URI. This method MAY be overridden by human
intervention (or other means) on the desired content of origin server. The client cannot be
guaranteed that the
resource after operation has been carried out, even if the status
code returned from the origin server indicates that the PATCH action has been applied. The list of
differences is in a format defined by
completed successfully. However, the media type of server SHOULD not indicate success
unless, at the entity
(e.g., "application/diff") and must include sufficient information
to allow time the server response is given, it intends to recreate delete the changes necessary
resource or move it to convert an inaccessible location.

A successful response SHOULD be 200 (OK) if the original version of response includes an
entity describing the resource to status, 202 (accepted) if the desired version. action has not yet
been enacted, or 204 (no content) if the response is OK but does not
include an entity.

If the request passes through a cache and the Request-URI identifies a
currently cached entity, that entity must MUST be removed from the cache.
Responses to this method are not cachable.

HTTP/1.1 allows for a two-phase process

8.12 TRACE
The TRACE method is used to occur in accepting and
processing invoke a PATCH request. An HTTP/1.1 client must pause between
sending the message header fields (including the empty line
signifying remote, application-layer loop back
of the end request message. The final recipient of the headers) and sending request SHOULD
reflect the message body; received back to the duration of client as the pause is five (5) seconds or until entity body of a response
is received from the server, whichever is shorter. If no response
200 (OK) response. The final recipient is received during either the pause period, origin server or if the initial response is
100 (continue), the client may continue sending
the PATCH request.
If first proxy or gateway to receive a Max-Forwards value of zero (0)
in the response indicates request (see Section 10.45). A TRACE request MUST NOT include an error,

entity body and MUST include a Content-Length header field with a value
of zero (0).

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

TRACE allows the client must discontinue to see what is being received at the other end
of the request chain and close the connection with the server after reading use that data for testing or diagnostic
information. The value of the
response.

Upon receipt Via header field (Section 10.20) is of

particular interest, since it acts as a PATCH request, trace of the server must examine request chain. Use
of the Max-Forwards header
fields and determine whether or not field allows the client should continue its
request. If any of to limit the header fields indicate length
of the request chain, which is
insufficient or unacceptable to useful for testing a chain of proxies
forwarding messages in an infinite loop.

If successful, the server (i.e., will result response SHOULD contain the entire request message in
the entity body, with a
4xx or 5xx response), Content-Type of _message/http_,
_application/http_, or if the server _text/plain_. Responses to this method MUST NOT
be cached.

9. Status Code Definitions
Each Status-Code is described below, including a description of which
method(s) it can determine follow and any metainformation required in the response
without reading
response.

9.1 Informational 1xx
This class of status code indicates a provisional response, consisting
only of the entity body (e.g., 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 a 301 or 302 1xx response due to an old Request-URI), HTTP/1.0 client except under
experimental conditions.

100 Continue
The client may continue with its request. This interim response is used
to inform the server must send client that response immediately
upon its determination. If, on the other hand, initial part of the request appears
(at least initially) to be acceptable has been
received and the client has indicated
HTTP/1.1 compliance, not yet been rejected by the server must transmit an interim 100
response message after receiving server. The client SHOULD
continue by sending the empty line terminating remainder of the request headers and continue processing or, if the request. After
processing request has finished,
already been completed, ignore this response. The server MUST send a
final response message must be sent to
indicate the actual result of after the request. A 100 response should
not be sent in response to an HTTP/1.0 request except under
experimental conditions, since an HTTP/1.0 client may mistake has been completed.

101 Switching Protocols
The server understands and is willing to comply with the
100 response for client's
request, via the final response.

For compatibility with HTTP/1.0 applications, all PATCH requests
must include a valid Content-Length Upgrade message header field unless the server
is known to be HTTP/1.1 compliant. When sending a PATCH request to
an HTTP/1.1 server, a client must use at least one of: a valid
Content-Length, (Section 10.41), for a multipart Content-Type, or

change in the "chunked"
Transfer-Encoding. application protocol being used on this connection. The
server should respond with a 400 (bad
request) message if it cannot determine will switch protocols to those defined by the length of response's Upgrade
header field immediately after the request
message's content, or with 411 (length required) if empty line which terminates the 101
response.

The protocol should only be switched when it wishes is advantageous to do so.
For example, switching to
insist on receiving a valid Content-Length.

The client can create or modify relationships between the new
resource newer version of HTTP is advantageous over
older versions, and other existing resources by including Link header
fields, as described in Section 10.26. As with POST, the server switching to a real-time, synchronous protocol may
be advantageous when delivering resources that use such features.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

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

200 OK
The request has succeeded. The information to perform other operations as a result of returned with the request. However, no mandatory operation response is imposed
dependent on the
origin server. The origin server may generate its own or additional
links to other resources.

The actual method for determining how used in the patched resource is
placed, and what happens request, as follows:

GET
an entity corresponding to its predecessor, is defined entirely by the origin server. If version control requested resource is implemented by sent in the origin
server, then Link relationships should be defined by
response;

HEAD
the server to
help identify response MUST only contain the header information and control revisions to a resource. If no Entity-
Body;

POST
an entity describing or containing the original
version result of the resource being patched included a Content-Version
header field, action;

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

otherwise,
an entity must describing the result of the action;
If the entity corresponds to a resource, the response MAY include a Derived-From
Content-Location header field corresponding to giving the value actual location of the original Content-Version
header field. Applications are encouraged to use these fields that
specific resource for
constructing versioning relationships later reference.

201 Created
The request has been fulfilled and resolving version
conflicts.

8.7 COPY resulted in a new resource being
created. The COPY method requests that the newly created resource identified by the
Request-URI can be copied to referenced by the location(s) given URI(s)
returned in the URI header
field entity of the request. Responses to this method are not cachable.

8.8 MOVE

The MOVE method requests that response, with the most specific URL for
the resource identified given by a Location header field. The origin server SHOULD
create the
Request-URI resource before using this Status-Code. If the action cannot
be moved to carried out immediately, the location(s) given server MUST include in the URI header
field response body
a description of when the request. This method is equivalent to resource will be available; otherwise, the
server SHOULD respond with 202 (accepted).

202 Accepted
The request has been accepted for processing, but the processing has not
been completed. The request MAY or MAY NOT eventually be acted upon, as
it MAY be disallowed when processing actually takes place. There is no
facility for re-sending a COPY
immediately followed by status code from an asynchronous operation
such as this.

The 202 response is intentionally non-committal. Its purpose is to allow
a DELETE, but enables both server to occur within accept a single transaction.

If the request passes through for some other process (perhaps a cache 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
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

completed. The entity returned with this response SHOULD include an
indication of the Request-URI
identifies request's current status and either a currently cached entity, that entity must be removed
from pointer to a
status monitor or some estimate of when the cache. Responses user can expect the request
to this method are not cachable.

8.9 DELETE be fulfilled.

203 Non-Authoritative Information
The DELETE method requests that returned metainformation in the Entity-Header is not the definitive
set as available from the origin server delete server, but is gathered from a local or
a third-party copy. The set presented MAY be a subset or superset of the
original version. For example, including local annotation information
about the resource identified by MAY result in a superset of the Request-URI. This method may be
overridden metainformation known
by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been
carried out, even if the status Use of this response code returned from is not required and is
only appropriate when the origin response would otherwise be 200 (OK).

204 No Content
The server indicates that the action has been completed successfully.
However, the server should not indicate success unless, at the time fulfilled the response request but there is given, it intends no new information to delete
send back. If the resource or move client is a user agent, it SHOULD not change its
document view from that which caused the request to an inaccessible location.

A successful response should be 200 (ok) if generated. This
response is primarily intended to allow input for actions to take place
without causing a change to the user agent's active document view. The
response includes
an MAY include new metainformation in the form of entity describing headers,
which SHOULD apply to the status, 202 (accepted) if document currently in the action has
not yet been enacted, or user agent's active
view.

The 204 (no content) if the response is OK but
does MUST not include an entity.

If the request passes through a cache entity body, and thus is always
terminated by the Request-URI
identifies a currently cached entity, that entity must be removed
from first empty line after the cache. Responses to this method are not cachable.

8.10 LINK header fields.

205 Reset Content
The LINK method establishes one or more Link relationships between
the existing resource identified by server has fulfilled the Request-URI and other
existing resources. The difference between LINK request and other methods
allowing links the user agent SHOULD reset the
document view which caused the request to be established between resources generated. This response is that the LINK
method does not
primarily intended to allow any Entity-Body input for actions to be sent in take place via user
input, followed by a clearing of the request and
does not directly result form in which the creation input is given so
that the user can easily initiate another input action. The response
MUST include a Content-Length with a value of new resources.

If zero (0) and no entity
body.

206 Partial Content
The server has fulfilled the partial GET request for the resource. The
request passes through MUST have included a cache and Range header field (Section 10.33)

indicating the Request-URI
identifies desired range. The response MUST include a currently cached entity, that entity must be removed
from Content-Range
header field (Section 10.14) indicating the cache. Responses to range included with this method are not cachable.

8.11 UNLINK

The UNLINK method removes one or more Link relationships from

response. All entity header fields in the
existing resource identified by response MUST describe the Request-URI. These
relationships may
partial entity transmitted rather than what would have been established using transmitted
in a full response. In particular, the LINK method or by
any other method supporting Content-Length header field in
the Link header. The removal response MUST match the actual number of a link
to a resource does not imply OCTETs transmitted in the
entity body. It is assumed that the resource ceases to exist or
becomes inaccessible for future references.

If client already has the request passes through a cache complete
entity's header field data.

Fielding, Frystyk, Berners-Lee, Gettys, and the Request-URI
identifies a currently cached entity, Mogul [Page 57]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

207 Range Out Of Bounds
The server has determined that entity must be removed
from the cache. Responses to this method requested range(s) are not cachable.

8.12 TRACE

The TRACE method requests that the server identified by present in
the
Request-URI reflect whatever requested resource, and so there is received back no content to return. This
status code should be handled by the client as the
entity body of the response. In this way, the client can see what same as 204 No Content.

This could be a compatibility problem if there is being received at the other end of the request chain, and may
use this data for testing or diagnostic information. an installed
base. If successful, the response should contain the entire, unedited
request message in the entity body, with a Content-Type of
"message/http", "application/http", or "text/plain". Responses to treating this method are not cachable.

8.13 WRAPPED

The WRAPPED method allows a client status code as the generic 2xx code by
such implementations would lead to send one or more encapsulated
requests an error, it will have to the server identified be
replace by the Request-URI. 204.

9.3 Redirection 3xx
This method
is intended to allow the request(s) class of status code indicates that further action needs to be wrapped together,
possibly encrypted
taken by the user agent in order to improve the security and/or privacy
of fulfill the request, and delivered for unwrapping request. The action
required MAY be carried out by the destination
server. Upon receipt of the WRAPPED request, the destination server
must unwrap the message and feed it to user agent without interaction with
the appropriate protocol
handler as user if it were an incoming request stream.

Responses to this method are not cachable. Applications should not
use this method for making requests that would normally be public and cachable.

The request entity must include at least one encapsulated message,
with the media type identifying the protocol of that message. For
example, only if the wrapped request is another HTTP request message,
then method used in the media type must be either "message/http" (for a single
message) second request is GET or "application/http" (for
HEAD. A user agent SHOULD NOT automatically redirect a request stream containing one
or more requests), with any codings identied than
5 times, since such redirections usually indicate an infinite loop.

300 Multiple Choices
This status code is reserved for future use by the
Content-Encoding and Transfer-Encoding header fields. a planned content
negotiation mechanism. HTTP/1.1 allows for user agents receiving a two-phase process to occur in accepting and
processing 300 response
which includes a WRAPPED request. An HTTP/1.1 client must pause between
sending the message Location header fields (including field can treat this response as they
would treat a 303 (See Other) response. If no Location header field is
included, the empty line
signifying appropriate action is to display the end of entity enclosed in
the headers) response to the user.

301 Moved Permanently
The requested resource has been assigned a new permanent URI and sending any
future references to this resource SHOULD be done using one of the message body;
returned URIs. Clients with link editing capabilities SHOULD
automatically re-link references to the duration Request-URI to one or more of
the pause is five (5) seconds or until a response
is received from new references returned by the server, whichever where possible. This response
is shorter. cachable unless indicated otherwise.

If no response the new URI is received during a location, its URL MUST be given by the pause period, or if Location
field in the initial response is
100 (continue), response. Unless it was a HEAD request, the client may continue sending Entity-Body of
the WRAPPED
request. response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).

If the 301 status code is received in response indicates an error, to a request other than
GET or HEAD, the client must
discontinue user agent MUST NOT automatically redirect the request and close
unless it can be confirmed by the connection with user, since this might change the server
after reading
conditions under which the response.

Upon receipt of request was issued.

Note: When automatically redirecting a WRAPPED request, the server must examine the
header fields POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.

302 Moved Temporarily

Fielding, Frystyk, Berners-Lee, Gettys, and determine whether or not Mogul [Page 58]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The requested resource resides temporarily under a different URI. Since
the redirection MAY be altered on occasion, the client should SHOULD continue its request. If any of
to use the Request-URI for future requests. This response is only
cachable if indicated by a Cache-Control or Expires header fields indicate field.

If the
request new URI is insufficient or unacceptable to a location, its URL MUST be given by the server (i.e., will
result Location
field in the response. Unless it was a 4xx or 5xx response), or if HEAD request, the server can determine Entity-Body of
the response without reading the entity body (e.g., SHOULD contain a 301 or 302
response due short hypertext note with a hyperlink to an old Request-URI),
the server must send that
response immediately upon its determination. If, on new URI(s).

If the 302 status code is received in response to a request other hand, than
GET or HEAD, the user agent MUST NOT automatically redirect the request appears (at least initially) to
unless it can be acceptable and the
client has indicated HTTP/1.1 compliance, confirmed by the server must transmit
an interim 100 response message after receiving user, since this might change the empty line
terminating
conditions under which the request headers and continue processing the
request. After processing has finished, a final was issued.

303 See Other
The response message
must be sent to indicate the actual result of the request. A 100
response should not be sent in response to an HTTP/1.0 request
except can be found under experimental conditions, since an HTTP/1.0 client may
mistake the 100 response for the final response.

For compatibility with HTTP/1.0 applications, all WRAPPED requests
must include a valid Content-Length header field unless the server
is known to different URI and
SHOULD be HTTP/1.1 compliant. When sending retrieved using a WRAPPED request GET method on that resource. This method
exists primarily to an HTTP/1.1 server, allow the output of a client must use at least one of: POST-activated script to
redirect the user agent to a valid
Content-Length, selected resource. The new resource is not
a multipart Content-Type, or update reference for the "chunked"
Transfer-Encoding. original Request-URI. The server should respond with a 400 (bad
request) message if it cannot determine 303 response is not
cachable, but the length of response to the second request
message's content, or with 411 (length required) if it wishes to
insist on receiving a valid Content-Length.

9. Status Code Definitions

Each Status-Code MAY be cachable.

If the new URI is described below, including a description of
which method(s) it can follow and any metainformation required location, its URL MUST be given by the Location
field in the response.

9.1 Informational 1xx

This class of status code indicates Unless it was a provisional response,
consisting only HEAD request, the Entity-Body 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 should not send a 1xx response SHOULD contain a short hypertext note with a hyperlink to an
the new URI(s).

Note: When automatically redirecting a POST request after
receiving a 302 status code, some existing HTTP/1.0
client except under experimental conditions.

100 Continue

The client may continue with its user agents
will erroneously change it into a GET request. This interim response is
used to inform

304 Not Modified
If the client that the initial part of the request has
been received performed a conditional GET request and access is
allowed, but the document has not yet been rejected by the server. The
client should continue by sending modified since the remainder of date and time
specified in the request or,
if If-Modified-Since field, the request has already been completed, ignore this response.
The server must MUST respond with
this status code and not send a final response after an Entity-Body to the request has been
completed.

101 Switching Protocols

The server understands and client. Header
fields contained in the response SHOULD only include information which
is willing relevant to comply with the client's
request, via cache managers or which MAY have changed independently of
the Upgrade message entity's Last-Modified date. Examples of relevant header fields
include: Date, Server, Content-Length, Content-MD5, Content-Version,
Cache-Control and Expires.

A cache SHOULD update its cached entity to reflect any new field (Section 10.41), for
a change values
given in the application protocol being used on this connection.
The server will switch protocols to those defined by 304 response. If the response's
Upgrade header new field immediately after values indicate that the empty line which
terminates
cached entity differs from the 101 response.

The protocol should only current resource (as would be switched when it is advantageous to do
so. For example, switching to indicated
by a newer version of HTTP is
advantageous over older versions, change in Content-Length, Content-MD5, or Content-Version), then
the cache MUST disregard the 304 response and switching to a real-time,
synchronous protocol may be advantageous when delivering resources
that use such features.

9.2 Successful 2xx

This class of status code indicates that repeat the client's request was
successfully received, understood, without
an If-Modified-Since field.

Fielding, Frystyk, Berners-Lee, Gettys, and accepted.

200 OK

The request has succeeded. Mogul [Page 59]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The information returned with the 304 response is dependent on the method used in the request, as follows:

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

305 Use Proxy
The requested resource MUST be accessed through the proxy given by the
Location field in the response. In other words, this is sent a proxy
redirect.

9.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the response;

HEAD client
seems to have erred. If the response must only contain client has not completed the header information and
no Entity-Body;

POST an entity describing or containing request when a
4xx code is received, it SHOULD immediately cease sending data to the result of
server. Except when responding to a HEAD request, the action;

TRACE server SHOULD
include an entity containing an explanation of the error situation, and
whether it is a temporary or permanent condition. These status codes are
applicable to any request message as received by method.

Note: If the
end server;

otherwise, an entity describing client is sending data, server implementations on
TCP SHOULD be careful to ensure that the result client acknowledges
receipt of the action; packet(s) containing the response prior to
closing the input connection. If the entity corresponds client continues sending
data to the server after the close, the server's controller will
send a resource, reset packet to the response client, which may include a
Location header field giving erase the actual location of that specific
resource for later reference.

201 Created

The request has been fulfilled client's
unacknowledged input buffers before they can be read and resulted in a new resource being
created.
interpreted by the HTTP application.

400 Bad Request
The newly created resource can request could not be referenced understood by the URI(s)
returned in server due to malformed
syntax. The client SHOULD not repeat the URI-header request without modifications.

401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field and/or (Section 10.44) containing a challenge

applicable to the entity of requested resource. The client MAY repeat the response, request
with the most specific URL for the resource given by a Location suitable Authorization header field. The origin server should create the resource before
using this Status-Code. field (Section 10.6). If the action cannot be carried out
immediately, the server must include in

request already included Authorization credentials, then the 401
response body a
description of when the resource will be available; otherwise, the
server should respond with 202 (accepted).

202 Accepted

The request indicates that authorization has been accepted refused for processing, but those
credentials. If the processing
has not been completed. The request may or may not eventually be
acted upon, 401 response contains the same challenge as it may the
prior response, and the user agent has already attempted authentication
at least once, then the user SHOULD be disallowed when processing actually takes
place. There is no facility for re-sending a status presented the entity that was
given in the response, since that entity MAY include relevant diagnostic
information. HTTP access authentication is explained in Section 11.

402 Payment Required
This code from an
asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose reserved for future use.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

403 Forbidden
The server understood the request, but is refusing to
allow a fulfill it.
Authorization will not help and the request SHOULD not be repeated. If
the request method was not HEAD and the server wishes to accept a make public why
the request has not been fulfilled, it SHOULD describe the reason 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 refusal in the entity body. This status code is commonly used when
the server persist
until does not wish to reveal exactly why the process request has been
refused, or when no other response is completed. applicable.

404 Not Found
The entity returned with this
response should include an server has not found anything matching the Request-URI. No
indication is given of whether the request's current
status and either a pointer to a status monitor condition is temporary or some estimate of
when the user can expect permanent.
If the request server does not wish to make this information available to the
client, the status code 403 (forbidden) can be fulfilled.

203 Non-Authoritative Information used instead. The returned metainformation 410
(gone) status code SHOULD be used if the server knows, through some
internally configurable mechanism, that an old resource is permanently
unavailable and has no forwarding address.

405 Method Not Allowed
The method specified in the Entity-Header Request-Line is not allowed for the
definitive set as available from resource
identified by the origin server, but is gathered
from a local or a third-party copy. Request-URI. The set presented may be response MUST include an Allow header
containing a
subset or superset list of valid methods for the original version. For example, including
local annotation information about the requested resource.

406 Not Acceptable
The resource may result in a
superset of the metainformation known identified by the origin server. Use request is only capable of
this generating
response code is entities which have content characteristics not required and is only appropriate when acceptable
according to the
response would otherwise be 200 (ok).

204 No Content

The server has fulfilled accept headers sent in the request but there is no new
information request.

HTTP/1.1 servers are allowed to send back. If the client is a user agent, it should
not change its document view from that return responses which caused the request are not
acceptable according to the accept headers sent in the request. In some
cases, this may even be generated. This response is primarily intended to allow input
for actions to take place without causing preferable over sending a change 406 response. User
agents are encouraged to inspect the user
agent's active document view. The response may include new
metainformation in the form headers of entity headers, which should apply an incoming response to
determine if it is acceptable. If the document currently in the user agent's active view.

The 204 response must not include an entity body, and thus is
always ternminated by not acceptable, user
agents SHOULD interrupt the first empty line after receipt of the header fields.

205 Reset Content

The server has fulfilled the request and the user agent should
reset the document view which caused the request to be generated.
This response if doing so would
save network resources. If it is primarily intended to allow input for actions to
take place via user input, followed by unknown whether an incoming response
would be acceptable, a clearing user agent SHOULD temporarily stop receipt of
more data and query the form in
which the input user for a decision on further

actions.

407 Proxy Authentication Required
This code is given so similar to 401 (unauthorized), but indicates that the user can easily initiate
another input action.
client MUST first authenticate itself with the proxy. The response must include proxy MUST
return a Content-Length
with Proxy-Authenticate header field (Section 10.30) containing a value of zero (0) and no entity body.

206 Partial Content

The server has fulfilled

challenge applicable to the partial GET request proxy for the requested resource. The client
MAY repeat the request must have included with a Range suitable Proxy-Authorization header field
(Section 10.33)
indicating the desired range. 10.31). HTTP access authentication is explained in Section 11.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

408 Request Timeout
The response must include client did not produce a
Content-Range header field (Section 10.14) indicating request within the range
included with this response. All entity header fields in time that the
response must describe server was
prepared to wait. The client MAY repeat the actual entity transmitted rather than
what would have been transmitted in request without
modifications at any later time.

409 Conflict
The request could not be completed due to a full response. In particular,
the Content-Length header field in the response must match conflict with the
actual number current
state of OCTETs transmitted in the entity body. It is
assumed that the client already has the complete entity's header
field data.

9.3 Redirection 3xx resource. This class of status code indicates is only allowed in situations where it
is expected that further action needs to be
taken by the user agent in order MAY be able to fulfill resolve the conflict and
resubmit the request. The action
required may be carried out by response body SHOULD include enough
information for the user agent without interaction
with to recognize the user if and only if source of the method used in conflict.
Ideally, the response entity would include enough information for the second request
is GET or HEAD. A
user agent should never automatically redirect a
request more than 5 times, since such redirections usually indicate
an infinite loop.

300 Multiple Choices

The requested resource is available at one or more locations and a
preferred location could user-agent to fix the problem; however, that MAY not be determined via preemptive content
negotiation (Section 12). Unless it was possible
and is not required.

Conflicts are most likely to occur in response to a HEAD request, PUT request. If
versioning is being used and the
response should include an entity containing being PUT includes changes to a list of
resource
characteristics and locations from which the user or user agent can
choose the one most appropriate. The entity format is specified conflict with those made by an earlier (third-party)
request, the media type given in the Content-Type header field. Depending
upon server MAY use the format and 409 response to indicate that it can't
complete the capabilities of request. In this case, the user agent, selection response entity SHOULD contain a
list of the most appropriate choice may be performed automatically. If
the server has a preferred choice, it should include differences between the URL two versions in a
Location field; user agents not capable of complex selection may
use this field value for automatic redirection. This format defined by
the response is
cachable unless indicated otherwise.

301 Moved Permanently Content-Type.

410 Gone
The requested resource has been assigned a new permanent URI is no longer available at the server and
any future references to this resource should no
forwarding address is known. This condition SHOULD be done using one of
the returned URIs. considered
permanent. Clients with link editing capabilities should
automatically relink SHOULD delete
references to the Request-URI after user approval. If the server does
not know, or has no facility to one determine, whether or more
of not the new references returned by condition
is permanent, the server, where possible. status code 404 (not found) SHOULD be used instead.
This response is cachable unless indicated otherwise.

If the new URI

The 410 response is a single location, its URL must be given by primarily intended to assist the
Location field in task of web
maintenance by notifying the response. If more than one URI exists for recipient that the
resource, resource is
intentionally unavailable and that the primary URL should server owners desire that remote
links to that resource be given in the Location field removed. Such an event is common for limited-
time, promotional services and
the other URIs given in one or more URI-header fields. Unless it
was a HEAD request, the Entity-Body of the response should contain
a short hypertext note with a hyperlink for resources belonging to individuals no
longer working at the new URI(s).

If the 301 status code server's site. It is received in response not necessary to a request other
than GET mark all
permanently unavailable resources as _gone_ or HEAD, the user agent must not automatically redirect to keep the request unless it can be confirmed by mark for any
length of time -- that is left to the user, since this
might change discretion of the conditions under which server owner.

411 Length Required
The server refuses to accept the request was issued.

302 Moved Temporarily

The requested resource resides temporarily under without a different URI.
Since the redirection may be altered on occasion, the defined Content-
Length. The client should
continue to use MAY repeat the Request-URI for future requests. This response
is only cachable request if indicated by it adds a Cache-Control or Expires valid Content-
Length header
field.

If the new URI is a single location, its URL must be given by the
Location field in the response. If more than one URI exists for containing the
resource, length of the primary URL should be given entity body in the Location field and
the other URIs
request message.

412 Precondition Failed
The precondition given in one or more URI-header fields. Unless of the request header fields
evaluated to false when it was a HEAD request, the Entity-Body of tested on the server. This response should contain
a short hypertext note with a hyperlink code
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

allows the client to place preconditions on the new URI(s).

If current resource
metainformation (header field data) and thus prevent the 302 status code is received in response requested
method from being applied to a request resource other than GET or HEAD, the user agent must not automatically redirect the one intended.

413 Request Entity Too Large
The server is refusing to process a request unless because it can be confirmed by considers the user, since
request entity to be larger than it is willing or able to process. The
server SHOULD close the connection if that is necessary to prevent the
client from continuing the request.

If the client manages to read the 413 response, it MUST honor it and
SHOULD reflect it to the user.

If this
might change restriction is considered temporary, the conditions under which server MAY include a
Retry-After header field to indicate that it is temporary and after what
time the request was issued.

303 See Other client MAY try again.

414 Request-URI Too Large
The response server is refusing to service the request can be found under because the Request-URI is
longer than the server is willing to interpret. This rare condition is
only likely to occur when a different URI and
should be retrieved using client has improperly converted a GET method on that resource. This
method exists primarily POST
request to allow a GET request with long query information, when the output client
has descended into a URL _black hole_ of redirection (e.g., a POST-activated
script to redirect the user agent redirected
URL prefix that points to a selected resource. The new
resource suffix of itself), or when the server is not
under attack by a replacement reference client attempting to exploit security holes present in
some servers using fixed-length buffers for reading or manipulating the original
Request-URI.

415 Unsupported Media Type
The 303 response server is not cachable, but the response refusing to service the second request may be cachable.

If because the new URI entity body of
the request is in a single location, its URL must be given format not supported by the
Location field in requested resource for
the requested method.

416 None Acceptable
This status code is reserved for future use by a planned content
negotiation mechanism. HTTP/1.1 user agents receiving a 416 response
which includes a Location header can treat this response as they would
treat a 303 (See Other) response. If more than one URI exists for no Location header is included, the
resource,
appropriate action is to display the primary URL should be given entity enclosed in the Location field and response to
the other URIs given user.

9.5 Server Error 5xx
Response status codes beginning with the digit _5_ indicate cases in one or more URI-header fields. Unless it
was a HEAD request,
which the Entity-Body server is aware that it has erred or is incapable of
performing the response should contain
a short hypertext note with a hyperlink to the new URI(s).

304 Not Modified request. If the client has performed a conditional GET not completed the request when
Fielding, Frystyk, Berners-Lee, Gettys, and access Mogul [Page 63]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

a 5xx code is
allowed, but received, it SHOULD immediately cease sending data to the document has not been modified since
server. Except when responding to a HEAD request, the date and
time specified in server SHOULD
include an entity containing an explanation of the If-Modified-Since field, error situation, and
whether it is a temporary or permanent condition. These response codes
are applicable to any request method and there are no required header
fields.

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

501 Not Implemented
The server must
respond with this status code and does not send an Entity-Body support the functionality required to fulfill the
client. Header fields contained in
request. This is the appropriate response should only include
information which when the server does not
recognize the request method and is relevant to cache managers or which may have
changed independently not capable of the entity's Last-Modified date. Examples
of relevant header fields include: Date, Server, Content-Length,
Content-MD5, Content-Version, Cache-Control and Expires.

A cache should update its cached entity to reflect supporting it for any new field
values given in the 304 response. If the new field values indicate
that the cached entity differs from the current resource (as would
be indicated by
resource.

502 Bad Gateway
The server, while acting as a change in Content-Length, Content-MD5, gateway or
Content-Version), then the cache must disregard the 304 proxy, received an invalid
response
and repeat from the request without an If-Modified-Since field. upstream server it accessed in attempting to fulfill
the request.

503 Service Unavailable
The 304 response must not include an entity body, and thus server is
always ternminated by currently unable to handle the first empty line after request due to a temporary
overloading or maintenance of the header fields.

305 Use Proxy server. The requested resource must implication is that this
is a temporary condition which will be accessed through alleviated after some delay. If
known, the proxy given by length of the Location field delay MAY be indicated in the response. In other words, this a Retry-After header.
If no Retry-After is given, the client SHOULD handle the response as it
would for a proxy
redirect.

9.4 Client Error 4xx 500 response.

Note: The 4xx class existence of the 503 status code is intended for cases in which the
client seems does not imply that a
server must use it when becoming overloaded. Some servers MAY
wish to have erred. If simply refuse the client has connection.

504 Gateway Timeout
The server, while acting as a gateway or proxy, did not completed the
request when receive a 4xx code is received, timely
response from the upstream server it should immediately cease
sending data accessed in attempting to complete
the server. Except when responding request.

505 HTTP Version Not Supported
The server does not support, or refuses to a HEAD
request, support, the server should include an entity containing an
explanation of HTTP protocol
version that was used in the error situation, and whether request message. The server is indicating
that it is a temporary unable or permanent condition. These status codes are applicable unwilling to any complete the request method.

Note: If using the client same
major version as the client, as described in Section 3.1, other than

with this error message. The response SHOULD contain an entity
describing why that version is sending data, server implementations
on TCP should be careful to ensure not supported and what other protocols
are supported by that server.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

10. Header Field Definitions
This section defines the client
acknowledges receipt syntax and semantics of the packet(s) containing the
response prior all standard HTTP/1.1
header fields. For Entity-Header fields, both sender and recipient refer
to closing the input connection. If either the client continues sending data to the server after or the close, server, depending on who sends and who
receives the server's controller will send a reset packet entity.

10.1 Accept
The Accept request-header field can be used to the
client, specify certain media
types which may erase are acceptable for the client's unacknowledged input
buffers before they response. Accept headers can be read and interpreted by the HTTP
application.

400 Bad Request

The request could not be understood by the server due used
to malformed
syntax. The client should not repeat indicate that the request without
modifications.

401 Unauthorized

The request requires user authentication. The response must include
a WWW-Authenticate header field (Section 10.44) containing a
challenge applicable is specifically limited to the requested resource. The client may
repeat the request with a suitable Authorization header field
(Section 10.6). If small set of
desired types, as in the case of a request already included Authorization
credentials, then the 401 response indicates that authorization has
been refused for those credentials. If an in-line image.

The field MAY be folded onto several lines and more than one occurrence
of the 401 response contains field is allowed, with the semantics being the same challenge as if all the prior response,
entries had been in one field value.

Accept = "Accept" ":" #(
media-range
[ ( ":" | ";" )

range-parameter

*( ";" range-parameter ) ]

| extension-token )

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

range-parameter = ( "q" "=" qvalue )
| extension-range-parameter

extension-range-parameter = ( token "=" token )

extension-token = token

The asterisk _*_ character is used to group media types into ranges,
with _*/*_ indicating all media types and _type/*_ indicating all
subtypes of that type. The range-parameter q is used to indicate the user agent has
already attempted authentication at least once, then the user
should be presented
media type quality factor for the entity that was given in range, which represents the response,
since that entity may include relevant diagnostic information. HTTP
access authentication is explained in Section 11.

402 Payment Required

This code is reserved user's
preference for future use.

403 Forbidden that range of media types. The server understood default value is q=1. In
Accept headers generated by HTTP/1.1 clients, the request, character separating
media-ranges from range-parameters SHOULD be a _:_. HTTP/1.1 servers
SHOULD be tolerant of use of the _;_ separator by HTTP/1.0 clients.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Accept: audio/*: q=0.2, audio/basic

SHOULD be interpreted as _I prefer audio/basic, but send me any audio
type if it is refusing to fulfill it.
Authorization will not help and the request should not be repeated. best available after an 80% mark-down in quality._

If no Accept header is present, then it is assumed that the request method was not HEAD client
accepts all media types. If Accept headers are present, and if the
server wishes cannot send a response which is acceptable according to make
public why the request has not been fulfilled, it should describe the reason for
Accept headers, then the refusal in server SHOULD send an error response with the entity body. This
406 (not acceptable) status code is
commonly used when the server does not wish to reveal exactly why code, though the request has been refused, or when no other sending of an unacceptable
response is
applicable.

404 Not Found

The server has not found anything matching the Request-URI. No
indication also allowed.

A more elaborate example is given of whether

Accept: text/plain: q=0.5, text/html,
text/x-dvi: q=0.8, text/x-c

Verbally, this would be interpreted as _text/html and text/x-c are the condition is temporary or
permanent. If
preferred media types, but if they do not exist, then send the server text/x-
dvi entity, and if that does not wish to make this information
available to the client, exist, send the status code 403 (forbidden) text/plain entity._

Media ranges can be
used instead. The 410 (gone) status code should be used if the
server knows, through some internally configurable mechanism, that
an old resource is permanently unavailable and has no forwarding
address.

405 Method Not Allowed

The method specified in the Request-Line is not allowed for the
resource identified overridden by the Request-URI. The response must include
an Allow header containing a list of valid methods for the
requested resource.

406 None Acceptable

The server has found a resource matching the Request-URI, but not more specific media ranges or specific
media types. If more than one that satisfies the conditions identified by the Accept and
Accept-Encoding request headers. Unless it was a HEAD request, the
response should include an entity containing media range applies to a list of resource
characteristics and locations from which the user or user agent can
choose given type, the one
most appropriate. specific reference has precedence. For example,

Accept: text/*, text/html, text/html;level=1, */*

have the following precedence:

1) text/html;level=1
2) text/html
3) text/*
4) */*

The entity format media type quality factor associated with a given type is specified determined
by finding the media type given in range with the Content-Type header field. Depending
upon highest precedence which matches
that type. For example,

Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
*/*:q=0.5

would cause the format following values to be associated:

Fielding, Frystyk, Berners-Lee, Gettys, and the capabilities of the Mogul [Page 66]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

text/html;level=1 = 1

image/jpeg = 0.5
text/html;level=3 = 0.7

Note: A user agent, selection agent MAY be provided with a default set of quality
values for certain media ranges. However, unless the most appropriate choice may be performed automatically.

407 Proxy Authentication Required

This code user agent
is similar to 401 (unauthorized), but indicates that the
client must first authenticate itself a closed system which cannot interact with other rendering text/html = 0.7 text/plain = 0.3
agents, this default set SHOULD be configurable by the proxy. user.

10.2 Accept-Charset
The proxy
must return a Proxy-Authenticate header Accept-Charset request-header field (Section 10.30)
containing a challenge applicable can be used to the proxy indicate what
character sets are acceptable for the requested
resource. The client may repeat the request with a suitable
Proxy-Authorization header response. This field (Section 10.31). HTTP access
authentication allows
clients capable of understanding more comprehensive or special-purpose
character sets to signal that capability to a server which is explained capable of
representing documents in Section 11.

408 Request Timeout those character sets. The client did not produce a request within the time that the
server was prepared ISO-8859-1 character
set can be assumed to wait. The client may repeat the request
without modifications at any later time.

409 Conflict

The request could not be completed due acceptable to a conflict with the
current state of the resource. This code is only allowed in
situations where it is expected that the all user agents.

Accept-Charset = "Accept-Charset" ":"

1#( charset [ ";" "q" "=" qvalue ] )

Character set values are described in Section 3.4. Each charset may be able to
resolve

given an associated quality value which represents the conflict user's preference
for that charset. The default value is q=1. An example is

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

If no Accept-Charset header is present, the default is that any
character set is acceptable. If an Accept-Charset header is present, and resubmit
if the request. The server cannot send a response body
should include enough information for the user which is acceptable according to recognize
the
source of the conflict. Ideally, Accept-Charset header, then the server SHOULD send an error response entity would include
enough information for
with the user or user-agent to fix 406 (not acceptable) status code, though the problem;
however, that may not be possible and sending of an
unacceptable response is not required.

Conflicts are most likely also allowed.

10.3 Accept-Encoding
The Accept-Encoding request-header field is similar to occur Accept, but
restricts the content-coding values (Section 3.5) which are acceptable

in response to a PUT or PATCH
request. the response.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )

An example of its use is

Accept-Encoding: compress, gzip

If versioning no Accept-Encoding header is being used and the entity being PUT or
PATCHed includes changes to present in a resource which conflict with those
made by an earlier (third-party) request, the server may use the
409 response to indicate MAY
assume that it can't complete the request. In
this case, the response entity should contain a list of the
differences between the two versions in a format defined by the
response Content-Type.

410 Gone

The requested resource client will accept any content coding. If an Accept-
Encoding header is no longer available at present, and if the server and no
forwarding address cannot send a response
which is known. This condition should be considered
permanent. Clients with link editing capabilities should delete
references acceptable according to the Request-URI after user approval. If Accept-Encoding header, then the
server
does not know, or has no facility to determine, whether or not the
condition is permanent, SHOULD send an error response with the status code 404 406 (not found) should be
used instead. This response is cachable unless indicated otherwise. acceptable)
status code.

10.4 Accept-Language
The 410 response Accept-Language request-header field is primarily intended similar to assist Accept, but
restricts the task set of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to natural languages that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging
to individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources are preferred as "gone"
or a response
to keep the mark for any length request.

Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )

language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) )
| "*" )

Each language-range MAY be given an associated quality value which
represents an estimate of time -- that is left to the
discretion user's comprehension of the server owner.

411 Length Required languages
specified by that range. The server refuses quality value defaults to _q=1_ (100%
comprehension).For example,

Accept-Language: da, en-gb;q=0.8, en;q=0.7

would mean: _I prefer Danish, but will accept the request without British English (with 80%
comprehension) and other types of English(with 70% comprehension)._ A
language-range matches a defined
Content-Length. The client may repeat language-tag if it exactly equals the request tag, or
if it adds exactly equals a
valid Content-Length header field containing prefix (a sub-sequence starting at the length first
character) of the
entity body in tag such that the request message.

412 Unless True first tag character following the
prefix is _-_. The condition given special range _*_, if present in the Unless request-header field
(Section 10.40) evaluated to true when it was tested on the server
and the request did Accept-Language
field, matches every tag not include matched by any other ranges present in the
Accept-Language field.

Note: This use of a Range header field (which would
indicate prefix matching rule does not imply that
language tags are assigned to languages in such a partial GET) or an If-Modified-Since header field (which
would indicate way that it is
always true that if a conditional GET). This response code user understands a language with a certain
tag, then this user will also understand all languages with tags
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

for which this tag is a prefix. The prefix rule simply allows
the
client to place arbitrary preconditions on the current resource
metainformation (header field data) and thus prevent use of prefix tags if this is the requested
method from being applied case.

The language quality factor assigned to a resource other than language-tag by the one intended.

9.5 Server Error 5xx

Response status codes beginning with Accept-
Language field is the digit "5" indicate cases quality value of the longest language-range in which the server is aware
field that it has erred or is incapable of
performing matches the request. language-range. If no language-range in the client has not completed
field matches the request
when a 5xx code tag, the language quality factor assigned is received, it should immediately cease sending
data to 0. If no
Accept-Language header is present in the server. Except when responding to a HEAD request, the server should include an entity containing SHOULD
assume that all languages are equally acceptable. If an explanation of the
error situation, and whether it Accept-Language
header is a temporary or permanent
condition. These response codes present, then all languages which are applicable to any request
method and there assigned a quality
factor greater than 0 are no required header fields.

500 Internal Server Error

The acceptable. If the server encountered cannot generate a
response for an unexpected condition which prevented audience capable of understanding at least one
acceptable language, it
from fulfilling can send a response that uses one or more un-
accepted languages.

It may be contrary to the request.

501 Not Implemented

The server does not support privacy expectations of the functionality required user to fulfill send an
Accept-Language header with the complete linguistic preferences of the
user in every request. This For a discussion of this issue, see Section 14.7

Note: As intelligibility is highly dependent on the appropriate response when individual
user, it is recommended that client applications make the server does
not recognize choice
of linguistic preference available to the request method and user. If the choice is
not capable of supporting
it for any resource.

502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid
response from made available, then the upstream server it accessed Accept-Language header field MUST
not be given in attempting to
fulfill the request.

503 Service Unavailable

10.5 Allow
The server is currently unable to handle Allow entity-header field lists the request due to a
temporary overloading or maintenance set of methods supported by the server.
resource identified by the Request-URI. The implication
is that purpose of this field is a temporary condition which will be alleviated
after some delay. If known,
strictly to inform the length recipient of valid methods associated with the delay may
resource. An Allow header field MUST be
indicated present in a Retry-After header. If no Retry-After is given, the
client should handle the response as it would for a 500 405 (method not
allowed) response.

Note: The existence of the 503 status code does Allow header field is not imply
that permitted in a server must use it when becoming overloaded. Some
servers may wish to simply refuse request
using the connection.

504 Gateway Timeout

The server, while acting POST method, and thus SHOULD be ignored if it is received as
part of a gateway or proxy, did not receive POST entity.

Allow = "Allow" ":" 1#method

Example of use:

Allow: GET, HEAD, PUT

This field cannot prevent a
timely response client from trying other methods. However,
the upstream server it accessed in attempting
to complete the request.

10. Header Field Definitions

This section defines indications given by the syntax and semantics of all standard
HTTP/1.1 Allow header fields. For Entity-Header fields, both sender and
recipient refer to either field value SHOULD be
followed. The actual set of allowed methods is defined by the client or origin
server at the server, depending on
who sends time of each request.

Fielding, Frystyk, Berners-Lee, Gettys, and who receives the entity.

10.1 Accept Mogul [Page 69]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The Accept response-header Allow header field can MAY be used to indicate a list of
media ranges which are acceptable as provided with a response PUT request to recommend
the methods to be supported by the request. new or modified resource. The
asterisk "*" character server
is used not required to group media types into ranges,
with "*/*" indicating all media types support these methods and "type/*" indicating SHOULD include an Allow
header in the response giving the actual supported methods.

A proxy MUST not modify the Allow header field even if it does not
understand all
subtypes the methods specified, since the user agent MAY have
other means of that type. communicating with the origin server.

The set of ranges given by Allow header field does not indicate what methods are implemented at
the client should
represent server level. Servers MAY use the Public response header field
(Section 10.32) to describe what types methods are acceptable given implemented on the context of server

as a whole.

10.6 Authorization
A user agent that wishes to authenticate itself with a server--usually,
but not necessarily, after receiving a 401 response--MAY do so by
including an Authorization request-header field with the request. The Accept
Authorization field should only be used when value consists of credentials containing the request is
specifically limited to a set
authentication information of desired types, as in the case user agent for the realm of the
resource being requested.

Authorization = "Authorization" ":" credentials

HTTP access authentication is described in Section 11. If a request is

authenticated and a realm specified, the same credentials SHOULD be
valid for all other requests within this realm.

When a shared cache (see section 13.10) receives a request containing an in-line image, or
Authorization field, it MUST NOT return the corresponding response as a
reply to indicate qualitative
preferences for specific media types.

The field may be folded onto several lines and more than any other request, unless one
occurrence of the field is allowed, with following specific
exceptions holds:

1. If the semantics being response includes the
same as if all _proxy-revalidate_ Cache-Control
directive, the entries had been cache MAY use that response in one field value.

Accept = "Accept" ":" #(
media-range
[ ";" "q" "=" qvalue ]
[ ";" "mxb" "=" 1*DIGIT ] )

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

The parameter q is used replying to indicate a
subsequent request, but a proxy cache MUST first revalidate it with
the quality factor, which
represents the user's preference for that range of media types. The
parameter mxb gives origin server, using the maximum acceptable size of request headers from the Entity-Body,
in decimal number of octets, for that range of media types.
Section 12 describes new request
to allow the content negotiation algorithm which makes
use of these values. The default values are: q=1 and mxb=undefined
(i.e., infinity).

The example

Accept: audio/*; q=0.2, audio/basic

should be interpreted as "I prefer audio/basic, but send me any
audio type if it is origin server to authenticate the best available after an 80% mark-down in
quality." new request.
2. If no Accept header is present, then it is assumed that the client
accepts all media types with quality factor 1. This is equivalent
to response includes the client sending _must-revalidate_ Cache-Control
directive, the following accept header field:

Accept: */*; q=1

Accept: */*

If cache MAY use that response in replying to a single Accept header is provided and
subsequent request, but all caches MUST first revalidate it contains no field
value, then with
the server must interpret it as a origin server, using the request headers from the new request
to not
perform any preemptive content negotiation (Section 12) and instead
return a 406 (none acceptable) response if there are variants
available for allow the Request-URI.

A more elaborate example is

Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8; mxb=100000, text/x-c

Verbally, this would be interpreted as "text/html and text/x-c are origin server to authenticate the preferred media types, but if they do not exist, then send new request.
3. If the
text/x-dvi entity if it is less than 100000 bytes, otherwise send response includes the text/plain entity."

Media ranges can _public_ Cache-Control directive, it
may be overridden by more specific media ranges or
specific media types. If more than one media range applies returned in reply to a
given type, the most specific reference has precedence. For example,

Accept: text/*, text/html, text/html;version=2.0, */*

have the following precedence:

1) text/html;version=2.0
2) text/html
3) text/*
4) */* any subsequent request.

10.7 Cache-Control
The quality value associated with a given type Cache-Control general-header field is determined used to specify directives
that MUST be obeyed by
finding all caching mechanisms along the media range request/response
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

chain. The directives specify behavior intended to prevent caches from
adversely interfering with the highest precedence which matches request or response. . These directives
typically override the default caching algorithms. Cache directives are
unidirectional in that type. For example,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0,
*/*;q=0.5

would cause the following values to be associated:

text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7

It must be emphasized presence of a directive in a request does not
imply that the Accept field same directive should only be used
when it is necessary to restrict given in the response media types to response.

Cache directives must be passed through by a
subset of those possible proxy or when the user has been permitted to
specify qualitative values for ranges of media types. If no quality
factors have been set by the user, and the context gateway
application, regardless of the request
is such their significance to that application, since
the user agent is capable of saving the entity directives may be applicable to a
file if all recipients along the received media type
request/response chain. It is unknown, then the only
appropriate value not possible to specify a cache-directive
for Accept is "*/*", or an empty value if the
user desires reactive negotiation.

Note: A user agent may be provided with a default set of
quality values for certain media ranges. However, unless specific cache.

Cache-Control = "Cache-Control" ":" 1#cache-directive

and perhaps
| "max-uses" "=" 1*DIGIT
| "use-count" "=" 1*DIGIT

When a directive appears without any 1#field-name parameter, the
user agent is
directive applies to the entire request or response. When such a closed system which cannot interact
directive appears with
other rendering agents, this default set should be
configurable by a 1#field-name parameter, it applies only to the user.

10.2 Accept-Charset

The Accept-Charset request-header
named field can be used or fields, and not to indicate
what character sets are acceptable for the rest of the request or response.
This field
allows clients capable mechanism supports extensibility; implementations of understanding more comprehensive or
special-purpose character sets to signal that capability to a
server which is capable future
versions of representing documents the HTTP protocol may apply these directives to header
fields not defined in those
character sets. HTTP/1.1.

The US-ASCII character set cache-control directives can be assumed to be
acceptable to all user agents.

Accept-Charset = "Accept-Charset" ":" 1#charset

Character set values are described in Section 3.4. An example is

Accept-Charset: iso-8859-1, unicode-1-1

If no Accept-Charset field broken down into these general
categories:

. Restrictions on what is given, cachable; these may only be imposed by the default is that any
character set is acceptable. If
origin server.
. Restrictions on what may be stored by a cache; these may be imposed
by either the Accept-Charset field is given
and origin server or the requested resource is not available in one end-user client.
. Modifications of the listed
character sets, then basic expiration mechanism; these may be
imposed by either the origin server should respond with the 406 (none
acceptable) status code.

10.3 Accept-Encoding

The Accept-Encoding request-header field is similar to Accept, but
restricts or the content-coding values (Section 3.5) which are
acceptable in end-user client.
. Controls over cache revalidation and reload; these may only be
imposed by an end-user client.
. Restrictions on the response.

Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )

An example number of its use times a cache entry may be used, and
related demographic reporting mechanisms.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

. Miscellaneous restrictions
Caches never add or remove Cache-Control directives to requests or
responses.

Check: is

Accept-Encoding: compress, gzip

If no Accept-Encoding field this true?

10.7.1 SLUSHY: Restrictions on What is present in Cachable
Unless specifically constrained by a request, the server Cache-Control directive, a caching
system may
assume that the client will accept any content coding. always store a successful response as a cache entry, may
return it without validation if it is fresh, and may return it after
successful validation. If an
Accept-Encoding field there is present, but contains neither a cache validator nor an empty field
value, then the user agent is refusing to accept any content coding.

10.4 Accept-Language

The Accept-Language request-header field is similar
explicit expiration time associated with a response, we do not expect it
to Accept, be cached, but
restricts certain caches may violate this expectation (for
example, when little or no network connectivity is available) as long as
they explicit mark their responses using the set of natural languages Warning mechanism describe
in section 10.51.

Note that some HTTP/1.0 caches are preferred as a
response known to the request.

Accept-Language = "Accept-Language" ":"
1#( language-tag [ ";" "q" "=" qvalue ] )

The language-tag is described violate this
expectation without providing any Warning.

However, in Section 3.10. Each language some cases it may be
given an associated quality value which represents an estimate of
the user's comprehension of that language. The quality value
defaults to "q=1" (100% comprehension) inappropriate for listed languages. a cache to retain a
resource value, or to return it in response to a subsequent request.
This
value may be used in because absolute semantic transparency is deemed necessary
by the server's content negotiation algorithm
(Section 12). For example,

Accept-Language: da, en-gb;q=0.8, de;q=0.55

would mean: "I prefer Danish, but will accept British English (with
80% comprehension) service author, or German (with a 55% comprehension)."

If because of security or privacy considerations.
Certain Cache-Control directives are therefore provided so that the
server cannot fulfill the request with one can indicate that certain resources, or more portions thereof, may not
be cached regardless of the
languages given, or if the languages only represent other considerations.

Note that section 10.6 normally prevents a subset of shared cache from saving and
returning a
multi-linguistic Entity-Body, it is acceptable response to serve the a previous request
in if that request included an unspecified language. This
Authorization header.

The following Cache-Control response directives add or remove
restrictions on what is equivalent to assigning cachable:

public
Overrides the restriction in section 10.6 that prevents a
quality value of "q=0.001" shared
cache from saving and returning a response to a previous request if
that request included an Authorization header. However, any unlisted language.

If no Accept-Language header is present in the request, the server
should assume other
constraints on caching still apply.
private
Indicates that all languages are equally acceptable.

Note: As intelligibility is highly dependent on or parts of the
individual user, it is recommended response message are intended for
a single user and MUST NOT be cached by a shared cache. This allows
an origin server to state that client applications
make the choice specified parts of linguistic preference available to the
user. If the choice is response
are intended for only one user and are not made available, then the
Accept-Language header field a valid response for
requests by other users. applicable to responses and must not be given in the
request.

10.5 Allow

The Allow entity-header field lists the set of methods supported
generated by clients. A private (non-shared) cache may ignore this
directive.
Note: This usage of the resource identified by word _private_ only controls where the Request-URI. The purpose of this
field is strictly to inform
response may cached, and cannot ensure the recipient privacy of valid methods
associated with the resource. An Allow header field must be present
message content. Note in a 405 (method not allowed) response. The Allow header field is particular that HTTP/1.0 caches will
not permitted in a request using the POST method, recognize or obey this directive.

Fielding, Frystyk, Berners-Lee, Gettys, and thus should
be ignored if it is received as part of a POST entity.

Allow = "Allow" ":" 1#method

Example Mogul [Page 72]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

no-cache
indicates that all or parts of use:

Allow: GET, HEAD, PUT

This field cannot prevent a client from trying other methods.
However, the indications given by the Allow header field value
should response message MUST NOT be followed. The actual set of allowed methods is defined by
the
cached. This allows an origin server at the time of each request.

The Allow header field may be provided with a PUT request to
recommend the methods to be supported prevent caching even by the new
caches that have been configured to return stale responses to client
requests.
Note: HTTP/1.0 caches will not recognize or modified
resource. obey this directive.

TBS: precedence relations between public, private, and no-cache.

10.7.2 Restrictions On What May be Stored by a Cache
The server is not required _no-store_ directive applies to support these methods the entire message, and
should include an Allow header may be sent
either in the a response giving the actual
supported methods.

A proxy must not modify the Allow header field even if it does not
understand all the methods specified, since the user agent may have
other means or in a request. If sent in a request, a cache MUST
NOT store any part of communicating with the origin server.

The Allow header field does not indicate what methods are
implemented at the server level. Servers may use the Public either this request or any response header field (Section 10.32) to describe what methods are
implemented on the server as it. If sent
in a whole.

10.6 Authorization

A user agent response, a cache MUST NOT store any part of either this response
or the request that wishes elicited it. This directive applies to authenticate itself both non-
shared and shared caches.

Even when this directive is associated with a
server--usually, but not necessarily, after receiving response, users may
explicitly store such a 401
response--may do so by including an Authorization request-header
field with response outside of the request. caching system (e.g.,
with a _Save As_ dialog). History buffers may store such responses as
part of their normal operation.

The Authorization field value consists purpose of
credentials containing this directive is to meet the authentication information stated requirements of the user
agent for the realm
certain users and service authors who are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the resource being requested.

Authorization = "Authorization" ":" credentials

HTTP access authentication is described use of this directive may improve privacy in Section 11. If a request some
cases, we caution that it is authenticated and NOT in any way a realm specified, the same credentials should
be valid reliable or sufficient
mechanism for all other requests within ensuring privacy. In particular, HTTP/1.0 caches will not
recognize or obey this realm.

Responses to requests containing an Authorization field are directive, malicious or compromised caches may
not
cachable.

10.7 Base

The Base entity-header field recognize or obey this directive, and all communications networks
may be used to specify the base URI
for resolving relative URLs, as described in RFC 1808 [11].

10.8 Cache-Control

The Cache-Control general-header field is used vulnerable to specify
directives that must be obeyed by all caching mechanisms along the
request/response chain. eavesdropping.

The directives specify behavior intended _min-vers_ directive applies to
prevent caches from adversely interfering with the request entire message, and may be sent
either in a response or
response. Cache directives are unidirectional in that a request. If sent in a request, a cache
whose HTTP version number is less than the presence specified version MUST NOT
store any part of a directive either this request or any response to it. If sent in
a response, a cache whose HTTP version number is less than the specified
version MUST NOT store any part of either this response or the request does not imply
that elicited it, nor may any cache transmit a stored (non-firsthand)
copy of the same response to any client with a lower HTTP version number.
This directive
should be given in the response.

Cache-Control = "Cache-Control" ":" 1#cache-directive

cache-directive = "cachable"
| "max-age" "=" delta-seconds
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]

The Cache-Control header field may be used applies to modify the optional
behavior of caching mechanisms, both non-shared and the default cachability of a
response message; it cannot be used shared caches, and is made
mandatory to modify the required behavior
of caching mechanisms. HTTP requirements allow for caching and cachable
messages are described in Section 13.

The "cachable" directive indicates future protocol extensions that the entire response message
is cachable unless required otherwise by HTTP restrictions on the
request method and response code. In other words, this directive
indicates may affect
caching.

Note that the server believes the response to lowest version that can be cachable.
This sensibly included in a
_min-vers_ directive applies only to responses and must is HTTP/1.1, since HTTP/1.0 caches do not be used with
any other cache directive.

When
obey it.

10.7.3 Modifications of the "max-age" directive is present in Basic Expiration Mechanism
The expiration time of a request message, an
application must forward the request toward resource may be specified by the origin server if it
has no cached copy, or refresh its cached copy if
using the Expires header (see section TBS). Alternatively, it is older than may be
specified using the age value given (in seconds) prior to returning _max-age_ directive in a response. A
cached copy's age is determined by the cached message's Date header
field, or the equivalent as stored by the cache manager.

In most cases,
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

If a cached copy can be refreshed by forwarding response includes both an Expires header and a
conditional GET request toward max-age: directive,
the origin server with max-age: directive overrides the stored
message's Last-Modified value in Expires header, even if the If-Modified-Since field. The
Unless Expires
header field is more restrictive. This rule allows an origin server to
provide, for a given response, a longer expiration time to an HTTP/1.1
(or later) cache than to an HTTP/1.0 cache. This may be used useful if
certain HTTP/1.0 caches improperly calculate ages or expiration times,
perhaps due to add further restrictions badly unsynchronized clocks.

Other directives allow an end-user client to modify the
modification test basic expiration
mechanism, making it either stricter or looser. These directives may be
specified on a request:

max-age Indicates that the server. If client is willing to accept a 304 (not modified) response whose
age is received, the cache should replace the cached message's Date
with that of no greater than the 304 response and send this refreshed message as specified time in seconds. Unless _max-stale_
is also included, the response. Any other response should be forwarded directly client is not willing to
the requestor and, depending on the response code and the
discretion accept a stale response.
This directive overrides any policy of the cache manager, may replace the message in the cache.

When

min-fresh Indicates that the "max-age" directive client is present in willing to accept a cached response
message, an application must refresh the message if it
whose freshness lifetime is older no less than the its current age value given (in seconds) at plus the
specified time of in seconds. That is, the client wants a new request
for that resource. The behavior should response
will still be equivalent to what would
occur if the request had included the max-age directive. If both
the new request and the cached message have max-age specified, then fresh for at least the lesser specified number of seconds.

max-stale Indicates that the two values must be used. A max-age value of zero
(0) forces a cache client is willing to perform a refresh (If-Modified-Since) on
every request. The max-age directive on accept a response implies that
has exceeded its expiration time by no more than the
server believes it to be cachable.

The "private" directive indicates that parts specified number of the response
message are intended for a single user and must not be cached
except within
seconds. If a private (non-shared) cache controlled by returns a stale response in response to such a
request, it MUST mark it as stale using the user
agent. Warning header.

Note that HTTP/1.0 caches will ignore these directives.

If no list a cache returns a stale response, either because of field names is given, then a max-stale
directive on a request, or because the entire message cache is private; otherwise, only configured to override
the information within expiration time of a response, the cache MUST attach a Warning
header
fields identified by to the list of names stale response, using Warning 10 (Response is private stale).

10.7.4 SLUSHY: Controls over cache revalidation and reload
Sometimes an end-user client may want or need to insist that a cache
revalidate its cache entry with the remainder
of origin server (and not just with the message is believed
next cache along the path to the origin server), or to reload its cache
entry from the origin server. End-to-end revalidation may be cachable by any application. This
allows an necessary
if either the cache or the origin server to state that has overestimated the specified parts
expiration time of the
message are intended for only one user and are not a valid cached response. End-to-end reload may be
necessary if the response value has become corrupted for requests by other agents. The "private" directive is only
applicable to responses some reason,
and must not be generated by clients.

Note: This usage of the word "private" implies only fact that its validator is up-to-date is irrelevant.

End-to-end revalidation may be requested either when the
message must client does not be
have its own local cached publically; copy, in which case we call it does not ensure
the privacy of _unspecified
end-to-end revalidation_, or when the message content.

The "no-cache" directive on client does have a local cached
copy, in which case we call it _specific end-to-end revalidation._

The client can specify these three kinds of action using Cache-Control
request message requires any cache to
forward the directives:

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

End-to-end reload The request toward includes _Cache-Control: no-cache_ or, for
compatibility with HTTP/1.0 clients, _Pragma: no-cache_. No field names
may be included with the origin _no-cache_ directive in a request. The server even if it has
MUST NOT use a cached copy of what is being requested. This allows when responding to such a client request.

Specific end-to-end revalidation The request includes _Cache-Control:
max-age=0_, which forces each cache along the path to
insist upon receiving an authoritative response the origin server
to revalidate its request. It
also allows a client to refresh own entry, if any, with the next cache or server. The
initial request includes a cached copy cache-validating conditional with the
client's current validator.

Unspecified end-to-end revalidation The request includes _Cache-Control:
max-age=0_, which is known forces each cache along the path to be
corrupted or stale. This is equivalent the origin server
to revalidate its own entry, if any, with the "no-cache"
pragma-directive in Section 10.29. next cache or server. The list of field names is not
used with requests and must
initial request does not be generated by clients. The
no-cache directive overrides any max-age directive.

The "no-cache" directive on include a response message indicates cache-validating conditional; the
first cache along the path (if any) that parts holds a cache entry for this
resource includes a cache-validating conditional with its current
validator.

Note that HTTP/1.0 caches will ignore these directives, except
perhaps for _Pragma: no-cache_.

When an intermediate cache is forced, by means of a _max-age=0_
directive, to revalidate its own cache entry, and the message must never be cached. If no list of field names is
given, then client has
supplied its own validator in the entire message must not be cached; otherwise, only request, the information within supplied validator may
differ from the header fields identified by validator currently stored with the list of
names must not be cached and cache entry. In this
case, the remainder of cache may use either validator in making its own request
without affecting semantic transparency.

However, the message choice of validator may affect performance. The best
approach is
believed for the intermediate cache to be cachable. This allows an origin use its own validator when
making its request. If the server to state that replies with 304 (Not Modified), then
the specified parts of cache should return its now validated copy to the message are intended for only one
recipient and must not be stored unless client with a 200
(OK) response. If the user explicitly
requests it through server replies with a separate action.

The max-age, private, new Entity-body and no-cache directives may be used in
combination to define cache
validator, however, the cachability of each part of intermediate cache should compare the message.
In all cases, no-cache takes precedence over private, which returned
validator with the one provided in turn
takes precedence over max-age.

Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along client's request, using the
request/response chain. It is not possible to specify a
cache-directive for a specific cache.

10.9 Connection

The Connection general-header field is used to indicate a list of
keywords and header field names containing information which
strong comparison function. If the client's validator is
only applicable equal to the current connection between
origin server's, then the sender and intermediate cache simply returns 304 (Not
Modified). Otherwise, it returns the nearest non-tunnel recipient on new Entity-body with a 200 (OK)
response.

If a request includes the request/response chain.
This information must _no-cache_ directive, it should not be forwarded include
_fresh-min_, _max-stale_, or cached. Unlike the
default behavior, the recipient cannot safely ignore the semantics _max-age_.

In some cases, such as times of the listed field-names if they are not understood, since
forwarding them extremely poor network connectivity, a
client may imply want a cache to return only those responses that understanding.

Connection = "Connection" ":" 1#field-name

Proxies and gateways must discard the named header fields, and the
Connection header itself, before forwarding the message. Proxies it currently
has stored, and gateways may add their own Connection information to forwarded
messages if such options are desired for the forwarding connection.
These restrictions do not apply to a tunnel, since reload or revalidate with the tunnel is
acting as a relay between two connections and does not affect origin server. To
do this, the
connection options.

Whether or not client may include the listed field-name(s) occur as header fields _only-if-cached_ directive in
the message is optional. a
request. If no corresponding header field it receives this directive, a cache SHOULD either respond
using a cached value that is
present, then consistent with the field name other constraints of
the request, or respond with a 504 (Gateway Timeout) status. However, if
a group of caches is treated being operated as a keyword. Keywords are
useful for indicating unified system with good
internal connectivity, such a desired option without assigning parameters
to request MAY be forwarded within that option. This allows for a minimal syntax to provide
connection-based options without pre-restricting the syntax or
number of those options. HTTP/1.1 only defines the "keep-alive"
keyword.

The semantics group
of Connection are defined by caches.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75]

INTERNET-DRAFT HTTP/1.1 in order to
provide Monday, April 22, 1996

Because a safe transition to connection-based features. Connection
header fields received in an HTTP/1.0 message, as would be the case
if an older proxy mistakenly forwards the field, cannot cache may be trusted configured to ignore a server's specified
expiration time, and must be discarded except under experimental conditions.

10.9.1 Persistent Connections

The "keep-alive" keyword in because a Connection header field allows client request may include a max-stale
directive, which has a similar effect, the
sender to indicate its desire protocol also includes a
mechanism for the origin server to require revalidation of a persistent connection (i.e., cache entry
on any subsequent use. When the _must-revalidate_ directive is present
in a
connection response received by a cache, that lasts beyond the current request/response
transaction). Persistent connections allow cache MUST NOT use the client value
after it becomes stale to perform
multiple requests respond to a subsequent request without first
revalidating it with the overhead of connection tear-down origin server. (I.e., the cache must do an end-
to-end revalidation every time.)

The _must-revalidate_ directive is necessary to support reliable
operation for cookies and
set-up between each request.

As certain other protocol features. In all
circumstances an example, HTTP/1.1 cache MUST obey the _must-revalidate_
directive; in particular, if the cache cannot reach the origin server
for any reason, it MUST generate a client would send

Connection: Keep-Alive

to indicate 504 (Gateway Timeout) response. Note
that it desires HTTP/1.0 caches will ignore this directive.

Servers should send the _must-revalidate_ directive if and only if
failure to keep revalidate a request on the connection open for
multiple requests. The server may then respond with entity could result in
significantly incorrect operation, such as a message
containing

Connection: Keep-Alive

to indicate silently unexecuted
financial transaction. Recipients MUST NOT take any automated action
that violates this directive, and MUST NOT automatically provide an
unvalidated copy of the connection will be kept open for entity if revalidation fails.

Although this is not recommended, user agents operating under severe
connectivity constraints may violate this directive but if so, MUST
explicitly warn the next
request. user that an unvalidated response has been provided.
The Connection header field with a keep-alive keyword must warning MUST be sent provided on all requests each unvalidated access, and responses that wish to continue the
persistence. SHOULD
require explicit user confirmation.

The client sends requests as normal and _proxy-revalidate_ directive has the server
responds same meaning as normal, the _must-
revalidate_ directive, except that all messages containing an entity
body must have a length that can it does not apply to user-agent
caches. This directive is meant to support digest authentication.

10.7.5 FLUID: Restrictions on use count and demographic reporting
This section is highly debatable and is likely to be determined without closing the
connection (i.e., each message containg an entity body must have removed to a
valid Content-Length, be
separate I.D.

The _max-uses_ response directive allows a multipart media type, or be encoded
using cache to use a response at
most a certain limited number of times. For example, _max-uses=10_
means that the "chunked" transfer coding, as described response should be returned in Section 7.2.2).

The Keep-Alive header field (Section 10.24) reply to the current
request, and may be used returned in reply to no more than nine subsequent
requests (subject to include
diagnostic information and other optional parameters. caching constraints), unless revalidated.

A cache may subdivide its remaining use-count among several of its own
clients. For example, if the server incoming response includes _max-uses=10_,
the recipient may responds forward this as two responses, each with

Connection: Keep-Alive
Keep-Alive: timeout=10, max=5

to indicate _max-uses=5_.
The idea is that the server has selected (perhaps dynamically) a
maximum total number of 5 requests, but will timeout if the next request is uses allowed in a cache hierarchy
should not
received within 10 seconds. Note, however, that this additional
information is optional and exceed the Keep-Alive header field does not
need specified limit. (The heuristics a cache uses to be present. If it is present,
sub-allocate its max-uses value are beyond the semantics scope of the
Connection header field prevents it from being accidentally
forwarded to downstream connections. HTTP spec.)

The persistent connection ends when either side closes _use-count_ request directive allows a cache to tell a server how
many times it has actually used the
connection or after cache entry specified in the receipt
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

associated request. If a cache receives a use-count value from one of
its clients, and it has a response which lacks the
"keep-alive" keyword. The server may close corresponding cache entry, it should add the connection
immediately after responding
incoming use-count to its local count.

When a request without cache removes an entry, it MAY first send a "keep-alive"
keyword. A client can tell if HEAD request on the connection will be closed by
looking for
associated URI, including its use-count value, to inform the server of
the actual use-count. If the server has sent a "keep-alive" in max-uses limit, the response.

10.10 Content-Encoding

The Content-Encoding entity-header field
cache SHOULD perform this notification.

A cache that is used as a modifier willing to perform such notifications and that is
willing to obey the media-type. When present, max-uses limit SHOULD send a ``use-count=0''
directive on its value indicates what additional
content codings have been applied to first (non-conditional) request on a resource. This
informs the resource, and thus what
decoding mechanisms must be applied in order to obtain server that the
media-type referenced by cache intends to use these two directives in
the Content-Type header field.
Content-Encoding is primarily used manner described here.

10.7.6 Miscellaneous restrictions
In certain circumstances, an intermediate cache (proxy) may find it
useful to allow convert the encoding of an entity body. For example, a proxy
might use a document to be compressed without losing content-coding to transfer the identity body to a client
on a slow link.

Because end-to-end authentication of its underlying media type.

Content-Encoding = "Content-Encoding" ":" 1#content-coding

Content codings are defined in Section 3.5. An example entity bodies and/or entity headers
relies on the specific encoding of its use is

Content-Encoding: gzip

The Content-Encoding is a characteristic these values, such transformations
may cause authentication failures. Therefore, an intermediate cache MUST
NOT change the encoding of an entity body if the resource identified
by response includes the Request-URI. Typically,
_no-transform_ directive.

10.8 Connection
HTTP version 1.1 provides a new request and response header field called
_Connection_. This header field allows the resource is stored with this
encoding client and is server to specify
options which should only decoded before rendering or analogous usage.

If multiple encodings exist over that particular connection and MUST
NOT be communicated by proxies over further connections. The connection
header field MAY have been applied multiple tokens separated by commas (referred to a resource,
as connection-tokens).

HTTP version 1.1 proxies MUST parse the content
codings must be listed Connection header field and for
every connection-token in this field, remove a corresponding header
field from the order in which they were applied.
Additional information about request before the encoding parameters may be
provided by other Entity-Header fields not defined by this
specification.

10.11 Content-Language request is forwarded. The Content-Language entity-header field describes use of a
connection option is specified by the natural
language(s) presence of a connection token in
the intended audience for Connection header field, not by the enclosed entity. Note
that this corresponding additional header
field (which may not be equivalent present).

When a client wishes to all the languages used within establish a persistent connection it MUST send a
_Persist_ connection-token:

Connection: persist

The Connection header has the entity.

Content-Language following grammar:

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Connection-header = "Content-Language" "Connection" ":"

connection-token 0#( "," connection-token )

When the Persist connection-token has been transmitted with a request or
a response a Persist header field MAY also be included. The 10.8.1 Persist Persist
header field takes the following form:

Persist-header = "Persist" ":" 0#pers-param

pers-param = param-name "=" value

The Persist header itself is optional, and is used only if a parameter
is being sent. HTTP/1.1 does not define any parameters.

If the Persist header is sent, the corresponding connection token MUST
be transmitted. The Persist header MUST be ignored if received without
the connection token.

10.9 Content-Base
The Content-Base entity-header field may be used to specify the base URI
for resolving relative URLs within the entity. This header field is
described as "Base" in RFC 1808 [11], which is expected to be revised

soon.

Content-Base = "Content-Base" ":" absoluteURI

If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location or the URI used to initiate the
request, in that order of precedence. Note, however, that the base URI
of the contents within the entity body may be redefined within that
entity body.

10.10 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the resource, and thus what decoding
mechanisms MUST be applied in order to obtain the media-type referenced
by the Content-Type header field. Content-Encoding is primarily used to
allow a document to be compressed without losing the identity of its
underlying media type.

Content-Encoding = "Content-Encoding" ":" 1#content-coding

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Content codings are defined in Section 3.5. An example of its use is

Content-Encoding: gzip

The Content-Encoding is a characteristic of the resource identified by
the Request-URI. Typically, the resource is stored with this encoding
and is only decoded before rendering or analogous usage.

If multiple encodings have been applied to a resource, the content
codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided by
other Entity-Header fields not defined by this specification.

10.11 Content-Language
The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity. Note that
this may not be equivalent to all the languages used within the entity.

Content-Language = "Content-Language" ":" 1#language-tag

Language tags are defined in Section 3.10. The primary purpose of

Content-Language is to allow a selective consumer to identify and
differentiate resources according to the consumer's own preferred
language. Thus, if the body content is intended only for a
Danish-literate Danish-
literate audience, the appropriate field is

Content-Language: dk

If no Content-Language is specified, the default is that the content is
intended for all language audiences. This may mean that the sender does
not consider it to be specific to any natural language, or that the
sender does not know for which language it is intended.

Multiple languages may MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty _Treaty of
Waitangi,"
Waitangi,_ presented simultaneously in the original Maori and English
versions, would call for

Content-Language: mi, en

However, just because multiple languages are present within an entity
does not mean that it is intended for multiple linguistic audiences. An
example would be a beginner's language primer, such as "A _A First Lesson
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

in Latin," Latin,_ which is clearly intended to be used by an English-literate
audience. In this case, the Content-Language should only include "en". _en_.

Content-Language may MAY be applied to any media type -- it should SHOULD not be
limited to textual documents.

10.12 Content-Length
The Content-Length entity-header field indicates the size of the
Entity-Body, Entity-
Body, in decimal number of octets, sent to the recipient or, in the case
of the HEAD method, the size of the Entity-Body that would have been
sent had the request been a GET.

Content-Length = "Content-Length" ":" 1*DIGIT

An example is

Content-Length: 3495

Applications should SHOULD use this field to indicate the size of the
Entity-Body Entity-
Body to be transferred, regardless of the media type of the entity. A
valid Content-Length field value is required on all HTTP/1.1 request
messages containing an entity body.

Any Content-Length greater than or equal to zero is a valid value.
Section 7.2.2 describes how to determine the length of an Entity-Body if

a Content-Length is not given.

Note: The meaning of this field is significantly different from
the corresponding definition in MIME, where it is an optional
field used within the "message/external-body" _message/external-body_ content-type. In
HTTP, it should SHOULD be used whenever the entity's length can be
determined prior to being transferred.

10.13 Content-MD5

TBS

10.14 Content-Range

TBS

10.15 Content-Type
The Content-Type Content-MD5 entity-header field indicates the media type of
the Entity-Body sent to the recipient or, in the case is an MD5 digest of the HEAD
method, the media type that would have been sent had the request
been a GET.

Content-Type = "Content-Type" ":" media-type

Media types are entity-body,
as defined in Section 3.7. An example of the field is

Content-Type: text/html; charset=ISO-8859-4

Further discussion of methods RFC 1864 [23], for identifying the media type purpose of providing an
entity is provided in Section 7.2.1.

10.16 Content-Version

The Content-Version entity-header field defines the version tag
associated with a rendition end-to-end

message integrity check (MIC) of an evolving entity. Together with the Derived-From field described in Section 10.18, it allows a
group entity-body. (Note: an MIC is good
for detecting accidental modification of people to work simultaneously on the creation entity-body in transit, but
is not proof against malicious attacks.)

ContentMD5 = "Content-MD5" ":" md5-digest

md5-digest = <base64 of a work 128 bit MD5 digest as
an iterative process. The field should per RFC 1864>

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The Content-MD5 header may be used generated by an origin server to allow evolution function
as an integrity check of a particular work along a single path. It should not be used to
indicate derived works or renditions in different representations.
It the entity-body. Only origin-servers may also me used
generate the Content-MD5 header field; proxies and gateways MUST NOT
generate it, as an opaque this would defeat its value for comparing a cached
entity's version with that as an end-to-end integrity
check. Any recipient of the current resource.

Content-Version= "Content-Version" ":" quoted-string

Examples of entity-body, including gateways and proxies,
MAY check that the Content-Version digest value in this header field include:

Content-Version: "2.1.2"

Content-Version: "Fred 19950116-12:26:48"

Content-Version: "2.5a4-omega7" matches that of the
entity-body as received.

The value MD5 digest is computed based on the content of the Content-Version field should be considered opaque
to all parties entity body,
including any Content-Encoding that has been applied, but not including
any Transfer-Encoding. If the origin server. A user agent may suggest entity is received with a Transfer-
Encoding, that encoding must be removed prior to checking the Content-
MD5 value for against the version of an entity transferred via a PUT request;
however, only received entity.

This has the origin server can reliably assign result that value.

10.17 Date

The Date general-header field represents the date and time at which digest is computed on the message was originated, having octets of the same semantics as orig-date
entity body exactly as, and in the order that, they would be sent if no
Transfer-Encoding were being applied.

HTTP extends RFC 822. The field value 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but this
does not change how the digest is an HTTP-date, computed as described defined in
Section 3.3.

Date = "Date" ":" HTTP-date

An example is

Date: Tue, 15 Nov 1994 08:12:31 GMT the preceding
paragraph.

Note: There are several consequences of this. The entity-body
for composite types many contain many body-parts, each with its
own MIME and HTTP headers (including Content-MD5, Content-
Transfer-Encoding, and Content-Encoding headers). If a message body-part
has a Content-Transfer-Encoding or Content-Encoding header, it
is received via direct connection with the user agent
(in assumed that the case content of requests) or the origin server (in body-part has had the case of
responses), then
encoding applied, and the date can be assumed to be body-part is included in the current date at Content-
MD5 digest as is -- i.e., after the receiving end. However, since application. Also, the date--as HTTP
Transfer-Encoding header makes no sense within body-parts; if it
is believed by present, it is ignored -- i.e. treated as ordinary text.

Note: while the
origin--is important definition of Content-MD5 is exactly the same
for evaluating cached responses, origin servers
should always include a Date header. Clients should only send a
Date header field in messages that include an entity body, HTTP as in RFC 1864 for MIME entity-bodies, there are
several ways in which the case application of the PUT Content-MD5 to HTTP
entity-bodies differs from its application to MIME entity-
bodies. One is that HTTP, unlike MIME, does not use Content-
Transfer-Encoding, and POST requests, does use Transfer-Encoding and even then Content-
Encoding. Another is that HTTP more frequently uses binary
content types than MIME, so it is
optional. A received message which does not have a Date header
field should be assigned one by the recipient if the message will
be cached by worth noting that recipient or gatewayed via a protocol which
requires a Date.

In theory, in such
cases, the date should represent byte order used to compute the moment just before the
entity digest is generated. In practice, the date can be generated at any
time during
transmission byte order defined for the message origination without affecting its semantic
value.

Note: An earlier version type. Lastly, HTTP
allows transmission of this document incorrectly
specified that this field should contain the creation date text types with any of several line break
conventions and not just the enclosed Entity-Body. This has been changed canonical form using CR-LF.
Conversion of all line breaks to
reflect actual (and proper) usage.

10.18 Derived-From

The Derived-From entity-header field can CR-LF should not be used to indicate the
version tag of the resource from which the enclosed entity was
derived done before modifications were made by
computing or checking the sender. This field is digest: the line break convention used to help manage
in the process of merging successive changes to a
resource, particularly text actually transmitted should be left unaltered when such changes are being made in parallel
and from multiple sources.

Derived-From = "Derived-From" ":" quoted-string

An example use of
computing the field is:

Derived-From: "2.1.1" digest.

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

10.14 SLUSHY Content-Range
The Derived-From field Content-Range header is required for PUT and PATCH requests if
the entity being sent was previously retrieved from the same URI
and a Content-Version header was included with the a partial entity when it
was last retrieved.

10.19 Expires

The Expires entity-header field gives the date/time after which body to specify
where in the full entity body the partial body should be considered stale. This allows information
providers to suggest inserted. It
also indicates the volatility total size of the resource, or a date
after which the information may no longer be valid. Applications
must not cache this entity beyond the date given. The presence of entity.

Content-Range = "Content-Range" ":" content-range-spec

When an Expires field does not imply that HTTP message includes the original resource will
change or cease content of a single range (for
example, a response to exist at, before, or after that time. However,
information providers that know or even suspect that a resource
will change by request for a certain date should include an Expires header with single range, or to request for a
set of ranges that date. The format overlap without any holes), this content is an absolute date
transmitted with a Content-Range header, and time as defined by
HTTP-date in Section 3.3.

Expires = "Expires" ":" HTTP-date

An example a Content-length header
showing the number of its use is

Expires: Thu, 01 Dec 1994 16:00:00 bytes actually transferred.

For example,

HTTP/1.0 206 Partial content

Date: Wed, 15 Nov 1995 06:25:24 GMT

If the date given is equal to or earlier than

Last-modified: Wed, 15 Nov 1995 04:58:08 GMT

Content-range: 21010-47021/47022

Content-length: 26012

Content-type: image/gif

10.14.1 MIME multipart/byteranges content-type
When an HTTP message includes the value content of the Date
header, the recipient must not cache the enclosed entity. If multiple ranges (for
example, a
resource is dynamic by nature, response to a request for multiple non-overlapping ranges),
these are transmitted as is the case with many
data-producing processes, entities from that resource should be
given an appropriate Expires value which reflects that dynamism. a multipart MIME message. The Expires field cannot be multipart MIME
content-type used for this purpose is defined in this specification to force a user agent to refresh
its display
be "multipart/byteranges".

The MIME multipart/byteranges content-type includes two or reload a resource; more parts,
each with its semantics apply only to
caching mechanisms, own Content-type and such mechanisms need only check a
resource's expiration status when Content-Range fields. The parts are
separated using a new request MIME boundary parameter.

For example:

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

HTTP/1.0 206 Partial content

Date: Wed, 15 Nov 1995 06:25:24 GMT

Last-modified: Wed, 15 Nov 1995 04:58:08 GMT

Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES

Content-type: application/pdf

Content-range: bytes 500-999/8000

...the first range...

--THIS_STRING_SEPARATES

Content-type: application/pdf

Content-range: bytes 7000-7999/8000

...the second range...

--THIS_STRING_SEPARATES_

10.14.2 Additional rules for Content-Range
A client that resource
is initiated.

User agents often have history mechanisms, such as "Back" buttons
and history lists, which can be used to redisplay an entity
retrieved earlier cannot decode a MIME multipart/byteranges message should
not ask for multiple byte-ranges in a session. By default, single request.

When a client requests multiple byte-ranges in one request, the Expires field does
not apply to history mechanisms. If server
SHOULD return them in the entity is still order that they appeared in storage, the request.

If the server ignores a history mechanism should display byte-range-spec because it even if is invalid, or
because it specifies a range that starts beyond the entity has
expired, unless end of the user has specifically configured entity,
it may omit the agent to
refresh expired history documents.

Note: Applications are encouraged to be tolerant corresponding Content-Range field and partial entity
body.

If none of bad or
misinformed implementations the byte-range-spec values in a request specify part of the Expires header. A value
current entity (i.e., start before the last byte of zero (0) or an invalid date format the entity), then
the server should be considered
equivalent to an "expires immediately." Although these
values are not legitimate for HTTP/1.1, return a robust
implementation is always desirable.

10.20 Forwarded status of 207 (Range Out Of Bounds).

10.15 Content-Type
The Forwarded general-header Content-Type entity-header field is to be used by gateways and
proxies indicates the media type of the
Entity-Body sent to indicate the intermediate steps between recipient or, in the user agent
and case of the server on requests, and between HEAD method,
the origin server media type that would have been sent had the request been a GET.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Content-Type = "Content-Type" ":" media-type

Media types are defined in Section 3.7. An example of the
client on responses. It field is analogous to

Further discussion of methods for identifying the "Received" field media type of RFC
822 [9] and an
entity is provided in Section 7.2.1. Content-Type: text/html; charset=ISO-8859-4

10.16 Content-Location
The Content-Location entity-header field is intended to be used for tracing transport problems
and avoiding request loops.

Forwarded = "Forwarded" ":" #( "by" URI [ "(" product ")" ]
[ "for" FQDN ] )

FQDN = <Fully-Qualified Domain Name>

For example, to define the location
of the specific resource associated with the entity enclosed in the
message. A server SHOULD provide a message could be sent from Content-Location if, when including
an entity in response to a client GET request on
ptsun00.cern.ch a negotiated resource, the
entity corresponds to a server at www.ics.uci.edu port 80, specific, non-negotiated location which can be
accessed via an
intermediate HTTP proxy at info.cern.ch port 8000. The request
received by the Content-Location URI. A server at www.ics.uci.edu would then have SHOULD provide a
Content-Location with any 200 (OK) response which was internally (not
visible to the
following Forwarded header field:

Forwarded: client) redirected to a resource other than the one
identified by http://info.cern.ch:8000/ for ptsun00.cern.ch

Multiple Forwarded header fields are allowed the request and should represent
each proxy/gateway for which correct interpretation of that has forwarded
resource MAY require knowledge of its actual location. The recipient MAY
make future requests on this location instead of on the message. It Request-URI.

Content-Location = "Content-Location" ":" absoluteURI

If no Content-Base header field is strongly
recommended that proxies/gateways used as a portal through a
network firewall do not, by default, send out information about the
internal hosts within present, the firewall region. This information should
only be propagated if explicitly enabled. If not enabled, value of Content-
Location also defines the base URL for
token and FQDN should not be included the entity (see Section 10.9).

Note: Since the Content-Location field re-interprets the source
of an entity, recipients must take care in not allowing a
_spoofed_ location to deny access to the real resource. This is
described in Section 15.9.

10.17 Date
The Date general-header field value, represents the date and any
Forwarded headers already present in time at which the
message (those added
behind was originated, having the firewall) should be removed.

10.21 From same semantics as orig-date in RFC
822. The From request-header field, if given, should contain field value is an Internet
e-mail address for the human user who controls the requesting user
agent. The address should be machine-usable, HTTP-date, as defined by mailbox described in RFC 822 [9] (as updated by RFC 1123 [8]):

From Section 3.3.

Date = "From" "Date" ":" mailbox HTTP-date

An example is:

From: webmaster@w3.org

This header field may be used for logging purposes is

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Date: Tue, 15 Nov 1994 08:12:31 GMT

If a means
for identifying the source of invalid or unwanted requests. It
should not be used as an insecure form of access protection. The
interpretation of this field message is that received via direct connection with the request is being performed
on behalf of user agent (in
the person given, who accepts responsibility for case of requests) or the
method performed. In particular, robot agents should include this
header so that origin server (in the person responsible for running case of responses),
then the robot date can be
contacted if problems occur on assumed to be the current date at the receiving
end.

The Internet e-mail address in this field may be separate from However, since the
Internet host which issued date--as it is believed by the request. For example, when origin--is
important for evaluating cached responses, origin servers SHOULD always
include a request
is passed through Date header. Clients SHOULD only send a proxy Date header field in
messages that include an entity body, as in the original issuer's address should be
used.

Note: The client should not send case of the From PUT and POST
requests, and even then it is optional. A received message which does
not have a Date header field
without SHOULD be assigned one by the user's approval, as it may conflict with recipient if
the
user's privacy interests message will be cached by that recipient or their site's security policy. It gatewayed via a protocol
which requires a Date.

In theory, the date SHOULD represent the moment just before the entity
is strongly recommended that generated. In practice, the user date can be able to disable,
enable, and modify generated at any time during
the value message origination without affecting its semantic value.

Note: An earlier version of this document incorrectly specified
that this field at any time prior SHOULD contain the creation date of the enclosed
Entity-Body. This has been changed to reflect actual (and
proper) usage.

Origin servers MUST send a request.

10.22 Host

The Host request-header Date field allows in every response. However, if a
cache receives a response without a Date field, it SHOULD attach one
with the client to specify, for the
server's benefit, the Internet host given by the original Uniform
Resource Identifier (Section 3.2) cache's best estimate of the resource being requested,
as it was obtained from the user or the referring resource. This
allows a server to differentiate between internally-ambiguous URLs
(such as time at which the root "/" URL response was
originally generated.

The format of a server harboring multiple virtual
hostnames). This field is required on all HTTP/1.1 requests which
do not already include the host Date is an absolute date and time as defined by HTTP-
date in the Request-URI.

Host = "Host" ":" host ; Section 3.2.2

Example:

Host: www.w3.org 3.3; it MUST be in RFC1123-date format.

10.19 SLUSHY Expires
The contents of the Host header Expires entity-header field should exactly match the host
information used to contact the origin server or gateway in
question. It must not include gives the trailing ":port" information date/time after which the
entity should be considered stale. A stale cache entry may also not normally
be found in the net_loc portion of returned by a URL
(Section 3.2).

10.23 If-Modified-Since

The If-Modified-Since request-header field cache (either a proxy cache or an end-user cache)
unless it is used first validated with the GET
method to make it conditional: if the requested resource origin server (or with an
intermediate cache that has not
been modified since the time specified in this field, a fresh copy of the
resource will resource). See section
13.2 for further discussion of the expiration model.

The presence of an Expires field does not be returned from imply that the server; instead, a 304 (not
modified) response original
resource will change or cease to exist at, before, or after that time.

The format is an absolute date and time as defined by HTTP-date in
Section 3.3; it MUST be returned without any Entity-Body.

If-Modified-Since in rfc1123-date format:

Expires = "If-Modified-Since" "Expires" ":" HTTP-date

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

An example of the field is:

If-Modified-Since: Sat, 29 Oct its use is

Expires: Thu, 01 Dec 1994 19:43:31 16:00:00 GMT

A conditional GET method requests that the identified resource be
transferred only

Note: if it has been modified since the date given by
the If-Modified-Since header. The algorithm for determining this a response includes a Cache-Control field with the following cases:

a) If max-
age directive, that directive overrides the request would normally result in anything Expires field.

HTTP/1.1 clients and caches MUST treat other than
a 200 (ok) status, or if the passed If-Modified-Since invalid date
is invalid, formats,
especially including the value _0_, as in the past (i.e., _already
expired_).

To mark a response as _already expired,_ an origin server should use an
Expires date that is exactly equal to the same as Date header value. (See the rules for
expiration calculations in section 13.2.7.)

To mark a
normal GET. A response as _never expires,_ an origin server should use
Expires date which is later than approximately one year from the server's current time is invalid.

b) If the resource has been modified since the
If-Modified-Since date, the response is exactly the same as
for a normal GET.

c) If the resource has
generated. HTTP/1.1 servers should not been modified since a valid
If-Modified-Since date, send Expires dates more than one
year in the server must return a 304 (not
modified) response.

The purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead.

10.24 Keep-Alive future.

10.20 Via
The Keep-Alive Via general-header field may MUST be used to include
diagnostic information by gateways and other optional parameters associated
with proxies to
indicate the "keep-alive" keyword of intermediate protocols and recipients between the Connection header field
(Section 10.9). This Keep-Alive user
agent and the server on requests, and between the origin server and the
client on responses. It is analogous to the _Received_ field must only of RFC 822
[9]and is intended to be used when for tracking message forwards, avoiding

request loops, and identifying the
"keep-alive" keyword is present (Section 10.9.1).

Keep-Alive protocol capabilities of all senders
along the request/response chain.

Via = "Keep-Alive" "Via" ":" 1#kaparam

kaparam = ( "timeout" "=" delta-seconds )
| ( "max" "=" 1*DIGIT 1#( received-protocol received-by [ comment ] )
|

received-protocol = [ protocol-name "/" ] protocol-version

protocol-name = token

protocol-version = token

received-by = ( attribute host [ "=" value ":" port ] ) | pseudonym

pseudonym = token

The Keep-Alive header field and received-protocol indicates the additional information it
provides are optional protocol version of the message
received by the server or client along each segment of the
Fielding, Frystyk, Berners-Lee, Gettys, and do not need to be present to indicate a
persistent connection has been established. Mogul [Page 86]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

request/response chain. The semantics of received-protocol version is appended to
the
Connection header Via field prevent value when the Keep-Alive field from being
accidentally message is forwarded to downstream connections.

HTTP/1.1 defines semantics for so that information
about the protocol capabilities of upstream applications remains visible
to all recipients.

The protocol-name is optional "timeout" if and "max"
parameters on responses; other parameters may only if it would be added _HTTP_. The
received-by field is normally the host and optional port number of a
recipient server or client that subsequently forwarded the
field may also message.
However, if the real host is considered to be used on request messages. The "timeout" parameter
allows sensitive information, it
MAY be replaced by a pseudonym. If the server port is not given, it MAY be
assumed to indicate, for diagnostic purposes only, be the
amount default port of time in seconds it is currently allowing between when the
response was generated and when received-protocol.

Multiple Via field values represent each proxy or gateway that has
forwarded the next request message. Each recipient MUST append their information
such that the end result is received from ordered according to the client (i.e., sequence of
forwarding applications.

Comments MAY be used in the request timeout limit). Similarly, Via header field to identify the "max"
parameter allows software of
the server recipient proxy or gateway, analogous to indicate the maximum additional
requests that it will allow on User-Agent and Server
header fields. However, all comments in the current persistent connection. Via field are optional and
MAY be removed by any recipient prior to forwarding the message.

For example, the server may respond to a request for a persistent
connection with

Connection: Keep-Alive
Keep-Alive: timeout=10, max=5 message could be sent from an HTTP/1.0 user agent
to indicate that an internal proxy code-named _fred_, which uses HTTP/1.1 to forward
the server has selected (perhaps dynamically) request to a
maximum of 5 requests, but will timeout public proxy at nowhere.com, which completes the connection if
request by forwarding it to the next origin server at www.ics.uci.edu. The
request is not received within 10 seconds. Although these
parameters by www.ics.uci.edu would then have no affect on the operational requirements of the
connection, they are sometimes useful for testing functionality following Via
header field:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Proxies and
monitoring server behavior.

10.25 Last-Modified

The Last-Modified entity-header field indicates gateways used as a portal through a network firewall SHOULD
NOT, by default, forward the date names and time
at which the sender believes the resource was last modified. The
exact semantics of this field are defined in terms ports of how hosts within the
recipient should interpret it:
firewall region. This information SHOULD only be propagated if the recipient has a copy
explicitly enabled. If not enabled, the received-by host of this
resource which is older than any host
behind the date given firewall SHOULD be replaced by an appropriate pseudonym for
that host.

For organizations that have strong privacy requirements for hiding
internal structures, a proxy MAY combine an ordered subsequence of Via
header field entries with identical received-protocol values into a
single such entry. For example,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

could be collapsed to

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values.

Note: The Via header field replaces the Last-Modified Forwarded header field
which was present in earlier drafts of this specification.

10.21 From
The From request-header field, that copy should if given, SHOULD contain an Internet e-
mail address for the human user who controls the requesting user agent.
The address SHOULD be considered stale.

Last-Modified machine-usable, as defined by mailbox in RFC 822
[9] (as updated by RFC 1123 [8]):

From = "Last-Modified" "From" ":" HTTP-date mailbox

An example is:

From: webmaster@w3.org

This header field MAY be used for logging purposes and as a means for
identifying the source of its use is

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT invalid or unwanted requests. It SHOULD NOT be
used as an insecure form of access protection. The exact meaning interpretation of
this header field depends on is that the
implementation request is being performed on behalf of the sender and
person given, who accepts responsibility for the nature of method performed. In
particular, robot agents SHOULD include this header so that the original
resource. For files, it may person
responsible for running the robot can be just contacted if problems occur on
the file system last-modified
time. For entities with dynamically included parts, it may receiving end.

The Internet e-mail address in this field MAY be separate from the
most recent of
Internet host which issued the set of last-modify times for its component
parts. request. For database gateways, it may example, when a request is
passed through a proxy the original issuer's address SHOULD be used.

Note: The client SHOULD not send the last-update timestamp
of From header field without
the record. For virtual objects, user's approval, as it may conflict with the user's privacy
interests or their site's security policy. It is strongly
recommended that the user be able to disable, enable, and modify
the last value of this field at any time the
internal state changed.

An origin server must not send prior to a Last-Modified date which is later
than request.

10.22 Host
The Host request-header field specifies the server's time Internet host and port
number of message origination. In such cases, where
the resource's last modification would indicate some time in the
future, resource being requested, as obtained from the server must replace that date with original
URL given by the message
origination date.

10.26 Link user or referring resource (generally an HTTP URL, as
described in Section 3.2.2). The Link entity-header Host field provides a means for describing a
relationship between value MUST represent the entity

Fielding, Frystyk, Berners-Lee, Gettys, and some other resource. An entity
may include multiple Link values. Links at Mogul [Page 88]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

network location of the metainformation
level typically indicate relationships like hierarchical structure
and navigation paths. The Link field is semantically equivalent to origin server or gateway given by the <LINK> element in HTML [5].

Link = "Link" ":" #("<" URI ">"
[ ";" "rel" "=" relationship ]
[ ";" "rev" "=" relationship ]
[ ";" "title" "=" quoted-string ] )

relationship = sgml-name
| ( <"> sgml-name *( SP sgml-name) <"> )

sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )

Relationship values are case-insensitive and may be extended within
the constraints of original
URL. This allows the sgml-name syntax. The title parameter may be
used origin server or gateway to label the destination of a link differentiate between
internally-ambiguous URLs, such that it can be used as
identification within a human-readable menu.

Examples of usage include:

Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"

Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"

The first example indicates that chapter2 is previous to the
entity in root _/_ URL of a logical navigation path. The second indicates that the
person responsible server for making the resource available is identified
by the given e-mail
multiple host names on a single IP address.

10.27 Location

The Location response-header field defines the exact location of

Host = "Host" ":" host [ ":" port ] ; see Section 3.2.2

_host_ without any trailing port information implies the resource that was identified by default port
for the Request-URI. service requested (e.g., _80_ for an HTTP URL). For 2xx
responses, if the Request-URI corresponds to example, a negotiable set of
variants and the response includes one of those variants, then
request on the
response must also include a Location origin server for <http://www.w3.org/pub/WWW/> MUST
include:

GET /pub/WWW/ HTTP/1.1

Host: www.w3.org

The header field containing the
exact location of the chosen variant. For 3xx responses, the
location should indicate MUST be included in all HTTP/1.1 request messages A Host
on the server's preferred URL for automatic
redirection Internet (i.e., on any message corresponding to the resource. The field value consists of a single
absolute URL.

Location = "Location" ":" absoluteURI

An example is

Location: http://www.w3.org/pub/WWW/People.html

If no base request for a
URL is provided by or within the entity, which includes an Internet host address for the value of service being
requested). If the Location Host field should be used as the base for resolving
relative URLs [11].

10.28 MIME-Version

HTTP is not a MIME-compliant protocol (see Appendix C). However, already present, an HTTP/1.1 messages may include proxy
MUST add a single MIME-Version general-header Host field to indicate what version of the MIME protocol was used request message prior to
construct the message. Use of the MIME-Version header field
indicates that forwarding it on
the message is in full compliance Internet. All Internet-based HTTP/1.1 servers MUST respond with the MIME
protocol (as defined in [7]). Proxies/gateways are responsible for
ensuring full compliance (where possible) when exporting HTTP
messages a
400 status code to strict MIME environments.

MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

MIME version "1.0" is the default for use in HTTP/1.1. However, any HTTP/1.1 request message parsing and semantics are defined by this document
and not the MIME specification.

10.29 Pragma which lacks a Host
header field.

10.23 If-Modified-Since
The Pragma general-header If-Modified-Since request-header field is used with the GET method
to include
implementation-specific directives that may apply to any recipient
along make it conditional: if the request/response chain. All pragma directives specify
optional behavior from requested resource has not been modified
since the viewpoint time specified in this field, a copy of the protocol; however, some
systems may require that behavior resource will not
be consistent with returned from the directives.

Pragma server; instead, a 304 (not modified) response will
be returned without any Entity-Body.

If-Modified-Since = "Pragma" "If-Modified-Since" ":" 1#pragma-directive

pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]

When HTTP-date

An example of the "no-cache" directive is present in a request message, field is:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

A GET method with an
application should forward the request toward If-Modified-Since header and no Range header
requests that the origin server
even identified resource be transferred only if it has been
modified since the date given by the If-Modified-Since header. The
algorithm for determining this includes the following cases:

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

a)
If the request would normally result in anything other than a cached copy of what 200
(ok) status, or if the passed If-Modified-Since date is being requested. This
pragma directive has invalid, the
response is exactly the same semantics as the "no-cache"
cache-directive (see Section 10.8) and is defined here for
backwards compatibility with HTTP/1.0. Clients should include both
header fields when a "no-cache" request normal GET. A date which is sent to a server not
known to be HTTP/1.1 compliant.

Pragma directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
later than the server's current time is invalid.

b)
If the resource has been modified since the directives may be applicable to all recipients along If-Modified-Since date,
the
request/response chain. It response is not possible to specify a pragma exactly the same as for a specific recipient; however, any pragma directive normal GET.

c)
If the resource has not relevant to been modified since a recipient should be ignored by that recipient.

10.30 Proxy-Authenticate

The Proxy-Authenticate response-header field must be included as
part of valid If-Modified-Since
date, the server MUST return a 407 (proxy authentication required) 304 (not modified) response.
The field
value consists purpose of this feature is to allow efficient updates of cached
information with a challenge minimum amount of transaction overhead.

Note that indicates the authentication
scheme and parameters applicable to Range request-header field modifies the proxy meaning of
If-Modified-Since; see section 13.9 for this Request-URI.

Proxy-Authentication = "Proxy-Authentication" ":" challenge

The HTTP access authentication process full details.

Note that If-Modified-Since is described in Section 11.
Unlike WWW-Authenticate, the Proxy-Authenticate header field
applies only to ignored for varying resources.

Note that If-Modified-Since times are interpreted by the current connection and must server,
whose clock may not be passed on to
downstream clients.

10.31 Proxy-Authorization

The Proxy-Authorization request-header field allows synchronized with the client to
identify itself (or its user) to client.

Note that if a proxy which requires
authentication. The Proxy-Authorization field value consists of
credentials containing client uses an arbitrary date in the authentication information If-Modified-
Since header instead of a date taken from the user
agent Last-Modified
header for the proxy and/or realm same request, the client should be aware of the resource being requested.

Proxy-Authorization = "Proxy-Authorization" ":" credentials

The HTTP access authentication process
fact that this date is described interpreted in Section 11.
Unlike Authorization, the Proxy-Authorization applies only to the
current connection server's understanding
of time. The client should consider unsynchronized clocks and must not be passed on
rounding problems due to upstream servers.
If a request is authenticated the different representations of time
between the client and a realm specified, server. This includes the same
credentials should be valid possibility of
race conditions if the document has changed between the time it
was first request and the If-Modified-Since date of a subsequent
request, and the possibility of clock-skew-related problems if
the If-Modified-Date date is derived from the client's clock
without correction to the server's clock. Corrections for all other requests within this
realm.

10.32 Public
different time bases between client and server are at best
approximate due to network latency.

10.25 Last-Modified
The Public response-header Last-Modified entity-header field lists indicates the set date and time at
which the sender believes the resource was last modified. The exact
semantics of non-standard
methods supported this field are defined in terms of how the recipient SHOULD
interpret it: if the recipient has a copy of this resource which is
older than the date given by the server. Last-Modified field, that copy SHOULD
be considered stale.

Last-Modified = "Last-Modified" ":" HTTP-date

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

An example of its use is

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

The purpose exact meaning of this header field is
strictly to inform depends on the recipient implementation of
the capabilities sender and the nature of the server
regarding unusual methods. The methods listed original resource. For files, it may or be
just the file system last-modified time. For entities with dynamically
included parts, it may not be
applicable to the Request-URI; most recent of the Allow header field
(Section 10.5) should be used to indicate methods allowed set of last-modify
times for a
particular URI. This does not prevent a client from trying other
methods. The field value should not include its component parts. For database gateways, it may be the methods predefined
for HTTP/1.1 in Section 5.1.1.

Public = "Public" ":" 1#method

Example
last-update time stamp of use:

Public: OPTIONS, MGET, MHEAD

This header field applies only to the server directly connected to record. For virtual objects, it may be the client (i.e.,
last time the nearest neighbor in internal state changed.

An origin server MUST not send a chain Last-Modified date which is later than
the server's time of connections).
If message origination. In such cases, where the response passes through a proxy,
resource's last modification would indicate some time in the proxy must either
remove future, the Public header field or
server MUST replace it that date with one applicable to
its own capabilities.

10.33 Range

TBS

10.34 Referer

The Referer request-header field allows the client to specify, for the server's benefit, message origination date.

An origin server should obtain the address (URI) Last-Modified value of the resource from which entity as
close as possible to the Request-URI was obtained. time that it generates the Date value of its
response. This allows a server recipient to generate
lists make an accurate assessment of back-links to resources for interest, logging, optimized
caching, etc. It also allows obsolete or mistyped links to be
traced for maintenance. The Referer field must not be sent the
entity's modification time, especially if the
Request-URI was obtained from a source entity changes near the
time that does not have its own
URI, such as input from the user keyboard.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

If a partial URI response is given, it should be interpreted relative generated.

10.27 Location
The Location response-header field is used to redirect the
Request-URI. The URI must not include recipient to
a fragment.

Note: Because location other than the source Request-URI for completion of a link may be private
information the request or may reveal an otherwise private information
source, it
identification of a new resource. For 201 responses, the Location is strongly recommended
that of the user be able to
select whether or not new resource which was created by the Referer field is sent. request. For
example, a browser client could have a toggle switch for
browsing openly/anonymously, which would respectively
enable/disable 3xx
responses, the sending of Referer and From information.

10.35 Refresh

TBS

10.36 Retry-After

The Retry-After response-header field can be used with a 503
(service unavailable) response to location SHOULD indicate how long the service is
expected to be unavailable server's preferred URL for
automatic redirection to the requesting client. resource. The value of
this field can be either an HTTP-date or an integer number of
seconds (in decimal) after the time value consists of the response.

Retry-After a
single absolute URL.

Location = "Retry-After" "Location" ":" ( HTTP-date | delta-seconds )

Two examples of its use are

Retry-After: Wed, 14 Dec 1994 18:22:54 GMT
Retry-After: 120

In the latter example, the delay absoluteURI

An example is 2 minutes.

10.37 Server

Location: http://www.w3.org/pub/WWW/People.html

Note: The Server response-header Content-Location header field contains information about (Section 10.16) differs
from Location in that the
software used by former identifies the origin server to handle original
location of the entity enclosed in the request. The field
can It is therefore
possible for a response to contain multiple product tokens (Section 3.8) header fields for both
Location and comments
identifying Content-Location.

10.29 Pragma
The Pragma general-header field is used to include implementation-
specific directives that may apply to any recipient along the server
request/response chain. All pragma directives specify optional behavior
Fielding, Frystyk, Berners-Lee, Gettys, and any significant subproducts. By
convention, Mogul [Page 91]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

from the product tokens are listed in order viewpoint of their
significance for identifying the application.

Server = "Server" ":" 1*( product | comment )

Example:

Server: CERN/3.0 libwww/2.17

If protocol; however, some systems MAY require
that behavior be consistent with the response directives.

When the _no-cache_ directive is being forwarded through present in a proxy, the proxy request message, an
application must not add its data to SHOULD forward the product list. Instead, request toward the origin server even if
it
should include has a Forwarded field (as described in Section 10.20).

Note: Revealing the specific software version cached copy of what is being requested. This pragma directive Pragma = "Pragma" ":" 1#pragma-directive extension-pragma = token [ "=" word ]
has the server
may allow same semantics as the _no-cache_ cache-directive (see pragma-directive = "no-cache" | extension-pragma
Section 10.8) and is defined here for backwards compatibility with

HTTP/1.0. Clients SHOULD include both header fields when a _no-cache_
request is sent to a server machine not known to become more vulnerable be HTTP/1.1 compliant.

Pragma directives MUST be passed through by a proxy or gateway
application, regardless of their significance to
attacks against software that application, since
the directives may be applicable to all recipients along the
request/response chain. It is known not possible to contain security
holes. Server implementors are encouraged specify a pragma for a
specific recipient; however, any pragma directive not relevant to make this field a configurable option.

10.38 Title

The Title entity-header field indicates the title of
recipient SHOULD be ignored by that recipient.

HTTP/1.1 clients SHOULD NOT send the entity

Title = "Title" ":" *TEXT

An example of Pragma request header. HTTP/1.1
caches SHOULD treat _Pragma: no-cache_ as if the field is

Title: Hypertext Transfer Protocol -- HTTP/1.1

This field is isomorphic with the <TITLE> element client had sent _Cache-
control: no-cache_. No new Pragma directives will be defined in HTML [5].

10.39 Transfer Encoding HTTP.

10.30 Proxy-Authenticate
The Transfer-Encoding general-header Proxy-Authenticate response-header field indicates what (if any)
type MUST be included as part of transformation has been applied to the message body in
order to safely transfer it between the sender and the recipient.
This differs from the Content-Encoding in that the transfer coding
is
a property 407 (proxy authentication required) response. The field value consists
of a challenge that indicates the message, not of authentication scheme and parameters
applicable to the original resource.

Transfer-Encoding proxy for this Request-URI.

Proxy-Authentication = "Transfer-Encoding" "Proxy-Authentication" ":" 1#transfer-coding

Transfer codings are defined challenge

The HTTP access authentication process is described in Section 3.6. An example is:

Transfer-Encoding: chunked

Many older HTTP/1.0 applications do not understand 11.

Unlike WWW-Authenticate, the
Transfer-Encoding header.

10.40 Unless Proxy-Authenticate header field applies
only to the current connection and MUST not be passed on to downstream
clients.

10.31 Proxy-Authorization
The Unless Proxy-Authorization request-header field performs a similar function as
If-Modified-Since, but allows the comparison is based on any Entity-Header client to
identify itself (or its user) to a proxy which requires authentication.
Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 92]

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

The Proxy-Authorization field value consists of credentials containing
the resource and is not restricted to authentication information of the GET method.

Unless user agent for the proxy and/or
realm of the resource being requested.

Proxy-Authorization = "Unless" "Proxy-Authorization" ":" 1#logic-bag

For example,

Unless: {or {ne {Content-MD5 "Q2hlY2sgSW50ZWdyaXR5IQ=="}}
{ne {Content-Length 10036}}
{ne {Content-Version "12.4.8"}}
{gt {Last-Modified "Mon, 04 Dec 1995 01:23:45 GMT"}}}

Multiple Unless headers, or multiple bags separated by commas, can
be combined by OR'ing them together:

Unless: {eq {A "a"}}
Unless: {eq {B "b"}} credentials

The HTTP access authentication process is equivalent to

Unless: {eq {A "a"}},{eq {B "b"}}

which described in turn is equivalent Section 11.

Unlike Authorization, the Proxy-Authorization applies only to

Unless: {or {eq {A "a"}} {eq {B "b"}}}

When the
current connection and MUST not be passed on to upstream servers. If a
request containing an Unless header field is received, authenticated and a realm specified, the
server must evaluate same credentials
SHOULD be valid for all other requests within this realm.

10.32 Public
The Public response-header field lists the expression defined set of non-standard methods
supported by the listed
logic-bags (Section 3.11). If the expression evaluates to false,
then no change server. The purpose of this field is made strictly to inform
the semantics recipient of the request. If it
evaluates true and capabilities of the request is server regarding unusual
methods. The methods listed may or may not be applicable to the Request-
URI; the Allow header field (Section 10.5) SHOULD be used to indicate

methods allowed for a conditional GET
(If-Modified-Since, Section 10.23) or particular URI. This does not prevent a partial GET (Range, client
from trying other methods. The field value SHOULD not include the
methods predefined for HTTP/1.1 in Section 10.33), then 5.1.1.

Public = "Public" ":" 1#method

Example of use:

Public: OPTIONS, MGET, MHEAD

This header field applies only to the server must abort directly connected to the request and respond
with
client (i.e., the 412 (unless true) status code. nearest neighbor in a chain of connections). If the request is
response passes through a
conditional GET, then proxy, the server must disregard proxy MUST either remove the
If-Modified-Since value and respond as Public
header field or replace it would for a normal GET.
Similarly, if the with one applicable to its own capabilities.

10.33 Range
HTTP retrieval requests using conditional or unconditional GET methods
may request is a partial GET, then one or more sub-ranges of the server must
disregard entity, instead of the Range value and respond as entire
entity. This is done using the Range request header:

Range = "Range" ":" ranges-specifier

A server MAY ignore the Range header. However, HTTP/1.1 origin servers
and intermediate caches SHOULD support byte ranges whenever possible,

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

INTERNET-DRAFT HTTP/1.1 Monday, April 22, 1996

since this supports efficient recovery from partially failed transfers,
and it would supports efficient partial retrieval of large entities.

I the server supports the Range header and the specified range or ranges
are appropriate for a normal GET.

10.41 Upgrade the entity:

. The Upgrade general-header allows presence of a Range header in an unconditional GET modifies
what is returned if the client to specify GET is otherwise successful. In other
words, the response carries a status code of 206 (Partial content)
instead of 200 (OK).
. The presence of a Range header in a conditional GET (a request
using one or both of If-Modified-Since and If-Invalid, or one or
both of If-Unmodified-Since and If-Valid) modifies what
additional communication protocols it supports is returned
if the GET is otherwise successful and would like to
use the condition is true. It
does not affect the 304 (Not Modified) response returned if the server finds
conditional is false.
In some cases, it may be more appropriate to switch protocols. The
server must use the Upgrade Range-If header field within a 101 (switching
protocols) response to indicate which protocol(s) are being
switched.

Upgrade = "Upgrade" ":" 1#product

For example,

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

The purpose
(see section 10.104) instead of the Upgrade header is to allow easier migration
across protocols in order to better match the application needs
with protocol capabilities.

10.42 URI Range header.

10.34 Referer
The URI entity-header Referer(sic) request-header field is used allows the client to inform specify, for
the recipient server's benefit, the address (URI) of
other Uniform Resource Identifiers (Section 3.2) by which the resource can be identified, and from which the
Request-URI was obtained. This allows a server to generate lists of all negotiable variants
corresponding
back-links to resources for interest, logging, optimized caching, etc.
It also allows obsolete or mistyped links to be traced for maintenance.
The Referer field MUST not be sent if the Request-URI.

URI-header Request-URI was obtained from
a source that does not have its own URI, such as input from the user
keyboard.

Referer = "URI" "Referer" ":" 1#( uri-mirror | uri-name