Network Working Group                                      R. Fielding
Request for Comments: 2068                                   UC Irvine
Category: Standards Track                                    J. Gettys
                                                              J. Mogul
                                                                   DEC
                                                            H. Frystyk
                                                        T. Berners-Lee
                                                               MIT/LCS
                                                          January 1997


                Hypertext Transfer Protocol -- HTTP/1.1

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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.
   A feature of HTTP is the typing and negotiation of data
   representation, allowing systems to be built independently of the
   data being transferred.

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

Table of Contents

   1 Introduction.............................................7
    1.1 Purpose ..............................................7
    1.2 Requirements .........................................7
    1.3 Terminology ..........................................8
    1.4 Overall Operation ...................................11
   2 Notational Conventions and Generic Grammar..............13
    2.1 Augmented BNF .......................................13
    2.2 Basic Rules .........................................15
   3 Protocol Parameters.....................................17
    3.1 HTTP Version ........................................17



Fielding, et. al.           Standards Track                     [Page 1]


RFC 2068                        HTTP/1.1                    January 1997


    3.2 Uniform Resource Identifiers ........................18
     3.2.1 General Syntax ...................................18
     3.2.2 http URL .........................................19
     3.2.3 URI Comparison ...................................20
    3.3 Date/Time Formats ...................................21
     3.3.1 Full Date ........................................21
     3.3.2 Delta Seconds ....................................22
    3.4 Character Sets ......................................22
    3.5 Content Codings .....................................23
    3.6 Transfer Codings ....................................24
    3.7 Media Types .........................................25
     3.7.1 Canonicalization and Text Defaults ...............26
     3.7.2 Multipart Types ..................................27
    3.8 Product Tokens ......................................28
    3.9 Quality Values ......................................28
    3.10 Language Tags ......................................28
    3.11 Entity Tags ........................................29
    3.12 Range Units ........................................30
   4 HTTP Message............................................30
    4.1 Message Types .......................................30
    4.2 Message Headers .....................................31
    4.3 Message Body ........................................32
    4.4 Message Length ......................................32
    4.5 General Header Fields ...............................34
   5 Request.................................................34
    5.1 Request-Line ........................................34
     5.1.1 Method ...........................................35
     5.1.2 Request-URI ......................................35
    5.2 The Resource Identified by a Request ................37
    5.3 Request Header Fields ...............................37
   6 Response................................................38
    6.1 Status-Line .........................................38
     6.1.1 Status Code and Reason Phrase ....................39
    6.2 Response Header Fields ..............................41
   7 Entity..................................................41
    7.1 Entity Header Fields ................................41
    7.2 Entity Body .........................................42
     7.2.1 Type .............................................42
     7.2.2 Length ...........................................43
   8 Connections.............................................43
    8.1 Persistent Connections ..............................43
     8.1.1 Purpose ..........................................43
     8.1.2 Overall Operation ................................44
     8.1.3 Proxy Servers ....................................45
     8.1.4 Practical Considerations .........................45
    8.2 Message Transmission Requirements ...................46
   9 Method Definitions......................................48
    9.1 Safe and Idempotent Methods .........................48



Fielding, et. al.           Standards Track                     [Page 2]


