- From: Paul Leach <paulle@microsoft.com>
- Date: Fri, 3 May 1996 00:27:38 -0700
- To: "'internet-drafts@cnri.reston.va.us'" <internet-drafts@cnri.reston.va.us>, "'masinter@parc.xerox.com'" <masinter@parc.xerox.com>, "'jg@w3.org'" <jg@w3.org>
- Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'PaulLeach@msn.com'" <PaulLeach@msn.com>
Here is the plain text version..
Paul Leach
>============
>
>
>
>
>
>
>
>
>HTTP Working Group R. Fielding, UC
>Irvine
>INTERNET-DRAFT H. Frystyk,
>MIT/LCS
><draft-ietf-http-v11-spec-03.html> T. Berners-Lee,
>MIT/LCS
> J. Gettys,
>DEC
> J. C. Mogul,
>DEC
>Expires October 2, 1996 May 2,
>1996
>
> Hypertext Transfer Protocol -- HTTP/1.1
>
>
>1 Status of this Memo
>This document is an Internet-Draft. Internet-Drafts are working
>documents of the Internet Engineering Task Force (IETF), its areas, and
>its working groups. Note that other groups may also distribute working
>documents as Internet-Drafts.
>
>Internet-Drafts are draft documents valid for a maximum of six months
>and may be updated, replaced, or made obsolete by other documents at
>any
>time. It is inappropriate to use Internet-Drafts as reference material
>or to cite them other than as "work in progress".
>
>To learn the current status of any Internet-Draft, please check the
>"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
>Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
>munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
>ftp.isi.edu (US West Coast).
>
>Distribution of this document is unlimited. Please send comments to the
>HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions of the
>working group are archived at
><URL:http://www.ics.uci.edu/pub/ietf/http/>. General discussions about
>HTTP and the applications which use HTTP should take place on the <www-
>talk@w3.org> mailing list.
>
> NOTE: This specification is for discussion purposes only. It is not
> claimed to represent the consensus of the HTTP working group, and
> contains a number of proposals that either have not been discussed
> or are controversial. The working group is discussing significant
> changes in many areas, including - support for caching, persistent
> connections, range retrieval, content negotiation, MIME
> compatibility, authentication, timing of the PUT operation.
>
>
>2 Abstract
>The Hypertext Transfer Protocol (HTTP) is an application-level protocol
>for distributed, collaborative, hypermedia information systems. It is a
>generic, stateless, object-oriented protocol which can be used for many
>tasks, such as name servers and distributed object management systems,
>through extension of its request methods (commands). A feature of HTTP
>is the typing and negotiation of data representation, allowing systems
>to be built independently of the data being transferred.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 1]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>HTTP has been in use by the World-Wide Web global information
>initiative
>since 1990. This specification defines the protocol referred to as
>"HTTP/1.1".
>
>3 Note to Readers of This Document
>
>
>We believe this draft to be very close to consensus of the working
>group
>in terms of functionality for HTTP/1.1, and the text substantially
>correct. One final technical change NOT reflected in this draft is to
>make persistent connections the default behavior for HTTP/1.1;
>editorial
>changes to reflect this in the next, and we hope final draft, are being
>circulated in the working group mailing list.
>
>This draft has undergone extensive reorganization to improve
>presentation. Let us know if there are remaining problems.
>
>The terminology used in this draft has changed to reduce confusion.
>While we are converging on a shared set of terminology and definitions,
>it is possible there will be a final set of terminology adopted in the
>next draft. Despite any terminology changes that may occur to improve
>the presentation of the specification, we do not expect to change the
>name of any header field or parameter name.
>
>There are a very few remaining issues indicated by Editor's Note: in
>bold font.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 2]
>
>
>
>
>
>
>
>4 Table of Contents
>
>
>HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1
>1
>
>1 Status of this Memo
>1
>
>2 Abstract
>1
>
>3 Note to Readers of This Document
>2
>
>4 Table of Contents
>3
>
>5 Introduction
>7
> 5.1 Purpose
>7
> 5.2 Requirements
>7
> 5.3 Terminology
>8
> 5.4 Overall Operation
>11
> 5.5 HTTP and MIME
>13
>
>6 Notational Conventions and Generic Grammar
>13
> 6.1 Augmented BNF
>13
> 6.2 Basic Rules
>14
>
>7 Protocol Parameters
>16
> 7.1 HTTP Version
>16
> 7.2 Uniform Resource Identifiers
>17
> 7.3 Date/Time Formats
>19
> 7.4 Character Sets
>21
> 7.5 Content Codings
>22
> 7.6 Transfer Codings
>23
> 7.7 Media Types
>24
> 7.8 Product Tokens
>26
> 7.9 Quality Values
>26
> 7.10 Language Tags
>27
> 7.11 Entity Tags
>27
> 7.12 Variant IDs
>28
> 7.13 Variant Sets
>28
> 7.14 Range Protocol Parameters
>28
>
>8 HTTP Message
>31
> 8.1 Message Types
>31
> 8.2 Message Headers
>31
> 8.3 General Header Fields
>32
>
>9 Request
>32
> 9.1 Request-Line
>33
> 9.2 The Resource Identified by a Request
>35
> 9.3 Request Header Fields
>35
>
>10 Response
>36
> 10.1 Status-Line
>36
> 10.2 Response Header Fields
>38
>
>Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 3]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>11 Entity
>38
> 11.1 Entity Header Fields
>39
> 11.2 Entity Body
>39
>
>12 Status Code Definitions
>41
> 12.1 Informational 1xx
>41
> 12.2 Successful 2xx
>41
> 12.3 Redirection 3xx
>43
> 12.4 Client Error 4xx
>45
> 12.5 Server Error 5xx
>49
>
>13 Method Definitions
>50
> 13.1 OPTIONS
>50
> 13.2 GET
>51
> 13.3 HEAD
>51
> 13.4 POST
>51
> 13.5 PUT
>54
> 13.6 DELETE
>55
> 13.7 TRACE
>55
>
>14 Access Authentication
>56
> 14.1 Basic Authentication Scheme
>57
> 14.2 Digest Authentication Scheme
>58
>
>15 Content Negotiation
>58
> 15.1 Negotiation Facilities Defined in this Specification
>59
>
>16 Caching in HTTP
>59
> 16.1 Semantic Transparency
>59
> 16.2 Expiration Model
>63
> 16.3 Validation Model
>68
> 16.4 Constructing Responses From Caches
>73
> 16.5 Caching and Generic Resources
>75
> 16.6 Shared and Non-Shared Caches
>76
> 16.7 Selecting a Cached Response
>77
> 16.8 Errors or Incomplete Response Cache Behavior
>77
> 16.9 Side Effects of GET and HEAD
>78
> 16.10 Invalidation After Updates or Deletions
>78
> 16.11 Write-Through Mandatory
>79
> 16.12 Generic Resources and HTTP/1.0 Proxy Caches
>79
> 16.13 Cache Replacement
>80
> 16.14 Caching of Negative Responses
>80
> 16.15 History Lists
>80
>
>17 Persistent Connections
>80
> 17.1 Purpose
>80
> 17.2 Overall Operation
>81
> 17.3 Proxy Servers
>82
> 17.4 Interaction with Security Protocols
>82
> 17.5 Practical Considerations
>83
>
>18 Header Field Definitions
>83
> 18.1 Accept
>83
> 18.2 Accept-Charset
>85
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 4]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> 18.3 Accept-Encoding
>86
> 18.4 Accept-Language
>86
> 18.5 Accept-Ranges
>87
> 18.6 Age
>88
> 18.7 Allow
>88
> 18.8 Alternates
>89
> 18.9 Authorization
>89
> 18.10 Cache-Control
>90
> 18.11 Connection
>96
> 18.12 Content-Base
>97
> 18.13 Content-Encoding
>97
> 18.14 Content-Language
>97
> 18.15 Content-Length
>98
> 18.16 Content-Location
>99
> 18.17 Content-MD5
>99
> 18.18 Content-Range
>100
> 18.19 Content-Type
>101
> 18.20 Date
>102
> 18.21 ETag
>102
> 18.22 Expires
>103
> 18.23 From
>104
> 18.24 Host
>104
> 18.25 If-Modified-Since
>105
> 18.26 If-Match
>106
> 18.27 If-NoneMatch
>107
> 18.28 If-Range
>108
> 18.29 If-Unmodified-Since
>108
> 18.30 Last-Modified
>109
> 18.31 Location
>109
> 18.32 Max-Forwards
>110
> 18.33 Persist
>110
> 18.34 Pragma
>111
> 18.35 Proxy-Authenticate
>111
> 18.36 Proxy-Authorization
>111
> 18.37 Public
>112
> 18.38 Range
>112
> 18.39 Referer
>113
> 18.40 Retry-After
>113
> 18.41 Server
>113
> 18.42 Title
>114
> 18.43 Transfer Encoding
>114
> 18.44 Upgrade
>114
> 18.45 User-Agent
>115
> 18.46 Vary
>116
> 18.47 Via
>118
> 18.48 Warning
>120
> 18.49 WWW-Authenticate
>121
>
>19 Security Considerations
>121
> 19.1 Authentication of Clients
>122
> 19.2 Safe Methods
>123
> 19.3 Abuse of Server Log Information
>123
> 19.4 Transfer of Sensitive Information
>123
> 19.5 Attacks Based On File and Path Names
>124
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 5]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> 19.6 Personal Information
>124
> 19.7 Privacy Issues Connected to Accept headers
>124
> 19.8 DNS Spoofing
>125
> 19.9 Location Headers and Spoofing
>126
>
>20 Acknowledgments
>126
>
>21 References
>127
>
>22 Authors' Addresses
>130
>
>23 Appendices
>131
> 23.1 Internet Media Type message/http
>131
> 23.2 Tolerant Applications
>131
> 23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message
> Bodies
>132
> 23.4 Changes from HTTP/1.0
>134
> 23.5 Additional Features
>135
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 6]
>
>
>
>
>
>
>5 Introduction
>5.1 Purpose
>The Hypertext Transfer Protocol (HTTP) is an application-level protocol
>for distributed, collaborative, hypermedia information systems. HTTP
>has
>been in use by the World-Wide Web global information initiative since
>1990. The first version of HTTP, referred to as HTTP/0.9, was a simple
>protocol for raw data transfer across the Internet. HTTP/1.0, as
>defined
>by RFC xxxx , 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 , caching, the need for persistent connections and
>virtual hosts.. In addition, the proliferation of incompletely-
>implemented applications calling themselves "HTTP/1.0" has necessitated
>a protocol version change in order for two communicating applications
>to
>determine each other's true capabilities.
>
>This specification defines the protocol referred to as "HTTP/1.1". This
>protocol is backwards-compatible with HTTP/1.0, but includes more
>stringent requirements in order to ensure reliable implementation of
>its
>features.
>
>Practical information systems require more functionality than simple
>retrieval, including search, front-end update, and annotation. HTTP
>allows an open-ended set of methods that indicate the purpose of a
>request. It builds on the discipline of reference provided by the
>Uniform Resource Identifier (URI) , as a location (URL) or name (URN)
>,
>for indicating the resource to which a method is to be applied.
>Messages
>are passed in a format similar to that used by Internet Mail and the
>Multipurpose Internet Mail Extensions (MIME) .
>
>HTTP is also used as a generic protocol for communication between user
>agents and proxies/gateways to other Internet protocols, such as SMTP ,
>NNTP , FTP , Gopher , and WAIS , allowing basic hypermedia access to
>resources available from diverse applications and simplifying the
>implementation of user agents.
>
>
>5.2 Requirements
>This specification uses the same words as RFC 1123 for defining the
>significance of each particular requirement. These words are:
>
>
>MUST
> This word or the adjective "required" means that the item is an
> absolute requirement of the specification.
>
>SHOULD
> This word or the adjective "recommended" means that there may
>exist
> valid reasons in particular circumstances to ignore this item, but
> the full implications should be understood and the case carefully
> weighed before choosing a different course.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys and Mogul [Page 7]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>MAY
> This word or the adjective "optional" means that this item is
>truly
> optional. One vendor may choose to include the item because a
> particular marketplace requires it or because it enhances the
> product, for example; another vendor may omit the same item.
>An implementation is not compliant if it fails to satisfy one or more
>of
>the MUST requirements for the protocols it implements. An
>implementation
>that satisfies all the MUST and all the SHOULD requirements for its
>protocols is said to be "unconditionally compliant"; one that satisfies
>all the MUST requirements but not all the SHOULD requirements for its
>protocols is said to be "conditionally compliant".
>
>
>5.3 Terminology
>This specification uses a number of terms to refer to the roles played
>by participants in, and objects of, the HTTP communication.
>
>
>connection
> A transport layer virtual circuit established between two programs
> for the purpose of communication.
>
>message
> The basic unit of HTTP communication, consisting of a structured
> sequence of octets matching the syntax defined in section 8 and
> transmitted via the connection.
>
>request
> An HTTP request message as defined in section 9.
>
>response
> An HTTP response message as defined in section 10.
>
>resource
> A network data object or service that can be identified by a URI
> (section 7.2). At any point in time, a resource may be either a
> plain resource, which corresponds to only one possible
> representation, or a generic resource.
>
>generic resource
> A resource that is a set of closely related representations of the
> same document, form, applet, etc. A generic resource is always
> identified by a URI. The individual representations may each be
> identified by a unique URI, or by the combination of the generic
> resource's URI and a variant-ID, or by the combination of the generic
> resource's URI and some "content-negotiation" mechanism. In this
> case, other URIs may exist which identify a resource more
> specifically.
>
>plain resource
> A resource that is not a generic resource. A plain resource is
> always identified by a URI.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 8]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>entity
> The set of information transferred as the payload of a request or
> response An entity consists of metainformation in the form of
> Entity-Header fields and content in the form of an Entity-Body, as
> described in section 11.
>
>resource entity
> A specific representation, rendition, encoding, or presentation of a
> network data object or service, either a plain resource or a specific
> member of a generic resource. A resource entity might be identified
> by a URI, or by the combination of a URI and a variant-ID, or by the
> combination of a URI and some other mechanism. An plain resource MUST
> be bound to a single resource entity at any instant in time.
>
>variant
> A resource entity that is a member of at least one generic resource.
> Sometimes called a resource variant. Note that the set of variants
> of a generic resource may change over time as well.
>
>content negotiation
> The mechanism for selecting the appropriate variant of a generic
> resource when servicing a request, as described in section 15.
>
>entity tag
> An opaque string associated with an entity and used to distinguish it
> from other entities of the requested resource . A "strong entity
> tag" is one that may be shared by two entities of a resource only if
> they are equivalent by octet equality. A "weak entity tag" is one
> that may be shared by two entities of a resource if they are
> equivalent and could be substituted for each other with no
> significant change in semantics. A given entity tag value may be
> used for entities obtained by requests on different URIs without
> implying anything about the equivalence of these entities.
>
>client
> An application program that establishes connections for the purpose
> of sending requests.
>
>user agent
> The client which initiates a request. These are often browsers,
> editors, spiders (web-traversing robots), or other end user tools.
>
>server
> An application program that accepts connections in order to service
> requests by sending back responses. Any given program MAY be capable
> of being both a client and a server; our use of these terms refers
> only to the role being performed by the program for a particular
> connection, rather than to the program's capabilities in general.
> Likewise, any server MAY act as an origin server, proxy, gateway, or
> tunnel, switching behavior based on the nature of each request.
>
>origin server
> The server on which a given resource resides or is to be created.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 9]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>proxy
> An intermediary program which acts as both a server and a client for
> the purpose of making requests on behalf of other clients. Requests
> are serviced internally or by passing them on, with possible
> translation, to other servers. A proxy MUST interpret and, if
> necessary, rewrite a request message before forwarding it. Proxies
> are often used as client-side portals through network firewalls and
> as helper applications for handling requests via protocols not
> implemented by 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
> An intermediary program which is acting as a blind relay between two
> connections. Once active, a tunnel is not considered a party to the
> HTTP communication, though the tunnel may have been initiated by an
> HTTP request. The tunnel ceases to exist when both ends of the
> relayed connections are closed. Tunnels are used when a portal is
> necessary and the intermediary cannot, or should not, interpret the
> relayed communication.
>
>cache
> A program's local store of response messages and the subsystem that
> controls its message storage, retrieval, and deletion. A cache stores
> cachable responses in order to reduce the response time and network
> bandwidth consumption on future, equivalent requests. Any client or
> server MAY include a cache, though a cache cannot be used by a server
> that acts acting as a tunnel.
>
>cachable
> A response is cachable if a cache is allowed to store a copy of the
> response message for use in answering subsequent requests. The rules
> for determining the cachability of HTTP responses are defined in
> Section 16. Even if a resource is cachable, there may be additional
> constraints on when and if a cache can use the cached copy for a
> particular request.
>
>firsthand
> A response is firsthand if it comes directly and without unnecessary
> delay from the origin server, perhaps via one or more proxies. A
> response is also firsthand if its validity has just been checked
> directly with the origin server.
>
>explicit expiration time
> The time at which the origin server intends that an entity should no
> longer be returned by a cache without further validation.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 10]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>heuristic expiration time
> An expiration time assigned by a cache when no explicit expiration
> time is available.
>
>age
> The age of a response is the time since it was generated by, or
> successfully validated with, the origin server.
>
>freshness lifetime
> The length of time between the generation of a response and its
> expiration time.
>
>fresh
> A response is fresh if its age has not yet exceeded its freshness
> lifetime.
>
>stale
> A response is stale if its age has passed its freshness lifetime. A
> cache may use a fresh response without validating it, but "normally"
> may not use a stale response without first validating it.
> ("Normally" means "unless configured to provide better performance at
> the expense of transparency.")
> Therefore, what expires is the cache's authority to use a cached
> response, without validation, in its reply to a subsequent request.
>
>semantically transparent
> Ideally, an HTTP/1.1 cache would be "semantically transparent." That
> is, use of the cache would not affect either the clients or the
> servers in any way except to improve performance. When a client makes
> a request via a semantically transparent cache, it receives exactly
> the same entity headers and entity body it would have received if it
> had made the same request to the origin server, at the same time.
>
>validator
> An entity tag, or a Last-Modified time, which is used to find out
> whether a cache entry is a semantically transparent copy of a
> resource entity. A cache entry is semantically transparent if its
> validator exactly matches the validator that the server would provide
> for current instance of that resource entity.
>
>5.4 Overall Operation
>The HTTP protocol is a request/response protocol. A client sends a
>request to the server in the form of a request method, URI, and
>protocol
>version, followed by a MIME-like message containing request modifiers,
>client information, and possible body content over a connection with a
>server. The server responds with a status line, including the message's
>protocol version and a success or error code, followed by a MIME-like
>message containing server information, entity metainformation, and
>possible entity body content.
>
>Most HTTP communication is initiated by a user agent and consists of a
>request to be applied to a resource on some origin server. In the
>simplest case, this may be accomplished via a single connection (v)
>between the user agent (UA) and the origin server (O).
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 11]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> request chain ------------------------>
> UA -------------------v------------------- O
> <----------------------- response chain
>
>A more complicated situation occurs when one or more intermediaries are
>present in the request/response chain. There are three common forms of
>intermediary: proxy, gateway, and tunnel. A proxy is a forwarding
>agent,
>receiving requests for a URI in its absolute form, rewriting all or
>part
>of the message, and forwarding the reformatted request toward the
>server
>identified by the URI. A gateway is a receiving agent, acting as a
>layer
>above some other server(s) and, if necessary, translating the requests
>to the underlying server's protocol. A tunnel acts as a relay point
>between two connections without changing the messages; tunnels are used
>when the communication needs to pass through an intermediary (such as a
>firewall) even when the intermediary cannot understand the contents of
>the messages.
>
> request chain -------------------------------------->
> UA -----v----- A -----v----- B -----v----- C -----v----- O
> <------------------------------------- response chain
>
>The figure above shows three intermediaries (A, B, and C) between the
>user agent and origin server. A request or response message that
>travels
>the whole chain MUST pass through four separate connections. This
>distinction is important because some HTTP communication options may
>apply only to the connection with the nearest, non-tunnel neighbor,
>only
>to the end-points of the chain, or to all connections along the chain.
>Although the diagram is linear, each participant may be engaged in
>multiple, simultaneous communications. For example, B may be receiving
>requests from many clients other than A, and/or forwarding requests to
>servers other than C, at the same time that it is handling A's request.
>
>Any party to the communication which is not acting as a tunnel may
>employ an internal cache for handling requests. The effect of a cache
>is
>that the request/response chain is shortened if one of the participants
>along the chain has a cached response applicable to that request. The
>following illustrates the resulting chain if B has a cached copy of an
>earlier response from O (via C) for a request which has not been cached
>by UA or A.
>
> request chain ---------->
> UA -----v----- A -----v----- B - - - - - - C - - - - - - O
> <--------- response chain
>
>Not all responses are cachable, and some requests may contain modifiers
>which place special requirements on cache behavior. HTTP requirements
>for cache behavior and cachable responses are defined in section 16.
>
>HTTP communication usually takes place over TCP/IP connections. The
>default port is TCP 80 , but other ports can be used. This does not
>preclude HTTP from being implemented on top of any other protocol on
>the
>Internet, or on other networks. HTTP only presumes a reliable
>transport;
>any protocol that provides such guarantees can be used; the mapping of
>the HTTP/1.1 request and response structures onto the transport data
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 12]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>units of the protocol in question is outside the scope of this
>specification.
>
>However, HTTP/1.1 implementations SHOULD implement persistent
>connections (See section 17). Both clients and servers MUST be capable
>of handling cases where either party closes the connection prematurely,
>due to user action, automated time-out, or program failure. In any
>case,
>the closing of the connection by either or both parties always
>terminates the current request, regardless of its status.
>
>
>5.5 HTTP and MIME
>HTTP/1.1 uses many of the constructs defined for MIME, as defined in
>RFC
>1521 . Appendix 23.3 describes the ways in which the context of HTTP
>allows for different use of Internet Media Types than is typically
>found
>in Internet mail, and gives the rationale for those differences.
>
>
>6 Notational Conventions and Generic Grammar
>
>6.1 Augmented BNF
>All of the mechanisms specified in this document are described in both
>prose and an augmented Backus-Naur Form (BNF) similar to that used by
>RFC 822 . 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 (foo | bar) elem)" allows the token sequences "elem
> foo elem" and "elem bar elem".
>
>*rule
> The character "*" preceding an element indicates repetition. The
> full form is "<n>*<m>element" indicating at least <n> and at most
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 13]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> <m> occurrences of element. Default values are 0 and infinity so
> that "*(element)" allows any number, including zero; "1*element"
> requires at least one; and "1*2element" allows one or two.
>
>[rule]
> Square brackets enclose optional elements; "[foo bar]" is
> equivalent to "*1(foo bar)".
>
>N rule
> Specific repetition: "<n>(element)" is equivalent to
> "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
> Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
> alphabetic characters.
>
>#rule
> A construct "#" is defined, similar to "*", for defining lists of
> elements. The full form is "<n>#<m>element " indicating at least
> <n> and at most <m> elements, each separated by one or more commas
> (",") and optional linear whitespace (LWS). This makes the usual
> form of lists very easy; a rule such as "( *LWS element *( *LWS
>","
> *LWS element )) " can be shown as "1#element". Wherever this
> construct is used, null elements are allowed, but do not
>contribute
> to the count of elements present. That is, "(element), , (element)
> " is permitted, but counts as only two elements. Therefore, where
> at least one element is required, at least one non-null element
> MUST be present. Default values are 0 and infinity so that
> "#(element) " allows any number, including zero; "1#element"
> requires at least one; and "1#2element" allows one or two.
>
>; comment
> A semi-colon, set off some distance to the right of rule text,
> starts a comment that continues to the end of line. This is a
> simple way of including useful notes in parallel with the
> specifications.
>
>implied *LWS
> The grammar described by this specification is word-based. Except
> where noted otherwise, linear whitespace (LWS) can be included
> between any two adjacent words (token or quoted-string), and
> between adjacent tokens and delimiters (tspecials), without
> changing the interpretation of a field. At least one delimiter
> (tspecials) MUST exist between any two tokens, since they would
> otherwise be interpreted as a single token. However, applications
> SHOULD attempt to follow "common form" when generating HTTP
> constructs, since there exist some implementations that fail to
> accept anything beyond the common forms.
>
>6.2 Basic Rules
>The following rules are used throughout this specification to describe
>basic parsing constructs. The US-ASCII coded character set is defined
>by
>.
>
> OCTET = <any 8-bit sequence of data>
> CHAR = <any US-ASCII character (octets 0 - 127)>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 14]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> UPALPHA = <any US-ASCII uppercase letter "A".."Z">
> LOALPHA = <any US-ASCII lowercase letter "a".."z">
> ALPHA = UPALPHA | LOALPHA
> DIGIT = <any US-ASCII digit "0".."9">
> CTL = <any US-ASCII control character
> (octets 0 - 31) and DEL (127)>
> CR = <US-ASCII CR, carriage return (13)>
> LF = <US-ASCII LF, linefeed (10)>
> SP = <US-ASCII SP, space (32)>
> HT = <US-ASCII HT, horizontal-tab (9)>
> <"> = <US-ASCII double-quote mark (34)>
>
>HTTP/1.1 defines the octet sequence CR LF as the end-of-line marker for
>all protocol elements except the Entity-Body (see appendix 23.2 for
>tolerant applications). The end-of-line marker within an Entity-Body is
>defined by its associated media type, as described in section 7.7.
>
> CRLF = CR LF
>
>HTTP/1.1 headers can be folded onto multiple lines if the continuation
>line begins with a space or horizontal tab. All linear whitespace,
>including folding, has the same semantics as SP.
>
> LWS = [CRLF] 1*( SP | HT )
>
>The TEXT rule is only used for descriptive field contents and values
>that are not intended to be interpreted by the message parser. Words of
>*TEXT MAY contain octets from character sets other than US-ASCII only
>when encoded according to the rules of RFC 1522 .
>
> TEXT = <any OCTET except CTLs,
> but including LWS>
>
>Recipients of header field TEXT containing octets outside the US-ASCII
>character set range MAY assume that they represent ISO-8859-1
>characters
>if there is no other encoding indicated by an RFC 1522 mechanism.
>
>Hexadecimal numeric characters are used in several protocol elements.
>
> HEX = "A" | "B" | "C" | "D" | "E" | "F"
> | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
>
>Many HTTP/1.1 header field values consist of words separated by LWS or
>special characters. These special characters MUST be in a quoted string
>to be used within a parameter value.
>
> word = token | quoted-string
>
> token = 1*<any CHAR except CTLs or tspecials>
>
> tspecials = "(" | ")" | "<" | ">" | "@"
> | "," | ";" | ":" | "\" | <">
> | "/" | "[" | "]" | "?" | "="
> | "{" | "}" | SP | HT
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 15]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Comments can be included in some HTTP header fields by surrounding the
>comment text with parentheses. Comments are only allowed in fields
>containing "comment" as part of their field value definition. In all
>other fields, parentheses are considered part of the field value.
>
> comment = "(" *( ctext | comment ) ")"
> ctext = <any TEXT excluding "(" and ")">
>
>A string of text is parsed as a single word if it is quoted using
>double-quote marks.
>
> quoted-string = ( <"> *(qdtext) <"> )
>
>
> qdtext = <any CHAR except <"> and CTLs,
> but including LWS>
>
>The backslash character ("\") may be used as a single-character quoting
>mechanism only within quoted-string and comment constructs.
>
> quoted-pair = "\" CHAR
>
>
>7 Protocol Parameters
>
>7.1 HTTP Version
>HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of
>the protocol. The protocol versioning policy is intended to allow the
>sender to indicate the format of a message and its capacity for
>understanding further HTTP communication, rather than the features
>obtained via that communication. No change is made to the version
>number
>for the addition of message components which do not affect
>communication
>behavior or which only add to extensible field values. The <minor>
>number is incremented when the changes made to the protocol add
>features
>which do not change the general message parsing algorithm, but which
>may
>add to the message semantics and imply additional capabilities of the
>sender. The <major> number is incremented when the format of a message
>within the protocol is changed.
>
>The version of an HTTP message is indicated by an HTTP-Version field in
>the first line of the message. If the protocol version is not
>specified,
>the recipient MUST assume that the message is in the simple HTTP/0.9
>format .
>
> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
>
>Note that the major and minor numbers SHOULD be treated as separate
>integers and that each MAY be incremented higher than a single digit.
>Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
>lower
>than HTTP/12.3. Leading zeros SHOULD be ignored by recipients and never
>generated by senders.
>
>Applications sending Full-Request or Full-Response messages, as defined
>by this specification, MUST include an HTTP-Version of "HTTP/1.1". Use
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 16]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>of this version number indicates that the sending application is at
>least conditionally compliant with this specification.
>
>Proxy and gateway applications MUST be careful in forwarding requests
>that are received in a format different from that of the application's
>native HTTP version. Since the protocol version indicates the protocol
>capability of the sender, a proxy/gateway MUST never send a message
>with
>a version indicator which is greater than its native version; if a
>higher version request is received, the proxy/gateway MUST either
>downgrade the request version, respond with an error, or switch to
>tunnel behavior. Requests with a version lower than that of the
>application's native format MAY be upgraded before being forwarded; the
>proxy/gateway's response to that request MUST follow the server
>requirements listed above.
>
> Note: Converting between versions of HTTP may involve addition or
> deletion of headers required or forbidden by the version involved.
> It is likely more involved than just changing the version
> indicator.
>
>
>7.2 Uniform Resource Identifiers
>URIs have been known by many names: WWW addresses, Universal Document
>Identifiers, Universal Resource Identifiers , and finally the
>combination of Uniform Resource Locators (URL) and Names (URN) . As
>far
>as HTTP is concerned, Uniform Resource Identifiers are simply formatted
>strings which identify--via name, location, or any other
>characteristic-
>-a network resource.
>
>
>7.2.1 General Syntax
>URIs in HTTP can be represented in absolute form or relative to some
>known base URI , depending upon the context of their use. The two forms
>are differentiated by the fact that absolute URIs always begin with a
>scheme name followed by a colon.
>
> URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
>
> absoluteURI = scheme ":" *( uchar | reserved )
>
> relativeURI = net_path | abs_path | rel_path
>
> net_path = "//" net_loc [ abs_path ] abs_path
>= "/" rel_path
> rel_path = [ path ] [ ";" params ] [ "?" query ]
>
> path = fsegment *( "/" segment )
> fsegment = 1*pchar
> segment = *pchar
>
> params = param *( ";" param )
> param = *( pchar | "/" )
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 17]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
> net_loc = *( pchar | ";" | "?" )
> query = *( uchar | reserved )
> fragment = *( uchar | reserved )
>
> pchar = uchar | ":" | "@" | "&" | "=" | "+"
> uchar = unreserved | escape
> unreserved = ALPHA | DIGIT | safe | extra | national
>
> escape = "%" HEX HEX
> reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
> extra = "!" | "*" | "'" | "(" | ")" | ","
> safe = "$" | "-" | "_" | "."
> unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
> national = <any OCTET excluding ALPHA, DIGIT,
> reserved, extra, safe, and unsafe>
>
>For definitive information on URL syntax and semantics, see RFC 1738
>and RFC 1808 . The BNF above includes national characters not allowed
>in
>valid URLs as specified by RFC 1738, since HTTP servers are not
>restricted in the set of unreserved characters allowed to represent the
>rel_path part of addresses, and HTTP proxies may receive requests for
>URIs not defined by RFC 1738.
>
>The HTTP protocol does not place any a priori limit on the length of a
>URI. Servers MUST be able to handle the URI of any resource they
>serve, and SHOULD be able to handle URIs of unbounded length if they
>provide GET-based forms that could generate such URIs. A server SHOULD
>return a status code of
>
> 414 Request-URI Too Large
>
> if a URI is longer than the server can handle. See section 12.4.1.15.
>
> Note: Servers should be cautious about depending on URI lengths
> above 255 bytes, because some older client or proxy implementations
> may not properly support these.
>
> All client and proxy implementations MUST be able to handle a URI of
>any finite length.
>
>
>7.2.2 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
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 18]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>If the port is empty or not given, port 80 is assumed. The semantics
>are
>that the identified resource is located at the server listening for TCP
>connections on that port of that host, and the Request-URI for the
>resource is abs_path. The use of IP addresses in URL's SHOULD be
>avoided whenever possible. See RFC 1900. If the abs_path is not
>present in the URL, it MUST be given as "/" when used as a Request-URI
>for a resource (section 9.1.2).
>
> Note: Although the HTTP protocol is independent of the transport
> layer protocol, the http URL only identifies resources by their TCP
> location, and thus non-TCP resources MUST be identified by some
> other URI scheme.
>
>The canonical form for "http" URLs is obtained by converting any
>UPALPHA
>characters in host to their LOALPHA equivalent (hostnames are case-
>insensitive), eliding the [ ":" port ] if the port is 80, and replacing
>an empty abs_path with "/".
>
>
>7.2.3 URI Canonicalization
>A cache, when comparing two URIs to decide if they match or not, a
>cache
>MUST use a case-sensitive octet-by-octet comparison of the entire URIs,
>with these exceptions:
>
>Following the rules from section 7.2.2:
>
> . A port that is empty or not given is equivalent to port 80.
> . Comparisons of host names MUST be case-insensitive.
> . Comparisons of scheme names MUST be case-insensitive.
> . An empty abs_path is equivalent to an abs_path of "/"
>Characters except those in the reserved set and the unsafe set (see
>section 7.2) are equivalent to their ""%" HEX HEX" encodings.
>
>For example, the following three URIs are equivalent:
>
> http://abc.com:80/~smith/home.html
> http://ABC.com/%7Esmith/home.html
> http://ABC.com:/%7esmith/home.html
>
>
>
>
>7.3 Date/Time Formats
>
>7.3.1 Full Date
>HTTP applications have historically allowed three different formats for
>the representation of date/time stamps:
>
> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
> Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
> Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
>
>The first format is preferred as an Internet standard and represents a
>fixed-length subset of that defined by RFC 1123 (an update to RFC 822
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 19]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>). The second format is in common use, but is based on the obsolete RFC
>850 date format and lacks a four-digit year. HTTP/1.1 clients and
>servers that parse the date value MUST accept all three formats, though
>they MUST generate only the RFC 1123 format for representing date/time
>stamps in HTTP message fields.
>
> Note: Recipients of date values are encouraged to be robust in
> accepting date values that may have been generated by non-HTTP
> applications, as is sometimes the case when retrieving or posting
> messages via proxies/gateways to SMTP or NNTP.
>
>All HTTP date/time stamps MUST be represented in Universal Time (UT),
>also known as Greenwich Mean Time (GMT), without exception. This is
>indicated in the first two formats by the inclusion of "GMT" as the
>three-letter abbreviation for time zone, and SHOULD be assumed when
>reading the asctime format.
>
> HTTP-date = rfc1123-date | rfc850-date | asctime-date
>
> rfc1123-date = wkday "," SP date1 SP time SP "GMT"
> rfc850-date = weekday "," SP date2 SP time SP "GMT"
> asctime-date = wkday SP date3 SP time SP 4DIGIT
>
> date1 = 2DIGIT SP month SP 4DIGIT
> ; day month year (e.g., 02 Jun 1982)
> date2 = 2DIGIT "-" month "-" 2DIGIT
> ; day-month-year (e.g., 02-Jun-82)
> date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
> ; month day (e.g., Jun 2)
>
> time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
> ; 00:00:00 - 23:59:59
>
> wkday = "Mon" | "Tue" | "Wed"
> | "Thu" | "Fri" | "Sat" | "Sun"
>
> weekday = "Monday" | "Tuesday" | "Wednesday"
> | "Thursday" | "Friday" | "Saturday" | "Sunday"
>
> month = "Jan" | "Feb" | "Mar" | "Apr"
> | "May" | "Jun" | "Jul" | "Aug"
> | "Sep" | "Oct" | "Nov" | "Dec"
>
> Note: HTTP requirements for the date/time stamp format apply only
> to their usage within the protocol stream. Clients and servers are
> not required to use these formats for user presentation, request
> logging, etc.
>
>Additional rules for requirements on parsing and representation of
>dates
>and other potential problems with date representations include:
>
> . HTTP/1.1 clients and caches should assume that an RFC-850 date
> which appears to be more than 50 years in the future is in fact in
> the past (this helps solve the "year 2000" problem).
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 20]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . An HTTP/1.1 implementation may internally represent a parsed
> Expires date as earlier than the proper value, but MUST NOT
> internally represent a parsed Expires date as later than the
>proper
> value.
> . All expiration-related calculations must be done in Universal Time
> (GMT). The local time zone MUST NOT influence the calculation or
> comparison of an age or expiration time.
> . If an HTTP header incorrectly carries a date value with a time
>zone
> other than GMT, it must be converted into GMT using the most
> conservative possible conversion.
>
>
>
>
>7.3.2 Delta Seconds
>Some HTTP header fields allow a time value to be specified as an
>integer
>number of seconds, represented in decimal, after the time that the
>message was received. This format SHOULD only be used to represent
>short
>time periods or periods that cannot start until receipt of the message.
>
> delta-seconds = 1*DIGIT
>
>
>7.4 Character Sets
>HTTP uses the same definition of the term "character set" as that
>described for MIME:
>
> The term "character set" is used in this document to refer to a
> method used with one or more tables to convert a sequence of octets
> into a sequence of characters. Note that unconditional conversion
> in the other direction is not required, in that not all characters
> may be available in a given character set and a character set may
> provide more than one sequence of octets to represent a particular
> character. This definition is intended to allow various kinds of
> character encodings, from simple single-table mappings such as US-
> ASCII to complex table switching methods such as those that use ISO
> 2022's techniques. However, the definition associated with a MIME
> character set name MUST fully specify the mapping to be performed
> from octets to characters. In particular, use of external profiling
> information to determine the exact mapping is not permitted.
>
> Note: This use of the term "character set" is more commonly
> referred to as a "character encoding." However, since HTTP and MIME
> share the same registry, it is important that the terminology also
> be shared.
>
>HTTP character sets are identified by case-insensitive tokens. The
>complete set of tokens is defined by the IANA Character Set registry .
>However, because that registry does not define a single, consistent
>token for each character set, we define here the preferred names for
>those character sets most likely to be used with HTTP entities. These
>character sets include those registered by RFC 1521 -- the US-ASCII
>and ISO-8859 character sets -- and other names specifically
>recommended
>for use within MIME charset parameters.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 21]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> charset = "US-ASCII"
> | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
> | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
> | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
> | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
> | "UNICODE-1-1" | "UNICODE-1-1-UTF-7"
> | "UNICODE-1-1-UTF-8" | token
>
>Although HTTP allows an arbitrary token to be used as a charset value,
>any token that has a predefined value within the IANA Character Set
>registry MUST represent the character set defined by that registry.
>Applications SHOULD limit their use of character sets to those defined
>by the IANA registry.
>
>The character set of an entity body SHOULD be labeled as the lowest
>common denominator of the character codes used within that body, with
>the exception that no label is preferred over the labels US-ASCII or
>ISO-8859-1.
>
>
>7.5 Content Codings
>Content coding values indicate an encoding transformation that has been
>or can be applied to a resource entity. Content codings are primarily
>used to allow a document to be compressed or encrypted without losing
>the identity of its underlying media type. Typically, the resource
>entity is stored in this encoding and only decoded before rendering or
>analogous usage.
>
> content-coding = "gzip" | "x-gzip"
> | "compress" | "x-compress" | token
>
> Note: For historical reasons, HTTP applications SHOULD consider "x-
> gzip" and "x-compress" to be equivalent to "gzip" and "compress",
> respectively.
>
>All content-coding values are case-insensitive. HTTP/1.1 uses content-
>coding values in the Accept-Encoding (section 18.3) and
>Content-Encoding
>(section 18.13) header fields. Although the value describes the
>content-
>coding, what is more important is that it indicates what decoding
>mechanism will be required to remove the encoding. Note that a single
>program MAY be capable of decoding multiple content-coding formats. Two
>values are defined by this specification:
>
>
>gzip
> An encoding format produced by the file compression program "gzip"
> (GNU zip) developed by Jean-loup Gailly. This format is typically
>a
> Lempel-Ziv coding (LZ77) with a 32 bit CRC.
>
>compress
> The encoding format produced by the file compression program
> "compress". This format is an adaptive Lempel-Ziv-Welch coding
> (LZW).
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 22]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Note: Use of program names for the identification of encoding
> formats is not desirable and should be discouraged for future
> encodings. Their use here is representative of historical practice,
> not good design.
>
>HTTP defines a registration process which uses the Internet Assigned
>Numbers Authority (IANA) as a central registry for content-coding value
>tokens. Additional content-coding value tokens beyond the four defined
>in this document (gzip x-gzip compress x-compress) SHOULD be
>registered
>with the IANA. To allow interoperability between clients and servers,
>specifications of the content coding algorithms used to implement a new
>value SHOULD be publicly available and adequate for independent
>implementation, and MUST conform to the purpose of content coding
>defined in this section.
>
>
>7.6 Transfer Codings
>Transfer coding values are used to indicate an encoding transformation
>that has been, can be, or may need to be applied to an Entity-Body in
>order to ensure safe transport through the network. This differs from a
>content coding in that the transfer coding is a property of the
>message,
>not of the original resource entity.
>
> transfer-coding = "chunked" | transfer-extension
>
> transfer-extension = token
>
>All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer
>coding values in the Transfer-Encoding header field (section 18.43).
>
>Transfer codings are analogous to the Content-Transfer-Encoding values
>of MIME , which were designed to enable safe transport of binary data
>over a 7-bit transport service. However, "safe transport" 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 11.2.2), or the desire to encrypt data
>over a shared transport.
>
>All HTTP/1.1 applications MUST be able to receive and decode the
>"chunked" transfer coding , and MUST ignore transfer coding extensions
>they do not understand. A server which receives a an entity-body with a
>transfer-coding it does not understand SHOULD return
>501(Unimplemented),
>and close the connection. A server MUST NOT send transfer-codings to a
>client that were not defined in the version of HTTP used in the
>client's
>request. Clients sending entity-bodies with transfer-codings SHOULD
>must
>be prepared for the connection to be closed if the server doesn't
>understand the transfer-coding. The chunked encoding modifies the body
>of a message in order to transfer it as a series of chunks, each with
>its own size indicator, followed by an optional footer containing
>entity-header fields. This allows dynamically-produced content to be
>transferred along with the information necessary for the recipient to
>verify that it has received the full message.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 23]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Chunked-Body = *chunk
> "0" CRLF
> footer
> CRLF
>
> chunk = chunk-size [ chunk-ext ] CRLF
> chunk-data CRLF
>
> chunk-size = hex-no-zero *HEX
> chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
> chunk-ext-name = token
> chunk-ext-val = token | quoted-string
> chunk-data = chunk-size(OCTET)
>
> footer = *<<Content-MD5 and future headers that specify
> they are allowed in footer>>
>
> hex-no-zero = <HEX excluding "0">
>
>Note that the chunks are 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 23.3.6.
>
>
>7.7 Media Types
>HTTP uses Internet Media Types in the Content-Type (section 18.19) and
>Accept (section 18.1) header fields in order to provide open and
>extensible data typing and type negotiation.
>
> media-type = type "/" subtype *( ";" parameter )
> type = token
> subtype = token
>
>Parameters may follow the type/subtype in the form of attribute/value
>pairs.
>
> parameter = attribute "=" value
> attribute = token
> value = token | quoted-string
>
>The type, subtype, and parameter attribute names are case-insensitive.
>Parameter values may or may not be case-sensitive, depending on the
>semantics of the parameter name. LWS MUST NOT be generated between the
>type and subtype, nor between an attribute and its value. Upon receipt
>of a media type with an unrecognized parameter, a user agent SHOULD
>treat the media type as if the unrecognized parameter and its value
>were
>not present.
>
>Some older HTTP applications do not recognize media type parameters.
>HTTP/1.1 applications SHOULD only use media type parameters when they
>are necessary to define the content of a message.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 24]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Media-type values are registered with the Internet Assigned Number
>Authority (IANA ). The media type registration process is outlined in
>RFC 1590 . Use of non-registered media types is discouraged.
>
>
>7.7.1 Canonicalization and Text Defaults
>Internet media types are registered with a canonical form. In general,
>an Entity-Body transferred via HTTP MUST be represented in the
>appropriate canonical form prior to its transmission; the exception is
>"text" types, as defined in the next paragraph..
>
>when in canonical form , media subtypes of the "text" type use CRLF as
>the text line break. However, HTTP allows the transport of text media
>with plain CR or LF alone representing a line break when if it is done
>consistently for an entire Entity-Body.. HTTP applications MUST accept
>CRLF, bare CR, and bare LF as being representative of a line break in
>text media received via HTTP.In addition, if the text media is
>represented in a character set that does not use octets 13 and 10 for
>CR
>and LF respectively, as is the case for some multi-byte character sets,
>HTTP allows the use of whatever octet sequences are defined by that
>character set to represent the equivalent of CR and LF for line breaks.
>This flexibility regarding line breaks applies only to text media in
>the
>Entity-Body; a bare CR or LF MUST NOT be substituted for CRLF within
>any
>of the HTTP control structures (such as header fields and multipart
>boundaries).
>
>If an Entity-Body is encoded with a Content-Encoding, the underlying
>data MUST be in a form defined above prior to being encoded.
>
>The "charset" parameter is used with some media types to define the
>character set (section 7.4) of the data. When no explicit charset
>parameter is provided by the sender, media subtypes of the "text" type
>are defined to have a default charset value of "ISO-8859-1" when
>received via HTTP. Data in character sets other than "ISO-8859-1" or
>its
>subsets MUST be labeled with an appropriate charset value in order to
>be
>consistently interpreted by the recipient.
>
> Note: Many current HTTP servers provide data using charsets other
> than "ISO-8859-1" without proper labeling. This situation reduces
> interoperability and is not recommended. To compensate for this,
> some HTTP user agents provide a configuration option to allow the
> user to change the default interpretation of the media type
> character set when no charset parameter is given.
>
>
>
>
>7.7.2 Multipart Types
>MIME provides for a number of "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 ,
>and MUST include a boundary parameter as part of the media type value.
>The message body is itself a protocol element and MUST therefore use
>only CRLF to represent line breaks between body-parts. Unlike in RFC
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 25]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>1521, the epilogue of any multipart message MUST be empty; HTTP
>applications MUST NOT transmit the epilogue even if the original
>resource entity contains an epilogue.
>
>In HTTP, multipart body-parts MAY contain header fields which are
>significant to the meaning of that part.
>
>In general, an HTTP user agent SHOULD follow the same or similar
>behavior as a MIME user agent would upon receipt of a multipart type.
>If
>an application receives an unrecognized multipart subtype, the
>application MUST treat it as being equivalent to "multipart/mixed".
>
> Note: The "multipart/form-data" type has been specifically defined
> for carrying form data suitable for processing via the POST request
> method, as described in RFC 1867 .
>
>
>
>
>7.8 Product Tokens
>Product tokens are used to allow communicating applications to identify
>themselves via a simple product token, with an optional slash and
>version designator. Most fields using product tokens also allow sub-
>products which form a significant part of the application to be listed,
>separated by whitespace. By convention, the products are listed in
>order
>of their significance for identifying the application.
>
> product = token ["/" product-version]
> product-version = token
>
>Examples:
>
> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
> Server: Apache/0.8.4
>
>Product tokens should be short and to the point -- use of them for
>advertising or other non-essential information is explicitly forbidden.
>Although any token character may appear in a product-version, this
>token
>SHOULD only be used for a version identifier (i.e., successive versions
>of the same product SHOULD only differ in the product-version portion
>of
>the product value).
>
>
>7.9 Quality Values
>HTTP content negotiation (section 15) uses short "floating point"
>numbers to indicate the relative importance ("weight") of various
>negotiable parameters. The weights are normalized to a real number in
>the range 0 through 1, where 0 is the minimum and 1 the maximum value.
>In order to discourage misuse of this feature, HTTP/1.1 applications
>MUST NOT generate more than three digits after the decimal point. User
>configuration of these values SHOULD also be limited in this fashion.
>
> qvalue = ( "0" [ "." 0*3DIGIT ] )
> | ( "1" [ "." 0*3("0") ] )
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 26]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>"Quality values" is a slight misnomer, since these values actually
>measure relative degradation in perceived quality. Thus, a value of
>"0.8" represents a 20% degradation from the optimum rather than a
>statement of 80% quality.
>
>
>7.10 Language Tags
>A language tag identifies a natural language spoken, written, or
>otherwise conveyed by human beings for communication of information to
>other human beings. Computer languages are explicitly excluded. HTTP
>uses language tags within the Accept-Language, and Content-Language
>fields.
>
>The syntax and registry of HTTP language tags is the same as that
>defined by RFC 1766 . In summary, a language tag is composed of 1 or
>more parts: A primary language tag and a possibly empty series of
>subtags:
>
> language-tag = primary-tag *( "-" subtag )
>
> primary-tag = 1*8ALPHA
> subtag = 1*8ALPHA
>
>Whitespace is not allowed within the tag and all tags are case-
>insensitive. The name space of language tags is administered by the
>IANA. Example tags include:
>
> en, en-US, en-cockney, i-cherokee, x-pig-latin
>
>where any two-letter primary-tag is an ISO 639 language abbreviation
>and
>any two-letter initial subtag is an ISO 3166 country code. (The last
>three tags above are not registered tags; all but the last are examples
>of tags which could be registered in future.)
>
>
>7.11 Entity Tags
>Entity tags are quoted strings whose internal structure is not visible
>to clients or caches. Entity tags are used as cache validators in
>HTTP/1.1.
>
> entity-tag = strong-entity-tag | weak-entity-tag
> | null-entity-tag
> strong-entity-tag = quoted-string
> weak-entity-tag = quoted-string "/W"
> null-entity-tag = <"> <">
>
> Note that the "/W" tag is considered part of a weak entity tag; it
> MUST NOT be removed by any cache or client.
>
>There are two comparison functions on validators:
>
> . The strong comparison function: in order to be considered equal,
> both validators must be identical in every way, and neither may be
> weak.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 27]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . The weak comparison function: in order to be considered equal,
>both
> validators must be identical in every way, except for the presence
> or absence of a "weak" tag.
>The weak comparison function MAY be used for simple (non-subrange) GET
>requests. The strong comparison function MUST be used in all other
>cases.
>
>The null validator is a special value, defined as never matching the
>current validator of an existing resource entity, and always matching
>the "current" validator of a resource entity that does not exist.
>
>
>7.12 Variant IDs
>A cache stores instances of resource entities, not instances of generic
>resources per se. Therefore, the URI of a generic resource is not
>sufficient for use as an identifier for a specific resource entity. In
>certain interactions between a cache and an origin server, it is
>convenient to encode that identifier using a more compact
>representation than the full set of selecting request headers (which
>may
>not even be possible if the selection criteria are not known to the
>cache).
>
>For these reasons, the HTTP protocol provides an optional mechanism for
>identifying a specific entity source of a generic resource, called a
>variant-ID.
>
>Variant-IDs are used to identify specific variants of a generic
>resource; see section 16.5.3 for how they are used.
>
> variant-id = quoted-string
>
>Variant-IDs are compared using string octet-equality; case is
>significant.
>
>All responses from generic resources SHOULD include variant-IDs. If
>these are not present, the resource author can expect caches to
>correctly handle requests on the generic resource, but cannot expect
>the
>caching to be efficient.
>
>
>
>
>7.13 Variant Sets
>Validator sets are used for doing conditional retrievals on generic
>resources; see section 16.5.3.
>
> variant-set = 1#variant-set-item
> variant-set-item = opaque-validator ";" variant-id
>
>
>7.14 Range Protocol Parameters
>This section defines certain HTTP protocol parameters used in range
>requests and related responses.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 28]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>7.14.1 Range Units
>A resource entity may be broken down into subranges according to
>various
>structural units.
>
> range-unit = bytes-unit | other-range-unit
>
> bytes-unit = "bytes"
> other-range-unit = token
>
>The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
>implementations may ignore ranges specified using other units.
>
>
>7.14.2 Byte Ranges
>Since all HTTP entities are represented in HTTP messages as sequences
>of
>bytes, the concept of a byte range is meaningful for any HTTP entity.
>(However, not all clients and servers need to support byte-range
>operations.)
>
>Byte range specifications in HTTP apply to the sequence of bytes that
>would be transferred by the protocol if no transfer-coding were being
>applied.
>
> This means that if Content-coding is applied to the data, the byte
> range specification applies to the resulting content-encoded byte
> stream, not to the unencoded byte stream. It also means that if
> the entity-body's media-type is a composite type (e.g., multipart/*
> and message/rfc822), then the composite's body-parts may have their
> own content-encoding and content-transfer-encoding, and the byte
> range applies to the result of the those encodings.
>
>A byte range operation may specify a single range of bytes, or a set of
>ranges within a single entity.
>
> ranges-specifier = byte-ranges-specifier
>
> byte-ranges-specifier = bytes-unit "=" byte-range-set
>
> byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
>
> byte-range-spec = first-byte-pos "-" [last-byte-pos]
>
> first-byte-pos = 1*DIGIT
>
> last-byte-pos = 1*DIGIT
>
>The first-byte-pos value in a byte-range-spec gives the byte-offset of
>the first byte in a range. The last-byte-pos value gives the byte-
>offset of the last byte in the range; that is, the byte positions
>specified are inclusive. Byte offsets start at zero.
>
>If the last-byte-pos value is present, it must be greater than or equal
>to the first-byte-pos in that byte-range-spec, or the byte-range-spec
>is
>invalid. The recipient of an invalid byte-range-spec must ignore it.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 29]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>If the last-byte-pos value is absent, it is assumed to be equal to the
>current length of the entity in bytes.
>
>If the last-byte-pos value is larger than the current length of the
>entity, it is assumed to be equal to the current length of the entity.
>
> suffix-byte-range-spec = "-" suffix-length
>
> suffix-length = 1*DIGIT
>
>A suffix-byte-range-spec is used to specify the suffix of the entity,
>of
>a length given by the suffix-length value. (That is, this form
>specifies the last N bytes of an entity.) If the entity is shorter
>than
>the specified suffix-length, the entire entity is used.
>
>Examples of byte-ranges-specifier values (assuming an entity of length
>10000):
>
> . The first 500 bytes (byte offsets 0-499, inclusive):
> bytes=0-499
>
> . The second 500 bytes (byte offsets 500-999, inclusive):
> bytes=500-999
>
> . The final 500 bytes (byte offsets 9500-9999, inclusive):
> bytes=-500
>
> . Or
> bytes=9500-
>
> . The first and last bytes only (bytes 0 and 9999):
> bytes=0-0,-1
>
> . Several legal but not canonical specifications of the second 500
> bytes (byte offsets 500-999, inclusive):
> bytes=500-600,601-999
>
> bytes=500-700,601-999
>
>
>7.14.3 Content Ranges
>When a server returns a partial response to a client, it must describe
>both the extent of the range covered by the response, and the length of
>the entire entity.
>
> content-range-spec = byte-content-range-spec
>
> byte-content-range-spec = bytes-unit SP first-byte-pos "-"
> last-byte-pos "/" entity-length
>
> entity-length = 1*DIGIT
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 30]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Unlike byte-ranges-specifier values, a byte-content-range-spec may only
>specify one range, and must contain absolute byte positions for both
>the
>first and last byte of the range.
>
>A byte-content-range-spec whose last-byte-pos value is less than its
>first-byte-pos value, or whose entity-length value is less than or
>equal
>to its last-byte-pos value, is invalid. The recipient of an invalid
>byte-content-range-spec MUST ignore it and any content transferred
>along
>with it.
>
>Examples of byte-content-range-spec values, assuming that the entity
>contains a total of 1234 bytes:
>
> . The first 500 bytes:
> bytes 0-499/1234
>
> . The second 500 bytes:
> bytes 500-999/1234
>
> . All except for the first 500 bytes:
> bytes 500-1233/1234
>
> . The last 500 bytes:
> bytes 734-1233/1234
>
>
>8 HTTP Message
>
>8.1 Message Types
>HTTP messages consist of requests from client to server and responses
>from server to client.
>
> HTTP-message = Full-Request ; HTTP/1.1 messages
> | Full-Response
>
>Full-Request and Full-Response use the generic message format of RFC
>822
>for transferring entities. Both messages may include optional header
>fields (also known as "headers") and an entity body. The entity body is
>separated from the headers by a null line (i.e., a line with nothing
>preceding the CRLF).
>
>
>8.2 Message Headers
>HTTP header fields, which include General-Header (Section 8.3),
>Request-
>Header (Section 9.2), Response-Header (Section 10.2), and Entity-Header
>(Section 11.1) fields, follow the same generic format as that given in
>Section 3.1 of RFC 822 . Each header field consists of a name followed
>by a colon (":") and the field value. Field names are case-insensitive.
>The field value may be preceded by any amount of LWS, though a single
>SP
>is preferred. Header fields can be extended over multiple lines by
>preceding each extra line with at least one SP or HT.
>
> HTTP-header = field-name ":" [ field-value ] CRLF
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 31]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> field-name = token
> field-value = *( field-content | LWS )
>
> field-content = <the OCTETs making up the field-value
> and consisting of either *TEXT or combinations
> of token, tspecials, and quoted-string>
>
>The order in which header fields with differing field names are
>received
>is not significant. However, it is "good practice" to send General-
>Header fields first, followed by Request-Header or Response-Header
>fields, and ending with the Entity-Header fields.
>
>Multiple HTTP-header fields with the same field-name may be present in
>a
>message if and only if the entire field-value for that header field is
>defined as a comma-separated list [i.e., #(values)]. It MUST be
>possible
>to combine the multiple header fields into one "field-name:
>field-value"
>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.
>
>
>8.3 General Header Fields
>There are a few header fields which have general applicability for both
>request and response messages, but which do not apply to the entity
>being transferred. These headers apply only to the message being
>transmitted.
>
> General-Header = Cache-Control ; Section 18.10
> | Connection ; Section 18.11
> | Date ; Section 18.20
> | Via ; Section 18.47
> | Keep-Alive ; Section 23.5.2.5.1
> | Pragma ; Section 18.34
> | Upgrade ; Section 18.44
>
>General header field names can be extended reliably only in combination
>with a change in the protocol version. However, new or experimental
>header fields may be given the semantics of general header fields if
>all
>parties in the communication recognize them to be general header
>fields.
>Unrecognized header fields are treated as Entity-Header fields.
>
>
>9 Request
>A request message from a client to a server includes, within the first
>line of that message, the method to be applied to the resource, the
>identifier of the resource, and the protocol version in use. For
>backwards compatibility with the more limited HTTP/0.9 protocol, there
>are two valid formats for an HTTP request:
>
> Request = Full-Request
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 32]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Full-Request = Request-Line ; Section 9.1
> *( General-Header ; Section 8.3
> | Request-Header ; Section 9.2
> | Entity-Header ) ; Section 11.1
> CRLF
> [ Entity-Body ] ; Section 11.2
>
>
>
>
>9.1 Request-Line
>The Request-Line begins with a method token, followed by the
>Request-URI
>and the protocol version, and ending with CRLF. The elements are
>separated by SP characters. No CR or LF are allowed except in the final
>CRLF sequence.
>
> Request-Line = CRLF | Method SP Request-URI SP HTTP-Version
>CRLF
>
>In the interest of robustness, HTTP/1.1 servers SHOULD ignore null
>request lines (ones that comprise just CRLF). An HTTP/1.1 client MUST
>NOT preface a request with CRLF.
>
>
>9.1.1 Method
>The Method token indicates the method to be performed on the resource
>identified by the Request-URI. The method is case-sensitive.
>
> Method = "OPTIONS" ; Section 13.1
> | "GET" ; Section 13.2
> | "HEAD" ; Section 13.3
> | "POST" ; Section 13.4
> | "PUT" ; Section 13.5
> | "DELETE" ; Section 13.6
> | "TRACE" ; Section 13.7
> | extension-method
>
> extension-method = token
>
>The list of methods acceptable by a plain resource can be specified in
>an Allow header field (section 18.7). However, the client is always
>notified through the return code of the response whether a method is
>currently allowed on a plain resource, as this can change dynamically.
>Servers SHOULD return the status code 405 (method not allowed) if the
>method is known by the server but not allowed for the requested
>resource, and 501 (not implemented) if the method is unrecognized or
>not
>implemented by the server. The list of methods known by a server can be
>listed in a Public response header field (section 18.37).
>
>The methods GET and HEAD MUST be supported by all general-purpose
>servers. Servers which provide Last-Modified dates for resources MUST
>also support the conditional GET method. All other methods are
>optional;
>however, if the above methods are implemented, they MUST be implemented
>with the same semantics as those specified in section 13.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 33]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>9.1.2 Request-URI
>The Request-URI is a Uniform Resource Identifier (section 7.2) and
>identifies the resource upon which to apply the request.
>
> Request-URI = "*" | absoluteURI | abs_path
>
>The three options for Request-URI are dependent on the nature of the
>request. The asterisk "*" means that the request does not apply to a
>particular resource, but to the server itself, and is only allowed when
>the Method used does not necessarily apply to a resource. One example
>would be
>
> OPTIONS * HTTP/1.1
>
>The absoluteURI form is required when the request is being made to a
>proxy. The proxy is requested to forward the request or service it from
>a valid cache, and return the response.. Note that the proxy MAY
>forward
>the request on to another proxy or directly to the server specified by
>the absoluteURI. In order to avoid request loops, a proxy MUST be able
>to recognize all of its server names, including any aliases, local
>variations, and the numeric IP address. An example Request-Line would
>be:
>
> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
>
>To allow for transition to absoluteURIs in all requests in future
>versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form
>in requests, even though HTTP/1.1 clients will only generate them in
>requests to proxies. The Host request-header field MUST be ignored in
>requests using an absoluteURL as the Request-URI.
>
>The most common form of Request-URI is that used to identify a resource
>on an origin server or gateway. In this case the absolute path of the
>URI MUST be transmitted (see 7.2.1, abs_path) as the Request-URI, and
>the network location of the URI (net_loc) MUST be transmitted in a Host
>header field.. For example, a client wishing to retrieve the resource
>above directly from the origin server would create a TCP connection to
>port 80 of the host "www.w3.org" and send the lines:
>
> GET /pub/WWW/TheProject.html HTTP/1.1
> Host:www.w3.org
>
>followed by the remainder of the Full-Request. Note that the absolute
>path cannot be empty; if none is present in the original URI, it MUST
>be
>given as "/" (the server root).
>
>If a proxy receives a request without any path in the Request-URI and
>the method specified is capable of supporting the asterisk form of
>request, then the last proxy on the request chain MUST forward the
>request with "*" as the final Request-URI. For example, the request
>
> OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
>
>would be forwarded by the proxy as
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 34]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> OPTIONS * HTTP/1.1
> Host: www.ics.uci.edu:8001
>
>after connecting to port 8001 of host "www.ics.uci.edu".
>
>The Request-URI is transmitted as an encoded string, where some
>characters may be escaped using the "% HEX HEX" encoding defined by RFC
>1738 . The origin server MUST decode the Request-URI in order to
>properly interpret the request. In requests that they forward, proxies
>MUST NOT rewrite the "abs_path" part of a Request-URI in any way except
>as noted above to replace a null abs_path with "*". Illegal
>Request-URIs
>SHOULD be responded to with an appropriate status code. Proxies MAY
>transform the Request-URI for internal processing purposes, but SHOULD
>NOT send such a transformed Request-URI in forwarded requests.
>
> The main reason for this rule is to make sure that the form of
> Request-URI is well specified, to enable future extensions without
> fear that they will break in the face of some rewritings. Another
> is that one consequence of rewriting the Request-URI is that
> integrity or authentication checks by the server may fail; since
> rewriting MUST be avoided in this case, it may as well be
> proscribed in general. Implementers should be aware that some pre-
> HTTP/1.1 proxies do some rewriting.
>
>
>9.2 The Resource Identified by a Request
>HTTP/1.1 origin servers SHOULD be aware that the exact resource
>identified by an Internet request is determined by examining both the
>Request-URI and the Host header field. An origin server that does not
>allow resources to differ by the requested host MAY ignore the Host
>header field. An origin server that does differentiate resources based
>on the host requested (sometimes referred to as virtual hosts or vanity
>hostnames) MUST use the following rules for determining the requested
>resource on an HTTP/1.1 request:.
>
> 1. If Request-URI is an absoluteURI, the host is included in the
> Request-URI. Any Host header field in the request MUST be
>ignored.
> 2. If the Request-URI is not an absoluteURI, and the request includes
> a Host header field, the host is determined by the Host header
> field.
> 3. If the request-URI is not an absoluteURI and no Host header field
> is present (or does not represent a valid host on that server),
> the response MUST be a 400 (Bad Request) error message.
>Recipients of an HTTP/1.0 request lacking a Host header field MAY
>attempt to use heuristics (e.g., examination of the URI path for
>something unique to a particular host) in order to determine what exact
>resource is being requested.
>
>
>9.3 Request Header Fields
>The request header fields allow the client to pass additional
>information about the request, and about the client itself, to the
>server. These fields act as request modifiers, with semantics
>equivalent
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 35]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>to the parameters on a programming language method (procedure)
>invocation.
>
> Request-Header = Accept ; Section 18.1
> | Accept-Charset ; Section 18.2
> | Accept-Encoding ; Section 18.3
> | Accept-Language ; Section 18.4
> | Authorization ; Section 18.8
> | From ; Section 18.23
> | Host ; Section 18.24
> | If-Modified-Since ; Section 18.25
> | If-Range ; Section 18.28
> | Proxy-Authorization ; Section 18.36
> | Range ; Section 18.38
> | Referer ; Section 18.39
> | User-Agent ; Section 18.45
> | Max-Forwards ; Section 18.32
>
>Request-Header field names can be extended reliably only in combination
>with a change in the protocol version. However, new or experimental
>header fields MAY be given the semantics of request header fields if
>all
>parties in the communication recognize them to be request header
>fields.
>Unrecognized header fields are treated as Entity-Header fields.
>
>
>10 Response
>After receiving and interpreting a request message, a server responds
>in
>the form of an HTTP response message.
>
> Response = Full-Response
>
> Full-Response = Status-Line ; Section 10.1
> *( General-Header ; Section 8.3
> | Response-Header ; Section 10.2
> | Entity-Header ) ; Section 11.1
> CRLF
> [ Entity-Body ] ; Section 11.2
>
>
>10.1 Status-Line
>The first line of a Full-Response message is the Status-Line,
>consisting
>of the protocol version followed by a numeric status code and its
>associated textual phrase, with each element separated by SP
>characters.
>No CR or LF is allowed except in the final CRLF sequence.
>
> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
>
>
>10.1.1 Status Code and Reason Phrase
>The Status-Code element is a 3-digit integer result code of the attempt
>to understand and satisfy the request. The Reason-Phrase is intended to
>give a short textual description of the Status-Code. The Status-Code is
>intended for use by automata and the Reason-Phrase is intended for the
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 36]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>human user. The client is not required to examine or display the
>Reason-
>Phrase.
>
>The first digit of the Status-Code defines the class of response. The
>last two digits do not have any categorization role. There are 5 values
>for the first digit:
>
>
> . 1xx: Informational - Request received, continuing process
>
> . 2xx: Success - The action was successfully received, understood,
> and accepted
>
> . 3xx: Redirection - Further action must be taken in order to
> complete the request
>
> . 4xx: Client Error - The request contains bad syntax or cannot be
> fulfilled
>
> . 5xx: Server Error - The server failed to fulfill an apparently
> valid request
>The individual values of the numeric status codes defined for HTTP/1.1,
>and an example set of corresponding Reason-Phrase's, are presented
>below. The reason phrases listed here are only recommended -- they may
>be replaced by local equivalents without affecting the protocol. These
>codes are fully defined in section 12.
>
> Status-Code = "100" ; Continue
> | "101" ; Switching Protocols
> | "200" ; OK
> | "201" ; Created
> | "202" ; Accepted
> | "203" ; Non-Authoritative Information
> | "204" ; No Content
> | "205" ; Reset Content
> | "206" ; Partial Content
> | "300" ; Multiple Choices
> | "301" ; Moved Permanently
> | "302" ; Moved Temporarily
> | "303" ; See Other
> | "304" ; Not Modified
> | "305" ; Use Proxy
> | "400" ; Bad Request
> | "401" ; Unauthorized
> | "402" ; Payment Required
> | "403" ; Forbidden
> | "404" ; Not Found
> | "405" ; Method Not Allowed
> | "406" ; Not Acceptable
> | "407" ; Proxy Authentication Required
> | "408" ; Request Time-out
> | "409" ; Conflict
> | "410" ; Gone
> | "411" ; Length Required
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 37]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> | "412" ; Precondition Failed
> | "413" ; Request Entity Too Large
> | "414" ; Request URI Too Large
> | "415" ; Unsupported Media Type
> | "500" ; Internal Server Error
> | "501" ; Not Implemented
> | "502" ; Bad Gateway
> | "503" ; Service Unavailable
> | "504" ; Gateway Time-out
> | "505" ; HTTP Version not supported
> | extension-code
>
> extension-code = 3DIGIT
>
> Reason-Phrase = *<TEXT, excluding CR, LF>
>
>HTTP status codes are extensible. HTTP applications are not required to
>understand the meaning of all registered status codes, though such
>understanding is obviously desirable. However, applications MUST
>understand the class of any status code, as indicated by the first
>digit, and treat any unrecognized response as being equivalent to the
>x00 status code of that class, with the exception that an unrecognized
>response MUST NOT be cached. For example, if an unrecognized status
>code
>of 431 is received by the client, it can safely assume that there was
>something wrong with its request and treat the response as if it had
>received a 400 status code. In such cases, user agents SHOULD present
>to
>the user the entity returned with the response, since that entity is
>likely to include human-readable information which will explain the
>unusual status.
>
>
>10.2 Response Header Fields
>The response header fields allow the server to pass additional
>information about the response which cannot be placed in the Status-
>Line. These header fields give information about the server and about
>further access to the resource identified by the Request-URI.
>
> Response-Header = Location ; Section 18.31
> | Proxy-Authenticate ; Section 18.35
> | Public ; Section 18.37
> | Retry-After ; Section 18.40
> | Server ; Section 18.41
> | WWW-Authenticate ; Section 18.46
>
>Response-Header field names can be extended reliably only in
>combination
>with a change in the protocol version. However, new or experimental
>header fields MAY be given the semantics of response header fields if
>all parties in the communication recognize them to be response header
>fields. Unrecognized header fields are treated as Entity-Header fields.
>
>
>11 Entity
>Full-Request and Full-Response messages MAY transfer an entity within
>some requests and responses. An entity consists of Entity-Header fields
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 38]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>and (usually) an Entity-Body. In this section, both sender and
>recipient
>refer to either the client or the server, depending on who sends and
>who
>receives the entity.
>
>
>11.1 Entity Header Fields
>Entity-Header fields define optional metainformation about the Entity-
>Body or, if no body is present, about the resource identified by the
>request.
>
> Entity-Header = Allow ; Section 18.7
> | Content-Base ; Section 18.12
> | Content-Encoding ; Section 18.3
> | Content-Language ; Section 18.14
> | Content-Length ; Section 18.15
> | Content-Location ; Section 18.16
> | Content-MD5 ; Section 0
> | Content-Range ; Section 18.18
> | Content-Type ; Section 18.19
> | Expires ; Section 18.22
> | Last-Modified ; Section 18.30
> | Title ; Section 18.42
> | Transfer-Encoding ; Section 18.43
> | extension-header
>
> extension-header = HTTP-header
>
>The extension-header mechanism allows additional Entity-Header fields
>to
>be defined without changing the protocol, but these fields cannot be
>assumed to be recognizable by the recipient. Unrecognized header fields
>SHOULD be ignored by the recipient and forwarded by proxies.
>
>
>11.2 Entity Body
>The entity body (if any) sent with an HTTP request or response is in a
>format and encoding defined by the Entity-Header fields.
>
> Entity-Body = *OCTET
>
>An entity body MUST ONLY be included with a request message 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.
>All responses to the HEAD request method 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 NOT include a body. All other responses MUST include an
>entity body or a Content-Length header field defined with a value of
>zero (0).
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 39]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>11.2.1 Type
>When an entity body is included with a message, the data type of that
>body is determined via the header fields Content-Type,
>Content-Encoding,
>and Transfer-Encoding. These define a three-layer, ordered encoding
>model:
>
> entity-body :=
> Transfer-Encoding( Content-Encoding( Content-Type( data ) ) )
>
>The default for both encodings is none (i.e., the identity function).
>Content-Type specifies the media type of the underlying data. Content-
>Encoding may be used to indicate any additional content codings applied
>to the type, usually for the purpose of data compression, that are a
>property of the resource entity requested. Transfer-Encoding may be
>used to indicate any additional transfer codings applied by an
>application to ensure safe and proper transfer of the message. Note
>that
>Transfer-Encoding is a property of the message, not of the resource
>entity.
>
>Any HTTP/1.1 message containing an entity body SHOULD include a
>Content-
>Type header field defining the media type of that body. If and only if
>the media type is not given by a Content-Type header, the recipient may
>attempt to guess the media type via inspection of its content and/or
>the
>name extension(s) of the URL used to identify the resource. If the
>media
>type remains unknown, the recipient SHOULD treat it as type
>"application/octet-stream".
>
>
>11.2.2 Length
>When an entity body is included with a message, the length of that body
>may be determined in one of several ways. If a Content-Length header
>field is present, its value in bytes represents the length of the
>entity
>body. Otherwise, the body length is determined by the Transfer-Encoding
>(if the "chunked" transfer coding has been applied) or by the server
>closing the connection.
>
> Note: Any response message which MUST NOT include an entity body
> (such as the 1xx, 204, and 304 responses and any response to a HEAD
> request) is always terminated by the first empty line after the
> header fields, regardless of the entity header fields present in
> the message.
>
>Closing the connection cannot be used to indicate the end of a request
>body, since it leaves no possibility for the server to send back a
>response. For compatibility with HTTP/1.0 applications, HTTP/1.1
>requests containing an entity body MUST include a valid Content-Length
>header field unless the server is known to be HTTP/1.1 compliant.
>HTTP/1.1 servers MUST accept the "chunked" transfer coding (section
>7.6), thus allowing this mechanism to be used for a request when
>Content-Length is unknown.
>
>If a request contains an entity body and Content-Length is not
>specified, the server SHOULD respond with 400 (bad request) if it
>cannot
>determine the length of the request message's content, or with 411
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 40]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>(length required) if it wishes to insist on receiving a valid Content-
>Length.
>
>Messages MUST NOT include both a Content-Length header field and the
>"chunked" transfer coding. If both are received, the Content-Length
>MUST
>be ignored.
>
>When a Content-Length is given in a message where an entity body is
>allowed, its field value MUST exactly match the number of OCTETs in the
>entity body. HTTP/1.1 user agents MUST notify the user when an invalid
>length is received and detected.
>
>
>12 Status Code Definitions
>Each Status-Code is described below, including a description of which
>method(s) it can follow and any metainformation required in the
>response.
>
>
>12.1 Informational 1xx
>This class of status code indicates a provisional response, consisting
>only of the Status-Line and optional headers, and is terminated by an
>empty line. Since HTTP/1.0 did not define any 1xx status codes, servers
>MUST NOT send a 1xx response to an HTTP/1.0 client except under
>experimental conditions.
>
>
>12.1.1.1 100 Continue
>The client may continue with its request. This interim response is used
>to inform the client that the initial part of the request has been
>received and has not yet been rejected by the server. The client SHOULD
>continue by sending the remainder of the request or, if the request has
>already been completed, ignore this response. The server MUST send a
>final response after the request has been completed.
>
>
>12.1.1.2 101 Switching Protocols
>The server understands and is willing to comply with the client's
>request, via the Upgrade message header field (section 18.44), for a
>change in the application protocol being used on this connection. The
>server will switch protocols to those defined by the response's Upgrade
>header field immediately after the empty line which terminates the 101
>response.
>
>The protocol should only be switched when it is advantageous to do so.
>For example, switching to a newer version of HTTP is advantageous over
>older versions, and switching to a real-time, synchronous protocol may
>be advantageous when delivering resources that use such features.
>
>
>12.2 Successful 2xx
>This class of status code indicates that the client's request was
>successfully received, understood, and accepted.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 41]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.2.1.1 200 OK
>The request has succeeded. The information returned with the response
>is
>dependent on the method used in the request, as follows:
>
>
>GET
> an entity corresponding to the requested resource is sent in the
> response;
>
>HEAD
> the response MUST only contain the header information and no Entity-
> Body;
>
>POST
> an entity describing or containing the result of the action;
>
>TRACE
> an entity containing the request message as received by the end
> server;
>
>otherwise,
> an entity describing the result of the action;
>If the entity corresponds to a resource, the response MAY include a
>Content-Location header field giving the actual location of that plain
>resource for later reference.
>
>
>12.2.1.2 201 Created
>The request has been fulfilled and resulted in a new resource being
>created. The newly created resource can be referenced by the URI(s)
>returned in the entity of the response, with the most specific URL for
>the resource given by a Location header field. The origin server SHOULD
>create the resource before returning this status code. If the action
>cannot be carried out immediately, the server MUST include in the
>response body a description of when the resource will be available;
>otherwise, the server SHOULD respond with 202 (Accepted).
>
>
>12.2.1.3 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 status code from an asynchronous operation
>such as this.
>
>The 202 response is intentionally non-committal. Its purpose is to
>allow
>a server to accept a request for some other process (perhaps a batch-
>oriented process that is only run once per day) without requiring that
>the user agent's connection to the server persist until the process is
>completed. The entity returned with this response SHOULD include an
>indication of the request's current status and either a pointer to a
>status monitor or some estimate of when the user can expect the request
>to be fulfilled.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 42]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.2.1.4 203 Non-Authoritative Information
>The returned metainformation in the Entity-Header is not the definitive
>set as available from the origin 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 MAY result in a superset of the metainformation
>known
>by the origin server. Use of this response code is not required and is
>only appropriate when the response would otherwise be 200 (OK).
>
>
>12.2.1.5 204 No Content
>The server has fulfilled the request but there is no new information to
>send back. If the client is a user agent, it SHOULD NOT change its
>document view from that which caused the request to be 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 MAY include new metainformation in the form of entity headers,
>which SHOULD apply to the document currently in the user agent's active
>view.
>
>The 204 response MUST NOT include an entity body, and thus is always
>terminated by the first empty line after the header fields.
>
>
>12.2.1.6 205 Reset Content
>The server has fulfilled the request and the user agent SHOULD reset
>the
>document view which caused the request to be generated. This response
>is
>primarily intended to allow input for actions to take place via user
>input, followed by a clearing of the form in which the input is given
>so
>that the user can easily initiate another input action. The response
>MUST include a Content-Length with a value of zero (0) and no entity
>body.
>
>
>12.2.1.7 206 Partial Content
>The server has fulfilled the partial GET request for the resource. The
>request MUST have included a Range header field (section 18.38)
>indicating the desired range. The response MUST include a Content-Range
>header field (section 18.18) indicating the range included with this
>response. All entity header fields in the response MUST describe the
>partial entity transmitted rather than what would have been transmitted
>in a full response. In particular, the Content-Length header field in
>the response MUST match the actual number of OCTETs transmitted in the
>entity body. It is assumed that the client already has the complete
>entity's header field data.
>
>
>12.3 Redirection 3xx
>This class of status code indicates that further action needs to be
>taken by the user agent in order to fulfill the request. The action
>required MAY be carried out by the user agent without interaction with
>the user if and only if the method used in the second request is GET or
>HEAD. A user agent SHOULD NOT automatically redirect a request more
>than
>5 times, since such redirections usually indicate an infinite loop.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 43]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.3.1.1 300 Multiple Choices
>This status code is reserved for future use by a planned content
>negotiation mechanism. HTTP/1.1 user agents receiving a 300 response
>which includes a Location header field can treat this response as they
>would treat a 303 (See Other) response. If no Location header field is
>included, the appropriate action is to display the entity enclosed in
>the response to the user.
>
>
>12.3.1.2 301 Moved Permanently
>The requested resource has been assigned a new permanent URI and any
>future references to this resource SHOULD be done using one of the
>returned URIs. Clients with link editing capabilities SHOULD
>automatically re-link references to the Request-URI to one or more of
>the new references returned by the server, where possible. This
>response
>is cachable unless indicated otherwise.
>
>If the new URI is a location, its URL MUST be given by the Location
>field in the response. Unless it was a HEAD request, the Entity-Body of
>the response SHOULD contain a short hypertext note with a hyperlink to
>the new URI(s).
>
>If the 301 status code is received in response to a request other than
>GET or HEAD, the user agent MUST NOT automatically redirect the request
>unless it can be confirmed by the user, since this might change the
>conditions under which the request was issued.
>
> Note: When automatically redirecting a POST request after receiving
> a 301 status code, some existing HTTP/1.0 user agents will
> erroneously change it into a GET request.
>
>
>12.3.1.3 302 Moved Temporarily
>The requested resource resides temporarily under a different URI. Since
>the redirection may be altered on occasion, the client SHOULD continue
>to use the Request-URI for future requests. This response is only
>cachable if indicated by a Cache-Control or Expires header field.
>
>If the new URI is a location, its URL MUST be given by the Location
>field in the response. Unless it was a HEAD request, the Entity-Body of
>the response SHOULD contain a short hypertext note with a hyperlink to
>the new URI(s).
>
>If the 302 status code is received in response to a request other than
>GET or HEAD, the user agent MUST NOT automatically redirect the request
>unless it can be confirmed by the user, since this might change the
>conditions under which the request was issued.
>
> Note: When automatically redirecting a POST request after receiving
> a 302 status code, some existing HTTP/1.0 user agents will
> erroneously change it into a GET request.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 44]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.3.1.4 303 See Other
>The response to the request can be found under a different URI and
>SHOULD be retrieved using a GET method on that resource. This method
>exists primarily to allow the output of a POST-activated script to
>redirect the user agent to a selected resource. The new resource is not
>a update reference for the original Request-URI. The 303 response is
>not
>cachable, but the response to the second request MAY be cachable.
>
>If the new URI is a location, its URL MUST be given by the Location
>field in the response. Unless it was a HEAD request, the Entity-Body of
>the response SHOULD contain a short hypertext note with a hyperlink to
>the new URI(s).
>
>
>12.3.1.5 304 Not Modified
>If the client has performed a conditional GET request and access is
>allowed, but the document has not been modified since the date and time
>specified in the If-Modified-Since field, the server MUST respond with
>this status code and not send an Entity-Body to the client. Header
>fields contained in the response SHOULD only include information which
>is relevant to cache managers or which MAY have changed independently
>of
>the entity's Last-Modified date. Examples of relevant header fields
>include: Date, Server, Content-Length, Content-MD5, Content-Version,
>Cache-Control and Expires.
>
>A cache SHOULD update its cached entity to reflect any new field values
>given in the 304 response. If the new field values indicate that the
>cached entity differs from the current resource entity (as would be
>indicated by a change in Content-Length, Content-MD5, or Content-
>Version), then the cache MUST disregard the 304 response and repeat the
>request without an If-Modified-Since field.
>
>The 304 response MUST NOT include an entity body, and thus is always
>terminated by the first empty line after the header fields.
>
>
>12.3.1.6 305 Use Proxy
>The requested resource MUST be accessed through the proxy given by the
>Location field in the response. In other words, this is a proxy
>redirect.
>
>
>12.4 Client Error 4xx
>The 4xx class of status code is intended for cases in which the client
>seems to have erred. If the client has not completed the request when a
>4xx code is received, it SHOULD immediately cease sending data to the
>server. Except when responding to a HEAD request, the 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 method.
>
> Note: If the client is sending data, server implementations using
> TCP SHOULD be careful to ensure that the client acknowledges
> receipt of the packet(s) containing the response prior to closing
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 45]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> the input connection. If the client continues sending data to the
> server after the close, the server's controller will send a reset
> packet to the client, which may erase the client's unacknowledged
> input buffers before they can be read and interpreted by the HTTP
> application.
>
>
>12.4.1.1 400 Bad Request
>The request could not be understood by the server due to malformed
>syntax. The client SHOULD NOT repeat the request without modifications.
>
>
>12.4.1.2 401 Unauthorized
>The request requires user authentication. The response MUST include a
>WWW-Authenticate header field (section 18.46) containing a challenge
>applicable to the requested resource. The client MAY repeat the request
>with a suitable Authorization header field (section 18.8). If the
>request already included Authorization credentials, then the 401
>response indicates that authorization has been refused for those
>credentials. If the 401 response contains the same challenge as the
>prior response, and the user agent has already attempted authentication
>at least once, then the user SHOULD be presented the entity that was
>given in the response, since that entity MAY include relevant
>diagnostic
>information. HTTP access authentication is explained in section 14.
>
>
>12.4.1.3 402 Payment Required
>This code is reserved for future use.
>
>
>12.4.1.4 403 Forbidden
>The server understood the request, but is refusing to 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 make public
>why
>the request has not been fulfilled, it SHOULD describe the reason for
>the refusal in the entity body. This status code is commonly used when
>the server does not wish to reveal exactly why the request has been
>refused, or when no other response is applicable.
>
>
>12.4.1.5 404 Not Found
>The server has not found anything matching the Request-URI. No
>indication is given of whether the condition is temporary or permanent.
>If the server does not wish to make this information available to the
>client, the status code 403 (Forbidden) can be used instead. The 410
>(Gone) status code SHOULD be used if the server knows, through some
>internally configurable mechanism, that an old resource is permanently
>unavailable and has no forwarding address.
>
>
>12.4.1.6 405 Method Not Allowed
>The method specified in the Request-Line is not allowed for the
>resource
>identified by the Request-URI. The response MUST include an Allow
>header
>containing a list of valid methods for the requested resource.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 46]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.4.1.7 406 Not Acceptable
>The resource identified by the request is only capable of generating
>response entities which have content characteristics not acceptable
>according to the accept headers sent in the request.
>
>HTTP/1.1 servers are allowed to return responses which are not
>acceptable according to the accept headers sent in the request. In some
>cases, this may even be preferable to sending a 406 response. User
>agents are encouraged to inspect the headers of an incoming response to
>determine if it is acceptable. If the response is not acceptable, user
>agents SHOULD interrupt the receipt of the response if doing so would
>save network resources. If it is unknown whether an incoming response
>would be acceptable, a user agent SHOULD temporarily stop receipt of
>more data and query the user for a decision on furtheractions.
>
>
>12.4.1.8 407 Proxy Authentication Required
>This code is similar to 401 (Unauthorized), but indicates that the
>client MUST first authenticate itself with the proxy. The proxy MUST
>return a Proxy-Authenticate header field (section 18.35) containing a
>challenge applicable to the proxy for the requested resource. The
>client
>MAY repeat the request with a suitable Proxy-Authorization header field
>(section 18.36). HTTP access authentication is explained in section 14.
>
>
>12.4.1.9 408 Request Timeout
>The client did not produce a request within the time that the server
>was
>prepared to wait. The client MAY repeat the request without
>modifications at any later time.
>
>
>12.4.1.10 409 Conflict
>The request could not be completed due to a conflict with the current
>state of the resource. This code is only allowed in situations where it
>is expected that the user MAY be able to resolve the conflict and
>resubmit the request. The response body SHOULD include enough
>information for the user to recognize the source of the conflict.
>Ideally, the response entity would include enough information for the
>user or user-agent to fix the problem; however, that MAY not be
>possible
>and is not required.
>
>Conflicts are most likely to occur in response to a PUT request. If
>versioning is being used and the entity being PUT includes changes to a
>resource which conflict with those made by an earlier (third-party)
>request, the server MAY use the 409 response to indicate 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.
>
>
>12.4.1.11 410 Gone
>The requested resource is no longer available at the server and no
>forwarding address is known. This condition SHOULD be considered
>permanent. Clients with link editing capabilities SHOULD delete
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 47]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>references to the Request-URI after user approval. If the server does
>not know, or has no facility to determine, whether or not the condition
>is permanent, the status code 404 (Not Found) SHOULD be used instead.
>This response is cachable unless indicated otherwise.
>
>The 410 response is primarily intended to assist the task of web
>maintenance by notifying the recipient that the resource is
>intentionally unavailable and that the server owners desire that remote
>links to that resource be removed. Such an event is common for limited-
>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 as "gone" or to keep the mark for any
>length of time -- that is left to the discretion of the server owner.
>
>
>12.4.1.12 411 Length Required
>The server refuses to accept the request without a defined Content-
>Length. The client MAY repeat the request if it adds a valid Content-
>Length header field containing the length of the entity body in the
>request message.
>
>
>12.4.1.13 412 Precondition Failed
>The precondition given in one or more of the request header fields
>evaluated to false when it was tested on the server. This response code
>allows the client to place preconditions on the current resource
>metainformation (header field data) and thus prevent the requested
>method from being applied to a resource other than the one intended.
>
>
>12.4.1.14 413 Request Entity Too Large
>The server is refusing to process a request because it considers the
>request entity to be larger than it is willing or able to process. The
>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 restriction is considered temporary, the server MAY include a
>Retry-After header field to indicate that it is temporary and after
>what
>time the client MAY try again.
>
>
>12.4.1.15 414 Request-URI Too Long
>The server is refusing to service the request because the Request-URI
>is
>longer than the server is willing to interpret. This rare condition is
>only likely to occur when a client has improperly converted a POST
>request to a GET request with long query information, when the client
>has descended into a URL "black hole" of redirection (e.g., a
>redirected
>URL prefix that points to a suffix of itself), or when the server is
>under attack by a client attempting to exploit security holes present
>in
>some servers using fixed-length buffers for reading or manipulating
>the
>Request-URI.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 48]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.4.1.16 415 Unsupported Media Type
>The server is refusing to service the request because the entity body
>of
>the request is in a format not supported by the requested resource for
>the requested method.
>
>
>12.5 Server Error 5xx
>Response status codes beginning with the digit "5" indicate cases in
>which the server is aware that it has erred or is incapable of
>performing the request. If the client has not completed the request
>when
>a 5xx code is received, it SHOULD immediately cease sending data to the
>server. Except when responding to a HEAD request, the server SHOULD
>include an entity containing an explanation of the 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.
>
>
>12.5.1.1 500 Internal Server Error
>The server encountered an unexpected condition which prevented it from
>fulfilling the request.
>
>
>12.5.1.2 501 Not Implemented
>The server does not support the functionality required to fulfill the
>request. This is the appropriate response when the server does not
>recognize the request method and is not capable of supporting it for
>any
>resource.
>
>
>12.5.1.3 502 Bad Gateway
>The server, while acting as a gateway or proxy, received an invalid
>response from the upstream server it accessed in attempting to fulfill
>the request.
>
>
>12.5.1.4 503 Service Unavailable
>The server is currently unable to handle the request due to a temporary
>overloading or maintenance of the server. The implication is that this
>is a temporary condition which will be alleviated after some delay. If
>known, the length of the delay MAY be indicated in a Retry-After
>header.
>If no Retry-After is given, the client SHOULD handle the response as it
>would for a 500 response.
>
> Note: The existence of the 503 status code does not imply that a
> server must use it when becoming overloaded. Some servers MAY wish
> to simply refuse the connection.
>
>
>12.5.1.5 504 Gateway Timeout
>The server, while acting as a gateway or proxy, did not receive a
>timely
>response from the upstream server it accessed in attempting to complete
>the request.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 49]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>12.5.1.6 505 HTTP Version Not Supported
>The server does not support, or refuses to support, the HTTP protocol
>version that was used in the request message. The server is indicating
>that it is unable or unwilling to complete the request using the same
>major version as the client, as described in section 7.1, other than
>with this error message. The response SHOULD contain an entity
>describing why that version is not supported and what other protocols
>are supported by that server.
>
>
>13 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 Host request-header field (section 18.24) MUST accompany all
>HTTP/1.1 requests.
>
>
>13.1 OPTIONS
>The OPTIONS method represents a request for information about the
>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 include
>entity information other than what can be considered as communication
>options (e.g., Allow is appropriate, but Content-Type is not) and MUST
>include a Content-Length 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 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 9.1.2, an "OPTIONS *" request can be
>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 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
>edit the response to exclude those options known to be unavailable
>through that proxy.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 50]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>13.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" if the
>request message includes an If-Modified-Since header field. A
>conditional GET method requests that the identified resource entity be
>transferred only if it has been modified since the date given by the
>If-
>Modified-Since header, as described in section 18.25. The conditional
>GET method is intended to reduce unnecessary network usage by allowing
>cached entities to be refreshed without requiring multiple requests or
>transferring data already held by the client.
>
>The semantics of the GET method change to a "partial GET" if the
>request
>message includes a Range header field. A partial GET requests that only
>part of the identified resource entity be transferred, as described in
>section 18.38. 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 16.
>
>
>13.3 HEAD
>The HEAD method is identical to GET except that the server MUST NOT
>return any Entity-Body in the response. The metainformation contained
>in
>the HTTP headers in response to a HEAD request SHOULD be identical to
>the information sent in response to a GET request. This method can be
>used for obtaining metainformation about the resource entity identified
>by the Request-URI without transferring the Entity-Body itself. This
>method is often used for testing hypertext links for validity,
>accessibility, and recent modification.
>
>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 entity (as would be
>indicated by a change in Content-Length, Content-MD5, or Content-
>Version), then the cache MUST mark the cache entry stale.
>
>There is no "conditional HEAD" or "partial HEAD" request analogous to
>those associated with the GET method. If an If-Modified-Since and/or
>Range header field is included with a HEAD request, they SHOULD be
>ignored.
>
>
>13.4 POST
>The POST method is used to request that the destination server accept
>the entity enclosed in the request as a new subordinate of the resource
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 51]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>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
> , 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.
>
>For compatibility with HTTP/1.0 applications, all POST requests 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 use a valid Content-Length or the "chunked"
>Transfer-Encoding. The server 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.
>
>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.
>
>If a resource has been created on the origin server, the response
>SHOULD
>be 201 (Created) and contain an entity (preferably of type "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.
>
>POST requests must obey the entity transmission requirements set out in
>section 13.4.1.
>
>
>13.4.1 SLUSHY: Entity Transmission Requirements
>Editor's Note: The issues here around reliable transmission of large
>entities to servers, particularly HTTP/1.0 servers, are complicated and
>subtle, particularly since we'd like optimistic transmission to be the
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 52]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>normal situation. We would like it if we can redraft this section to
>be
>simpler in the next draft
>
>General requirements:
>
> . HTTP/1.1 servers should maintain persistent connections and use
> TCP's flow control mechanisms to resolve temporary overloads,
> rather than terminating connections with the expectation that
> clients will retry. The latter technique can exacerbate network
> congestion.
> . An HTTP/1.1 (or later) client doing a PUT-like method SHOULD
> monitor the network connection for an error status while it is
> transmitting the request. If the client sees an error status, it
> should immediately cease transmitting the body. If the body is
> being sent using a "Chunked" encoding, a zero length chunk is used
> to mark the end of the message. If the body was preceded by a
> Content-length header, the client MUST close the connection.
> . 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) server that receives a request from a
> HTTP/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.
>Upon receiving a method subject to these requirements from an HTTP/1.1
>(or later) client, an HTTP/1.1 (or later) server MUST either
>immediately
>respondwith 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
>method if it returns an error status.
>
>If an HTTP/1.1 client has seen an HTTP/1.1 or later response from the
>server (clients SHOULD remember the version number of at least the most
>recently used server), and it sees the connection close before
>receiving
>any status from the server, the client SHOULD retry the request. If
>the
>client does retry the request,
>
> . it MUST first send the request headers,
> . and then MUST wait for the server to respond with either a 100
> (continue) response, in which case the client should continue, or
> with an error status.
>If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
>the server, it should assume that the server implements HTTP/1.0 or
>older and will not use the 100 (Continue) response. If in this case the
>client sees the connection close before receiving any status from the
>server, the client SHOULD retry the request. If the client does retry
>the request, it should use the following "binary exponential backoff"
>algorithm to be assured of obtaining a reliable response:
>
> 1.
> Initiate a new connection to the server
> 2.
> Transmit the request headers
> 3.
> Initialize a variable R to the estimated round-trip time to the
> server (e.g., based on the time it took to establish the
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 53]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> connection), or to a constant value of 5 seconds if the round-trip
> time is not available.
> 4.
> Compute T = R * (2**N), where N is the number of previous retries
> of this request.
> 5.
> Wait either for an error response from the server, or for T
>seconds
> (whichever comes first)
> 6.
> If no error response is received, after T seconds transmit the
>body
> of the request.
> 7.
> If client sees that the connection is closed prematurely, repeat
> from step 1 until the request is accepted, an error response is
> received, or the user becomes impatient.
>No matter what the server version, if an error status is received,
>
> . the client MUST NOT continue and
> . MUST close the connection if it has not already completed sending
> the full request body including any encoding mechanism used to
> transmit the body.
>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 wait for 100 (continue) response (but
>MAY do so if this simplifies the implementation).
>
>
>13.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 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 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 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 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 attempt to apply the request to some other resource. If
>the server desires that the request be applied to a different URI, it
>MUST send a 301 (Moved Permanently) response; the user agent MAY then
>make its own decision regarding whether or not to redirect the request.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 54]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>A single resource MAY be identified by many different URIs. For
>example,
>an article may have a URI for identifying "the current 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.
>
>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 to an HTTP/1.1
>server, a client MUST use a valid Content-Length or the "chunked"
>Transfer-Encoding. The server SHOULD respond with a 400 (bad request)
>message if it cannot determine 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 actual method for determining how the resource entity is placed,
>and
>what happens to its predecessor, is defined entirely by the origin
>server.
>
>PUT requests must obey the entity transmission requirements set out in
>section 13.4.1.
>
>
>13.6 DELETE
>The DELETE method requests that the origin server delete the resource
>identified by the Request-URI. This method MAY be overridden by human
>intervention (or other means) on the origin server. The client cannot
>be
>guaranteed that the operation has been carried out, even if the status
>code returned from the origin server indicates that the action has been
>completed successfully. However, the server SHOULD not indicate success
>unless, at the time the response is given, it intends to delete the
>resource or move it to an inaccessible location.
>
>A successful response SHOULD be 200 (OK) if the response includes an
>entity describing the status, 202 (Accepted) if the action has not yet
>been enacted, or 204 (No Content) if the response is OK but does not
>include an entity.
>
>If the request passes through a cache and the Request-URI identifies a
>currently cached entity, that entity MUST be removed from the cache.
>Responses to this method are not cachable.
>
>
>13.7 TRACE
>The TRACE method is used to invoke a remote, application-layer
>loop-back
>of the request message. The final recipient of the request SHOULD
>reflect the message received back to the client as the entity body of a
>200 (OK) response. The final recipient is either the origin server or
>the first proxy or gateway to receive a Max-Forwards value of zero (0)
>in the request (see section 18.32). A TRACE request MUST NOT include
>an
>entity.
>
>TRACE allows the client to see what is being received at the other end
>of the request chain and use that data for testing or diagnostic
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 55]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>information. The value of the Via header field (section 18.47) is of
>particular interest, since it acts as a trace of the request chain.
>Use
>of the Max-Forwards header field allows the client to limit the length
>of the request chain, which is useful for testing a chain of proxies
>forwarding messages in an infinite loop.
>
>If successful, the response SHOULD contain the entire request message
>in
>the entity body, with a Content-Type of "message/http",
>"application/http", or "text/plain". Responses to this method MUST NOT
>be cached.
>
>
>14 Access Authentication
>HTTP provides a simple challenge-response authentication mechanism
>which
>MAY be used by a server to challenge a client request and by a client
>to
>provide authentication information. It uses an extensible, case-
>insensitive token to identify the authentication scheme, followed by a
>comma-separated list of attribute-value pairs which carry the
>parameters
>necessary for achieving authentication via that scheme.
>
> auth-scheme = token
>
> auth-param = token "=" quoted-string
>
>The 401 (Unauthorized) response message is used by an origin server to
>challenge the authorization of a user agent. This response MUST include
>a WWW-Authenticate header field containing at least one challenge
>applicable to the requested resource.
>
> challenge = auth-scheme 1*SP realm *( "," auth-param )
>
> realm = "realm" "=" realm-value
> realm-value = quoted-string
>
>The realm attribute (case-insensitive) is required for all
>authentication schemes which issue a challenge. The realm value (case-
>sensitive), in combination with the canonical root URL of the server
>being accessed, defines the protection space. These realms allow the
>protected resources on a server to be partitioned into a set of
>protection spaces, each with its own authentication scheme and/or
>authorization database. The realm value is a string, generally assigned
>by the origin server, which may have additional semantics specific to
>the authentication scheme.
>
>A user agent that wishes to authenticate itself with a server--usually,
>but not necessarily, after receiving a 401 or 411 response--MAY do so
>by
>including an Authorization header field with the request. The
>Authorization field value consists of credentials containing the
>authentication information of the user agent for the realm of the
>resource being requested.
>
> credentials = basic-credentials
> | auth-scheme 0#auth-param
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 56]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The domain over which credentials can be automatically applied by a
>user
>agent is determined by the protection space. If a prior request has
>been
>authorized, the same credentials MAY be reused for all other requests
>within that protection space for a period of time determined by the
>authentication scheme, parameters, and/or user preference. Unless
>otherwise defined by the authentication scheme, a single protection
>space cannot extend outside the scope of its server.
>
>If the server does not wish to accept the credentials sent with a
>request, it SHOULD return a 401 (Unauthorized) response. The response
>MUST include a WWW-Authenticate header field containing the (possibly
>new) challenge applicable to the requested resource and an entity
>explaining the refusal.
>
>The HTTP protocol does not restrict applications to this simple
>challenge-response mechanism for access authentication. Additional
>mechanisms MAY be used, such as encryption at the transport level or
>via
>message encapsulation, and with additional header fields specifying
>authentication information. However, these additional mechanisms are
>not
>defined by this specification.
>
>Proxies MUST be completely transparent regarding user agent
>authentication. That is, they MUST forward the WWW-Authenticate and
>Authorization headers untouched, and MUST NOT cache the response to a
>request containing Authorization.
>
>HTTP/1.1 allows a client to pass authentication information to and from
>a proxy via the Proxy-Authenticate and Proxy-Authorization headers.
>
>
>14.1 Basic Authentication Scheme
>The "basic" authentication scheme is based on the model that the user
>agent must authenticate itself with a user-ID and a password for each
>realm. The realm value should be considered an opaque string which can
>only be compared for equality with other realms on that server. The
>server will service the request only if it can validate the user-ID and
>password for the protection space of the Request-URI. There are no
>optional authentication parameters.
>
>Upon receipt of an unauthorized request for a URI within the protection
>space, the server SHOULD respond with a challenge like the following:
>
> WWW-Authenticate: Basic realm="WallyWorld"
>
>where "WallyWorld" is the string assigned by the server to identify the
>protection space of the Request-URI.
>
>To receive authorization, the client sends the user-ID and password,
>separated by a single colon (":") character, within a base64 encoded
>string in the credentials.
>
> basic-credentials = "Basic" SP basic-cookie
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 57]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> basic-cookie = <base64 [7] encoding of user-pass,
> except not limited to 76 char/line>
>
> user-pass = userid ":" password
>
> userid = [ token ]
>
> password = *TEXT
>
>If the user agent wishes to send the user-ID "Aladdin" and password
>"open sesame", it would use the following header field:
>
> Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
>
>The basic authentication scheme is a non-secure method of filtering
>unauthorized access to resources on an HTTP server. It is based on the
>assumption that the connection between the client and the server can be
>regarded as a trusted carrier. As this is not generally true on an open
>network, the basic authentication scheme should be used accordingly. In
>spite of this, clients SHOULD implement the scheme in order to
>communicate with servers that use it.
>
>
>14.2 Digest Authentication Scheme
>The "digest" authentication scheme is [currently described in an
>expired
>Internet-Draft, and this description will have to be improved to
>reference a new draft or include the old one].
>
>
>15 Content Negotiation
>A generic resource has multiple entities associated with it, all of
>which are representations of the content of the resource. Content
>negotiation is the process of selecting the best representation when a
>GET or HEAD request is made on the generic resource. HTTP/1.1 has
>provisions for two kinds of content negotiation: opaque negotiation and
>transparent negotiation.
>
>With opaque negotiation, the selection of the best representation is
>done by an algorithm located at the origin server, and unknown to the
>proxies and user agents involved. Selection is based on the contents
>of
>particular header fields in the request message, or on other
>information
>pertaining to the request, like the network address of the sending
>client. A typical example of opaque negotiation would be the selection
>of a text/html response in a particular language based on the contents
>of the Accept-Language request header field. A disadvantage of opaque
>negotiation is that the request headers may not always contain enough
>information to allow for selection. If the Accept header
>
> Accept: text/*: q=0.3, text/html, */*: q=0.5
>
>is sent in a request on a generic resource which has a video/mpeg and a
>video/quicktime representation, the selection algorithm in the origin
>server will either have to make a default choice, or return an error
>response which allows the user to decide on further actions.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 58]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>With transparent negotiation, the selection of the best representation
>is done by a distributed algorithm which can perform computation steps
>in the origin server, in proxies, or in the user agent. Transparent
>negotiation guarantees that, if the user agent supports the transparent
>negotiation algorithm and is correctly configured, the request will
>always correctly yield either the video/mpeg representation, the
>video/quicktime representation, or an error message indicating that the
>resource cannot be displayed by the user agent.
>
>
>15.1 Negotiation Facilities Defined in this Specification
>This specification defines all protocol facilities for opaque
>negotiation, but does not define the distributed algorithm for
>transparent negotiation. This specification only defines the basic
>facilities (Vary, Alternates, Accept) in the core protocol allowing
>requests on transparently negotiated resources to be correctly handled
>by HTTP/1.1 caches. All other information about transparent content
>negotiation is found in a separate document[29].
>
>If a generic resource is opaquely negotiated, successful responses to
>requests on the resource will always include a Vary header. If a
>generic resource is transparently negotiated, successful responses to
>requests on the resource will always include an Alternates header. If
>a
>successful response contains an Alternates header, it will also always
>contain a Content-Location header. A future specification may allow a
>combination of opaque and transparent negotiation that would lead to
>the
>inclusion of both a Vary header and an Alternates header in a response.
>
>
>16 Caching in HTTP
>The World Wide Web is a distributed system, and so its performance can
>be improved by the use of caches. These caches are typically placed at
>proxies and in the clients themselves. The HTTP/1.1 protocol includes a
>number of elements intended to make caching work as well as possible.
>Because these elements are inextricable from other aspects of the
>protocol, and because they interact with each other, it is useful to
>describe the basic caching design of HTTP separately from the detailed
>descriptions of methods, headers, response codes, etc.
>
>
>16.1 Semantic Transparency
>Requirements for performance, availability, and disconnected operation
>require us to be able to relax the goal of semantic transparency. The
>HTTP/1.1 protocol allows origin servers, caches, and clients to
>explicitly reduce transparency when necessary. However, because non-
>transparent operation may confuse non-expert users, and may be
>incompatible with certain server applications (such as those for
>ordering merchandise), the protocol requires that transparency may not
>be relaxed
>
> . without an explicit protocol-level request (when relaxed by client
> or origin server)
> . without a means for warning the end user (when relaxed by cache or
> client)
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 59]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Therefore, the HTTP/1.1 protocol provides these important elements:
>
> 1. Protocol features that provide full semantic transparency when
>this
> is desired by all parties.
> 2. Protocol features that allow an origin server or end-user client
>to
> explicitly request and control non-transparent operation.
> 3. Protocol features that allow a cache to attach warnings to
> responses that do not preserve semantic transparency.
>A basic principle is that it must be possible for the clients to detect
>any potential breakdown of semantic transparency.
>
>Caching would be useless if it did not significantly improve
>performance. The goal of caching in HTTP/1.1 is to eliminate the need
>to
>send requests in many cases, and to eliminate the need to send full
>responses in many other cases. The former reduces the number of network
>round-trips required for many operations; we use an "expiration"
>mechanism for this purpose (see section 16.1.2). The latter reduces
>network bandwidth requirements; we use a "validation" mechanism for
>this
>purpose (see section 13.3).
>
>The server, cache, or client implementer may be faced with design
>decisions not explicitly discussed in this specification. If a decision
>may affect semantic transparency, the implementer ought to err on the
>side of maintaining transparency unless a careful and complete analysis
>shows significant benefits in breaking transparency.
>
>
>16.1.1 Cache Correctness
>If the cache can communicate with the origin-server, then a correct
>cache MUST respond to a request with a response that meets all the
>following conditions:
>
> 1. its end-to-end headers (see section 16.4.1) and entity-body value
> are equivalent to what the server would have returned for that
> request if the resource had not been modified since the response
> was cached. This may be accomplished by revalidating the response
> with the origin server, if is not fresh.
> 2. it is "fresh enough" (see section 16.1.2). In the default case,
> this means it meets the least restrictive freshness requirement of
> the client, server, and cache (see section 18.10); if the origin-
> server so specifies, it is the freshness requirement of the
>origin-
> server alone.
> 3. it includes a warning if the freshness demand of the client or the
> origin-server is violated (see section 16.1.5 and 18.48).
> 4. it is the most up-to-date response appropriate to the request the
> cache has seen (see section 16.2.6, 16.2.8, and 16.13).
>If the cache can not communicate with the origin server, then a correct
>cache SHOULD respond as above if the response can be correctly served
>from the cache; if not it MUST return an error or warning indicating
>that there was a communication.
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 60]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>16.1.2 Cache-control Mechanisms
>The basic cache mechanisms in HTTP/1.1 (server-specified expiration
>times and validators) are implicit directives to caches. In some cases,
>a server or client may need to provide explicit directives to the HTTP
>caches. We use the Cache-Control header for this purpose.
>
>The Cache-Control header allows a client or server to transmit a
>variety
>of directives in either requests or responses. These directives
>typically override the default caching algorithms. As a general rule,
>if
>there is any apparent conflict between header values, the most
>restrictive interpretation should be applied (that is, the one that is
>most likely to preserve semantic transparency). However, in some cases,
>Cache-Control directives are explicitly specified as weakening semantic
>transparency (for example, "max-stale" or "public").
>
>The Cache-Control directives are described in detail in section 18.10.
>
>
>16.1.3 Warnings
>Whenever a cache returns a response that is not semantically
>transparent, it must attach a warning to that effect, using a Warning
>response header. This warning allows clients and user agents to take
>appropriate action.
>
>Warnings may be used for other purposes, both cache-related and
>otherwise. The use of a warning, rather than an error status code,
>distinguish these responses from true failures.
>
>Warnings are always cachable, because they never weaken the
>transparency
>of a response. This means that warnings can be passed to HTTP/1.0
>caches
>without danger; such caches will simply pass the warning along as a
>entity header in the response.
>
>Warnings are assigned numbers between 0 and 99. This specification
>defines the code numbers and meanings of each warning, allowing a
>client
>or cache to take automated action in some (but not all) cases.
>
>Warnings also carry a warning message text in any appropriate natural
>language (perhaps based on the client's Accept headers), and an
>optional
>indication of what language and character set are used.
>
>Multiple warning messages may be attached to a response (either by the
>origin server or by a cache), including multiple warnings with the same
>code number. For example, a server may provide the same warning with
>texts in both English and Basque.
>
>When multiple warnings are attached to a response, it may not be
>practical or reasonable to display all of them to the user. This
>version
>of HTTP does not specify strict priority rules for deciding which
>warnings to display and in what order, but does suggest some
>heuristics.
>
>The Warning header and the currently defined warnings are described in
>section 18.48.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 61]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>16.1.4 Explicit User Agent Warnings
>Many user agents make it possible for users to override the basic
>caching mechanisms. For example, the user agent may allow the user to
>specify that cached entities (even explicitly stale ones) are never
>validated. Or the user agent might habitually add "Cache-Control: max-
>stale=3600" or "Cache-Control: reload" to every request. We recognize
>that there may be situations which require such overrides, although
>user
>agents SHOULD NOT default to any behavior contrary to the HTTP/1.1
>specification. That is, the user should have to explicitly request
>either non-transparent behavior, or behavior that results in abnormally
>ineffective caching.
>
>If the user has overridden the basic caching mechanisms, the user agent
>should explicitly indicate to the user whenever this results in the
>display of information that might not meet the server's transparency
>requirements (in particular, if the displayed entity is known to be
>stale). Since the protocol normally allows the user agent to determine
>if responses are stale or not, this indication need only be displayed
>when this actually happens. The indication need not be a dialog box; it
>could be an icon (for example, a picture of a rotting fish) or some
>other visual indicator.
>
>If the user has overridden the caching mechanisms in a way that would
>abnormally reduce the effectiveness of caches, the user agent should
>continually display an indication (for example, a picture of currency
>in
>flames) so that the user does not inadvertently consume excess
>resources
>or suffer from excessive latency.
>
>
>16.1.5 Exceptions to the Rules and Warnings
>In some cases, the operator of a cache may choose to configure it to
>return stale responses even when not requested by clients. This
>decision
>not be made lightly, but may be necessary for reasons of availability
>or
>performance, especially when the cache is poorly connected to the
>origin
>server. Whenever a cache returns a stale response, it MUST mark it as
>such (using a Warning header). This allows the client software to alert
>the user that there may be a potential problem.
>
>It also allows the user to take steps to obtain a firsthand or fresh
>response, if the user so desires. For this reason, a cache MUST NOT
>return a stale response if the client explicitly requests a first-hand
>or fresh one, unless it is impossible to comply.
>
>
>16.1.6 Client-controlled Behavior
>While the origin server (and to a lesser extent, intermediate caches,
>by
>their contribution to the age of a response) are the primary source of
>expiration information, in some cases the client may need to control a
>cache's decision about whether to return a cached response without
>validating it. Clients do this using several directives of the Cache-
>Control header.
>
>A client's request may specify the maximum age it is willing to accept
>for an unvalidated response; specifying a value of zero forces the
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 62]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>cache(s) to revalidate all responses. A client may also specify the
>minimum time remaining before a response expires. Both of these options
>increase constraints on the behavior of caches, and so cannot decrease
>semantic transparency.
>
>A client may also specify that it will accept stale responses, up to
>some maximum amount of staleness. This loosens the constraints on the
>caches, and so may violate semantic transparency, but may be necessary
>to support disconnected operation, or high availability in the face of
>poor connectivity.
>
>
>16.2 Expiration Model
>
>16.2.1 Server-Specified Expiration
>HTTP caching works best when caches can entirely avoid making requests
>to the origin server. The primary mechanism for avoiding requests is
>for
>an origin server to provide an explicit expiration time in the future,
>indicating that a response may be used to satisfy subsequent requests.
>In other words, a cache can return a fresh response without first
>contacting the server.
>
>Our expectation is that servers will assign future explicit expiration
>times to responses in the belief that the entity is not likely to
>change, in a semantically significant way, before the expiration time
>is
>reached. This normally preserves semantic transparency, as long as the
>server's expiration times are carefully chosen.
>
>If an origin server wishes to force a semantically transparent cache to
>validate every request, it may assign an explicit expiration time in
>the
>past. This means that the response is always stale, and so the cache
>SHOULD validate it before using it for subsequent requests. (See
>section 18.10.4 for a more restrictive way to force revalidation).
>
> Note that a firsthand response MUST always be returned to the
> requesting client, independent of its expiration time, unless the
> connection to the client is lost.
>
>If an origin server wishes to force any HTTP/1.1 cache, no matter how
>it
>is configured, to validate every request, it should use the "must-
>revalidate" Cache-Control directive. See section 18.10.
>
>Servers specify explicit expiration times using either the Expires
>header, or the max-age directive of the Cache-Control header.
>
>
>16.2.2 Limitations on the Effect of Expiration Times
>An expiration time cannot be used to force a user agent to refresh its
>display or reload a resource entity; its semantics apply only to
>caching
>mechanisms, and such mechanisms need only check a resource's expiration
>status when a new request for 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
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 63]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>earlier in a session. By default, an expiration time does not apply to
>history mechanisms. If the entity is still in storage, a history
>mechanism should display it even if the entity has expired, unless the
>user has specifically configured the agent to refresh expired history
>documents.
>
>
>16.2.3 Heuristic Expiration
>Since origin servers do not always provide explicit expiration times,
>HTTP caches typically assign heuristic expiration times, employing
>algorithms that use other header values (such as the Last-Modified
>time)
>to estimate a plausible expiration time. The HTTP/1.1 specification
>does
>not provide specific algorithms, but does impose worst-case constraints
>on their results. Since heuristic expiration times may compromise
>semantic transparency, they should be used cautiously, and we encourage
>origin servers to provide explicit expiration times as much as
>possible.
>
>
>16.2.4 Age Calculations
>In order to know if a cached entry is fresh, a cache needs to know if
>its age exceeds its freshness lifetime. We discuss how to calculate the
>latter in section 0; this section describes how to calculate the age of
>a response or cache entry.
>
>In this discussion, we use the term "now" to mean "the current value of
>the clock at the host performing the calculation." All HTTP
>implementations, but especially origin servers and caches, should use
>NTP [RFC1305] or some similar protocol to synchronize their clocks to a
>globally accurate time standard.
>
>Also note that HTTP/1.1 requires origin servers to send a Date header
>with every response, giving the time at which the response was
>generated. We use the term "date_value" to denote a representation of
>the value of the Date header, in a form appropriate for arithmetic
>operations.
>
>HTTP/1.1 uses the "Age" response header to help convey age information
>between caches. The Age header value is the sender's estimate of the
>amount of time since the response was generated at the origin server.
>In
>the case of a cached response that has been revalidated with the origin
>server, the Age value is based on the time of revalidation, not of the
>original response.
>
>In essence, the Age value is the sum of the time that the response has
>been resident in each of the caches along the path from the origin
>server, plus the amount of time it has been in transit along network
>paths.
>
>We use the term "age_value" to denote a representation of the value of
>the Age header, in a form appropriate for arithmetic operations.
>
>An response's age can be calculated in two entirely independent ways:
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 64]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> 1. now - date_value, if the local clock is reasonably well
> synchronized to the origin server's clock. If the result is
> negative, this is replaced by zero.
> 2. age_value, if all of the caches along the response path implement
> HTTP/1.1.
>Given that we have two independent ways to compute the age of a
>response
>when it is received, we can combine these as
>
> corrected_received_age = max(now - date_value, age_value)
>
>and as long as we have either nearly synchronized clocks or
>all-HTTP/1.1
>paths, one gets a reliable (conservative) result.
>
>Note that this correction is applied at each HTTP/1.1 cache along the
>path, so that if there is an HTTP/1.0 cache in the path, the correct
>received age is computed as long as the receiving cache's clock is
>nearly in sync. We don't need end-to-end clock synchronization
>(although
>it is good to have), and there is no explicit clock synchronization
>step.
>
>Because of network-imposed delays, some significant interval may pass
>from the time that a server generates a response, and the time it is
>received at the next outbound cache or client. If uncorrected, this
>delay could result in improperly low ages.
>
>Because the request that resulted in the returned Age value must have
>been initiated prior to that Age value's generation, we can correct for
>delays imposed by the network by recording the time at which the
>request
>was initiated. Then, when an Age value is received, it MUST be
>interpreted relative to the time the request was initiated, not the
>time
>that the response was received. This algorithm results in conservative
>behavior no matter how much delay is experienced. So, we compute:
>
> corrected_initial_age = corrected_received_age
> + (now - request_time)
>
>where "request_time" is the time (according to the local clock) when
>the
>request that elicited this response was sent.
>
>Summary of age calculation algorithm, when a cache receives a response:
>
> /*
> * age_value
> * is the value of Age: header received by the cache with
> * this response.
> * date_value
> * is the value of the origin server's Date: header
> * request_time
> * is the (local) time when the cache made the request
> * that resulted in this cached response
> * response_time
> * is the (local) time when the cache received the
> * response
> * now
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 65]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> * is the current (local) time
> */
> apparent_age = max(0, now - date_value);
> corrected_received_age = max(apparent_age, age_value);
> response_delay = now - request_time;
> corrected_initial_age = corrected_received_age + response_delay;
> resident_time = now - response_time;
> current_age = corrected_initial_age + resident_time;
>
>When a cache sends a response, it must add to the corrected_initial_age
>the amount of time that the response was resident locally. It must then
>transmit this total age, using the Age header, to the next recipient
>cache.
>
> Note that a client can usually tell if a response is firsthand by
> comparing the Date to its local request-time, and hoping that the
> clocks are not badly skewed.
>
>
>
>
>16.2.5 Expiration Calculations
>In order to decide whether a response is fresh or stale, we need to
>compare its freshness lifetime to its age. The age is calculated as
>described in section 16.2.4; this section describes how to calculate
>the
>freshness lifetime, and to determine if a response has expired.
>
>We use the term "expires_value" to denote a representation of the value
>of the Expires header, in a form appropriate for arithmetic operations.
>We use the term "max_age_value" to denote an appropriate representation
>of the number of seconds carried by the max-age directive of the Cache-
>Control header in a response (see section 18.11).
>
>The max-age directive takes priority over Expires, so if max-age is
>present in a response, the calculation is simply:
>
> freshness_lifetime = max_age_value
>
>Otherwise, if Expires is present in the response, the calculation is:
>
> freshness_lifetime = expires_value - date_value
>
>Note that neither of these calculations is vulnerable to clock skew,
>since all of the information comes from the origin server.
>
>If neither Expires nor Cache-Control max-age appears in the response,
>and the response does not include other restrictions on caching, the
>cache MAY compute a freshness lifetime using a heuristic. This
>heuristic
>is subject to certain limitations; the minimum value may be zero, and
>the maximum value MUST be no more than 24 hours.
>
>Also, if the response does have a Last-Modified time, the heuristic
>expiration value SHOULD be no more than some fraction of the interval
>since that time. A typical setting of this fraction might be 10%.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 66]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The calculation to determine if a response has expired is quite simple:
>
> response_is_fresh = (freshness_lifetime > current_age)
>
>
>16.2.6 Scope of Expiration
>HTTP/1.1's expiration model is that as soon as any variant of a URI
>becomes stale, all variants becomes stale as well. Thus, "freshness"
>applies to all the variants of URI, rather than any particular variant.
>Dates and expires etc. apply to any cached variant that a proxy might
>have with a URI and not just the one particular entity.
>
>Editor's note: This restriction may be dropped in the next draft; there
>are still discussions about whether this restriction is needed.
>
>
>16.2.7 Disambiguating Expiration Values
>Because expiration values are assigned optimistically, it is possible
>that two caches may contain fresh values for the same resource that are
>different.
>
>If a client performing a retrieval receives a non-firsthand response
>for
>a resource entity that was already fresh in its own cache, and the
>Date
>header in its existing cache entry is newer than the Date on the new
>response, then the client MAY ignore the response. If so, it MAY retry
>the request with a "Cache-Control: max-age=0" directive (see section
>18.10), to force a check with the origin server.
>
>If a cache that is pooling cached responses from other caches sees two
>fresh responses for the same resource entity with different validators,
>it SHOULD use the one with the newer Date header.
>
>
>16.2.8 Disambiguating Multiple Responses
>Because a client may be receiving responses via multiple paths, so that
>some responses flow through one set of caches and other responses flow
>through a different set of caches, a client may receive responses in an
>order different from that in which the origin server generated them. We
>would like the client to use the most recently generated response, even
>if older responses are still apparently fresh.
>
>Neither the entity tag nor the expiration value can impose an ordering
>on responses, since it is possible that a later response intentionally
>carries an earlier expiration time. However, the HTTP/1.1 specification
>requires the transmission of Date headers on every response, and the
>Date values are ordered to a granularity of one second.
>
>If a client performs a request for a resource entity that it already
>has
>in its cache, and the response it receives contains a Date header that
>appears to be older than the one it already has in its cache, then the
>client SHOULD repeat the request unconditionally, and include
>
> Cache-Control: max-age=0
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 67]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>to force any intermediate caches to validate their copies directly with
>the origin server, or
>
> Cache-Control: no-cache
>
>to force any intermediate caches to obtain a new copy from the origin
>server. This prevents certain paradoxes arising from the use of
>multiple
>caches.
>
>If the Date values are equal, then the client may use either response
>(or may, if it is being extremely prudent, request a new response).
>Servers MUST NOT depend on clients being able to choose
>deterministically between responses generated during the same second,
>if
>their expiration times overlap.
>
>
>16.3 Validation Model
>When a cache has a stale entry that it would like to use as a response
>to a client's request, it first has to check with the origin server (or
>possibly an intermediate cache with a fresh response) to see if its
>cached entry is still usable. We call this "validating" the cache
>entry.
>Since we do not want to have to pay the overhead of retransmitting the
>full response if the cached entry is good, and we do not want to pay
>the
>overhead of an extra round trip if the cached entry is invalid, the
>HTTP/1.1 protocol supports the use of conditional methods.
>
>The key protocol features for supporting conditional methods are those
>concerned with "cache validators." When an origin server generates a
>full response, it attaches some sort of validator to it, which is kept
>with the cache entry. When a client (end-user or cache) makes a
>conditional request for a resource for which it has a cache entry, it
>includes the associated validator in the request.
>
>The server then checks that validator against the current validator for
>the resource entity, and, if they match, it responds with a special
>status code (usually, "304 Not Modified") and no entity body.
>Otherwise,
>it returns a full response (including entity body). Thus, we avoid
>transmitting the full response if the validator matches, and we avoid
>an
>extra round trip if it does not match.
>
> Note: the comparison functions used to decide if validators match
> are defined in section 16.3.3.
>
>In HTTP/1.1, a conditional request looks exactly the same as a normal
>request for the same resource, except that it carries a special header
>(which includes the validator) that implicitly turns the method
>(usually, GET) into a conditional.
>
>The protocol includes both positive and negative senses of cache-
>validating conditions. That is, it is possible to request either that a
>method be performed if and only if the validators match, or if and only
>if the validators do not match.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 68]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Note: a response that lacks a cache validator may still be cached,
> and served from cache until it expires, unless this is explicitly
> prohibited by a Cache-Control directive. However, a cache cannot do
> a conditional retrieval if it does not have a cache validator for
> the entity, which means it will not be refreshable after it
> expires.
>
>
>
>
>16.3.1 Last-modified Dates
>In HTTP/1.0, the only cache validator is the Last-Modified time carried
>by a response. Clients validate entities using the If-Modified-Since
>header. In simple terms, a cache entry is considered to be valid if the
>actual resource entity has not been modified since the original
>response
>was generated.
>
>
>16.3.2 Entity Tags
>HTTP/1.1 introduces the possibility of using an "opaque" validator,
>called an "entity tag," for situations where the Last-Modified date is
>not appropriate. This may include server implementations where it is
>not
>convenient to store modification dates, or where the one-second
>resolution of HTTP date values is insufficient, or where the origin
>server wishes to avoid certain paradoxes that may arise from the use of
>modification dates.
>
>An entity tag is simply a string of octets whose internal structure is
>not known to clients or caches. Caches store entity tags and return
>them
>when making conditional requests. Also, when a cache receives a
>conditional request for a resource for which it has a fresh cache
>entry,
>it may compare entity tags using strict octet-equality. Otherwise,
>entity tags have no semantic value to clients or caches.
>
>To preserve compatibility with HTTP/1.0 clients and caches, and because
>the Last-Modified date may be useful for purposes other than cache
>validation, HTTP/1.1 servers SHOULD send Last-Modified whenever
>feasible.
>
>The headers used to convey entity tags are described in sections Error!
>Reference source not found., Error! Reference source not found., 18.26,
>and 18.46.
>
>
>16.3.3 Weak and Strong Validators
>Since both origin servers and caches will compare two validator values
>to decide if they represent the same or different resource entities,
>one
>normally would expect that if the resource entity (the entity body or
>any entity headers) changes in any way, then the associated validator
>would change as well. If this is true, then we call this validator a
>"strong validator."
>
>However, there may be cases when a server prefers to change the
>validator only on semantically significant changes, and not when
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 69]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>insignificant aspects of the resource entity change. A validator that
>does not always change when the resource changes is a "weak validator."
>
>One can think of a strong validator as one that changes whenever the
>bits of an entity changes, while a weak value changes whenever the
>meaning of an entity changes. Alternatively, one can think of a strong
>validator as part of an identifier for a specific entity, while a weak
>validator is part of an identifier for a set of semantically equivalent
>entities.
>
> Note: One example of a strong validator is an integer that is
> incremented in stable storage every time an entity is changed.
>
> An entity's modification time, if represented with one-second
> resolution, could be a weak validator, since it is possible that
> the resource entity may be modified twice during a single second.
>
>Entity tags are normally "strong validators," but the protocol provides
>a mechanism to tag an entity tag as "weak."
>
>A "use" of a validator is either when a client generates a request and
>includes the validator in a validating header field, or when a server
>compares two validators.
>
>Strong validators are usable in any context. Weak validators are only
>usable in contexts that do not depend on exact equality of an entity.
>For example, either kind is usable for a conditional GET of a full
>entity. However, only a strong validator is usable for a sub-range
>retrieval, since otherwise the client may end up with an internally
>inconsistent entity body.
>
>The only function that the HTTP/1.1 protocol defines on validators is
>comparison. There are two validator comparison functions, depending on
>whether the comparison context allows the use of weak validators or
>not:
>
> . The strong comparison function: in order to be considered equal,
> both validators must be identical in every way, and neither may be
> weak.
> . The weak comparison function: in order to be considered equal,
>both
> validators must be identical in every way, but either or both of
> them may be tagged as "weak" without affecting the result.
>The weak comparison function SHOULD be used for simple (non-subrange)
>GET requests. The strong comparison function MUST be used in all other
>cases.
>
>An entity tag is strong unless it is explicitly tagged as weak. Section
>16.3 gives the syntax for entity tags.
>
>A Last-Modified time, when used as a validator in a request, is
>implicitly weak unless it is possible to deduce that it is strong,
>using
>the following rules:
>
> . The validator is being compared by an origin server to the actual
> current validator for the entity and,
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 70]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . That origin server reliably knows that the associated entity did
> not change twice during the second covered by the presented
> validator.
>or
>
> . The validator is about to be used by a client in an If-Modified-
> Since or If-Unmodified-Since header, because the client has a
>cache
> entry for the associated entity, and
> . That cache entry includes a Date value, which gives the time when
> the origin server generated the original response, and
> . The presented Last-Modified time is at least 60 seconds before the
> Date value.
>or
>
> . The validator is being compared by an intermediate cache to the
> validator stored in its cache entry for the entity, and
> . That cache entry includes a Date value, which gives the time when
> the origin server generated the original response, and
> . The presented Last-Modified time is at least 60 seconds before the
> Date value.
>This method relies on the fact that if two different responses were
>generated by the origin server during the same second, but both had the
>same Last-Modified time, then at least one of those responses would
>have
>a Date value equal to its Last-Modified time. The arbitrary 60-second
>limit guards against the possibility that the Date and Last-Modified
>values are generated from different clocks, or at somewhat different
>times during the preparation of the response. An implementation may use
>a value larger than 60 seconds, if it is believed that 60 seconds is
>too
>short.
>
>If a client wishes to perform a sub-range retrieval on a value for
>which
>it has only a Last-Modified time and no opaque validator, it may do
>this
>only if the Last-Modified time is strong in the sense described here.
>
>A cache or origin server receiving a cache-conditional request, other
>than a full-body GET request, must use the strong comparison function
>to
>evaluate the condition.
>
>These rules allow HTTP/1.1 caches and clients to safely perform sub-
>range retrievals on values that have been obtained from HTTP/1.0
>servers.
>
>
>16.3.4 Rules for When to Use Entity Tags and Last-modified Dates
>We adopt a set of rules and recommendations for origin servers,
>clients,
>and caches regarding when various validator types should be used, and
>for what purposes.
>
>HTTP/1.1 origin servers:
>
> . SHOULD send an entity tag validator unless performance
> considerations support the use of weak entity tags, or unless it
>is
> unfeasible to send a strong entity tag.
> . MAY send a weak entity tag instead of a strong one.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 71]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . MAY send no entity tag if it is not feasible to generate one.
> . SHOULD send a Last-Modified value if it is feasible to send one,
> unless the risk of a breakdown in semantic transparency that could
> result from using this date in an If-Modified-Since header would
> lead to serious problems.
>In other words, the preferred behavior for an HTTP/1.1 origin server is
>to send both a strong entity tag and a Last-Modified value.
>
>In order to be legal, a strong entity tag MUST change whenever the
>associated entity value changes in any way. A weak entity tag SHOULD
>change whenever the associated entity changes in a semantically
>significant way.
>
> Note: in order to provide semantically transparent caching, an
> origin server should avoid reusing a specific strong entity tag
> value for two different resource entities, or reusing a specific
> weak entity tag value for two semantically different instances of a
> resource entity. Cache entries may persist for arbitrarily long
> periods, regardless of expiration times, so it may be inappropriate
> to expect that a cache will never again attempt to validate an
> entry using a validator that it obtained at some point in the past.
>
>HTTP/1.1 clients:
>
> . If an entity tag has been provided by the origin server, MUST use
> that entity tag in any cache-conditional request (using If-Match
>or
> If-NoneMatch).
> . If only a Last-Modified value has been provided by the origin
> server, SHOULD use that value in non-subrange cache-conditional
> requests (using If-Modified-Since).
> . If only a Last-Modified value has been provided by an HTTP/1.0
> origin server, MAY use that value in subrange cache-conditional
> requests (using If-Unmodified-Since:). The user agent should
> provide a way to disable this, in case of difficulty.
> . If both an entity tag and a Last-Modified value have been provided
> by the origin server, SHOULD use both validators in cache-
> conditional requests. This allows both HTTP/1.0 and HTTP/1.1
>caches
> to respond appropriately.
>An HTTP/1.1 cache, upon receiving a request, MUST use the most
>restrictive validator when deciding whether the client's cache entry
>matches the cache's own cache entry. This is only an issue when the
>request contains both an entity tag and a last-modified-date validator
>(If-Modified-Since or If-Unmodified-Since).
>
> A note on rationale: The general principle behind these rules is
> that HTTP/1.1 servers and clients should transmit as much non-
> redundant information as is available in their responses and
> requests. HTTP/1.1 systems receiving this information will make the
> most conservative assumptions about the validators they receive.
>
> HTTP/1.0 clients and caches will ignore entity tags. Generally,
> last-modified values received or used by these systems will support
> transparent and efficient caching, and so HTTP/1.1 origin servers
> should provide Last-Modified values. In those rare cases where the
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 72]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> use of a Last-Modified value as a validator by an HTTP/1.0 system
> could result in a serious problem, then HTTP/1.1 origin servers
> should not provide one.
>
>
>16.3.5 Non-validating Conditionals
>The principle behind entity tags is that only the service author knows
>the semantics of a resource well enough to select an appropriate cache
>validation mechanism, and the specification of any validator comparison
>function more complex than byte-equality would open up a can of worms.
>Thus, comparisons of any other headers (except Last-Modified, for
>compatibility with HTTP/1.0) are never used for purposes of validating
>a
>cache entry.
>
>
>16.4 Constructing Responses From Caches
>The purpose of an HTTP cache is to store information received in
>response to requests, for use in responding to future requests. In many
>cases, a cache simply returns the appropriate parts of a response to
>the
>requester. However, if the cache holds a cache entry based on a
>previous
>response, it may have to combine parts of a new response with what is
>held in the cache entry.
>
>
>16.4.1 End-to-end and Hop-by-hop Headers
>For the purpose of defining the behavior of caches and non-caching
>proxies, we divide HTTP headers into two categories:
>
> . End-to-end headers, which must be transmitted to the ultimate
> recipient of a request or response. End-to-end headers in
>responses
> must be stored as part of a cache entry and transmitted in any
> response formed from a cache entry.
> . Hop-by-hop headers, which are meaningful only for a single
> transport-level connection, and are not stored by caches or
> forwarded by proxies.
>The following HTTP/1.1 headers are hop-by-hop headers:
>
> . Connection
> . Keep-Alive
> . Upgrade
> . Public
> . Proxy-Authenticate
> . Transfer-Encoding
>All other headers defined by HTTP/1.1 are end-to-end headers.
>
>Hop-by-hop headers introduced in future versions of HTTP MUST be listed
>in a Connection header, as described in section 18.11.
>
>
>16.4.2 Non-modifiable Headers
>Some features of the HTTP/1.1 protocol, such as Digest Authentication,
>depend on the value of certain end-to-end headers. A cache or non-
>caching proxy SHOULD NOT modify an end-to-end header unless the
>definition of that header requires or specifically allows that.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 73]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>A cache or non-caching proxy MUST NOT modify any of the following
>fields
>in a request or response, nor may it add any of these fields if not
>already present:
>
> . Content-Type
> . Content-Encoding
> . Content-Length
> . Expires
> . Last-Modified
> . Content-Range
> . Content-Location
> Warning: unnecessary modification of end-to-end headers may cause
> authentication failures if stronger authentication mechanisms are
> introduced in later versions of HTTP. Such authentication
> mechanisms may rely on the values of header fields not listed here.
>
>
>
>
>16.4.3 Combining Headers
>When a cache makes a validating request to a server, and the server
>provides a 304 Not Modified response, the cache must construct a
>response to send to the requesting client. The cache uses the entity-
>body stored in the cache entry as the entity-body of this outgoing
>response. It uses the end-to-end headers from the incoming response,
>not
>from the cache entry. Unless it decides to remove the cache entry, it
>must also replace the end-to-end headers stored with the cache entry
>with those received in the incoming response.
>
>In other words, the complete set of end-to-end headers received in the
>incoming response overrides all end-to-end headers stored with the
>cache
>entry. The cache may add Warning headers (see section 18.48) to this
>set.
>
>A cache MUST preserve the order of all headers as received in an
>incoming response.
>
>These rule allows an origin server to completely control the response
>seen by the client of a cache when the cache revalidates an entry, and
>may be necessary for preserving semantic transparency or for certain
>kinds of security mechanisms or future extensions.
>
>
>16.4.4 Combining Byte Ranges
>A response may transfer only a subrange of the bytes of an entity,
>either because the request included one or more Range specifications,
>or
>because a connection was broken prematurely. After several such
>transfers, a cache may have received several ranges of the same entity.
>
>If a cache has a stored non-empty set of subranges for an entity, and
>an
>incoming response transfers another subrange, the cache MAY combine the
>new subrange with the existing set if both the following conditions are
>met:
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 74]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . Both the incoming response and the cache entry must have a cache
> validator.
> . The two cache validators must match using the strong comparison
> function (see section 16.3.3).
>If either requirement is not meant, the cache must use only the most
>recent partial response (based on the Date values transmitted with
>every
>response, and using the incoming response if these values are equal or
>missing), and must discard the other partial information.
>
>
>16.5 Caching and Generic Resources
>Generic resources interacts with caching in several ways:
>
> . A generic resource (one subject to content negotiation) may be
> bound to more than one entity. Each of these entities is called a
> "variant" of the resource.
> . The request-URI may be only one part of the cache key.
>
>16.5.1 Vary Header Use
>Origin servers may respond to requests for generic resources use the
>Vary header (see section 18.46 for a full description) to inform the
>cache which header fields of the request were used to select the
>variant
>returned in the response. A cache can use that response to reply to a
>subsequent request only if the two requests not only specify the same
>URI, but also have the same value for all headers specified in the Vary
>response-header.
>
>The Vary header may also inform the cache that the variant was selected
>using criteria not limited to the request headers; in this case, the
>response MUST NOT be used in a reply to a subsequent request except if
>the cache relays the new request to the origin server in a conditional
>request, and the origin server responds with 304 (Not Modified) and
>includes the same variant-ID (see 13.8.3).
>
>
>16.5.2 Alternates Header Use
>The Alternates header is present in the HTTP/1.1 to enable caching of
>entities from the planned content negotiation facilities. If a cache
>receives an Alternates header in a response from the origin server (and
>implement these planned facilities), it should act as if the response
>carried a "Vary:{accept-headers}" header. This means that the response
>may be returned in reply to a subsequent request with Accept-* headers
>identical to those in the current request.
>
>
>16.5.3 Variant-ID Use
>If an origin server chooses to use the variant-ID mechanism, it assigns
>a variant-ID (see section 7.12) to each distinct resource entity
>(variant). This assignment can only be made by the origin server. It
>then returns the appropriate variant-ID with each response that applies
>to a specific resource entity (variant), using the ETag header (see
>Error! Reference source not found.).
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 75]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>When sending an entity derived from a particular variant in a response,
>an origin server SHOULD include a variant-ID identifying the variant in
>the ETag header (see section Error! Reference source not found.). This
>variant-ID can be used for cache replacement and in conditional
>requests
>on the generic resource. When a cache receives a successful response
>with a variant-ID, it SHOULD use this information to replace any
>existing cache entries for the same variant of the corresponding URI.
>That is, it forms a cache key using the URI of the request and the
>variant-ID of the response. If this key matches the key of an existing
>cache entry, it SHOULD replace the existing entry with the new response
>(subject to all of the other rules on caching). See section Error!
>Reference source not found. for more details on update.
>
>When a cache performs a conditional request on a generic resource, and
>it has one or more cache entries for the resource that include variant-
>IDs, the cache MUST transmit the (cache-validator, variant-ID) tuples
>in
>the conditional request, using the variant-set mechanism (see section
>7.13). This tells the server which variants are currently in the
>requester's cache.
>
> The client MAY choose to transmit only a subset of the (cache-
> validator, variant-ID) tuples corresponding to its cache entries
> for this resource.
>
>When a server receives a conditional request that includes a variant-
>set, and the server is able to reply with an appropriate variant
>(either
>because it is the origin server, or because it is an intermediate cache
>that can properly implement the variant selection algorithm), once it
>has selected the variant it should examine the elements of the supplied
>variant-set. If one of these matches the variant-ID of the selected
>variant, and if the cache validators match, the server SHOULD reply
>with
>a 304 (Not Modified) response, including the variant-ID of the selected
>variant. Otherwise, the server should reply as if the request were
>unconditional.
>
>The server may optionally use the variant-set information in its
>selection algorithm. For example, if the selection algorithm yields
>several variants with equal preference, and one of these is already in
>the requester's cache, the server could select that variant and avoid
>an
>extra data transfer. This is a performance optimization; otherwise, the
>variant-selection mechanism is orthogonal to the variant-ID mechanism.
>
>
>16.6 Shared and Non-Shared Caches
>For reasons of security and privacy, it is necessary to make a
>distinction between "shared" and "non-shared" caches. A non-shared
>cache
>is one that is accessible only to a single user. Accessibility in this
>case SHOULD be enforced by appropriate security mechanisms. All other
>caches are considered to be "shared." Other sections of this
>specification place certain constraints on the operation of shared
>caches in order to prevent loss of privacy or failure of access
>controls
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 76]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>16.7 Selecting a Cached Response
>When a cache receives a request it tries to see if it has a cached
>response appropriate for that request, using the matching rules in this
>section. If such a response exists, then the cache can decide if it is
>fresh enough (using the expiration model in section 16.1.2 and the
>freshness requirements of client and origin-server expressed in the
>Cache-Control headers of the request and cached response) to return in
>reply to the request.
>If on a cache lookup there are two or more fresh entries that appear to
>match the request, then the one with the most recent Date value MUST be
>used.
>16.7.1 Plain Resources
>If the cached response was for a plain resource (that is, the response
>includes no Vary or Alternates headers), it matches if the Request-URI
>of the request matches the Request-URI of the of the request that
>caused
>the cached response to be stored. Request-URIs match if their canonical
>forms (see section 7.2.3) are equal.
>
>16.7.2 Generic Resources
>If the cached response was for a generic resource (that is, the
>response
>includes Vary, or Alternates headers), it matches if the Request-URI of
>the request matches the Request-URI of the request that caused the
>cached response to be stored, and the selecting request header field
>values of the request match those of the request that caused the cached
>response to be stored. (See section 18.46 on Vary, which defines the
>canonical form for selecting request headers and the matching rules for
>them.)
>If the response contains "Vary: {other}", then the selecting request
>header field values for its request are defined as never matching a set
>of request headers.
>
>16.8 Errors or Incomplete Response Cache Behavior
>A cache that receives an incomplete response (for example, with fewer
>bytes of data than specified in a Content-length: header) may store the
>response. However, the cache MUST treat this as a partial response.
>Partial responses may be combined as described in section 16.4.4; the
>result might be a full response or might still be partial. A cache MUST
>NOT return a partial response to a client without explicitly marking it
>as such, using the 206 (Partial Content) status code. A cache MUST NOT
>return a partial response using a status code of 200 (OK).
>
>A cache that receives a response with a zero-length Entity-body and no
>explicit indication that the correct length is zero (such as "Content-
>Length: 0") MUST NOT store the response. The same rule applies to a
>response of any length received without an explicit length indication
>if
>the transport connection was terminated in any unusual way.
>
>If a cache receives a response carrying Retry-After header (see section
>18.40), it may either forward this response to the requesting client,
>or
>act as if the server failed to respond. In the latter case, it MAY
>return a previously received response, although it MUST follow all of
>the rules applying to stale responses. In particular, it MUST NOT
>override the "must-revalidate" Cache-Control directive (see section
>18.10).
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 77]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>16.8.1 Caching and Status Codes
>A response received with a status code of 200 or 206 may be stored by a
>cache and used in reply to a subsequent request, subject to the
>expiration mechanism, unless a Cache-control directive prohibits
>caching.
>
>A response received with any other status code MUST NOT be returned in
>a
>reply to a subsequent request unless it carries at least one of the
>following:
>
> . an Expires header
> . a max-age Cache-control directive
> . a must-revalidate Cache-control directive
> . a public Cache-control directive
>
>16.8.2 Handling of Retry-After
>If a cache receives a response carrying a Retry-After header (see
>section 18.40), it may either forward this response to the requesting
>client, or act as if the server failed to respond. In the latter case,
>it MAY return a previously received response, although it MUST follow
>all of the rules applying to stale responses. In particular, it MUST
>NOT override the "must-revalidate" Cache-Control directive (see section
>18.10).
>
>
>16.9 Side Effects of GET and HEAD
>Unless the origin server explicitly prohibits the caching of their
>responses, the application of GET and HEAD methods to any resources
>SHOULD NOT have side effects that would lead to erroneous behavior if
>these responses are taken from a cache. They may still have side
>effects, but a cache is not required to consider such side effects in
>its caching decisions. Caches are always expected to observe an origin
>server's explicit restrictions on caching.
>
>We note one exception to this rule: since some applications have
>traditionally used GETs and HEADs with query URLs (those containing a
>"?" in the rel_path part) to perform operations with significant side
>effects, caches MUST NOT treat responses to such URLs as fresh unless
>the server provides an explicit expiration time.
>
>This specifically means that responses from HTTP/1.0 servers for such
>URIs should not be taken from a cache.
>
>See section 19.2 for related information.
>
>
>16.10 Invalidation After Updates or Deletions
>The effect of certain methods at the origin server may cause one or
>more
>existing cache entries to become non-transparently invalid. That is,
>although they may continue to be "fresh," they do not accurately
>reflect
>what the origin server would return for a new request.
>
>There is no way for the HTTP protocol to guarantee that all such cache
>entries are marked invalid. For example, the request that caused the
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 78]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>change at the origin server may not have gone through the proxy where a
>cache entry is stored. However, several rules help reduce the
>likelihood of erroneous behavior.
>
>In this section, the phrase "invalidate an entity" means that the cache
>should either remove all instances of that entity from its storage, or
>should mark these as "invalid" and in need of a mandatory revalidation
>before they can be returned in response to a subsequent request.
>
>Some HTTP methods invalidate a single entity. This is either the
>entity
>referred to by the Request-URI, or by the Location or Content-Location
>response headers (if present). These methods are:
>
> . PUT
> . DELETE
> . POST
>In order to prevent denial of service attacks, an invalidation based on
>the URI in a Location or Content-Location header MUST only be performed
>if the host part is the same as in the Request-URI.
>
>
>16.11 Write-Through Mandatory
>All methods that may be expected to cause modifications to the origin
>server's resources MUST be written through to the origin server. This
>currently includes all methods except for GET and HEAD. A cache MUST
>NOT
>reply to such a request from a client before having transmitted the
>request to the inbound server, and having received a corresponding
>response from the inbound server.
>
>The alternative (known as "write-back" or "copy-back" caching) is not
>allowed in HTTP/1.1, due to the difficulty of providing consistent
>updates and the problems arising from server, cache, or network failure
>prior to write-back.
>
>
>16.12 Generic Resources and HTTP/1.0 Proxy Caches
>If the correct handling of responses from a generic resource (Section
>15) by HTTP/1.0 proxy caches in the response chain is important,
>HTTP/1.1 origin servers can include the following Expires (Section
>18.22) response header in all responses from the generic resource:
>
> Expires: Thu, 01 Jan 1980 00:00:00 GMT
>
>If this Expires header is included, the server should usually also
>include a Cache-Control header for the benefit of HTTP/1.1 caches, for
>example
>
> Cache-Control: max-age=604800
>
>which overrides the freshness lifetime of zero seconds specified by the
>included Expires header.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 79]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>16.13 Cache Replacement
>If a new cacheable response (see sections 18.10.2, 16.2.6, 16.2.8 and
>16.8) is received from a plain resource while any existing responses
>for
>the same resource are cached, the cache MUST NOT return any of those
>older responses to any future requests for the resource.
>
> Note: a new response that has an older Date header value than
> existing cached responses is not cacheable.
>
>If a new cacheable response is received from a generic resource with a
>certain variant-ID while any old responses with the same variant-ID for
>the same resource are cached, the cache MUST NOT return any of those
>old
>responses to any future requests for the resource.
>
> Note: In some cases, this may mean that the cache chooses to delete
> the old response(s) from cache storage to recover space. However,
> note that there will never be a new response to signal that a
> variant-ID is no longer in use. It is expected that the cache's
> update heuristics will eventually cause such old responses to be
> deleted.
>
>The cache SHOULD use the new response to reply to the current request.
>It may insert it into cache storage and may, if it meets all other
>requirements, use it to respond to any future requests that would
>previously have caused the old response to be returned. If it inserts
>the new response into cache storage it should follow the rules in
>section 16.4.3.
>
>
>16.14 Caching of Negative Responses
>Caching of negative responses has often been a significant performance
>advantage in distributed systems. In some future draft or
>specification
>we may have more to say about negative caching.
>
>
>16.15 History Lists
>History lists as implemented in many user agents and caches are
>different. In particular history lists SHOULD NOT try to show a
>semantically transparent view of the current state of a resource
>entity.
>Rather, a history list is meant to show exactly what the user saw at
>the
>time when the resource was retrieved .
>
>This should not be construed to prohibit the history mechanism from
>telling the user that a view may be stale.
>
>
>17 Persistent Connections
>
>17.1 Purpose
>HTTP's greatest strength and its greatest weakness has been its
>simplicity. Prior to persistent connections, a separate TCP connection
>was established to fetch each URL, increasing the load on HTTP servers,
>and causing congestion on the Internet. The use of inline images and
>other associated data often requires a client to make multiple requests
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 80]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>of the same server in a short amount of time. An excellent analysis
>of
>these performance problems is available [30]; analysis and results from
>a prototype implementation are in [33], [34].
>
> Persistent HTTP connections have a number of advantages:
>
> . By opening and closing fewer TCP connections, CPU time is saved,
> and memory used for TCP protocol control blocks is also saved
> . HTTP requests and responses can be pipe-lined on a connection.
> Pipe-lining allows a client to make multiple requests without
> waiting for each response, allowing a single TCP connection to be
> used much more efficiently, with much lower elapsed time.
> . Network congestion is reduced by reducing the number of packets
> caused by TCP opens, and by allowing TCP sufficient time to
> determine the congestion state of the network.
> . HTTP can evolve more gracefully; since errors can be reported
> without the penalty of closing the TCP connection. Clients using
> future versions of HTTP might optimistically try a new feature,
>but
> if communicating with an older server, retry with old semantics
> after an error is reported.
>HTTP implementations SHOULD implement persistent connections.
>
>
>17.2 Overall Operation
>Persistent connections provides a mechanism by which a client and a
>server can negotiate the use of a TCP connection for an extended
>conversation. This negotiation takes place using the Connection and
>Persist header fields. Once this option has been negotiated, the client
>can make multiple HTTP requests over a single transport connection.
>
>
>17.2.1 Negotiation
>To request the use of persistent connections, a client sends a
>Connection header with a connection-token "Persist". If the server
>wishes to accept persistent connections, it will respond with the same
>connection-token. Both the client and server MUST send this connection-
>token with every request and response for the duration of the
>persistent
>connection. If either the client or the server omits the Persist token
>from the Connection header, that request becomes the last one for the
>connection.
>
>A server MUST NOT establish a persistent connection with an HTTP/1.0
>client that uses the above form of the Persist header due to problems
>with the interactions between HTTP/1.1 clients and HTTP/1.0 proxy
>servers. (See section 23.5.2.5 for more information on backwards
>compatibility with HTTP/1.0 clients.)
>
>
>17.2.2 Pipe-lining
>Clients and servers which support persistent connections MAY
>"pipe-line"
>their requests and responses. When pipe-lining, a client will send
>multiple requests without waiting for the responses. The server MUST
>then send all of the responses in the same order that the requests were
>made.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 81]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>A client MAY assume that a server supports persistent connections if
>the
>same server has accepted persistent connections within the past 24
>hours. Clients which assume persistent connections and pipeline
>immediately SHOULD be prepared to retry their connection if the first
>pipe-lined attempt fails. If a client does such a retry, it MUST NOT
>pipeline without first receiving an explicit Persist token from the
>server. Clients MUST also be prepared to resend their requests if the
>server closes the connection before sending all of the corresponding
>responses.
>
>
>17.2.3 Delimiting Entity-Bodies
>When using persistent connections, both the client and the server MUST
>mark the exact endings of transmitted entity-bodies using one of the
>following three techniques:
>
> 1. Send a Content-length field in the header with the exact number of
> bytes in the entity-body.
> 2. Send the message using chunked Transfer Coding as described in
> section 7.6. Chunked Transfer Coding allows the server to transmit
> the data to the client a piece at a time while still communicating
> an exact ending of the entity-body.
> 3. Close the transport connection after the entity body.
>Sending the Content-length is the preferred technique. Chunked encoding
>SHOULD be used when the size of the entity-body is not known before
>beginning to transmit the entity-body. Finally, the connection MAY be
>closed and fall back to non-persistent connections, if neither 1 or 2
>are possible.
>
>Clients and servers that support persistent connections MUST correctly
>support receiving via all three techniques.
>
>
>17.3 Proxy Servers
>It is especially important that proxies correctly implement the
>properties of the Connection header field as specified in 14.2.1.
>
>The proxy server MUST negotiate persistent connections separately with
>its clients and the origin servers (or other proxy servers) that it
>connects to. Each persistent connection applies to only one transport
>link.
>
>A proxy server MUST NOT establish a persistent connection with an
>HTTP/1.0 client.
>
>
>17.4 Interaction with Security Protocols
>It is expected that persistent connections will operate with both SHTTP
>[31] and SSL [32]. When used in conjunction with SHTTP, the SHTTP
>request is prepared normally and the persist connection-token is placed
>in the outermost request block (the one containing the "Secure"
>method).
>When used in conjunction with SSL, a SSL session is started as normal
>and the first HTTP request made using SSL contains the persistent
>connection header.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 82]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>17.5 Practical Considerations
>Servers will usually have some time-out value beyond which they will no
>longer maintain an inactive connection. Proxy servers might make this a
>higher value since it is likely that the client will be making more
>connections through the same server. The use of persistent connections
>places no requirements on the length of this time-out for either the
>client or the server.
>
>When a client or server wishes to time-out it SHOULD issue a graceful
>close on the transport connection. Clients and servers SHOULD both
>constantly watch for the other side of the transport close, and respond
>to it as appropriate. If a client or server does not detect the other
>side's close promptly it could cause unnecessary resource drain on the
>network.
>
>A client, server, or proxy MAY close the transport connection at any
>time. For example, a client MAY have started to send a new request at
>the same time that the server has decided to close the "idle"
>connection. From the server's point of view, the connection is being
>closed while it was idle, but from the client's point of view, a
>request
>is in progress.
>
>This means that clients, servers, and proxies MUST be able to recover
>from asynchronous close events. Client software SHOULD reopen the
>transport connection and retransmit the aborted request without user
>interaction. However, this automatic retry SHOULD NOT be repeated if
>the
>second request fails.
>
>Servers SHOULD always respond to at least one request per connection,
>if
>at all possible. Servers SHOULD NOT close a connection in the middle of
>transmitting a response, unless a network or client failure is
>suspected.
>
>It is suggested that clients which use persistent connections SHOULD
>limit the number of simultaneous connections that they maintain to a
>given server. A single-user client SHOULD maintain AT MOST 2
>connections
>with any server of proxy. A proxy SHOULD use up to 2*N connections to
>another server or proxy, where N is the number of simultaneously active
>users. These guidelines are intended to improve HTTP response times and
>avoid congestion of the Internet or other networks.
>
>
>18 Header Field Definitions
>This section defines the syntax and semantics of all standard HTTP/1.1
>header fields. For Entity-Header fields, both sender and recipient
>refer
>to either the client or the server, depending on who sends and who
>receives the entity.
>
>
>18.1 Accept
>The Accept request-header field can be used to specify certain media
>types which are acceptable for the response. Accept headers can be
>used
>to indicate that the request is specifically limited to a small set of
>desired types, as in the case of a request for an in-line image.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 83]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The field MAY be folded onto several lines and more than one occurrence
>of the field is allowed, with the semantics being the same as if all
>the
>entries had been in one field value.
>
> Accept = "Accept" ":" #(
> media-range
> [ ( ":" | ";" )
>
> range-parameter
>
> *( ";" range-parameter ) ]
>
> | extension-token )
>
> media-range = ( "*/*"
> | ( type "/" "*" )
> | ( type "/" subtype )
> ) *( ";" parameter )
>
> range-parameter = ( "q" "=" qvalue )
> | extension-range-parameter
>
> extension-range-parameter = ( token "=" token )
>
> extension-token = token
>
>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
>media type quality factor for the range, which represents the user's
>preference for that range of media types. The default value is q=1.
>In
>Accept headers generated by HTTP/1.1 clients, the 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
>
> Accept: audio/*: q=0.2, audio/basic
>
>SHOULD be interpreted as "I prefer audio/basic, but send me any audio
>type if it is the best available after an 80% mark-down in quality."
>
>If no Accept header is present, then it is assumed that the client
>accepts all media types. If Accept headers are present, and if the
>server cannot send a response which is acceptable according to the
>Accept headers, then the server SHOULD send an error response with the
>406 (not acceptable) status code, though the sending of an unacceptable
>response is also allowed.
>
>A more elaborate example is
>
> Accept: text/plain: q=0.5, text/html,
> text/x-dvi: q=0.8, text/x-c
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 84]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Verbally, this would be interpreted as "text/html and text/x-c are the
>preferred media types, but if they do not exist, then send the text/x-
>dvi entity, and if that does not exist, send the text/plain entity."
>
>Media ranges can be overridden by more specific media ranges or
>specific
>media types. If more than one media range applies to a given type, the
>most specific reference has precedence. For example,
>
> Accept: text/*, text/html, text/html;level=1, */*
>
>have the following precedence:
>
> 1) text/html;level=1
> 2) text/html
> 3) text/*
> 4) */*
>
>The media type quality factor associated with a given type is
>determined
>by finding the media range with the highest precedence which matches
>that type. For example,
>
> Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
> */*:q=0.5
>
>would cause the following values to be associated:
>
> text/html;level=1 = 1
> text/html = 0.7
> text/plain = 0.3
> image/jpeg = 0.5
> text/html;level=3 = 0.7
>
> Note: A user agent MAY be provided with a default set of quality
> values for certain media ranges. However, unless the user agent is
> a closed system which cannot interact with other rendering agents,
> this default set SHOULD be configurable by the user.
>
>
>
>
>18.2 Accept-Charset
>The Accept-Charset request-header field can be used to indicate what
>character sets are acceptable for the response. This field allows
>clients capable of understanding more comprehensive or special-purpose
>character sets to signal that capability to a server which is capable
>of
>representing documents in those character sets. The ISO-8859-1
>character
>set can be assumed to be acceptable to all user agents.
>
> Accept-Charset = "Accept-Charset" ":"
>
> 1#( charset [ ";" "q" "=" qvalue ] )
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 85]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Character set values are described in section 7.4. Each charset may be
>given an associated quality value which represents the user's
>preference
>for that charset. The default value is q=1. An example 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
>if the server cannot send a response which is acceptable according to
>the Accept-Charset header, then the server SHOULD send an error
>response
>with the 406 (not acceptable) status code, though the sending of an
>unacceptable response is also allowed.
>
>
>
>
>18.3 Accept-Encoding
>The Accept-Encoding request-header field is similar to Accept, but
>restricts the content-coding values (18.13) which are acceptable in the
>response.
>
> Accept-Encoding = "Accept-Encoding" ":"
> #( content-coding )
>
>An example of its use is
>
> Accept-Encoding: compress, gzip
>
>If no Accept-Encoding header is present in a request, the server MAY
>assume that the client will accept any content coding. If an Accept-
>Encoding header is present, and if the server cannot send a response
>which is acceptable according to the Accept-Encoding header, then the
>server SHOULD send an error response with the 406 (not acceptable)
>status code.
>
>
>18.4 Accept-Language
>The Accept-Language request-header field is similar to Accept, but
>restricts the set of natural languages that are preferred as a response
>to the request.
>
> Accept-Language = "Accept-Language" ":"
> 1#( language-range [ ";" "q" "=" qvalue ] )
>
> language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) )
> | "*" )
>
>Each language-range MAY be given an associated quality value which
>represents an estimate of the user's comprehension of the languages
>specified by that range. The quality value defaults to "q=1" (100%
>comprehension).For example,
>
> Accept-Language: da, en-gb;q=0.8, en;q=0.7
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 86]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>would mean: "I prefer Danish, but will accept British English (with 80%
>comprehension) and other types of English(with 70% comprehension)." A
>language-range matches a language-tag if it exactly equals the tag, or
>if it exactly equals a prefix (a sub-sequence starting at the first
>character) of the tag such that the first tag character following the
>prefix is "-". The special range "*", if present in the
>Accept-Language
>field, matches every tag not matched by any other ranges present in the
>Accept-Language field.
>
> Note: This use of a prefix matching rule does not imply that
> language tags are assigned to languages in such a way that it is
> always true that if a user understands a language with a certain
> tag, then this user will also understand all languages with tags
> for which this tag is a prefix. The prefix rule simply allows the
> use of prefix tags if this is the case.
>
>The language quality factor assigned to a language-tag by the Accept-
>Language field is the quality value of the longest language-range in
>the
>field that matches the language-range. If no language-range in the
>field matches the tag, the language quality factor assigned is 0. If no
>Accept-Language header is present in the request, the server SHOULD
>assume that all languages are equally acceptable. If an
>Accept-Language
>header is present, then all languages which are assigned a quality
>factor greater than 0 are acceptable. If the server cannot generate a
>response for an audience capable of understanding at least one
>acceptable language, it can send a response that uses one or more un-
>accepted languages.
>
>It may be contrary to the privacy expectations of the user to send an
>Accept-Language header with the complete linguistic preferences of the
>user in every request. For a discussion of this issue, see section
>19.7.
>
> Note: As intelligibility is highly dependent on the individual
> user, it is recommended that client applications make the choice of
> linguistic preference available to the user. If the choice is not
> made available, then the Accept-Language header field MUST NOT be
> given in the request.
>
>
>
>
>18.5 Accept-Ranges
>In some cases, a client may want to know if the server accepts range
>requests using a certain range unit. The server may indicate its
>acceptance of range requests for a resource entity by providing this
>header in a response for that resource:
>
> Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
>
> acceptable-ranges = 1#range-unit | "none"
>
>Origin servers that accept byte-range requests MAY send
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 87]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Accept-Ranges: bytes
>
>but are not required to do so. Clients MAY generate byte-range
>requests
>without having received this header for the plain resource involved,
>but
>the server MAY ignore such requests.
>
>Origin servers that do not accept any kind of range request for a plain
>resource MAY send
>
> Accept-Ranges: none
>
>to advise the client not to attempt a range request.
>
>
>18.6 Age
>Caches transmit age values using:
>
> Age = "Age" ":" age-value
>
> age-value = delta-seconds
>
>Age values are non-negative decimal integers, representing time in
>seconds.
>
>If a cache receives a value larger than the largest positive integer it
>can represent, or if any of its age calculations overflows, it MUST
>transmit an Age header with a value of 2147483648 (2^31). Otherwise,
>HTTP/1.1 caches MUST send an Age header in every response. Caches
>SHOULD use a representation with at least 31 bits of range..
>
>
>18.7 Allow
>The Allow entity-header field lists the set of methods supported by the
>resource identified by the Request-URI. The purpose of this field is
>strictly to inform the recipient of valid methods associated with the
>resource. An Allow header field MUST be present in a 405 (method not
>allowed) response. The Allow header field is not permitted in a request
>using the POST method, and thus SHOULD be ignored if it is received as
>part of a POST entity.
>
> Allow = "Allow" ":" 1#method
>
>Example 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 be
>followed. The actual set of allowed methods is defined by the 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 by the new or modified resource. The server
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 88]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>is not required to support these methods and SHOULD include an Allow
>header in the response giving the actual supported methods.
>
>A proxy MUST NOT modify the Allow header field even if it does not
>understand all the methods specified, since the user agent MAY have
>other means 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 response header field
>(section 18.37) to describe what methods are implemented on the server
>as a whole.
>
>
>18.8 Alternates
>The Alternates response-header field is used by origin servers to
>signal
>that the resource identified by the current request has the capability
>to send different responses depending on the accept headers in the
>request message. This has an important effect on cache management,
>particularly for caching proxies which service a diverse set of user
>agents. This effect is covered in section 18.46.
>
> Alternates = "Alternates" ":" opaque-field
>
> opaque-field = field-value
>
>The Alternates header is included into HTTP/1.1 to make HTTP/1.1 caches
>compatible with a planned content negotiation mechanism. HTTP/1.1
>allows a future content negotiation standard to define the format of
>the
>Alternates header field-value, as long as the defined format satisfies
>the general rules in section 18.8.
>
>To ensure compatibility with future experimental or standardized
>software, caching HTTP/1.1 clients MUST treat all Alternates headers in
>a response as synonymous to the following Vary header:
>
> Vary: {accept-headers}
>
>and follow the caching rules associated with the presence of this Vary
>header, as covered in Section 18.46. HTTP/1.1 allows origin servers to
>send Alternates headers under experimental conditions.
>
>
>18.9 Authorization
>A user agent that wishes to authenticate itself with a server--usually,
>but not necessarily, after receiving a 401 response--MAY do so by
>including an Authorization request-header field with the request. The
>Authorization field value consists of credentials containing the
>authentication information of the user agent for the realm of the
>resource being requested.
>
> Authorization = "Authorization" ":" credentials
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 89]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>HTTP access authentication is described in section 14. 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 16.6) receives a request containing an
>Authorization field, it MUST NOT return the corresponding response as a
>reply to any other request, unless one of the following specific
>exceptions holds:
>
> 1. If the response includes the "proxy-revalidate" Cache-Control
> directive, the cache MAY use that response in replying to a
> subsequent request, but a proxy cache MUST first revalidate it
>with
> the origin server, using the request headers from the new request
> to allow the origin server to authenticate the new request.
> 2. If the response includes the "must-revalidate" Cache-Control
> directive, the cache MAY use that response in replying to a
> subsequent request, but all caches MUST first revalidate it with
> the origin server, using the request headers from the new request
> to allow the origin server to authenticate the new request.
> 3. If the response includes the "public" Cache-Control directive, it
> may be returned in reply to any subsequent request.
>
>18.10 Cache-Control
>The Cache-Control general-header field is used to specify directives
>that MUST be obeyed by all caching mechanisms along the
>request/response
>chain. The directives specify behavior intended to prevent caches from
>adversely interfering with the request or response. . These directives
>typically override the default caching algorithms. Cache directives
>are
>unidirectional in that the presence of a directive in a request does
>not
>imply that the same directive should be given in the response.
>
>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 the
>request/response chain. It is not possible to specify a cache-directive
>for a specific cache.
>
> Cache-Control = "Cache-Control" ":" 1#cache-directive
>
> cache-directive = "public"
> | "private" [ "=" <"> 1#field-name <"> ]
> | "no-cache" [ "=" <"> 1#field-name <"> ]
> | "no-store"
> | "no-transform"
> | "must-revalidate"
> | "proxy-revalidate"
> | "only-if-cached"
> | "max-age" "=" delta-seconds
> | "max-stale" "=" delta-seconds
> | "min-fresh" "=" delta-seconds
> | "min-vers" "=" HTTP-Version
>
>When a directive appears without any 1#field-name parameter, the
>directive applies to the entire request or response. When such a
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 90]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>directive appears with a 1#field-name parameter, it applies only to the
>named field or fields, and not to the rest of the request or response.
>This mechanism supports extensibility; implementations of future
>versions of the HTTP protocol may apply these directives to header
>fields not defined in HTTP/1.1.
>
>The cache-control directives can be broken down into these general
>categories:
>
> . Restrictions on what is cachable; these may only be imposed by the
> origin server.
> . Restrictions on what may be stored by a cache; these may be
>imposed
> by either the origin server or the end-user client.
> . Modifications of the basic expiration mechanism; these may be
> imposed by either the origin server or the end-user client.
> . Controls over cache revalidation and reload; these may only be
> imposed by an end-user client.
> . Restrictions on the number of times a cache entry may be used, and
> related demographic reporting mechanisms.
> . Miscellaneous restrictions
>Caches never add or remove Cache-Control directives to requests or
>responses.
>
>Check: is this true?
>
>
>18.10.1 Cache-Control Restrictions on What is Cachable
>Unless specifically constrained by a Cache-Control directive, a caching
>system may always store a successful response (see section 16.8) as a
>cache entry, may return it without validation if it is fresh, and may
>return it after successful validation. If there is neither a cache
>validator nor an explicit expiration time associated with a response,
>we
>do not expect it to be cached, but certain caches may violate this
>expectation (for example, when little or no network connectivity is
>available). A client can usually detect that such a response was taken
>from a cache by comparing the Date header to the current time.
>
> Note that some HTTP/1.0 caches are known to violate this
> expectation without providing any Warning.
>
>However, in some cases it may be inappropriate for a cache to retain a
>resource entity, or to return it in response to a subsequent request.
>This may be because absolute semantic transparency is deemed necessary
>by the service author, or because of security or privacy
>considerations.
>Certain Cache-Control directives are therefore provided so that the
>server can indicate that certain resource entities, or portions
>thereof,
>may not be cached regardless of other considerations.
>
>Note that section 18.8 normally prevents a shared cache from saving and
>returning a response to a previous request if that request included an
>Authorization header.
>
>The following Cache-Control response directives add or remove
>restrictions on what is cachable:
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 91]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>public
> Overrides the restriction in section 18.8 that prevents a shared
> cache from saving and returning a response to a previous request if
> that request included an Authorization header. However, any other
> constraints on caching still apply.
>
>private
> Indicates that all or part of the response message is intended for a
> single user and MUST NOT be cached by a shared cache. This allows an
> origin server to state that the specified parts of the response are
> intended for only one user and are not a valid response for requests
> by other users. A private (non-shared) cache may ignore this
> directive.
> Note: This usage of the word "private" only controls where the
> response may be cached, and cannot ensure the privacy of the
> message content. Note in particular that HTTP/1.0 caches will not
> recognize or obey this directive.
>
>
>no-cache
> indicates that all or partof the response message MUST NOT be cached
> anywhere. This allows an origin server to prevent caching even by
> caches that have been configured to return stale responses to client
> requests.
> Note: HTTP/1.0 caches will not recognize or obey this directive.
>
>TBS: precedence relations between public, private, and no-cache.
>
>
>18.10.2 What May be Stored by Caches
>The "no-store" directive applies to the entire message, and may be sent
>either in a response or in a request. If sent in a request, a cache
>MUST
>NOT store any part of either this request or any response to it. If
>sent
>in a response, a cache MUST NOT store any part of either this response
>or the request that elicited it. This directive applies to both non-
>shared and shared caches.
>
>Even when this directive is associated with a response, users may
>explicitly store such a response outside of the caching system (e.g.,
>with a "Save As" dialog). History buffers may store such responses as
>part of their normal operation.
>
>The purpose of this directive is to meet the stated requirements of
>certain users and service authors who are concerned about accidental
>releases of information via unanticipated accesses to cache data
>structures. While the use of this directive may improve privacy in some
>cases, we caution that it is NOT in any way a reliable or sufficient
>mechanism for ensuring privacy. In particular, HTTP/1.0 caches will not
>recognize or obey this directive, malicious or compromised caches may
>not recognize or obey this directive, and communications networks may
>be
>vulnerable to eavesdropping.
>
>The "min-vers" directive applies to the entire message, and may be sent
>either in a response or in a request. If sent in a request, a cache
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 92]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>whose HTTP version number is less than the specified version MUST NOT
>store any part of 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
>that elicited it, nor may any cache transmit a stored (non-firsthand)
>copy of the response to any client with a lower HTTP version number.
>This directive applies to both non-shared and shared caches, and is
>made
>mandatory to allow for future protocol extensions that may affect
>caching.
>
> Note that the lowest version that can be sensibly included in a
> "min-vers" directive is HTTP/1.1, since HTTP/1.0 caches do not obey
> it.
>
>
>18.10.3 Modifications of the Basic Expiration Mechanism
>The expiration time of a resource entity may be specified by the origin
>server using the Expires header (see section 18.22). Alternatively, it
>may be specified using the "max-age" directive in a response.
>
>If a response includes both an Expires header and a max-age directive,
>the max-age directive overrides the Expires header, even if the Expires
>header 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 useful if
>certain HTTP/1.0 caches improperly calculate ages or expiration times,
>perhaps due to synchronized clocks.
>
>Other directives allow an end-user client to modify the basic
>expiration
>mechanism, making it either stricter or looser. These directives may be
>specified on a request:
>
>
>max-age
> Indicates that the client is willing to accept a response whose age
> is no greater than the specified time in seconds. Unless "max-stale"
> is also included, the client is not willing to accept a stale
> response. This directive overrides any policy of the cache.
>
>min-fresh
> Indicates that the client is willing to accept a response whose
> freshness lifetime is no less than its current age plus the specified
> time in seconds. That is, the client wants a that response will still
> be fresh for at least the specified number of seconds.
>
>max-stale
> Indicates that the client is willing to accept a response that has
> exceeded its expiration time by no more than the specified number of
> seconds. If a cache returns a stale response in response to such a
> request, it MUST mark it as stale using the Warning header.
> Note that HTTP/1.0 caches will ignore these directives.
>
>If a cache returns a stale response, either because of a max-stale
>directive on a request, or because the cache is configured to override
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 93]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>the expiration time of a response, the cache MUST attach a Warning
>header to the stale response, using Warning 10 (Response is stale).
>
>
>18.10.4 Cache Revalidation and Reload Controls
>Sometimes an end-user client may want or need to insist that a cache
>revalidate its cache entry with the origin server (and not just with
>the
>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 necessary
>if either the cache or the origin server has overestimated the
>expiration time of the cached response. End-to-end reload may be
>necessary if the cache entryhas become corrupted for some reason, and
>the fact that its validator is up-to-date is irrelevant.
>
>End-to-end revalidation may be requested either when the client does
>not
>have its own local cached copy, in which case we call it "unspecified
>end-to-end revalidation", or when the client does 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 directives:
>
>
>End-to-end reload
> The request includes "Cache-Control: no-cache" or, for compatibility
> with HTTP/1.0 clients, "Pragma: no-cache". No field names may be
> included with the "no-cache" directive in a request. The server MUST
> NOT use a cached copy when responding to such a request.
>
>Specific end-to-end revalidation
> The request includes "Cache-Control: max-age=0", which forces each
> cache along the path to the origin server to revalidate its own
> entry, if any, with the next cache or server. The initial request
> includes a cache-validating conditional with the client's current
> validator.
>
>Unspecified end-to-end revalidation
> The request includes "Cache-Control: max-age=0", which forces each
> cache along the path to the origin server to revalidate its own
> entry, if any, with the next cache or server. The initial request
> does not include a cache-validating conditional; the first cache
> along the path (if any) that 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 client has
>supplied its own validator in the request, the supplied validator may
>differ from the validator currently stored with the cache entry. In
>this
>case, the cache may use either validator in making its own request
>without affecting semantic transparency.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 94]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>However, the choice of validator may affect performance. The best
>approach is for the intermediate cache to use its own validator when
>making its request. If the server replies with 304 (Not Modified), then
>the cache should return its now validated copy to the client with a 200
>(OK) response. If the server replies with a new Entity-body and cache
>validator, however, the intermediate cache should compare the returned
>validator with the one provided in the client's request, using the
>strong comparison function. If the client's validator is equal to the
>origin server's, then the intermediate cache simply returns 304 (Not
>Modified). Otherwise, it returns the new Entity-body with a 200 (OK)
>response.
>
>If a request includes the "no-cache" directive, it should not include
>"min-fresh", "max-stale", or "max-age".
>
>In some cases, such as times of extremely poor network connectivity, a
>client may want a cache to return only those responses that it
>currently
>has stored, and not to reload or revalidate with the origin server. To
>do this, the client may include the "only-if-cached" directive in a
>request. If it receives this directive, a cache SHOULD either respond
>using a cached entry that is consistent with the other constraints of
>the request, or respond with a 504 (Gateway Timeout) status. However,
>if
>a group of caches is being operated as a unified system with good
>internal connectivity, such a request MAY be forwarded within that
>group
>of caches.
>
>Because a cache may be configured to ignore a server's specified
>expiration time, and because a client request may include a max-stale
>directive, which has a similar effect, the protocol also includes a
>mechanism for the origin server to require revalidation of a cache
>entry
>on any subsequent use. When the "must-revalidate" directive is present
>in a response received by a cache, that cache MUST NOT use the entry
>after it becomes stale to respond to a subsequent request without first
>revalidating it with the origin server. (I.e., the cache must do an
>end-
>to-end revalidation every time, if, based solely on the origin server's
>Expires or max-age value, the cached response is stale.)
>
>The "must-revalidate" directive is necessary to support reliable
>operation for certain protocol features. In all circumstances an
>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 504 (Gateway Timeout) response. Note that HTTP/1.0 caches
>will ignore this directive.
>
>Servers should send the "must-revalidate" directive if and only if
>failure to revalidate a request on the entity could result in incorrect
>operation, such as a 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
>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 user that an unvalidated response has been
>provided.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 95]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The warning MUST be provided on each unvalidated access, and SHOULD
>require explicit user confirmation.
>
>The "proxy-revalidate" directive has the same meaning as the "must-
>revalidate" directive, except that it does not apply to user-agent
>caches.
>
>
>18.10.5 Miscellaneous Restrictions
>In certain circumstances, an intermediate cache (proxy) may find it
>useful to convert the encoding of an entity body. For example, a proxy
>might use a compressed content-coding to transfer the body to a client
>on a slow link.
>
>Because end-to-end authentication of entity bodies and/or entity
>headers
>relies on the specific encoding of these values, such transformations
>may cause authentication failures. Therefore, an intermediate cache
>MUST
>NOT change the encoding of an entity body if the response includes the
>"no-transform" directive.
>
> Note: the use of hop-by-hop compression in conjunction with Range
> retrievals may require additional specification in a subsequent
> draft.
>
>
>18.11 Connection
>HTTP version 1.1 provides a new request and response header field
>called
>"Connection". This header field allows the client and server to specify
>options which should only exist over that particular connection and
>MUST
>NOT be communicated by proxies over further connections. The connection
>header field MAY have multiple tokens separated by commas (referred to
>as connection-tokens).
>
>HTTP version 1.1 proxies MUST parse the Connection header field and for
>every connection-token in this field, remove a corresponding header
>field from the request before the request is forwarded. The use of a
>connection option is specified by the presence of a connection token in
>the Connection header field, not by the corresponding additional header
>field (which may not be present).
>
>When a client wishes to establish a persistent connection it MUST send
>a
>"Persist" connection-token:
>
> Connection: persist
>
>The Connection header has the following grammar:
>
> Connection-header = "Connection" ":" 1#(connection-token)
> connection-token = token
>
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 96]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>18.12 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 , 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.
>
>
>18.13 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 entity, 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
>
>Content codings are defined in section 7.5. An example of its use is
>
> Content-Encoding: gzip
>
>The Content-Encoding is a characteristic of the resource entity
>identified by the Request-URI. Typically, the resource entity is stored
>with this encoding and is only decoded before rendering or analogous
>usage.
>
>If multiple encodings have been applied to a resource entity, 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.
>
>
>18.14 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 7.10. The primary purpose of
>Content-Language is to allow a selective consumer to identify and
>differentiate resource variants according to the consumer's own
>preferred language. Thus, if the body content is intended only for a
>Danish-literate audience, the appropriate field is
>
> Content-Language: dk
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 97]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>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 be listed for content that is intended for
>multiple audiences. For example, a rendition of the "Treaty of
>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 First Lesson
>in Latin," which is clearly intended to be used by an English-literate
>audience. In this case, the Content-Language should only include "en".
>
>Content-Language MAY be applied to any media type -- it SHOULD not be
>limited to textual documents.
>
>
>18.15 Content-Length
>The Content-Length entity-header field indicates the size of the
>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 use this field to indicate the size of the Entity-
>Body to be transferred, regardless of the media type of the entity. It
>must be possible for the recipient to reliably determine the end of a
>HTTP/1.1 request method containing an entity body, e.g., because the
>request has a valid Content-Length field, uses Transfer-Encoding:
>chunked or a multipart body.
>
>Any Content-Length greater than or equal to zero is a valid value.
>Section 11.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" content-type. In HTTP, it
> SHOULD be used whenever the entity's length can be determined prior
> to being transferred.
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 98]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>18.16 Content-Location
>The Content-Location entity-header field is used to define the location
>of the plain resource associated with the entity enclosed in the
>message. A server SHOULD provide a Content-Location if, when including
>an entity in response to a GET request on a generic resource, the
>entity
>corresponds to a specific, non-negotiated location which can be
>accessed
>via the Content-Location URI. A server SHOULD provide a
>Content-Location
>with any 200 (OK) response which was internally (not visible to the
>client) redirected to a resource other than the one identified by the
>request and for which correct interpretation of that resource MAY
>require knowledge of its actual location.
>
> Content-Location = "Content-Location" ":" absoluteURI
>
>If no Content-Base header field is present, the value of Content-
>Location also defines the base URL for the entity (see Section 18.12).
>
> Note that the Content-Location information is advisory, and that
> there is no guarantee that the URI of the Content-Location actually
> corresponds in any way to the original request URI. For example, a
> cache cannot reliably assume that the data returned as a result of
> the request can be returned from a new request on any URI other
> than the original request. See section 19.9.
>
>
>18.17 Content-MD5
>The Content-MD5 entity-header field is an MD5 digest of the
>entity-body,
>as defined in RFC 1864 [], for the purpose of providing an end-to-end
>message integrity check (MIC) of the entity-body. (Note: an MIC is good
>for detecting accidental modification of the entity-body in transit,
>but
>is not proof against malicious attacks.)
>
> ContentMD5 = "Content-MD5" ":" md5-digest
>
> md5-digest = <base64 of 128 bit MD5 digest as per RFC
>1864>
>
>The Content-MD5 header may be generated by an origin server to function
>as an integrity check of the entity-body. Only origin-servers may
>generate the Content-MD5 header field; proxies and gateways MUST NOT
>generate it, as this would defeat its value as an end-to-end integrity
>check. Any recipient of the entity-body, including gateways and
>proxies,
>MAY check that the digest value in this header field matches that of
>the
>entity-body as received.
>
>The MD5 digest is computed based on the content of the entity body,
>including any Content-Encoding that has been applied, but not including
>any Transfer-Encoding. If the entity is received with a Transfer-
>Encoding, that encoding must be removed prior to checking the Content-
>MD5 value against the received entity.
>
>This has the result that the digest is computed on the octets of the
>entity body exactly as, and in the order that, they would be sent if no
>Transfer-Encoding were being applied.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 99]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>HTTP extends RFC 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 computed as defined in the preceding
>paragraph.
>
> Note: There are several consequences of this. The entity-body for
> composite types may contain many body-parts, each with its own MIME
> and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
> and Content-Encoding headers). If a body-part has a Content-
> Transfer-Encoding or Content-Encoding header, it is assumed that
> the content of the body-part has had the encoding applied, and the
> body-part is included in the Content-MD5 digest as is -- i.e.,
> after the application. Also, the HTTP Transfer-Encoding header
> makes no sense within body-parts; if it is present, it is ignored -
> - i.e. treated as ordinary text.
>
> Note: while the definition of Content-MD5 is exactly the same for
> HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
> in which the application of Content-MD5 to HTTP entity-bodies
> differs from its application to MIME entity-bodies. One is that
> HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
> use Transfer-Encoding and Content-Encoding. Another is that HTTP
> more frequently uses binary content types than MIME, so it is worth
> noting that in such cases, the byte order used to compute the
> digest is the transmission byte order defined for the type. Lastly,
> HTTP allows transmission of text types with any of several line
> break conventions and not just the canonical form using CRLF.
> Conversion of all line breaks to CRLF should not be done before
> computing or checking the digest: the line break convention used in
> the text actually transmitted should be left unaltered when
> computing the digest.
>
>
>
>
>18.18 Content-Range
>The Content-Range header is sent with a partial entity body to specify
>where in the full entity body the partial body should be inserted. It
>also indicates the total size of the entity.
>
> Content-Range = "Content-Range" ":" content-range-spec
>
>When an HTTP message includes the content of a single range (for
>example, a response to a request for a single range, or to request for
>a
>set of ranges that overlap without any holes), this content is
>transmitted with a Content-Range header, and a Content-Length header
>showing the number of bytes actually transferred. For example,
>
> HTTP/1.0 206 Partial content
> Date: Wed, 15 Nov 1995 06:25:24 GMT
> Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
> Content-Range: 21010-47021/47022
> Content-Length: 26012
> Content-Type: image/gif
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 100]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>18.18.1 MIME multipart/byteranges Content-type
>When an HTTP message includes the content of multiple ranges (for
>
>example, a response to a request for multiple non-overlapping ranges),
>these are transmitted as a multipart MIME message. The multipart MIME
>content-type used for this purpose is defined in this specification to
>be "multipart/byteranges".
>
>The MIME multipart/byteranges content-type includes two or more parts,
>each with its own Content-Type and Content-Range fields. The parts are
>separated using a MIME boundary parameter.
>
>For example:
>
> 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_
>
>
>18.18.2 Additional Rules for Content-Range
>A client that cannot decode a MIME multipart/byteranges message should
>not ask for multiple byte-ranges in a single request.
>
>When a client requests multiple byte-ranges in one request, the server
>SHOULD return them in the order that they appeared in the request.
>
>If the server ignores a byte-range-spec because it is invalid, the
>server should treat the request as if the invalid Range header field
>did
>not exist (normally, this means return a 200 response containing the
>full resource entity). The reason is that the only time a client will
>make such an invalid request is when the resource entity has changed
>(shrunk) since the prior request.
>
>
>18.19 Content-Type
>The Content-Type entity-header field indicates the media type of the
>Entity-Body sent to the recipient or, in the case of the HEAD method,
>the media type that would have been sent had the request been a GET.
>
> Content-Type = "Content-Type" ":" media-type
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 101]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Media types are defined in section 7.7. An example of the field is
>
> Content-Type: text/html; charset=ISO-8859-4
>
>Further discussion of methods for identifying the media type of an
>entity is provided in section 11.2.1.
>
>
>18.20 Date
>The Date general-header field represents the date and time at which the
>message was originated, having the same semantics as orig-date in RFC
>822. The field value is an HTTP-date, as described in section 7.3.1.
>
> Date = "Date" ":" HTTP-date
>
>An example is
>
> Date: Tue, 15 Nov 1994 08:12:31 GMT
>
>If a message is received via direct connection with the user agent (in
>the case of requests) or the origin server (in the case of responses),
>then the date can be assumed to be the current date at the receiving
>end. However, since the date--as it is believed by the origin--is
>important 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, as in the case of the PUT and
>POST
>requests, and even then it is optional. A received message which does
>not have a Date header field SHOULD be assigned one by the recipient if
>the message will be cached by that recipient or gatewayed via a
>protocol
>which requires a Date.
>
>In theory, the date SHOULD represent the moment just before the entity
>is generated. In practice, the date can be generated at any time during
>the message origination without affecting its semantic value.
>
> Note: An earlier version of this document incorrectly specified
> that this field 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 Date field in every response. However, if a
>cache receives a response without a Date field, it SHOULD attach one
>with the cache's best estimate of the time at which the response was
>originally generated.
>
>The format of the Date is an absolute date and time as defined by HTTP-
>date in Section 7.3; it MUST be in RFC1123-date format.
>
>
>
>
>18.21 ETag
>The ETag header is used to transmit entity tags with variant id's in
>HTTP/1.1 responses.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 102]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> ETag = "ETag" ":" etag-info
> etag-info = entity-tag [ ";" variant-id ]
>
>Examples:
>
> ETag: "xyzzy"
> ETag: "xyzzy"/W
> ETag: "xyzzy";"3"
> ETag: "xyzzy"/W;"3"
> ETag: ""
>
> Note that the variant-id is not part of the entity tag. The ETag
> field is used to transmit a variant-id simply as a matter of
> compact representation of responses.
>
>
>18.22 Expires
>The Expires entity-header field gives the date/time after which the
>entity should be considered stale. A stale cache entry may not normally
>be returned by a cache (either a proxy cache or an end-user cache)
>unless it is first validated with the origin server (or with an
>intermediate cache that has a fresh copy of the resource entity). See
>section 16.1.2 for further discussion of the expiration model.
>
>The presence of an Expires field does not imply that the 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 7.3; it MUST be in rfc1123-date format:
>
> Expires = "Expires" ":" HTTP-date
>
>An example of its use is
>
> Expires: Thu, 01 Dec 1994 16:00:00 GMT
>
> Note: if a response includes a Cache-Control field with the max-age
> directive, that directive overrides the Expires field.
>
>HTTP/1.1 clients and caches MUST treat other invalid date 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 equal to the Date header value. (See the rules for
>expiration calculations in section 0.)
>
>To mark a response as "never expires," an origin server should use an
>Expires date approximately one year from the time the response is
>generated. HTTP/1.1 servers should not send Expires dates more than one
>year in the future.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 103]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>18.23 From
>The From request-header field, if given, SHOULD contain an Internet e-
>mail address for the human user who controls the requesting user agent.
>The address SHOULD be machine-usable, as defined by mailbox in RFC 822
>(as updated by RFC 1123 ):
>
> From = "From" ":" 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 invalid or unwanted requests. It SHOULD NOT
>be
>used as an insecure form of access protection. The interpretation of
>this field is that the request is being performed on behalf of the
>person given, who accepts responsibility for the method performed. In
>particular, robot agents SHOULD include this header so that the person
>responsible for running the robot can be contacted if problems occur on
>the receiving end.
>
>The Internet e-mail address in this field MAY be separate from the
>Internet host which issued the request. For example, when a request is
>passed through a proxy the original issuer's address SHOULD be used.
>
> Note: The client SHOULD not send the From header field without the
> user's approval, as 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 value of this field at any time prior to a request.
>
>
>18.24 Host
>The Host request-header field specifies the Internet host and port
>number of the resource being requested, as obtained from the original
>URL given by the user or referring resource (generally an HTTP URL, as
>described in section 7.2.2). The Host field value MUST represent the
>network location of the origin server or gateway given by the original
>URL. This allows the origin server or gateway to differentiate between
>internally-ambiguous URLs, such as the root "/" URL of a server for
>multiple host names on a single IP address.
>
> Host = "Host" ":" host [ ":" port ] ; Section 7.2.2
>
>A "host" without any trailing port information implies the default port
>for the service requested (e.g., "80" for an HTTP URL). For example, a
>request on the origin server for <http://www.w3.org/pub/WWW/> MUST
>include:
>
> GET /pub/WWW/ HTTP/1.1
> Host: www.w3.org
>
>The Host header field MUST be included in all HTTP/1.1 request messages
>on the Internet (i.e., on any message corresponding to a request for a
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 104]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>URL which includes an Internet host address for the service being
>requested). If the Host field is not already present, an HTTP/1.1
>proxy
>MUST add a Host field to the request message prior to forwarding it on
>the Internet. All Internet-based HTTP/1.1 servers MUST respond with a
>400 status code to any HTTP/1.1 request message which lacks a Host
>header field.
>
>
>18.25 If-Modified-Since
>The If-Modified-Since request-header field is used with the GET method
>to make it conditional: if the requested resource entity has not been
>modified since the time specified in this field, a copy of the resource
>entity will not be returned from the server; instead, a 304 (not
>modified) response will be returned without any Entity-Body.
>
> If-Modified-Since = "If-Modified-Since" ":" HTTP-date
>
>An example of the field is:
>
> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
>
>A GET method with an If-Modified-Since header and no Range header
>requests that the identified resource entity 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:
>
>
>a)If the request would normally result in anything other than a 200
> (OK) status, or if the passed If-Modified-Since date is invalid, the
> response is exactly the same as for a normal GET. A date which is
> later than the server's current time is invalid.
>
>b)If the resource entity has been modified since the If-Modified-Since
> date, the response is exactly the same as for a normal GET.
>
>c)If the resource entity has not been modified since a valid If-
> Modified-Since date, 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.
>
> Note that the Range request-header field modifies the meaning of
> If-Modified-Since; see section 18.38 for full details.
>
> Note that If-Modified-Since is ignored for generic resources.
>
> Note that If-Modified-Since times are interpreted by the server,
> whose clock may not be synchronized with the client.
>
> Note that if a client uses an arbitrary date in the If-Modified-
> Since header instead of a date taken from the Last-Modified header
> for the same request, the client should be aware of the fact that
> this date is interpreted in the server's understanding of time.
> The client should consider unsynchronized clocks and rounding
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 105]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> problems due to the different representations of time between the
> client and server. This includes the possibility of race
> conditions if the document has changed between the time it was
> first requested 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 different time
> bases between client and server are at best approximate due to
> network latency.
>
>
>
>
>18.26 If-Match
>The If-Match request-header field is used with a method to make it
>conditional. A client that has a cache entry for the relevant entity
>supplies the associated entity tag using the If-Match header; if this
>entity tag matches the server's current entity tag for the entity, the
>server SHOULD perform the requested operation as if the If-Match header
>were not present.
>
>If the entity tags do not match, the server MUST NOT perform the
>requested operation, and MUST return a 412 (Precondition failed)
>response with no Entity-Body. This behavior is most useful when the
>client wants to prevent an updating method, such as PUT or POST, from
>modifying a resource entity that has changed since the client last
>checked it.
>
>When the If-Match header is used, the server should use the strong
>comparison function (see section 18.26) to compare entity tags.
>
>If the If-Match header is used to make a conditional request on generic
>resource, it may be used to pass a set of validators. This is done
>using the variant-set mechanism if the client has variant IDs for the
>corresponding cache entries (see sections 16.5.3 and 7.13 ). The
>server
>selects the appropriate variant based on other request headers; if the
>variant-ID for that resource entity is listed in the If-Match header,
>and if the entity-tag associated with that variant-ID in the header
>matches the current entity-tag of the resource entity, then the
>requested operation SHOULD be performed. Otherwise, it MUST NOT be
>performed.
>
> If-Match = "If-Match" ":" if-match-rhs
> if-match-rhs = opaque-validator | variant-set
>
>An updating request (e.g., a PUT or POST) on a generic resource should
>include only one variant-set-item, the one associated with the
>particular variant whose value is being conditionally updated.
>
>Examples of plain resource form:
>
> If-Match: "xyzzy"
> If-Match: "xyzzy"/W
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 106]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Examples of generic resource form:
>
> If-Match: "xyzzy";"4"
> If-Match: "xyzzy";"3", "r2d2xxxx";"5", "c3piozzzz";"7"
> If-Match: "xyzzy"/W; "3", "r2d2xxxx"/W; "5", "c3piozzzz"/W; "7"
>
>If the request would, without the If-Match header, result in anything
>other than a 2xx status, then the If-Match header is ignored.
>
>The purpose of this feature is to allow efficient updates of cached
>information with a minimum amount of transaction overhead. It is also
>used, on updating requests, to prevent inadvertent modification of the
>wrong variant of a resource.
>
>
>18.27 If-NoneMatch
>The If-NoneMatch request-header field is used with a method to make it
>conditional. A client that has a cache entry for the relevant entity
>supplies the associated entity tag using the If-NoneMatch header; if
>this entity tag matches the server's current entity tag for the entity,
>the server SHOULD return a 304 (Not Modified) response without any
>Entity-Body.
>
>If the entity tags do not match, the server should treat the request as
>if the If-NoneMatch header was not present.
>
>See section 18.26 for rules on how to determine if two entity tags
>match.
>
>If the If-NoneMatch header is used to make a conditional request on
>generic resource, it may be used to pass a set of validators. This is
>done using the variant-set mechanism if the client has variant IDs for
>the corresponding cache entries (see sections 16.5.3 and 7.13). The
>server selects the appropriate variant based on other request headers;
>if the variant-ID for that resource entity is listed in the
>If-NoneMatch
>header, and if the entity-tag associated with that variant-ID in the
>header matches the current entity-tag of the resource entity, then the
>requested operation SHOULD NOT be performed. Otherwise, it SHOULD be
>performed.
>
> If-NoneMatch = "If-NoneMatch" ":" if-nonematch-rhs
> if-nonematch-rhs = opaque-validator | variant-set
>
>Examples of plain resource form:
>
> If-NoneMatch: "xyzzy"
> If-NoneMatch: "xyzzy"/W
>
>Examples of generic resource form:
>
> If-NoneMatch: "xyzzy";"4"
> If-NoneMatch: "xyzzy";"3", "r2d2xxxx";"5", "c3piozzzz";"7"
> If-NoneMatch: "xyzzy"/W; "3", "r2d2xxxx"/W; "5", "c3piozzzz"/W;7
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 107]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>If the request would, without the If-NoneMatch header, result in
>anything other than a 2xx status, then the If-NoneMatch header is
>ignored.
>
>The purpose of this feature is to allow efficient updates of cached
>information with a minimum amount of transaction overhead.
>
>
>18.28 If-Range
>If a client has a partial copy of an entity in its cache, and wishes to
>have an up-to-date copy of the entire entity in its cache, it could use
>the Range request header with a conditional GET (using either or both
>of
>If-Unmodified-Since and If-Match.) However, if the condition fails
>because the entity has been modified, the client would then have to
>make
>a second request to obtain the entire current entity body.
>
>The If-Range header allows a client to "short-circuit" the second
>request. Informally, its meaning is "if the entity is unchanged, send
>me the part(s) that I am missing; otherwise, send me the entire new
>entity.'"
>
> Range-If = "Range-If" ":" (if-valid-rhs | HTTP-date)
>
>If the client has no entity tag for a plain resource, but does have a
>Last-Modified date, it may use that date in a If-Range header. (The
>server can detect this because an HTTP-date, unlike any form of if-
>valid-rhs, does not start with a `"' quotation mark.) Dates may only
>be
>used in If-Range for plain resources, not for generic resources. The
>If-Range header should only be used together with a Range header, and
>must be ignored if the request does not include a Range header, or if
>the server does not support the sub-range operation.
>
>If the entity tag given in the If-Range header matches the current
>entity tag for the entity, then the server should provide the specified
>sub-range of the entity using a 206 (Partial content) response. If the
>entity tag does not match, then the server should return the entire
>entity using a 200 (OK) response.
>
>
>18.29 If-Unmodified-Since
>The If-Unmodified-Since request-header field is used with a method to
>make it conditional. If the requested resource entity has not been
>modified since the time specified in this field, the server should
>perform the requested operation as if the If-Unmodified-Since header
>were not present.
>
>If the requested resource entity has been modified since the specified
>time, the server MUST NOT perform the requested operation, and MUST
>return a 412 (Precondition Failed) response with no Entity-Body.
>
> If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
>
>An example of the field is:
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 108]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
>
>If the request normally (i.e., without the If-Unmodified-Since header)
>would result in anything other than a 2xx status, the If-Unmodified-
>Since header should be ignored.
>
>If the specified date is invalid, the header is ignored.
>
>
>18.30 Last-Modified
>The Last-Modified entity-header field indicates the date and time at
>which the sender believes the resource entity was last modified. The
>exact semantics of this field are defined in terms of how the recipient
>SHOULD interpret it: if the recipient has a copy of this resource
>entity
>which is older than the date given by the Last-Modified field, that
>copy
>SHOULD be considered stale.
>
> Last-Modified = "Last-Modified" ":" HTTP-date
>
>An example of its use is
>
> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
>
>The exact meaning of this header field depends on the implementation of
>the sender and the nature of the original resource. For files, it may
>be
>just the file system last-modified time. For entities with dynamically
>included parts, it may be the most recent of the set of last-modify
>times for its component parts. For database gateways, it may be the
>last-update time stamp of the record. For virtual objects, it may be
>the
>last time the internal state changed.
>
>An origin server MUST NOT send a Last-Modified date which is later than
>the server's time of message origination. In such cases, where the
>resource's last modification would indicate some time in the future,
>the
>server MUST replace that date with the message origination date.
>
>An origin server should obtain the Last-Modified value of the entity as
>close as possible to the time that it generates the Date value of its
>response. This allows a recipient to make an accurate assessment of the
>entity's modification time, especially if the entity changes near the
>time that the response is generated.
>
>
>18.31 Location
>The Location response-header field is used to redirect the recipient to
>a location other than the Request-URI for completion of the request or
>identification of a new resource. For 201 (created) responses, the
>Location is that of the new resource which was created by the request.
>For 3xx responses, the location SHOULD indicate the server's preferred
>URL for automatic redirection to the resource. The field value consists
>of a single absolute URL.
>
> Location = "Location" ":" absoluteURI
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 109]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>An example is
>
> Location: http://www.w3.org/pub/WWW/People.html
>
> Note: The Content-Location header field (section 18.16) differs
> from Location in that the Content-Location identifies the original
> location of the entity enclosed in the request. It is therefore
> possible for a response to contain header fields for both Location
> and Content-Location.
>
>
>18.32 Max-Forwards
>[JG14]The Max-Forwards general-header field may be used with the TRACE
>method (section 18.32) to limit the number of times that a proxy or
>gateway can forward the request to the next inbound server. This can
>be
>useful when the client is attempting to trace a request chain which
>appears to be failing or looping in mid-chain.
>
> Max-Forwards = "Max-Forwards" ":" 1*DIGIT
>
>The Max-Forwards value is a decimal integer indicating the remaining
>number of times this request message may be forwarded.
>
>Each proxy or gateway recipient of a TRACE request containing a Max-
>Forwards header field SHOULD check and update its value prior to
>forwarding the request. If the received value is zero (0), the
>recipient SHOULD NOT forward the request; instead, it SHOULD respond as
>the final recipient with a 200 (OK) response containing the received
>request message as the response entity body (as described in Section
>13.7). If the received Max-Forwards value is greater than zero, then
>the forwarded message SHOULD contain an updated Max-Forwards field with
>a value decremented by one (1).
>
>The Max-Forwards header field SHOULD be ignored for all other methods
>defined by this specification and for any extension methods for which
>it
>is not explicitly referred to as part of that method definition.
>
>
>18.33 Persist
>When the Persist connection-token has been transmitted with a request
>or
>a response a Persist header field MAY also be included. The Persist
>header field takes the following form:
>
> Persist-header = "Persist" ":" 0#pers-param
>
> pers-param = param-name "=" word
> param-name = token
>
>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.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 110]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>18.34 Pragma
>The Pragma general-header field is used to include implementation-
>specific directives that may apply to any recipient along the
>request/response chain. All pragma directives specify optional behavior
>from the viewpoint of the protocol; however, some systems MAY require
>that behavior be consistent with the directives.
>
> Pragma = "Pragma" ":" 1#pragma-directive
>
> pragma-directive = "no-cache" | extension-pragma
> extension-pragma = token [ "=" word ]
>
>When the "no-cache" directive is present in a request message, an
>application SHOULD forward the request toward the origin server even if
>it has a cached copy of what is being requested. This pragma directive
>has the same semantics as the "no-cache" cache-directive (see section
>18.10) 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 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,
>since
>the directives may be applicable to all recipients along the
>request/response chain. It is not possible to specify a pragma for a
>specific recipient; however, any pragma directive not relevant to a
>recipient SHOULD be ignored by that recipient.
>
>HTTP/1.1 clients SHOULD NOT send the Pragma request header. HTTP/1.1
>caches SHOULD treat "Pragma: no-cache" as if the client had sent
>"Cache-
>control: no-cache". No new Pragma directives will be defined in HTTP.
>
>
>18.35 Proxy-Authenticate
>The Proxy-Authenticate response-header field MUST be included as part
>of
>a 407 (Proxy Authentication Required) response. The field value
>consists
>of a challenge that indicates the authentication scheme and parameters
>applicable to the proxy for this Request-URI.
>
> Proxy-Authentication = "Proxy-Authentication" ":" challenge
>
>The HTTP access authentication process is described in section 14.
>Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
>only to the current connection and MUST NOT be passed on to downstream
>clients.
>
>
>18.36 Proxy-Authorization
>The Proxy-Authorization request-header field allows the client to
>identify itself (or its user) to a proxy which requires authentication.
>The Proxy-Authorization field value consists of credentials containing
>the authentication information of the user agent for the proxy and/or
>realm of the resource being requested.
>
> Proxy-Authorization = "Proxy-Authorization" ":" credentials
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 111]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The HTTP access authentication process is described in section 14.
>Unlike Authorization, the Proxy-Authorization applies only to the
>current connection and MUST NOT be passed on to upstream servers. If a
>request is authenticated and a realm specified, the same credentials
>SHOULD be valid for all other requests within this realm.
>
>
>18.37 Public
>The Public response-header field lists the set of non-standard methods
>supported by the server. The purpose of this field is strictly to
>inform
>the recipient of the capabilities of the server regarding unusual
>methods. The methods listed may or may not be applicable to the
>Request-
>URI; the Allow header field (section 18.7) SHOULD be used to indicate
>methods allowed for a particular URI. This does not prevent a client
>from trying other methods. The field value SHOULD not include the
>methods predefined for HTTP/1.1 in section 9.1.1.
>
> Public = "Public" ":" 1#method
>
>Example of use:
>
> Public: OPTIONS, MGET, MHEAD
>
>This header field applies only to the server directly connected to the
>client (i.e., the nearest neighbor in a chain of connections). If the
>response passes through a proxy, the proxy MUST either remove the
>Public
>header field or replace it with one applicable to its own capabilities.
>
>
>18.38 Range
>HTTP retrieval requests using conditional or unconditional GET methods
>may request one or more sub-ranges of the entity, instead of the 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,
>since this supports efficient recovery from partially failed transfers,
>and it supports efficient partial retrieval of large entities.
>
>If the server supports the Range header and the specified range or
>ranges are appropriate for the entity:
>
> . The presence of a Range header in an unconditional GET modifies
> what is returned if the 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-NoneMatch, or one or
> both of If-Unmodified-Since and If-Match) modifies what is
>returned
> if the GET is otherwise successful and the condition is true. It
> does not affect the 304 (Not Modified) response returned if the
> conditional is false.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 112]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>In some cases, it may be more appropriate to use the If-Range header
>(see section 18.28) in addition to the Range header.
>
>
>18.39 Referer
>The Referer[sic] request-header field allows the client to specify, for
>the server's benefit, the address (URI) of the resource from which the
>Request-URI was obtained. This allows a server to generate lists 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 if the Request-URI was obtained from
>a source 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 is given, it SHOULD be interpreted relative to the
>Request-URI. The URI MUST NOT include a fragment.
>
> Note: Because the source of a link may be private information or
> may reveal an otherwise private information source, it is strongly
> recommended that the user be able to select whether or not the
> Referer field is sent. For example, a browser client could have a
> toggle switch for browsing openly/anonymously, which would
> respectively enable/disable the sending of Referer and From
> information.
>
>
>18.40 Retry-After
>The Retry-After response-header field can be used with a 503 (Service
>Unavailable) response to indicate how long the service is expected to
>be
>unavailable to the requesting client. The value of this field can be
>either an HTTP-date or an integer number of seconds (in decimal) after
>the time of the response.
>
> Retry-After = "Retry-After" ":" ( 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 is 2 minutes.
>
>
>18.41 Server
>The Server response-header field contains information about the
>software
>used by the origin server to handle the request. The field can contain
>multiple product tokens (section 7.8) and comments identifying the
>server and any significant subproducts. By convention, the product
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 113]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>tokens are listed in order of their significance for identifying the
>application.
>
> Server = "Server" ":" 1*( product | comment )
>
>Example:
>
> Server: CERN/3.0 libwww/2.17
>
>If the response is being forwarded through a proxy, the proxy
>application MUST NOT add its data to the product list. Instead, it
>SHOULD include a Via field (as described in section 18.47).
>
> Note: Revealing the specific software version of the server may
> allow the server machine to become more vulnerable to attacks
> against software that is known to contain security holes. Server
> implementers are encouraged to make this field a configurable
> option.
>
>
>18.42 Title
>The Title entity-header field indicates the title of the entity
>
> Title = "Title" ":" *TEXT
>
>An example of the field is
>
> Title: Hypertext Transfer Protocol -- HTTP/1.1
>
>This field is isomorphic with the <TITLE> element in HTML .
>
>
>18.43 Transfer Encoding
>The Transfer-Encoding general-header field indicates what (if any) type
>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 of
>the message, not of the original resource entity.
>
> Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-
>coding
>
>Transfer codings are defined in section 7.6. An example is:
>
> Transfer-Encoding: chunked
>
>Many older HTTP/1.0 applications do not understand the
>Transfer-Encoding
>header.
>
>
>18.44 Upgrade
>The Upgrade general-header allows the client to specify what additional
>communication protocols it supports and would like to use if the server
>finds it appropriate to switch protocols. The server MUST use the
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 114]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Upgrade 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 Upgrade header field is intended to provide a simple mechanism for
>transition from HTTP/1.1 to some other, incompatible protocol. It does
>so by allowing the client to advertise its desire to use another
>protocol, such as a later version of HTTP with a higher major version
>number, even though the current request has been made using HTTP/1.1.
>This eases the difficult transition between incompatible protocols by
>allowing the client to initiate a request in the more commonly
>supported
>protocol while indicating to the server that it would like to use a
>"better" protocol if available (where "better" is determined by the
>server, possibly according to the nature of the method and/or resource
>being requested).
>
>The Upgrade header field only applies to switching application-layer
>protocols upon the existing transport-layer connection. Upgrade cannot
>be used to insist on a protocol change; its acceptance and use by the
>server is optional. The capabilities and nature of the application-
>layer communication after the protocol change is entirely dependent
>upon
>the new protocol chosen, although the first action after changing the
>protocol MUST be a response to the initial HTTP request containing the
>Upgrade header field.
>
>The Upgrade header field only applies to the immediate connection.
>Therefore, the "upgrade" keyword MUST be supplied within a Connection
>header field (section 18.11) whenever Upgrade is present in an HTTP/1.1
>message.
>
>The Upgrade header field cannot be used to indicate a switch to a
>protocol on a different connection. For that purpose, it is more
>appropriate to use a 301, 302, 303, or 305 redirection response.
>
>This specification only defines the protocol name "HTTP" for use by the
>family of Hypertext Transfer Protocols, as defined by the HTTP version
>rules of section 7.1 and future updates to this specification. Any
>token can be used as a protocol name; however, it will only be useful
>if
>both the client and server associate the name with the same protocol.
>
>
>18.45 User-Agent
>The User-Agent request-header field contains information about the user
>agent originating the request. This is for statistical purposes, the
>tracing of protocol violations, and automated recognition of user
>agents
>for the sake of tailoring responses to avoid particular user agent
>limitations. Although it is not required, user agents SHOULD include
>this field with requests. The field can contain multiple product tokens
>(section 7.8) and comments identifying the agent and any subproducts
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 115]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>which form a significant part of the user agent. By convention, the
>product tokens are listed in order of their significance for
>identifying
>the application.
>
> User-Agent = "User-Agent" ":" 1*( product | comment )
>
>Example:
>
> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
>
>
>18.46 Vary
>The Vary response-header field is used by an origin server to signal
>that the resource identified by the current request is a generic)
>resource. A generic resource has multiple entities associated with it,
>all of which are representations of the content of the resource. If a
>GET or HEAD request on a generic resource is received, the origin
>server
>will select one of the associated entities as the entity best matching
>the request. Selection of this entity is based on the contents of
>particular header fields in the request message, or on other
>information
>pertaining to the request, like the network address of the sending
>client.
>
>A resource being generic has an important effect on cache management,
>particularly for caching proxies which service a diverse set of user
>agents. All 200 (OK) responses from generic resources MUST contain at
>least one Vary header (section 18.46) or Alternates header (section
>18.8) to signal variance.
>
>If no Vary headers and no Alternates headers are present in a 200 (OK)
>response, then caches may assume, as long as the response is fresh,
>that
>the resource in question is plain, and has only one associated entity.
>Note however that this entity can still change through time, as
>possibly
>indicated by a Cache-Control response header (section 18.10).
>
>After selection of the entity best matching the current request, the
>origin server will usually generate a 200 (OK) response, but it can
>also
>generate other responses like 206 (Partial Content) or 304 (Not
>Modified) if headers which modify the semantics of the request, like
>Range (section 18.38) or If-Match (section 18.26), are present. An
>origin server need not be capable of selecting an entity for every
>possible incoming request on a generic resource; it can choose to
>generate a 3xx (redirection) or 4xx (client error) type response for
>some requests.
>
>In a request message on a generic resource, the selecting request
>headers are those request headers whose contents were used by the
>origin
>server to select the entity best matching the request. The Vary header
>field specifies the selecting request headers and any other selection
>parameters that were used by the origin server.
>
> Vary = "Vary" ":" 1#selection-parameter
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 116]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> selection-parameter = request-header-name
> | "{accept-headers}"
> | "{other}"
> | "{" extension-parameter "}"
>
> request-header-name = field-name
>
> extension-parameter = token
>
>The presence of a request-header-name signals that the request-header
>field with this name is selecting. Note that the name need not belong
>to a request-header field defined in this specification, and that
>header
>names are case-insensitive. The presence of the "{accept-headers}"
>parameter signals that all request headers whose names start with
>"accept" are selecting.
>
>The inclusion of the "{other}" parameter in a Vary field signals that
>parameters other than the contents of request headers, for example the
>network address of the sending party, play a role in the selection of
>the response.
>
> Note: This specification allows the origin server to express that
> other parameters were used, but does not allow the origin server to
> specify the exact nature of these parameters. This is left to
> future extensions.
>
>If an extension-parameter unknown to the cache is present in a Vary
>header, the cache MUST treat it as the "{other}" parameter. If multiple
>Vary and Alternates header fields are present in a response, these MUST
>be combined to give all selecting parameters.
>
>The field name "Host" MUST never be included in a Vary header; clients
>MUST ignore it if it is present. The names of fields which change the
>semantics of a GET request, like "Range" and "If-Match" MUST also never
>be included, and MUST be ignored when present.
>
>Servers which use access authentication are not obliged to send "Vary:
>Authorization" headers in responses. It MUST be assumed that requests
>on authenticated resources can always produce different responses for
>different users. Note that servers can signal the absence of
>authentication by including "Cache-Control: public" header in the
>response.
>
>A cache MAY store and refresh 200 (OK) responses from a generic
>resource
>according to the rules in section 16.4. The partial entities in 206
>(Partial Content) responses from generic resources MAY also be used by
>the cache.
>
>When getting a request on a generic resource, a cache can only return a
>cached 200 (OK) response to one of its clients in two particular cases.
>
>First, if a cache gets a request on a generic resource for which it has
>cached one or more responses with Vary or Alternates headers, it can
>relay that request towards the origin server, adding an If-NoneMatch
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 117]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>header listing the etag-info values in the ETag headers (section Error!
>Reference source not found.) of the cached responses which have
>variant-
>IDs. If it then gets back a 304 (Not Modified) response with the etag-
>info of a cached 200 (OK) response in its ETag header, it can return
>this cached 200 (OK) response to its client, after merging in any of
>the
>304 response headers as specified in section 16.4.2.
>
>Second, if a cache gets a request on a generic resource, it can return
>to its client a cached, fresh 200 (OK) response which has Vary or
>Alternates headers, provided that
>
>
> . the Vary and Alternates headers of this fresh response specify
>that
> only request header fields are selecting parameters,
>
> . the specified selecting request header fields of the current
> request match the specified selecting request header fields of a
> previous request on the resource relayed towards the origin
>server,
>
> . this previous request got a 200 (OK) or 304 (Not Modified)
>response
> which had the same etag-info value in its ETag header as the
> cached, fresh 200 (OK) response.
>Two sequences of selecting request header fields match if and only if
>the first sequence can be transformed into the second sequence by only
>adding or removing whitespace at places in fields where this is allowed
>according to the syntax rules in this specification.
>
>If a cached 200 (OK) response MAY be returned to a request on a generic
>resource which includes a Range request header, then a cache MAY also
>use this 200 (OK) response to construct and return a 206 (Partial
>Content) response with the requested range.
>
> Note: Implementation of support for the second case above is mainly
> interesting in user agent caches, as a user agent cache will
> generally have an easy way of determining whether the sequence of
> request header fields of the current request equals the sequence
> sent in an earlier request on the same resource. Proxy caches
> supporting the second case would have to record diverse sequences
> of request header fields previously relayed; the implementation
> effort associated with this may not be balanced by a sufficient
> payoff in traffic savings. A planned specification of a content
> negotiation mechanism will define additional cases in which proxy
> caches can return a cached 200 (OK) response without contacting the
> origin server. The implementation effort associated with support
> for these additional cases is expected to have a much better
> cost/benefit ratio.
>
>
>18.47 Via
>The Via general-header field MUST be used by gateways and proxies to
>indicate the intermediate protocols and recipients between the user
>agent and the server on requests, and between the origin server and the
>client on responses. It is analogous to the "Received" field of RFC 822
>and is intended to be used for tracking message forwards, avoiding
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 118]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>request loops, and identifying the protocol capabilities of all senders
>along the request/response chain.
>
> Via = "Via" ":" 1#( received-protocol received-by [ comment ]
>)
>
> received-protocol = [ protocol-name "/" ] protocol-version
> protocol-name = token
> protocol-version = token
> received-by = ( host [ ":" port ] ) | pseudonym
> pseudonym = token
>
>The received-protocol indicates the protocol version of the message
>received by the server or client along each segment of the
>request/response chain. The received-protocol version is appended to
>the Via field value when the message is forwarded so that information
>about the protocol capabilities of upstream applications remains
>visible
>to all recipients.
>
>The protocol-name is optional if and only if it would be "HTTP". The
>received-by field is normally the host and optional port number of a
>recipient server or client that subsequently forwarded the message.
>However, if the real host is considered to be sensitive information, it
>MAY be replaced by a pseudonym. If the port is not given, it MAY be
>assumed to be the default port of the received-protocol.
>
>Multiple Via field values represent each proxy or gateway that has
>forwarded the message. Each recipient MUST append its information such
>that the end result is ordered according to the sequence of forwarding
>applications.
>
>Comments MAY be used in the Via header field to identify the software
>of
>the recipient proxy or gateway, analogous to the User-Agent and Server
>header fields. However, all comments in the Via field are optional and
>MAY be removed by any recipient prior to forwarding the message.
>
>For example, a request message could be sent from an HTTP/1.0 user
>agent
>to an internal proxy code-named "fred", which uses HTTP/1.1 to forward
>the request to a public proxy at nowhere.com, which completes the
>request by forwarding it to the origin server at www.ics.uci.edu. The
>request received by www.ics.uci.edu would then have the following Via
>header field:
>
> Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
>
>Proxies and gateways used as a portal through a network firewall SHOULD
>NOT, by default, forward the names and ports of hosts within the
>firewall region. This information SHOULD only be propagated if
>explicitly enabled. If not enabled, the received-by host of any host
>behind the 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
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 119]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>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
>
>Applications SHOULD NOT combine multiple entries unless they are all
>under the same organizational control and the hosts have already been
>replaced by pseudonyms. Applications MUST NOT combine entries which
>have different received-protocol values.
>
> Note: The Via header field replaces the Forwarded header field
> which was present in earlier drafts of this specification.
>
>
>18.48 Warning
>Warning headers are sent with responses using:
>
> Warning = "Warning" ":" warn-code SP warn-agent SP warn-text
> warn-code = 2DIGIT
> warn-agent = ( host [ ":" port ] ) | pseudonym
> ; the name or pseudonym of the server adding
> ; the Warning header, for use in debugging
> warn-text = quoted-string
>
>A response may carry more than one Warning header.
>
>The warn-text should be in a natural language and character set that is
>most likely to be intelligible to the human user receiving the
>response.
>This decision may be based on any available knowledge, such as the
>location of the cache or user, the Accept-Language field in a request,
>the Content-Language field in a response, etc. The default language is
>English and the default character set is ISO-8599-1.
>
>If a character set other than ISO-8599-1 is used, it must be encoded in
>the warn-text using the method described in RFC 1522 [14].
>
>Any server or cache may add Warning headers to a response. New Warning
>headers should be added after any existing Warning headers. A cache
>MUST
>NOT delete any Warning header that it received with a response.
>However,
>if a cache successfully validates a cache entry, it SHOULD remove any
>Warning headers previously attached to that entry. It MUST then add any
>Warning headers received in the validating response. In other words,
>Warning headers are those that would be attached to the most recent
>relevant response.
>
>When multiple Warning headers are attached to a response, the user
>agent
>SHOULD display as many of them as possible, in the order that they
>appear in the response. If it is not possible to display all of the
>warnings, the user agent should follow these heuristics:
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 120]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . Warnings that appear early in the response take priority over
>those
> appearing later in the response.
> . Warnings in the user's preferred character set take priority over
> warnings in other character sets but with identical warn-codes and
> warn-agents.
>Systems that generate multiple Warning headers should order them with
>this user-agent behavior in mind.
>
>This is a list of the currently-defined warn-codes, each with a
>recommended warn-text in English, and a description of its meaning.
>
>
>10 Response is stale
> MUST be included whenever the returned response is stale. A cache may
> add this warning to any response, but may never remove it until the
> response is known to be fresh.
>
>11 Revalidation failed
> MUST be included if a cache returns a stale response because an
> attempt to revalidate the response failed, due to an inability to
> reach the server. A cache may add this warning to any response, but
> may never remove it until the response is successfully revalidated.
>
>12 Disconnected operation
> SHOULD be included if the cache is intentionally disconnected from
> the rest of the network for a period of time.
>
>99 Miscellaneous warning
> The warning text may include arbitrary information to be presented to
> a human user, or logged. A system receiving this warning MUST NOT
> take any automated action.
>
>
>
>18.49 WWW-Authenticate
>The WWW-Authenticate response-header field MUST be included in 401
>(Unauthorized) response messages. The field value consists of at least
>one challenge that indicates the authentication scheme(s) and
>parameters
>applicable to the Request-URI.
>
> WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
>
>The HTTP access authentication process is described in section 14. User
>agents MUST take special care in parsing the WWW-Authenticate field
>value if it contains more than one challenge, or if more than one WWW-
>Authenticate header field is provided, since the contents of a
>challenge
>may itself contain a comma-separated list of authentication parameters.
>
>
>19 Security Considerations
>This section is meant to inform application developers, information
>providers, and users of the security limitations in HTTP/1.1 as
>described by this document. The discussion does not include definitive
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 121]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>solutions to the problems revealed, though it does make some
>suggestions
>for reducing security risks.
>
>
>19.1 Authentication of Clients
>As mentioned in section 14, the Basic authentication scheme is not a
>secure method of user authentication, nor does it in any way protect
>the
>Entity-Body, which is transmitted in clear text across the physical
>network used as the carrier. HTTP does not prevent additional
>authentication schemes and encryption mechanisms from being employed to
>increase security or the addition of enhancements (such as schemes to
>use one-time passwords) to Basic authentication.
>
>The most serious flaw in Basic authentication is that it results in the
>essentially clear text transmission of the user's password over the
>physical network. It is this problem which Digest Authentication
>attempts to address.
>
>Because Basic authentication involves the clear text transmission of
>passwords it SHOULD never be used (without enhancements) to protect
>sensitive or valuable information.
>
>A common use of Basic authentication is for identification purposes --
>requiring the user to provide a user name and password as a means of
>identification, for example, for purposes of gathering accurate usage
>statistics on a server. When used in this way it is tempting to think
>that there is no danger in its use if illicit access to the protected
>documents is not a major concern. This is only correct if the server
>issues both user name and password to the users and in particular does
>not allow the user to choose his or her own password. The danger
>arises
>because naive users frequently reuse a single password to avoid the
>task
>of maintaining multiple passwords.
>
>If a server permits users to select their own passwords, then the
>threat
>is not only illicit access to documents on the server but also illicit
>access to the accounts of all users who have chosen to use their
>account
>password. If users are allowed to choose their own password that also
>means the server must maintain files containing the (presumably
>encrypted) passwords. Many of these may be the account passwords of
>users perhaps at distant sites. The owner or administrator of such a
>system could conceivably incur liability if this information is not
>maintained in a secure fashion.
>
>Basic Authentication is also vulnerable to spoofing by counterfeit
>servers. If a user can be led to believe that he is connecting to a
>host containing information protected by basic authentication when in
>fact he is connecting to a hostile server or gateway then the attacker
>can request a password, store it for later use, and feign an error.
>This type of attack is not possible with Digest Authentication[26].
>Server implementers SHOULD guard against the possibility of this sort
>of
>counterfeiting by gateways or CGI scripts. In particular it is very
>dangerous for a server to simply turn over a connection to a gateway
>since that gateway can then use the persistent connection mechanism to
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 122]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>engage in multiple transactions with the client while impersonating the
>original server in a way that is not detectable by the client.
>
>
>19.2 Safe Methods
>The writers of client software should be aware that the software
>represents the user in their interactions over the Internet, and should
>be careful to allow the user to be aware of any actions they may take
>which may have an unexpected significance to themselves or others.
>
>In particular, the convention has been established that the GET and
>HEAD
>methods should never have the significance of taking an action other
>than retrieval. These methods should be considered "safe. " This
>allows
>user agents to represent other methods, such as POST, PUT and DELETE,
>in
>a special way, so that the user is made aware of the fact that a
>possibly unsafe action is being requested.
>
>Naturally, it is not possible to ensure that the server does not
>generate side-effects as a result of performing a GET request; in fact,
>some dynamic resources consider that a feature. The important
>distinction here is that the user did not request the side-effects, so
>therefore cannot be held accountable for them.
>
>
>19.3 Abuse of Server Log Information
>A server is in the position to save personal data about a user's
>requests which may identify their reading patterns or subjects of
>interest. This information is clearly confidential in nature and its
>handling may be constrained by law in certain countries. People using
>the HTTP protocol to provide data are responsible for ensuring that
>such
>material is not distributed without the permission of any individuals
>that are identifiable by the published results.
>
>
>19.4 Transfer of Sensitive Information
>Like any generic data transfer protocol, HTTP cannot regulate the
>content of the data that is transferred, nor is there any a priori
>method of determining the sensitivity of any particular piece of
>information within the context of any given request. Therefore,
>applications SHOULD supply as much control over this information as
>possible to the provider of that information. Four header fields are
>worth special mention in this context: Server, Via, Referer and From.
>
>Revealing the specific software version of the server may allow the
>server machine to become more vulnerable to attacks against software
>that is known to contain security holes. Implementers SHOULD make the
>Server header field a configurable option.
>
>Proxies which serve as a portal through a network firewall SHOULD take
>special precautions regarding the transfer of header information that
>identifies the hosts behind the firewall. In particular, they SHOULD
>remove, or replace with sanitized versions, any Via fields generated
>behind the firewall.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 123]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The Referer field allows reading patterns to be studied and reverse
>links drawn. Although it can be very useful, its power can be abused if
>user details are not separated from the information contained in the
>Referer. Even when the personal information has been removed, the
>Referer field may indicate a private document's URI whose publication
>would be inappropriate.
>
>The information sent in the From field might conflict with the user's
>privacy interests or their site's security policy, and hence it SHOULD
>NOT be transmitted without the user being able to disable, enable, and
>modify the contents of the field. The user MUST be able to set the
>contents of this field within a user preference or application defaults
>configuration.
>
>We suggest, though do not require, that a convenient toggle interface
>be
>provided for the user to enable or disable the sending of From and
>Referer information.
>
>
>19.5 Attacks Based On File and Path Names
>Implementations of HTTP origin servers SHOULD be careful to restrict
>the
>documents returned by HTTP requests to be only those that were intended
>by the server administrators. If an HTTP server translates HTTP URIs
>directly into file system calls, the server MUST take special care not
>to serve files that were not intended to be delivered to HTTP clients.
>For example, UNIX, Microsoft Windows, and other operating systems use
>".." as a path component to indicate a directory level above the
>current
>one. On such a system, an HTTP server MUST disallow any such construct
>in the Request-URI if it would otherwise allow access to a resource
>outside those intended to be accessible via the HTTP server. Similarly,
>files intended for reference only internally to the server (such as
>access control files, configuration files, and script code) MUST be
>protected from inappropriate retrieval, since they might contain
>sensitive information. Experience has shown that minor bugs in such
>HTTP
>server implementations have turned into security risks.
>
>
>19.6 Personal Information
>HTTP clients are often privy to large amounts of personal information
>(e.g. the user's name, location, mail address, passwords, encryption
>keys, etc.), and SHOULD be very careful to prevent unintentional
>leakage
>of this information via the HTTP protocol to other sources. We very
>strongly recommend that a convenient interface be provided for the user
>to control dissemination of such information, and that designers and
>implementers be particularly careful in this area. History shows that
>errors in this area are often both serious security and/or privacy
>problems, and often generate very adverse publicity for the
>implementer's company.
>
>
>19.7 Privacy Issues Connected to Accept headers
>Accept request headers can reveal information about the user to all
>servers which are accessed. The Accept-Language header in particular
>can reveal information the user would consider to be of a private
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 124]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>nature, because the understanding of particular languages is often
>strongly correlated to the membership of a particular ethnic group.
>User agents which offer the option to configure the contents of an
>Accept-Language header to be sent in every request are strongly
>encouraged to let the configuration process include a message which
>makes the user aware of the loss of privacy involved.
>
>An approach that limits the loss of privacy would be for a user agent
>to
>omit the sending of Accept-Language headers by default, and to ask the
>user whether it should start sending Accept-Language headers to a
>server
>if it detects, by looking for any Vary or Alternates response headers
>generated by the server, that such sending could improve the quality of
>service.
>
>Elaborate user-customized accept header fields sent in every request,
>in
>particular if these include quality values, can be used by servers as
>relatively reliable and long-lived user identifiers. Such user
>identifiers would allow content providers to do click-trail tracking,
>and would allow collaborating content providers to match cross-server
>click-trails or form submissions of individual users. Note that for
>many users not behind a proxy, the network address of the host running
>the user agent will also serve as a long-lived user identifier. In
>environments where proxies are used to enhance privacy, user agents
>should be conservative in offering accept header configuration options
>to end users. As an extreme privacy measure, proxies could filter the
>accept headers in relayed requests. General purpose user agents which
>provide a high degree of header configurability should warn users about
>the loss of privacy which can be involved.
>
>
>19.8 DNS Spoofing
>Clients using HTTP rely heavily on the Domain Name Service, and are
>thus
>generally prone to security attacks based on the deliberate miss-
>association of IP addresses and DNS names. The deployment of DNSSEC
>should help this situation. In advance of this deployment, however,
>clients need to be cautious in assuming the continuing validity of an
>IP
>number/DNS name association.
>
>In particular, HTTP clients SHOULD rely on their name resolver for
>confirmation of an IP number/DNS name association, rather than caching
>the result of previous host name lookups. Many platforms already can
>cache host name lookups locally when appropriate, and they SHOULD be
>configured to do so. These lookups should be cached, however, only
>when
>the TTL (Time To Live) information reported by the name server makes it
>likely that the cached information will remain useful.
>
>If HTTP clients cache the results of host name lookups in order to
>achieve a performance improvement, they MUST observe the TTL
>information
>reported by DNS.
>
>If HTTP clients do not observe this rule, they could be spoofed when a
>previously-accessed server's IP address changes. As renumbering is
>expected to become increasingly common, the possibility of this form of
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 125]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>attack will grow. Observing this requirement thus reduces this
>potential security vulnerability.
>
>This requirement also improves the load-balancing behavior of clients
>for replicated servers using the same DNS name and reduces the
>likelihood of a user's experiencing failure in accessing sites which
>use
>that strategy.
>
>
>19.9 Location Headers and Spoofing
>If a single server supports multiple organizations that do not trust
>one
>another, then it must check the values of Location and Content-Location
>headers in responses that are generated under control of said
>organizations to make sure that they do not attempt to invalidate
>resources over which they have no authority.
>
>
>20 Acknowledgments
>This specification makes heavy use of the augmented BNF and generic
>constructs defined by David H. Crocker for RFC 822 . Similarly, it
>reuses many of the definitions provided by Nathaniel Borenstein and Ned
>Freed for MIME . We hope that their inclusion in this specification
>will
>help reduce past confusion over the relationship between HTTP and
>Internet mail message formats.
>
>The HTTP protocol has evolved considerably over the past four years. It
>has benefited from a large and active developer community--the many
>people who have participated on the www-talk mailing list--and it is
>that community which has been most responsible for the success of HTTP
>and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau,
>Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff,
>Phillip
>M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
>Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
>recognition for their efforts in defining early aspects of the
>protocol.
>
>This document has benefited greatly from the comments of all those
>participating in the HTTP-WG. In addition to those already mentioned,
>the following individuals have contributed to this specification:
>
> Gary Adams Harald Tveit Alvestrand
> Keith Ball Brian Behlendorf
> Paul Burchard Maurizio Codogno
> Mike Cowlishaw Roman Czyborra
> Michael A. Dolan Alan Freier
> Marc Hedlund Koen Holtman
> Alex Hopmann Bob Jernigan
> Shel Kaphan Rohit Khare
> Martijn Koster Alexei Kosut
> David M. Kristol Daniel LaLiberte
> Paul J. Leach Albert Lunde
> John C. Mallery Jean-Philippe Martin-Flatin
> Larry Masinter Mitra
> Gavin Nicol Scott Powers
> Bill Perry Jeffrey Perry
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 126]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> Owen Rees Luigi Rizzo
> David Robinson Marc Salomon
> Rich Salz Jim Seidman
> Chuck Shotton Eric W. Sink
> Simon E. Spero Richard N. Taylor
> Robert S. Thau Francois Yergeau
> Mary Ellen Zurko David Morris
> Greg Herlihy Bill (BearHeart) Weinman
> Allan M. Schiffman
>
>
>Much of the content and presentation of the caching design is due to
>suggestions and comments from individuals including: Shel Kaphan, Paul
>Leach, Koen Holtman, David Morris, Larry Masinter, and Roy Fielding.
>
>Most of the specification of ranges is based on work originally done by
>Ari Luotonen and John Franks, with additional input from Steve Zilles
>and Roy Fielding.
>
>XXX need acks for subgroup work.
>
>
>
>
>21 References
>
>[1] H. Alvestrand. "Tags for the identification of languages." RFC
>
> 1766, UNINETT, March 1995.
>
>[2] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey,
> B. Alberti. "The Internet Gopher Protocol: (a distributed document
>
> search and retrieval protocol)", RFC 1436, University of Minnesota,
> March 1993.
>
>[3] T. Berners-Lee. "Universal Resource Identifiers in WWW" A
>
> Unifying Syntax for the Expression of Names and Addresses of Objects
> on the Network as used in the World-Wide Web." RFC 1630, CERN, June
> 1994.
>
>[4] T. Berners-Lee, L. Masinter, M. McCahill.
> "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC,
>
> University of Minnesota, December 1994.
>
>[5] T. Berners-Lee, D. Connolly.
> "HyperText Markup Language Specification - 2.0." RFC 1866, MIT/LCS,
>
> November 1995.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 127]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>[6] T. Berners-Lee, R. Fielding, H. Frystyk.
> "Hypertext Transfer Protocol - HTTP/1.0." Work in Progress (draft-
>
> ietf-http-v10-spec-04.txt), MIT/LCS, UC Irvine, September 1995.
>
>[7] N. Borenstein, N. Freed.
> "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
>
> for Specifying and Describing the Format of Internet Message Bodies."
> RFC 1521, Bellcore, Innosoft, September 1993.
>
>[8] R. Braden.
> "Requirements for Internet hosts - application and support." STD 3,
>
> RFC 1123, IETF, October 1989.
>
>[9] D. H. Crocker.
> "Standard for the Format of ARPA Internet Text Messages." STD 11, RFC
>
> 822, UDEL, August 1982.
>
>[10] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J.
> Sui, M. Grinbaum. "WAIS Interface Protocol Prototype Functional
> Specification." (v1.5), Thinking Machines Corporation, April 1990.
>
>[11] R. Fielding. "Relative Uniform Resource Locators." RFC 1808, UC
>
> Irvine, June 1995.
>
>[12] M. Horton, R. Adams.
> "Standard for interchange of USENET messages." RFC 1036 (Obsoletes
>
> RFC 850), AT&T Bell Laboratories, Center for Seismic Studies,
> December 1987.
>
>[13] B. Kantor, P. Lapsley. "Network News Transfer Protocol A
>
> Proposed Standard for the Stream-Based Transmission of News." RFC
> 977, UC San Diego, UC Berkeley, February 1986.
>
>[14] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part
>Two
>
> : Message Header Extensions for Non-ASCII Text." RFC 1522, University
> of Tennessee, September 1993.
>
>[15] E. Nebel, L. Masinter. "Form-based File Upload in HTML." RFC
>
> 1867, Xerox Corporation, November 1995.
>
>[16] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821,
>
> USC/ISI, August 1982.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 128]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>[17] J. Postel. "Media Type Registration Procedure." RFC 1590,
>
> USC/ISI, March 1994.
>
>[18] J. Postel, J. K. Reynolds. "File Transfer Protocol (FTP)" STD
>9,
>
> RFC 959, USC/ISI, October 1985.
>
>[19] J. Reynolds, J. Postel. "Assigned Numbers." STD 2, RFC 1700,
>
> USC/ISI, October 1994.
>
>[20] K. Sollins, L. Masinter.
> "Functional Requirements for Uniform Resource Names." RFC 1737,
>
> MIT/LCS, Xerox Corporation, December 1994.
>
>[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code
>for
> Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
>
>[22] ISO-8859. International Standard -- Information Processing --
> 8-bit Single-Byte Coded Graphic Character Sets --
> Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
> Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
> Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
> Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
> Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
> Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
> Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
> Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
> Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
>
>[23] Meyers, M. Rose "The Content-MD5 Header Field." RFC 1864,
>
> Carnegie Mellon, Dover Beach Consulting, October, 1995.
>
>[24] B. Carpenter, Y. Rekhter, "Renumbering Needs Work". RFC 1900,
>
> IAB, February 1996.
>
>[25] Gzip is available from the GNU project at
> <URL:ftp://prep.ai.mit.edu/pub/gnu/>. A more formal specification is
>
> currently a work in progress.
>
>[26] Work In Progress for Digest authentication of the IETF HTTP
> working group.
>
>[27] TBS, Work in progress (XXX should put RFC in here_ )
>
>[28] Mills, D, "Network Time Protocol, Version 3", Specification,
>
> Implementation and Analysis RFC 1305, University of Delaware, March,
> 1992.
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 129]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>[29] Work in progress of the HTTP working group (XXX is this correct
> reference for incomplete work?).
>
>[30] S. Spero. "Analysis of HTTP Performance Problems"
> <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>
>
>[31] E. Rescorla, A. Schiffman "The Secure HyperText Transfer
> Protocol" Internet-Draft (work in progress).
>
>[32] A. Freier, P Karlton, P. Kocher. "SSL Version 3.0" Internet-
> Draft" (work in progress).
>
>[33] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP".
>In
> Proc.SIGCOMM '95 Symposium on Communications Architectures and
> Protocols, pages 299-313. Cambridge, MA, August, 1995.
>
>[34] Jeffrey C. Mogul. "The Case for Persistent-Connection HTTP".
> Research, Report 95/4, Digital Equipment Corporation Western Research
> Laboratory, May, 1995.,
> <URL
> :http://www.research.digital.com/wrl/techreports/abstracts/95.4.html>
>
>
>[35] Work in progress of the HTTP working group on state management.
>
>22 Authors' Addresses
>
>Roy T. Fielding
>
>Department of Information and Computer Science
>University of California
>Irvine, CA 92717-3425, USA
>Fax: +1 (714) 824-4056
>Email: fielding@ics.uci.edu
>
>Henrik Frystyk Nielsen
>
>W3 Consortium
>MIT Laboratory for Computer Science
>545 Technology Square
>Cambridge, MA 02139, USA
>Fax: +1 (617) 258 8682
>Email: frystyk@w3.org
>
>Tim Berners-Lee
>
>Director, W3 Consortium
>MIT Laboratory for Computer Science
>545 Technology Square
>Cambridge, MA 02139, USA
>Fax: +1 (617) 258 8682
>Email: timbl@w3.org
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 130]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>Jim Gettys
>
>MIT Laboratory for Computer Science
>545 Technology Square
>Cambridge, MA 02139, USA
>Fax: +1 (617) 258 8682
>Email: jg@w3.org
>
>Jeffrey C. Mogul
>
>Western Research Laboratory
>Digital Equipment Corporation
>250 University Avenue
>Palo Alto, California, 94305, U.S.A.
>Email: mogul@wrl.dec.com
>
>
>
>
>23 Appendices
>These appendices are provided for informational reasons only -- they do
>not form a part of the HTTP/1.1 specification.
>
>
>23.1 Internet Media Type message/http
>In addition to defining the HTTP/1.1 protocol, this document serves as
>the specification for the Internet media type "message/http". The
>following is to be registered with IANA .
>
> Media Type name: message
> Media subtype name: http
> Required parameters: none
> Optional parameters: version, msgtype
>
> version: The HTTP-Version number of the enclosed message
> (e.g., "1.1"). If not present, the version can
>be
> determined from the first line of the body.
>
> msgtype: The message type -- "request" or "response". If
>not
> present, the type can be determined from the
>first
> line of the body.
>
> Encoding considerations: only "7bit", "8bit", or "binary" are
> permitted
>
> Security considerations: none
>
>
>23.2 Tolerant Applications
>Although this document specifies the requirements for the generation of
>HTTP/1.1 messages, not all applications will be correct in their
>implementation. We therefore recommend that operational applications be
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 131]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>tolerant of deviations whenever those deviations can be interpreted
>unambiguously.
>
>Clients SHOULD be tolerant in parsing the Status-Line and servers
>tolerant when parsing the Request-Line. In particular, they SHOULD
>accept any amount of SP or HT characters between fields, even though
>only a single SP is required.
>
>The line terminator for HTTP-header fields is the sequence CRLF.
>However, we recommend that applications, when parsing such headers,
>recognize a single LF as a line terminator and ignore the leading CR.
>
>
>23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message
>Bodies
>HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822
>) and the Multipurpose Internet Mail Extensions (MIME ) to allow
>entities to be transmitted in an open variety of representations and
>with extensible mechanisms. However, RFC 1521 discusses mail, and HTTP
>has a few features that are different than those described in RFC 1521.
>These differences were carefully chosen to optimize performance over
>binary connections, to allow greater freedom in the use of new media
>types, to make date comparisons easier, and to acknowledge the practice
>of some early HTTP servers and clients.
>
>At the time of this writing, it is expected that RFC 1521 will be
>revised. The revisions may include some of the practices found in
>HTTP/1.1 but not in RFC 1521.
>
>This appendix describes specific areas where HTTP differs from RFC
>1521.
>Proxies and gateways to strict MIME environments SHOULD be aware of
>these differences and provide the appropriate conversions where
>necessary. Proxies and gateways from MIME environments to HTTP also
>need
>to be aware of the differences because some conversions may be
>required.
>
>
>23.3.1 Conversion to Canonical Form
>RFC 1521 requires that an Internet mail entity be converted to
>canonical
>form prior to being transferred, as described in Appendix G of RFC 1521
>. Section 7.7.1 of this document describes the forms allowed for
>subtypes of the "text" media type when transmitted over HTTP. RFC 1521
>requires that content with a typeof "text" represent line breaks as
>CRLF and forbids the use of CR or LF outside of line break sequences.
>HTTP allows CRLF, bare CR, and bare LF to indicate a line break within
>text content when a message is transmitted over HTTP.
>
>Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521
>environment SHOULD translate all line breaks within the text media
>types
>described in section 7.7.1 of this document to the RFC 1521 canonical
>form of CRLF. Note, however, that this may be complicated by the
>presence of a Content-Encoding and by the fact that HTTP allows the use
>of some character sets which do not use octets 13 and 10 to represent
>CR
>and LF, as is the case for some multi-byte character sets.
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 132]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>23.3.2 Conversion of Date Formats
>HTTP/1.1 uses a restricted set of date formats (section 7.3.1) to
>simplify the process of date comparison. Proxies and gateways from
>other
>protocols SHOULD ensure that any Date header field present in a message
>conforms to one of the HTTP/1.1 formats and rewrite the date if
>necessary.
>
>
>23.3.3 Introduction of Content-Encoding
>RFC 1521 does not include any concept equivalent to HTTP/1.1's Content-
>Encoding header field. Since this acts as a modifier on the media type,
>proxies and gateways from HTTP to MIME-compliant protocols MUST either
>change the value of the Content-Type header field or decode the Entity-
>Body before forwarding the message. (Some experimental applications of
>Content-Type for Internet mail have used a media-type parameter of
>";conversions=<content-coding>" to perform an equivalent function as
>Content-Encoding. However, this parameter is not part of RFC 1521.)
>
>
>23.3.4 No Content-Transfer-Encoding
>HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
>1521.
>Proxies and gateways from MIME-compliant protocols to HTTP MUST remove
>any non-identity CTE ("quoted-printable" or "base64") encoding prior to
>delivering the response message to an HTTP client.
>
>Proxies and gateways from HTTP to MIME-compliant protocols are
>responsible for ensuring that the message is in the correct format and
>encoding for safe transport on that protocol, where "safe transport" is
>defined by the limitations of the protocol being used. Such a proxy or
>gateway SHOULD label the data with an appropriate Content-Transfer-
>Encoding if doing so will improve the likelihood of safe transport over
>the destination protocol.
>
>
>23.3.5 HTTP Header Fields in Multipart Body-Parts
>In RFC 1521, most header fields in multipart body-parts are generally
>ignored unless the field name begins with "Content-". In HTTP/1.1,
>multipart body-parts may contain any HTTP header fields which are
>significant to the meaning of that part.
>
>
>23.3.6 Introduction of Transfer-Encoding
>HTTP/1.1 introduces the Transfer-Encoding header field (section 18.43).
>Proxies/gateways MUST remove any transfer coding prior to forwarding a
>message via a MIME-compliant protocol. The process for decoding the
>"chunked" transfer coding (section 7.6) can be represented in pseudo-
>code as:
>
> length := 0
> read chunk-size and CRLF
> while (chunk-size > 0) {
> read chunk-data and CRLF
> append chunk-data to Entity-Body
> length := length + chunk-size
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 133]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> read chunk-size and CRLF
> }
> read entity-header
> while (entity-header not empty) {
> append entity-header to existing header fields
> read entity-header
> }
> Content-Length := length
> Remove "chunked" from Transfer-Encoding
>
>
>
>
>23.3.7 MIME-Version
>HTTP is not a MIME-compliant protocol (see Appendix 23.3). However,
>HTTP/1.1 messages may include a single MIME-Version general-header
>field
>to indicate what version of the MIME protocol was used to construct the
>message. Use of the MIME-Version header field indicates that the
>message
>is in full compliance with the MIME protocol (as defined in ).
>Proxies/gateways are responsible for ensuring full compliance (where
>possible) when exporting HTTP messages 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,
>HTTP/1.1
>message parsing and semantics are defined by this document and not the
>MIME specification.
>
>
>23.4 Changes from HTTP/1.0
>This section will summarize major differences between versions HTTP/1.0
>and HTTP/1.1.
>
>
>23.4.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
>Addresses
>The requirements that clients and servers support the Host request-
>header, report an error if the Host request-header (section 18.24) is
>missing from an HTTP/1.1 request, and accept absolute URIs (Section
>9.1.2) are among the most important changes from HTTP/1.0.
>
>In HTTP/1.0 there is a one-to-one relationship of IP addresses and
>servers. There is no other way to distinguish the intended server of a
>request than the IP address to which that request is directed. The
>HTTP/1.1 change will allow the Internet, once HTTP/1.0 clients and
>servers are no longer common, to support multiple Web sites from a
>single IP address, greatly simplifying large operational Web servers,
>where allocation of many IP addresses to a single host has created
>serious problems. The Internet will also be able to recover the IP
>addresses that have been used for the sole purpose of allowing root-
>level domain names to be used in HTTP URLs. Given the rate of growth of
>the Web, and the number of servers already deployed, it is extremely
>important that implementations of HTTP/1.1 correctly implement these
>new
>requirements:
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 134]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> . both clients and servers MUST support the Host request-header
>
> . Host request-headers are required in HTTP/1.1 requests.
>
> . servers MUST report an error if an HTTP/1.1 request does not
> include a Host request-header
>
> . servers MUST accept absolute URIs
>
>23.5 Additional Features
>This appendix documents protocol elements used by some existing HTTP
>implementations, but not consistently and correctly across most
>HTTP/1.1
>applications. Implementers should be aware of these features, but
>cannot
>rely upon their presence in, or interoperability with, other HTTP/1.1
>applications. Some of these describe proposed experimental features,
>and some describe features that experimental deployment found lacking
>that are now addressed in the base HTTP/1.1 specification.
>
>
>23.5.1 Additional Request Methods
>
>23.5.1.1 PATCH
>The PATCH method is similar to PUT except that the entity contains a
>list of differences between the original version of the resource
>identified by the Request-URI and the desired content of the resource
>entity after the PATCH action has been applied. The list of
>differences
>is in a format defined by the media type of the entity (e.g.,
>"application/diff") and MUST include sufficient information to allow
>the
>server to recreate the changes necessary to convert the original
>version
>of the resource entity to the desired version.
>
>If the request passes through a cache and the Request-URI identifies a
>currently cached entity, that entity MUST be removed from the cache.
>Responses to this method are not cachable.
>
>For compatibility with HTTP/1.0 applications, all PATCH requests MUST
>include a valid Content-Length 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 a valid Content-Length or the "chunked"
>Transfer-Encoding. The server 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 actual method for determining how the patched resource is placed,
>and what happens to its predecessor, is defined entirely by the origin
>server. If the original version of the resource being patched included
>a
>Content-Version header field, the request entity MUST include a
>Derived-
>From header field corresponding to the value of the original Content-
>Version header field. Applications are encouraged to use these fields
>for constructing versioning relationships and resolving version
>conflicts.
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 135]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>PATCH requests must obey the entity transmission requirements set out
>in
>section 13.4.1.
>
>Caches that implement PATCH should invalidate cached responses as
>defined in section 16.10 for PUT.
>
>
>23.5.1.2 LINK
>The LINK method establishes one or more Link relationships between the
>existing resource identified by the Request-URI and other existing
>resources. The difference between LINK and other methods allowing links
>to be established between resources is that the LINK method does not
>allow any Entity-Body to be sent in the request and does not directly
>result in the creation of new resources.
>
>If the request passes through a cache and the Request-URI identifies a
>currently cached entity, that entity MUST be removed from the cache.
>Responses to this method are not cachable.
>
>Caches that implement LINK should invalidate cached responses as
>defined
>in section 16.10 for PUT.
>
>
>23.5.1.3 UNLINK
>The UNLINK method removes one or more Link relationships from the
>existing resource identified by the Request-URI. These relationships
>may
>have been established using the LINK method or by any other method
>supporting the Link header. The removal of a link to a resource does
>not
>imply that the resource ceases to exist or becomes inaccessible for
>future references.
>
>If the request passes through a cache and the Request-URI identifies a
>currently cached entity, that entity MUST be removed from the cache.
>Responses to this method are not cachable.
>
>Caches that implement UNLINK should invalidate cached responses as
>defined in section 16.10 for PUT.
>
>
>23.5.1.4 PUT
>To support the PATCH method, if the entity being PUT was derived from
>an
>existing resource which included a Content-Version header field, the
>new
>entity 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 information. Applications are encouraged
>to use these fields for constructing versioning relationships and
>resolving version conflicts.
>
>
>23.5.2 Additional Header Field Definitions
>
>23.5.2.1 Content-Version
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 136]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>The Content-Version entity-header field defines the version tag
>associated with a rendition of an evolving entity. Together with the
>Derived-From field described in section 23.5.2.2, it allows a group of
>people to work simultaneously on the creation of a work as an iterative
>process. The field SHOULD be used to allow evolution of a particular
>work along a single path. It SHOULD NOT be used to indicate derived
>works or renditions in different representations. It MAY also me used
>as
>an opaque value for comparing a cached entity's version with that of
>the
>current resource entity.
>
> Content-Version = "Content-Version" ":" quoted-string
>
>Examples of the Content-Version field include:
>
> Content-Version: "2.1.2"
> Content-Version: "Fred 19950116-12:26:48"
> Content-Version: "2.5a4-omega7"
>
>The value of the Content-Version field SHOULD be considered opaque to
>all parties but the origin server. A user agent MAY suggest a value for
>the version of an entity transferred via a PUT request; however, only
>the origin server can reliably assign that value.
>
>
>23.5.2.2 Derived-From
>The Derived-From entity-header field can be used to indicate the
>version
>tag of the resource from which the enclosed entity was derived before
>modifications were made by the sender. This field is used to help
>manage
>the process of merging successive changes to a resource, particularly
>when such changes are being made in parallel and from multiple sources.
>
> Derived-From = "Derived-From" ":" quoted-string
>
>An example use of the field is:
>
> Derived-From: "2.1.1"
>
>The Derived-From field 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 entity when it was last
>retrieved.
>
>
>23.5.2.3 Link
>The Link entity-header field provides a means for describing a
>relationship between two resources, generally between the requested
>resource and some other resource. An entity MAY include multiple Link
>values. Links at the metainformation level typically indicate
>relationships like hierarchical structure and navigation paths. The
>Link
>field is semantically equivalent to the <LINK> element in HTML .
>
> Link = "Link" ":" #("<" URI ">" *( ";" link-param )
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 137]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
> link-param = ( ( "rel" "=" relationship )
> | ( "rev" "=" relationship )
> | ( "title" "=" quoted-string )
> | ( "anchor" "=" <"> URI <"> )
> | ( link-extension ) )
>
> link-extension = token [ "=" ( token | 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 the sgml-name syntax. The title parameter MAY be used to
>label the destination of a link such that it can be used as
>identification within a human-readable menu. The anchor parameter MAY
>be
>used to indicate a source anchor other than the entire current
>resource,
>such as a fragment of this resource or a third resource.
>
>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 this resource
>in a logical navigation path. The second indicates that the person
>responsible for making the resource available is identified by the
>given
>e-mail address.
>
>
>23.5.2.4 URI
>The URI header field has, in past versions of this specification, been
>used as a combination of the existing Location, Content-Location, and
>Alternates header fields. Its primary purpose has been to include a
>list
>of additional URIs for the resource, including names and mirror
>locations. However, it has become clear that the combination of many
>different functions within this single field has been a barrier to
>consistently and correctly implementing any of those functions.
>Furthermore, we believe that the identification of names and mirror
>locations would be better performed via the Link header field. The URI
>header field is therefore deprecated in favor of those other fields.
>
> URI-header = "URI" ":" 1#( "<" URI ">" )
>
>
>23.5.2.5 Compatibility with HTTP/1.0 Persistent Connections
>Some clients and servers may wish to be compatible with some previous
>implementations of persistent connections in HTTP/1.0 clients and
>servers. These implementations are faulty, and the new facilities in
>HTTP/1.1 are designed to rectify these problems. The fear was that
>some existing 1.0 clients may be sending Keep-Alive to a proxy server
>that doesn't understand Connection, which would then erroneously
>forward
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 138]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>it to the next inbound server, which would establish the Keep-Alive
>connection and result in a dead 1.0 proxy waiting for the close on the
>response. The result is that 1.0 clients must be prevented from using
>Keep-Alive when talking to proxies.
>
>However, talking to proxies is the most important use of persistent
>connections, so that is clearly unacceptable. Therefore, we need some
>other mechanism for indicating a persistent connection is desired,
>which
>is safe to use even when talking to an old proxy that ignores
>Connection. As it turns out, there are two ways to accomplish that:
>
>1.
> Introduce a new keyword (persist) which is declared to be valid only
> when received from an HTTP/1.1 message.
>
>2.
> Declare persistence to be the default for HTTP/1.1 messages and
> introduce a new keyword (close) for declaring non-persistence.
>
>The following describes the original, buggy form of persistent
>connections.
>
>When connecting to an origin server an HTTP client MAY send the Keep-
>Alive connection-token in addition to the Persist connection-token:
>
> Connection: Keep-Alive,Persist
>
>An HTTP/1.0 server would then respond with the Keep-Alive connection
>token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
>persistent connection.
>
>An HTTP/1.1 server may also establish persistent connections with
>HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
>However, a persistent connection with an HTTP/1.0 client cannot make
>use
>of the chunked transfer-coding, and therefore MUST use a Content-Length
>for marking the ending boundary of each Entity-Body.
>
>A client MUST NOT send the Keep-Alive connection token to a proxy
>server
>as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing
>the Connection header field.
>
>
>23.5.2.5.1 The Keep-Alive Header
>When the Keep-Alive connection-token has been transmitted with a
>request
>or a response a Keep-Alive header field MAY also be included. The Keep-
>Alive header field takes the following form:
>
> Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
>
> keepalive-param = param-name "=" value
>
>The Keep-Alive header itself is optional, and is used only if a
>parameter is being sent. HTTP/1.1 does not define any parameters.
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 139]
>
>
>
>INTERNET-DRAFT HTTP/1.1 Friday, May 03, 1996
>
>
>If the Keep-Alive header is sent, the corresponding connection token
>MUST be transmitted. The Keep-Alive header MUST be ignored if received
>without the connection token.
>
>
>23.5.3 Compatibility with Previous Versions
>It is beyond the scope of a protocol specification to mandate
>compliance
>with previous versions. HTTP/1.1 was deliberately designed, however,
>to
>make supporting previous versions easy. While we are contemplating a
>separate document containing advice to implementers, we feel it worth
>noting that at the time of composing this specification, we would
>expect
>commercial HTTP/1.1 servers to:
>
>
> . recognize the format of the Request-Line for HTTP/0.9, 1.0, and
>1.1
> requests;
>
> . understand any valid request in the format of HTTP/0.9, 1.0, or
> 1.1;
>
> . respond appropriately with a message in the same major version
>used
> by the client.
>And we would expect HTTP/1.1 clients to:
>
>
> . recognize the format of the Status-Line for HTTP/1.0 and 1.1
> responses;
>
> . understand any valid response in the format of HTTP/0.9, 1.0, or
> 1.1.
>For most implementations of HTTP/1.0, each connection is established by
>the client prior to the request and closed by the server after sending
>the response. A few implementations implement the Keep-Alive version
>of
>persistent connections described in section 23.5.2.5.1.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Fielding, Frystyk, Berners-Lee, Gettys, and Mogul [Page 140]
>
>
Received on Friday, 3 May 1996 00:52:35 UTC