W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

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

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 3 May 1996 00:27:38 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960503072738Z-37900@tide21.microsoft.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:59 EDT