RFC 2068                        HTTP/1.1                    January 1997


     9.1.1 Safe Methods .....................................48
     9.1.2 Idempotent Methods ...............................49
    9.2 OPTIONS .............................................49
    9.3 GET .................................................50
    9.4 HEAD ................................................50
    9.5 POST ................................................51
    9.6 PUT .................................................52
    9.7 DELETE ..............................................53
    9.8 TRACE ...............................................53
   10 Status Code Definitions................................53
    10.1 Informational 1xx ..................................54
     10.1.1 100 Continue ....................................54
     10.1.2 101 Switching Protocols .........................54
    10.2 Successful 2xx .....................................54
     10.2.1 200 OK ..........................................54
     10.2.2 201 Created .....................................55
     10.2.3 202 Accepted ....................................55
     10.2.4 203 Non-Authoritative Information ...............55
     10.2.5 204 No Content ..................................55
     10.2.6 205 Reset Content ...............................56
     10.2.7 206 Partial Content .............................56
    10.3 Redirection 3xx ....................................56
     10.3.1 300 Multiple Choices ............................57
     10.3.2 301 Moved Permanently ...........................57
     10.3.3 302 Moved Temporarily ...........................58
     10.3.4 303 See Other ...................................58
     10.3.5 304 Not Modified ................................58
     10.3.6 305 Use Proxy ...................................59
    10.4 Client Error 4xx ...................................59
     10.4.1 400 Bad Request .................................60
     10.4.2 401 Unauthorized ................................60
     10.4.3 402 Payment Required ............................60
     10.4.4 403 Forbidden ...................................60
     10.4.5 404 Not Found ...................................60
     10.4.6 405 Method Not Allowed ..........................61
     10.4.7 406 Not Acceptable ..............................61
     10.4.8 407 Proxy Authentication Required ...............61
     10.4.9 408 Request Timeout .............................62
     10.4.10 409 Conflict ...................................62
     10.4.11 410 Gone .......................................62
     10.4.12 411 Length Required ............................63
     10.4.13 412 Precondition Failed ........................63
     10.4.14 413 Request Entity Too Large ...................63
     10.4.15 414 Request-URI Too Long .......................63
     10.4.16 415 Unsupported Media Type .....................63
    10.5 Server Error 5xx ...................................64
     10.5.1 500 Internal Server Error .......................64
     10.5.2 501 Not Implemented .............................64



Fielding, et. al.           Standards Track                     [Page 3]


RFC 2068                        HTTP/1.1                    January 1997


     10.5.3 502 Bad Gateway .................................64
     10.5.4 503 Service Unavailable .........................64
     10.5.5 504 Gateway Timeout .............................64
     10.5.6 505 HTTP Version Not Supported ..................65
   11 Access Authentication..................................65
    11.1 Basic Authentication Scheme ........................66
    11.2 Digest Authentication Scheme .......................67
   12 Content Negotiation....................................67
    12.1 Server-driven Negotiation ..........................68
    12.2 Agent-driven Negotiation ...........................69
    12.3 Transparent Negotiation ............................70
   13 Caching in HTTP........................................70
     13.1.1 Cache Correctness ...............................72
     13.1.2 Warnings ........................................73
     13.1.3 Cache-control Mechanisms ........................74
     13.1.4 Explicit User Agent Warnings ....................74
     13.1.5 Exceptions to the Rules and Warnings ............75
     13.1.6 Client-controlled Behavior ......................75
    13.2 Expiration Model ...................................75
     13.2.1 Server-Specified Expiration .....................75
     13.2.2 Heuristic Expiration ............................76
     13.2.3 Age Calculations ................................77
     13.2.4 Expiration Calculations .........................79
     13.2.5 Disambiguating Expiration Values ................80
     13.2.6 Disambiguating Multiple Responses ...............80
    13.3 Validation Model ...................................81
     13.3.1 Last-modified Dates .............................82
     13.3.2 Entity Tag Cache Validators .....................82
     13.3.3 Weak and Strong Validators ......................82
     13.3.4 Rules for When to Use Entity Tags and Last-
     modified Dates..........................................85
     13.3.5 Non-validating Conditionals .....................86
    13.4 Response Cachability ...............................86
    13.5 Constructing Responses From Caches .................87
     13.5.1 End-to-end and Hop-by-hop Headers ...............88
     13.5.2 Non-modifiable Headers ..........................88
     13.5.3 Combining Headers ...............................89
     13.5.4 Combining Byte Ranges ...........................90
    13.6 Caching Negotiated Responses .......................90
    13.7 Shared and Non-Shared Caches .......................91
    13.8 Errors or Incomplete Response Cache Behavior .......91
    13.9 Side Effects of GET and HEAD .......................92
    13.10 Invalidation After Updates or Deletions ...........92
    13.11 Write-Through Mandatory ...........................93
    13.12 Cache Replacement .................................93
    13.13 History Lists .....................................93
   14 Header Field Definitions...............................94
    14.1 Accept .............................................95



Fielding, et. al.           Standards Track                     [Page 4]


