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.
`
`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.
`
`Fielding, Frystyk, Berners-Lee, Gettys and Mogul
`
`[Page 1]
`
`Google Inc.
`GOOG 1014
`CBM of U.S. Patent No. 6,286,045
`
`Page 1 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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]
`
`Page 2 of 110
`
`

`
`4 Table of Contents
`
`HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1
`
`1 Status of this Memo
`
`2 Abstract
`
`3 Note to Readers of This Document
`
`4 Table of Contents
`
`5 Introduction
`5.1 Purpose
`5.2 Requirements
`5.3 Terminology
`5.4 Overall Operation
`5.5 HTTP and MIME
`
`6 Notational Conventions and Generic Grammar
`6.1 Augmented BNF
`6.2 Basic Rules
`
`7 Protocol Parameters
`7.1 HTTP Version
`7.2 Uniform Resource Identifiers
`7.2.1 General Syntax
`7.2.2 http URL
`7.2.3 URI Canonicalization
`7.3 Date/Time Formats
`7.3.1 Full Date
`7.3.2 Delta Seconds
`7.4 Character Sets
`7.5 Content Codings
`7.6 Transfer Codings
`7.7 Media Types
`7.7.1 Canonicalization and Text Defaults
`7.7.2 Multipart Types
`7.8 Product Tokens
`7.9 Quality Values
`7.10 Language Tags
`7.11 Entity Tags
`7.12 Variant IDs
`7.13 Variant Sets
`7.14 Range Protocol Parameters
`7.14.1 Range Units
`7.14.2 Byte Ranges
`7.14.3 Content Ranges
`
`1
`
`1
`
`1
`
`1
`
`3
`
`9
`9
`9
`10
`12
`13
`
`13
`13
`15
`
`16
`16
`16
`17
`17
`18
`18
`18
`19
`20
`20
`21
`22
`22
`23
`23
`24
`24
`24
`25
`25
`25
`25
`25
`27
`
`Fielding, Frystyk, Berners-Lee, Gettys and Mogul
`
`[Page 3]
`
`Page 3 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`8 HTTP Message
`8.1 Message Types
`8.2 Message Headers
`8.3 General Header Fields
`
`9 Request
`9.1 Request-Line
`9.1.1 Method
`9.1.2 Request-URI
`9.2 The Resource Identified by a Request
`9.3 Request Header Fields
`
`10 Response
`10.1 Status-Line
`10.1.1 Status Code and Reason Phrase
`10.2 Response Header Fields
`
`11 Entity
`11.1 Entity Header Fields
`11.2 Entity Body
`11.2.1 Type
`11.2.2 Length
`
`12 Status Code Definitions
`12.1 Informational 1xx
`12.2 Successful 2xx
`12.3 Redirection 3xx
`12.4 Client Error 4xx
`12.5 Server Error 5xx
`
`13 Method Definitions
`13.1 OPTIONS
`13.2 GET
`13.3 HEAD
`13.4 POST
`13.4.1 SLUSHY: Entity Transmission Requirements
`13.5 PUT
`13.6 DELETE
`13.7 TRACE
`
`14 Access Authentication
`14.1 Basic Authentication Scheme
`14.2 Digest Authentication Scheme
`
`15 Content Negotiation
`15.1 Negotiation Facilities Defined in this Specification
`
`16 Caching in HTTP
`16.1 Semantic Transparency
`16.1.1 Cache Correctness
`16.1.2 Cache-control Mechanisms
`16.1.3 Warnings
`16.1.4 Explicit User Agent Warnings
`16.1.5 Exceptions to the Rules and Warnings
`
`27
`27
`27
`28
`
`28
`29
`29
`29
`30
`31
`
`31
`31
`31
`33
`
`34
`34
`34
`35
`35
`
`35
`36
`36
`37
`39
`41
`
`42
`42
`43
`43
`43
`44
`45
`46
`46
`
`47
`47
`48
`
`48
`49
`
`49
`49
`50
`50
`50
`51
`51
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 4]
`
`Page 4 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`16.1.6 Client-controlled Behavior
`16.2 Expiration Model
`16.2.1 Server-Specified Expiration
`16.2.2 Limitations on the Effect of Expiration Times
`16.2.3 Heuristic Expiration
`16.2.4 Age Calculations
`16.2.5 Expiration Calculations
`16.2.6 Scope of Expiration
`16.2.7 Disambiguating Expiration Values
`16.2.8 Disambiguating Multiple Responses
`16.3 Validation Model
`16.3.1 Last-modified Dates
`16.3.2 Entity Tags
`16.3.3 Weak and Strong Validators
`16.3.4 Rules for When to Use Entity Tags and Last-modified Dates
`16.3.5 Non-validating Conditionals
`16.4 Constructing Responses From Caches
`16.4.1 End-to-end and Hop-by-hop Headers
`16.4.2 Non-modifiable Headers
`16.4.3 Combining Headers
`16.4.4 Combining Byte Ranges
`16.5 Caching and Generic Resources
`16.5.1 Vary Header Use
`16.5.2 Alternates Header Use
`16.5.3 Variant-ID Use
`16.6 Shared and Non-Shared Caches
`16.7 Selecting a Cached Response
`16.7.1 Plain Resources
`16.7.2 Generic Resources
`16.8 Errors or Incomplete Response Cache Behavior
`16.8.1 Caching and Status Codes
`16.8.2 Handling of Retry-After
`16.9 Side Effects of GET and HEAD
`16.10 Invalidation After Updates or Deletions
`16.11 Write-Through Mandatory
`16.12 Generic Resources and HTTP/1.0 Proxy Caches
`16.13 Cache Replacement
`16.14 Caching of Negative Responses
`16.15 History Lists
`
`17 Persistent Connections
`17.1 Purpose
`17.2 Overall Operation
`17.2.1 Negotiation
`17.2.2 Pipe-lining
`17.2.3 Delimiting Entity-Bodies
`17.3 Proxy Servers
`17.4 Interaction with Security Protocols
`17.5 Practical Considerations
`
`18 Header Field Definitions
`18.1 Accept
`18.2 Accept-Charset
`18.3 Accept-Encoding
`
`51
`52
`52
`52
`52
`53
`54
`55
`55
`55
`55
`56
`56
`57
`58
`59
`59
`59
`60
`60
`61
`61
`61
`61
`61
`62
`62
`62
`63
`63
`63
`63
`64
`64
`64
`65
`65
`65
`65
`
`65
`65
`66
`66
`66
`67
`67
`67
`67
`
`68
`68
`69
`70
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 5]
`
`Page 5 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`18.4 Accept-Language
`18.5 Accept-Ranges
`18.6 Age
`18.7 Allow
`18.8 Alternates
`18.9 Authorization
`18.10 Cache-Control
`18.10.1 Cache-Control Restrictions on What is Cachable
`18.10.2 What May be Stored by Caches
`18.10.3 Modifications of the Basic Expiration Mechanism
`18.10.4 Cache Revalidation and Reload Controls
`18.10.5 Miscellaneous Restrictions
`18.11 Connection
`18.12 Content-Base
`18.13 Content-Encoding
`18.14 Content-Language
`18.15 Content-Length
`18.16 Content-Location
`18.17 Content-MD5
`18.18 Content-Range
`18.18.1 MIME multipart/byteranges Content-type
`18.18.2 Additional Rules for Content-Range
`18.19 Content-Type
`18.20 Date
`18.21 ETag
`18.22 Expires
`18.23 From
`18.24 Host
`18.25 If-Modified-Since
`18.26 If-Match
`18.27 If-NoneMatch
`18.28 If-Range
`18.29 If-Unmodified-Since
`18.30 Last-Modified
`18.31 Location
`18.32 Max-Forwards
`18.33 Persist
`18.34 Pragma
`18.35 Proxy-Authenticate
`18.36 Proxy-Authorization
`18.37 Public
`18.38 Range
`18.39 Referer
`18.40 Retry-After
`18.41 Server
`18.42 Title
`18.43 Transfer Encoding
`18.44 Upgrade
`18.45 User-Agent
`18.46 Vary
`18.47 Via
`18.48 Warning
`18.49 WWW-Authenticate
`
`70
`71
`71
`71
`72
`72
`73
`73
`74
`75
`75
`77
`77
`77
`78
`78
`78
`79
`79
`80
`80
`81
`81
`81
`82
`82
`83
`83
`84
`84
`85
`86
`86
`87
`87
`87
`88
`88
`88
`89
`89
`89
`90
`90
`90
`90
`91
`91
`92
`92
`94
`95
`96
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 6]
`
`Page 6 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`19 Security Considerations
`19.1 Authentication of Clients
`19.2 Safe Methods
`19.3 Abuse of Server Log Information
`19.4 Transfer of Sensitive Information
`19.5 Attacks Based On File and Path Names
`19.6 Personal Information
`19.7 Privacy Issues Connected to Accept headers
`19.8 DNS Spoofing
`19.9 Location Headers and Spoofing
`
`20 Acknowledgments
`
`21 References
`
`22 Authors' Addresses
`
`23 Appendices
`23.1 Internet Media Type message/http
`23.2 Tolerant Applications
`23.3 Differences Between HTTP Bodies and RFC 1521 Internet Message Bodies
`23.3.1 Conversion to Canonical Form
`23.3.2 Conversion of Date Formats
`23.3.3 Introduction of Content-Encoding
`23.3.4 No Content-Transfer-Encoding
`23.3.5 HTTP Header Fields in Multipart Body-Parts
`23.3.6 Introduction of Transfer-Encoding
`23.3.7 MIME-Version
`23.4 Changes from HTTP/1.0
`23.4.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
`23.5 Additional Features
`23.5.1 Additional Request Methods
`23.5.2 Additional Header Field Definitions
`23.5.3 Compatibility with Previous Versions
`
`96
`96
`97
`97
`97
`98
`98
`98
`99
`99
`
`99
`
`100
`
`102
`
`103
`103
`103
`104
`104
`104
`104
`104
`105
`105
`105
`105
`105
`106
`106
`107
`109
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 7]
`
`Page 7 of 110
`
`

`
`
`
`Page8of110
`
`[Page 8]
`[Page 8]
`
`Page 8 of 110
`
`

`
`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.
`
`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”.
`
`Fielding, Frystyk, Berners-Lee, Gettys and Mogul
`
`[Page 9]
`
`Page 9 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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.
`
`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
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 10]
`
`Page 10 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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.
`
`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.
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 11]
`
`Page 11 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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.
`
`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).
` 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
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 12]
`
`Page 12 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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 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
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 13]
`
`Page 13 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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 <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
`
`#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.
`
`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.
`
`Fielding, Frystyk, Berners-Lee, Gettys, and Mogul
`
`[Page 14]
`
`Page 14 of 110
`
`

`
`INTERNET-DRAFT
`
`Hypertext Transfer Protocol - HTTP/1.1
`
`Thursday, May 02, 1996
`
`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)>
` 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 sp