RFC 2068                        HTTP/1.1                    January 1997


    14.2 Accept-Charset .....................................97
    14.3 Accept-Encoding ....................................97
    14.4 Accept-Language ....................................98
    14.5 Accept-Ranges ......................................99
    14.6 Age ................................................99
    14.7 Allow .............................................100
    14.8 Authorization .....................................100
    14.9 Cache-Control .....................................101
     14.9.1 What is Cachable ...............................103
     14.9.2 What May be Stored by Caches ...................103
     14.9.3 Modifications of the Basic Expiration Mechanism 104
     14.9.4 Cache Revalidation and Reload Controls .........105
     14.9.5 No-Transform Directive .........................107
     14.9.6 Cache Control Extensions .......................108
    14.10 Connection .......................................109
    14.11 Content-Base .....................................109
    14.12 Content-Encoding .................................110
    14.13 Content-Language .................................110
    14.14 Content-Length ...................................111
    14.15 Content-Location .................................112
    14.16 Content-MD5 ......................................113
    14.17 Content-Range ....................................114
    14.18 Content-Type .....................................116
    14.19 Date .............................................116
    14.20 ETag .............................................117
    14.21 Expires ..........................................117
    14.22 From .............................................118
    14.23 Host .............................................119
    14.24 If-Modified-Since ................................119
    14.25 If-Match .........................................121
    14.26 If-None-Match ....................................122
    14.27 If-Range .........................................123
    14.28 If-Unmodified-Since ..............................124
    14.29 Last-Modified ....................................124
    14.30 Location .........................................125
    14.31 Max-Forwards .....................................125
    14.32 Pragma ...........................................126
    14.33 Proxy-Authenticate ...............................127
    14.34 Proxy-Authorization ..............................127
    14.35 Public ...........................................127
    14.36 Range ............................................128
     14.36.1 Byte Ranges ...................................128
     14.36.2 Range Retrieval Requests ......................130
    14.37 Referer ..........................................131
    14.38 Retry-After ......................................131
    14.39 Server ...........................................132
    14.40 Transfer-Encoding ................................132
    14.41 Upgrade ..........................................132



Fielding, et. al.           Standards Track                     [Page 5]


RFC 2068                        HTTP/1.1                    January 1997


    14.42 User-Agent .......................................134
    14.43 Vary .............................................134
    14.44 Via ..............................................135
    14.45 Warning ..........................................137
    14.46 WWW-Authenticate .................................139
   15 Security Considerations...............................139
    15.1 Authentication of Clients .........................139
    15.2 Offering a Choice of Authentication Schemes .......140
    15.3 Abuse of Server Log Information ...................141
    15.4 Transfer of Sensitive Information .................141
    15.5 Attacks Based On File and Path Names ..............142
    15.6 Personal Information ..............................143
    15.7 Privacy Issues Connected to Accept Headers ........143
    15.8 DNS Spoofing ......................................144
    15.9 Location Headers and Spoofing .....................144
   16 Acknowledgments.......................................144
   17 References............................................146
   18 Authors' Addresses....................................149
   19 Appendices............................................150
    19.1 Internet Media Type message/http ..................150
    19.2 Internet Media Type multipart/byteranges ..........150
    19.3 Tolerant Applications .............................151
    19.4 Differences Between HTTP Entities and
    MIME Entities...........................................152
     19.4.1 Conversion to Canonical Form ...................152
     19.4.2 Conversion of Date Formats .....................153
     19.4.3 Introduction of Content-Encoding ...............153
     19.4.4 No Content-Transfer-Encoding ...................153
     19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
     19.4.6 Introduction of Transfer-Encoding ..............154
     19.4.7 MIME-Version ...................................154
    19.5 Changes from HTTP/1.0 .............................154
     19.5.1 Changes to Simplify Multi-homed Web Servers and
     Conserve IP Addresses .................................155
    19.6 Additional Features ...............................156
     19.6.1 Additional Request Methods .....................156
     19.6.2 Additional Header Field Definitions ............156
    19.7 Compatibility with Previous Versions ..............160
     19.7.1 Compatibility with HTTP/1.0 Persistent
     Connections............................................161











Fielding, et. al.           Standards Track                     [Page 6]


RFC 2068                        HTTP/1.1                    January 1997


1 Introduction

1.1 Purpose

   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. HTTP has been in use by the World-Wide Web global
   information initiative since 1990. The first version of HTTP,
   referred to as HTTP/0.9, was a simple protocol for raw data transfer
   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
   the protocol by allowing messages to be in the format of MIME-like
   messages, containing metainformation about the data transferred and
   modifiers on the request/response semantics. However, HTTP/1.0 does
   not sufficiently take into consideration the effects 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 includes more stringent requirements than HTTP/1.0 in
   order to ensure reliable implementation of its features.

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

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

1.2 Requirements

   This specification uses the same words as RFC 1123 [8] for defining
   the significance of each particular requirement. These words are:

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



Fielding, et. al.           Standards Track                     [Page 7]


RFC 2068                        HTTP/1.1                    January 1997


   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.

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

1.3 Terminology

   This specification uses a number of terms to refer to the roles
   played by participants in, and objects of, the HTTP communication.

   connection
      A transport layer virtual circuit established between two programs
      for the purpose of communication.

   message
      The basic unit of HTTP communication, consisting of a structured
      sequence of octets matching the syntax defined in section 4 and
      transmitted via the connection.

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

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

   resource
      A network data object or service that can be identified by a URI,
      as defined in section 3.2. Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size,
      resolutions) or vary in other ways.






Fielding, et. al.           Standards Track                     [Page 8]


RFC 2068                        HTTP/1.1                    January 1997


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

   representation
      An entity included with a response that is subject to content
      negotiation, as described in section 12. There may exist multiple
      representations associated with a particular response status.

   content negotiation
      The mechanism for selecting the appropriate representation when
      servicing a request, as described in section 12. The
      representation of entities in any response can be negotiated
      (including error responses).

   variant
      A resource may have one, or more than one, representation(s)
      associated with it at any given instant. Each of these
      representations is termed a `variant.' Use of the term `variant'
      does not necessarily imply that the resource is subject to content
      negotiation.

   client
      A 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, et. al.           Standards Track                     [Page 9]


RFC 2068                        HTTP/1.1                    January 1997


   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 implement
      both the client and server requirements of this specification.

   gateway
      A server which acts as an intermediary for some other server.
      Unlike a proxy, a gateway receives requests as if it were the
      origin server for the requested resource; the requesting client
      may not be aware that it is communicating with a gateway.

   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.

   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 is acting as a tunnel.

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

   first-hand
      A response is first-hand if it comes directly and without
      unnecessary delay from the origin server, perhaps via one or more
      proxies. A response is also first-hand if its validity has just
      been checked directly with the origin server.

   explicit expiration time
      The time at which the origin server intends that an entity should
      no longer be returned by a cache without further validation.






Fielding, et. al.           Standards Track                    [Page 10]


RFC 2068                        HTTP/1.1                    January 1997


   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 sent by, or
      successfully validated with, the origin server.

   freshness lifetime
      The length of time between the generation of a response and its
      expiration time.

   fresh
      A response is fresh if its age has not yet exceeded its freshness
      lifetime.

   stale
      A response is stale if its age has passed its freshness lifetime.

   semantically transparent
      A cache behaves in a "semantically transparent" manner, with
      respect to a particular response, when its use affects neither the
      requesting client nor the origin server, except to improve
      performance. When a cache is semantically transparent, the client
      receives exactly the same response (except for hop-by-hop headers)
      that it would have received had its request been handled directly
      by the origin server.

   validator
      A protocol element (e.g., an entity tag or a Last-Modified time)
      that is used to find out whether a cache entry is an equivalent
      copy of an entity.

1.4 Overall Operation

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







Fielding, et. al.           Standards Track                    [Page 11]


RFC 2068                        HTTP/1.1                    January 1997


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

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

   A more complicated situation occurs when one or more intermediaries
   are present in the request/response chain. There are three common
   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
   forwarding agent, receiving requests for a URI in its absolute form,
   rewriting all or 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 will pass through four separate connections.
   This distinction is important because some HTTP communication options
   may apply only to the connection with the nearest, non-tunnel
   neighbor, only to the end-points of the chain, or to all connections
   along the chain.  Although the diagram is linear, each participant
   may be engaged in multiple, simultaneous communications. For example,
   B may be receiving requests from many clients other than A, and/or
   forwarding requests to servers other than C, at the same time that it
   is handling A's request.

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





Fielding, et. al.           Standards Track                    [Page 12]


RFC 2068                        HTTP/1.1                    January 1997


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

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

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

   HTTP communication usually takes place over TCP/IP connections. The
   default port is TCP 80, 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 units of the protocol in question is outside the scope
   of this specification.

   In HTTP/1.0, most implementations used a new connection for each
   request/response exchange. In HTTP/1.1, a connection may be used for
   one or more request/response exchanges, although connections may be
   closed for a variety of reasons (see section 8.1).

2 Notational Conventions and Generic Grammar

2.1 Augmented BNF

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) similar to that
   used by RFC 822 [9]. Implementers will need to be familiar with the
   notation in order to understand this specification. The augmented BNF
   includes the following constructs:





Fielding, et. al.           Standards Track                    [Page 13]


RFC 2068                        HTTP/1.1                    January 1997


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 ("|") 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
     <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



Fielding, et. al.           Standards Track                    [Page 14]


RFC 2068                        HTTP/1.1                    January 1997


     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.

2.2 Basic Rules

   The following rules are used throughout this specification to
   describe basic parsing constructs. The US-ASCII coded character set
   is defined by ANSI X3.4-1986 [21].

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










Fielding, et. al.           Standards Track                    [Page 15]


RFC 2068                        HTTP/1.1                    January 1997


   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

          CRLF           = CR LF

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

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

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

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

   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.

          token          = 1*<any CHAR except CTLs or tspecials>

          tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" 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 ")">





Fielding, et. al.           Standards Track                    [Page 16]


RFC 2068                        HTTP/1.1                    January 1997


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

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

          qdtext         = <any TEXT except <">>

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

          quoted-pair    = "\" CHAR

3 Protocol Parameters

3.1 HTTP Version

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

   The version of an HTTP message is indicated by an HTTP-Version field
   in the first line of the message.

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

   Note that the major and minor numbers MUST 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 MUST be ignored by recipients and
   MUST NOT be sent.

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

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



Fielding, et. al.           Standards Track                    [Page 17]


RFC 2068                        HTTP/1.1                    January 1997


   Proxy and gateway applications must be careful when forwarding
   messages in protocol versions different from that of the application.
   Since the protocol version indicates the protocol capability of the
   sender, a proxy/gateway MUST never send a message with a version
   indicator which is greater than its actual version; if a higher
   version request is received, the proxy/gateway MUST either downgrade
   the request version, respond with an error, or switch to tunnel
   behavior. Requests with a version lower than that of the
   proxy/gateway's version MAY be upgraded before being forwarded; the
   proxy/gateway's response to that request MUST be in the same major
   version as the request.

     Note: Converting between versions of HTTP may involve modification
     of header fields required or forbidden by the versions involved.

3.2 Uniform Resource Identifiers

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

3.2.1 General Syntax

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI, depending upon the context of their use. The two
   forms are differentiated by the fact that absolute URIs always begin
   with a scheme name followed by a colon.

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

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

          relativeURI    = net_path | abs_path | rel_path

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

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

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




Fielding, et. al.           Standards Track                    [Page 18]


RFC 2068                        HTTP/1.1                    January 1997


          scheme         = 1*( ALPHA | DIGIT | "+" | "-" | "." )
          net_loc        = *( pchar | ";" | "?" )

          query          = *( uchar | reserved )
          fragment       = *( uchar | reserved )

          pchar          = uchar | ":" | "@" | "&" | "=" | "+"
          uchar          = unreserved | escape
          unreserved     = ALPHA | DIGIT | safe | extra | national

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

   For definitive information on URL syntax and semantics, see RFC 1738
   [4] and RFC 1808 [11]. The BNF above includes national characters not
   allowed in valid URLs as specified by RFC 1738, since HTTP servers
   are not restricted in the set of unreserved characters allowed to
   represent the rel_path part of addresses, and HTTP proxies may
   receive requests for URIs not defined by RFC 1738.

   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 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

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

3.2.2 http URL

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










Fielding, et. al.           Standards Track                    [Page 19]


RFC 2068                        HTTP/1.1                    January 1997


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

          host           = <A legal Internet host domain name
                            or IP address (in dotted-decimal form),
                            as defined by Section 2.1 of RFC 1123>

          port           = *DIGIT

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path. The use of IP addresses in URL's SHOULD
   be avoided whenever possible (see RFC 1900 [24]). If the abs_path is
   not present in the URL, it MUST be given as "/" when used as a
   Request-URI for a resource (section 5.1.2).

3.2.3 URI Comparison

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

     o  A port that is empty or not given is equivalent to the default
        port for that URI;

     o  Comparisons of host names MUST be case-insensitive;

     o  Comparisons of scheme names MUST be case-insensitive;

     o  An empty abs_path is equivalent to an abs_path of "/".

   Characters other than those in the "reserved" and "unsafe" sets (see
   section 3.2) are equivalent to their ""%" HEX HEX" encodings.

   For example, the following three URIs are equivalent:

         http://abc.com:80/~smith/home.html
         http://ABC.com/%7Esmith/home.html
         http://ABC.com:/%7esmith/home.html












Fielding, et. al.           Standards Track                    [Page 20]


RFC 2068                        HTTP/1.1                    January 1997


3.3 Date/Time Formats

3.3.1 Full Date

   HTTP applications have historically allowed three different formats
   for the representation of date/time stamps:

          Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
          Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted 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).  The second format is in common use, but is based on the
   obsolete RFC 850 [12] date format and lacks a four-digit year.
   HTTP/1.1 clients and servers that parse the date value MUST accept
   all three formats (for compatibility with HTTP/1.0), though they MUST
   only generate the RFC 1123 format for representing HTTP-date values
   in header fields.

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

   All HTTP date/time stamps MUST be represented in 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 MUST be assumed when reading the asctime format.

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

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

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

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

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



Fielding, et. al.           Standards Track                    [Page 21]


RFC 2068                        HTTP/1.1                    January 1997


          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.

3.3.2 Delta Seconds

   Some HTTP header fields allow a time value to be specified as an
   integer number of seconds, represented in decimal, after the time
   that the message was received.

          delta-seconds  = 1*DIGIT

3.4 Character Sets

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

     The term "character set" is used in this document to refer to a
     method used with one or more tables to convert a sequence of octets
     into a sequence of characters. Note that unconditional conversion
     in the other direction is not required, in that not all characters
     may be available in a given character set and a character set may
     provide more than one sequence of octets to represent a particular
     character. This definition is intended to allow various kinds of
     character encodings, from simple single-table mappings such as US-
     ASCII to complex table switching methods such as those that use ISO
     2022's techniques. However, the definition associated with a MIME
     character set name MUST fully specify the mapping to be performed
     from octets to characters. In particular, use of external profiling
     information to determine the exact mapping is not permitted.

     Note: This use of the term "character set" is more commonly
     referred to as a "character encoding." However, since HTTP and MIME
     share the same registry, it is important that the terminology also
     be shared.








Fielding, et. al.           Standards Track                    [Page 22]


RFC 2068                        HTTP/1.1                    January 1997


   HTTP character sets are identified by case-insensitive tokens. The
   complete set of tokens is defined by the IANA Character Set registry
   [19].

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

3.5 Content Codings

   Content coding values indicate an encoding transformation that has
   been or can be applied to an entity. Content codings are primarily
   used to allow a document to be compressed or otherwise usefully
   transformed without losing the identity of its underlying media type
   and without loss of information. Frequently, the entity is stored in
   coded form, transmitted directly, and only decoded by the recipient.

          content-coding   = token

   All content-coding values are case-insensitive. HTTP/1.1 uses
   content-coding values in the Accept-Encoding (section 14.3) and
   Content-Encoding (section 14.12) header fields. Although the value
   describes the content-coding, what is more important is that it
   indicates what decoding mechanism will be required to remove the
   encoding.

   The Internet Assigned Numbers Authority (IANA) acts as a registry for
   content-coding value tokens. Initially, the registry contains the
   following tokens:

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

   compress
        The encoding format produced by the common UNIX file compression
        program "compress". This format is an adaptive Lempel-Ziv-Welch
        coding (LZW).









Fielding, et. al.           Standards Track                    [Page 23]


RFC 2068                        HTTP/1.1                    January 1997


     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. For compatibility with previous implementations of
     HTTP, applications should consider "x-gzip" and "x-compress" to be
     equivalent to "gzip" and "compress" respectively.

   deflate The "zlib" format defined in RFC 1950[31] in combination with
        the "deflate" compression mechanism described in RFC 1951[29].

   New content-coding value tokens should be registered; to allow
   interoperability between clients and servers, specifications of the
   content coding algorithms needed to implement a new value should be
   publicly available and adequate for independent implementation, and
   conform to the purpose of content coding defined in this section.

3.6 Transfer Codings

   Transfer coding values are used to indicate an encoding
   transformation that has been, can be, or may need to be applied to an
   entity-body in order to ensure "safe transport" through the network.
   This differs from a content coding in that the transfer coding is a
   property of the message, not of the original 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
   14.40).

   Transfer codings are analogous to the Content-Transfer-Encoding
   values of MIME , which were designed to enable safe transport of
   binary data over a 7-bit transport service. However, safe transport
   has a different focus for an 8bit-clean transfer protocol. In HTTP,
   the only unsafe characteristic of message-bodies is the difficulty in
   determining the exact body length (section 7.2.2), or the desire to
   encrypt data over a shared transport.

   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, et. al.           Standards Track                    [Page 24]


RFC 2068                        HTTP/1.1                    January 1997


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

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

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

       chunk-size     = hex-no-zero *HEX
       chunk-ext      = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
       chunk-ext-name = token
       chunk-ext-val  = token | quoted-string
       chunk-data     = chunk-size(OCTET)

       footer         = *entity-header

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

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

   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 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 an HTTP/1.0 client.

3.7 Media Types

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

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

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



Fielding, et. al.           Standards Track                    [Page 25]


RFC 2068                        HTTP/1.1                    January 1997


          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. Linear white space
   (LWS) MUST NOT be used between the type and subtype, nor between an
   attribute and its value. User agents that recognize the media-type
   MUST process (or arrange to be processed by any external applications
   used to process that type/subtype by the user agent) the parameters
   for that MIME type as described by that type/subtype definition to
   the and inform the user of any problems discovered.

     Note: some older HTTP applications do not recognize media type
     parameters. When sending data to older HTTP applications,
     implementations should only use media type parameters when they are
     required by that type/subtype definition.

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

3.7.1 Canonicalization and Text Defaults

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

   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when 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 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.



Fielding, et. al.           Standards Track                    [Page 26]


RFC 2068                        HTTP/1.1                    January 1997


   The "charset" parameter is used with some media types to define the
   character set (section 3.4) of the data. When no explicit charset
   parameter is provided by the sender, media subtypes of the "text"
   type are defined to have a default charset value of "ISO-8859-1" when
   received via HTTP. Data in character sets other than "ISO-8859-1" or
   its subsets MUST be labeled with an appropriate charset value.

   Some HTTP/1.0 software has interpreted a Content-Type header without
   charset parameter incorrectly to mean "recipient should guess."
   Senders wishing to defeat this behavior MAY include a charset
   parameter even when the charset is ISO-8859-1 and SHOULD do so when
   it is known that it will not confuse the recipient.

   Unfortunately, some older HTTP/1.0 clients did not deal properly with
   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
   charset label provided by the sender; and those user agents that have
   a provision to "guess" a charset MUST use the charset from the
   content-type field if they support that charset, rather than the
   recipient's preference, when initially displaying a document.

3.7.2 Multipart Types

   MIME provides for a number of "multipart" types -- encapsulations of
   one or more entities within a single message-body. All multipart
   types share a common syntax, as defined in  MIME [7], and MUST
   include a boundary parameter as part of the media type value. The
   message body is itself a protocol element and MUST therefore use only
   CRLF to represent line breaks between body-parts. Unlike in MIME, the
   epilogue of any multipart message MUST be empty; HTTP applications
   MUST NOT transmit the epilogue (even if the original multipart
   contains an epilogue).

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

   In general, an HTTP user agent SHOULD follow the same or similar
   behavior as a MIME user agent would upon receipt of a multipart type.
   If an application receives an unrecognized multipart subtype, the
   application MUST treat it as being equivalent to "multipart/mixed".

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






Fielding, et. al.           Standards Track                    [Page 27]


RFC 2068                        HTTP/1.1                    January 1997


3.8 Product Tokens

   Product tokens are used to allow communicating applications to
   identify themselves by software name and version. 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).

3.9 Quality Values

   HTTP content negotiation (section 12) uses short "floating point"
   numbers to indicate the relative importance ("weight") of various
   negotiable parameters. A weight is normalized to a real number in the
   range 0 through 1, where 0 is the minimum and 1 the maximum value.
   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") ] )

   "Quality values" is a misnomer, since these values merely represent
   relative degradation in desired quality.

3.10 Language Tags

   A language tag identifies a natural language spoken, written, or
   otherwise conveyed by human beings for communication of information
   to other human beings. Computer languages are explicitly excluded.
   HTTP uses language tags within the Accept-Language and Content-
   Language fields.




Fielding, et. al.           Standards Track                    [Page 28]


RFC 2068                        HTTP/1.1                    January 1997


   The syntax and registry of HTTP language tags is the same as that
   defined by RFC 1766 [1]. In summary, a language tag is composed of 1
   or more parts: A primary language tag and a possibly empty series of
   subtags:

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

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

   Whitespace is not allowed within the tag and all tags are case-
   insensitive. The name space of language tags is administered by the
   IANA. Example tags include:

          en, en-US, en-cockney, i-cherokee, x-pig-latin

   where any two-letter primary-tag is an ISO 639 language abbreviation
   and any two-letter initial subtag is an ISO 3166 country code. (The
   last three tags above are not registered tags; all but the last are
   examples of tags which could be registered in future.)

3.11 Entity Tags

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

         entity-tag = [ weak ] opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

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

   A "weak entity tag," indicated by the "W/" prefix, may be shared by
   two entities of a resource only if the entities are equivalent and
   could be substituted for each other with no significant change in
   semantics. A weak entity tag can only be used for weak comparison.

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



Fielding, et. al.           Standards Track                    [Page 29]


RFC 2068                        HTTP/1.1                    January 1997


3.12 Range Units

   HTTP/1.1 allows a client to request that only part (a range of) the
   response entity be included within the response. HTTP/1.1 uses range
   units in the Range (section 14.36) and Content-Range (section 14.17)
   header fields. An entity may be broken down into subranges according
   to various structural units.

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
   implementations may ignore ranges specified using other units.
   HTTP/1.1 has been designed to allow implementations of applications
   that do not depend on knowledge of ranges.

4 HTTP Message

4.1 Message Types

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

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

   Request (section 5) and Response (section 6) messages use the generic
   message format of RFC 822 [9] for transferring entities (the payload
   of the message). Both types of message consist of a start-line, one
   or more header fields (also known as "headers"), an empty line (i.e.,
   a line with nothing preceding the CRLF) indicating the end of the
   header fields, and an optional message-body.

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

           start-line      = Request-Line | Status-Line

   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected. In other words, if
   the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.






Fielding, et. al.           Standards Track                    [Page 30]


RFC 2068                        HTTP/1.1                    January 1997


     Note: certain buggy HTTP/1.0 client implementations generate an
     extra CRLF's after a POST request. To restate what is explicitly
     forbidden by the BNF, an HTTP/1.1 client must not preface or follow
     a request with an extra CRLF.

4.2 Message Headers

   HTTP header fields, which include general-header (section 4.5),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section 7.1) fields, follow the same generic format as