--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ that given in Section 3.1 of RFC 822 [9]. Each header field consists
+ of a name followed by a colon (":") and the field value. Field names
+ are case-insensitive. The field value may be preceded by any amount
+ of LWS, though a single SP is preferred. Header fields can be
+ extended over multiple lines by preceding each extra line with at
+ least one SP or HT. Applications SHOULD follow "common form" when
+ generating HTTP constructs, since there might exist some
+ implementations that fail to accept anything beyond the common forms.
+
+ message-header = field-name ":" [ field-value ] CRLF
+
+ field-name = token
+ field-value = *( field-content | LWS )
+
+ field-content = <the OCTETs making up the field-value
+ and consisting of either *TEXT or combinations
+ of token, tspecials, and quoted-string>
+
+ The order in which header fields with differing field names are
+ received is not significant. However, it is "good practice" to send
+ general-header fields first, followed by request-header or response-
+ header fields, and ending with the entity-header fields.
+
+ Multiple message-header fields with the same field-name may be
+ present in a message if and only if the entire field-value for that
+ header field is defined as a comma-separated list [i.e., #(values)].
+ It MUST be possible to combine the multiple header fields into one
+ "field-name: field-value" pair, without changing the semantics of the
+ message, by appending each subsequent field-value to the first, each
+ separated by a comma. The order in which header fields with the same
+ field-name are received is therefore significant to the
+ interpretation of the combined field value, and thus a proxy MUST NOT
+ change the order of these field values when a message is forwarded.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 31]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+4.3 Message Body
+
+ The message-body (if any) of an HTTP message is used to carry the
+ entity-body associated with the request or response. The message-body
+ differs from the entity-body only when a transfer coding has been
+ applied, as indicated by the Transfer-Encoding header field (section
+ 14.40).
+
+ message-body = entity-body
+ | <entity-body encoded as per Transfer-Encoding>
+
+ Transfer-Encoding MUST be used to indicate any transfer codings
+ applied by an application to ensure safe and proper transfer of the
+ message. Transfer-Encoding is a property of the message, not of the
+ entity, and thus can be added or removed by any application along the
+ request/response chain.
+
+ The rules for when a message-body is allowed in a message differ for
+ requests and responses.
+
+ The presence of a message-body in a request is signaled by the
+ inclusion of a Content-Length or Transfer-Encoding header field in
+ the request's message-headers. A message-body MAY be included in a
+ request only when the request method (section 5.1.1) allows an
+ entity-body.
+
+ For response messages, whether or not a message-body is included with
+ a message is dependent on both the request method and the response
+ status code (section 6.1.1). All responses to the HEAD request method
+ MUST NOT include a message-body, even though the presence of entity-
+ header fields might lead one to believe they do. All 1xx
+ (informational), 204 (no content), and 304 (not modified) responses
+ MUST NOT include a message-body. All other responses do include a
+ message-body, although it may be of zero length.
+
+4.4 Message Length
+
+ When a message-body is included with a message, the length of that
+ body is determined by one of the following (in order of precedence):
+
+ 1. Any response message which MUST NOT include a message-body
+ (such as the 1xx, 204, and 304 responses and any response to a HEAD
+ request) is always terminated by the first empty line after the
+ header fields, regardless of the entity-header fields present in the
+ message.
+
+ 2. If a Transfer-Encoding header field (section 14.40) is present and
+ indicates that the "chunked" transfer coding has been applied, then
+
+
+
+Fielding, et. al. Standards Track [Page 32]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ the length is defined by the chunked encoding (section 3.6).
+
+ 3. If a Content-Length header field (section 14.14) is present, its
+ value in bytes represents the length of the message-body.
+
+ 4. If the message uses the media type "multipart/byteranges", which is
+ self-delimiting, then that defines the length. This media type MUST
+ NOT be used unless the sender knows that the recipient can parse it;
+ the presence in a request of a Range header with multiple byte-range
+ specifiers implies that the client can parse multipart/byteranges
+ responses.
+
+ 5. By the server closing the connection. (Closing the connection
+ cannot be used to indicate the end of a request body, since that
+ would leave no possibility for the server to send back a response.)
+
+ For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+ containing a message-body MUST include a valid Content-Length header
+ field unless the server is known to be HTTP/1.1 compliant. If a
+ request contains a message-body and a Content-Length is not given,
+ the server SHOULD respond with 400 (bad request) if it cannot
+ determine the length of the message, or with 411 (length required) if
+ it wishes to insist on receiving a valid Content-Length.
+
+ All HTTP/1.1 applications that receive entities MUST accept the
+ "chunked" transfer coding (section 3.6), thus allowing this mechanism
+ to be used for messages when the message length cannot be determined
+ in advance.
+
+ Messages MUST NOT include both a Content-Length header field and the
+ "chunked" transfer coding. If both are received, the Content-Length
+ MUST be ignored.
+
+ When a Content-Length is given in a message where a message-body is
+ allowed, its field value MUST exactly match the number of OCTETs in
+ the message-body. HTTP/1.1 user agents MUST notify the user when an
+ invalid length is received and detected.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 33]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+4.5 General Header Fields
+
+ There are a few header fields which have general applicability for
+ both request and response messages, but which do not apply to the
+ entity being transferred. These header fields apply only to the
+ message being transmitted.
+
+ general-header = Cache-Control ; Section 14.9
+ | Connection ; Section 14.10
+ | Date ; Section 14.19
+ | Pragma ; Section 14.32
+ | Transfer-Encoding ; Section 14.40
+ | Upgrade ; Section 14.41
+ | Via ; Section 14.44
+
+ General-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields may be given the semantics of general
+ header fields if all parties in the communication recognize them to
+ be general-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+5 Request
+
+ A request message from a client to a server includes, within the
+ first line of that message, the method to be applied to the resource,
+ the identifier of the resource, and the protocol version in use.
+
+ Request = Request-Line ; Section 5.1
+ *( general-header ; Section 4.5
+ | request-header ; Section 5.3
+ | entity-header ) ; Section 7.1
+ CRLF
+ [ message-body ] ; Section 7.2
+
+5.1 Request-Line
+
+ The Request-Line begins with a method token, followed by the
+ Request-URI and the protocol version, and ending with CRLF. The
+ elements are separated by SP characters. No CR or LF are allowed
+ except in the final CRLF sequence.
+
+ Request-Line = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 34]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+5.1.1 Method
+
+ The Method token indicates the method to be performed on the resource
+ identified by the Request-URI. The method is case-sensitive.
+
+ Method = "OPTIONS" ; Section 9.2
+ | "GET" ; Section 9.3
+ | "HEAD" ; Section 9.4
+ | "POST" ; Section 9.5
+ | "PUT" ; Section 9.6
+ | "DELETE" ; Section 9.7
+ | "TRACE" ; Section 9.8
+ | extension-method
+
+ extension-method = token
+
+ The list of methods allowed by a resource can be specified in an
+ Allow header field (section 14.7). The return code of the response
+ always notifies the client whether a method is currently allowed on a
+ resource, since the set of allowed methods can change dynamically.
+ Servers SHOULD return the status code 405 (Method Not Allowed) if the
+ method is known by the server but not allowed for the requested
+ resource, and 501 (Not Implemented) if the method is unrecognized or
+ not implemented by the server. The list of methods known by a server
+ can be listed in a Public response-header field (section 14.35).
+
+ The methods GET and HEAD MUST be supported by all general-purpose
+ servers. All other methods are optional; however, if the above
+ methods are implemented, they MUST be implemented with the same
+ semantics as those specified in section 9.
+
+5.1.2 Request-URI
+
+ The Request-URI is a Uniform Resource Identifier (section 3.2) and
+ identifies the resource upon which to apply the request.
+
+ Request-URI = "*" | absoluteURI | abs_path
+
+ The three options for Request-URI are dependent on the nature of the
+ request. The asterisk "*" means that the request does not apply to a
+ particular resource, but to the server itself, and is only allowed
+ when the method used does not necessarily apply to a resource. One
+ example would be
+
+ OPTIONS * HTTP/1.1
+
+ The absoluteURI form is required when the request is being made to a
+ proxy. The proxy is requested to forward the request or service it
+
+
+
+Fielding, et. al. Standards Track [Page 35]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ from a valid cache, and return the response. Note that the proxy MAY
+ forward the request on to another proxy or directly to the server
+ specified by the absoluteURI. In order to avoid request loops, a
+ proxy MUST be able to recognize all of its server names, including
+ any aliases, local variations, and the numeric IP address. An example
+ Request-Line would be:
+
+ GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+ To allow for transition to absoluteURIs in all requests in future
+ versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
+ form in requests, even though HTTP/1.1 clients will only generate
+ them in requests to proxies.
+
+ The most common form of Request-URI is that used to identify a
+ resource on an origin server or gateway. In this case the absolute
+ path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+ the Request-URI, and the network location of the URI (net_loc) MUST
+ be transmitted in a Host header field. For example, a client wishing
+ to retrieve the resource above directly from the origin server would
+ create a TCP connection to port 80 of the host "www.w3.org" and send
+ the lines:
+
+ GET /pub/WWW/TheProject.html HTTP/1.1
+ Host: www.w3.org
+
+ followed by the remainder of the Request. Note that the absolute path
+ cannot be empty; if none is present in the original URI, it MUST be
+ given as "/" (the server root).
+
+ If a proxy receives a request without any path in the Request-URI and
+ the method specified is capable of supporting the asterisk form of
+ request, then the last proxy on the request chain MUST forward the
+ request with "*" as the final Request-URI. For example, the request
+
+ OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
+
+ would be forwarded by the proxy as
+
+ OPTIONS * HTTP/1.1
+ Host: www.ics.uci.edu:8001
+
+ after connecting to port 8001 of host "www.ics.uci.edu".
+
+ The Request-URI is transmitted in the format specified in section
+ 3.2.1. The origin server MUST decode the Request-URI in order to
+ properly interpret the request. Servers SHOULD respond to invalid
+ Request-URIs with an appropriate status code.
+
+
+
+Fielding, et. al. Standards Track [Page 36]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ In requests that they forward, proxies MUST NOT rewrite the
+ "abs_path" part of a Request-URI in any way except as noted above to
+ replace a null abs_path with "*", no matter what the proxy does in
+ its internal implementation.
+
+ Note: The "no rewrite" rule prevents the proxy from changing the
+ meaning of the request when the origin server is improperly using a
+ non-reserved URL character for a reserved purpose. Implementers
+ should be aware that some pre-HTTP/1.1 proxies have been known to
+ rewrite the Request-URI.
+
+5.2 The Resource Identified by a Request
+
+ HTTP/1.1 origin servers SHOULD be aware that the exact resource
+ identified by an Internet request is determined by examining both the
+ Request-URI and the Host header field.
+
+ An origin server that does not allow resources to differ by the
+ requested host MAY ignore the Host header field value. (But see
+ section 19.5.1 for other requirements on Host support in HTTP/1.1.)
+
+ An origin server that does differentiate resources based on the host
+ requested (sometimes referred to as virtual hosts or vanity
+ hostnames) MUST use the following rules for determining the requested
+ resource on an HTTP/1.1 request:
+
+ 1. If Request-URI is an absoluteURI, the host is part of the
+ Request-URI. Any Host header field value in the request MUST be
+ ignored.
+
+ 2. If the Request-URI is not an absoluteURI, and the request
+ includes a Host header field, the host is determined by the Host
+ header field value.
+
+ 3. If the host as determined by rule 1 or 2 is not a valid host on
+ the server, the response MUST be a 400 (Bad Request) error
+ message.
+
+ Recipients of an HTTP/1.0 request that lacks a Host header field MAY
+ attempt to use heuristics (e.g., examination of the URI path for
+ something unique to a particular host) in order to determine what
+ exact resource is being requested.
+
+5.3 Request Header Fields
+
+ The request-header fields allow the client to pass additional
+ information about the request, and about the client itself, to the
+ server. These fields act as request modifiers, with semantics
+
+
+
+Fielding, et. al. Standards Track [Page 37]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ equivalent to the parameters on a programming language method
+ invocation.
+
+ request-header = Accept ; Section 14.1
+ | Accept-Charset ; Section 14.2
+ | Accept-Encoding ; Section 14.3
+ | Accept-Language ; Section 14.4
+ | Authorization ; Section 14.8
+ | From ; Section 14.22
+ | Host ; Section 14.23
+ | If-Modified-Since ; Section 14.24
+ | If-Match ; Section 14.25
+ | If-None-Match ; Section 14.26
+ | If-Range ; Section 14.27
+ | If-Unmodified-Since ; Section 14.28
+ | Max-Forwards ; Section 14.31
+ | Proxy-Authorization ; Section 14.34
+ | Range ; Section 14.36
+ | Referer ; Section 14.37
+ | User-Agent ; Section 14.42
+
+ Request-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields MAY be given the semantics of request-
+ header fields if all parties in the communication recognize them to
+ be request-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+6 Response
+
+ After receiving and interpreting a request message, a server responds
+ with an HTTP response message.
+
+ Response = Status-Line ; Section 6.1
+ *( general-header ; Section 4.5
+ | response-header ; Section 6.2
+ | entity-header ) ; Section 7.1
+ CRLF
+ [ message-body ] ; Section 7.2
+
+6.1 Status-Line
+
+ The first line of a Response message is the Status-Line, consisting
+ of the protocol version followed by a numeric status code and its
+ associated textual phrase, with each element separated by SP
+ characters. No CR or LF is allowed except in the final CRLF
+ sequence.
+
+
+
+
+Fielding, et. al. Standards Track [Page 38]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+6.1.1 Status Code and Reason Phrase
+
+ The Status-Code element is a 3-digit integer result code of the
+ attempt to understand and satisfy the request. These codes are fully
+ defined in section 10. The Reason-Phrase is intended to give a short
+ textual description of the Status-Code. The Status-Code is intended
+ for use by automata and the Reason-Phrase is intended for the human
+ user. The client is not required to examine or display the Reason-
+ Phrase.
+
+ The first digit of the Status-Code defines the class of response. The
+ last two digits do not have any categorization role. There are 5
+ values for the first digit:
+
+ o 1xx: Informational - Request received, continuing process
+
+ o 2xx: Success - The action was successfully received, understood,
+ and accepted
+
+ o 3xx: Redirection - Further action must be taken in order to
+ complete the request
+
+ o 4xx: Client Error - The request contains bad syntax or cannot be
+ fulfilled
+
+ o 5xx: Server Error - The server failed to fulfill an apparently
+ valid request
+
+ The individual values of the numeric status codes defined for
+ HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+ presented below. The reason phrases listed here are only recommended
+ -- they may be replaced by local equivalents without affecting the
+ protocol.
+
+ Status-Code = "100" ; Continue
+ | "101" ; Switching Protocols
+ | "200" ; OK
+ | "201" ; Created
+ | "202" ; Accepted
+ | "203" ; Non-Authoritative Information
+ | "204" ; No Content
+ | "205" ; Reset Content
+ | "206" ; Partial Content
+ | "300" ; Multiple Choices
+ | "301" ; Moved Permanently
+ | "302" ; Moved Temporarily
+
+
+
+Fielding, et. al. Standards Track [Page 39]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ | "303" ; See Other
+ | "304" ; Not Modified
+ | "305" ; Use Proxy
+ | "400" ; Bad Request
+ | "401" ; Unauthorized
+ | "402" ; Payment Required
+ | "403" ; Forbidden
+ | "404" ; Not Found
+ | "405" ; Method Not Allowed
+ | "406" ; Not Acceptable
+ | "407" ; Proxy Authentication Required
+ | "408" ; Request Time-out
+ | "409" ; Conflict
+ | "410" ; Gone
+ | "411" ; Length Required
+ | "412" ; Precondition Failed
+ | "413" ; Request Entity Too Large
+ | "414" ; Request-URI Too Large
+ | "415" ; Unsupported Media Type
+ | "500" ; Internal Server Error
+ | "501" ; Not Implemented
+ | "502" ; Bad Gateway
+ | "503" ; Service Unavailable
+ | "504" ; Gateway Time-out
+ | "505" ; HTTP Version not supported
+ | extension-code
+
+ extension-code = 3DIGIT
+
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+
+ HTTP status codes are extensible. HTTP applications are not required
+ to understand the meaning of all registered status codes, though such
+ understanding is obviously desirable. However, applications MUST
+ understand the class of any status code, as indicated by the first
+ digit, and treat any unrecognized response as being equivalent to the
+ x00 status code of that class, with the exception that an
+ unrecognized response MUST NOT be cached. For example, if an
+ unrecognized status code of 431 is received by the client, it can
+ safely assume that there was something wrong with its request and
+ treat the response as if it had received a 400 status code. In such
+ cases, user agents SHOULD present to the user the entity returned
+ with the response, since that entity is likely to include human-
+ readable information which will explain the unusual status.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 40]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+6.2 Response Header Fields
+
+ The response-header fields allow the server to pass additional
+ information about the response which cannot be placed in the Status-
+ Line. These header fields give information about the server and about
+ further access to the resource identified by the Request-URI.
+
+ response-header = Age ; Section 14.6
+ | Location ; Section 14.30
+ | Proxy-Authenticate ; Section 14.33
+ | Public ; Section 14.35
+ | Retry-After ; Section 14.38
+ | Server ; Section 14.39
+ | Vary ; Section 14.43
+ | Warning ; Section 14.45
+ | WWW-Authenticate ; Section 14.46
+
+ Response-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields MAY be given the semantics of response-
+ header fields if all parties in the communication recognize them to
+ be response-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+7 Entity
+
+ Request and Response messages MAY transfer an entity if not otherwise
+ restricted by the request method or response status code. An entity
+ consists of entity-header fields and an entity-body, although some
+ responses will only include the entity-headers.
+
+ In this section, both sender and recipient refer to either the client
+ or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+ Entity-header fields define optional metainformation about the
+ entity-body or, if no body is present, about the resource identified
+ by the request.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 41]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ entity-header = Allow ; Section 14.7
+ | Content-Base ; Section 14.11
+ | Content-Encoding ; Section 14.12
+ | Content-Language ; Section 14.13
+ | Content-Length ; Section 14.14
+ | Content-Location ; Section 14.15
+ | Content-MD5 ; Section 14.16
+ | Content-Range ; Section 14.17
+ | Content-Type ; Section 14.18
+ | ETag ; Section 14.20
+ | Expires ; Section 14.21
+ | Last-Modified ; Section 14.29
+ | extension-header
+
+ extension-header = message-header
+
+ The extension-header mechanism allows additional entity-header fields
+ to be defined without changing the protocol, but these fields cannot
+ be assumed to be recognizable by the recipient. Unrecognized header
+ fields SHOULD be ignored by the recipient and forwarded by proxies.
+
+7.2 Entity Body
+
+ The entity-body (if any) sent with an HTTP request or response is in
+ a format and encoding defined by the entity-header fields.
+
+ entity-body = *OCTET
+
+ An entity-body is only present in a message when a message-body is
+ present, as described in section 4.3. The entity-body is obtained
+ from the message-body by decoding any Transfer-Encoding that may have
+ been applied to ensure safe and proper transfer of the message.
+
+7.2.1 Type
+
+ When an entity-body is included with a message, the data type of that
+ body is determined via the header fields Content-Type and Content-
+ Encoding. These define a two-layer, ordered encoding model:
+
+ entity-body := Content-Encoding( Content-Type( data ) )
+
+ Content-Type specifies the media type of the underlying data.
+ Content-Encoding may be used to indicate any additional content
+ codings applied to the data, usually for the purpose of data
+ compression, that are a property of the requested resource. There is
+ no default encoding.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 42]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Any HTTP/1.1 message containing an entity-body SHOULD include a
+ Content-Type header field defining the media type of that body. If
+ and only if the media type is not given by a Content-Type field, the
+ recipient MAY attempt to guess the media type via inspection of its
+ content and/or the name extension(s) of the URL used to identify the
+ resource. If the media type remains unknown, the recipient SHOULD
+ treat it as type "application/octet-stream".
+
+7.2.2 Length
+
+ The length of an entity-body is the length of the message-body after
+ any transfer codings have been removed. Section 4.4 defines how the
+ length of a message-body is determined.
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+ Prior to persistent connections, a separate TCP connection was
+ established to fetch each URL, increasing the load on HTTP servers
+ and causing congestion on the Internet. The use of inline images and
+ other associated data often requires a client to make multiple
+ requests of the same server in a short amount of time. Analyses of
+ these performance problems are available [30][27]; analysis and
+ results from a prototype implementation are in [26].
+
+ Persistent HTTP connections have a number of advantages:
+
+ o By opening and closing fewer TCP connections, CPU time is saved,
+ and memory used for TCP protocol control blocks is also saved.
+ o HTTP requests and responses can be pipelined on a connection.
+ Pipelining allows a client to make multiple requests without
+ waiting for each response, allowing a single TCP connection to be
+ used much more efficiently, with much lower elapsed time.
+ o Network congestion is reduced by reducing the number of packets
+ caused by TCP opens, and by allowing TCP sufficient time to
+ determine the congestion state of the network.
+ o HTTP can evolve more gracefully; since errors can be reported
+ without the penalty of closing the TCP connection. Clients using
+ future versions of HTTP might optimistically try a new feature, but
+ if communicating with an older server, retry with old semantics
+ after an error is reported.
+
+ HTTP implementations SHOULD implement persistent connections.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 43]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+8.1.2 Overall Operation
+
+ A significant difference between HTTP/1.1 and earlier versions of
+ HTTP is that persistent connections are the default behavior of any
+ HTTP connection. That is, unless otherwise indicated, the client may
+ assume that the server will maintain a persistent connection.
+
+ Persistent connections provide a mechanism by which a client and a
+ server can signal the close of a TCP connection. This signaling takes
+ place using the Connection header field. Once a close has been
+ signaled, the client MUST not send any more requests on that
+ connection.
+
+8.1.2.1 Negotiation
+
+ An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+ maintain a persistent connection unless a Connection header including
+ the connection-token "close" was sent in the request. If the server
+ chooses to close the connection immediately after sending the
+ response, it SHOULD send a Connection header including the
+ connection-token close.
+
+ An HTTP/1.1 client MAY expect a connection to remain open, but would
+ decide to keep it open based on whether the response from a server
+ contains a Connection header with the connection-token close. In case
+ the client does not want to maintain a connection for more than that
+ request, it SHOULD send a Connection header including the
+ connection-token close.
+
+ If either the client or the server sends the close token in the
+ Connection header, that request becomes the last one for the
+ connection.
+
+ Clients and servers SHOULD NOT assume that a persistent connection is
+ maintained for HTTP versions less than 1.1 unless it is explicitly
+ signaled. See section 19.7.1 for more information on backwards
+ compatibility with HTTP/1.0 clients.
+
+ In order to remain persistent, all messages on the connection must
+ have a self-defined message length (i.e., one not defined by closure
+ of the connection), as described in section 4.4.
+
+8.1.2.2 Pipelining
+
+ A client that supports persistent connections MAY "pipeline" its
+ requests (i.e., send multiple requests without waiting for each
+ response). A server MUST send its responses to those requests in the
+ same order that the requests were received.
+
+
+
+Fielding, et. al. Standards Track [Page 44]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Clients which assume persistent connections and pipeline immediately
+ after connection establishment SHOULD be prepared to retry their
+ connection if the first pipelined attempt fails. If a client does
+ such a retry, it MUST NOT pipeline before it knows the connection is
+ persistent. Clients MUST also be prepared to resend their requests if
+ the server closes the connection before sending all of the
+ corresponding responses.
+
+8.1.3 Proxy Servers
+
+ It is especially important that proxies correctly implement the
+ properties of the Connection header field as specified in 14.2.1.
+
+ The proxy server MUST signal persistent connections separately with
+ its clients and the origin servers (or other proxy servers) that it
+ connects to. Each persistent connection applies to only one transport
+ link.
+
+ A proxy server MUST NOT establish a persistent connection with an
+ HTTP/1.0 client.
+
+8.1.4 Practical Considerations
+
+ Servers will usually have some time-out value beyond which they will
+ no longer maintain an inactive connection. Proxy servers might make
+ this a higher value since it is likely that the client will be making
+ more connections through the same server. The use of persistent
+ connections places no requirements on the length of this time-out for
+ either the client or the server.
+
+ When a client or server wishes to time-out it SHOULD issue a graceful
+ close on the transport connection. Clients and servers SHOULD both
+ constantly watch for the other side of the transport close, and
+ respond to it as appropriate. If a client or server does not detect
+ the other side's close promptly it could cause unnecessary resource
+ drain on the network.
+
+ A client, server, or proxy MAY close the transport connection at any
+ time. For example, a client MAY have started to send a new request at
+ the same time that the server has decided to close the "idle"
+ connection. From the server's point of view, the connection is being
+ closed while it was idle, but from the client's point of view, a
+ request is in progress.
+
+ This means that clients, servers, and proxies MUST be able to recover
+ from asynchronous close events. Client software SHOULD reopen the
+ transport connection and retransmit the aborted request without user
+ interaction so long as the request method is idempotent (see section
+
+
+
+Fielding, et. al. Standards Track [Page 45]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ 9.1.2); other methods MUST NOT be automatically retried, although
+ user agents MAY offer a human operator the choice of retrying the
+ request.
+
+ However, this automatic retry SHOULD NOT be repeated if the second
+ request fails.
+
+ Servers SHOULD always respond to at least one request per connection,
+ if at all possible. Servers SHOULD NOT close a connection in the
+ middle of transmitting a response, unless a network or client failure
+ is suspected.
+
+ Clients that use persistent connections SHOULD limit the number of
+ simultaneous connections that they maintain to a given server. A
+ single-user client SHOULD maintain AT MOST 2 connections with any
+ server or proxy. A proxy SHOULD use up to 2*N connections to another
+ server or proxy, where N is the number of simultaneously active
+ users. These guidelines are intended to improve HTTP response times
+ and avoid congestion of the Internet or other networks.
+
+8.2 Message Transmission Requirements
+
+General requirements:
+
+o HTTP/1.1 servers SHOULD maintain persistent connections and use
+ TCP's flow control mechanisms to resolve temporary overloads,
+ rather than terminating connections with the expectation that
+ clients will retry. The latter technique can exacerbate network
+ congestion.
+
+o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
+ the network connection for an error status while it is transmitting
+ the request. If the client sees an error status, it SHOULD
+ immediately cease transmitting the body. If the body is being sent
+ using a "chunked" encoding (section 3.6), a zero length chunk and
+ empty footer MAY be used to prematurely mark the end of the
+ message. If the body was preceded by a Content-Length header, the
+ client MUST close the connection.
+
+o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
+ (Continue) status followed by a regular response.
+
+o An HTTP/1.1 (or later) server that receives a request from a
+ HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
+ response; it SHOULD either wait for the request to be completed
+ normally (thus avoiding an interrupted request) or close the
+ connection prematurely.
+
+
+
+
+Fielding, et. al. Standards Track [Page 46]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Upon receiving a method subject to these requirements from an
+ HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
+ respond with 100 (Continue) status and continue to read from the
+ input stream, or respond with an error status. If it responds with an
+ error status, it MAY close the transport (TCP) connection or it MAY
+ continue to read and discard the rest of the request. It MUST NOT
+ perform the requested method if it returns an error status.
+
+ Clients SHOULD remember the version number of at least the most
+ recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
+ later response from the server, and it sees the connection close
+ before receiving any status from the server, the client SHOULD retry
+ the request without user interaction so long as the request method is
+ idempotent (see section 9.1.2); other methods MUST NOT be
+ automatically retried, although user agents MAY offer a human
+ operator the choice of retrying the request.. If the client does
+ retry the request, the client
+
+ o MUST first send the request header fields, and then
+
+ o MUST wait for the server to respond with either a 100 (Continue)
+ response, in which case the client should continue, or with an
+ error status.
+
+ If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
+ the server, it should assume that the server implements HTTP/1.0 or
+ older and will not use the 100 (Continue) response. If in this case
+ the client sees the connection close before receiving any status from
+ the server, the client SHOULD retry the request. If the client does
+ retry the request to this HTTP/1.0 server, it should use the
+ following "binary exponential backoff" algorithm to be assured of
+ obtaining a reliable response:
+
+ 1. Initiate a new connection to the server
+
+ 2. Transmit the request-headers
+
+ 3. Initialize a variable R to the estimated round-trip time to the
+ server (e.g., based on the time it took to establish the
+ connection), or to a constant value of 5 seconds if the round-trip
+ time is not available.
+
+ 4. Compute T = R * (2**N), where N is the number of previous retries
+ of this request.
+
+ 5. Wait either for an error response from the server, or for T seconds
+ (whichever comes first)
+
+
+
+
+Fielding, et. al. Standards Track [Page 47]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ 6. If no error response is received, after T seconds transmit the body
+ of the request.
+
+ 7. If client sees that the connection is closed prematurely, repeat
+ from step 1 until the request is accepted, an error response is
+ received, or the user becomes impatient and terminates the retry
+ process.
+
+ No matter what the server version, if an error status is received,
+ the client
+
+ o MUST NOT continue and
+
+ o MUST close the connection if it has not completed sending the
+ message.
+
+ An HTTP/1.1 (or later) client that sees the connection close after
+ receiving a 100 (Continue) but before receiving any other status
+ SHOULD retry the request, and need not wait for 100 (Continue)
+ response (but MAY do so if this simplifies the implementation).
+
+9 Method Definitions
+
+ The set of common methods for HTTP/1.1 is defined below. Although
+ this set can be expanded, additional methods cannot be assumed to
+ share the same semantics for separately extended clients and servers.
+
+ The Host request-header field (section 14.23) MUST accompany all
+ HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+ Implementers should be aware that the software represents the user in
+ their interactions over the Internet, and should be careful to allow
+ the user to be aware of any actions they may take which may have an
+ unexpected significance to themselves or others.
+
+ In particular, the convention has been established that the GET and
+ HEAD methods should never have the significance of taking an action
+ other than retrieval. These methods should be considered "safe." This
+ allows user agents to represent other methods, such as POST, PUT and
+ DELETE, in a special way, so that the user is made aware of the fact
+ that a possibly unsafe action is being requested.
+
+ Naturally, it is not possible to ensure that the server does not
+ generate side-effects as a result of performing a GET request; in
+
+
+
+Fielding, et. al. Standards Track [Page 48]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ fact, some dynamic resources consider that a feature. The important
+ distinction here is that the user did not request the side-effects,
+ so therefore cannot be held accountable for them.
+
+9.1.2 Idempotent Methods
+
+ Methods may also have the property of "idempotence" in that (aside
+ from error or expiration issues) the side-effects of N > 0 identical
+ requests is the same as for a single request. The methods GET, HEAD,
+ PUT and DELETE share this property.
+
+9.2 OPTIONS
+
+ The OPTIONS method represents a request for information about the
+ communication options available on the request/response chain
+ identified by the Request-URI. This method allows the client to
+ determine the options and/or requirements associated with a resource,
+ or the capabilities of a server, without implying a resource action
+ or initiating a resource retrieval.
+
+ Unless the server's response is an error, the response MUST NOT
+ include entity information other than what can be considered as
+ communication options (e.g., Allow is appropriate, but Content-Type
+ is not). Responses to this method are not cachable.
+
+ If the Request-URI is an asterisk ("*"), the OPTIONS request is
+ intended to apply to the server as a whole. A 200 response SHOULD
+ include any header fields which indicate optional features
+ implemented by the server (e.g., Public), including any extensions
+ not defined by this specification, in addition to any applicable
+ general or response-header fields. As described in section 5.1.2, an
+ "OPTIONS *" request can be applied through a proxy by specifying the
+ destination server in the Request-URI without any path information.
+
+ If the Request-URI is not an asterisk, the OPTIONS request applies
+ only to the options that are available when communicating with that
+ resource. A 200 response SHOULD include any header fields which
+ indicate optional features implemented by the server and applicable
+ to that resource (e.g., Allow), including any extensions not defined
+ by this specification, in addition to any applicable general or
+ response-header fields. If the OPTIONS request passes through a
+ proxy, the proxy MUST edit the response to exclude those options
+ which apply to a proxy's capabilities and which are known to be
+ unavailable through that proxy.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 49]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+9.3 GET
+
+ The GET method means retrieve whatever information (in the form of an
+ entity) is identified by the Request-URI. If the Request-URI refers
+ to a data-producing process, it is the produced data which shall be
+ returned as the entity in the response and not the source text of the
+ process, unless that text happens to be the output of the process.
+
+ The semantics of the GET method change to a "conditional GET" if the
+ request message includes an If-Modified-Since, If-Unmodified-Since,
+ If-Match, If-None-Match, or If-Range header field. A conditional GET
+ method requests that the entity be transferred only under the
+ circumstances described by the conditional header field(s). The
+ conditional GET method is intended to reduce unnecessary network
+ usage by allowing cached entities to be refreshed without requiring
+ multiple requests or transferring data already held by the client.
+
+ The semantics of the GET method change to a "partial GET" if the
+ request message includes a Range header field. A partial GET requests
+ that only part of the entity be transferred, as described in section
+ 14.36. The partial GET method is intended to reduce unnecessary
+ network usage by allowing partially-retrieved entities to be
+ completed without transferring data already held by the client.
+
+ The response to a GET request is cachable if and only if it meets the
+ requirements for HTTP caching described in section 13.
+
+9.4 HEAD
+
+ The HEAD method is identical to GET except that the server MUST NOT
+ return a message-body in the response. The metainformation contained
+ in the HTTP headers in response to a HEAD request SHOULD be identical
+ to the information sent in response to a GET request. This method can
+ be used for obtaining metainformation about the entity implied by the
+ request without transferring the entity-body itself. This method is
+ often used for testing hypertext links for validity, accessibility,
+ and recent modification.
+
+ The response to a HEAD request may be cachable in the sense that the
+ information contained in the response may be used to update a
+ previously cached entity from that resource. If the new field values
+ indicate that the cached entity differs from the current entity (as
+ would be indicated by a change in Content-Length, Content-MD5, ETag
+ or Last-Modified), then the cache MUST treat the cache entry as
+ stale.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 50]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+9.5 POST
+
+ The POST method is used to request that the destination server accept
+ the entity enclosed in the request as a new subordinate of the
+ resource identified by the Request-URI in the Request-Line. POST is
+ designed to allow a uniform method to cover the following functions:
+
+ o Annotation of existing resources;
+
+ o Posting a message to a bulletin board, newsgroup, mailing list,
+ or similar group of articles;
+
+ o Providing a block of data, such as the result of submitting a
+ form, to a data-handling process;
+
+ o Extending a database through an append operation.
+
+ The actual function performed by the POST method is determined by the
+ server and is usually dependent on the Request-URI. The posted entity
+ is subordinate to that URI in the same way that a file is subordinate
+ to a directory containing it, a news article is subordinate to a
+ newsgroup to which it is posted, or a record is subordinate to a
+ database.
+
+ The action performed by the POST method might not result in a
+ resource that can be identified by a URI. In this case, either 200
+ (OK) or 204 (No Content) is the appropriate response status,
+ depending on whether or not the response includes an entity that
+ describes the result.
+
+ If a resource has been created on the origin server, the response
+ SHOULD be 201 (Created) and contain an entity which describes the
+ status of the request and refers to the new resource, and a Location
+ header (see section 14.30).
+
+ Responses to this method are not cachable, unless the response
+ includes appropriate Cache-Control or Expires header fields. However,
+ the 303 (See Other) response can be used to direct the user agent to
+ retrieve a cachable resource.
+
+ POST requests must obey the message transmission requirements set out
+ in section 8.2.
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 51]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+9.6 PUT
+
+ The PUT method requests that the enclosed entity be stored under the
+ supplied Request-URI. If the Request-URI refers to an already
+ existing resource, the enclosed entity SHOULD be considered as a
+ modified version of the one residing on the origin server. If the
+ Request-URI does not point to an existing resource, and that URI is
+ capable of being defined as a new resource by the requesting user
+ agent, the origin server can create the resource with that URI. If a
+ new resource is created, the origin server MUST inform the user agent
+ via the 201 (Created) response. If an existing resource is modified,
+ either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
+ to indicate successful completion of the request. If the resource
+ could not be created or modified with the Request-URI, an appropriate
+ error response SHOULD be given that reflects the nature of the
+ problem. The recipient of the entity MUST NOT ignore any Content-*
+ (e.g. Content-Range) headers that it does not understand or implement
+ and MUST return a 501 (Not Implemented) response in such cases.
+
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries should be
+ treated as stale. Responses to this method are not cachable.
+
+ The fundamental difference between the POST and PUT requests is
+ reflected in the different meaning of the Request-URI. The URI in a
+ POST request identifies the resource that will handle the enclosed
+ entity. That resource may be a data-accepting process, a gateway to
+ some other protocol, or a separate entity that accepts annotations.
+ In contrast, the URI in a PUT request identifies the entity enclosed
+ with the request -- the user agent knows what URI is intended and the
+ server MUST NOT attempt to apply the request to some other resource.
+ If the server desires that the request be applied to a different URI,
+ it MUST send a 301 (Moved Permanently) response; the user agent MAY
+ then make its own decision regarding whether or not to redirect the
+ request.
+
+ A single resource MAY be identified by many different URIs. For
+ example, an article may have a URI for identifying "the current
+ version" which is separate from the URI identifying each particular
+ version. In this case, a PUT request on a general URI may result in
+ several other URIs being defined by the origin server.
+
+ HTTP/1.1 does not define how a PUT method affects the state of an
+ origin server.
+
+ PUT requests must obey the message transmission requirements set out
+ in section 8.2.
+
+
+
+
+Fielding, et. al. Standards Track [Page 52]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+9.7 DELETE
+
+ The DELETE method requests that the origin server delete the resource
+ identified by the Request-URI. This method MAY be overridden by human
+ intervention (or other means) on the origin server. The client cannot
+ be guaranteed that the operation has been carried out, even if the
+ status code returned from the origin server indicates that the action
+ has been completed successfully. However, the server SHOULD not
+ indicate success unless, at the time the response is given, it
+ intends to delete the resource or move it to an inaccessible
+ location.
+
+ A successful response SHOULD be 200 (OK) if the response includes an
+ entity describing the status, 202 (Accepted) if the action has not
+ yet been enacted, or 204 (No Content) if the response is OK but does
+ not include an entity.
+
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries should be
+ treated as stale. Responses to this method are not cachable.
+
+9.8 TRACE
+
+ The TRACE method is used to invoke a remote, application-layer loop-
+ back of the request message. The final recipient of the request
+ SHOULD reflect the message received back to the client as the
+ entity-body of a 200 (OK) response. The final recipient is either the
+ origin server or the first proxy or gateway to receive a Max-Forwards
+ value of zero (0) in the request (see section 14.31). A TRACE request
+ MUST NOT include an entity.
+
+ TRACE allows the client to see what is being received at the other
+ end of the request chain and use that data for testing or diagnostic
+ information. The value of the Via header field (section 14.44) is of
+ particular interest, since it acts as a trace of the request chain.
+ Use of the Max-Forwards header field allows the client to limit the
+ length of the request chain, which is useful for testing a chain of
+ proxies forwarding messages in an infinite loop.
+
+ If successful, the response SHOULD contain the entire request message
+ in the entity-body, with a Content-Type of "message/http". Responses
+ to this method MUST NOT be cached.
+
+10 Status Code Definitions
+
+ Each Status-Code is described below, including a description of which
+ method(s) it can follow and any metainformation required in the
+ response.
+
+
+
+Fielding, et. al. Standards Track [Page 53]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.1 Informational 1xx
+
+ This class of status code indicates a provisional response,
+ consisting only of the Status-Line and optional headers, and is
+ terminated by an empty line. Since HTTP/1.0 did not define any 1xx
+ status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
+ client except under experimental conditions.
+
+10.1.1 100 Continue
+
+ The client may continue with its request. This interim response is
+ used to inform the client that the initial part of the request has
+ been received and has not yet been rejected by the server. The client
+ SHOULD continue by sending the remainder of the request or, if the
+ request has already been completed, ignore this response. The server
+ MUST send a final response after the request has been completed.
+
+10.1.2 101 Switching Protocols
+
+ The server understands and is willing to comply with the client's
+ request, via the Upgrade message header field (section 14.41), for a
+ change in the application protocol being used on this connection. The
+ server will switch protocols to those defined by the response's
+ Upgrade header field immediately after the empty line which
+ terminates the 101 response.
+
+ The protocol should only be switched when it is advantageous to do
+ so. For example, switching to a newer version of HTTP is
+ advantageous over older versions, and switching to a real-time,
+ synchronous protocol may be advantageous when delivering resources
+ that use such features.
+
+10.2 Successful 2xx
+
+ This class of status code indicates that the client's request was
+ successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+ The request has succeeded. The information returned with the response
+ is dependent on the method used in the request, for example:
+
+ GET an entity corresponding to the requested resource is sent in the
+ response;
+
+ HEAD the entity-header fields corresponding to the requested resource
+ are sent in the response without any message-body;
+
+
+
+
+Fielding, et. al. Standards Track [Page 54]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ POST an entity describing or containing the result of the action;
+
+ TRACE an entity containing the request message as received by the end
+ server.
+
+10.2.2 201 Created
+
+ The request has been fulfilled and resulted in a new resource being
+ created. The newly created resource can be referenced by the URI(s)
+ returned in the entity of the response, with the most specific URL
+ for the resource given by a Location header field. The origin server
+ MUST create the resource before returning the 201 status code. If the
+ action cannot be carried out immediately, the server should respond
+ with 202 (Accepted) response instead.
+
+10.2.3 202 Accepted
+
+ The request has been accepted for processing, but the processing has
+ not been completed. The request MAY or MAY NOT eventually be acted
+ upon, as it MAY be disallowed when processing actually takes place.
+ There is no facility for re-sending a status code from an
+ asynchronous operation such as this.
+
+ The 202 response is intentionally non-committal. Its purpose is to
+ allow a server to accept a request for some other process (perhaps a
+ batch-oriented process that is only run once per day) without
+ requiring that the user agent's connection to the server persist
+ until the process is completed. The entity returned with this
+ response SHOULD include an indication of the request's current status
+ and either a pointer to a status monitor or some estimate of when the
+ user can expect the request to be fulfilled.
+
+10.2.4 203 Non-Authoritative Information
+
+ The returned metainformation in the entity-header is not the
+ definitive set as available from the origin server, but is gathered
+ from a local or a third-party copy. The set presented MAY be a subset
+ or superset of the original version. For example, including local
+ annotation information about the resource MAY result in a superset of
+ the metainformation known by the origin server. Use of this response
+ code is not required and is only appropriate when the response would
+ otherwise be 200 (OK).
+
+10.2.5 204 No Content
+
+ The server has fulfilled the request but there is no new information
+ to send back. If the client is a user agent, it SHOULD NOT change its
+ document view from that which caused the request to be sent. This
+
+
+
+Fielding, et. al. Standards Track [Page 55]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ response is primarily intended to allow input for actions to take
+ place without causing a change to the user agent's active document
+ view. The response MAY include new metainformation in the form of
+ entity-headers, which SHOULD apply to the document currently in the
+ user agent's active view.
+
+ The 204 response MUST NOT include a message-body, and thus is always
+ terminated by the first empty line after the header fields.
+
+10.2.6 205 Reset Content
+
+ The server has fulfilled the request and the user agent SHOULD reset
+ the document view which caused the request to be sent. This response
+ is primarily intended to allow input for actions to take place via
+ user input, followed by a clearing of the form in which the input is
+ given so that the user can easily initiate another input action. The
+ response MUST NOT include an entity.
+
+10.2.7 206 Partial Content
+
+ The server has fulfilled the partial GET request for the resource.
+ The request must have included a Range header field (section 14.36)
+ indicating the desired range. The response MUST include either a
+ Content-Range header field (section 14.17) indicating the range
+ included with this response, or a multipart/byteranges Content-Type
+ including Content-Range fields for each part. If multipart/byteranges
+ is not used, the Content-Length header field in the response MUST
+ match the actual number of OCTETs transmitted in the message-body.
+
+ A cache that does not support the Range and Content-Range headers
+ MUST NOT cache 206 (Partial) responses.
+
+10.3 Redirection 3xx
+
+ This class of status code indicates that further action needs to be
+ taken by the user agent in order to fulfill the request. The action
+ required MAY be carried out by the user agent without interaction
+ with the user if and only if the method used in the second request is
+ GET or HEAD. A user agent SHOULD NOT automatically redirect a request
+ more than 5 times, since such redirections usually indicate an
+ infinite loop.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 56]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.3.1 300 Multiple Choices
+
+ The requested resource corresponds to any one of a set of
+ representations, each with its own specific location, and agent-
+ driven negotiation information (section 12) is being provided so that
+ the user (or user agent) can select a preferred representation and
+ redirect its request to that location.
+
+ Unless it was a HEAD request, the response SHOULD include an entity
+ containing a list of resource characteristics and location(s) from
+ which the user or user agent can choose the one most appropriate. The
+ entity format is specified by the media type given in the Content-
+ Type header field. Depending upon the format and the capabilities of
+ the user agent, selection of the most appropriate choice may be
+ performed automatically. However, this specification does not define
+ any standard for such automatic selection.
+
+ If the server has a preferred choice of representation, it SHOULD
+ include the specific URL for that representation in the Location
+ field; user agents MAY use the Location field value for automatic
+ redirection. This response is cachable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+ The requested resource has been assigned a new permanent URI and any
+ future references to this resource SHOULD be done using one of the
+ returned URIs. Clients with link editing capabilities SHOULD
+ automatically re-link references to the Request-URI to one or more of
+ the new references returned by the server, where possible. This
+ response is cachable unless indicated otherwise.
+
+ If the new URI is a location, its URL SHOULD be given by the Location
+ field in the response. Unless the request method was HEAD, the entity
+ of the response SHOULD contain a short hypertext note with a
+ hyperlink to the new URI(s).
+
+ If the 301 status code is received in response to a request other
+ than GET or HEAD, the user agent MUST NOT automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+
+ Note: When automatically redirecting a POST request after receiving
+ a 301 status code, some existing HTTP/1.0 user agents will
+ erroneously change it into a GET request.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 57]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.3.3 302 Moved Temporarily
+
+ The requested resource resides temporarily under a different URI.
+ Since the redirection may be altered on occasion, the client SHOULD
+ continue to use the Request-URI for future requests. This response is
+ only cachable if indicated by a Cache-Control or Expires header
+ field.
+
+ If the new URI is a location, its URL SHOULD be given by the Location
+ field in the response. Unless the request method was HEAD, the entity
+ of the response SHOULD contain a short hypertext note with a
+ hyperlink to the new URI(s).
+
+ If the 302 status code is received in response to a request other
+ than GET or HEAD, the user agent MUST NOT automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+
+ Note: When automatically redirecting a POST request after receiving
+ a 302 status code, some existing HTTP/1.0 user agents will
+ erroneously change it into a GET request.
+
+10.3.4 303 See Other
+
+ The response to the request can be found under a different URI and
+ SHOULD be retrieved using a GET method on that resource. This method
+ exists primarily to allow the output of a POST-activated script to
+ redirect the user agent to a selected resource. The new URI is not a
+ substitute reference for the originally requested resource. The 303
+ response is not cachable, but the response to the second (redirected)
+ request MAY be cachable.
+
+ If the new URI is a location, its URL SHOULD be given by the Location
+ field in the response. Unless the request method was HEAD, the entity
+ of the response SHOULD contain a short hypertext note with a
+ hyperlink to the new URI(s).
+
+10.3.5 304 Not Modified
+
+ If the client has performed a conditional GET request and access is
+ allowed, but the document has not been modified, the server SHOULD
+ respond with this status code. The response MUST NOT contain a
+ message-body.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 58]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The response MUST include the following header fields:
+
+ o Date
+
+ o ETag and/or Content-Location, if the header would have been sent in
+ a 200 response to the same request
+
+ o Expires, Cache-Control, and/or Vary, if the field-value might
+ differ from that sent in any previous response for the same variant
+
+ If the conditional GET used a strong cache validator (see section
+ 13.3.3), the response SHOULD NOT include other entity-headers.
+ Otherwise (i.e., the conditional GET used a weak validator), the
+ response MUST NOT include other entity-headers; this prevents
+ inconsistencies between cached entity-bodies and updated headers.
+
+ If a 304 response indicates an entity not currently cached, then the
+ cache MUST disregard the response and repeat the request without the
+ conditional.
+
+ If a cache uses a received 304 response to update a cache entry, the
+ cache MUST update the entry to reflect any new field values given in
+ the response.
+
+ The 304 response MUST NOT include a message-body, and thus is always
+ terminated by the first empty line after the header fields.
+
+10.3.6 305 Use Proxy
+
+ The requested resource MUST be accessed through the proxy given by
+ the Location field. The Location field gives the URL of the proxy.
+ The recipient is expected to repeat the request via the proxy.
+
+10.4 Client Error 4xx
+
+ The 4xx class of status code is intended for cases in which the
+ client seems to have erred. Except when responding to a HEAD request,
+ the server SHOULD include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. These status codes are applicable to any request method.
+ User agents SHOULD display any included entity to the user.
+
+ Note: If the client is sending data, a server implementation using
+ TCP should be careful to ensure that the client acknowledges
+ receipt of the packet(s) containing the response, before the server
+ closes the input connection. If the client continues sending data
+ to the server after the close, the server's TCP stack will send a
+ reset packet to the client, which may erase the client's
+
+
+
+Fielding, et. al. Standards Track [Page 59]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ unacknowledged input buffers before they can be read and
+ interpreted by the HTTP application.
+
+10.4.1 400 Bad Request
+
+ The request could not be understood by the server due to malformed
+ syntax. The client SHOULD NOT repeat the request without
+ modifications.
+
+10.4.2 401 Unauthorized
+
+ The request requires user authentication. The response MUST include a
+ WWW-Authenticate header field (section 14.46) containing a challenge
+ applicable to the requested resource. The client MAY repeat the
+ request with a suitable Authorization header field (section 14.8). If
+ the request already included Authorization credentials, then the 401
+ response indicates that authorization has been refused for those
+ credentials. If the 401 response contains the same challenge as the
+ prior response, and the user agent has already attempted
+ authentication at least once, then the user SHOULD be presented the
+ entity that was given in the response, since that entity MAY include
+ relevant diagnostic information. HTTP access authentication is
+ explained in section 11.
+
+10.4.3 402 Payment Required
+
+ This code is reserved for future use.
+
+10.4.4 403 Forbidden
+
+ The server understood the request, but is refusing to fulfill it.
+ Authorization will not help and the request SHOULD NOT be repeated.
+ If the request method was not HEAD and the server wishes to make
+ public why the request has not been fulfilled, it SHOULD describe the
+ reason for the refusal in the entity. This status code is commonly
+ used when the server does not wish to reveal exactly why the request
+ has been refused, or when no other response is applicable.
+
+10.4.5 404 Not Found
+
+ The server has not found anything matching the Request-URI. No
+ indication is given of whether the condition is temporary or
+ permanent.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 60]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If the server does not wish to make this information available to the
+ client, the status code 403 (Forbidden) can be used instead. The 410
+ (Gone) status code SHOULD be used if the server knows, through some
+ internally configurable mechanism, that an old resource is
+ permanently unavailable and has no forwarding address.
+
+10.4.6 405 Method Not Allowed
+
+ The method specified in the Request-Line is not allowed for the
+ resource identified by the Request-URI. The response MUST include an
+ Allow header containing a list of valid methods for the requested
+ resource.
+
+10.4.7 406 Not Acceptable
+
+ The resource identified by the request is only capable of generating
+ response entities which have content characteristics not acceptable
+ according to the accept headers sent in the request.
+
+ Unless it was a HEAD request, the response SHOULD include an entity
+ containing a list of available entity characteristics and location(s)
+ from which the user or user agent can choose the one most
+ appropriate. The entity format is specified by the media type given
+ in the Content-Type header field. Depending upon the format and the
+ capabilities of the user agent, selection of the most appropriate
+ choice may be performed automatically. However, this specification
+ does not define any standard for such automatic selection.
+
+ Note: HTTP/1.1 servers are allowed to return responses which are
+ not acceptable according to the accept headers sent in the request.
+ In some cases, this may even be preferable to sending a 406
+ response. User agents are encouraged to inspect the headers of an
+ incoming response to determine if it is acceptable. If the response
+ could be unacceptable, a user agent SHOULD temporarily stop receipt
+ of more data and query the user for a decision on further actions.
+
+10.4.8 407 Proxy Authentication Required
+
+ This code is similar to 401 (Unauthorized), but indicates that the
+ client MUST first authenticate itself with the proxy. The proxy MUST
+ return a Proxy-Authenticate header field (section 14.33) containing a
+ challenge applicable to the proxy for the requested resource. The
+ client MAY repeat the request with a suitable Proxy-Authorization
+ header field (section 14.34). HTTP access authentication is explained
+ in section 11.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 61]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.4.9 408 Request Timeout
+
+ The client did not produce a request within the time that the server
+ was prepared to wait. The client MAY repeat the request without
+ modifications at any later time.
+
+10.4.10 409 Conflict
+
+ The request could not be completed due to a conflict with the current
+ state of the resource. This code is only allowed in situations where
+ it is expected that the user might be able to resolve the conflict
+ and resubmit the request. The response body SHOULD include enough
+ information for the user to recognize the source of the conflict.
+ Ideally, the response entity would include enough information for the
+ user or user agent to fix the problem; however, that may not be
+ possible and is not required.
+
+ Conflicts are most likely to occur in response to a PUT request. If
+ versioning is being used and the entity being PUT includes changes to
+ a resource which conflict with those made by an earlier (third-party)
+ request, the server MAY use the 409 response to indicate that it
+ can't complete the request. In this case, the response entity SHOULD
+ contain a list of the differences between the two versions in a
+ format defined by the response Content-Type.
+
+10.4.11 410 Gone
+
+ The requested resource is no longer available at the server and no
+ forwarding address is known. This condition SHOULD be considered
+ permanent. Clients with link editing capabilities SHOULD delete
+ references to the Request-URI after user approval. If the server does
+ not know, or has no facility to determine, whether or not the
+ condition is permanent, the status code 404 (Not Found) SHOULD be
+ used instead. This response is cachable unless indicated otherwise.
+
+ The 410 response is primarily intended to assist the task of web
+ maintenance by notifying the recipient that the resource is
+ intentionally unavailable and that the server owners desire that
+ remote links to that resource be removed. Such an event is common for
+ limited-time, promotional services and for resources belonging to
+ individuals no longer working at the server's site. It is not
+ necessary to mark all permanently unavailable resources as "gone" or
+ to keep the mark for any length of time -- that is left to the
+ discretion of the server owner.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 62]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.4.12 411 Length Required
+
+ The server refuses to accept the request without a defined Content-
+ Length. The client MAY repeat the request if it adds a valid
+ Content-Length header field containing the length of the message-body
+ in the request message.
+
+10.4.13 412 Precondition Failed
+
+ The precondition given in one or more of the request-header fields
+ evaluated to false when it was tested on the server. This response
+ code allows the client to place preconditions on the current resource
+ metainformation (header field data) and thus prevent the requested
+ method from being applied to a resource other than the one intended.
+
+10.4.14 413 Request Entity Too Large
+
+ The server is refusing to process a request because the request
+ entity is larger than the server is willing or able to process. The
+ server may close the connection to prevent the client from continuing
+ the request.
+
+ If the condition is temporary, the server SHOULD include a Retry-
+ After header field to indicate that it is temporary and after what
+ time the client may try again.
+
+10.4.15 414 Request-URI Too Long
+
+ The server is refusing to service the request because the Request-URI
+ is longer than the server is willing to interpret. This rare
+ condition is only likely to occur when a client has improperly
+ converted a POST request to a GET request with long query
+ information, when the client has descended into a URL "black hole" of
+ redirection (e.g., a redirected URL prefix that points to a suffix of
+ itself), or when the server is under attack by a client attempting to
+ exploit security holes present in some servers using fixed-length
+ buffers for reading or manipulating the Request-URI.
+
+10.4.16 415 Unsupported Media Type
+
+ The server is refusing to service the request because the entity of
+ the request is in a format not supported by the requested resource
+ for the requested method.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 63]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.5 Server Error 5xx
+
+ Response status codes beginning with the digit "5" indicate cases in
+ which the server is aware that it has erred or is incapable of
+ performing the request. Except when responding to a HEAD request, the
+ server SHOULD include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. User agents SHOULD display any included entity to the
+ user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+ The server encountered an unexpected condition which prevented it
+ from fulfilling the request.
+
+10.5.2 501 Not Implemented
+
+ The server does not support the functionality required to fulfill the
+ request. This is the appropriate response when the server does not
+ recognize the request method and is not capable of supporting it for
+ any resource.
+
+10.5.3 502 Bad Gateway
+
+ The server, while acting as a gateway or proxy, received an invalid
+ response from the upstream server it accessed in attempting to
+ fulfill the request.
+
+10.5.4 503 Service Unavailable
+
+ The server is currently unable to handle the request due to a
+ temporary overloading or maintenance of the server. The implication
+ is that this is a temporary condition which will be alleviated after
+ some delay. If known, the length of the delay may be indicated in a
+ Retry-After header. If no Retry-After is given, the client SHOULD
+ handle the response as it would for a 500 response.
+
+ Note: The existence of the 503 status code does not imply that a
+ server must use it when becoming overloaded. Some servers may wish
+ to simply refuse the connection.
+
+10.5.5 504 Gateway Timeout
+
+ The server, while acting as a gateway or proxy, did not receive a
+ timely response from the upstream server it accessed in attempting to
+ complete the request.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 64]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+10.5.6 505 HTTP Version Not Supported
+
+ The server does not support, or refuses to support, the HTTP protocol
+ version that was used in the request message. The server is
+ indicating that it is unable or unwilling to complete the request
+ using the same major version as the client, as described in section
+ 3.1, other than with this error message. The response SHOULD contain
+ an entity describing why that version is not supported and what other
+ protocols are supported by that server.
+
+11 Access Authentication
+
+ HTTP provides a simple challenge-response authentication mechanism
+ which MAY be used by a server to challenge a client request and by a
+ client to provide authentication information. It uses an extensible,
+ case-insensitive token to identify the authentication scheme,
+ followed by a comma-separated list of attribute-value pairs which
+ carry the parameters necessary for achieving authentication via that
+ scheme.
+
+ auth-scheme = token
+
+ auth-param = token "=" quoted-string
+
+ The 401 (Unauthorized) response message is used by an origin server
+ to challenge the authorization of a user agent. This response MUST
+ include a WWW-Authenticate header field containing at least one
+ challenge applicable to the requested resource.
+
+ challenge = auth-scheme 1*SP realm *( "," auth-param )
+
+ realm = "realm" "=" realm-value
+ realm-value = quoted-string
+
+ The realm attribute (case-insensitive) is required for all
+ authentication schemes which issue a challenge. The realm value
+ (case-sensitive), in combination with the canonical root URL (see
+ section 5.1.2) of the server being accessed, defines the protection
+ space. These realms allow the protected resources on a server to be
+ partitioned into a set of protection spaces, each with its own
+ authentication scheme and/or authorization database. The realm value
+ is a string, generally assigned by the origin server, which may have
+ additional semantics specific to the authentication scheme.
+
+ A user agent that wishes to authenticate itself with a server--
+ usually, but not necessarily, after receiving a 401 or 411 response-
+ -MAY do so by including an Authorization header field with the
+ request. The Authorization field value consists of credentials
+
+
+
+Fielding, et. al. Standards Track [Page 65]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ containing the authentication information of the user agent for the
+ realm of the resource being requested.
+
+ credentials = basic-credentials
+ | auth-scheme #auth-param
+
+ The domain over which credentials can be automatically applied by a
+ user agent is determined by the protection space. If a prior request
+ has been authorized, the same credentials MAY be reused for all other
+ requests within that protection space for a period of time determined
+ by the authentication scheme, parameters, and/or user preference.
+ Unless otherwise defined by the authentication scheme, a single
+ protection space cannot extend outside the scope of its server.
+
+ If the server does not wish to accept the credentials sent with a
+ request, it SHOULD return a 401 (Unauthorized) response. The response
+ MUST include a WWW-Authenticate header field containing the (possibly
+ new) challenge applicable to the requested resource and an entity
+ explaining the refusal.
+
+ The HTTP protocol does not restrict applications to this simple
+ challenge-response mechanism for access authentication. Additional
+ mechanisms MAY be used, such as encryption at the transport level or
+ via message encapsulation, and with additional header fields
+ specifying authentication information. However, these additional
+ mechanisms are not defined by this specification.
+
+ Proxies MUST be completely transparent regarding user agent
+ authentication. That is, they MUST forward the WWW-Authenticate and
+ Authorization headers untouched, and follow the rules found in
+ section 14.8.
+
+ HTTP/1.1 allows a client to pass authentication information to and
+ from a proxy via the Proxy-Authenticate and Proxy-Authorization
+ headers.
+
+11.1 Basic Authentication Scheme
+
+ The "basic" authentication scheme is based on the model that the user
+ agent must authenticate itself with a user-ID and a password for each
+ realm. The realm value should be considered an opaque string which
+ can only be compared for equality with other realms on that server.
+ The server will service the request only if it can validate the
+ user-ID and password for the protection space of the Request-URI.
+ There are no optional authentication parameters.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 66]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Upon receipt of an unauthorized request for a URI within the
+ protection space, the server MAY respond with a challenge like the
+ following:
+
+ WWW-Authenticate: Basic realm="WallyWorld"
+
+ where "WallyWorld" is the string assigned by the server to identify
+ the protection space of the Request-URI.
+
+ To receive authorization, the client sends the userid and password,
+ separated by a single colon (":") character, within a base64 encoded
+ string in the credentials.
+
+ basic-credentials = "Basic" SP basic-cookie
+
+ basic-cookie = <base64 [7] encoding of user-pass,
+ except not limited to 76 char/line>
+
+ user-pass = userid ":" password
+
+ userid = *<TEXT excluding ":">
+
+ password = *TEXT
+
+ Userids might be case sensitive.
+
+ If the user agent wishes to send the userid "Aladdin" and password
+ "open sesame", it would use the following header field:
+
+ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+
+ See section 15 for security considerations associated with Basic
+ authentication.
+
+11.2 Digest Authentication Scheme
+
+ A digest authentication for HTTP is specified in RFC 2069 [32].
+
+12 Content Negotiation
+
+ Most HTTP responses include an entity which contains information for
+ interpretation by a human user. Naturally, it is desirable to supply
+ the user with the "best available" entity corresponding to the
+ request. Unfortunately for servers and caches, not all users have
+ the same preferences for what is "best," and not all user agents are
+ equally capable of rendering all entity types. For that reason, HTTP
+ has provisions for several mechanisms for "content negotiation" --
+ the process of selecting the best representation for a given response
+
+
+
+Fielding, et. al. Standards Track [Page 67]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ when there are multiple representations available.
+
+ Note: This is not called "format negotiation" because the alternate
+ representations may be of the same media type, but use different
+ capabilities of that type, be in different languages, etc.
+
+ Any response containing an entity-body MAY be subject to negotiation,
+ including error responses.
+
+ There are two kinds of content negotiation which are possible in
+ HTTP: server-driven and agent-driven negotiation. These two kinds of
+ negotiation are orthogonal and thus may be used separately or in
+ combination. One method of combination, referred to as transparent
+ negotiation, occurs when a cache uses the agent-driven negotiation
+ information provided by the origin server in order to provide
+ server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+ If the selection of the best representation for a response is made by
+ an algorithm located at the server, it is called server-driven
+ negotiation. Selection is based on the available representations of
+ the response (the dimensions over which it can vary; e.g. language,
+ content-coding, etc.) and the contents of particular header fields in
+ the request message or on other information pertaining to the request
+ (such as the network address of the client).
+
+ Server-driven negotiation is advantageous when the algorithm for
+ selecting from among the available representations is difficult to
+ describe to the user agent, or when the server desires to send its
+ "best guess" to the client along with the first response (hoping to
+ avoid the round-trip delay of a subsequent request if the "best
+ guess" is good enough for the user). In order to improve the server's
+ guess, the user agent MAY include request header fields (Accept,
+ Accept-Language, Accept-Encoding, etc.) which describe its
+ preferences for such a response.
+
+ Server-driven negotiation has disadvantages:
+
+1. It is impossible for the server to accurately determine what might be
+ "best" for any given user, since that would require complete
+ knowledge of both the capabilities of the user agent and the intended
+ use for the response (e.g., does the user want to view it on screen
+ or print it on paper?).
+
+2. Having the user agent describe its capabilities in every request can
+ be both very inefficient (given that only a small percentage of
+ responses have multiple representations) and a potential violation of
+
+
+
+Fielding, et. al. Standards Track [Page 68]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ the user's privacy.
+
+3. It complicates the implementation of an origin server and the
+ algorithms for generating responses to a request.
+
+4. It may limit a public cache's ability to use the same response for
+ multiple user's requests.
+
+ HTTP/1.1 includes the following request-header fields for enabling
+ server-driven negotiation through description of user agent
+ capabilities and user preferences: Accept (section 14.1), Accept-
+ Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+ Language (section 14.4), and User-Agent (section 14.42). However, an
+ origin server is not limited to these dimensions and MAY vary the
+ response based on any aspect of the request, including information
+ outside the request-header fields or within extension header fields
+ not defined by this specification.
+
+ HTTP/1.1 origin servers MUST include an appropriate Vary header field
+ (section 14.43) in any cachable response based on server-driven
+ negotiation. The Vary header field describes the dimensions over
+ which the response might vary (i.e. the dimensions over which the
+ origin server picks its "best guess" response from multiple
+ representations).
+
+ HTTP/1.1 public caches MUST recognize the Vary header field when it
+ is included in a response and obey the requirements described in
+ section 13.6 that describes the interactions between caching and
+ content negotiation.
+
+12.2 Agent-driven Negotiation
+
+ With agent-driven negotiation, selection of the best representation
+ for a response is performed by the user agent after receiving an
+ initial response from the origin server. Selection is based on a list
+ of the available representations of the response included within the
+ header fields (this specification reserves the field-name Alternates,
+ as described in appendix 19.6.2.1) or entity-body of the initial
+ response, with each representation identified by its own URI.
+ Selection from among the representations may be performed
+ automatically (if the user agent is capable of doing so) or manually
+ by the user selecting from a generated (possibly hypertext) menu.
+
+ Agent-driven negotiation is advantageous when the response would vary
+ over commonly-used dimensions (such as type, language, or encoding),
+ when the origin server is unable to determine a user agent's
+ capabilities from examining the request, and generally when public
+ caches are used to distribute server load and reduce network usage.
+
+
+
+Fielding, et. al. Standards Track [Page 69]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Agent-driven negotiation suffers from the disadvantage of needing a
+ second request to obtain the best alternate representation. This
+ second request is only efficient when caching is used. In addition,
+ this specification does not define any mechanism for supporting
+ automatic selection, though it also does not prevent any such
+ mechanism from being developed as an extension and used within
+ HTTP/1.1.
+
+ HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+ status codes for enabling agent-driven negotiation when the server is
+ unwilling or unable to provide a varying response using server-driven
+ negotiation.
+
+12.3 Transparent Negotiation
+
+ Transparent negotiation is a combination of both server-driven and
+ agent-driven negotiation. When a cache is supplied with a form of the
+ list of available representations of the response (as in agent-driven
+ negotiation) and the dimensions of variance are completely understood
+ by the cache, then the cache becomes capable of performing server-
+ driven negotiation on behalf of the origin server for subsequent
+ requests on that resource.
+
+ Transparent negotiation has the advantage of distributing the
+ negotiation work that would otherwise be required of the origin
+ server and also removing the second request delay of agent-driven
+ negotiation when the cache is able to correctly guess the right
+ response.
+
+ This specification does not define any mechanism for transparent
+ negotiation, though it also does not prevent any such mechanism from
+ being developed as an extension and used within HTTP/1.1. An HTTP/1.1
+ cache performing transparent negotiation MUST include a Vary header
+ field in the response (defining the dimensions of its variance) if it
+ is cachable to ensure correct interoperation with all HTTP/1.1
+ clients. The agent-driven negotiation information supplied by the
+ origin server SHOULD be included with the transparently negotiated
+ response.
+
+13 Caching in HTTP
+
+ HTTP is typically used for distributed information systems, where
+ performance can be improved by the use of response caches. The
+ HTTP/1.1 protocol includes a number of elements intended to make
+ caching work as well as possible. Because these elements are
+ inextricable from other aspects of the protocol, and because they
+ interact with each other, it is useful to describe the basic caching
+ design of HTTP separately from the detailed descriptions of methods,
+
+
+
+Fielding, et. al. Standards Track [Page 70]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ headers, response codes, etc.
+
+ Caching would be useless if it did not significantly improve
+ performance. The goal of caching in HTTP/1.1 is to eliminate the need
+ to send requests in many cases, and to eliminate the need to send
+ full responses in many other cases. The former reduces the number of
+ network round-trips required for many operations; we use an
+ "expiration" mechanism for this purpose (see section 13.2). The
+ latter reduces network bandwidth requirements; we use a "validation"
+ mechanism for this purpose (see section 13.3).
+
+ Requirements for performance, availability, and disconnected
+ operation require us to be able to relax the goal of semantic
+ transparency. The HTTP/1.1 protocol allows origin servers, caches,
+ and clients to explicitly reduce transparency when necessary.
+ However, because non-transparent operation may confuse non-expert
+ users, and may be incompatible with certain server applications (such
+ as those for ordering merchandise), the protocol requires that
+ transparency be relaxed
+
+ o only by an explicit protocol-level request when relaxed by client
+ or origin server
+
+ o only with an explicit warning to the end user when relaxed by cache
+ or client
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 71]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Therefore, the HTTP/1.1 protocol provides these important elements:
+
+ 1. Protocol features that provide full semantic transparency when this
+ is required by all parties.
+
+ 2. Protocol features that allow an origin server or user agent to
+ explicitly request and control non-transparent operation.
+
+ 3. Protocol features that allow a cache to attach warnings to
+ responses that do not preserve the requested approximation of
+ semantic transparency.
+
+ A basic principle is that it must be possible for the clients to
+ detect any potential relaxation of semantic transparency.
+
+ Note: The server, cache, or client implementer may be faced with
+ design decisions not explicitly discussed in this specification. If
+ a decision may affect semantic transparency, the implementer ought
+ to err on the side of maintaining transparency unless a careful and
+ complete analysis shows significant benefits in breaking
+ transparency.
+
+13.1.1 Cache Correctness
+
+ A correct cache MUST respond to a request with the most up-to-date
+ response held by the cache that is appropriate to the request (see
+ sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+ conditions:
+
+ 1. It has been checked for equivalence with what the origin server
+ would have returned by revalidating the response with the origin
+ server (section 13.3);
+
+ 2. It is "fresh enough" (see section 13.2). In the default case, this
+ means it meets the least restrictive freshness requirement of the
+ client, server, and cache (see section 14.9); if the origin server
+ so specifies, it is the freshness requirement of the origin server
+ alone.
+
+ 3. It includes a warning if the freshness demand of the client or the
+ origin server is violated (see section 13.1.5 and 14.45).
+
+ 4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
+ error (4xx or 5xx) response message.
+
+ If the cache can not communicate with the origin server, then a
+ correct cache SHOULD respond as above if the response can be
+ correctly served from the cache; if not it MUST return an error or
+
+
+
+Fielding, et. al. Standards Track [Page 72]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ warning indicating that there was a communication failure.
+
+ If a cache receives a response (either an entire response, or a 304
+ (Not Modified) response) that it would normally forward to the
+ requesting client, and the received response is no longer fresh, the
+ cache SHOULD forward it to the requesting client without adding a new
+ Warning (but without removing any existing Warning headers). A cache
+ SHOULD NOT attempt to revalidate a response simply because that
+ response became stale in transit; this might lead to an infinite
+ loop. An user agent that receives a stale response without a Warning
+ MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+ Whenever a cache returns a response that is neither first-hand nor
+ "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+ must attach a warning to that effect, using a Warning response-
+ header. This warning allows clients to take appropriate action.
+
+ Warnings may be used for other purposes, both cache-related and
+ otherwise. The use of a warning, rather than an error status code,
+ distinguish these responses from true failures.
+
+ Warnings are always cachable, because they never weaken the
+ transparency of a response. This means that warnings can be passed to
+ HTTP/1.0 caches without danger; such caches will simply pass the
+ warning along as an entity-header in the response.
+
+ Warnings are assigned numbers between 0 and 99. This specification
+ defines the code numbers and meanings of each currently assigned
+ warnings, allowing a client or cache to take automated action in some
+ (but not all) cases.
+
+ Warnings also carry a warning text. The text may be in any
+ appropriate natural language (perhaps based on the client's Accept
+ headers), and include an optional indication of what character set is
+ used.
+
+ Multiple warnings may be attached to a response (either by the origin
+ server or by a cache), including multiple warnings with the same code
+ number. For example, a server may provide the same warning with texts
+ in both English and Basque.
+
+ When multiple warnings are attached to a response, it may not be
+ practical or reasonable to display all of them to the user. This
+ version of HTTP does not specify strict priority rules for deciding
+ which warnings to display and in what order, but does suggest some
+ heuristics.
+
+
+
+Fielding, et. al. Standards Track [Page 73]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The Warning header and the currently defined warnings are described
+ in section 14.45.
+
+13.1.3 Cache-control Mechanisms
+
+ The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+ times and validators) are implicit directives to caches. In some
+ cases, a server or client may need to provide explicit directives to
+ the HTTP caches. We use the Cache-Control header for this purpose.
+
+ The Cache-Control header allows a client or server to transmit a
+ variety of directives in either requests or responses. These
+ directives typically override the default caching algorithms. As a
+ general rule, if there is any apparent conflict between header
+ values, the most restrictive interpretation should be applied (that
+ is, the one that is most likely to preserve semantic transparency).
+ However, in some cases, Cache-Control directives are explicitly
+ specified as weakening the approximation of semantic transparency
+ (for example, "max-stale" or "public").
+
+ The Cache-Control directives are described in detail in section 14.9.
+
+13.1.4 Explicit User Agent Warnings
+
+ Many user agents make it possible for users to override the basic
+ caching mechanisms. For example, the user agent may allow the user to
+ specify that cached entities (even explicitly stale ones) are never
+ validated. Or the user agent might habitually add "Cache-Control:
+ max-stale=3600" to every request. The user should have to explicitly
+ request either non-transparent behavior, or behavior that results in
+ abnormally ineffective caching.
+
+ If the user has overridden the basic caching mechanisms, the user
+ agent should explicitly indicate to the user whenever this results in
+ the display of information that might not meet the server's
+ transparency requirements (in particular, if the displayed entity is
+ known to be stale). Since the protocol normally allows the user agent
+ to determine if responses are stale or not, this indication need only
+ be displayed when this actually happens. The indication need not be a
+ dialog box; it could be an icon (for example, a picture of a rotting
+ fish) or some other visual indicator.
+
+ If the user has overridden the caching mechanisms in a way that would
+ abnormally reduce the effectiveness of caches, the user agent should
+ continually display an indication (for example, a picture of currency
+ in flames) so that the user does not inadvertently consume excess
+ resources or suffer from excessive latency.
+
+
+
+
+Fielding, et. al. Standards Track [Page 74]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+13.1.5 Exceptions to the Rules and Warnings
+
+ In some cases, the operator of a cache may choose to configure it to
+ return stale responses even when not requested by clients. This
+ decision should not be made lightly, but may be necessary for reasons
+ of availability or performance, especially when the cache is poorly
+ connected to the origin server. Whenever a cache returns a stale
+ response, it MUST mark it as such (using a Warning header). This
+ allows the client software to alert the user that there may be a
+ potential problem.
+
+ It also allows the user agent to take steps to obtain a first-hand or
+ fresh response. For this reason, a cache SHOULD NOT return a stale
+ response if the client explicitly requests a first-hand or fresh one,
+ unless it is impossible to comply for technical or policy reasons.
+
+13.1.6 Client-controlled Behavior
+
+ While the origin server (and to a lesser extent, intermediate caches,
+ by their contribution to the age of a response) are the primary
+ source of expiration information, in some cases the client may need
+ to control a cache's decision about whether to return a cached
+ response without validating it. Clients do this using several
+ directives of the Cache-Control header.
+
+ A client's request may specify the maximum age it is willing to
+ accept of an unvalidated response; specifying a value of zero forces
+ the cache(s) to revalidate all responses. A client may also specify
+ the minimum time remaining before a response expires. Both of these
+ options increase constraints on the behavior of caches, and so cannot
+ further relax the cache's approximation of semantic transparency.
+
+ A client may also specify that it will accept stale responses, up to
+ some maximum amount of staleness. This loosens the constraints on the
+ caches, and so may violate the origin server's specified constraints
+ on semantic transparency, but may be necessary to support
+ disconnected operation, or high availability in the face of poor
+ connectivity.
+
+13.2 Expiration Model
+
+13.2.1 Server-Specified Expiration
+
+ HTTP caching works best when caches can entirely avoid making
+ requests to the origin server. The primary mechanism for avoiding
+ requests is for an origin server to provide an explicit expiration
+ time in the future, indicating that a response may be used to satisfy
+ subsequent requests. In other words, a cache can return a fresh
+
+
+
+Fielding, et. al. Standards Track [Page 75]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ response without first contacting the server.
+
+ Our expectation is that servers will assign future explicit
+ expiration times to responses in the belief that the entity is not
+ likely to change, in a semantically significant way, before the
+ expiration time is reached. This normally preserves semantic
+ transparency, as long as the server's expiration times are carefully
+ chosen.
+
+ The expiration mechanism applies only to responses taken from a cache
+ and not to first-hand responses forwarded immediately to the
+ requesting client.
+
+ If an origin server wishes to force a semantically transparent cache
+ to validate every request, it may assign an explicit expiration time
+ in the past. This means that the response is always stale, and so the
+ cache SHOULD validate it before using it for subsequent requests. See
+ section 14.9.4 for a more restrictive way to force revalidation.
+
+ If an origin server wishes to force any HTTP/1.1 cache, no matter how
+ it is configured, to validate every request, it should use the
+ "must-revalidate" Cache-Control directive (see section 14.9).
+
+ Servers specify explicit expiration times using either the Expires
+ header, or the max-age directive of the Cache-Control header.
+
+ An expiration time cannot be used to force a user agent to refresh
+ its display or reload a resource; its semantics apply only to caching
+ mechanisms, and such mechanisms need only check a resource's
+ expiration status when a new request for that resource is initiated.
+ See section 13.13 for explanation of the difference between caches
+ and history mechanisms.
+
+13.2.2 Heuristic Expiration
+
+ Since origin servers do not always provide explicit expiration times,
+ HTTP caches typically assign heuristic expiration times, employing
+ algorithms that use other header values (such as the Last-Modified
+ time) to estimate a plausible expiration time. The HTTP/1.1
+ specification does not provide specific algorithms, but does impose
+ worst-case constraints on their results. Since heuristic expiration
+ times may compromise semantic transparency, they should be used
+ cautiously, and we encourage origin servers to provide explicit
+ expiration times as much as possible.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 76]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+13.2.3 Age Calculations
+
+ In order to know if a cached entry is fresh, a cache needs to know if
+ its age exceeds its freshness lifetime. We discuss how to calculate
+ the latter in section 13.2.4; this section describes how to calculate
+ the age of a response or cache entry.
+
+ In this discussion, we use the term "now" to mean "the current value
+ of the clock at the host performing the calculation." Hosts that use
+ HTTP, but especially hosts running origin servers and caches, should
+ use NTP [28] or some similar protocol to synchronize their clocks to
+ a globally accurate time standard.
+
+ Also note that HTTP/1.1 requires origin servers to send a Date header
+ with every response, giving the time at which the response was
+ generated. We use the term "date_value" to denote the value of the
+ Date header, in a form appropriate for arithmetic operations.
+
+ HTTP/1.1 uses the Age response-header to help convey age information
+ between caches. The Age header value is the sender's estimate of the
+ amount of time since the response was generated at the origin server.
+ In the case of a cached response that has been revalidated with the
+ origin server, the Age value is based on the time of revalidation,
+ not of the original response.
+
+ In essence, the Age value is the sum of the time that the response
+ has been resident in each of the caches along the path from the
+ origin server, plus the amount of time it has been in transit along
+ network paths.
+
+ We use the term "age_value" to denote the value of the Age header, in
+ a form appropriate for arithmetic operations.
+
+ A response's age can be calculated in two entirely independent ways:
+
+ 1. now minus date_value, if the local clock is reasonably well
+ synchronized to the origin server's clock. If the result is
+ negative, the result is replaced by zero.
+
+ 2. age_value, if all of the caches along the response path
+ implement HTTP/1.1.
+
+ Given that we have two independent ways to compute the age of a
+ response when it is received, we can combine these as
+
+ corrected_received_age = max(now - date_value, age_value)
+
+ and as long as we have either nearly synchronized clocks or all-
+
+
+
+Fielding, et. al. Standards Track [Page 77]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ HTTP/1.1 paths, one gets a reliable (conservative) result.
+
+ Note that this correction is applied at each HTTP/1.1 cache along the
+ path, so that if there is an HTTP/1.0 cache in the path, the correct
+ received age is computed as long as the receiving cache's clock is
+ nearly in sync. We don't need end-to-end clock synchronization
+ (although it is good to have), and there is no explicit clock
+ synchronization step.
+
+ Because of network-imposed delays, some significant interval may pass
+ from the time that a server generates a response and the time it is
+ received at the next outbound cache or client. If uncorrected, this
+ delay could result in improperly low ages.
+
+ Because the request that resulted in the returned Age value must have
+ been initiated prior to that Age value's generation, we can correct
+ for delays imposed by the network by recording the time at which the
+ request was initiated. Then, when an Age value is received, it MUST
+ be interpreted relative to the time the request was initiated, not
+ the time that the response was received. This algorithm results in
+ conservative behavior no matter how much delay is experienced. So, we
+ compute:
+
+ corrected_initial_age = corrected_received_age
+ + (now - request_time)
+
+ where "request_time" is the time (according to the local clock) when
+ the request that elicited this response was sent.
+
+ Summary of age calculation algorithm, when a cache receives a
+ response:
+
+ /*
+ * age_value
+ * is the value of Age: header received by the cache with
+ * this response.
+ * date_value
+ * is the value of the origin server's Date: header
+ * request_time
+ * is the (local) time when the cache made the request
+ * that resulted in this cached response
+ * response_time
+ * is the (local) time when the cache received the
+ * response
+ * now
+ * is the current (local) time
+ */
+ apparent_age = max(0, response_time - date_value);
+
+
+
+Fielding, et. al. Standards Track [Page 78]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ corrected_received_age = max(apparent_age, age_value);
+ response_delay = response_time - request_time;
+ corrected_initial_age = corrected_received_age + response_delay;
+ resident_time = now - response_time;
+ current_age = corrected_initial_age + resident_time;
+
+ When a cache sends a response, it must add to the
+ corrected_initial_age the amount of time that the response was
+ resident locally. It must then transmit this total age, using the Age
+ header, to the next recipient cache.
+
+ Note that a client cannot reliably tell that a response is first-
+ hand, but the presence of an Age header indicates that a response
+ is definitely not first-hand. Also, if the Date in a response is
+ earlier than the client's local request time, the response is
+ probably not first-hand (in the absence of serious clock skew).
+
+13.2.4 Expiration Calculations
+
+ In order to decide whether a response is fresh or stale, we need to
+ compare its freshness lifetime to its age. The age is calculated as
+ described in section 13.2.3; this section describes how to calculate
+ the freshness lifetime, and to determine if a response has expired.
+ In the discussion below, the values can be represented in any form
+ appropriate for arithmetic operations.
+
+ We use the term "expires_value" to denote the value of the Expires
+ header. We use the term "max_age_value" to denote an appropriate
+ value of the number of seconds carried by the max-age directive of
+ the Cache-Control header in a response (see section 14.10.
+
+ The max-age directive takes priority over Expires, so if max-age is
+ present in a response, the calculation is simply:
+
+ freshness_lifetime = max_age_value
+
+ Otherwise, if Expires is present in the response, the calculation is:
+
+ freshness_lifetime = expires_value - date_value
+
+ Note that neither of these calculations is vulnerable to clock skew,
+ since all of the information comes from the origin server.
+
+ If neither Expires nor Cache-Control: max-age appears in the
+ response, and the response does not include other restrictions on
+ caching, the cache MAY compute a freshness lifetime using a
+ heuristic. If the value is greater than 24 hours, the cache must
+ attach Warning 13 to any response whose age is more than 24 hours if
+
+
+
+Fielding, et. al. Standards Track [Page 79]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ such warning has not already been added.
+
+ Also, if the response does have a Last-Modified time, the heuristic
+ expiration value SHOULD be no more than some fraction of the interval
+ since that time. A typical setting of this fraction might be 10%.
+
+ The calculation to determine if a response has expired is quite
+ simple:
+
+ response_is_fresh = (freshness_lifetime > current_age)
+
+13.2.5 Disambiguating Expiration Values
+
+ Because expiration values are assigned optimistically, it is possible
+ for two caches to contain fresh values for the same resource that are
+ different.
+
+ If a client performing a retrieval receives a non-first-hand response
+ for a request that was already fresh in its own cache, and the Date
+ header in its existing cache entry is newer than the Date on the new
+ response, then the client MAY ignore the response. If so, it MAY
+ retry the request with a "Cache-Control: max-age=0" directive (see
+ section 14.9), to force a check with the origin server.
+
+ If a cache has two fresh responses for the same representation with
+ different validators, it MUST use the one with the more recent Date
+ header. This situation may arise because the cache is pooling
+ responses from other caches, or because a client has asked for a
+ reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+ Because a client may be receiving responses via multiple paths, so
+ that some responses flow through one set of caches and other
+ responses flow through a different set of caches, a client may
+ receive responses in an order different from that in which the origin
+ server sent them. We would like the client to use the most recently
+ generated response, even if older responses are still apparently
+ fresh.
+
+ Neither the entity tag nor the expiration value can impose an
+ ordering on responses, since it is possible that a later response
+ intentionally carries an earlier expiration time. However, the
+ HTTP/1.1 specification requires the transmission of Date headers on
+ every response, and the Date values are ordered to a granularity of
+ one second.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 80]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ When a client tries to revalidate a cache entry, and the response it
+ receives contains a Date header that appears to be older than the one
+ for the existing entry, then the client SHOULD repeat the request
+ unconditionally, and include
+
+ Cache-Control: max-age=0
+
+ to force any intermediate caches to validate their copies directly
+ with the origin server, or
+
+ Cache-Control: no-cache
+
+ to force any intermediate caches to obtain a new copy from the origin
+ server.
+
+ If the Date values are equal, then the client may use either response
+ (or may, if it is being extremely prudent, request a new response).
+ Servers MUST NOT depend on clients being able to choose
+ deterministically between responses generated during the same second,
+ if their expiration times overlap.
+
+13.3 Validation Model
+
+ When a cache has a stale entry that it would like to use as a
+ response to a client's request, it first has to check with the origin
+ server (or possibly an intermediate cache with a fresh response) to
+ see if its cached entry is still usable. We call this "validating"
+ the cache entry. Since we do not want to have to pay the overhead of
+ retransmitting the full response if the cached entry is good, and we
+ do not want to pay the overhead of an extra round trip if the cached
+ entry is invalid, the HTTP/1.1 protocol supports the use of
+ conditional methods.
+
+ The key protocol features for supporting conditional methods are
+ those concerned with "cache validators." When an origin server
+ generates a full response, it attaches some sort of validator to it,
+ which is kept with the cache entry. When a client (user agent or
+ proxy cache) makes a conditional request for a resource for which it
+ has a cache entry, it includes the associated validator in the
+ request.
+
+ The server then checks that validator against the current validator
+ for the entity, and, if they match, it responds with a special status
+ code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
+ returns a full response (including entity-body). Thus, we avoid
+ transmitting the full response if the validator matches, and we avoid
+ an extra round trip if it does not match.
+
+
+
+
+Fielding, et. al. Standards Track [Page 81]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Note: the comparison functions used to decide if validators match
+ are defined in section 13.3.3.
+
+ In HTTP/1.1, a conditional request looks exactly the same as a normal
+ request for the same resource, except that it carries a special
+ header (which includes the validator) that implicitly turns the
+ method (usually, GET) into a conditional.
+
+ The protocol includes both positive and negative senses of cache-
+ validating conditions. That is, it is possible to request either that
+ a method be performed if and only if a validator matches or if and
+ only if no validators match.
+
+ Note: a response that lacks a validator may still be cached, and
+ served from cache until it expires, unless this is explicitly
+ prohibited by a Cache-Control directive. However, a cache cannot do
+ a conditional retrieval if it does not have a validator for the
+ entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-modified Dates
+
+ The Last-Modified entity-header field value is often used as a cache
+ validator. In simple terms, a cache entry is considered to be valid
+ if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+ The ETag entity-header field value, an entity tag, provides for an
+ "opaque" cache validator. This may allow more reliable validation in
+ situations where it is inconvenient to store modification dates,
+ where the one-second resolution of HTTP date values is not
+ sufficient, or where the origin server wishes to avoid certain
+ paradoxes that may arise from the use of modification dates.
+
+ Entity Tags are described in section 3.11. The headers used with
+ entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.
+
+13.3.3 Weak and Strong Validators
+
+ Since both origin servers and caches will compare two validators to
+ decide if they represent the same or different entities, one normally
+ would expect that if the entity (the entity-body or any entity-
+ headers) changes in any way, then the associated validator would
+ change as well. If this is true, then we call this validator a
+ "strong validator."
+
+ However, there may be cases when a server prefers to change the
+ validator only on semantically significant changes, and not when
+
+
+
+Fielding, et. al. Standards Track [Page 82]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ insignificant aspects of the entity change. A validator that does not
+ always change when the resource changes is a "weak validator."
+
+ Entity tags are normally "strong validators," but the protocol
+ provides a mechanism to tag an entity tag as "weak." One can think of
+ a strong validator as one that changes whenever the bits of an entity
+ changes, while a weak value changes whenever the meaning of an entity
+ changes. Alternatively, one can think of a strong validator as part
+ of an identifier for a specific entity, while a weak validator is
+ part of an identifier for a set of semantically equivalent entities.
+
+ Note: One example of a strong validator is an integer that is
+ incremented in stable storage every time an entity is changed.
+
+ An entity's modification time, if represented with one-second
+ resolution, could be a weak validator, since it is possible that
+ the resource may be modified twice during a single second.
+
+ Support for weak validators is optional; however, weak validators
+ allow for more efficient caching of equivalent objects; for
+ example, a hit counter on a site is probably good enough if it is
+ updated every few days or weeks, and any value during that period
+ is likely "good enough" to be equivalent.
+
+ A "use" of a validator is either when a client generates a request
+ and includes the validator in a validating header field, or when a
+ server compares two validators.
+
+ Strong validators are usable in any context. Weak validators are only
+ usable in contexts that do not depend on exact equality of an entity.
+ For example, either kind is usable for a conditional GET of a full
+ entity. However, only a strong validator is usable for a sub-range
+ retrieval, since otherwise the client may end up with an internally
+ inconsistent entity.
+
+ The only function that the HTTP/1.1 protocol defines on validators is
+ comparison. There are two validator comparison functions, depending
+ on whether the comparison context allows the use of weak validators
+ or not:
+
+ o The strong comparison function: in order to be considered equal,
+ both validators must be identical in every way, and neither may be
+ weak.
+ o The weak comparison function: in order to be considered equal, both
+ validators must be identical in every way, but either or both of
+ them may be tagged as "weak" without affecting the result.
+
+ The weak comparison function MAY be used for simple (non-subrange)
+
+
+
+Fielding, et. al. Standards Track [Page 83]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ GET requests. The strong comparison function MUST be used in all
+ other cases.
+
+ An entity tag is strong unless it is explicitly tagged as weak.
+ Section 3.11 gives the syntax for entity tags.
+
+ A Last-Modified time, when used as a validator in a request, is
+ implicitly weak unless it is possible to deduce that it is strong,
+ using the following rules:
+
+ o The validator is being compared by an origin server to the actual
+ current validator for the entity and,
+ o That origin server reliably knows that the associated entity did
+ not change twice during the second covered by the presented
+ validator.
+or
+
+ o The validator is about to be used by a client in an If-Modified-
+ Since or If-Unmodified-Since header, because the client has a cache
+ entry for the associated entity, and
+ o That cache entry includes a Date value, which gives the time when
+ the origin server sent the original response, and
+ o The presented Last-Modified time is at least 60 seconds before the
+ Date value.
+or
+
+ o The validator is being compared by an intermediate cache to the
+ validator stored in its cache entry for the entity, and
+ o That cache entry includes a Date value, which gives the time when
+ the origin server sent the original response, and
+ o The presented Last-Modified time is at least 60 seconds before the
+ Date value.
+
+ This method relies on the fact that if two different responses were
+ sent by the origin server during the same second, but both had the
+ same Last-Modified time, then at least one of those responses would
+ have a Date value equal to its Last-Modified time. The arbitrary 60-
+ second limit guards against the possibility that the Date and Last-
+ Modified values are generated from different clocks, or at somewhat
+ different times during the preparation of the response. An
+ implementation may use a value larger than 60 seconds, if it is
+ believed that 60 seconds is too short.
+
+ If a client wishes to perform a sub-range retrieval on a value for
+ which it has only a Last-Modified time and no opaque validator, it
+ may do this only if the Last-Modified time is strong in the sense
+ described here.
+
+
+
+
+Fielding, et. al. Standards Track [Page 84]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ A cache or origin server receiving a cache-conditional request, other
+ than a full-body GET request, MUST use the strong comparison function
+ to evaluate the condition.
+
+ These rules allow HTTP/1.1 caches and clients to safely perform sub-
+ range retrievals on values that have been obtained from HTTP/1.0
+ servers.
+
+13.3.4 Rules for When to Use Entity Tags and Last-modified Dates
+
+ We adopt a set of rules and recommendations for origin servers,
+ clients, and caches regarding when various validator types should be
+ used, and for what purposes.
+
+ HTTP/1.1 origin servers:
+
+ o SHOULD send an entity tag validator unless it is not feasible to
+ generate one.
+ o MAY send a weak entity tag instead of a strong entity tag, if
+ performance considerations support the use of weak entity tags, or
+ if it is unfeasible to send a strong entity tag.
+ o SHOULD send a Last-Modified value if it is feasible to send one,
+ unless the risk of a breakdown in semantic transparency that could
+ result from using this date in an If-Modified-Since header would
+ lead to serious problems.
+
+ In other words, the preferred behavior for an HTTP/1.1 origin server
+ is to send both a strong entity tag and a Last-Modified value.
+
+ In order to be legal, a strong entity tag MUST change whenever the
+ associated entity value changes in any way. A weak entity tag SHOULD
+ change whenever the associated entity changes in a semantically
+ significant way.
+
+ Note: in order to provide semantically transparent caching, an
+ origin server must avoid reusing a specific strong entity tag value
+ for two different entities, or reusing a specific weak entity tag
+ value for two semantically different entities. Cache entries may
+ persist for arbitrarily long periods, regardless of expiration
+ times, so it may be inappropriate to expect that a cache will never
+ again attempt to validate an entry using a validator that it
+ obtained at some point in the past.
+
+ HTTP/1.1 clients:
+
+ o If an entity tag has been provided by the origin server, MUST
+ use that entity tag in any cache-conditional request (using
+ If-Match or If-None-Match).
+
+
+
+Fielding, et. al. Standards Track [Page 85]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ o If only a Last-Modified value has been provided by the origin
+ server, SHOULD use that value in non-subrange cache-conditional
+ requests (using If-Modified-Since).
+ o If only a Last-Modified value has been provided by an HTTP/1.0
+ origin server, MAY use that value in subrange cache-conditional
+ requests (using If-Unmodified-Since:). The user agent should
+ provide a way to disable this, in case of difficulty.
+ o If both an entity tag and a Last-Modified value have been
+ provided by the origin server, SHOULD use both validators in
+ cache-conditional requests. This allows both HTTP/1.0 and
+ HTTP/1.1 caches to respond appropriately.
+
+ An HTTP/1.1 cache, upon receiving a request, MUST use the most
+ restrictive validator when deciding whether the client's cache entry
+ matches the cache's own cache entry. This is only an issue when the
+ request contains both an entity tag and a last-modified-date
+ validator (If-Modified-Since or If-Unmodified-Since).
+
+ A note on rationale: The general principle behind these rules is
+ that HTTP/1.1 servers and clients should transmit as much non-
+ redundant information as is available in their responses and
+ requests. HTTP/1.1 systems receiving this information will make the
+ most conservative assumptions about the validators they receive.
+
+ HTTP/1.0 clients and caches will ignore entity tags. Generally,
+ last-modified values received or used by these systems will support
+ transparent and efficient caching, and so HTTP/1.1 origin servers
+ should provide Last-Modified values. In those rare cases where the
+ use of a Last-Modified value as a validator by an HTTP/1.0 system
+ could result in a serious problem, then HTTP/1.1 origin servers
+ should not provide one.
+
+13.3.5 Non-validating Conditionals
+
+ The principle behind entity tags is that only the service author
+ knows the semantics of a resource well enough to select an
+ appropriate cache validation mechanism, and the specification of any
+ validator comparison function more complex than byte-equality would
+ open up a can of worms. Thus, comparisons of any other headers
+ (except Last-Modified, for compatibility with HTTP/1.0) are never
+ used for purposes of validating a cache entry.
+
+13.4 Response Cachability
+
+ Unless specifically constrained by a Cache-Control (section 14.9)
+ directive, a caching system may always store a successful response
+ (see section 13.8) as a cache entry, may return it without validation
+ if it is fresh, and may return it after successful validation. If
+
+
+
+Fielding, et. al. Standards Track [Page 86]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ there is neither a cache validator nor an explicit expiration time
+ associated with a response, we do not expect it to be cached, but
+ certain caches may violate this expectation (for example, when little
+ or no network connectivity is available). A client can usually detect
+ that such a response was taken from a cache by comparing the Date
+ header to the current time.
+
+ Note that some HTTP/1.0 caches are known to violate this
+ expectation without providing any Warning.
+
+ However, in some cases it may be inappropriate for a cache to retain
+ an entity, or to return it in response to a subsequent request. This
+ may be because absolute semantic transparency is deemed necessary by
+ the service author, or because of security or privacy considerations.
+ Certain Cache-Control directives are therefore provided so that the
+ server can indicate that certain resource entities, or portions
+ thereof, may not be cached regardless of other considerations.
+
+ Note that section 14.8 normally prevents a shared cache from saving
+ and returning a response to a previous request if that request
+ included an Authorization header.
+
+ A response received with a status code of 200, 203, 206, 300, 301 or
+ 410 may be stored by a cache and used in reply to a subsequent
+ request, subject to the expiration mechanism, unless a Cache-Control
+ directive prohibits caching. However, a cache that does not support
+ the Range and Content-Range headers MUST NOT cache 206 (Partial
+ Content) responses.
+
+ A response received with any other status code MUST NOT be returned
+ in a reply to a subsequent request unless there are Cache-Control
+ directives or another header(s) that explicitly allow it. For
+ example, these include the following: an Expires header (section
+ 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
+ or "private" Cache-Control directive (section 14.9).
+
+13.5 Constructing Responses From Caches
+
+ The purpose of an HTTP cache is to store information received in
+ response to requests, for use in responding to future requests. In
+ many cases, a cache simply returns the appropriate parts of a
+ response to the requester. However, if the cache holds a cache entry
+ based on a previous response, it may have to combine parts of a new
+ response with what is held in the cache entry.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 87]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+13.5.1 End-to-end and Hop-by-hop Headers
+
+ For the purpose of defining the behavior of caches and non-caching
+ proxies, we divide HTTP headers into two categories:
+
+ o End-to-end headers, which must be transmitted to the
+ ultimate recipient of a request or response. End-to-end
+ headers in responses must be stored as part of a cache entry
+ and transmitted in any response formed from a cache entry.
+ o Hop-by-hop headers, which are meaningful only for a single
+ transport-level connection, and are not stored by caches or
+ forwarded by proxies.
+
+ The following HTTP/1.1 headers are hop-by-hop headers:
+
+ o Connection
+ o Keep-Alive
+ o Public
+ o Proxy-Authenticate
+ o Transfer-Encoding
+ o Upgrade
+
+ All other headers defined by HTTP/1.1 are end-to-end headers.
+
+ Hop-by-hop headers introduced in future versions of HTTP MUST be
+ listed in a Connection header, as described in section 14.10.
+
+13.5.2 Non-modifiable Headers
+
+ Some features of the HTTP/1.1 protocol, such as Digest
+ Authentication, depend on the value of certain end-to-end headers. A
+ cache or non-caching proxy SHOULD NOT modify an end-to-end header
+ unless the definition of that header requires or specifically allows
+ that.
+
+ A cache or non-caching proxy MUST NOT modify any of the following
+ fields in a request or response, nor may it add any of these fields
+ if not already present:
+
+ o Content-Location
+ o ETag
+ o Expires
+ o Last-Modified
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 88]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ A cache or non-caching proxy MUST NOT modify or add any of the
+ following fields in a response that contains the no-transform Cache-
+ Control directive, or in any request:
+
+ o Content-Encoding
+ o Content-Length
+ o Content-Range
+ o Content-Type
+
+ A cache or non-caching proxy MAY modify or add these fields in a
+ response that does not include no-transform, but if it does so, it
+ MUST add a Warning 14 (Transformation applied) if one does not
+ already appear in the response.
+
+ Warning: unnecessary modification of end-to-end headers may cause
+ authentication failures if stronger authentication mechanisms are
+ introduced in later versions of HTTP. Such authentication
+ mechanisms may rely on the values of header fields not listed here.
+
+13.5.3 Combining Headers
+
+ When a cache makes a validating request to a server, and the server
+ provides a 304 (Not Modified) response, the cache must construct a
+ response to send to the requesting client. The cache uses the
+ entity-body stored in the cache entry as the entity-body of this
+ outgoing response. The end-to-end headers stored in the cache entry
+ are used for the constructed response, except that any end-to-end
+ headers provided in the 304 response MUST replace the corresponding
+ headers from the cache entry. Unless the cache decides to remove the
+ cache entry, it MUST also replace the end-to-end headers stored with
+ the cache entry with corresponding headers received in the incoming
+ response.
+
+ In other words, the set of end-to-end headers received in the
+ incoming response overrides all corresponding end-to-end headers
+ stored with the cache entry. The cache may add Warning headers (see
+ section 14.45) to this set.
+
+ If a header field-name in the incoming response matches more than one
+ header in the cache entry, all such old headers are replaced.
+
+ Note: this rule allows an origin server to use a 304 (Not Modified)
+ response to update any header associated with a previous response
+ for the same entity, although it might not always be meaningful or
+ correct to do so. This rule does not allow an origin server to use
+ a 304 (not Modified) response to entirely delete a header that it
+ had provided with a previous response.
+
+
+
+
+Fielding, et. al. Standards Track [Page 89]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+13.5.4 Combining Byte Ranges
+
+ A response may transfer only a subrange of the bytes of an entity-
+ body, either because the request included one or more Range
+ specifications, or because a connection was broken prematurely. After
+ several such transfers, a cache may have received several ranges of
+ the same entity-body.
+
+ If a cache has a stored non-empty set of subranges for an entity, and
+ an incoming response transfers another subrange, the cache MAY
+ combine the new subrange with the existing set if both the following
+ conditions are met:
+
+ o Both the incoming response and the cache entry must have a cache
+ validator.
+ o The two cache validators must match using the strong comparison
+ function (see section 13.3.3).
+
+ If either requirement is not meant, the cache must use only the most
+ recent partial response (based on the Date values transmitted with
+ every response, and using the incoming response if these values are
+ equal or missing), and must discard the other partial information.
+
+13.6 Caching Negotiated Responses
+
+ Use of server-driven content negotiation (section 12), as indicated
+ by the presence of a Vary header field in a response, alters the
+ conditions and procedure by which a cache can use the response for
+ subsequent requests.
+
+ A server MUST use the Vary header field (section 14.43) to inform a
+ cache of what header field dimensions are used to select among
+ multiple representations of a cachable response. A cache may use the
+ selected representation (the entity included with that particular
+ response) for replying to subsequent requests on that resource only
+ when the subsequent requests have the same or equivalent values for
+ all header fields specified in the Vary response-header. Requests
+ with a different value for one or more of those header fields would
+ be forwarded toward the origin server.
+
+ If an entity tag was assigned to the representation, the forwarded
+ request SHOULD be conditional and include the entity tags in an If-
+ None-Match header field from all its cache entries for the Request-
+ URI. This conveys to the server the set of entities currently held by
+ the cache, so that if any one of these entities matches the requested
+ entity, the server can use the ETag header in its 304 (Not Modified)
+ response to tell the cache which entry is appropriate. If the
+ entity-tag of the new response matches that of an existing entry, the
+
+
+
+Fielding, et. al. Standards Track [Page 90]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ new response SHOULD be used to update the header fields of the
+ existing entry, and the result MUST be returned to the client.
+
+ The Vary header field may also inform the cache that the
+ representation was selected using criteria not limited to the
+ request-headers; in this case, a cache MUST NOT use the response in a
+ reply to a subsequent request unless the cache relays the new request
+ to the origin server in a conditional request and the server responds
+ with 304 (Not Modified), including an entity tag or Content-Location
+ that indicates which entity should be used.
+
+ If any of the existing cache entries contains only partial content
+ for the associated entity, its entity-tag SHOULD NOT be included in
+ the If-None-Match header unless the request is for a range that would
+ be fully satisfied by that entry.
+
+ If a cache receives a successful response whose Content-Location
+ field matches that of an existing cache entry for the same Request-
+ URI, whose entity-tag differs from that of the existing entry, and
+ whose Date is more recent than that of the existing entry, the
+ existing entry SHOULD NOT be returned in response to future requests,
+ and should be deleted from the cache.
+
+13.7 Shared and Non-Shared Caches
+
+ For reasons of security and privacy, it is necessary to make a
+ distinction between "shared" and "non-shared" caches. A non-shared
+ cache is one that is accessible only to a single user. Accessibility
+ in this case SHOULD be enforced by appropriate security mechanisms.
+ All other caches are considered to be "shared." Other sections of
+ this specification place certain constraints on the operation of
+ shared caches in order to prevent loss of privacy or failure of
+ access controls.
+
+13.8 Errors or Incomplete Response Cache Behavior
+
+ A cache that receives an incomplete response (for example, with fewer
+ bytes of data than specified in a Content-Length header) may store
+ the response. However, the cache MUST treat this as a partial
+ response. Partial responses may be combined as described in section
+ 13.5.4; the result might be a full response or might still be
+ partial. A cache MUST NOT return a partial response to a client
+ without explicitly marking it as such, using the 206 (Partial
+ Content) status code. A cache MUST NOT return a partial response
+ using a status code of 200 (OK).
+
+ If a cache receives a 5xx response while attempting to revalidate an
+ entry, it may either forward this response to the requesting client,
+
+
+
+Fielding, et. al. Standards Track [Page 91]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ or act as if the server failed to respond. In the latter case, it MAY
+ return a previously received response unless the cached entry
+ includes the "must-revalidate" Cache-Control directive (see section
+ 14.9).
+
+13.9 Side Effects of GET and HEAD
+
+ Unless the origin server explicitly prohibits the caching of their
+ responses, the application of GET and HEAD methods to any resources
+ SHOULD NOT have side effects that would lead to erroneous behavior if
+ these responses are taken from a cache. They may still have side
+ effects, but a cache is not required to consider such side effects in
+ its caching decisions. Caches are always expected to observe an
+ origin server's explicit restrictions on caching.
+
+ We note one exception to this rule: since some applications have
+ traditionally used GETs and HEADs with query URLs (those containing a
+ "?" in the rel_path part) to perform operations with significant side
+ effects, caches MUST NOT treat responses to such URLs as fresh unless
+ the server provides an explicit expiration time. This specifically
+ means that responses from HTTP/1.0 servers for such URIs should not
+ be taken from a cache. See section 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+ The effect of certain methods at the origin server may cause one or
+ more existing cache entries to become non-transparently invalid. That
+ is, although they may continue to be "fresh," they do not accurately
+ reflect what the origin server would return for a new request.
+
+ There is no way for the HTTP protocol to guarantee that all such
+ cache entries are marked invalid. For example, the request that
+ caused the change at the origin server may not have gone through the
+ proxy where a cache entry is stored. However, several rules help
+ reduce the likelihood of erroneous behavior.
+
+ In this section, the phrase "invalidate an entity" means that the
+ cache should either remove all instances of that entity from its
+ storage, or should mark these as "invalid" and in need of a mandatory
+ revalidation before they can be returned in response to a subsequent
+ request.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 92]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Some HTTP methods may invalidate an entity. This is either the entity
+ referred to by the Request-URI, or by the Location or Content-
+ Location response-headers (if present). These methods are:
+
+ o PUT
+ o DELETE
+ o POST
+
+ In order to prevent denial of service attacks, an invalidation based
+ on the URI in a Location or Content-Location header MUST only be
+ performed if the host part is the same as in the Request-URI.
+
+13.11 Write-Through Mandatory
+
+ All methods that may be expected to cause modifications to the origin
+ server's resources MUST be written through to the origin server. This
+ currently includes all methods except for GET and HEAD. A cache MUST
+ NOT reply to such a request from a client before having transmitted
+ the request to the inbound server, and having received a
+ corresponding response from the inbound server. This does not prevent
+ a cache from sending a 100 (Continue) response before the inbound
+ server has replied.
+
+ The alternative (known as "write-back" or "copy-back" caching) is not
+ allowed in HTTP/1.1, due to the difficulty of providing consistent
+ updates and the problems arising from server, cache, or network
+ failure prior to write-back.
+
+13.12 Cache Replacement
+
+ If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+ response is received from a resource while any existing responses for
+ the same resource are cached, the cache SHOULD use the new response
+ to reply to the current request. It may insert it into cache storage
+ and may, if it meets all other requirements, use it to respond to any
+ future requests that would previously have caused the old response to
+ be returned. If it inserts the new response into cache storage it
+ should follow the rules in section 13.5.3.
+
+ Note: a new response that has an older Date header value than
+ existing cached responses is not cachable.
+
+13.13 History Lists
+
+ User agents often have history mechanisms, such as "Back" buttons and
+ history lists, which can be used to redisplay an entity retrieved
+ earlier in a session.
+
+
+
+
+Fielding, et. al. Standards Track [Page 93]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ History mechanisms and caches are different. In particular history
+ mechanisms SHOULD NOT try to show a semantically transparent view of
+ the current state of a resource. Rather, a history mechanism is meant
+ to show exactly what the user saw at the time when the resource was
+ retrieved.
+
+ By default, an expiration time does not apply to history mechanisms.
+ If the entity is still in storage, a history mechanism should display
+ it even if the entity has expired, unless the user has specifically
+ configured the agent to refresh expired history documents.
+
+ This should not be construed to prohibit the history mechanism from
+ telling the user that a view may be stale.
+
+ Note: if history list mechanisms unnecessarily prevent users from
+ viewing stale resources, this will tend to force service authors to
+ avoid using HTTP expiration controls and cache controls when they
+ would otherwise like to. Service authors may consider it important
+ that users not be presented with error messages or warning messages
+ when they use navigation controls (such as BACK) to view previously
+ fetched resources. Even though sometimes such resources ought not
+ to cached, or ought to expire quickly, user interface
+ considerations may force service authors to resort to other means
+ of preventing caching (e.g. "once-only" URLs) in order not to
+ suffer the effects of improperly functioning history mechanisms.
+
+14 Header Field Definitions
+
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 94]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.1 Accept
+
+ The Accept request-header field can be used to specify certain media
+ types which are acceptable for the response. Accept headers can be
+ used to indicate that the request is specifically limited to a small
+ set of desired types, as in the case of a request for an in-line
+ image.
+
+ Accept = "Accept" ":"
+ #( media-range [ accept-params ] )
+
+ media-range = ( "*/*"
+ | ( type "/" "*" )
+ | ( type "/" subtype )
+ ) *( ";" parameter )
+
+ accept-params = ";" "q" "=" qvalue *( accept-extension )
+
+ accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+ The asterisk "*" character is used to group media types into ranges,
+ with "*/*" indicating all media types and "type/*" indicating all
+ subtypes of that type. The media-range MAY include media type
+ parameters that are applicable to that range.
+
+ Each media-range MAY be followed by one or more accept-params,
+ beginning with the "q" parameter for indicating a relative quality
+ factor. The first "q" parameter (if any) separates the media-range
+ parameter(s) from the accept-params. Quality factors allow the user
+ or user agent to indicate the relative degree of preference for that
+ media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+ default value is q=1.
+
+ Note: Use of the "q" parameter name to separate media type
+ parameters from Accept extension parameters is due to historical
+ practice. Although this prevents any media type parameter named
+ "q" from being used with a media range, such an event is believed
+ to be unlikely given the lack of any "q" parameters in the IANA
+ media type registry and the rare usage of any media type parameters
+ in Accept. Future media types should be discouraged from
+ registering any parameter named "q".
+
+ The example
+
+ Accept: audio/*; q=0.2, audio/basic
+
+ SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+ type if it is the best available after an 80% mark-down in quality."
+
+
+
+Fielding, et. al. Standards Track [Page 95]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If no Accept header field is present, then it is assumed that the
+ client accepts all media types. If an Accept header field is present,
+ and if the server cannot send a response which is acceptable
+ according to the combined Accept field value, then the server SHOULD
+ send a 406 (not acceptable) response.
+
+ A more elaborate example is
+
+ Accept: text/plain; q=0.5, text/html,
+ text/x-dvi; q=0.8, text/x-c
+
+ Verbally, this would be interpreted as "text/html and text/x-c are
+ the preferred media types, but if they do not exist, then send the
+ text/x-dvi entity, and if that does not exist, send the text/plain
+ entity."
+
+ Media ranges can be overridden by more specific media ranges or
+ specific media types. If more than one media range applies to a given
+ type, the most specific reference has precedence. For example,
+
+ Accept: text/*, text/html, text/html;level=1, */*
+
+ have the following precedence:
+
+ 1) text/html;level=1
+ 2) text/html
+ 3) text/*
+ 4) */*
+
+ The media type quality factor associated with a given type is
+ determined by finding the media range with the highest precedence
+ which matches that type. For example,
+
+ Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+ text/html;level=2;q=0.4, */*;q=0.5
+
+ would cause the following values to be associated:
+
+ text/html;level=1 = 1
+ text/html = 0.7
+ text/plain = 0.3
+ image/jpeg = 0.5
+ text/html;level=2 = 0.4
+ text/html;level=3 = 0.7
+
+ Note: A user agent may be provided with a default set of quality
+ values for certain media ranges. However, unless the user agent is
+ a closed system which cannot interact with other rendering agents,
+
+
+
+Fielding, et. al. Standards Track [Page 96]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ this default set should be configurable by the user.
+
+14.2 Accept-Charset
+
+ The Accept-Charset request-header field can be used to indicate what
+ character sets are acceptable for the response. This field allows
+ clients capable of understanding more comprehensive or special-
+ purpose character sets to signal that capability to a server which is
+ capable of representing documents in those character sets. The ISO-
+ 8859-1 character set can be assumed to be acceptable to all user
+ agents.
+
+ Accept-Charset = "Accept-Charset" ":"
+ 1#( charset [ ";" "q" "=" qvalue ] )
+
+ Character set values are described in section 3.4. Each charset may
+ be given an associated quality value which represents the user's
+ preference for that charset. The default value is q=1. An example is
+
+ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+ If no Accept-Charset header is present, the default is that any
+ character set is acceptable. If an Accept-Charset header is present,
+ and if the server cannot send a response which is acceptable
+ according to the Accept-Charset header, then the server SHOULD send
+ an error response with the 406 (not acceptable) status code, though
+ the sending of an unacceptable response is also allowed.
+
+14.3 Accept-Encoding
+
+ The Accept-Encoding request-header field is similar to Accept, but
+ restricts the content-coding values (section 14.12) which are
+ acceptable in the response.
+
+ Accept-Encoding = "Accept-Encoding" ":"
+ #( content-coding )
+
+ An example of its use is
+
+ Accept-Encoding: compress, gzip
+
+ If no Accept-Encoding header is present in a request, the server MAY
+ assume that the client will accept any content coding. If an Accept-
+ Encoding header is present, and if the server cannot send a response
+ which is acceptable according to the Accept-Encoding header, then the
+ server SHOULD send an error response with the 406 (Not Acceptable)
+ status code.
+
+
+
+
+Fielding, et. al. Standards Track [Page 97]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ An empty Accept-Encoding value indicates none are acceptable.
+
+14.4 Accept-Language
+
+ The Accept-Language request-header field is similar to Accept, but
+ restricts the set of natural languages that are preferred as a
+ response to the request.
+
+ Accept-Language = "Accept-Language" ":"
+ 1#( language-range [ ";" "q" "=" qvalue ] )
+
+ language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+
+ Each language-range MAY be given an associated quality value which
+ represents an estimate of the user's preference for the languages
+ specified by that range. The quality value defaults to "q=1". For
+ example,
+
+ Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+ would mean: "I prefer Danish, but will accept British English and
+ other types of English." A language-range matches a language-tag if
+ it exactly equals the tag, or if it exactly equals a prefix of the
+ tag such that the first tag character following the prefix is "-".
+ The special range "*", if present in the Accept-Language field,
+ matches every tag not matched by any other range present in the
+ Accept-Language field.
+
+ Note: This use of a prefix matching rule does not imply that
+ language tags are assigned to languages in such a way that it is
+ always true that if a user understands a language with a certain
+ tag, then this user will also understand all languages with tags
+ for which this tag is a prefix. The prefix rule simply allows the
+ use of prefix tags if this is the case.
+
+ The language quality factor assigned to a language-tag by the
+ Accept-Language field is the quality value of the longest language-
+ range in the field that matches the language-tag. If no language-
+ range in the field matches the tag, the language quality factor
+ assigned is 0. If no Accept-Language header is present in the
+ request, the server SHOULD assume that all languages are equally
+ acceptable. If an Accept-Language header is present, then all
+ languages which are assigned a quality factor greater than 0 are
+ acceptable.
+
+ It may be contrary to the privacy expectations of the user to send an
+ Accept-Language header with the complete linguistic preferences of
+ the user in every request. For a discussion of this issue, see
+
+
+
+Fielding, et. al. Standards Track [Page 98]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ section 15.7.
+
+ Note: As intelligibility is highly dependent on the individual
+ user, it is recommended that client applications make the choice of
+ linguistic preference available to the user. If the choice is not
+ made available, then the Accept-Language header field must not be
+ given in the request.
+
+14.5 Accept-Ranges
+
+ The Accept-Ranges response-header field allows the server to indicate
+ its acceptance of range requests for a resource:
+
+ Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
+
+ acceptable-ranges = 1#range-unit | "none"
+
+ Origin servers that accept byte-range requests MAY send
+
+ Accept-Ranges: bytes
+
+ but are not required to do so. Clients MAY generate byte-range
+ requests without having received this header for the resource
+ involved.
+
+ Servers that do not accept any kind of range request for a resource
+ MAY send
+
+ Accept-Ranges: none
+
+ to advise the client not to attempt a range request.
+
+14.6 Age
+
+ The Age response-header field conveys the sender's estimate of the
+ amount of time since the response (or its revalidation) was generated
+ at the origin server. A cached response is "fresh" if its age does
+ not exceed its freshness lifetime. Age values are calculated as
+ specified in section 13.2.3.
+
+ Age = "Age" ":" age-value
+
+ age-value = delta-seconds
+
+ Age values are non-negative decimal integers, representing time in
+ seconds.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 99]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If a cache receives a value larger than the largest positive integer
+ it can represent, or if any of its age calculations overflows, it
+ MUST transmit an Age header with a value of 2147483648 (2^31).
+ HTTP/1.1 caches MUST send an Age header in every response. Caches
+ SHOULD use an arithmetic type of at least 31 bits of range.
+
+14.7 Allow
+
+ The Allow entity-header field lists the set of methods supported by
+ the resource identified by the Request-URI. The purpose of this field
+ is strictly to inform the recipient of valid methods associated with
+ the resource. An Allow header field MUST be present in a 405 (Method
+ Not Allowed) response.
+
+ Allow = "Allow" ":" 1#method
+
+ Example of use:
+
+ Allow: GET, HEAD, PUT
+
+ This field cannot prevent a client from trying other methods.
+ However, the indications given by the Allow header field value SHOULD
+ be followed. The actual set of allowed methods is defined by the
+ origin server at the time of each request.
+
+ The Allow header field MAY be provided with a PUT request to
+ recommend the methods to be supported by the new or modified
+ resource. The server is not required to support these methods and
+ SHOULD include an Allow header in the response giving the actual
+ supported methods.
+
+ A proxy MUST NOT modify the Allow header field even if it does not
+ understand all the methods specified, since the user agent MAY have
+ other means of communicating with the origin server.
+
+ The Allow header field does not indicate what methods are implemented
+ at the server level. Servers MAY use the Public response-header field
+ (section 14.35) to describe what methods are implemented on the
+ server as a whole.
+
+14.8 Authorization
+
+ A user agent that wishes to authenticate itself with a server--
+ usually, but not necessarily, after receiving a 401 response--MAY do
+ so by including an Authorization request-header field with the
+ request. The Authorization field value consists of credentials
+ containing the authentication information of the user agent for the
+ realm of the resource being requested.
+
+
+
+Fielding, et. al. Standards Track [Page 100]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Authorization = "Authorization" ":" credentials
+
+ HTTP access authentication is described in section 11. If a request
+ is authenticated and a realm specified, the same credentials SHOULD
+ be valid for all other requests within this realm.
+
+ When a shared cache (see section 13.7) receives a request containing
+ an Authorization field, it MUST NOT return the corresponding response
+ as a reply to any other request, unless one of the following specific
+ exceptions holds:
+
+ 1. If the response includes the "proxy-revalidate" Cache-Control
+ directive, the cache MAY use that response in replying to a
+ subsequent request, but a proxy cache MUST first revalidate it with
+ the origin server, using the request-headers from the new request
+ to allow the origin server to authenticate the new request.
+ 2. If the response includes the "must-revalidate" Cache-Control
+ directive, the cache MAY use that response in replying to a
+ subsequent request, but all caches MUST first revalidate it with
+ the origin server, using the request-headers from the new request
+ to allow the origin server to authenticate the new request.
+ 3. If the response includes the "public" Cache-Control directive, it
+ may be returned in reply to any subsequent request.
+
+14.9 Cache-Control
+
+ The Cache-Control general-header field is used to specify directives
+ that MUST be obeyed by all caching mechanisms along the
+ request/response chain. The directives specify behavior intended to
+ prevent caches from adversely interfering with the request or
+ response. These directives typically override the default caching
+ algorithms. Cache directives are unidirectional in that the presence
+ of a directive in a request does not imply that the same directive
+ should be given in the response.
+
+ Note that HTTP/1.0 caches may not implement Cache-Control and may
+ only implement Pragma: no-cache (see section 14.32).
+
+ Cache directives must be passed through by a proxy or gateway
+ application, regardless of their significance to that application,
+ since the directives may be applicable to all recipients along the
+ request/response chain. It is not possible to specify a cache-
+ directive for a specific cache.
+
+ Cache-Control = "Cache-Control" ":" 1#cache-directive
+
+ cache-directive = cache-request-directive
+ | cache-response-directive
+
+
+
+Fielding, et. al. Standards Track [Page 101]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ cache-request-directive =
+ "no-cache" [ "=" <"> 1#field-name <"> ]
+ | "no-store"
+ | "max-age" "=" delta-seconds
+ | "max-stale" [ "=" delta-seconds ]
+ | "min-fresh" "=" delta-seconds
+ | "only-if-cached"
+ | cache-extension
+
+ cache-response-directive =
+ "public"
+ | "private" [ "=" <"> 1#field-name <"> ]
+ | "no-cache" [ "=" <"> 1#field-name <"> ]
+ | "no-store"
+ | "no-transform"
+ | "must-revalidate"
+ | "proxy-revalidate"
+ | "max-age" "=" delta-seconds
+ | cache-extension
+
+ cache-extension = token [ "=" ( token | quoted-string ) ]
+
+ When a directive appears without any 1#field-name parameter, the
+ directive applies to the entire request or response. When such a
+ directive appears with a 1#field-name parameter, it applies only to
+ the named field or fields, and not to the rest of the request or
+ response. This mechanism supports extensibility; implementations of
+ future versions of the HTTP protocol may apply these directives to
+ header fields not defined in HTTP/1.1.
+
+ The cache-control directives can be broken down into these general
+ categories:
+
+ o Restrictions on what is cachable; these may only be imposed by the
+ origin server.
+ o Restrictions on what may be stored by a cache; these may be imposed
+ by either the origin server or the user agent.
+ o Modifications of the basic expiration mechanism; these may be
+ imposed by either the origin server or the user agent.
+ o Controls over cache revalidation and reload; these may only be
+ imposed by a user agent.
+ o Control over transformation of entities.
+ o Extensions to the caching system.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 102]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.9.1 What is Cachable
+
+ By default, a response is cachable if the requirements of the request
+ method, request header fields, and the response status indicate that
+ it is cachable. Section 13.4 summarizes these defaults for
+ cachability. The following Cache-Control response directives allow an
+ origin server to override the default cachability of a response:
+
+public
+ Indicates that the response is cachable by any cache, even if it
+ would normally be non-cachable or cachable only within a non-shared
+ cache. (See also Authorization, section 14.8, for additional
+ details.)
+
+private
+ Indicates that all or part of the response message is intended for a
+ single user and MUST NOT be cached by a shared cache. This allows an
+ origin server to state that the specified parts of the response are
+ intended for only one user and are not a valid response for requests
+ by other users. A private (non-shared) cache may cache the response.
+
+ Note: This usage of the word private only controls where the
+ response may be cached, and cannot ensure the privacy of the
+ message content.
+
+no-cache
+ Indicates that all or part of the response message MUST NOT be cached
+ anywhere. This allows an origin server to prevent caching even by
+ caches that have been configured to return stale responses to client
+ requests.
+
+ Note: Most HTTP/1.0 caches will not recognize or obey this
+ directive.
+
+14.9.2 What May be Stored by Caches
+
+ The purpose of the no-store directive is to prevent the inadvertent
+ release or retention of sensitive information (for example, on backup
+ tapes). The no-store directive applies to the entire message, and may
+ be sent either in a response or in a request. If sent in a request, a
+ cache MUST NOT store any part of either this request or any response
+ to it. If sent in a response, a cache MUST NOT store any part of
+ either this response or the request that elicited it. This directive
+ applies to both non-shared and shared caches. "MUST NOT store" in
+ this context means that the cache MUST NOT intentionally store the
+ information in non-volatile storage, and MUST make a best-effort
+ attempt to remove the information from volatile storage as promptly
+ as possible after forwarding it.
+
+
+
+Fielding, et. al. Standards Track [Page 103]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Even when this directive is associated with a response, users may
+ explicitly store such a response outside of the caching system (e.g.,
+ with a "Save As" dialog). History buffers may store such responses as
+ part of their normal operation.
+
+ The purpose of this directive is to meet the stated requirements of
+ certain users and service authors who are concerned about accidental
+ releases of information via unanticipated accesses to cache data
+ structures. While the use of this directive may improve privacy in
+ some cases, we caution that it is NOT in any way a reliable or
+ sufficient mechanism for ensuring privacy. In particular, malicious
+ or compromised caches may not recognize or obey this directive; and
+ communications networks may be vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+ The expiration time of an entity may be specified by the origin
+ server using the Expires header (see section 14.21). Alternatively,
+ it may be specified using the max-age directive in a response.
+
+ If a response includes both an Expires header and a max-age
+ directive, the max-age directive overrides the Expires header, even
+ if the Expires header is more restrictive. This rule allows an origin
+ server to provide, for a given response, a longer expiration time to
+ an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
+ useful if certain HTTP/1.0 caches improperly calculate ages or
+ expiration times, perhaps due to desynchronized clocks.
+
+ Note: most older caches, not compliant with this specification, do
+ not implement any Cache-Control directives. An origin server
+ wishing to use a Cache-Control directive that restricts, but does
+ not prevent, caching by an HTTP/1.1-compliant cache may exploit the
+ requirement that the max-age directive overrides the Expires
+ header, and the fact that non-HTTP/1.1-compliant caches do not
+ observe the max-age directive.
+
+ Other directives allow an user agent to modify the basic expiration
+ mechanism. These directives may be specified on a request:
+
+ max-age
+ Indicates that the client is willing to accept a response whose age
+ is no greater than the specified time in seconds. Unless max-stale
+ directive is also included, the client is not willing to accept a
+ stale response.
+
+ min-fresh
+ Indicates that the client is willing to accept a response whose
+ freshness lifetime is no less than its current age plus the
+
+
+
+Fielding, et. al. Standards Track [Page 104]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ specified time in seconds. That is, the client wants a response
+ that will still be fresh for at least the specified number of
+ seconds.
+
+ max-stale
+ Indicates that the client is willing to accept a response that has
+ exceeded its expiration time. If max-stale is assigned a value,
+ then the client is willing to accept a response that has exceeded
+ its expiration time by no more than the specified number of
+ seconds. If no value is assigned to max-stale, then the client is
+ willing to accept a stale response of any age.
+
+ If a cache returns a stale response, either because of a max-stale
+ directive on a request, or because the cache is configured to
+ override the expiration time of a response, the cache MUST attach a
+ Warning header to the stale response, using Warning 10 (Response is
+ stale).
+
+14.9.4 Cache Revalidation and Reload Controls
+
+ Sometimes an user agent may want or need to insist that a cache
+ revalidate its cache entry with the origin server (and not just with
+ the next cache along the path to the origin server), or to reload its
+ cache entry from the origin server. End-to-end revalidation may be
+ necessary if either the cache or the origin server has overestimated
+ the expiration time of the cached response. End-to-end reload may be
+ necessary if the cache entry has become corrupted for some reason.
+
+ End-to-end revalidation may be requested either when the client does
+ not have its own local cached copy, in which case we call it
+ "unspecified end-to-end revalidation", or when the client does have a
+ local cached copy, in which case we call it "specific end-to-end
+ revalidation."
+
+ The client can specify these three kinds of action using Cache-
+ Control request directives:
+
+ End-to-end reload
+ The request includes a "no-cache" Cache-Control directive or, for
+ compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
+ names may be included with the no-cache directive in a request. The
+ server MUST NOT use a cached copy when responding to such a
+ request.
+
+ Specific end-to-end revalidation
+ The request includes a "max-age=0" Cache-Control directive, which
+ forces each cache along the path to the origin server to revalidate
+ its own entry, if any, with the next cache or server. The initial
+
+
+
+Fielding, et. al. Standards Track [Page 105]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ request includes a cache-validating conditional with the client's
+ current validator.
+
+ Unspecified end-to-end revalidation
+ The request includes "max-age=0" Cache-Control directive, which
+ forces each cache along the path to the origin server to revalidate
+ its own entry, if any, with the next cache or server. The initial
+ request does not include a cache-validating conditional; the first
+ cache along the path (if any) that holds a cache entry for this
+ resource includes a cache-validating conditional with its current
+ validator.
+
+ When an intermediate cache is forced, by means of a max-age=0
+ directive, to revalidate its own cache entry, and the client has
+ supplied its own validator in the request, the supplied validator may
+ differ from the validator currently stored with the cache entry. In
+ this case, the cache may use either validator in making its own
+ request without affecting semantic transparency.
+
+ However, the choice of validator may affect performance. The best
+ approach is for the intermediate cache to use its own validator when
+ making its request. If the server replies with 304 (Not Modified),
+ then the cache should return its now validated copy to the client
+ with a 200 (OK) response. If the server replies with a new entity and
+ cache validator, however, the intermediate cache should compare the
+ returned validator with the one provided in the client's request,
+ using the strong comparison function. If the client's validator is
+ equal to the origin server's, then the intermediate cache simply
+ returns 304 (Not Modified). Otherwise, it returns the new entity with
+ a 200 (OK) response.
+
+ If a request includes the no-cache directive, it should not include
+ min-fresh, max-stale, or max-age.
+
+ In some cases, such as times of extremely poor network connectivity,
+ a client may want a cache to return only those responses that it
+ currently has stored, and not to reload or revalidate with the origin
+ server. To do this, the client may include the only-if-cached
+ directive in a request. If it receives this directive, a cache SHOULD
+ either respond using a cached entry that is consistent with the other
+ constraints of the request, or respond with a 504 (Gateway Timeout)
+ status. However, if a group of caches is being operated as a unified
+ system with good internal connectivity, such a request MAY be
+ forwarded within that group of caches.
+
+ Because a cache may be configured to ignore a server's specified
+ expiration time, and because a client request may include a max-stale
+ directive (which has a similar effect), the protocol also includes a
+
+
+
+Fielding, et. al. Standards Track [Page 106]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ mechanism for the origin server to require revalidation of a cache
+ entry on any subsequent use. When the must-revalidate directive is
+ present in a response received by a cache, that cache MUST NOT use
+ the entry after it becomes stale to respond to a subsequent request
+ without first revalidating it with the origin server. (I.e., the
+ cache must do an end-to-end revalidation every time, if, based solely
+ on the origin server's Expires or max-age value, the cached response
+ is stale.)
+
+ The must-revalidate directive is necessary to support reliable
+ operation for certain protocol features. In all circumstances an
+ HTTP/1.1 cache MUST obey the must-revalidate directive; in
+ particular, if the cache cannot reach the origin server for any
+ reason, it MUST generate a 504 (Gateway Timeout) response.
+
+ Servers should send the must-revalidate directive if and only if
+ failure to revalidate a request on the entity could result in
+ incorrect operation, such as a silently unexecuted financial
+ transaction. Recipients MUST NOT take any automated action that
+ violates this directive, and MUST NOT automatically provide an
+ unvalidated copy of the entity if revalidation fails.
+
+ Although this is not recommended, user agents operating under severe
+ connectivity constraints may violate this directive but, if so, MUST
+ explicitly warn the user that an unvalidated response has been
+ provided. The warning MUST be provided on each unvalidated access,
+ and SHOULD require explicit user confirmation.
+
+ The proxy-revalidate directive has the same meaning as the must-
+ revalidate directive, except that it does not apply to non-shared
+ user agent caches. It can be used on a response to an authenticated
+ request to permit the user's cache to store and later return the
+ response without needing to revalidate it (since it has already been
+ authenticated once by that user), while still requiring proxies that
+ service many users to revalidate each time (in order to make sure
+ that each user has been authenticated). Note that such authenticated
+ responses also need the public cache control directive in order to
+ allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+ Implementers of intermediate caches (proxies) have found it useful to
+ convert the media type of certain entity bodies. A proxy might, for
+ example, convert between image formats in order to save cache space
+ or to reduce the amount of traffic on a slow link. HTTP has to date
+ been silent on these transformations.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 107]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Serious operational problems have already occurred, however, when
+ these transformations have been applied to entity bodies intended for
+ certain kinds of applications. For example, applications for medical
+ imaging, scientific data analysis and those using end-to-end
+ authentication, all depend on receiving an entity body that is bit
+ for bit identical to the original entity-body.
+
+ Therefore, if a response includes the no-transform directive, an
+ intermediate cache or proxy MUST NOT change those headers that are
+ listed in section 13.5.2 as being subject to the no-transform
+ directive. This implies that the cache or proxy must not change any
+ aspect of the entity-body that is specified by these headers.
+
+14.9.6 Cache Control Extensions
+
+ The Cache-Control header field can be extended through the use of one
+ or more cache-extension tokens, each with an optional assigned value.
+ Informational extensions (those which do not require a change in
+ cache behavior) may be added without changing the semantics of other
+ directives. Behavioral extensions are designed to work by acting as
+ modifiers to the existing base of cache directives. Both the new
+ directive and the standard directive are supplied, such that
+ applications which do not understand the new directive will default
+ to the behavior specified by the standard directive, and those that
+ understand the new directive will recognize it as modifying the
+ requirements associated with the standard directive. In this way,
+ extensions to the Cache-Control directives can be made without
+ requiring changes to the base protocol.
+
+ This extension mechanism depends on a HTTP cache obeying all of the
+ cache-control directives defined for its native HTTP-version, obeying
+ certain extensions, and ignoring all directives that it does not
+ understand.
+
+ For example, consider a hypothetical new response directive called
+ "community" which acts as a modifier to the "private" directive. We
+ define this new directive to mean that, in addition to any non-shared
+ cache, any cache which is shared only by members of the community
+ named within its value may cache the response. An origin server
+ wishing to allow the "UCI" community to use an otherwise private
+ response in their shared cache(s) may do so by including
+
+ Cache-Control: private, community="UCI"
+
+ A cache seeing this header field will act correctly even if the cache
+ does not understand the "community" cache-extension, since it will
+ also see and understand the "private" directive and thus default to
+ the safe behavior.
+
+
+
+Fielding, et. al. Standards Track [Page 108]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Unrecognized cache-directives MUST be ignored; it is assumed that any
+ cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+ be combined with standard directives (or the response's default
+ cachability) such that the cache behavior will remain minimally
+ correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+ The Connection general-header field allows the sender to specify
+ options that are desired for that particular connection and MUST NOT
+ be communicated by proxies over further connections.
+
+ The Connection header has the following grammar:
+
+ Connection-header = "Connection" ":" 1#(connection-token)
+ connection-token = token
+
+ HTTP/1.1 proxies MUST parse the Connection header field before a
+ message is forwarded and, for each connection-token in this field,
+ remove any header field(s) from the message with the same name as the
+ connection-token. Connection options are signaled by the presence of
+ a connection-token in the Connection header field, not by any
+ corresponding additional header field(s), since the additional header
+ field may not be sent if there are no parameters associated with that
+ connection option. HTTP/1.1 defines the "close" connection option
+ for the sender to signal that the connection will be closed after
+ completion of the response. For example,
+
+ Connection: close
+
+ in either the request or the response header fields indicates that
+ the connection should not be considered `persistent' (section 8.1)
+ after the current request/response is complete.
+
+ HTTP/1.1 applications that do not support persistent connections MUST
+ include the "close" connection option in every message.
+
+14.11 Content-Base
+
+ The Content-Base entity-header field may be used to specify the base
+ URI for resolving relative URLs within the entity. This header field
+ is described as Base in RFC 1808, which is expected to be revised.
+
+ Content-Base = "Content-Base" ":" absoluteURI
+
+ If no Content-Base field is present, the base URI of an entity is
+ defined either by its Content-Location (if that Content-Location URI
+ is an absolute URI) or the URI used to initiate the request, in that
+
+
+
+Fielding, et. al. Standards Track [Page 109]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ order of precedence. Note, however, that the base URI of the contents
+ within the entity-body may be redefined within that entity-body.
+
+14.12 Content-Encoding
+
+ The Content-Encoding entity-header field is used as a modifier to the
+ media-type. When present, its value indicates what additional content
+ codings have been applied to the entity-body, and thus what decoding
+ mechanisms MUST be applied in order to obtain the media-type
+ referenced by the Content-Type header field. Content-Encoding is
+ primarily used to allow a document to be compressed without losing
+ the identity of its underlying media type.
+
+ Content-Encoding = "Content-Encoding" ":" 1#content-coding
+
+ Content codings are defined in section 3.5. An example of its use is
+
+ Content-Encoding: gzip
+
+ The Content-Encoding is a characteristic of the entity identified by
+ the Request-URI. Typically, the entity-body is stored with this
+ encoding and is only decoded before rendering or analogous usage.
+
+ If multiple encodings have been applied to an entity, the content
+ codings MUST be listed in the order in which they were applied.
+
+ Additional information about the encoding parameters MAY be provided
+ by other entity-header fields not defined by this specification.
+
+14.13 Content-Language
+
+ The Content-Language entity-header field describes the natural
+ language(s) of the intended audience for the enclosed entity. Note
+ that this may not be equivalent to all the languages used within the
+ entity-body.
+
+ Content-Language = "Content-Language" ":" 1#language-tag
+
+ Language tags are defined in section 3.10. The primary purpose of
+ Content-Language is to allow a user to identify and differentiate
+ entities according to the user's own preferred language. Thus, if the
+ body content is intended only for a Danish-literate audience, the
+ appropriate field is
+
+ Content-Language: da
+
+ If no Content-Language is specified, the default is that the content
+ is intended for all language audiences. This may mean that the sender
+
+
+
+Fielding, et. al. Standards Track [Page 110]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ does not consider it to be specific to any natural language, or that
+ the sender does not know for which language it is intended.
+
+ Multiple languages MAY be listed for content that is intended for
+ multiple audiences. For example, a rendition of the "Treaty of
+ Waitangi," presented simultaneously in the original Maori and English
+ versions, would call for
+
+ Content-Language: mi, en
+
+ However, just because multiple languages are present within an entity
+ does not mean that it is intended for multiple linguistic audiences.
+ An example would be a beginner's language primer, such as "A First
+ Lesson in Latin," which is clearly intended to be used by an
+ English-literate audience. In this case, the Content-Language should
+ only include "en".
+
+ Content-Language may be applied to any media type -- it is not
+ limited to textual documents.
+
+14.14 Content-Length
+
+ The Content-Length entity-header field indicates the size of the
+ message-body, in decimal number of octets, sent to the recipient or,
+ in the case of the HEAD method, the size of the entity-body that
+ would have been sent had the request been a GET.
+
+ Content-Length = "Content-Length" ":" 1*DIGIT
+
+ An example is
+
+ Content-Length: 3495
+
+ Applications SHOULD use this field to indicate the size of the
+ message-body to be transferred, regardless of the media type of the
+ entity. It must be possible for the recipient to reliably determine
+ the end of HTTP/1.1 requests containing an entity-body, e.g., because
+ the request has a valid Content-Length field, uses Transfer-Encoding:
+ chunked or a multipart body.
+
+ Any Content-Length greater than or equal to zero is a valid value.
+ Section 4.4 describes how to determine the length of a message-body
+ if a Content-Length is not given.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 111]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Note: The meaning of this field is significantly different from the
+ corresponding definition in MIME, where it is an optional field
+ used within the "message/external-body" content-type. In HTTP, it
+ SHOULD be sent whenever the message's length can be determined
+ prior to being transferred.
+
+14.15 Content-Location
+
+ The Content-Location entity-header field may be used to supply the
+ resource location for the entity enclosed in the message. In the case
+ where a resource has multiple entities associated with it, and those
+ entities actually have separate locations by which they might be
+ individually accessed, the server should provide a Content-Location
+ for the particular variant which is returned. In addition, a server
+ SHOULD provide a Content-Location for the resource corresponding to
+ the response entity.
+
+ Content-Location = "Content-Location" ":"
+ ( absoluteURI | relativeURI )
+
+ If no Content-Base header field is present, the value of Content-
+ Location also defines the base URL for the entity (see section
+ 14.11).
+
+ The Content-Location value is not a replacement for the original
+ requested URI; it is only a statement of the location of the resource
+ corresponding to this particular entity at the time of the request.
+ Future requests MAY use the Content-Location URI if the desire is to
+ identify the source of that particular entity.
+
+ A cache cannot assume that an entity with a Content-Location
+ different from the URI used to retrieve it can be used to respond to
+ later requests on that Content-Location URI. However, the Content-
+ Location can be used to differentiate between multiple entities
+ retrieved from a single requested resource, as described in section
+ 13.6.
+
+ If the Content-Location is a relative URI, the URI is interpreted
+ relative to any Content-Base URI provided in the response. If no
+ Content-Base is provided, the relative URI is interpreted relative to
+ the Request-URI.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 112]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.16 Content-MD5
+
+ The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+ an MD5 digest of the entity-body for the purpose of providing an
+ end-to-end message integrity check (MIC) of the entity-body. (Note: a
+ MIC is good for detecting accidental modification of the entity-body
+ in transit, but is not proof against malicious attacks.)
+
+ Content-MD5 = "Content-MD5" ":" md5-digest
+
+ md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+ The Content-MD5 header field may be generated by an origin server to
+ function as an integrity check of the entity-body. Only origin
+ servers may generate the Content-MD5 header field; proxies and
+ gateways MUST NOT generate it, as this would defeat its value as an
+ end-to-end integrity check. Any recipient of the entity-body,
+ including gateways and proxies, MAY check that the digest value in
+ this header field matches that of the entity-body as received.
+
+ The MD5 digest is computed based on the content of the entity-body,
+ including any Content-Encoding that has been applied, but not
+ including any Transfer-Encoding that may have been applied to the
+ message-body. If the message is received with a Transfer-Encoding,
+ that encoding must be removed prior to checking the Content-MD5 value
+ against the received entity.
+
+ This has the result that the digest is computed on the octets of the
+ entity-body exactly as, and in the order that, they would be sent if
+ no Transfer-Encoding were being applied.
+
+ HTTP extends RFC 1864 to permit the digest to be computed for MIME
+ composite media-types (e.g., multipart/* and message/rfc822), but
+ this does not change how the digest is computed as defined in the
+ preceding paragraph.
+
+ Note: There are several consequences of this. The entity-body for
+ composite types may contain many body-parts, each with its own MIME
+ and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
+ and Content-Encoding headers). If a body-part has a Content-
+ Transfer-Encoding or Content-Encoding header, it is assumed that
+ the content of the body-part has had the encoding applied, and the
+ body-part is included in the Content-MD5 digest as is -- i.e.,
+ after the application. The Transfer-Encoding header field is not
+ allowed within body-parts.
+
+ Note: while the definition of Content-MD5 is exactly the same for
+ HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+
+
+
+Fielding, et. al. Standards Track [Page 113]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ in which the application of Content-MD5 to HTTP entity-bodies
+ differs from its application to MIME entity-bodies. One is that
+ HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
+ use Transfer-Encoding and Content-Encoding. Another is that HTTP
+ more frequently uses binary content types than MIME, so it is worth
+ noting that, in such cases, the byte order used to compute the
+ digest is the transmission byte order defined for the type. Lastly,
+ HTTP allows transmission of text types with any of several line
+ break conventions and not just the canonical form using CRLF.
+ Conversion of all line breaks to CRLF should not be done before
+ computing or checking the digest: the line break convention used in
+ the text actually transmitted should be left unaltered when
+ computing the digest.
+
+14.17 Content-Range
+
+ The Content-Range entity-header is sent with a partial entity-body to
+ specify where in the full entity-body the partial body should be
+ inserted. It also indicates the total size of the full entity-body.
+ When a server returns a partial response to a client, it must
+ describe both the extent of the range covered by the response, and
+ the length of the entire entity-body.
+
+ Content-Range = "Content-Range" ":" content-range-spec
+
+ content-range-spec = byte-content-range-spec
+
+ byte-content-range-spec = bytes-unit SP first-byte-pos "-"
+ last-byte-pos "/" entity-length
+
+ entity-length = 1*DIGIT
+
+ Unlike byte-ranges-specifier values, a byte-content-range-spec may
+ only specify one range, and must contain absolute byte positions for
+ both the first and last byte of the range.
+
+ A byte-content-range-spec whose last-byte-pos value is less than its
+ first-byte-pos value, or whose entity-length value is less than or
+ equal to its last-byte-pos value, is invalid. The recipient of an
+ invalid byte-content-range-spec MUST ignore it and any content
+ transferred along with it.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 114]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Examples of byte-content-range-spec values, assuming that the entity
+ contains a total of 1234 bytes:
+
+ o The first 500 bytes:
+
+ bytes 0-499/1234
+
+ o The second 500 bytes:
+
+ bytes 500-999/1234
+
+ o All except for the first 500 bytes:
+
+ bytes 500-1233/1234
+
+ o The last 500 bytes:
+
+ bytes 734-1233/1234
+
+ When an HTTP message includes the content of a single range (for
+ example, a response to a request for a single range, or to a request
+ for a set of ranges that overlap without any holes), this content is
+ transmitted with a Content-Range header, and a Content-Length header
+ showing the number of bytes actually transferred. For example,
+
+ HTTP/1.1 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-Range: bytes 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+
+ When an HTTP message includes the content of multiple ranges (for
+ example, a response to a request for multiple non-overlapping
+ ranges), these are transmitted as a multipart MIME message. The
+ multipart MIME content-type used for this purpose is defined in this
+ specification to be "multipart/byteranges". See appendix 19.2 for its
+ definition.
+
+ A client that cannot decode a MIME multipart/byteranges message
+ should not ask for multiple byte-ranges in a single request.
+
+ When a client requests multiple byte-ranges in one request, the
+ server SHOULD return them in the order that they appeared in the
+ request.
+
+ If the server ignores a byte-range-spec because it is invalid, the
+ server should treat the request as if the invalid Range header field
+
+
+
+Fielding, et. al. Standards Track [Page 115]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ did not exist. (Normally, this means return a 200 response containing
+ the full entity). The reason is that the only time a client will make
+ such an invalid request is when the entity is smaller than the entity
+ retrieved by a prior request.
+
+14.18 Content-Type
+
+ The Content-Type entity-header field indicates the media type of the
+ entity-body sent to the recipient or, in the case of the HEAD method,
+ the media type that would have been sent had the request been a GET.
+
+ Content-Type = "Content-Type" ":" media-type
+ Media types are defined in section 3.7. An example of the field is
+
+ Content-Type: text/html; charset=ISO-8859-4
+
+ Further discussion of methods for identifying the media type of an
+ entity is provided in section 7.2.1.
+
+14.19 Date
+
+ The Date general-header field represents the date and time at which
+ the message was originated, having the same semantics as orig-date in
+ RFC 822. The field value is an HTTP-date, as described in section
+ 3.3.1.
+
+ Date = "Date" ":" HTTP-date
+
+ An example is
+
+ Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+ If a message is received via direct connection with the user agent
+ (in the case of requests) or the origin server (in the case of
+ responses), then the date can be assumed to be the current date at
+ the receiving end. However, since the date--as it is believed by the
+ origin--is important for evaluating cached responses, origin servers
+ MUST include a Date header field in all responses. Clients SHOULD
+ only send a Date header field in messages that include an entity-
+ body, as in the case of the PUT and POST requests, and even then it
+ is optional. A received message which does not have a Date header
+ field SHOULD be assigned one by the recipient if the message will be
+ cached by that recipient or gatewayed via a protocol which requires a
+ Date.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 116]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ In theory, the date SHOULD represent the moment just before the
+ entity is generated. In practice, the date can be generated at any
+ time during the message origination without affecting its semantic
+ value.
+
+ The format of the Date is an absolute date and time as defined by
+ HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
+
+14.20 ETag
+
+ The ETag entity-header field defines the entity tag for the
+ associated entity. The headers used with entity tags are described in
+ sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
+ for comparison with other entities from the same resource (see
+ section 13.3.2).
+
+ ETag = "ETag" ":" entity-tag
+
+ Examples:
+
+ ETag: "xyzzy"
+ ETag: W/"xyzzy"
+ ETag: ""
+
+14.21 Expires
+
+ The Expires entity-header field gives the date/time after which the
+ response should be considered stale. A stale cache entry may not
+ normally be returned by a cache (either a proxy cache or an user
+ agent cache) unless it is first validated with the origin server (or
+ with an intermediate cache that has a fresh copy of the entity). See
+ section 13.2 for further discussion of the expiration model.
+
+ The presence of an Expires field does not imply that the original
+ resource will change or cease to exist at, before, or after that
+ time.
+
+ The format is an absolute date and time as defined by HTTP-date in
+ section 3.3; it MUST be in RFC1123-date format:
+
+ Expires = "Expires" ":" HTTP-date
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 117]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ An example of its use is
+
+ Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+ Note: if a response includes a Cache-Control field with the max-age
+ directive, that directive overrides the Expires field.
+
+ HTTP/1.1 clients and caches MUST treat other invalid date formats,
+ especially including the value "0", as in the past (i.e., "already
+ expired").
+
+ To mark a response as "already expired," an origin server should use
+ an Expires date that is equal to the Date header value. (See the
+ rules for expiration calculations in section 13.2.4.)
+
+ To mark a response as "never expires," an origin server should use an
+ Expires date approximately one year from the time the response is
+ sent. HTTP/1.1 servers should not send Expires dates more than one
+ year in the future.
+
+ The presence of an Expires header field with a date value of some
+ time in the future on an response that otherwise would by default be
+ non-cacheable indicates that the response is cachable, unless
+ indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 From
+
+ The From request-header field, if given, SHOULD contain an Internet
+ e-mail address for the human user who controls the requesting user
+ agent. The address SHOULD be machine-usable, as defined by mailbox
+ in RFC 822 (as updated by RFC 1123 ):
+
+ From = "From" ":" mailbox
+
+ An example is:
+
+ From: webmaster@w3.org
+
+ This header field MAY be used for logging purposes and as a means for
+ identifying the source of invalid or unwanted requests. It SHOULD NOT
+ be used as an insecure form of access protection. The interpretation
+ of this field is that the request is being performed on behalf of the
+ person given, who accepts responsibility for the method performed. In
+ particular, robot agents SHOULD include this header so that the
+ person responsible for running the robot can be contacted if problems
+ occur on the receiving end.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 118]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The Internet e-mail address in this field MAY be separate from the
+ Internet host which issued the request. For example, when a request
+ is passed through a proxy the original issuer's address SHOULD be
+ used.
+
+ Note: The client SHOULD not send the From header field without the
+ user's approval, as it may conflict with the user's privacy
+ interests or their site's security policy. It is strongly
+ recommended that the user be able to disable, enable, and modify
+ the value of this field at any time prior to a request.
+
+14.23 Host
+
+ The Host request-header field specifies the Internet host and port
+ number of the resource being requested, as obtained from the original
+ URL given by the user or referring resource (generally an HTTP URL,
+ as described in section 3.2.2). The Host field value MUST represent
+ the network location of the origin server or gateway given by the
+ original URL. This allows the origin server or gateway to
+ differentiate between internally-ambiguous URLs, such as the root "/"
+ URL of a server for multiple host names on a single IP address.
+
+ Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
+
+ A "host" without any trailing port information implies the default
+ port for the service requested (e.g., "80" for an HTTP URL). For
+ example, a request on the origin server for
+ <http://www.w3.org/pub/WWW/> MUST include:
+
+ GET /pub/WWW/ HTTP/1.1
+ Host: www.w3.org
+
+ A client MUST include a Host header field in all HTTP/1.1 request
+ messages on the Internet (i.e., on any message corresponding to a
+ request for a URL which includes an Internet host address for the
+ service being requested). If the Host field is not already present,
+ an HTTP/1.1 proxy MUST add a Host field to the request message prior
+ to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
+ MUST respond with a 400 status code to any HTTP/1.1 request message
+ which lacks a Host header field.
+
+ See sections 5.2 and 19.5.1 for other requirements relating to Host.
+
+14.24 If-Modified-Since
+
+ The If-Modified-Since request-header field is used with the GET
+ method to make it conditional: if the requested variant has not been
+ modified since the time specified in this field, an entity will not
+
+
+
+Fielding, et. al. Standards Track [Page 119]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ be returned from the server; instead, a 304 (not modified) response
+ will be returned without any message-body.
+
+ If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+ An example of the field is:
+
+ If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+ A GET method with an If-Modified-Since header and no Range header
+ requests that the identified entity be transferred only if it has
+ been modified since the date given by the If-Modified-Since header.
+ The algorithm for determining this includes the following cases:
+
+ a)If the request would normally result in anything other than a 200
+ (OK) status, or if the passed If-Modified-Since date is invalid, the
+ response is exactly the same as for a normal GET. A date which is
+ later than the server's current time is invalid.
+
+ b)If the variant has been modified since the If-Modified-Since date,
+ the response is exactly the same as for a normal GET.
+
+ c)If the variant has not been modified since a valid If-Modified-Since
+ date, the server MUST return a 304 (Not Modified) response.
+
+ The purpose of this feature is to allow efficient updates of cached
+ information with a minimum amount of transaction overhead.
+
+ Note that the Range request-header field modifies the meaning of
+ If-Modified-Since; see section 14.36 for full details.
+
+ Note that If-Modified-Since times are interpreted by the server,
+ whose clock may not be synchronized with the client.
+
+ Note that if a client uses an arbitrary date in the If-Modified-Since
+ header instead of a date taken from the Last-Modified header for the
+ same request, the client should be aware of the fact that this date
+ is interpreted in the server's understanding of time. The client
+ should consider unsynchronized clocks and rounding problems due to
+ the different encodings of time between the client and server. This
+ includes the possibility of race conditions if the document has
+ changed between the time it was first requested and the If-Modified-
+ Since date of a subsequent request, and the possibility of clock-
+ skew-related problems if the If-Modified-Since date is derived from
+ the client's clock without correction to the server's clock.
+ Corrections for different time bases between client and server are at
+ best approximate due to network latency.
+
+
+
+
+Fielding, et. al. Standards Track [Page 120]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.25 If-Match
+
+ The If-Match request-header field is used with a method to make it
+ conditional. A client that has one or more entities previously
+ obtained from the resource can verify that one of those entities is
+ current by including a list of their associated entity tags in the
+ If-Match header field. The purpose of this feature is to allow
+ efficient updates of cached information with a minimum amount of
+ transaction overhead. It is also used, on updating requests, to
+ prevent inadvertent modification of the wrong version of a resource.
+ As a special case, the value "*" matches any current entity of the
+ resource.
+
+ If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+ If any of the entity tags match the entity tag of the entity that
+ would have been returned in the response to a similar GET request
+ (without the If-Match header) on that resource, or if "*" is given
+ and any current entity exists for that resource, then the server MAY
+ perform the requested method as if the If-Match header field did not
+ exist.
+
+ A server MUST use the strong comparison function (see section 3.11)
+ to compare the entity tags in If-Match.
+
+ If none of the entity tags match, or if "*" is given and no current
+ entity exists, the server MUST NOT perform the requested method, and
+ MUST return a 412 (Precondition Failed) response. This behavior is
+ most useful when the client wants to prevent an updating method, such
+ as PUT, from modifying a resource that has changed since the client
+ last retrieved it.
+
+ If the request would, without the If-Match header field, result in
+ anything other than a 2xx status, then the If-Match header MUST be
+ ignored.
+
+ The meaning of "If-Match: *" is that the method SHOULD be performed
+ if the representation selected by the origin server (or by a cache,
+ possibly using the Vary mechanism, see section 14.43) exists, and
+ MUST NOT be performed if the representation does not exist.
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 121]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ A request intended to update a resource (e.g., a PUT) MAY include an
+ If-Match header field to signal that the request method MUST NOT be
+ applied if the entity corresponding to the If-Match value (a single
+ entity tag) is no longer a representation of that resource. This
+ allows the user to indicate that they do not wish the request to be
+ successful if the resource has been changed without their knowledge.
+ Examples:
+
+ If-Match: "xyzzy"
+ If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-Match: *
+
+14.26 If-None-Match
+
+ The If-None-Match request-header field is used with a method to make
+ it conditional. A client that has one or more entities previously
+ obtained from the resource can verify that none of those entities is
+ current by including a list of their associated entity tags in the
+ If-None-Match header field. The purpose of this feature is to allow
+ efficient updates of cached information with a minimum amount of
+ transaction overhead. It is also used, on updating requests, to
+ prevent inadvertent modification of a resource which was not known to
+ exist.
+
+ As a special case, the value "*" matches any current entity of the
+ resource.
+
+ If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+ If any of the entity tags match the entity tag of the entity that
+ would have been returned in the response to a similar GET request
+ (without the If-None-Match header) on that resource, or if "*" is
+ given and any current entity exists for that resource, then the
+ server MUST NOT perform the requested method. Instead, if the request
+ method was GET or HEAD, the server SHOULD respond with a 304 (Not
+ Modified) response, including the cache-related entity-header fields
+ (particularly ETag) of one of the entities that matched. For all
+ other request methods, the server MUST respond with a status of 412
+ (Precondition Failed).
+
+ See section 13.3.3 for rules on how to determine if two entity tags
+ match. The weak comparison function can only be used with GET or HEAD
+ requests.
+
+ If none of the entity tags match, or if "*" is given and no current
+ entity exists, then the server MAY perform the requested method as if
+ the If-None-Match header field did not exist.
+
+
+
+
+Fielding, et. al. Standards Track [Page 122]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If the request would, without the If-None-Match header field, result
+ in anything other than a 2xx status, then the If-None-Match header
+ MUST be ignored.
+
+ The meaning of "If-None-Match: *" is that the method MUST NOT be
+ performed if the representation selected by the origin server (or by
+ a cache, possibly using the Vary mechanism, see section 14.43)
+ exists, and SHOULD be performed if the representation does not exist.
+ This feature may be useful in preventing races between PUT
+ operations.
+
+ Examples:
+
+ If-None-Match: "xyzzy"
+ If-None-Match: W/"xyzzy"
+ If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+ If-None-Match: *
+
+14.27 If-Range
+
+ If a client has a partial copy of an entity in its cache, and wishes
+ to have an up-to-date copy of the entire entity in its cache, it
+ could use the Range request-header with a conditional GET (using
+ either or both of If-Unmodified-Since and If-Match.) However, if the
+ condition fails because the entity has been modified, the client
+ would then have to make a second request to obtain the entire current
+ entity-body.
+
+ The If-Range header allows a client to "short-circuit" the second
+ request. Informally, its meaning is `if the entity is unchanged, send
+ me the part(s) that I am missing; otherwise, send me the entire new
+ entity.'
+
+ If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+ If the client has no entity tag for an entity, but does have a Last-
+ Modified date, it may use that date in a If-Range header. (The server
+ can distinguish between a valid HTTP-date and any form of entity-tag
+ by examining no more than two characters.) The If-Range header should
+ only be used together with a Range header, and must be ignored if the
+ request does not include a Range header, or if the server does not
+ support the sub-range operation.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 123]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If the entity tag given in the If-Range header matches the current
+ entity tag for the entity, then the server should provide the
+ specified sub-range of the entity using a 206 (Partial content)
+ response. If the entity tag does not match, then the server should
+ return the entire entity using a 200 (OK) response.
+
+14.28 If-Unmodified-Since
+
+ The If-Unmodified-Since request-header field is used with a method to
+ make it conditional. If the requested resource has not been modified
+ since the time specified in this field, the server should perform the
+ requested operation as if the If-Unmodified-Since header were not
+ present.
+
+ If the requested variant has been modified since the specified time,
+ the server MUST NOT perform the requested operation, and MUST return
+ a 412 (Precondition Failed).
+
+ If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+ An example of the field is:
+
+ If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+ If the request normally (i.e., without the If-Unmodified-Since
+ header) would result in anything other than a 2xx status, the If-
+ Unmodified-Since header should be ignored.
+
+ If the specified date is invalid, the header is ignored.
+
+14.29 Last-Modified
+
+ The Last-Modified entity-header field indicates the date and time at
+ which the origin server believes the variant was last modified.
+
+ Last-Modified = "Last-Modified" ":" HTTP-date
+
+ An example of its use is
+
+ Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+ The exact meaning of this header field depends on the implementation
+ of the origin server and the nature of the original resource. For
+ files, it may be just the file system last-modified time. For
+ entities with dynamically included parts, it may be the most recent
+ of the set of last-modify times for its component parts. For database
+ gateways, it may be the last-update time stamp of the record. For
+ virtual objects, it may be the last time the internal state changed.
+
+
+
+Fielding, et. al. Standards Track [Page 124]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ An origin server MUST NOT send a Last-Modified date which is later
+ than the server's time of message origination. In such cases, where
+ the resource's last modification would indicate some time in the
+ future, the server MUST replace that date with the message
+ origination date.
+
+ An origin server should obtain the Last-Modified value of the entity
+ as close as possible to the time that it generates the Date value of
+ its response. This allows a recipient to make an accurate assessment
+ of the entity's modification time, especially if the entity changes
+ near the time that the response is generated.
+
+ HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 Location
+
+ The Location response-header field is used to redirect the recipient
+ to a location other than the Request-URI for completion of the
+ request or identification of a new resource. For 201 (Created)
+ responses, the Location is that of the new resource which was created
+ by the request. For 3xx responses, the location SHOULD indicate the
+ server's preferred URL for automatic redirection to the resource. The
+ field value consists of a single absolute URL.
+
+ Location = "Location" ":" absoluteURI
+
+ An example is
+
+ Location: http://www.w3.org/pub/WWW/People.html
+
+ Note: The Content-Location header field (section 14.15) differs
+ from Location in that the Content-Location identifies the original
+ location of the entity enclosed in the request. It is therefore
+ possible for a response to contain header fields for both Location
+ and Content-Location. Also see section 13.10 for cache requirements
+ of some methods.
+
+14.31 Max-Forwards
+
+ The Max-Forwards request-header field may be used with the TRACE
+ method (section 14.31) to limit the number of proxies or gateways
+ that can forward the request to the next inbound server. This can be
+ useful when the client is attempting to trace a request chain which
+ appears to be failing or looping in mid-chain.
+
+ Max-Forwards = "Max-Forwards" ":" 1*DIGIT
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 125]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The Max-Forwards value is a decimal integer indicating the remaining
+ number of times this request message may be forwarded.
+
+ Each proxy or gateway recipient of a TRACE request containing a Max-
+ Forwards header field SHOULD check and update its value prior to
+ forwarding the request. If the received value is zero (0), the
+ recipient SHOULD NOT forward the request; instead, it SHOULD respond
+ as the final recipient with a 200 (OK) response containing the
+ received request message as the response entity-body (as described in
+ section 9.8). If the received Max-Forwards value is greater than
+ zero, then the forwarded message SHOULD contain an updated Max-
+ Forwards field with a value decremented by one (1).
+
+ The Max-Forwards header field SHOULD be ignored for all other methods
+ defined by this specification and for any extension methods for which
+ it is not explicitly referred to as part of that method definition.
+
+14.32 Pragma
+
+ The Pragma general-header field is used to include implementation-
+ specific directives that may apply to any recipient along the
+ request/response chain. All pragma directives specify optional
+ behavior from the viewpoint of the protocol; however, some systems
+ MAY require that behavior be consistent with the directives.
+
+ Pragma = "Pragma" ":" 1#pragma-directive
+
+ pragma-directive = "no-cache" | extension-pragma
+ extension-pragma = token [ "=" ( token | quoted-string ) ]
+
+ When the no-cache directive is present in a request message, an
+ application SHOULD forward the request toward the origin server even
+ if it has a cached copy of what is being requested. This pragma
+ directive has the same semantics as the no-cache cache-directive (see
+ section 14.9) and is defined here for backwards compatibility with
+ HTTP/1.0. Clients SHOULD include both header fields when a no-cache
+ request is sent to a server not known to be HTTP/1.1 compliant.
+
+ Pragma directives MUST be passed through by a proxy or gateway
+ application, regardless of their significance to that application,
+ since the directives may be applicable to all recipients along the
+ request/response chain. It is not possible to specify a pragma for a
+ specific recipient; however, any pragma directive not relevant to a
+ recipient SHOULD be ignored by that recipient.
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 126]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
+ caches SHOULD treat "Pragma: no-cache" as if the client had sent
+ "Cache-Control: no-cache". No new Pragma directives will be defined
+ in HTTP.
+
+14.33 Proxy-Authenticate
+
+ The Proxy-Authenticate response-header field MUST be included as part
+ of a 407 (Proxy Authentication Required) response. The field value
+ consists of a challenge that indicates the authentication scheme and
+ parameters applicable to the proxy for this Request-URI.
+
+ Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
+
+ The HTTP access authentication process is described in section 11.
+ Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
+ only to the current connection and SHOULD NOT be passed on to
+ downstream clients. However, an intermediate proxy may need to obtain
+ its own credentials by requesting them from the downstream client,
+ which in some circumstances will appear as if the proxy is forwarding
+ the Proxy-Authenticate header field.
+
+14.34 Proxy-Authorization
+
+ The Proxy-Authorization request-header field allows the client to
+ identify itself (or its user) to a proxy which requires
+ authentication. The Proxy-Authorization field value consists of
+ credentials containing the authentication information of the user
+ agent for the proxy and/or realm of the resource being requested.
+
+ Proxy-Authorization = "Proxy-Authorization" ":" credentials
+
+ The HTTP access authentication process is described in section 11.
+ Unlike Authorization, the Proxy-Authorization header field applies
+ only to the next outbound proxy that demanded authentication using
+ the Proxy-Authenticate field. When multiple proxies are used in a
+ chain, the Proxy-Authorization header field is consumed by the first
+ outbound proxy that was expecting to receive credentials. A proxy MAY
+ relay the credentials from the client request to the next proxy if
+ that is the mechanism by which the proxies cooperatively authenticate
+ a given request.
+
+14.35 Public
+
+ The Public response-header field lists the set of methods supported
+ by the server. The purpose of this field is strictly to inform the
+ recipient of the capabilities of the server regarding unusual
+ methods. The methods listed may or may not be applicable to the
+
+
+
+Fielding, et. al. Standards Track [Page 127]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Request-URI; the Allow header field (section 14.7) MAY be used to
+ indicate methods allowed for a particular URI.
+
+ Public = "Public" ":" 1#method
+
+ Example of use:
+
+ Public: OPTIONS, MGET, MHEAD, GET, HEAD
+
+ This header field applies only to the server directly connected to
+ the client (i.e., the nearest neighbor in a chain of connections). If
+ the response passes through a proxy, the proxy MUST either remove the
+ Public header field or replace it with one applicable to its own
+ capabilities.
+
+14.36 Range
+
+14.36.1 Byte Ranges
+
+ Since all HTTP entities are represented in HTTP messages as sequences
+ of bytes, the concept of a byte range is meaningful for any HTTP
+ entity. (However, not all clients and servers need to support byte-
+ range operations.)
+
+ Byte range specifications in HTTP apply to the sequence of bytes in
+ the entity-body (not necessarily the same as the message-body).
+
+ A byte range operation may specify a single range of bytes, or a set
+ of ranges within a single entity.
+
+ ranges-specifier = byte-ranges-specifier
+
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+
+ byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
+
+ byte-range-spec = first-byte-pos "-" [last-byte-pos]
+
+ first-byte-pos = 1*DIGIT
+
+ last-byte-pos = 1*DIGIT
+
+ The first-byte-pos value in a byte-range-spec gives the byte-offset
+ of the first byte in a range. The last-byte-pos value gives the
+ byte-offset of the last byte in the range; that is, the byte
+ positions specified are inclusive. Byte offsets start at zero.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 128]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ If the last-byte-pos value is present, it must be greater than or
+ equal to the first-byte-pos in that byte-range-spec, or the byte-
+ range-spec is invalid. The recipient of an invalid byte-range-spec
+ must ignore it.
+
+ If the last-byte-pos value is absent, or if the value is greater than
+ or equal to the current length of the entity-body, last-byte-pos is
+ taken to be equal to one less than the current length of the entity-
+ body in bytes.
+
+ By its choice of last-byte-pos, a client can limit the number of
+ bytes retrieved without knowing the size of the entity.
+
+ suffix-byte-range-spec = "-" suffix-length
+
+ suffix-length = 1*DIGIT
+
+ A suffix-byte-range-spec is used to specify the suffix of the
+ entity-body, of a length given by the suffix-length value. (That is,
+ this form specifies the last N bytes of an entity-body.) If the
+ entity is shorter than the specified suffix-length, the entire
+ entity-body is used.
+
+ Examples of byte-ranges-specifier values (assuming an entity-body of
+ length 10000):
+
+ o The first 500 bytes (byte offsets 0-499, inclusive):
+
+ bytes=0-499
+
+ o The second 500 bytes (byte offsets 500-999, inclusive):
+
+ bytes=500-999
+
+ o The final 500 bytes (byte offsets 9500-9999, inclusive):
+
+ bytes=-500
+
+ o Or
+
+ bytes=9500-
+
+ o The first and last bytes only (bytes 0 and 9999):
+
+ bytes=0-0,-1
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 129]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ o Several legal but not canonical specifications of the second
+ 500 bytes (byte offsets 500-999, inclusive):
+
+ bytes=500-600,601-999
+
+ bytes=500-700,601-999
+
+14.36.2 Range Retrieval Requests
+
+ HTTP retrieval requests using conditional or unconditional GET
+ methods may request one or more sub-ranges of the entity, instead of
+ the entire entity, using the Range request header, which applies to
+ the entity returned as the result of the request:
+
+ Range = "Range" ":" ranges-specifier
+
+ A server MAY ignore the Range header. However, HTTP/1.1 origin
+ servers and intermediate caches SHOULD support byte ranges when
+ possible, since Range supports efficient recovery from partially
+ failed transfers, and supports efficient partial retrieval of large
+ entities.
+
+ If the server supports the Range header and the specified range or
+ ranges are appropriate for the entity:
+
+ o The presence of a Range header in an unconditional GET modifies
+ what is returned if the GET is otherwise successful. In other
+ words, the response carries a status code of 206 (Partial
+ Content) instead of 200 (OK).
+
+ o The presence of a Range header in a conditional GET (a request
+ using one or both of If-Modified-Since and If-None-Match, or
+ one or both of If-Unmodified-Since and If-Match) modifies what
+ is returned if the GET is otherwise successful and the condition
+ is true. It does not affect the 304 (Not Modified) response
+ returned if the conditional is false.
+
+ In some cases, it may be more appropriate to use the If-Range header
+ (see section 14.27) in addition to the Range header.
+
+ If a proxy that supports ranges receives a Range request, forwards
+ the request to an inbound server, and receives an entire entity in
+ reply, it SHOULD only return the requested range to its client. It
+ SHOULD store the entire received response in its cache, if that is
+ consistent with its cache allocation policies.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 130]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.37 Referer
+
+ The Referer[sic] request-header field allows the client to specify,
+ for the server's benefit, the address (URI) of the resource from
+ which the Request-URI was obtained (the "referrer", although the
+ header field is misspelled.) The Referer request-header allows a
+ server to generate lists of back-links to resources for interest,
+ logging, optimized caching, etc. It also allows obsolete or mistyped
+ links to be traced for maintenance. The Referer field MUST NOT be
+ sent if the Request-URI was obtained from a source that does not have
+ its own URI, such as input from the user keyboard.
+
+ Referer = "Referer" ":" ( absoluteURI | relativeURI )
+
+ Example:
+
+ Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+ If the field value is a partial URI, it SHOULD be interpreted
+ relative to the Request-URI. The URI MUST NOT include a fragment.
+
+ Note: Because the source of a link may be private information or
+ may reveal an otherwise private information source, it is strongly
+ recommended that the user be able to select whether or not the
+ Referer field is sent. For example, a browser client could have a
+ toggle switch for browsing openly/anonymously, which would
+ respectively enable/disable the sending of Referer and From
+ information.
+
+14.38 Retry-After
+
+ The Retry-After response-header field can be used with a 503 (Service
+ Unavailable) response to indicate how long the service is expected to
+ be unavailable to the requesting client. The value of this field can
+ be either an HTTP-date or an integer number of seconds (in decimal)
+ after the time of the response.
+
+ Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+ Two examples of its use are
+
+ Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+ Retry-After: 120
+
+ In the latter example, the delay is 2 minutes.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 131]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.39 Server
+
+ The Server response-header field contains information about the
+ software used by the origin server to handle the request. The field
+ can contain multiple product tokens (section 3.8) and comments
+ identifying the server and any significant subproducts. The product
+ tokens are listed in order of their significance for identifying the
+ application.
+
+ Server = "Server" ":" 1*( product | comment )
+
+ Example:
+
+ Server: CERN/3.0 libwww/2.17
+
+ If the response is being forwarded through a proxy, the proxy
+ application MUST NOT modify the Server response-header. Instead, it
+ SHOULD include a Via field (as described in section 14.44).
+
+ Note: Revealing the specific software version of the server may
+ allow the server machine to become more vulnerable to attacks
+ against software that is known to contain security holes. Server
+ implementers are encouraged to make this field a configurable
+ option.
+
+14.40 Transfer-Encoding
+
+ The Transfer-Encoding general-header field indicates what (if any)
+ type of transformation has been applied to the message body in order
+ to safely transfer it between the sender and the recipient. This
+ differs from the Content-Encoding in that the transfer coding is a
+ property of the message, not of the entity.
+
+ Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-
+ coding
+
+ Transfer codings are defined in section 3.6. An example is:
+
+ Transfer-Encoding: chunked
+
+ Many older HTTP/1.0 applications do not understand the Transfer-
+ Encoding header.
+
+14.41 Upgrade
+
+ The Upgrade general-header allows the client to specify what
+ additional communication protocols it supports and would like to use
+ if the server finds it appropriate to switch protocols. The server
+
+
+
+Fielding, et. al. Standards Track [Page 132]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ MUST use the Upgrade header field within a 101 (Switching Protocols)
+ response to indicate which protocol(s) are being switched.
+
+ Upgrade = "Upgrade" ":" 1#product
+
+ For example,
+
+ Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+ The Upgrade header field is intended to provide a simple mechanism
+ for transition from HTTP/1.1 to some other, incompatible protocol. It
+ does so by allowing the client to advertise its desire to use another
+ protocol, such as a later version of HTTP with a higher major version
+ number, even though the current request has been made using HTTP/1.1.
+ This eases the difficult transition between incompatible protocols by
+ allowing the client to initiate a request in the more commonly
+ supported protocol while indicating to the server that it would like
+ to use a "better" protocol if available (where "better" is determined
+ by the server, possibly according to the nature of the method and/or
+ resource being requested).
+
+ The Upgrade header field only applies to switching application-layer
+ protocols upon the existing transport-layer connection. Upgrade
+ cannot be used to insist on a protocol change; its acceptance and use
+ by the server is optional. The capabilities and nature of the
+ application-layer communication after the protocol change is entirely
+ dependent upon the new protocol chosen, although the first action
+ after changing the protocol MUST be a response to the initial HTTP
+ request containing the Upgrade header field.
+
+ The Upgrade header field only applies to the immediate connection.
+ Therefore, the upgrade keyword MUST be supplied within a Connection
+ header field (section 14.10) whenever Upgrade is present in an
+ HTTP/1.1 message.
+
+ The Upgrade header field cannot be used to indicate a switch to a
+ protocol on a different connection. For that purpose, it is more
+ appropriate to use a 301, 302, 303, or 305 redirection response.
+
+ This specification only defines the protocol name "HTTP" for use by
+ the family of Hypertext Transfer Protocols, as defined by the HTTP
+ version rules of section 3.1 and future updates to this
+ specification. Any token can be used as a protocol name; however, it
+ will only be useful if both the client and server associate the name
+ with the same protocol.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 133]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14.42 User-Agent
+
+ The User-Agent request-header field contains information about the
+ user agent originating the request. This is for statistical purposes,
+ the tracing of protocol violations, and automated recognition of user
+ agents for the sake of tailoring responses to avoid particular user
+ agent limitations. User agents SHOULD include this field with
+ requests. The field can contain multiple product tokens (section 3.8)
+ and comments identifying the agent and any subproducts which form a
+ significant part of the user agent. By convention, the product tokens
+ are listed in order of their significance for identifying the
+ application.
+
+ User-Agent = "User-Agent" ":" 1*( product | comment )
+
+ Example:
+
+ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+14.43 Vary
+
+ The Vary response-header field is used by a server to signal that the
+ response entity was selected from the available representations of
+ the response using server-driven negotiation (section 12). Field-
+ names listed in Vary headers are those of request-headers. The Vary
+ field value indicates either that the given set of header fields
+ encompass the dimensions over which the representation might vary, or
+ that the dimensions of variance are unspecified ("*") and thus may
+ vary over any aspect of future requests.
+
+ Vary = "Vary" ":" ( "*" | 1#field-name )
+
+ An HTTP/1.1 server MUST include an appropriate Vary header field with
+ any cachable response that is subject to server-driven negotiation.
+ Doing so allows a cache to properly interpret future requests on that
+ resource and informs the user agent about the presence of negotiation
+ on that resource. A server SHOULD include an appropriate Vary header
+ field with a non-cachable response that is subject to server-driven
+ negotiation, since this might provide the user agent with useful
+ information about the dimensions over which the response might vary.
+
+ The set of header fields named by the Vary field value is known as
+ the "selecting" request-headers.
+
+ When the cache receives a subsequent request whose Request-URI
+ specifies one or more cache entries including a Vary header, the
+ cache MUST NOT use such a cache entry to construct a response to the
+ new request unless all of the headers named in the cached Vary header
+
+
+
+Fielding, et. al. Standards Track [Page 134]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ are present in the new request, and all of the stored selecting
+ request-headers from the previous request match the corresponding
+ headers in the new request.
+
+ The selecting request-headers from two requests are defined to match
+ if and only if the selecting request-headers in the first request can
+ be transformed to the selecting request-headers in the second request
+ by adding or removing linear whitespace (LWS) at places where this is
+ allowed by the corresponding BNF, and/or combining multiple message-
+ header fields with the same field name following the rules about
+ message headers in section 4.2.
+
+ A Vary field value of "*" signals that unspecified parameters,
+ possibly other than the contents of request-header fields (e.g., the
+ network address of the client), play a role in the selection of the
+ response representation. Subsequent requests on that resource can
+ only be properly interpreted by the origin server, and thus a cache
+ MUST forward a (possibly conditional) request even when it has a
+ fresh response cached for the resource. See section 13.6 for use of
+ the Vary header by caches.
+
+ A Vary field value consisting of a list of field-names signals that
+ the representation selected for the response is based on a selection
+ algorithm which considers ONLY the listed request-header field values
+ in selecting the most appropriate representation. A cache MAY assume
+ that the same selection will be made for future requests with the
+ same values for the listed field names, for the duration of time in
+ which the response is fresh.
+
+ The field-names given are not limited to the set of standard
+ request-header fields defined by this specification. Field names are
+ case-insensitive.
+
+14.44 Via
+
+ The Via general-header field MUST be used by gateways and proxies to
+ indicate the intermediate protocols and recipients between the user
+ agent and the server on requests, and between the origin server and
+ the client on responses. It is analogous to the "Received" field of
+ RFC 822 and is intended to be used for tracking message forwards,
+ avoiding request loops, and identifying the protocol capabilities of
+ all senders along the request/response chain.
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 135]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
+
+ received-protocol = [ protocol-name "/" ] protocol-version
+ protocol-name = token
+ protocol-version = token
+ received-by = ( host [ ":" port ] ) | pseudonym
+ pseudonym = token
+
+ The received-protocol indicates the protocol version of the message
+ received by the server or client along each segment of the
+ request/response chain. The received-protocol version is appended to
+ the Via field value when the message is forwarded so that information
+ about the protocol capabilities of upstream applications remains
+ visible to all recipients.
+
+ The protocol-name is optional if and only if it would be "HTTP". The
+ received-by field is normally the host and optional port number of a
+ recipient server or client that subsequently forwarded the message.
+ However, if the real host is considered to be sensitive information,
+ it MAY be replaced by a pseudonym. If the port is not given, it MAY
+ be assumed to be the default port of the received-protocol.
+
+ Multiple Via field values represent each proxy or gateway that has
+ forwarded the message. Each recipient MUST append its information
+ such that the end result is ordered according to the sequence of
+ forwarding applications.
+
+ Comments MAY be used in the Via header field to identify the software
+ of the recipient proxy or gateway, analogous to the User-Agent and
+ Server header fields. However, all comments in the Via field are
+ optional and MAY be removed by any recipient prior to forwarding the
+ message.
+
+ For example, a request message could be sent from an HTTP/1.0 user
+ agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
+ forward the request to a public proxy at nowhere.com, which completes
+ the request by forwarding it to the origin server at www.ics.uci.edu.
+ The request received by www.ics.uci.edu would then have the following
+ Via header field:
+
+ Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+ Proxies and gateways used as a portal through a network firewall
+ SHOULD NOT, by default, forward the names and ports of hosts within
+ the firewall region. This information SHOULD only be propagated if
+ explicitly enabled. If not enabled, the received-by host of any host
+ behind the firewall SHOULD be replaced by an appropriate pseudonym
+ for that host.
+
+
+
+Fielding, et. al. Standards Track [Page 136]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ For organizations that have strong privacy requirements for hiding
+ internal structures, a proxy MAY combine an ordered subsequence of
+ Via header field entries with identical received-protocol values into
+ a single such entry. For example,
+
+ Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+ could be collapsed to
+
+ Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+ Applications SHOULD NOT combine multiple entries unless they are all
+ under the same organizational control and the hosts have already been
+ replaced by pseudonyms. Applications MUST NOT combine entries which
+ have different received-protocol values.
+
+14.45 Warning
+
+ The Warning response-header field is used to carry additional
+ information about the status of a response which may not be reflected
+ by the response status code. This information is typically, though
+ not exclusively, used to warn about a possible lack of semantic
+ transparency from caching operations.
+
+ Warning headers are sent with responses using:
+
+ Warning = "Warning" ":" 1#warning-value
+
+ warning-value = warn-code SP warn-agent SP warn-text
+ warn-code = 2DIGIT
+ warn-agent = ( host [ ":" port ] ) | pseudonym
+ ; the name or pseudonym of the server adding
+ ; the Warning header, for use in debugging
+ warn-text = quoted-string
+
+ A response may carry more than one Warning header.
+
+ The warn-text should be in a natural language and character set that
+ is most likely to be intelligible to the human user receiving the
+ response. This decision may be based on any available knowledge,
+ such as the location of the cache or user, the Accept-Language field
+ in a request, the Content-Language field in a response, etc. The
+ default language is English and the default character set is ISO-
+ 8859-1.
+
+ If a character set other than ISO-8859-1 is used, it MUST be encoded
+ in the warn-text using the method described in RFC 1522 [14].
+
+
+
+
+Fielding, et. al. Standards Track [Page 137]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Any server or cache may add Warning headers to a response. New
+ Warning headers should be added after any existing Warning headers. A
+ cache MUST NOT delete any Warning header that it received with a
+ response. However, if a cache successfully validates a cache entry,
+ it SHOULD remove any Warning headers previously attached to that
+ entry except as specified for specific Warning codes. It MUST then
+ add any Warning headers received in the validating response. In other
+ words, Warning headers are those that would be attached to the most
+ recent relevant response.
+
+ When multiple Warning headers are attached to a response, the user
+ agent SHOULD display as many of them as possible, in the order that
+ they appear in the response. If it is not possible to display all of
+ the warnings, the user agent should follow these heuristics:
+
+ o Warnings that appear early in the response take priority over those
+ appearing later in the response.
+ o Warnings in the user's preferred character set take priority over
+ warnings in other character sets but with identical warn-codes and
+ warn-agents.
+
+ Systems that generate multiple Warning headers should order them with
+ this user agent behavior in mind.
+
+ This is a list of the currently-defined warn-codes, each with a
+ recommended warn-text in English, and a description of its meaning.
+
+10 Response is stale
+ MUST be included whenever the returned response is stale. A cache may
+ add this warning to any response, but may never remove it until the
+ response is known to be fresh.
+
+11 Revalidation failed
+ MUST be included if a cache returns a stale response because an
+ attempt to revalidate the response failed, due to an inability to
+ reach the server. A cache may add this warning to any response, but
+ may never remove it until the response is successfully revalidated.
+
+12 Disconnected operation
+ SHOULD be included if the cache is intentionally disconnected from
+ the rest of the network for a period of time.
+
+13 Heuristic expiration
+ MUST be included if the cache heuristically chose a freshness
+ lifetime greater than 24 hours and the response's age is greater than
+ 24 hours.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 138]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+14 Transformation applied
+ MUST be added by an intermediate cache or proxy if it applies any
+ transformation changing the content-coding (as specified in the
+ Content-Encoding header) or media-type (as specified in the
+ Content-Type header) of the response, unless this Warning code
+ already appears in the response. MUST NOT be deleted from a response
+ even after revalidation.
+
+99 Miscellaneous warning
+ The warning text may include arbitrary information to be presented to
+ a human user, or logged. A system receiving this warning MUST NOT
+ take any automated action.
+
+14.46 WWW-Authenticate
+
+ The WWW-Authenticate response-header field MUST be included in 401
+ (Unauthorized) response messages. The field value consists of at
+ least one challenge that indicates the authentication scheme(s) and
+ parameters applicable to the Request-URI.
+
+ WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
+
+ The HTTP access authentication process is described in section 11.
+ User agents MUST take special care in parsing the WWW-Authenticate
+ field value if it contains more than one challenge, or if more than
+ one WWW-Authenticate header field is provided, since the contents of
+ a challenge may itself contain a comma-separated list of
+ authentication parameters.
+
+15 Security Considerations
+
+ This section is meant to inform application developers, information
+ providers, and users of the security limitations in HTTP/1.1 as
+ described by this document. The discussion does not include
+ definitive solutions to the problems revealed, though it does make
+ some suggestions for reducing security risks.
+
+15.1 Authentication of Clients
+
+ The Basic authentication scheme is not a secure method of user
+ authentication, nor does it in any way protect the entity, which is
+ transmitted in clear text across the physical network used as the
+ carrier. HTTP does not prevent additional authentication schemes and
+ encryption mechanisms from being employed to increase security or the
+ addition of enhancements (such as schemes to use one-time passwords)
+ to Basic authentication.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 139]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The most serious flaw in Basic authentication is that it results in
+ the essentially clear text transmission of the user's password over
+ the physical network. It is this problem which Digest Authentication
+ attempts to address.
+
+ Because Basic authentication involves the clear text transmission of
+ passwords it SHOULD never be used (without enhancements) to protect
+ sensitive or valuable information.
+
+ A common use of Basic authentication is for identification purposes
+ -- requiring the user to provide a user name and password as a means
+ of identification, for example, for purposes of gathering accurate
+ usage statistics on a server. When used in this way it is tempting to
+ think that there is no danger in its use if illicit access to the
+ protected documents is not a major concern. This is only correct if
+ the server issues both user name and password to the users and in
+ particular does not allow the user to choose his or her own password.
+ The danger arises because naive users frequently reuse a single
+ password to avoid the task of maintaining multiple passwords.
+
+ If a server permits users to select their own passwords, then the
+ threat is not only illicit access to documents on the server but also
+ illicit access to the accounts of all users who have chosen to use
+ their account password. If users are allowed to choose their own
+ password that also means the server must maintain files containing
+ the (presumably encrypted) passwords. Many of these may be the
+ account passwords of users perhaps at distant sites. The owner or
+ administrator of such a system could conceivably incur liability if
+ this information is not maintained in a secure fashion.
+
+ Basic Authentication is also vulnerable to spoofing by counterfeit
+ servers. If a user can be led to believe that he is connecting to a
+ host containing information protected by basic authentication when in
+ fact he is connecting to a hostile server or gateway then the
+ attacker can request a password, store it for later use, and feign an
+ error. This type of attack is not possible with Digest Authentication
+ [32]. Server implementers SHOULD guard against the possibility of
+ this sort of counterfeiting by gateways or CGI scripts. In particular
+ it is very dangerous for a server to simply turn over a connection to
+ a gateway since that gateway can then use the persistent connection
+ mechanism to engage in multiple transactions with the client while
+ impersonating the original server in a way that is not detectable by
+ the client.
+
+15.2 Offering a Choice of Authentication Schemes
+
+ An HTTP/1.1 server may return multiple challenges with a 401
+ (Authenticate) response, and each challenge may use a different
+
+
+
+Fielding, et. al. Standards Track [Page 140]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ scheme. The order of the challenges returned to the user agent is in
+ the order that the server would prefer they be chosen. The server
+ should order its challenges with the "most secure" authentication
+ scheme first. A user agent should choose as the challenge to be made
+ to the user the first one that the user agent understands.
+
+ When the server offers choices of authentication schemes using the
+ WWW-Authenticate header, the "security" of the authentication is only
+ as malicious user could capture the set of challenges and try to
+ authenticate him/herself using the weakest of the authentication
+ schemes. Thus, the ordering serves more to protect the user's
+ credentials than the server's information.
+
+ A possible man-in-the-middle (MITM) attack would be to add a weak
+ authentication scheme to the set of choices, hoping that the client
+ will use one that exposes the user's credentials (e.g. password). For
+ this reason, the client should always use the strongest scheme that
+ it understands from the choices accepted.
+
+ An even better MITM attack would be to remove all offered choices,
+ and to insert a challenge that requests Basic authentication. For
+ this reason, user agents that are concerned about this kind of attack
+ could remember the strongest authentication scheme ever requested by
+ a server and produce a warning message that requires user
+ confirmation before using a weaker one. A particularly insidious way
+ to mount such a MITM attack would be to offer a "free" proxy caching
+ service to gullible users.
+
+15.3 Abuse of Server Log Information
+
+ A server is in the position to save personal data about a user's
+ requests which may identify their reading patterns or subjects of
+ interest. This information is clearly confidential in nature and its
+ handling may be constrained by law in certain countries. People using
+ the HTTP protocol to provide data are responsible for ensuring that
+ such material is not distributed without the permission of any
+ individuals that are identifiable by the published results.
+
+15.4 Transfer of Sensitive Information
+
+ Like any generic data transfer protocol, HTTP cannot regulate the
+ content of the data that is transferred, nor is there any a priori
+ method of determining the sensitivity of any particular piece of
+ information within the context of any given request. Therefore,
+ applications SHOULD supply as much control over this information as
+ possible to the provider of that information. Four header fields are
+ worth special mention in this context: Server, Via, Referer and From.
+
+
+
+
+Fielding, et. al. Standards Track [Page 141]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Revealing the specific software version of the server may allow the
+ server machine to become more vulnerable to attacks against software
+ that is known to contain security holes. Implementers SHOULD make the
+ Server header field a configurable option.
+
+ Proxies which serve as a portal through a network firewall SHOULD
+ take special precautions regarding the transfer of header information
+ that identifies the hosts behind the firewall. In particular, they
+ SHOULD remove, or replace with sanitized versions, any Via fields
+ generated behind the firewall.
+
+ The Referer field allows reading patterns to be studied and reverse
+ links drawn. Although it can be very useful, its power can be abused
+ if user details are not separated from the information contained in
+ the Referer. Even when the personal information has been removed, the
+ Referer field may indicate a private document's URI whose publication
+ would be inappropriate.
+
+ The information sent in the From field might conflict with the user's
+ privacy interests or their site's security policy, and hence it
+ SHOULD NOT be transmitted without the user being able to disable,
+ enable, and modify the contents of the field. The user MUST be able
+ to set the contents of this field within a user preference or
+ application defaults configuration.
+
+ We suggest, though do not require, that a convenient toggle interface
+ be provided for the user to enable or disable the sending of From and
+ Referer information.
+
+15.5 Attacks Based On File and Path Names
+
+ Implementations of HTTP origin servers SHOULD be careful to restrict
+ the documents returned by HTTP requests to be only those that were
+ intended by the server administrators. If an HTTP server translates
+ HTTP URIs directly into file system calls, the server MUST take
+ special care not to serve files that were not intended to be
+ delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
+ other operating systems use ".." as a path component to indicate a
+ directory level above the current one. On such a system, an HTTP
+ server MUST disallow any such construct in the Request-URI if it
+ would otherwise allow access to a resource outside those intended to
+ be accessible via the HTTP server. Similarly, files intended for
+ reference only internally to the server (such as access control
+ files, configuration files, and script code) MUST be protected from
+ inappropriate retrieval, since they might contain sensitive
+ information. Experience has shown that minor bugs in such HTTP server
+ implementations have turned into security risks.
+
+
+
+
+Fielding, et. al. Standards Track [Page 142]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+15.6 Personal Information
+
+ HTTP clients are often privy to large amounts of personal information
+ (e.g. the user's name, location, mail address, passwords, encryption
+ keys, etc.), and SHOULD be very careful to prevent unintentional
+ leakage of this information via the HTTP protocol to other sources.
+ We very strongly recommend that a convenient interface be provided
+ for the user to control dissemination of such information, and that
+ designers and implementers be particularly careful in this area.
+ History shows that errors in this area are often both serious
+ security and/or privacy problems, and often generate highly adverse
+ publicity for the implementer's company.
+
+15.7 Privacy Issues Connected to Accept Headers
+
+ Accept request-headers can reveal information about the user to all
+ servers which are accessed. The Accept-Language header in particular
+ can reveal information the user would consider to be of a private
+ nature, because the understanding of particular languages is often
+ strongly correlated to the membership of a particular ethnic group.
+ User agents which offer the option to configure the contents of an
+ Accept-Language header to be sent in every request are strongly
+ encouraged to let the configuration process include a message which
+ makes the user aware of the loss of privacy involved.
+
+ An approach that limits the loss of privacy would be for a user agent
+ to omit the sending of Accept-Language headers by default, and to ask
+ the user whether it should start sending Accept-Language headers to a
+ server if it detects, by looking for any Vary response-header fields
+ generated by the server, that such sending could improve the quality
+ of service.
+
+ Elaborate user-customized accept header fields sent in every request,
+ in particular if these include quality values, can be used by servers
+ as relatively reliable and long-lived user identifiers. Such user
+ identifiers would allow content providers to do click-trail tracking,
+ and would allow collaborating content providers to match cross-server
+ click-trails or form submissions of individual users. Note that for
+ many users not behind a proxy, the network address of the host
+ running the user agent will also serve as a long-lived user
+ identifier. In environments where proxies are used to enhance
+ privacy, user agents should be conservative in offering accept header
+ configuration options to end users. As an extreme privacy measure,
+ proxies could filter the accept headers in relayed requests. General
+ purpose user agents which provide a high degree of header
+ configurability should warn users about the loss of privacy which can
+ be involved.
+
+
+
+
+Fielding, et. al. Standards Track [Page 143]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+15.8 DNS Spoofing
+
+ Clients using HTTP rely heavily on the Domain Name Service, and are
+ thus generally prone to security attacks based on the deliberate
+ mis-association of IP addresses and DNS names. Clients need to be
+ cautious in assuming the continuing validity of an IP number/DNS name
+ association.
+
+ In particular, HTTP clients SHOULD rely on their name resolver for
+ confirmation of an IP number/DNS name association, rather than
+ caching the result of previous host name lookups. Many platforms
+ already can cache host name lookups locally when appropriate, and
+ they SHOULD be configured to do so. These lookups should be cached,
+ however, only when the TTL (Time To Live) information reported by the
+ name server makes it likely that the cached information will remain
+ useful.
+
+ If HTTP clients cache the results of host name lookups in order to
+ achieve a performance improvement, they MUST observe the TTL
+ information reported by DNS.
+
+ If HTTP clients do not observe this rule, they could be spoofed when
+ a previously-accessed server's IP address changes. As network
+ renumbering is expected to become increasingly common, the
+ possibility of this form of attack will grow. Observing this
+ requirement thus reduces this potential security vulnerability.
+
+ This requirement also improves the load-balancing behavior of clients
+ for replicated servers using the same DNS name and reduces the
+ likelihood of a user's experiencing failure in accessing sites which
+ use that strategy.
+
+15.9 Location Headers and Spoofing
+
+ If a single server supports multiple organizations that do not trust
+ one another, then it must check the values of Location and Content-
+ Location headers in responses that are generated under control of
+ said organizations to make sure that they do not attempt to
+ invalidate resources over which they have no authority.
+
+16 Acknowledgments
+
+ This specification makes heavy use of the augmented BNF and generic
+ constructs defined by David H. Crocker for RFC 822. Similarly, it
+ reuses many of the definitions provided by Nathaniel Borenstein and
+ Ned Freed for MIME. We hope that their inclusion in this
+ specification will help reduce past confusion over the relationship
+ between HTTP and Internet mail message formats.
+
+
+
+Fielding, et. al. Standards Track [Page 144]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The HTTP protocol has evolved considerably over the past four years.
+ It has benefited from a large and active developer community--the
+ many people who have participated on the www-talk mailing list--and
+ it is that community which has been most responsible for the success
+ of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
+ Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
+ Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
+ McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
+ VanHeyningen deserve special recognition for their efforts in
+ defining early aspects of the protocol.
+
+ This document has benefited greatly from the comments of all those
+ participating in the HTTP-WG. In addition to those already mentioned,
+ the following individuals have contributed to this specification:
+
+ Gary Adams Albert Lunde
+ Harald Tveit Alvestrand John C. Mallery
+ Keith Ball Jean-Philippe Martin-Flatin
+ Brian Behlendorf Larry Masinter
+ Paul Burchard Mitra
+ Maurizio Codogno David Morris
+ Mike Cowlishaw Gavin Nicol
+ Roman Czyborra Bill Perry
+ Michael A. Dolan Jeffrey Perry
+ David J. Fiander Scott Powers
+ Alan Freier Owen Rees
+ Marc Hedlund Luigi Rizzo
+ Greg Herlihy David Robinson
+ Koen Holtman Marc Salomon
+ Alex Hopmann Rich Salz
+ Bob Jernigan Allan M. Schiffman
+ Shel Kaphan Jim Seidman
+ Rohit Khare Chuck Shotton
+ John Klensin Eric W. Sink
+ Martijn Koster Simon E. Spero
+ Alexei Kosut Richard N. Taylor
+ David M. Kristol Robert S. Thau
+ Daniel LaLiberte Bill (BearHeart) Weinman
+ Ben Laurie Francois Yergeau
+ Paul J. Leach Mary Ellen Zurko
+ Daniel DuBois
+
+ Much of the content and presentation of the caching design is due to
+ suggestions and comments from individuals including: Shel Kaphan,
+ Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 145]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Most of the specification of ranges is based on work originally done
+ by Ari Luotonen and John Franks, with additional input from Steve
+ Zilles.
+
+ Thanks to the "cave men" of Palo Alto. You know who you are.
+
+ Jim Gettys (the current editor of this document) wishes particularly
+ to thank Roy Fielding, the previous editor of this document, along
+ with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+ Holtman, John Franks, Alex Hopmann, and Larry Masinter for their
+ help.
+
+17 References
+
+ [1] Alvestrand, H., "Tags for the identification of languages", RFC
+ 1766, UNINETT, March 1995.
+
+ [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+ D., and B. Alberti. "The Internet Gopher Protocol: (a distributed
+ document search and retrieval protocol)", RFC 1436, University of
+ Minnesota, March 1993.
+
+ [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A
+ Unifying Syntax for the Expression of Names and Addresses of Objects
+ on the Network as used in the World-Wide Web", RFC 1630, CERN, June
+ 1994.
+
+ [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
+ December 1994.
+
+ [5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language
+ Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
+
+ [6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+ Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May
+ 1996.
+
+ [7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
+ 2045, Innosoft, First Virtual, November 1996.
+
+ [8] Braden, R., "Requirements for Internet hosts - application and
+ support", STD 3, RFC 1123, IETF, October 1989.
+
+ [9] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+
+
+
+Fielding, et. al. Standards Track [Page 146]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+ Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype
+ Functional Specification", (v1.5), Thinking Machines Corporation,
+ April 1990.
+
+ [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC
+ Irvine, June 1995.
+
+ [12] Horton, M., and R. Adams. "Standard for interchange of USENET
+ messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
+ Studies, December 1987.
+
+ [13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A
+ Proposed Standard for the Stream-Based Transmission of News", RFC
+ 977, UC San Diego, UC Berkeley, February 1986.
+
+ [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+ Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+ University of Tennessee, November 1996.
+
+ [15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML",
+ RFC 1867, Xerox Corporation, November 1995.
+
+ [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/ISI, August 1982.
+
+ [17] Postel, J., "Media Type Registration Procedure", RFC 2048,
+ USC/ISI, November 1996.
+
+ [18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD
+ 9, RFC 959, USC/ISI, October 1985.
+
+ [19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, USC/ISI, October 1994.
+
+ [20] Sollins, K., and L. Masinter, "Functional Requirements for
+ Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
+ December 1994.
+
+ [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+ Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+ [22] ISO-8859. International Standard -- Information Processing --
+ 8-bit Single-Byte Coded Graphic Character Sets --
+ Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
+ Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
+ Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
+ Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
+
+
+
+Fielding, et. al. Standards Track [Page 147]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
+ Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
+ Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
+ Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
+ Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
+
+ [23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC
+ 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995.
+
+ [24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC
+ 1900, IAB, February 1996.
+
+ [25] Deutsch, P., "GZIP file format specification version 4.3." RFC
+ 1952, Aladdin Enterprises, May 1996.
+
+ [26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP
+ Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec.
+ 1995. Slightly revised version of paper in Proc. 2nd International
+ WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at
+ http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/
+ HTTPLatency.html.
+
+ [27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP
+ Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>,
+ USC/Information Sciences Institute, June 1996
+
+ [28] Mills, D., "Network Time Protocol, Version 3, Specification,
+ Implementation and Analysis", RFC 1305, University of Delaware, March
+ 1992.
+
+ [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+ version 1.3." RFC 1951, Aladdin Enterprises, May 1996.
+
+ [30] Spero, S., "Analysis of HTTP Performance Problems"
+ <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>.
+
+ [31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP,
+ May 1996.
+
+ [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+ Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP :
+ Digest Access Authentication", RFC 2069, January 1997.
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 148]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+18 Authors' Addresses
+
+ Roy T. Fielding
+ Department of Information and Computer Science
+ University of California
+ Irvine, CA 92717-3425, USA
+
+ Fax: +1 (714) 824-4056
+ EMail: fielding@ics.uci.edu
+
+
+ Jim Gettys
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: jg@w3.org
+
+
+ Jeffrey C. Mogul
+ Western Research Laboratory
+ Digital Equipment Corporation
+ 250 University Avenue
+ Palo Alto, California, 94305, USA
+
+ EMail: mogul@wrl.dec.com
+
+
+ Henrik Frystyk Nielsen
+ W3 Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: frystyk@w3.org
+
+
+ Tim Berners-Lee
+ Director, W3 Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: timbl@w3.org
+
+
+
+
+Fielding, et. al. Standards Track [Page 149]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http
+
+ In addition to defining the HTTP/1.1 protocol, this document serves
+ as the specification for the Internet media type "message/http". The
+ following is to be registered with IANA.
+
+ Media Type name: message
+ Media subtype name: http
+ Required parameters: none
+ Optional parameters: version, msgtype
+
+ version: The HTTP-Version number of the enclosed message
+ (e.g., "1.1"). If not present, the version can be
+ determined from the first line of the body.
+
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first
+ line of the body.
+
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+
+ Security considerations: none
+
+19.2 Internet Media Type multipart/byteranges
+
+ When an HTTP message includes the content of multiple ranges (for
+ example, a response to a request for multiple non-overlapping
+ ranges), these are transmitted as a multipart MIME message. The
+ multipart media type for this purpose is called
+ "multipart/byteranges".
+
+ The multipart/byteranges media type includes two or more parts, each
+ with its own Content-Type and Content-Range fields. The parts are
+ separated using a MIME boundary parameter.
+
+ Media Type name: multipart
+ Media subtype name: byteranges
+ Required parameters: boundary
+ Optional parameters: none
+
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+
+ Security considerations: none
+
+
+
+
+Fielding, et. al. Standards Track [Page 150]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+For example:
+
+ HTTP/1.1 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 500-999/8000
+
+ ...the first range...
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 7000-7999/8000
+
+ ...the second range
+ --THIS_STRING_SEPARATES--
+
+19.3 Tolerant Applications
+
+ Although this document specifies the requirements for the generation
+ of HTTP/1.1 messages, not all applications will be correct in their
+ implementation. We therefore recommend that operational applications
+ be tolerant of deviations whenever those deviations can be
+ interpreted unambiguously.
+
+ Clients SHOULD be tolerant in parsing the Status-Line and servers
+ tolerant when parsing the Request-Line. In particular, they SHOULD
+ accept any amount of SP or HT characters between fields, even though
+ only a single SP is required.
+
+ The line terminator for message-header fields is the sequence CRLF.
+ However, we recommend that applications, when parsing such headers,
+ recognize a single LF as a line terminator and ignore the leading CR.
+
+ The character set of an entity-body should be labeled as the lowest
+ common denominator of the character codes used within that body, with
+ the exception that no label is preferred over the labels US-ASCII or
+ ISO-8859-1.
+
+ Additional rules for requirements on parsing and encoding of dates
+ and other potential problems with date encodings include:
+
+ o HTTP/1.1 clients and caches should assume that an RFC-850 date
+ which appears to be more than 50 years in the future is in fact
+ in the past (this helps solve the "year 2000" problem).
+
+
+
+
+Fielding, et. al. Standards Track [Page 151]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ o An HTTP/1.1 implementation may internally represent a parsed
+ Expires date as earlier than the proper value, but MUST NOT
+ internally represent a parsed Expires date as later than the
+ proper value.
+
+ o All expiration-related calculations must be done in GMT. The
+ local time zone MUST NOT influence the calculation or comparison
+ of an age or expiration time.
+
+ o If an HTTP header incorrectly carries a date value with a time
+ zone other than GMT, it must be converted into GMT using the most
+ conservative possible conversion.
+
+19.4 Differences Between HTTP Entities and MIME Entities
+
+ HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+ 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
+ entities to be transmitted in an open variety of representations and
+ with extensible mechanisms. However, MIME [7] discusses mail, and
+ HTTP has a few features that are different from those described in
+ MIME. These differences were carefully chosen to optimize
+ performance over binary connections, to allow greater freedom in the
+ use of new media types, to make date comparisons easier, and to
+ acknowledge the practice of some early HTTP servers and clients.
+
+ This appendix describes specific areas where HTTP differs from MIME.
+ Proxies and gateways to strict MIME environments SHOULD be aware of
+ these differences and provide the appropriate conversions where
+ necessary. Proxies and gateways from MIME environments to HTTP also
+ need to be aware of the differences because some conversions may be
+ required.
+
+19.4.1 Conversion to Canonical Form
+
+ MIME requires that an Internet mail entity be converted to canonical
+ form prior to being transferred. Section 3.7.1 of this document
+ describes the forms allowed for subtypes of the "text" media type
+ when transmitted over HTTP. MIME requires that content with a type of
+ "text" represent line breaks as CRLF and forbids the use of CR or LF
+ outside of line break sequences. HTTP allows CRLF, bare CR, and bare
+ LF to indicate a line break within text content when a message is
+ transmitted over HTTP.
+
+ Where it is possible, a proxy or gateway from HTTP to a strict MIME
+ environment SHOULD translate all line breaks within the text media
+ types described in section 3.7.1 of this document to the MIME
+ canonical form of CRLF. Note, however, that this may be complicated
+ by the presence of a Content-Encoding and by the fact that HTTP
+
+
+
+Fielding, et. al. Standards Track [Page 152]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ allows the use of some character sets which do not use octets 13 and
+ 10 to represent CR and LF, as is the case for some multi-byte
+ character sets.
+
+19.4.2 Conversion of Date Formats
+
+ HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
+ simplify the process of date comparison. Proxies and gateways from
+ other protocols SHOULD ensure that any Date header field present in a
+ message conforms to one of the HTTP/1.1 formats and rewrite the date
+ if necessary.
+
+19.4.3 Introduction of Content-Encoding
+
+ MIME does not include any concept equivalent to HTTP/1.1's Content-
+ Encoding header field. Since this acts as a modifier on the media
+ type, proxies and gateways from HTTP to MIME-compliant protocols MUST
+ either change the value of the Content-Type header field or decode
+ the entity-body before forwarding the message. (Some experimental
+ applications of Content-Type for Internet mail have used a media-type
+ parameter of ";conversions=<content-coding>" to perform an equivalent
+ function as Content-Encoding. However, this parameter is not part of
+ MIME.)
+
+19.4.4 No Content-Transfer-Encoding
+
+ HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME.
+ Proxies and gateways from MIME-compliant protocols to HTTP MUST
+ remove any non-identity CTE ("quoted-printable" or "base64") encoding
+ prior to delivering the response message to an HTTP client.
+
+ Proxies and gateways from HTTP to MIME-compliant protocols are
+ responsible for ensuring that the message is in the correct format
+ and encoding for safe transport on that protocol, where "safe
+ transport" is defined by the limitations of the protocol being used.
+ Such a proxy or gateway SHOULD label the data with an appropriate
+ Content-Transfer-Encoding if doing so will improve the likelihood of
+ safe transport over the destination protocol.
+
+19.4.5 HTTP Header Fields in Multipart Body-Parts
+
+ In MIME, most header fields in multipart body-parts are generally
+ ignored unless the field name begins with "Content-". In HTTP/1.1,
+ multipart body-parts may contain any HTTP header fields which are
+ significant to the meaning of that part.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 153]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.4.6 Introduction of Transfer-Encoding
+
+ HTTP/1.1 introduces the Transfer-Encoding header field (section
+ 14.40). Proxies/gateways MUST remove any transfer coding prior to
+ forwarding a message via a MIME-compliant protocol.
+
+ A process for decoding the "chunked" transfer coding (section 3.6)
+ can be represented in pseudo-code as:
+
+ length := 0
+ read chunk-size, chunk-ext (if any) and CRLF
+ while (chunk-size > 0) {
+ read chunk-data and CRLF
+ append chunk-data to entity-body
+ length := length + chunk-size
+ read chunk-size and CRLF
+ }
+ read entity-header
+ while (entity-header not empty) {
+ append entity-header to existing header fields
+ read entity-header
+ }
+ Content-Length := length
+ Remove "chunked" from Transfer-Encoding
+
+19.4.7 MIME-Version
+
+ HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
+ HTTP/1.1 messages may include a single MIME-Version general-header
+ field to indicate what version of the MIME protocol was used to
+ construct the message. Use of the MIME-Version header field indicates
+ that the message is in full compliance with the MIME protocol.
+ Proxies/gateways are responsible for ensuring full compliance (where
+ possible) when exporting HTTP messages to strict MIME environments.
+
+ MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ MIME version "1.0" is the default for use in HTTP/1.1. However,
+ HTTP/1.1 message parsing and semantics are defined by this document
+ and not the MIME specification.
+
+19.5 Changes from HTTP/1.0
+
+ This section summarizes major differences between versions HTTP/1.0
+ and HTTP/1.1.
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 154]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
+ Addresses
+
+ The requirements that clients and servers support the Host request-
+ header, report an error if the Host request-header (section 14.23) is
+ missing from an HTTP/1.1 request, and accept absolute URIs (section
+ 5.1.2) are among the most important changes defined by this
+ specification.
+
+ Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+ addresses and servers; there was no other established mechanism for
+ distinguishing the intended server of a request than the IP address
+ to which that request was directed. The changes outlined above will
+ allow the Internet, once older HTTP clients are no longer common, to
+ support multiple Web sites from a single IP address, greatly
+ simplifying large operational Web servers, where allocation of many
+ IP addresses to a single host has created serious problems. The
+ Internet will also be able to recover the IP addresses that have been
+ allocated for the sole purpose of allowing special-purpose domain
+ names to be used in root-level HTTP URLs. Given the rate of growth of
+ the Web, and the number of servers already deployed, it is extremely
+ important that all implementations of HTTP (including updates to
+ existing HTTP/1.0 applications) correctly implement these
+ requirements:
+
+ o Both clients and servers MUST support the Host request-header.
+
+ o Host request-headers are required in HTTP/1.1 requests.
+
+ o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+ request does not include a Host request-header.
+
+ o Servers MUST accept absolute URIs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 155]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.6 Additional Features
+
+ This appendix documents protocol elements used by some existing HTTP
+ implementations, but not consistently and correctly across most
+ HTTP/1.1 applications. Implementers should be aware of these
+ features, but cannot rely upon their presence in, or interoperability
+ with, other HTTP/1.1 applications. Some of these describe proposed
+ experimental features, and some describe features that experimental
+ deployment found lacking that are now addressed in the base HTTP/1.1
+ specification.
+
+19.6.1 Additional Request Methods
+
+19.6.1.1 PATCH
+
+ The PATCH method is similar to PUT except that the entity contains a
+ list of differences between the original version of the resource
+ identified by the Request-URI and the desired content of the resource
+ after the PATCH action has been applied. The list of differences is
+ in a format defined by the media type of the entity (e.g.,
+ "application/diff") and MUST include sufficient information to allow
+ the server to recreate the changes necessary to convert the original
+ version of the resource to the desired version.
+
+ If the request passes through a cache and the Request-URI identifies
+ a currently cached entity, that entity MUST be removed from the
+ cache. Responses to this method are not cachable.
+
+ The actual method for determining how the patched resource is placed,
+ and what happens to its predecessor, is defined entirely by the
+ origin server. If the original version of the resource being patched
+ included a Content-Version header field, the request entity MUST
+ include a Derived-From header field corresponding to the value of the
+ original Content-Version header field. Applications are encouraged to
+ use these fields for constructing versioning relationships and
+ resolving version conflicts.
+
+ PATCH requests must obey the message transmission requirements set
+ out in section 8.2.
+
+ Caches that implement PATCH should invalidate cached responses as
+ defined in section 13.10 for PUT.
+
+19.6.1.2 LINK
+
+ The LINK method establishes one or more Link relationships between
+ the existing resource identified by the Request-URI and other
+ existing resources. The difference between LINK and other methods
+
+
+
+Fielding, et. al. Standards Track [Page 156]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ allowing links to be established between resources is that the LINK
+ method does not allow any message-body to be sent in the request and
+ does not directly result in the creation of new resources.
+
+ If the request passes through a cache and the Request-URI identifies
+ a currently cached entity, that entity MUST be removed from the
+ cache. Responses to this method are not cachable.
+
+ Caches that implement LINK should invalidate cached responses as
+ defined in section 13.10 for PUT.
+
+19.6.1.3 UNLINK
+
+ The UNLINK method removes one or more Link relationships from the
+ existing resource identified by the Request-URI. These relationships
+ may have been established using the LINK method or by any other
+ method supporting the Link header. The removal of a link to a
+ resource does not imply that the resource ceases to exist or becomes
+ inaccessible for future references.
+
+ If the request passes through a cache and the Request-URI identifies
+ a currently cached entity, that entity MUST be removed from the
+ cache. Responses to this method are not cachable.
+
+ Caches that implement UNLINK should invalidate cached responses as
+ defined in section 13.10 for PUT.
+
+19.6.2 Additional Header Field Definitions
+
+19.6.2.1 Alternates
+
+ The Alternates response-header field has been proposed as a means for
+ the origin server to inform the client about other available
+ representations of the requested resource, along with their
+ distinguishing attributes, and thus providing a more reliable means
+ for a user agent to perform subsequent selection of another
+ representation which better fits the desires of its user (described
+ as agent-driven negotiation in section 12).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 157]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ The Alternates header field is orthogonal to the Vary header field in
+ that both may coexist in a message without affecting the
+ interpretation of the response or the available representations. It
+ is expected that Alternates will provide a significant improvement
+ over the server-driven negotiation provided by the Vary field for
+ those resources that vary over common dimensions like type and
+ language.
+
+ The Alternates header field will be defined in a future
+ specification.
+
+19.6.2.2 Content-Version
+
+ The Content-Version entity-header field defines the version tag
+ associated with a rendition of an evolving entity. Together with the
+ Derived-From field described in section 19.6.2.3, it allows a group
+ of people to work simultaneously on the creation of a work as an
+ iterative process. The field should be used to allow evolution of a
+ particular work along a single path rather than derived works or
+ renditions in different representations.
+
+ Content-Version = "Content-Version" ":" quoted-string
+
+ Examples of the Content-Version field include:
+
+ Content-Version: "2.1.2"
+ Content-Version: "Fred 19950116-12:26:48"
+ Content-Version: "2.5a4-omega7"
+
+19.6.2.3 Derived-From
+
+ The Derived-From entity-header field can be used to indicate the
+ version tag of the resource from which the enclosed entity was
+ derived before modifications were made by the sender. This field is
+ used to help manage the process of merging successive changes to a
+ resource, particularly when such changes are being made in parallel
+ and from multiple sources.
+
+ Derived-From = "Derived-From" ":" quoted-string
+
+ An example use of the field is:
+
+ Derived-From: "2.1.1"
+
+ The Derived-From field is required for PUT and PATCH requests if the
+ entity being sent was previously retrieved from the same URI and a
+ Content-Version header was included with the entity when it was last
+ retrieved.
+
+
+
+Fielding, et. al. Standards Track [Page 158]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.6.2.4 Link
+
+ The Link entity-header field provides a means for describing a
+ relationship between two resources, generally between the requested
+ resource and some other resource. An entity MAY include multiple Link
+ values. Links at the metainformation level typically indicate
+ relationships like hierarchical structure and navigation paths. The
+ Link field is semantically equivalent to the <LINK> element in
+ HTML.[5]
+
+ Link = "Link" ":" #("<" URI ">" *( ";" link-param )
+
+ link-param = ( ( "rel" "=" relationship )
+ | ( "rev" "=" relationship )
+ | ( "title" "=" quoted-string )
+ | ( "anchor" "=" <"> URI <"> )
+ | ( link-extension ) )
+
+ link-extension = token [ "=" ( token | quoted-string ) ]
+
+ relationship = sgml-name
+ | ( <"> sgml-name *( SP sgml-name) <"> )
+
+ sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
+
+ Relationship values are case-insensitive and MAY be extended within
+ the constraints of the sgml-name syntax. The title parameter MAY be
+ used to label the destination of a link such that it can be used as
+ identification within a human-readable menu. The anchor parameter MAY
+ be used to indicate a source anchor other than the entire current
+ resource, such as a fragment of this resource or a third resource.
+
+ Examples of usage include:
+
+ Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
+
+ Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"
+
+ The first example indicates that chapter2 is previous to this
+ resource in a logical navigation path. The second indicates that the
+ person responsible for making the resource available is identified by
+ the given e-mail address.
+
+19.6.2.5 URI
+
+ The URI header field has, in past versions of this specification,
+ been used as a combination of the existing Location, Content-
+ Location, and Vary header fields as well as the future Alternates
+
+
+
+Fielding, et. al. Standards Track [Page 159]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+ field (above). Its primary purpose has been to include a list of
+ additional URIs for the resource, including names and mirror
+ locations. However, it has become clear that the combination of many
+ different functions within this single field has been a barrier to
+ consistently and correctly implementing any of those functions.
+ Furthermore, we believe that the identification of names and mirror
+ locations would be better performed via the Link header field. The
+ URI header field is therefore deprecated in favor of those other
+ fields.
+
+ URI-header = "URI" ":" 1#( "<" URI ">" )
+
+19.7 Compatibility with Previous Versions
+
+ It is beyond the scope of a protocol specification to mandate
+ compliance with previous versions. HTTP/1.1 was deliberately
+ designed, however, to make supporting previous versions easy. It is
+ worth noting that at the time of composing this specification, we
+ would expect commercial HTTP/1.1 servers to:
+
+ o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
+ requests;
+
+ o understand any valid request in the format of HTTP/0.9, 1.0, or
+ 1.1;
+
+ o respond appropriately with a message in the same major version used
+ by the client.
+
+ And we would expect HTTP/1.1 clients to:
+
+ o recognize the format of the Status-Line for HTTP/1.0 and 1.1
+ responses;
+
+ o understand any valid response in the format of HTTP/0.9, 1.0, or
+ 1.1.
+
+ For most implementations of HTTP/1.0, each connection is established
+ by the client prior to the request and closed by the server after
+ sending the response. A few implementations implement the Keep-Alive
+ version of persistent connections described in section 19.7.1.1.
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 160]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.7.1 Compatibility with HTTP/1.0 Persistent Connections
+
+ Some clients and servers may wish to be compatible with some previous
+ implementations of persistent connections in HTTP/1.0 clients and
+ servers. Persistent connections in HTTP/1.0 must be explicitly
+ negotiated as they are not the default behavior. HTTP/1.0
+ experimental implementations of persistent connections are faulty,
+ and the new facilities in HTTP/1.1 are designed to rectify these
+ problems. The problem was that some existing 1.0 clients may be
+ sending Keep-Alive to a proxy server that doesn't understand
+ Connection, which would then erroneously forward it to the next
+ inbound server, which would establish the Keep-Alive connection and
+ result in a hung HTTP/1.0 proxy waiting for the close on the
+ response. The result is that HTTP/1.0 clients must be prevented from
+ using Keep-Alive when talking to proxies.
+
+ However, talking to proxies is the most important use of persistent
+ connections, so that prohibition is clearly unacceptable. Therefore,
+ we need some other mechanism for indicating a persistent connection
+ is desired, which is safe to use even when talking to an old proxy
+ that ignores Connection. Persistent connections are the default for
+ HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+ declaring non-persistence.
+
+ The following describes the original HTTP/1.0 form of persistent
+ connections.
+
+ When it connects to an origin server, an HTTP client MAY send the
+ Keep-Alive connection-token in addition to the Persist connection-
+ token:
+
+ Connection: Keep-Alive
+
+ An HTTP/1.0 server would then respond with the Keep-Alive connection
+ token and the client may proceed with an HTTP/1.0 (or Keep-Alive)
+ persistent connection.
+
+ An HTTP/1.1 server may also establish persistent connections with
+ HTTP/1.0 clients upon receipt of a Keep-Alive connection token.
+ However, a persistent connection with an HTTP/1.0 client cannot make
+ use of the chunked transfer-coding, and therefore MUST use a
+ Content-Length for marking the ending boundary of each message.
+
+ A client MUST NOT send the Keep-Alive connection token to a proxy
+ server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1
+ for parsing the Connection header field.
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 161]
+\f
+RFC 2068 HTTP/1.1 January 1997
+
+
+19.7.1.1 The Keep-Alive Header
+
+ When the Keep-Alive connection-token has been transmitted with a
+ request or a response, a Keep-Alive header field MAY also be
+ included. The Keep-Alive header field takes the following form:
+
+ Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
+
+ keepalive-param = param-name "=" value
+
+ The Keep-Alive header itself is optional, and is used only if a
+ parameter is being sent. HTTP/1.1 does not define any parameters.
+
+ If the Keep-Alive header is sent, the corresponding connection token
+ MUST be transmitted. The Keep-Alive header MUST be ignored if
+ received without the connection token.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et. al. Standards Track [Page 162]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Fielding
+Request for Comments: 2616 UC Irvine
+Obsoletes: 2068 J. Gettys
+Category: Standards Track Compaq/W3C
+ J. Mogul
+ Compaq
+ H. Frystyk
+ W3C/MIT
+ L. Masinter
+ Xerox
+ P. Leach
+ Microsoft
+ T. Berners-Lee
+ W3C/MIT
+ June 1999
+
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) is an application-level
+ protocol for distributed, collaborative, hypermedia information
+ systems. It is a generic, stateless, protocol which can be used for
+ many tasks beyond its use for hypertext, such as name servers and
+ distributed object management systems, through extension of its
+ request methods, error codes and headers [47]. 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", and is an update to RFC 2068 [33].
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 1]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+Table of Contents
+
+ 1 Introduction ...................................................7
+ 1.1 Purpose......................................................7
+ 1.2 Requirements .................................................8
+ 1.3 Terminology ..................................................8
+ 1.4 Overall Operation ...........................................12
+ 2 Notational Conventions and Generic Grammar ....................14
+ 2.1 Augmented BNF ...............................................14
+ 2.2 Basic Rules .................................................15
+ 3 Protocol Parameters ...........................................17
+ 3.1 HTTP Version ................................................17
+ 3.2 Uniform Resource Identifiers ................................18
+ 3.2.1 General Syntax ...........................................19
+ 3.2.2 http URL .................................................19
+ 3.2.3 URI Comparison ...........................................20
+ 3.3 Date/Time Formats ...........................................20
+ 3.3.1 Full Date ................................................20
+ 3.3.2 Delta Seconds ............................................21
+ 3.4 Character Sets ..............................................21
+ 3.4.1 Missing Charset ..........................................22
+ 3.5 Content Codings .............................................23
+ 3.6 Transfer Codings ............................................24
+ 3.6.1 Chunked Transfer Coding ..................................25
+ 3.7 Media Types .................................................26
+ 3.7.1 Canonicalization and Text Defaults .......................27
+ 3.7.2 Multipart Types ..........................................27
+ 3.8 Product Tokens ..............................................28
+ 3.9 Quality Values ..............................................29
+ 3.10 Language Tags ...............................................29
+ 3.11 Entity Tags .................................................30
+ 3.12 Range Units .................................................30
+ 4 HTTP Message ..................................................31
+ 4.1 Message Types ...............................................31
+ 4.2 Message Headers .............................................31
+ 4.3 Message Body ................................................32
+ 4.4 Message Length ..............................................33
+ 4.5 General Header Fields .......................................34
+ 5 Request .......................................................35
+ 5.1 Request-Line ................................................35
+ 5.1.1 Method ...................................................36
+ 5.1.2 Request-URI ..............................................36
+ 5.2 The Resource Identified by a Request ........................38
+ 5.3 Request Header Fields .......................................38
+ 6 Response ......................................................39
+ 6.1 Status-Line .................................................39
+ 6.1.1 Status Code and Reason Phrase ............................39
+ 6.2 Response Header Fields ......................................41
+
+
+
+Fielding, et al. Standards Track [Page 2]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 7 Entity ........................................................42
+ 7.1 Entity Header Fields ........................................42
+ 7.2 Entity Body .................................................43
+ 7.2.1 Type .....................................................43
+ 7.2.2 Entity Length ............................................43
+ 8 Connections ...................................................44
+ 8.1 Persistent Connections ......................................44
+ 8.1.1 Purpose ..................................................44
+ 8.1.2 Overall Operation ........................................45
+ 8.1.3 Proxy Servers ............................................46
+ 8.1.4 Practical Considerations .................................46
+ 8.2 Message Transmission Requirements ...........................47
+ 8.2.1 Persistent Connections and Flow Control ..................47
+ 8.2.2 Monitoring Connections for Error Status Messages .........48
+ 8.2.3 Use of the 100 (Continue) Status .........................48
+ 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
+ 9 Method Definitions ............................................51
+ 9.1 Safe and Idempotent Methods .................................51
+ 9.1.1 Safe Methods .............................................51
+ 9.1.2 Idempotent Methods .......................................51
+ 9.2 OPTIONS .....................................................52
+ 9.3 GET .........................................................53
+ 9.4 HEAD ........................................................54
+ 9.5 POST ........................................................54
+ 9.6 PUT .........................................................55
+ 9.7 DELETE ......................................................56
+ 9.8 TRACE .......................................................56
+ 9.9 CONNECT .....................................................57
+ 10 Status Code Definitions ......................................57
+ 10.1 Informational 1xx ...........................................57
+ 10.1.1 100 Continue .............................................58
+ 10.1.2 101 Switching Protocols ..................................58
+ 10.2 Successful 2xx ..............................................58
+ 10.2.1 200 OK ...................................................58
+ 10.2.2 201 Created ..............................................59
+ 10.2.3 202 Accepted .............................................59
+ 10.2.4 203 Non-Authoritative Information ........................59
+ 10.2.5 204 No Content ...........................................60
+ 10.2.6 205 Reset Content ........................................60
+ 10.2.7 206 Partial Content ......................................60
+ 10.3 Redirection 3xx .............................................61
+ 10.3.1 300 Multiple Choices .....................................61
+ 10.3.2 301 Moved Permanently ....................................62
+ 10.3.3 302 Found ................................................62
+ 10.3.4 303 See Other ............................................63
+ 10.3.5 304 Not Modified .........................................63
+ 10.3.6 305 Use Proxy ............................................64
+ 10.3.7 306 (Unused) .............................................64
+
+
+
+Fielding, et al. Standards Track [Page 3]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 10.3.8 307 Temporary Redirect ...................................65
+ 10.4 Client Error 4xx ............................................65
+ 10.4.1 400 Bad Request .........................................65
+ 10.4.2 401 Unauthorized ........................................66
+ 10.4.3 402 Payment Required ....................................66
+ 10.4.4 403 Forbidden ...........................................66
+ 10.4.5 404 Not Found ...........................................66
+ 10.4.6 405 Method Not Allowed ..................................66
+ 10.4.7 406 Not Acceptable ......................................67
+ 10.4.8 407 Proxy Authentication Required .......................67
+ 10.4.9 408 Request Timeout .....................................67
+ 10.4.10 409 Conflict ............................................67
+ 10.4.11 410 Gone ................................................68
+ 10.4.12 411 Length Required .....................................68
+ 10.4.13 412 Precondition Failed .................................68
+ 10.4.14 413 Request Entity Too Large ............................69
+ 10.4.15 414 Request-URI Too Long ................................69
+ 10.4.16 415 Unsupported Media Type ..............................69
+ 10.4.17 416 Requested Range Not Satisfiable .....................69
+ 10.4.18 417 Expectation Failed ..................................70
+ 10.5 Server Error 5xx ............................................70
+ 10.5.1 500 Internal Server Error ................................70
+ 10.5.2 501 Not Implemented ......................................70
+ 10.5.3 502 Bad Gateway ..........................................70
+ 10.5.4 503 Service Unavailable ..................................70
+ 10.5.5 504 Gateway Timeout ......................................71
+ 10.5.6 505 HTTP Version Not Supported ...........................71
+ 11 Access Authentication ........................................71
+ 12 Content Negotiation ..........................................71
+ 12.1 Server-driven Negotiation ...................................72
+ 12.2 Agent-driven Negotiation ....................................73
+ 12.3 Transparent Negotiation .....................................74
+ 13 Caching in HTTP ..............................................74
+ 13.1.1 Cache Correctness ........................................75
+ 13.1.2 Warnings .................................................76
+ 13.1.3 Cache-control Mechanisms .................................77
+ 13.1.4 Explicit User Agent Warnings .............................78
+ 13.1.5 Exceptions to the Rules and Warnings .....................78
+ 13.1.6 Client-controlled Behavior ...............................79
+ 13.2 Expiration Model ............................................79
+ 13.2.1 Server-Specified Expiration ..............................79
+ 13.2.2 Heuristic Expiration .....................................80
+ 13.2.3 Age Calculations .........................................80
+ 13.2.4 Expiration Calculations ..................................83
+ 13.2.5 Disambiguating Expiration Values .........................84
+ 13.2.6 Disambiguating Multiple Responses ........................84
+ 13.3 Validation Model ............................................85
+ 13.3.1 Last-Modified Dates ......................................86
+
+
+
+Fielding, et al. Standards Track [Page 4]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 13.3.2 Entity Tag Cache Validators ..............................86
+ 13.3.3 Weak and Strong Validators ...............................86
+ 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
+ 13.3.5 Non-validating Conditionals ..............................90
+ 13.4 Response Cacheability .......................................91
+ 13.5 Constructing Responses From Caches ..........................92
+ 13.5.1 End-to-end and Hop-by-hop Headers ........................92
+ 13.5.2 Non-modifiable Headers ...................................92
+ 13.5.3 Combining Headers ........................................94
+ 13.5.4 Combining Byte Ranges ....................................95
+ 13.6 Caching Negotiated Responses ................................95
+ 13.7 Shared and Non-Shared Caches ................................96
+ 13.8 Errors or Incomplete Response Cache Behavior ................97
+ 13.9 Side Effects of GET and HEAD ................................97
+ 13.10 Invalidation After Updates or Deletions ...................97
+ 13.11 Write-Through Mandatory ...................................98
+ 13.12 Cache Replacement .........................................99
+ 13.13 History Lists .............................................99
+ 14 Header Field Definitions ....................................100
+ 14.1 Accept .....................................................100
+ 14.2 Accept-Charset .............................................102
+ 14.3 Accept-Encoding ............................................102
+ 14.4 Accept-Language ............................................104
+ 14.5 Accept-Ranges ..............................................105
+ 14.6 Age ........................................................106
+ 14.7 Allow ......................................................106
+ 14.8 Authorization ..............................................107
+ 14.9 Cache-Control ..............................................108
+ 14.9.1 What is Cacheable .......................................109
+ 14.9.2 What May be Stored by Caches ............................110
+ 14.9.3 Modifications of the Basic Expiration Mechanism .........111
+ 14.9.4 Cache Revalidation and Reload Controls ..................113
+ 14.9.5 No-Transform Directive ..................................115
+ 14.9.6 Cache Control Extensions ................................116
+ 14.10 Connection ...............................................117
+ 14.11 Content-Encoding .........................................118
+ 14.12 Content-Language .........................................118
+ 14.13 Content-Length ...........................................119
+ 14.14 Content-Location .........................................120
+ 14.15 Content-MD5 ..............................................121
+ 14.16 Content-Range ............................................122
+ 14.17 Content-Type .............................................124
+ 14.18 Date .....................................................124
+ 14.18.1 Clockless Origin Server Operation ......................125
+ 14.19 ETag .....................................................126
+ 14.20 Expect ...................................................126
+ 14.21 Expires ..................................................127
+ 14.22 From .....................................................128
+
+
+
+Fielding, et al. Standards Track [Page 5]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 14.23 Host .....................................................128
+ 14.24 If-Match .................................................129
+ 14.25 If-Modified-Since ........................................130
+ 14.26 If-None-Match ............................................132
+ 14.27 If-Range .................................................133
+ 14.28 If-Unmodified-Since ......................................134
+ 14.29 Last-Modified ............................................134
+ 14.30 Location .................................................135
+ 14.31 Max-Forwards .............................................136
+ 14.32 Pragma ...................................................136
+ 14.33 Proxy-Authenticate .......................................137
+ 14.34 Proxy-Authorization ......................................137
+ 14.35 Range ....................................................138
+ 14.35.1 Byte Ranges ...........................................138
+ 14.35.2 Range Retrieval Requests ..............................139
+ 14.36 Referer ..................................................140
+ 14.37 Retry-After ..............................................141
+ 14.38 Server ...................................................141
+ 14.39 TE .......................................................142
+ 14.40 Trailer ..................................................143
+ 14.41 Transfer-Encoding..........................................143
+ 14.42 Upgrade ..................................................144
+ 14.43 User-Agent ...............................................145
+ 14.44 Vary .....................................................145
+ 14.45 Via ......................................................146
+ 14.46 Warning ..................................................148
+ 14.47 WWW-Authenticate .........................................150
+ 15 Security Considerations .......................................150
+ 15.1 Personal Information....................................151
+ 15.1.1 Abuse of Server Log Information .........................151
+ 15.1.2 Transfer of Sensitive Information .......................151
+ 15.1.3 Encoding Sensitive Information in URI's .................152
+ 15.1.4 Privacy Issues Connected to Accept Headers ..............152
+ 15.2 Attacks Based On File and Path Names .......................153
+ 15.3 DNS Spoofing ...............................................154
+ 15.4 Location Headers and Spoofing ..............................154
+ 15.5 Content-Disposition Issues .................................154
+ 15.6 Authentication Credentials and Idle Clients ................155
+ 15.7 Proxies and Caching ........................................155
+ 15.7.1 Denial of Service Attacks on Proxies....................156
+ 16 Acknowledgments .............................................156
+ 17 References ..................................................158
+ 18 Authors' Addresses ..........................................162
+ 19 Appendices ..................................................164
+ 19.1 Internet Media Type message/http and application/http ......164
+ 19.2 Internet Media Type multipart/byteranges ...................165
+ 19.3 Tolerant Applications ......................................166
+ 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
+
+
+
+Fielding, et al. Standards Track [Page 6]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 19.4.1 MIME-Version ............................................167
+ 19.4.2 Conversion to Canonical Form ............................167
+ 19.4.3 Conversion of Date Formats ..............................168
+ 19.4.4 Introduction of Content-Encoding ........................168
+ 19.4.5 No Content-Transfer-Encoding ............................168
+ 19.4.6 Introduction of Transfer-Encoding .......................169
+ 19.4.7 MHTML and Line Length Limitations .......................169
+ 19.5 Additional Features ........................................169
+ 19.5.1 Content-Disposition .....................................170
+ 19.6 Compatibility with Previous Versions .......................170
+ 19.6.1 Changes from HTTP/1.0 ...................................171
+ 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
+ 19.6.3 Changes from RFC 2068 ...................................172
+ 20 Index .......................................................175
+ 21 Full Copyright Statement ....................................176
+
+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, or 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 and headers that indicate the
+ purpose of a request [47]. It builds on the discipline of reference
+ provided by the Uniform Resource Identifier (URI) [3], as a location
+ (URL) [4] or name (URN) [20], for indicating the resource to which a
+
+
+
+
+
+Fielding, et al. Standards Track [Page 7]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ method is to be applied. Messages are passed in a format similar to
+ that used by Internet mail [9] as defined by the Multipurpose
+ Internet Mail Extensions (MIME) [7].
+
+ HTTP is also used as a generic protocol for communication between
+ user agents and proxies/gateways to other Internet 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
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [34].
+
+ An implementation is not compliant if it fails to satisfy one or more
+ of the MUST or REQUIRED level requirements for the protocols it
+ implements. An implementation that satisfies all the MUST or REQUIRED
+ level and all the SHOULD level requirements for its protocols is said
+ to be "unconditionally compliant"; one that satisfies all the MUST
+ level requirements but not all the SHOULD level 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.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 8]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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, and
+ resolutions) or vary in other ways.
+
+ 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 `varriant'. 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.
+
+
+
+
+Fielding, et al. Standards Track [Page 9]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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 implement
+ both the client and server requirements of this specification. A
+ "transparent proxy" is a proxy that does not modify the request or
+ response beyond what is required for proxy authentication and
+ identification. A "non-transparent proxy" is a proxy that modifies
+ the request or response in order to provide some added service to
+ the user agent, such as group annotation services, media type
+ transformation, protocol reduction, or anonymity filtering. Except
+ where either transparent or non-transparent behavior is explicitly
+ stated, the HTTP proxy requirements apply to both types of
+ proxies.
+
+ 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 cacheable 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.
+
+ cacheable
+ A response is cacheable if a cache is allowed to store a copy of
+ the response message for use in answering subsequent requests. The
+ rules for determining the cacheability of HTTP responses are
+ defined in section 13. Even if a resource is cacheable, there may
+ be additional constraints on whether a cache can use the cached
+ copy for a particular request.
+
+
+
+
+Fielding, et al. Standards Track [Page 10]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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.
+
+ 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.
+
+ upstream/downstream
+ Upstream and downstream describe the flow of a message: all
+ messages flow from upstream to downstream.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 11]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ inbound/outbound
+ Inbound and outbound refer to the request and response paths for
+ messages: "inbound" means "traveling toward the origin server",
+ and "outbound" means "traveling toward the user agent"
+
+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.
+
+ 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
+
+
+
+Fielding, et al. Standards Track [Page 12]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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 usefully cacheable, and some requests may
+ contain modifiers which place special requirements on cache behavior.
+ HTTP requirements for cache behavior and cacheable 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 [19], but other ports can be used. This does
+ not preclude HTTP from being implemented on top of any other protocol
+ on the Internet, or on other networks. HTTP only presumes a reliable
+ transport; any protocol that provides such guarantees can be used;
+ 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.
+
+
+
+
+Fielding, et al. Standards Track [Page 13]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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]. Implementors will need to be familiar with the
+ notation in order to understand this specification. The augmented BNF
+ includes the following constructs:
+
+ name = definition
+ The name of a rule is simply the name itself (without any
+ enclosing "<" and ">") and is separated from its definition by the
+ equal "=" character. White space 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)".
+
+
+
+Fielding, et al. Standards Track [Page 14]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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 white space (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 white space (LWS) can be included
+ between any two adjacent words (token or quoted-string), and
+ between adjacent words and separators, without changing the
+ interpretation of a field. At least one delimiter (LWS and/or
+
+ separators) MUST exist between any two tokens (for the definition
+ of "token" below), 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].
+
+
+
+
+
+Fielding, et al. Standards Track [Page 15]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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 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 header field values 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. A
+ recipient MAY replace any linear white space with a single SP before
+ interpreting the field value or forwarding the message downstream.
+
+ 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 2047
+ [14].
+
+ TEXT = <any OCTET except CTLs,
+ but including LWS>
+
+ A CRLF is allowed in the definition of TEXT only as part of a header
+ field continuation. It is expected that the folding LWS will be
+ replaced with a single SP before interpretation of the TEXT value.
+
+ Hexadecimal numeric characters are used in several protocol elements.
+
+ HEX = "A" | "B" | "C" | "D" | "E" | "F"
+ | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+
+
+
+
+Fielding, et al. Standards Track [Page 16]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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 (as defined in section
+ 3.6).
+
+ token = 1*<any CHAR except CTLs or separators>
+ separators = "(" | ")" | "<" | ">" | "@"
+ | "," | ";" | ":" | "\" | <">
+ | "/" | "[" | "]" | "?" | "="
+ | "{" | "}" | 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 | quoted-pair | comment ) ")"
+ ctext = <any TEXT excluding "(" and ")">
+
+ A string of text is parsed as a single word if it is quoted using
+ double-quote marks.
+
+ quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
+ 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. See RFC 2145 [36] for a fuller explanation.
+
+
+
+Fielding, et al. Standards Track [Page 17]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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.
+
+ An application that sends a request or response message that includes
+ HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
+ with this specification. Applications that are at least conditionally
+ compliant with this specification SHOULD use an HTTP-Version of
+ "HTTP/1.1" in their messages, and MUST do so for any message that is
+ not compatible with HTTP/1.0. For more details on when to send
+ specific HTTP-Version values, see RFC 2145 [36].
+
+ The HTTP version of an application is the highest HTTP version for
+ which the application is at least conditionally compliant.
+
+ Proxy and gateway applications need to 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 NOT 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, or respond with an error, or switch to tunnel
+ behavior.
+
+ Due to interoperability problems with HTTP/1.0 proxies discovered
+ since the publication of RFC 2068[33], caching proxies MUST, gateways
+ MAY, and tunnels MUST NOT upgrade the request to the highest version
+ they support. 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 [3], and finally the
+ combination of Uniform Resource Locators (URL) [4] and Names (URN)
+ [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
+ simply formatted strings which identify--via name, location, or any
+ other characteristic--a resource.
+
+
+
+Fielding, et al. Standards Track [Page 18]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+3.2.1 General Syntax
+
+ URIs in HTTP can be represented in absolute form or relative to some
+ known base URI [11], depending upon the context of their use. The two
+ forms are differentiated by the fact that absolute URIs always begin
+ with a scheme name followed by a colon. For definitive information on
+ URL syntax and semantics, see "Uniform Resource Identifiers (URI):
+ Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
+ 1738 [4] and RFC 1808 [11]). This specification adopts the
+ definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
+ "host","abs_path", "rel_path", and "authority" from that
+ specification.
+
+ 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 ought to be cautious about depending on URI lengths
+ above 255 bytes, because some older client or proxy
+ implementations might 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.
+
+ http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+ 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 (section 5.1.2). The use of IP addresses
+ in URLs 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). If a proxy
+ receives a host name which is not a fully qualified domain name, it
+ MAY add its domain to the host name it received. If a proxy receives
+ a fully qualified domain name, the proxy MUST NOT change the host
+ name.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 19]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+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:
+
+ - A port that is empty or not given is equivalent to the default
+ port for that URI-reference;
+
+ - Comparisons of host names MUST be case-insensitive;
+
+ - Comparisons of scheme names MUST be case-insensitive;
+
+ - An empty abs_path is equivalent to an abs_path of "/".
+
+ Characters other than those in the "reserved" and "unsafe" sets (see
+ RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
+
+ 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
+
+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 [8] (an update to
+ RFC 822 [9]). The second format is in common use, but is based on the
+ obsolete RFC 850 [12] date format and lacks a four-digit year.
+ HTTP/1.1 clients and servers that parse the date value MUST 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. See section 19.3 for further information.
+
+ 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.
+
+
+
+Fielding, et al. Standards Track [Page 20]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ All HTTP date/time stamps MUST be represented in Greenwich Mean Time
+ (GMT), without exception. For the purposes of HTTP, GMT is exactly
+ equal to UTC (Coordinated Universal Time). 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 is case sensitive and MUST NOT include
+ additional LWS beyond that specifically included as SP in the
+ grammar.
+
+ HTTP-date = rfc1123-date | rfc850-date | asctime-date
+ rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+ rfc850-date = weekday "," SP date2 SP time SP "GMT"
+ asctime-date = wkday SP date3 SP time SP 4DIGIT
+ date1 = 2DIGIT SP month SP 4DIGIT
+ ; day month year (e.g., 02 Jun 1982)
+ date2 = 2DIGIT "-" month "-" 2DIGIT
+ ; day-month-year (e.g., 02-Jun-82)
+ date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
+ ; month day (e.g., Jun 2)
+ time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+ ; 00:00:00 - 23:59:59
+ wkday = "Mon" | "Tue" | "Wed"
+ | "Thu" | "Fri" | "Sat" | "Sun"
+ weekday = "Monday" | "Tuesday" | "Wednesday"
+ | "Thursday" | "Friday" | "Saturday" | "Sunday"
+ month = "Jan" | "Feb" | "Mar" | "Apr"
+ | "May" | "Jun" | "Jul" | "Aug"
+ | "Sep" | "Oct" | "Nov" | "Dec"
+
+ Note: HTTP requirements for the date/time stamp format apply only
+ to their usage within the protocol stream. Clients and servers are
+ not required to use these formats for user presentation, request
+ logging, etc.
+
+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:
+
+
+
+
+
+Fielding, et al. Standards Track [Page 21]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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
+ encoding, from simple single-table mappings such as US-ASCII to
+ complex table switching methods such as those that use ISO-2022's
+ techniques. However, the definition associated with a MIME character
+ set name MUST fully specify the mapping to be performed from octets
+ to characters. In particular, use of external profiling information
+ to determine the exact mapping is not permitted.
+
+ Note: This use of the term "character set" is more commonly
+ referred to as a "character encoding." However, since HTTP and
+ MIME share the same registry, it is important that the terminology
+ also be shared.
+
+ HTTP character sets are identified by case-insensitive tokens. The
+ complete set of tokens is defined by the IANA Character Set registry
+ [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 [19] MUST represent the character set defined
+ by that registry. Applications SHOULD limit their use of character
+ sets to those defined by the IANA registry.
+
+ Implementors should be aware of IETF character set requirements [38]
+ [41].
+
+3.4.1 Missing Charset
+
+ 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
+
+
+
+
+
+Fielding, et al. Standards Track [Page 22]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ content-type field if they support that charset, rather than the
+ recipient's preference, when initially displaying a document. See
+ section 3.7.1.
+
+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.11) 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).
+
+ Use of program names for the identification of encoding formats
+ is not desirable and is 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].
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 23]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ identity
+ The default (identity) encoding; the use of no transformation
+ whatsoever. This content-coding is used only in the Accept-
+ Encoding header, and SHOULD NOT be used in the Content-Encoding
+ header.
+
+ 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 *( ";" parameter )
+
+ Parameters are in the form of attribute/value pairs.
+
+ parameter = attribute "=" value
+ attribute = token
+ value = token | quoted-string
+
+ All transfer-coding values are case-insensitive. HTTP/1.1 uses
+ transfer-coding values in the TE header field (section 14.39) and in
+ the Transfer-Encoding header field (section 14.41).
+
+ Whenever a transfer-coding is applied to a message-body, the set of
+ transfer-codings MUST include "chunked", unless the message is
+ terminated by closing the connection. When the "chunked" transfer-
+ coding is used, it MUST be the last transfer-coding applied to the
+ message-body. The "chunked" transfer-coding MUST NOT be applied more
+ than once to a message-body. These rules allow the recipient to
+ determine the transfer-length of the message (section 4.4).
+
+ Transfer-codings are analogous to the Content-Transfer-Encoding
+ values of MIME [7], which were designed to enable safe transport of
+ binary data over a 7-bit transport service. However, safe transport
+ has a different focus for an 8bit-clean transfer protocol. In HTTP,
+ the only unsafe characteristic of message-bodies is the difficulty in
+ determining the exact body length (section 7.2.2), or the desire to
+ encrypt data over a shared transport.
+
+
+
+Fielding, et al. Standards Track [Page 24]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The Internet Assigned Numbers Authority (IANA) acts as a registry for
+ transfer-coding value tokens. Initially, the registry contains the
+ following tokens: "chunked" (section 3.6.1), "identity" (section
+ 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
+ (section 3.5).
+
+ New transfer-coding value tokens SHOULD be registered in the same way
+ as new content-coding value tokens (section 3.5).
+
+ 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.6.1 Chunked Transfer Coding
+
+ The chunked encoding modifies the body of a message in order to
+ transfer it as a series of chunks, each with its own size indicator,
+ followed by an OPTIONAL trailer containing entity-header fields. This
+ allows dynamically produced content to be transferred along with the
+ information necessary for the recipient to verify that it has
+ received the full message.
+
+ Chunked-Body = *chunk
+ last-chunk
+ trailer
+ CRLF
+
+ chunk = chunk-size [ chunk-extension ] CRLF
+ chunk-data CRLF
+ chunk-size = 1*HEX
+ last-chunk = 1*("0") [ chunk-extension ] CRLF
+
+ chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
+ chunk-ext-name = token
+ chunk-ext-val = token | quoted-string
+ chunk-data = chunk-size(OCTET)
+ trailer = *(entity-header CRLF)
+
+ The chunk-size field is a string of hex digits indicating the size of
+ the chunk. The chunked encoding is ended by any chunk whose size is
+ zero, followed by the trailer, which is terminated by an empty line.
+
+ The trailer allows the sender to include additional HTTP header
+ fields at the end of the message. The Trailer header field can be
+ used to indicate which header fields are included in a trailer (see
+ section 14.40).
+
+
+
+
+Fielding, et al. Standards Track [Page 25]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ A server using chunked transfer-coding in a response MUST NOT use the
+ trailer for any header fields unless at least one of the following is
+ true:
+
+ a)the request included a TE header field that indicates "trailers" is
+ acceptable in the transfer-coding of the response, as described in
+ section 14.39; or,
+
+ b)the server is the origin server for the response, the trailer
+ fields consist entirely of optional metadata, and the recipient
+ could use the message (in a manner acceptable to the origin server)
+ without receiving this metadata. In other words, the origin server
+ is willing to accept the possibility that the trailer fields might
+ be silently discarded along the path to the client.
+
+ This requirement prevents an interoperability failure when the
+ message is being received by an HTTP/1.1 (or later) proxy and
+ forwarded to an HTTP/1.0 recipient. It avoids a situation where
+ compliance with the protocol would have necessitated a possibly
+ infinite buffer on the proxy.
+
+ 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 chunk-extension extensions
+ they do not understand.
+
+3.7 Media Types
+
+ HTTP uses Internet Media Types [17] in the Content-Type (section
+ 14.17) 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 (as defined in section 3.6).
+
+ The type, subtype, and parameter attribute names are case-
+ insensitive. Parameter values might or might 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. The presence or absence of a parameter might
+ be significant to the processing of a media-type, depending on its
+ definition within the media type registry.
+
+
+
+Fielding, et al. Standards Track [Page 26]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Note that 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 [19]). The media type registration process is
+ outlined in RFC 1590 [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. An
+ entity-body transferred via HTTP messages MUST be represented in the
+ appropriate canonical form prior to its transmission except for
+ "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-coding, the underlying
+ data MUST be in a form defined above prior to being encoded.
+
+ The "charset" parameter is used with some media types to define the
+ character set (section 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. See
+ section 3.4.1 for compatibility problems.
+
+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 section 5.1.1 of RFC 2046
+
+
+
+Fielding, et al. Standards Track [Page 27]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ [40], and MUST include a boundary parameter as part of the media type
+ value. The message body is itself a protocol element and MUST
+ therefore use only CRLF to represent line breaks between body-parts.
+ Unlike in RFC 2046, the epilogue of any multipart message MUST be
+ empty; HTTP applications MUST NOT transmit the epilogue (even if the
+ original multipart contains an epilogue). These restrictions exist in
+ order to preserve the self-delimiting nature of a multipart message-
+ body, wherein the "end" of the message-body is indicated by the
+ ending multipart boundary.
+
+ In general, HTTP treats a multipart message-body no differently than
+ any other media type: strictly as payload. The one exception is the
+ "multipart/byteranges" type (appendix 19.2) when it appears in a 206
+ (Partial Content) response, which will be interpreted by some HTTP
+ caching mechanisms as described in sections 13.5.4 and 14.16. In all
+ other cases, an HTTP user agent SHOULD follow the same or similar
+ behavior as a MIME user agent would upon receipt of a multipart type.
+ The MIME header fields within each body-part of a multipart message-
+ body do not have any significance to HTTP beyond that defined by
+ their MIME semantics.
+
+ 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].
+
+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 white space. 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
+
+
+
+
+
+Fielding, et al. Standards Track [Page 28]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Product tokens SHOULD be short and to the point. They MUST NOT be
+ used for advertising or other non-essential information. 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. If a parameter has a quality value of 0, then content with
+ this parameter is `not acceptable' for the client. 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.
+
+ 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
+
+ White space 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
+
+
+
+
+Fielding, et al. Standards Track [Page 29]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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.19), If-Match (section 14.24), 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. The use
+ of the same entity tag value in conjunction with entities obtained by
+ requests on different URIs does not imply the equivalence of those
+ entities.
+
+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.35) and Content-Range (section 14.16)
+ header fields. An entity can 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.
+
+
+
+Fielding, et al. Standards Track [Page 30]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 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, zero
+ 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 possibly a message-body.
+
+ generic-message = start-line
+ *(message-header CRLF)
+ 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.
+
+ Certain buggy HTTP/1.0 client implementations generate 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
+ that given in Section 3.1 of RFC 822 [9]. Each header field consists
+ of a name followed by a colon (":") and the field value. Field names
+ are case-insensitive. The field value MAY be preceded by any amount
+ of LWS, though a single SP is preferred. Header fields can be
+ extended over multiple lines by preceding each extra line with at
+ least one SP or HT. Applications ought to follow "common form", where
+ one is known or indicated, when generating HTTP constructs, since
+ there might exist some implementations that fail to accept anything
+
+
+
+Fielding, et al. Standards Track [Page 31]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ beyond the common forms.
+
+ message-header = field-name ":" [ field-value ]
+ field-name = token
+ field-value = *( field-content | LWS )
+ field-content = <the OCTETs making up the field-value
+ and consisting of either *TEXT or combinations
+ of token, separators, and quoted-string>
+
+ The field-content does not include any leading or trailing LWS:
+ linear white space occurring before the first non-whitespace
+ character of the field-value or after the last non-whitespace
+ character of the field-value. Such leading or trailing LWS MAY be
+ removed without changing the semantics of the field value. Any LWS
+ that occurs between field-content MAY be replaced with a single SP
+ before interpreting the field value or forwarding the message
+ downstream.
+
+ The order in which header fields with differing field names are
+ received is not significant. However, it is "good practice" to send
+ general-header fields first, followed by request-header or response-
+ header fields, and ending with the entity-header fields.
+
+ Multiple message-header fields with the same field-name MAY be
+ present in a message if and only if the entire field-value for that
+ header field is defined as a comma-separated list [i.e., #(values)].
+ It MUST be possible to combine the multiple header fields into one
+ "field-name: field-value" pair, without changing the semantics of the
+ message, by appending each subsequent field-value to the first, each
+ separated by a comma. The order in which header fields with the same
+ field-name are received is therefore significant to the
+ interpretation of the combined field value, and thus a proxy MUST NOT
+ change the order of these field values when a message is forwarded.
+
+4.3 Message Body
+
+ The message-body (if any) of an HTTP message is used to carry the
+ entity-body associated with the request or response. The message-body
+ differs from the entity-body only when a transfer-coding has been
+ applied, as indicated by the Transfer-Encoding header field (section
+ 14.41).
+
+ message-body = entity-body
+ | <entity-body encoded as per Transfer-Encoding>
+
+ Transfer-Encoding MUST be used to indicate any transfer-codings
+ applied by an application to ensure safe and proper transfer of the
+ message. Transfer-Encoding is a property of the message, not of the
+
+
+
+Fielding, et al. Standards Track [Page 32]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ entity, and thus MAY be added or removed by any application along the
+ request/response chain. (However, section 3.6 places restrictions on
+ when certain transfer-codings may be used.)
+
+ The rules for when a message-body is allowed in a message differ for
+ requests and responses.
+
+ The presence of a message-body in a request is signaled by the
+ inclusion of a Content-Length or Transfer-Encoding header field in
+ the request's message-headers. A message-body MUST NOT be included in
+ a request if the specification of the request method (section 5.1.1)
+ does not allow sending an entity-body in requests. A server SHOULD
+ read and forward a message-body on any request; if the request method
+ does not include defined semantics for an entity-body, then the
+ message-body SHOULD be ignored when handling the request.
+
+ For response messages, whether or not a message-body is included with
+ a message is dependent on both the request method and the response
+ status code (section 6.1.1). All responses to the HEAD request method
+ MUST NOT include a message-body, even though the presence of entity-
+ header fields might lead one to believe they do. All 1xx
+ (informational), 204 (no content), and 304 (not modified) responses
+ MUST NOT include a message-body. All other responses do include a
+ message-body, although it MAY be of zero length.
+
+4.4 Message Length
+
+ The transfer-length of a message is the length of the message-body as
+ it appears in the message; that is, after any transfer-codings have
+ been applied. When a message-body is included with a message, the
+ transfer-length of that body is determined by one of the following
+ (in order of precedence):
+
+ 1.Any response message which "MUST NOT" include a message-body (such
+ as the 1xx, 204, and 304 responses and any response to a HEAD
+ request) is always terminated by the first empty line after the
+ header fields, regardless of the entity-header fields present in
+ the message.
+
+ 2.If a Transfer-Encoding header field (section 14.41) is present and
+ has any value other than "identity", then the transfer-length is
+ defined by use of the "chunked" transfer-coding (section 3.6),
+ unless the message is terminated by closing the connection.
+
+ 3.If a Content-Length header field (section 14.13) is present, its
+ decimal value in OCTETs represents both the entity-length and the
+ transfer-length. The Content-Length header field MUST NOT be sent
+ if these two lengths are different (i.e., if a Transfer-Encoding
+
+
+
+Fielding, et al. Standards Track [Page 33]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ header field is present). If a message is received with both a
+ Transfer-Encoding header field and a Content-Length header field,
+ the latter MUST be ignored.
+
+ 4.If the message uses the media type "multipart/byteranges", and the
+ ransfer-length is not otherwise specified, then this self-
+ elimiting media type defines the transfer-length. This media type
+ UST NOT be used unless the sender knows that the recipient can arse
+ it; the presence in a request of a Range header with ultiple byte-
+ range specifiers from a 1.1 client implies that the lient can parse
+ multipart/byteranges responses.
+
+ A range header might be forwarded by a 1.0 proxy that does not
+ understand multipart/byteranges; in this case the server MUST
+ delimit the message using methods defined in items 1,3 or 5 of
+ this section.
+
+ 5.By the server closing the connection. (Closing the connection
+ cannot be used to indicate the end of a request body, since that
+ would leave no possibility for the server to send back a response.)
+
+ For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+ containing a message-body MUST include a valid Content-Length header
+ field unless the server is known to be HTTP/1.1 compliant. If a
+ request contains a message-body and a Content-Length is not given,
+ the server SHOULD respond with 400 (bad request) if it cannot
+ determine the length of the message, or with 411 (length required) if
+ it wishes to insist on receiving a valid Content-Length.
+
+ All HTTP/1.1 applications that receive entities MUST accept the
+ "chunked" transfer-coding (section 3.6), thus allowing this mechanism
+ to be used for messages when the message length cannot be determined
+ in advance.
+
+ Messages MUST NOT include both a Content-Length header field and a
+ non-identity transfer-coding. If the message does include a non-
+ identity transfer-coding, the Content-Length MUST be ignored.
+
+ When a Content-Length is given in a message where a message-body is
+ allowed, its field value MUST exactly match the number of OCTETs in
+ the message-body. HTTP/1.1 user agents MUST notify the user when an
+ invalid length is received and detected.
+
+4.5 General Header Fields
+
+ There are a few header fields which have general applicability for
+ both request and response messages, but which do not apply to the
+ entity being transferred. These header fields apply only to the
+
+
+
+Fielding, et al. Standards Track [Page 34]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ message being transmitted.
+
+ general-header = Cache-Control ; Section 14.9
+ | Connection ; Section 14.10
+ | Date ; Section 14.18
+ | Pragma ; Section 14.32
+ | Trailer ; Section 14.40
+ | Transfer-Encoding ; Section 14.41
+ | Upgrade ; Section 14.42
+ | Via ; Section 14.45
+ | Warning ; Section 14.46
+
+ General-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields may be given the semantics of general
+ header fields if all parties in the communication recognize them to
+ be general-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+5 Request
+
+ A request message from a client to a server includes, within the
+ first line of that message, the method to be applied to the resource,
+ the identifier of the resource, and the protocol version in use.
+
+ Request = Request-Line ; Section 5.1
+ *(( general-header ; Section 4.5
+ | request-header ; Section 5.3
+ | entity-header ) CRLF) ; Section 7.1
+ CRLF
+ [ message-body ] ; Section 4.3
+
+5.1 Request-Line
+
+ The Request-Line begins with a method token, followed by the
+ Request-URI and the protocol version, and ending with CRLF. The
+ elements are separated by SP characters. No CR or LF is allowed
+ except in the final CRLF sequence.
+
+ Request-Line = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 35]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+5.1.1 Method
+
+ The Method token indicates the method to be performed on the
+ resource identified by the Request-URI. The method is case-sensitive.
+
+ Method = "OPTIONS" ; Section 9.2
+ | "GET" ; Section 9.3
+ | "HEAD" ; Section 9.4
+ | "POST" ; Section 9.5
+ | "PUT" ; Section 9.6
+ | "DELETE" ; Section 9.7
+ | "TRACE" ; Section 9.8
+ | "CONNECT" ; Section 9.9
+ | extension-method
+ extension-method = token
+
+ The list of methods allowed by a resource can be specified in an
+ Allow header field (section 14.7). The return code of the response
+ always notifies the client whether a method is currently allowed on a
+ resource, since the set of allowed methods can change dynamically. An
+ origin server SHOULD return the status code 405 (Method Not Allowed)
+ if the method is known by the origin server but not allowed for the
+ requested resource, and 501 (Not Implemented) if the method is
+ unrecognized or not implemented by the origin server. The methods GET
+ and HEAD MUST be supported by all general-purpose servers. All other
+ methods are OPTIONAL; however, if the above methods are implemented,
+ they MUST be implemented with the same semantics as those specified
+ in section 9.
+
+5.1.2 Request-URI
+
+ The Request-URI is a Uniform Resource Identifier (section 3.2) and
+ identifies the resource upon which to apply the request.
+
+ Request-URI = "*" | absoluteURI | abs_path | authority
+
+ The four options for Request-URI are dependent on the nature of the
+ request. The asterisk "*" means that the request does not apply to a
+ particular resource, but to the server itself, and is only allowed
+ when the method used does not necessarily apply to a resource. One
+ example would be
+
+ OPTIONS * HTTP/1.1
+
+ The absoluteURI form is REQUIRED when the request is being made to a
+ proxy. The proxy is requested to forward the request or service it
+ from a valid cache, and return the response. Note that the proxy MAY
+ forward the request on to another proxy or directly to the server
+
+
+
+Fielding, et al. Standards Track [Page 36]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ specified by the absoluteURI. In order to avoid request loops, a
+ proxy MUST be able to recognize all of its server names, including
+ any aliases, local variations, and the numeric IP address. An example
+ Request-Line would be:
+
+ GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+ To allow for transition to absoluteURIs in all requests in future
+ versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
+ form in requests, even though HTTP/1.1 clients will only generate
+ them in requests to proxies.
+
+ The authority form is only used by the CONNECT method (section 9.9).
+
+ The most common form of Request-URI is that used to identify a
+ resource on an origin server or gateway. In this case the absolute
+ path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+ the Request-URI, and the network location of the URI (authority) MUST
+ be transmitted in a Host header field. For example, a client wishing
+ to retrieve the resource above directly from the origin server would
+ create a TCP connection to port 80 of the host "www.w3.org" and send
+ the lines:
+
+ GET /pub/WWW/TheProject.html HTTP/1.1
+ Host: www.w3.org
+
+ followed by the remainder of the Request. Note that the absolute path
+ cannot be empty; if none is present in the original URI, it MUST be
+ given as "/" (the server root).
+
+ The Request-URI is transmitted in the format specified in section
+ 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
+ [42], the origin server MUST decode the Request-URI in order to
+ properly interpret the request. Servers SHOULD respond to invalid
+ Request-URIs with an appropriate status code.
+
+ A transparent proxy MUST NOT rewrite the "abs_path" part of the
+ received Request-URI when forwarding it to the next inbound server,
+ except as noted above to replace a null abs_path with "/".
+
+ Note: The "no rewrite" rule prevents the proxy from changing the
+ meaning of the request when the origin server is improperly using
+ a non-reserved URI character for a reserved purpose. Implementors
+ should be aware that some pre-HTTP/1.1 proxies have been known to
+ rewrite the Request-URI.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 37]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+5.2 The Resource Identified by a Request
+
+ The exact resource identified by an Internet request is determined by
+ examining both the Request-URI and the Host header field.
+
+ An origin server that does not allow resources to differ by the
+ requested host MAY ignore the Host header field value when
+ determining the resource identified by an HTTP/1.1 request. (But see
+ section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
+
+ An origin server that does differentiate resources based on the host
+ requested (sometimes referred to as virtual hosts or vanity host
+ names) MUST use the following rules for determining the requested
+ resource on an HTTP/1.1 request:
+
+ 1. If Request-URI is an absoluteURI, the host is part of the
+ Request-URI. Any Host header field value in the request MUST be
+ ignored.
+
+ 2. If the Request-URI is not an absoluteURI, and the request includes
+ a Host header field, the host is determined by the Host header
+ field value.
+
+ 3. If the host as determined by rule 1 or 2 is not a valid host on
+ the server, the response MUST be a 400 (Bad Request) error message.
+
+ Recipients of an HTTP/1.0 request that lacks a Host header field MAY
+ attempt to use heuristics (e.g., examination of the URI path for
+ something unique to a particular host) in order to determine what
+ exact resource is being requested.
+
+5.3 Request Header Fields
+
+ The request-header fields allow the client to pass additional
+ information about the request, and about the client itself, to the
+ server. These fields act as request modifiers, with semantics
+ equivalent to the parameters on a programming language method
+ invocation.
+
+ request-header = Accept ; Section 14.1
+ | Accept-Charset ; Section 14.2
+ | Accept-Encoding ; Section 14.3
+ | Accept-Language ; Section 14.4
+ | Authorization ; Section 14.8
+ | Expect ; Section 14.20
+ | From ; Section 14.22
+ | Host ; Section 14.23
+ | If-Match ; Section 14.24
+
+
+
+Fielding, et al. Standards Track [Page 38]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ | If-Modified-Since ; Section 14.25
+ | If-None-Match ; Section 14.26
+ | If-Range ; Section 14.27
+ | If-Unmodified-Since ; Section 14.28
+ | Max-Forwards ; Section 14.31
+ | Proxy-Authorization ; Section 14.34
+ | Range ; Section 14.35
+ | Referer ; Section 14.36
+ | TE ; Section 14.39
+ | User-Agent ; Section 14.43
+
+ Request-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields MAY be given the semantics of request-
+ header fields if all parties in the communication recognize them to
+ be request-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+6 Response
+
+ After receiving and interpreting a request message, a server responds
+ with an HTTP response message.
+
+ Response = Status-Line ; Section 6.1
+ *(( general-header ; Section 4.5
+ | response-header ; Section 6.2
+ | entity-header ) CRLF) ; Section 7.1
+ CRLF
+ [ message-body ] ; Section 7.2
+
+6.1 Status-Line
+
+ The first line of a Response message is the Status-Line, consisting
+ of the protocol version followed by a numeric status code and its
+ associated textual phrase, with each element separated by SP
+ characters. No CR or LF is allowed except in the final CRLF sequence.
+
+ Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+6.1.1 Status Code and Reason Phrase
+
+ The Status-Code element is a 3-digit integer result code of the
+ attempt to understand and satisfy the request. These codes are fully
+ defined in section 10. The Reason-Phrase is intended to give a short
+ textual description of the Status-Code. The Status-Code is intended
+ for use by automata and the Reason-Phrase is intended for the human
+ user. The client is not required to examine or display the Reason-
+ Phrase.
+
+
+
+Fielding, et al. Standards Track [Page 39]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The first digit of the Status-Code defines the class of response. The
+ last two digits do not have any categorization role. There are 5
+ values for the first digit:
+
+ - 1xx: Informational - Request received, continuing process
+
+ - 2xx: Success - The action was successfully received,
+ understood, and accepted
+
+ - 3xx: Redirection - Further action must be taken in order to
+ complete the request
+
+ - 4xx: Client Error - The request contains bad syntax or cannot
+ be fulfilled
+
+ - 5xx: Server Error - The server failed to fulfill an apparently
+ valid request
+
+ The individual values of the numeric status codes defined for
+ HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+ presented below. The reason phrases listed here are only
+ recommendations -- they MAY be replaced by local equivalents without
+ affecting the protocol.
+
+ Status-Code =
+ "100" ; Section 10.1.1: Continue
+ | "101" ; Section 10.1.2: Switching Protocols
+ | "200" ; Section 10.2.1: OK
+ | "201" ; Section 10.2.2: Created
+ | "202" ; Section 10.2.3: Accepted
+ | "203" ; Section 10.2.4: Non-Authoritative Information
+ | "204" ; Section 10.2.5: No Content
+ | "205" ; Section 10.2.6: Reset Content
+ | "206" ; Section 10.2.7: Partial Content
+ | "300" ; Section 10.3.1: Multiple Choices
+ | "301" ; Section 10.3.2: Moved Permanently
+ | "302" ; Section 10.3.3: Found
+ | "303" ; Section 10.3.4: See Other
+ | "304" ; Section 10.3.5: Not Modified
+ | "305" ; Section 10.3.6: Use Proxy
+ | "307" ; Section 10.3.8: Temporary Redirect
+ | "400" ; Section 10.4.1: Bad Request
+ | "401" ; Section 10.4.2: Unauthorized
+ | "402" ; Section 10.4.3: Payment Required
+ | "403" ; Section 10.4.4: Forbidden
+ | "404" ; Section 10.4.5: Not Found
+ | "405" ; Section 10.4.6: Method Not Allowed
+ | "406" ; Section 10.4.7: Not Acceptable
+
+
+
+Fielding, et al. Standards Track [Page 40]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ | "407" ; Section 10.4.8: Proxy Authentication Required
+ | "408" ; Section 10.4.9: Request Time-out
+ | "409" ; Section 10.4.10: Conflict
+ | "410" ; Section 10.4.11: Gone
+ | "411" ; Section 10.4.12: Length Required
+ | "412" ; Section 10.4.13: Precondition Failed
+ | "413" ; Section 10.4.14: Request Entity Too Large
+ | "414" ; Section 10.4.15: Request-URI Too Large
+ | "415" ; Section 10.4.16: Unsupported Media Type
+ | "416" ; Section 10.4.17: Requested range not satisfiable
+ | "417" ; Section 10.4.18: Expectation Failed
+ | "500" ; Section 10.5.1: Internal Server Error
+ | "501" ; Section 10.5.2: Not Implemented
+ | "502" ; Section 10.5.3: Bad Gateway
+ | "503" ; Section 10.5.4: Service Unavailable
+ | "504" ; Section 10.5.5: Gateway Time-out
+ | "505" ; Section 10.5.6: HTTP Version not supported
+ | extension-code
+
+ extension-code = 3DIGIT
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+
+ HTTP status codes are extensible. HTTP applications are not required
+ to understand the meaning of all registered status codes, though such
+ understanding is obviously desirable. However, applications MUST
+ understand the class of any status code, as indicated by the first
+ digit, and treat any unrecognized response as being equivalent to the
+ x00 status code of that class, with the exception that an
+ unrecognized response MUST NOT be cached. For example, if an
+ unrecognized status code of 431 is received by the client, it can
+ safely assume that there was something wrong with its request and
+ treat the response as if it had received a 400 status code. In such
+ cases, user agents SHOULD present to the user the entity returned
+ with the response, since that entity is likely to include human-
+ readable information which will explain the unusual status.
+
+6.2 Response Header Fields
+
+ The response-header fields allow the server to pass additional
+ information about the response which cannot be placed in the Status-
+ Line. These header fields give information about the server and about
+ further access to the resource identified by the Request-URI.
+
+ response-header = Accept-Ranges ; Section 14.5
+ | Age ; Section 14.6
+ | ETag ; Section 14.19
+ | Location ; Section 14.30
+ | Proxy-Authenticate ; Section 14.33
+
+
+
+Fielding, et al. Standards Track [Page 41]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ | Retry-After ; Section 14.37
+ | Server ; Section 14.38
+ | Vary ; Section 14.44
+ | WWW-Authenticate ; Section 14.47
+
+ Response-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields MAY be given the semantics of response-
+ header fields if all parties in the communication recognize them to
+ be response-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+
+7 Entity
+
+ Request and Response messages MAY transfer an entity if not otherwise
+ restricted by the request method or response status code. An entity
+ consists of entity-header fields and an entity-body, although some
+ responses will only include the entity-headers.
+
+ In this section, both sender and recipient refer to either the client
+ or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+ Entity-header fields define metainformation about the entity-body or,
+ if no body is present, about the resource identified by the request.
+ Some of this metainformation is OPTIONAL; some might be REQUIRED by
+ portions of this specification.
+
+ entity-header = Allow ; Section 14.7
+ | Content-Encoding ; Section 14.11
+ | Content-Language ; Section 14.12
+ | Content-Length ; Section 14.13
+ | Content-Location ; Section 14.14
+ | Content-MD5 ; Section 14.15
+ | Content-Range ; Section 14.16
+ | Content-Type ; Section 14.17
+ | Expires ; Section 14.21
+ | Last-Modified ; Section 14.29
+ | extension-header
+
+ extension-header = message-header
+
+ The extension-header mechanism allows additional entity-header fields
+ to be defined without changing the protocol, but these fields cannot
+ be assumed to be recognizable by the recipient. Unrecognized header
+ fields SHOULD be ignored by the recipient and MUST be forwarded by
+ transparent proxies.
+
+
+
+Fielding, et al. Standards Track [Page 42]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+7.2 Entity Body
+
+ The entity-body (if any) sent with an HTTP request or response is in
+ a format and encoding defined by the entity-header fields.
+
+ entity-body = *OCTET
+
+ An entity-body is only present in a message when a message-body is
+ present, as described in section 4.3. The entity-body is obtained
+ from the message-body by decoding any Transfer-Encoding that might
+ have been applied to ensure safe and proper transfer of the message.
+
+7.2.1 Type
+
+ When an entity-body is included with a message, the data type of that
+ body is determined via the header fields Content-Type and Content-
+ Encoding. These define a two-layer, ordered encoding model:
+
+ entity-body := Content-Encoding( Content-Type( data ) )
+
+ Content-Type specifies the media type of the underlying data.
+ Content-Encoding may be used to indicate any additional content
+ codings applied to the data, usually for the purpose of data
+ compression, that are a property of the requested resource. There is
+ no default encoding.
+
+ Any HTTP/1.1 message containing an entity-body SHOULD include a
+ Content-Type header field defining the media type of that body. If
+ and only if the media type is not given by a Content-Type field, the
+ recipient MAY attempt to guess the media type via inspection of its
+ content and/or the name extension(s) of the URI used to identify the
+ resource. If the media type remains unknown, the recipient SHOULD
+ treat it as type "application/octet-stream".
+
+7.2.2 Entity Length
+
+ The entity-length of a message is the length of the message-body
+ before any transfer-codings have been applied. Section 4.4 defines
+ how the transfer-length of a message-body is determined.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 43]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+ Prior to persistent connections, a separate TCP connection was
+ established to fetch each URL, increasing the load on HTTP servers
+ and causing congestion on the Internet. The use of inline images and
+ other associated data often require a client to make multiple
+ requests of the same server in a short amount of time. Analysis of
+ these performance problems and results from a prototype
+ implementation are available [26] [30]. Implementation experience and
+ measurements of actual HTTP/1.1 (RFC 2068) implementations show good
+ results [39]. Alternatives have also been explored, for example,
+ T/TCP [27].
+
+ Persistent HTTP connections have a number of advantages:
+
+ - By opening and closing fewer TCP connections, CPU time is saved
+ in routers and hosts (clients, servers, proxies, gateways,
+ tunnels, or caches), and memory used for TCP protocol control
+ blocks can be saved in hosts.
+
+ - HTTP requests and responses can be pipelined on a connection.
+ Pipelining allows a client to make multiple requests without
+ waiting for each response, allowing a single TCP connection to
+ be used much more efficiently, with much lower elapsed time.
+
+ - Network congestion is reduced by reducing the number of packets
+ caused by TCP opens, and by allowing TCP sufficient time to
+ determine the congestion state of the network.
+
+ - Latency on subsequent requests is reduced since there is no time
+ spent in TCP's connection opening handshake.
+
+ - HTTP can evolve more gracefully, since errors can be reported
+ without the penalty of closing the TCP connection. Clients using
+ future versions of HTTP might optimistically try a new feature,
+ but if communicating with an older server, retry with old
+ semantics after an error is reported.
+
+ HTTP implementations SHOULD implement persistent connections.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 44]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+8.1.2 Overall Operation
+
+ A significant difference between HTTP/1.1 and earlier versions of
+ HTTP is that persistent connections are the default behavior of any
+ HTTP connection. That is, unless otherwise indicated, the client
+ SHOULD assume that the server will maintain a persistent connection,
+ even after error responses from the server.
+
+ Persistent connections provide a mechanism by which a client and a
+ server can signal the close of a TCP connection. This signaling takes
+ place using the Connection header field (section 14.10). Once a close
+ has been signaled, the client MUST NOT send any more requests on that
+ connection.
+
+8.1.2.1 Negotiation
+
+ An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+ maintain a persistent connection unless a Connection header including
+ the connection-token "close" was sent in the request. If the server
+ chooses to close the connection immediately after sending the
+ response, it SHOULD send a Connection header including the
+ connection-token close.
+
+ An HTTP/1.1 client MAY expect a connection to remain open, but would
+ decide to keep it open based on whether the response from a server
+ contains a Connection header with the connection-token close. In case
+ the client does not want to maintain a connection for more than that
+ request, it SHOULD send a Connection header including the
+ connection-token close.
+
+ If either the client or the server sends the close token in the
+ Connection header, that request becomes the last one for the
+ connection.
+
+ Clients and servers SHOULD NOT assume that a persistent connection is
+ maintained for HTTP versions less than 1.1 unless it is explicitly
+ signaled. See section 19.6.2 for more information on backward
+ compatibility with HTTP/1.0 clients.
+
+ In order to remain persistent, all messages on the connection MUST
+ have a self-defined message length (i.e., one not defined by closure
+ of the connection), as described in section 4.4.
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 45]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+8.1.2.2 Pipelining
+
+ A client that supports persistent connections MAY "pipeline" its
+ requests (i.e., send multiple requests without waiting for each
+ response). A server MUST send its responses to those requests in the
+ same order that the requests were received.
+
+ Clients which assume persistent connections and pipeline immediately
+ after connection establishment SHOULD be prepared to retry their
+ connection if the first pipelined attempt fails. If a client does
+ such a retry, it MUST NOT pipeline before it knows the connection is
+ persistent. Clients MUST also be prepared to resend their requests if
+ the server closes the connection before sending all of the
+ corresponding responses.
+
+ Clients SHOULD NOT pipeline requests using non-idempotent methods or
+ non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
+ premature termination of the transport connection could lead to
+ indeterminate results. A client wishing to send a non-idempotent
+ request SHOULD wait to send that request until it has received the
+ response status for the previous request.
+
+8.1.3 Proxy Servers
+
+ It is especially important that proxies correctly implement the
+ properties of the Connection header field as specified in section
+ 14.10.
+
+ The proxy server MUST signal persistent connections separately with
+ its clients and the origin servers (or other proxy servers) that it
+ connects to. Each persistent connection applies to only one transport
+ link.
+
+ A proxy server MUST NOT establish a HTTP/1.1 persistent connection
+ with an HTTP/1.0 client (but see RFC 2068 [33] for information and
+ discussion of the problems with the Keep-Alive header implemented by
+ many HTTP/1.0 clients).
+
+8.1.4 Practical Considerations
+
+ Servers will usually have some time-out value beyond which they will
+ no longer maintain an inactive connection. Proxy servers might make
+ this a higher value since it is likely that the client will be making
+ more connections through the same server. The use of persistent
+ connections places no requirements on the length (or existence) of
+ this time-out for either the client or the server.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 46]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ When a client or server wishes to time-out it SHOULD issue a graceful
+ close on the transport connection. Clients and servers SHOULD both
+ constantly watch for the other side of the transport close, and
+ respond to it as appropriate. If a client or server does not detect
+ the other side's close promptly it could cause unnecessary resource
+ drain on the network.
+
+ A client, server, or proxy MAY close the transport connection at any
+ time. For example, a client might have started to send a new request
+ at the same time that the server has decided to close the "idle"
+ connection. From the server's point of view, the connection is being
+ closed while it was idle, but from the client's point of view, a
+ request is in progress.
+
+ This means that clients, servers, and proxies MUST be able to recover
+ from asynchronous close events. Client software SHOULD reopen the
+ transport connection and retransmit the aborted sequence of requests
+ without user interaction so long as the request sequence is
+ idempotent (see section 9.1.2). Non-idempotent methods or sequences
+ MUST NOT be automatically retried, although user agents MAY offer a
+ human operator the choice of retrying the request(s). Confirmation by
+ user-agent software with semantic understanding of the application
+ MAY substitute for user confirmation. The automatic retry SHOULD NOT
+ be repeated if the second sequence of requests fails.
+
+ Servers SHOULD always respond to at least one request per connection,
+ if at all possible. Servers SHOULD NOT close a connection in the
+ middle of transmitting a response, unless a network or client failure
+ is suspected.
+
+ Clients that use persistent connections SHOULD limit the number of
+ simultaneous connections that they maintain to a given server. A
+ single-user client SHOULD NOT maintain more than 2 connections with
+ any server or proxy. A proxy SHOULD use up to 2*N connections to
+ another server or proxy, where N is the number of simultaneously
+ active users. These guidelines are intended to improve HTTP response
+ times and avoid congestion.
+
+8.2 Message Transmission Requirements
+
+8.2.1 Persistent Connections and Flow Control
+
+ HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
+ flow control mechanisms to resolve temporary overloads, rather than
+ terminating connections with the expectation that clients will retry.
+ The latter technique can exacerbate network congestion.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 47]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+8.2.2 Monitoring Connections for Error Status Messages
+
+ An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
+ the network connection for an error status while it is transmitting
+ the request. If the client sees an error status, it SHOULD
+ immediately cease transmitting the body. If the body is being sent
+ using a "chunked" encoding (section 3.6), a zero length chunk and
+ empty trailer MAY be used to prematurely mark the end of the message.
+ If the body was preceded by a Content-Length header, the client MUST
+ close the connection.
+
+8.2.3 Use of the 100 (Continue) Status
+
+ The purpose of the 100 (Continue) status (see section 10.1.1) is to
+ allow a client that is sending a request message with a request body
+ to determine if the origin server is willing to accept the request
+ (based on the request headers) before the client sends the request
+ body. In some cases, it might either be inappropriate or highly
+ inefficient for the client to send the body if the server will reject
+ the message without looking at the body.
+
+ Requirements for HTTP/1.1 clients:
+
+ - If a client will wait for a 100 (Continue) response before
+ sending the request body, it MUST send an Expect request-header
+ field (section 14.20) with the "100-continue" expectation.
+
+ - A client MUST NOT send an Expect request-header field (section
+ 14.20) with the "100-continue" expectation if it does not intend
+ to send a request body.
+
+ Because of the presence of older implementations, the protocol allows
+ ambiguous situations in which a client may send "Expect: 100-
+ continue" without receiving either a 417 (Expectation Failed) status
+ or a 100 (Continue) status. Therefore, when a client sends this
+ header field to an origin server (possibly via a proxy) from which it
+ has never seen a 100 (Continue) status, the client SHOULD NOT wait
+ for an indefinite period before sending the request body.
+
+ Requirements for HTTP/1.1 origin servers:
+
+ - Upon receiving a request which includes an Expect request-header
+ field with the "100-continue" expectation, an origin server MUST
+ either respond with 100 (Continue) status and continue to read
+ from the input stream, or respond with a final status code. The
+ origin server MUST NOT wait for the request body before sending
+ the 100 (Continue) response. If it responds with a final status
+ code, it MAY close the transport connection or it MAY continue
+
+
+
+Fielding, et al. Standards Track [Page 48]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ to read and discard the rest of the request. It MUST NOT
+ perform the requested method if it returns a final status code.
+
+ - An origin server SHOULD NOT send a 100 (Continue) response if
+ the request message does not include an Expect request-header
+ field with the "100-continue" expectation, and MUST NOT send a
+ 100 (Continue) response if such a request comes from an HTTP/1.0
+ (or earlier) client. There is an exception to this rule: for
+ compatibility with RFC 2068, a server MAY send a 100 (Continue)
+ status in response to an HTTP/1.1 PUT or POST request that does
+ not include an Expect request-header field with the "100-
+ continue" expectation. This exception, the purpose of which is
+ to minimize any client processing delays associated with an
+ undeclared wait for 100 (Continue) status, applies only to
+ HTTP/1.1 requests, and not to requests with any other HTTP-
+ version value.
+
+ - An origin server MAY omit a 100 (Continue) response if it has
+ already received some or all of the request body for the
+ corresponding request.
+
+ - An origin server that sends a 100 (Continue) response MUST
+ ultimately send a final status code, once the request body is
+ received and processed, unless it terminates the transport
+ connection prematurely.
+
+ - If an origin server receives a request that does not include an
+ Expect request-header field with the "100-continue" expectation,
+ the request includes a request body, and the server responds
+ with a final status code before reading the entire request body
+ from the transport connection, then the server SHOULD NOT close
+ the transport connection until it has read the entire request,
+ or until the client closes the connection. Otherwise, the client
+ might not reliably receive the response message. However, this
+ requirement is not be construed as preventing a server from
+ defending itself against denial-of-service attacks, or from
+ badly broken client implementations.
+
+ Requirements for HTTP/1.1 proxies:
+
+ - If a proxy receives a request that includes an Expect request-
+ header field with the "100-continue" expectation, and the proxy
+ either knows that the next-hop server complies with HTTP/1.1 or
+ higher, or does not know the HTTP version of the next-hop
+ server, it MUST forward the request, including the Expect header
+ field.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 49]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - If the proxy knows that the version of the next-hop server is
+ HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
+ respond with a 417 (Expectation Failed) status.
+
+ - Proxies SHOULD maintain a cache recording the HTTP version
+ numbers received from recently-referenced next-hop servers.
+
+ - A proxy MUST NOT forward a 100 (Continue) response if the
+ request message was received from an HTTP/1.0 (or earlier)
+ client and did not include an Expect request-header field with
+ the "100-continue" expectation. This requirement overrides the
+ general rule for forwarding of 1xx responses (see section 10.1).
+
+8.2.4 Client Behavior if Server Prematurely Closes Connection
+
+ If an HTTP/1.1 client sends a request which includes a request body,
+ but which does not include an Expect request-header field with the
+ "100-continue" expectation, and if the client is not directly
+ connected to an HTTP/1.1 origin server, and if the client sees the
+ connection close before receiving any status from the server, the
+ client SHOULD retry the request. If the client does retry this
+ request, it MAY use the following "binary exponential backoff"
+ algorithm to be assured of obtaining a reliable response:
+
+ 1. Initiate a new connection to the server
+
+ 2. Transmit the request-headers
+
+ 3. Initialize a variable R to the estimated round-trip time to the
+ server (e.g., based on the time it took to establish the
+ connection), or to a constant value of 5 seconds if the round-
+ trip time is not available.
+
+ 4. Compute T = R * (2**N), where N is the number of previous
+ retries of this request.
+
+ 5. Wait either for an error response from the server, or for T
+ seconds (whichever comes first)
+
+ 6. If no error response is received, after T seconds transmit the
+ body of the request.
+
+ 7. If client sees that the connection is closed prematurely,
+ repeat from step 1 until the request is accepted, an error
+ response is received, or the user becomes impatient and
+ terminates the retry process.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 50]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If at any point an error status is received, the client
+
+ - SHOULD NOT continue and
+
+ - SHOULD close the connection if it has not completed sending the
+ request message.
+
+9 Method Definitions
+
+ The set of common methods for HTTP/1.1 is defined below. Although
+ this set can be expanded, additional methods cannot be assumed to
+ share the same semantics for separately extended clients and servers.
+
+ The Host request-header field (section 14.23) MUST accompany all
+ HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+ Implementors should be aware that the software represents the user in
+ their interactions over the Internet, and should be careful to allow
+ the user to be aware of any actions they might take which may have an
+ unexpected significance to themselves or others.
+
+ In particular, the convention has been established that the GET and
+ HEAD methods SHOULD NOT have the significance of taking an action
+ other than retrieval. These methods ought to be considered "safe".
+ This allows user agents to represent other methods, such as POST, PUT
+ and DELETE, in a special way, so that the user is made aware of the
+ fact that a possibly unsafe action is being requested.
+
+ Naturally, it is not possible to ensure that the server does not
+ generate side-effects as a result of performing a GET request; in
+ fact, some dynamic resources consider that a feature. The important
+ distinction here is that the user did not request the side-effects,
+ so therefore cannot be held accountable for them.
+
+9.1.2 Idempotent Methods
+
+ Methods can also have the property of "idempotence" in that (aside
+ from error or expiration issues) the side-effects of N > 0 identical
+ requests is the same as for a single request. The methods GET, HEAD,
+ PUT and DELETE share this property. Also, the methods OPTIONS and
+ TRACE SHOULD NOT have side effects, and so are inherently idempotent.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 51]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ However, it is possible that a sequence of several requests is non-
+ idempotent, even if all of the methods executed in that sequence are
+ idempotent. (A sequence is idempotent if a single execution of the
+ entire sequence always yields a result that is not changed by a
+ reexecution of all, or part, of that sequence.) For example, a
+ sequence is non-idempotent if its result depends on a value that is
+ later modified in the same sequence.
+
+ A sequence that never has side effects is idempotent, by definition
+ (provided that no concurrent operations are being executed on the
+ same set of resources).
+
+9.2 OPTIONS
+
+ The OPTIONS method represents a request for information about the
+ communication options available on the request/response chain
+ identified by the Request-URI. This method allows the client to
+ determine the options and/or requirements associated with a resource,
+ or the capabilities of a server, without implying a resource action
+ or initiating a resource retrieval.
+
+ Responses to this method are not cacheable.
+
+ If the OPTIONS request includes an entity-body (as indicated by the
+ presence of Content-Length or Transfer-Encoding), then the media type
+ MUST be indicated by a Content-Type field. Although this
+ specification does not define any use for such a body, future
+ extensions to HTTP might use the OPTIONS body to make more detailed
+ queries on the server. A server that does not support such an
+ extension MAY discard the request body.
+
+ If the Request-URI is an asterisk ("*"), the OPTIONS request is
+ intended to apply to the server in general rather than to a specific
+ resource. Since a server's communication options typically depend on
+ the resource, the "*" request is only useful as a "ping" or "no-op"
+ type of method; it does nothing beyond allowing the client to test
+ the capabilities of the server. For example, this can be used to test
+ a proxy for HTTP/1.1 compliance (or lack thereof).
+
+ If the Request-URI is not an asterisk, the OPTIONS request applies
+ only to the options that are available when communicating with that
+ resource.
+
+ A 200 response SHOULD include any header fields that indicate
+ optional features implemented by the server and applicable to that
+ resource (e.g., Allow), possibly including extensions not defined by
+ this specification. The response body, if any, SHOULD also include
+ information about the communication options. The format for such a
+
+
+
+Fielding, et al. Standards Track [Page 52]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ body is not defined by this specification, but might be defined by
+ future extensions to HTTP. Content negotiation MAY be used to select
+ the appropriate response format. If no response body is included, the
+ response MUST include a Content-Length field with a field-value of
+ "0".
+
+ The Max-Forwards request-header field MAY be used to target a
+ specific proxy in the request chain. When a proxy receives an OPTIONS
+ request on an absoluteURI for which request forwarding is permitted,
+ the proxy MUST check for a Max-Forwards field. If the Max-Forwards
+ field-value is zero ("0"), the proxy MUST NOT forward the message;
+ instead, the proxy SHOULD respond with its own communication options.
+ If the Max-Forwards field-value is an integer greater than zero, the
+ proxy MUST decrement the field-value when it forwards the request. If
+ no Max-Forwards field is present in the request, then the forwarded
+ request MUST NOT include a Max-Forwards field.
+
+9.3 GET
+
+ The GET method means retrieve whatever information (in the form of an
+ entity) is identified by the Request-URI. If the Request-URI refers
+ to a data-producing process, it is the produced data which shall be
+ returned as the entity in the response and not the source text of the
+ process, unless that text happens to be the output of the process.
+
+ The semantics of the GET method change to a "conditional GET" if the
+ request message includes an If-Modified-Since, If-Unmodified-Since,
+ If-Match, If-None-Match, or If-Range header field. A conditional GET
+ method requests that the entity be transferred only under the
+ circumstances described by the conditional header field(s). The
+ conditional GET method is intended to reduce unnecessary network
+ usage by allowing cached entities to be refreshed without requiring
+ multiple requests or transferring data already held by the client.
+
+ The semantics of the GET method change to a "partial GET" if the
+ request message includes a Range header field. A partial GET requests
+ that only part of the entity be transferred, as described in section
+ 14.35. The partial GET method is intended to reduce unnecessary
+ network usage by allowing partially-retrieved entities to be
+ completed without transferring data already held by the client.
+
+ The response to a GET request is cacheable if and only if it meets
+ the requirements for HTTP caching described in section 13.
+
+ See section 15.1.3 for security considerations when used for forms.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 53]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+9.4 HEAD
+
+ The HEAD method is identical to GET except that the server MUST NOT
+ return a message-body in the response. The metainformation contained
+ in the HTTP headers in response to a HEAD request SHOULD be identical
+ to the information sent in response to a GET request. This method can
+ be used for obtaining metainformation about the entity implied by the
+ request without transferring the entity-body itself. This method is
+ often used for testing hypertext links for validity, accessibility,
+ and recent modification.
+
+ The response to a HEAD request MAY be cacheable in the sense that the
+ information contained in the response MAY be used to update a
+ previously cached entity from that resource. If the new field values
+ indicate that the cached entity differs from the current entity (as
+ would be indicated by a change in Content-Length, Content-MD5, ETag
+ or Last-Modified), then the cache MUST treat the cache entry as
+ stale.
+
+9.5 POST
+
+ The POST method is used to request that the origin server accept the
+ entity enclosed in the request as a new subordinate of the resource
+ identified by the Request-URI in the Request-Line. POST is designed
+ to allow a uniform method to cover the following functions:
+
+ - Annotation of existing resources;
+
+ - Posting a message to a bulletin board, newsgroup, mailing list,
+ or similar group of articles;
+
+ - Providing a block of data, such as the result of submitting a
+ form, to a data-handling process;
+
+ - Extending a database through an append operation.
+
+ The actual function performed by the POST method is determined by the
+ server and is usually dependent on the Request-URI. The posted entity
+ is subordinate to that URI in the same way that a file is subordinate
+ to a directory containing it, a news article is subordinate to a
+ newsgroup to which it is posted, or a record is subordinate to a
+ database.
+
+ The action performed by the POST method might not result in a
+ resource that can be identified by a URI. In this case, either 200
+ (OK) or 204 (No Content) is the appropriate response status,
+ depending on whether or not the response includes an entity that
+ describes the result.
+
+
+
+Fielding, et al. Standards Track [Page 54]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If a resource has been created on the origin server, the response
+ SHOULD be 201 (Created) and contain an entity which describes the
+ status of the request and refers to the new resource, and a Location
+ header (see section 14.30).
+
+ Responses to this method are not cacheable, unless the response
+ includes appropriate Cache-Control or Expires header fields. However,
+ the 303 (See Other) response can be used to direct the user agent to
+ retrieve a cacheable resource.
+
+ POST requests MUST obey the message transmission requirements set out
+ in section 8.2.
+
+ See section 15.1.3 for security considerations.
+
+9.6 PUT
+
+ The PUT method requests that the enclosed entity be stored under the
+ supplied Request-URI. If the Request-URI refers to an already
+ existing resource, the enclosed entity SHOULD be considered as a
+ modified version of the one residing on the origin server. If the
+ Request-URI does not point to an existing resource, and that URI is
+ capable of being defined as a new resource by the requesting user
+ agent, the origin server can create the resource with that URI. If a
+ new resource is created, the origin server MUST inform the user agent
+ via the 201 (Created) response. If an existing resource is modified,
+ either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
+ to indicate successful completion of the request. If the resource
+ could not be created or modified with the Request-URI, an appropriate
+ error response SHOULD be given that reflects the nature of the
+ problem. The recipient of the entity MUST NOT ignore any Content-*
+ (e.g. Content-Range) headers that it does not understand or implement
+ and MUST return a 501 (Not Implemented) response in such cases.
+
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries SHOULD be
+ treated as stale. Responses to this method are not cacheable.
+
+ The fundamental difference between the POST and PUT requests is
+ reflected in the different meaning of the Request-URI. The URI in a
+ POST request identifies the resource that will handle the enclosed
+ entity. That resource might be a data-accepting process, a gateway to
+ some other protocol, or a separate entity that accepts annotations.
+ In contrast, the URI in a PUT request identifies the entity enclosed
+ with the request -- the user agent knows what URI is intended and the
+ server MUST NOT attempt to apply the request to some other resource.
+ If the server desires that the request be applied to a different URI,
+
+
+
+
+Fielding, et al. Standards Track [Page 55]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ it MUST send a 301 (Moved Permanently) response; the user agent MAY
+ then make its own decision regarding whether or not to redirect the
+ request.
+
+ A single resource MAY be identified by many different URIs. For
+ example, an article might have a URI for identifying "the current
+ version" which is separate from the URI identifying each particular
+ version. In this case, a PUT request on a general URI might result in
+ several other URIs being defined by the origin server.
+
+ HTTP/1.1 does not define how a PUT method affects the state of an
+ origin server.
+
+ PUT requests MUST obey the message transmission requirements set out
+ in section 8.2.
+
+ Unless otherwise specified for a particular entity-header, the
+ entity-headers in the PUT request SHOULD be applied to the resource
+ created or modified by the PUT.
+
+9.7 DELETE
+
+ The DELETE method requests that the origin server delete the resource
+ identified by the Request-URI. This method MAY be overridden by human
+ intervention (or other means) on the origin server. The client cannot
+ be guaranteed that the operation has been carried out, even if the
+ status code returned from the origin server indicates that the action
+ has been completed successfully. However, the server SHOULD NOT
+ indicate success unless, at the time the response is given, it
+ intends to delete the resource or move it to an inaccessible
+ location.
+
+ A successful response SHOULD be 200 (OK) if the response includes an
+ entity describing the status, 202 (Accepted) if the action has not
+ yet been enacted, or 204 (No Content) if the action has been enacted
+ but the response does not include an entity.
+
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries SHOULD be
+ treated as stale. Responses to this method are not cacheable.
+
+9.8 TRACE
+
+ The TRACE method is used to invoke a remote, application-layer loop-
+ back of the request message. The final recipient of the request
+ SHOULD reflect the message received back to the client as the
+ entity-body of a 200 (OK) response. The final recipient is either the
+
+
+
+
+Fielding, et al. Standards Track [Page 56]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ origin server or the first proxy or gateway to receive a Max-Forwards
+ value of zero (0) in the request (see section 14.31). A TRACE request
+ MUST NOT include an entity.
+
+ TRACE allows the client to see what is being received at the other
+ end of the request chain and use that data for testing or diagnostic
+ information. The value of the Via header field (section 14.45) is of
+ particular interest, since it acts as a trace of the request chain.
+ Use of the Max-Forwards header field allows the client to limit the
+ length of the request chain, which is useful for testing a chain of
+ proxies forwarding messages in an infinite loop.
+
+ If the request is valid, the response SHOULD contain the entire
+ request message in the entity-body, with a Content-Type of
+ "message/http". Responses to this method MUST NOT be cached.
+
+9.9 CONNECT
+
+ This specification reserves the method name CONNECT for use with a
+ proxy that can dynamically switch to being a tunnel (e.g. SSL
+ tunneling [44]).
+
+10 Status Code Definitions
+
+ Each Status-Code is described below, including a description of which
+ method(s) it can follow and any metainformation required in the
+ response.
+
+10.1 Informational 1xx
+
+ This class of status code indicates a provisional response,
+ consisting only of the Status-Line and optional headers, and is
+ terminated by an empty line. There are no required headers for this
+ class of status code. Since HTTP/1.0 did not define any 1xx status
+ codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
+ except under experimental conditions.
+
+ A client MUST be prepared to accept one or more 1xx status responses
+ prior to a regular response, even if the client does not expect a 100
+ (Continue) status message. Unexpected 1xx status responses MAY be
+ ignored by a user agent.
+
+ Proxies MUST forward 1xx responses, unless the connection between the
+ proxy and its client has been closed, or unless the proxy itself
+ requested the generation of the 1xx response. (For example, if a
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 57]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ proxy adds a "Expect: 100-continue" field when it forwards a request,
+ then it need not forward the corresponding 100 (Continue)
+ response(s).)
+
+10.1.1 100 Continue
+
+ The client SHOULD continue with its request. This interim response is
+ used to inform the client that the initial part of the request has
+ been received and has not yet been rejected by the server. The client
+ SHOULD continue by sending the remainder of the request or, if the
+ request has already been completed, ignore this response. The server
+ MUST send a final response after the request has been completed. See
+ section 8.2.3 for detailed discussion of the use and handling of this
+ status code.
+
+10.1.2 101 Switching Protocols
+
+ The server understands and is willing to comply with the client's
+ request, via the Upgrade message header field (section 14.42), for a
+ change in the application protocol being used on this connection. The
+ server will switch protocols to those defined by the response's
+ Upgrade header field immediately after the empty line which
+ terminates the 101 response.
+
+ The protocol SHOULD be switched only when it is advantageous to do
+ so. For example, switching to a newer version of HTTP is advantageous
+ over older versions, and switching to a real-time, synchronous
+ protocol might be advantageous when delivering resources that use
+ such features.
+
+10.2 Successful 2xx
+
+ This class of status code indicates that the client's request was
+ successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+ The request has succeeded. The information returned with the response
+ is dependent on the method used in the request, for example:
+
+ GET an entity corresponding to the requested resource is sent in
+ the response;
+
+ HEAD the entity-header fields corresponding to the requested
+ resource are sent in the response without any message-body;
+
+ POST an entity describing or containing the result of the action;
+
+
+
+
+Fielding, et al. Standards Track [Page 58]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ TRACE an entity containing the request message as received by the
+ end server.
+
+10.2.2 201 Created
+
+ The request has been fulfilled and resulted in a new resource being
+ created. The newly created resource can be referenced by the URI(s)
+ returned in the entity of the response, with the most specific URI
+ for the resource given by a Location header field. The response
+ SHOULD include an entity containing a list of resource
+ characteristics and location(s) from which the user or user agent can
+ choose the one most appropriate. The entity format is specified by
+ the media type given in the Content-Type header field. The origin
+ server MUST create the resource before returning the 201 status code.
+ If the action cannot be carried out immediately, the server SHOULD
+ respond with 202 (Accepted) response instead.
+
+ A 201 response MAY contain an ETag response header field indicating
+ the current value of the entity tag for the requested variant just
+ created, see section 14.19.
+
+10.2.3 202 Accepted
+
+ The request has been accepted for processing, but the processing has
+ not been completed. The request might or might not eventually be
+ acted upon, as it might be disallowed when processing actually takes
+ place. There is no facility for re-sending a status code from an
+ asynchronous operation such as this.
+
+ The 202 response is intentionally non-committal. Its purpose is to
+ allow a server to accept a request for some other process (perhaps a
+ batch-oriented process that is only run once per day) without
+ requiring that the user agent's connection to the server persist
+ until the process is completed. The entity returned with this
+ response SHOULD include an indication of the request's current status
+ and either a pointer to a status monitor or some estimate of when the
+ user can expect the request to be fulfilled.
+
+10.2.4 203 Non-Authoritative Information
+
+ The returned metainformation in the entity-header is not the
+ definitive set as available from the origin server, but is gathered
+ from a local or a third-party copy. The set presented MAY be a subset
+ or superset of the original version. For example, including local
+ annotation information about the resource might result in a superset
+ of the metainformation known by the origin server. Use of this
+ response code is not required and is only appropriate when the
+ response would otherwise be 200 (OK).
+
+
+
+Fielding, et al. Standards Track [Page 59]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.2.5 204 No Content
+
+ The server has fulfilled the request but does not need to return an
+ entity-body, and might want to return updated metainformation. The
+ response MAY include new or updated metainformation in the form of
+ entity-headers, which if present SHOULD be associated with the
+ requested variant.
+
+ If the client is a user agent, it SHOULD NOT change its document view
+ from that which caused the request to be sent. This response is
+ primarily intended to allow input for actions to take place without
+ causing a change to the user agent's active document view, although
+ any new or updated metainformation SHOULD be applied to the document
+ currently in the user agent's active view.
+
+ The 204 response MUST NOT include a message-body, and thus is always
+ terminated by the first empty line after the header fields.
+
+10.2.6 205 Reset Content
+
+ The server has fulfilled the request and the user agent SHOULD reset
+ the document view which caused the request to be sent. This response
+ is primarily intended to allow input for actions to take place via
+ user input, followed by a clearing of the form in which the input is
+ given so that the user can easily initiate another input action. The
+ response MUST NOT include an entity.
+
+10.2.7 206 Partial Content
+
+ The server has fulfilled the partial GET request for the resource.
+ The request MUST have included a Range header field (section 14.35)
+ indicating the desired range, and MAY have included an If-Range
+ header field (section 14.27) to make the request conditional.
+
+ The response MUST include the following header fields:
+
+ - Either a Content-Range header field (section 14.16) indicating
+ the range included with this response, or a multipart/byteranges
+ Content-Type including Content-Range fields for each part. If a
+ Content-Length header field is present in the response, its
+ value MUST match the actual number of OCTETs transmitted in the
+ message-body.
+
+ - Date
+
+ - ETag and/or Content-Location, if the header would have been sent
+ in a 200 response to the same request
+
+
+
+
+Fielding, et al. Standards Track [Page 60]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - Expires, Cache-Control, and/or Vary, if the field-value might
+ differ from that sent in any previous response for the same
+ variant
+
+ If the 206 response is the result of an If-Range request that used a
+ strong cache validator (see section 13.3.3), the response SHOULD NOT
+ include other entity-headers. If the response is the result of an
+ If-Range request that used a weak validator, the response MUST NOT
+ include other entity-headers; this prevents inconsistencies between
+ cached entity-bodies and updated headers. Otherwise, the response
+ MUST include all of the entity-headers that would have been returned
+ with a 200 (OK) response to the same request.
+
+ A cache MUST NOT combine a 206 response with other previously cached
+ content if the ETag or Last-Modified headers do not match exactly,
+ see 13.5.4.
+
+ A cache that does not support the Range and Content-Range headers
+ MUST NOT cache 206 (Partial) responses.
+
+10.3 Redirection 3xx
+
+ This class of status code indicates that further action needs to be
+ taken by the user agent in order to fulfill the request. The action
+ required MAY be carried out by the user agent without interaction
+ with the user if and only if the method used in the second request is
+ GET or HEAD. A client SHOULD detect infinite redirection loops, since
+ such loops generate network traffic for each redirection.
+
+ Note: previous versions of this specification recommended a
+ maximum of five redirections. Content developers should be aware
+ that there might be clients that implement such a fixed
+ limitation.
+
+10.3.1 300 Multiple Choices
+
+ The requested resource corresponds to any one of a set of
+ representations, each with its own specific location, and agent-
+ driven negotiation information (section 12) is being provided so that
+ the user (or user agent) can select a preferred representation and
+ redirect its request to that location.
+
+ Unless it was a HEAD request, the response SHOULD include an entity
+ containing a list of resource characteristics and location(s) from
+ which the user or user agent can choose the one most appropriate. The
+ entity format is specified by the media type given in the Content-
+ Type header field. Depending upon the format and the capabilities of
+
+
+
+
+Fielding, et al. Standards Track [Page 61]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ the user agent, selection of the most appropriate choice MAY be
+ performed automatically. However, this specification does not define
+ any standard for such automatic selection.
+
+ If the server has a preferred choice of representation, it SHOULD
+ include the specific URI for that representation in the Location
+ field; user agents MAY use the Location field value for automatic
+ redirection. This response is cacheable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+ The requested resource has been assigned a new permanent URI and any
+ future references to this resource SHOULD use one of the returned
+ URIs. Clients with link editing capabilities ought to automatically
+ re-link references to the Request-URI to one or more of the new
+ references returned by the server, where possible. This response is
+ cacheable unless indicated otherwise.
+
+ The new permanent URI SHOULD be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response SHOULD contain a short hypertext note with a hyperlink to
+ the new URI(s).
+
+ If the 301 status code is received in response to a request other
+ than GET or HEAD, the user agent MUST NOT automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+
+ Note: When automatically redirecting a POST request after
+ receiving a 301 status code, some existing HTTP/1.0 user agents
+ will erroneously change it into a GET request.
+
+10.3.3 302 Found
+
+ The requested resource resides temporarily under a different URI.
+ Since the redirection might be altered on occasion, the client SHOULD
+ continue to use the Request-URI for future requests. This response
+ is only cacheable if indicated by a Cache-Control or Expires header
+ field.
+
+ The temporary URI SHOULD be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response SHOULD contain a short hypertext note with a hyperlink to
+ the new URI(s).
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 62]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If the 302 status code is received in response to a request other
+ than GET or HEAD, the user agent MUST NOT automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+
+ Note: RFC 1945 and RFC 2068 specify that the client is not allowed
+ to change the method on the redirected request. However, most
+ existing user agent implementations treat 302 as if it were a 303
+ response, performing a GET on the Location field-value regardless
+ of the original request method. The status codes 303 and 307 have
+ been added for servers that wish to make unambiguously clear which
+ kind of reaction is expected of the client.
+
+10.3.4 303 See Other
+
+ The response to the request can be found under a different URI and
+ SHOULD be retrieved using a GET method on that resource. This method
+ exists primarily to allow the output of a POST-activated script to
+ redirect the user agent to a selected resource. The new URI is not a
+ substitute reference for the originally requested resource. The 303
+ response MUST NOT be cached, but the response to the second
+ (redirected) request might be cacheable.
+
+ The different URI SHOULD be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response SHOULD contain a short hypertext note with a hyperlink to
+ the new URI(s).
+
+ Note: Many pre-HTTP/1.1 user agents do not understand the 303
+ status. When interoperability with such clients is a concern, the
+ 302 status code may be used instead, since most user agents react
+ to a 302 response as described here for 303.
+
+10.3.5 304 Not Modified
+
+ If the client has performed a conditional GET request and access is
+ allowed, but the document has not been modified, the server SHOULD
+ respond with this status code. The 304 response MUST NOT contain a
+ message-body, and thus is always terminated by the first empty line
+ after the header fields.
+
+ The response MUST include the following header fields:
+
+ - Date, unless its omission is required by section 14.18.1
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 63]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If a clockless origin server obeys these rules, and proxies and
+ clients add their own Date to any response received without one (as
+ already specified by [RFC 2068], section 14.19), caches will operate
+ correctly.
+
+ - ETag and/or Content-Location, if the header would have been sent
+ in a 200 response to the same request
+
+ - Expires, Cache-Control, and/or Vary, if the field-value might
+ differ from that sent in any previous response for the same
+ variant
+
+ If the conditional GET used a strong cache validator (see section
+ 13.3.3), the response SHOULD NOT include other entity-headers.
+ Otherwise (i.e., the conditional GET used a weak validator), the
+ response MUST NOT include other entity-headers; this prevents
+ inconsistencies between cached entity-bodies and updated headers.
+
+ If a 304 response indicates an entity not currently cached, then the
+ cache MUST disregard the response and repeat the request without the
+ conditional.
+
+ If a cache uses a received 304 response to update a cache entry, the
+ cache MUST update the entry to reflect any new field values given in
+ the response.
+
+10.3.6 305 Use Proxy
+
+ The requested resource MUST be accessed through the proxy given by
+ the Location field. The Location field gives the URI of the proxy.
+ The recipient is expected to repeat this single request via the
+ proxy. 305 responses MUST only be generated by origin servers.
+
+ Note: RFC 2068 was not clear that 305 was intended to redirect a
+ single request, and to be generated by origin servers only. Not
+ observing these limitations has significant security consequences.
+
+10.3.7 306 (Unused)
+
+ The 306 status code was used in a previous version of the
+ specification, is no longer used, and the code is reserved.
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 64]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.3.8 307 Temporary Redirect
+
+ The requested resource resides temporarily under a different URI.
+ Since the redirection MAY be altered on occasion, the client SHOULD
+ continue to use the Request-URI for future requests. This response
+ is only cacheable if indicated by a Cache-Control or Expires header
+ field.
+
+ The temporary URI SHOULD be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response SHOULD contain a short hypertext note with a hyperlink to
+ the new URI(s) , since many pre-HTTP/1.1 user agents do not
+ understand the 307 status. Therefore, the note SHOULD contain the
+ information necessary for a user to repeat the original request on
+ the new URI.
+
+ If the 307 status code is received in response to a request other
+ than GET or HEAD, the user agent MUST NOT automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+
+10.4 Client Error 4xx
+
+ The 4xx class of status code is intended for cases in which the
+ client seems to have erred. Except when responding to a HEAD request,
+ the server SHOULD include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. These status codes are applicable to any request method.
+ User agents SHOULD display any included entity to the user.
+
+ If the client is sending data, a server implementation using TCP
+ SHOULD be careful to ensure that the client acknowledges receipt of
+ the packet(s) containing the response, before the server closes the
+ input connection. If the client continues sending data to the server
+ after the close, the server's TCP stack will send a reset packet to
+ the client, which may erase the client's unacknowledged input buffers
+ before they can be read and interpreted by the HTTP application.
+
+10.4.1 400 Bad Request
+
+ The request could not be understood by the server due to malformed
+ syntax. The client SHOULD NOT repeat the request without
+ modifications.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 65]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.4.2 401 Unauthorized
+
+ The request requires user authentication. The response MUST include a
+ WWW-Authenticate header field (section 14.47) containing a challenge
+ applicable to the requested resource. The client MAY repeat the
+ request with a suitable Authorization header field (section 14.8). If
+ the request already included Authorization credentials, then the 401
+ response indicates that authorization has been refused for those
+ credentials. If the 401 response contains the same challenge as the
+ prior response, and the user agent has already attempted
+ authentication at least once, then the user SHOULD be presented the
+ entity that was given in the response, since that entity might
+ include relevant diagnostic information. HTTP access authentication
+ is explained in "HTTP Authentication: Basic and Digest Access
+ Authentication" [43].
+
+10.4.3 402 Payment Required
+
+ This code is reserved for future use.
+
+10.4.4 403 Forbidden
+
+ The server understood the request, but is refusing to fulfill it.
+ Authorization will not help and the request SHOULD NOT be repeated.
+ If the request method was not HEAD and the server wishes to make
+ public why the request has not been fulfilled, it SHOULD describe the
+ reason for the refusal in the entity. If the server does not wish to
+ make this information available to the client, the status code 404
+ (Not Found) can be used instead.
+
+10.4.5 404 Not Found
+
+ The server has not found anything matching the Request-URI. No
+ indication is given of whether the condition is temporary or
+ permanent. The 410 (Gone) status code SHOULD be used if the server
+ knows, through some internally configurable mechanism, that an old
+ resource is permanently unavailable and has no forwarding address.
+ This status code is commonly used when the server does not wish to
+ reveal exactly why the request has been refused, or when no other
+ response is applicable.
+
+10.4.6 405 Method Not Allowed
+
+ The method specified in the Request-Line is not allowed for the
+ resource identified by the Request-URI. The response MUST include an
+ Allow header containing a list of valid methods for the requested
+ resource.
+
+
+
+
+Fielding, et al. Standards Track [Page 66]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.4.7 406 Not Acceptable
+
+ The resource identified by the request is only capable of generating
+ response entities which have content characteristics not acceptable
+ according to the accept headers sent in the request.
+
+ Unless it was a HEAD request, the response SHOULD include an entity
+ containing a list of available entity characteristics and location(s)
+ from which the user or user agent can choose the one most
+ appropriate. The entity format is specified by the media type given
+ in the Content-Type header field. Depending upon the format and the
+ capabilities of the user agent, selection of the most appropriate
+ choice MAY be performed automatically. However, this specification
+ does not define any standard for such automatic selection.
+
+ Note: HTTP/1.1 servers are allowed to return responses which are
+ not acceptable according to the accept headers sent in the
+ request. In some cases, this may even be preferable to sending a
+ 406 response. User agents are encouraged to inspect the headers of
+ an incoming response to determine if it is acceptable.
+
+ If the response could be unacceptable, a user agent SHOULD
+ temporarily stop receipt of more data and query the user for a
+ decision on further actions.
+
+10.4.8 407 Proxy Authentication Required
+
+ This code is similar to 401 (Unauthorized), but indicates that the
+ client must first authenticate itself with the proxy. The proxy MUST
+ return a Proxy-Authenticate header field (section 14.33) containing a
+ challenge applicable to the proxy for the requested resource. The
+ client MAY repeat the request with a suitable Proxy-Authorization
+ header field (section 14.34). HTTP access authentication is explained
+ in "HTTP Authentication: Basic and Digest Access Authentication"
+ [43].
+
+10.4.9 408 Request Timeout
+
+ The client did not produce a request within the time that the server
+ was prepared to wait. The client MAY repeat the request without
+ modifications at any later time.
+
+10.4.10 409 Conflict
+
+ The request could not be completed due to a conflict with the current
+ state of the resource. This code is only allowed in situations where
+ it is expected that the user might be able to resolve the conflict
+ and resubmit the request. The response body SHOULD include enough
+
+
+
+Fielding, et al. Standards Track [Page 67]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ information for the user to recognize the source of the conflict.
+ Ideally, the response entity would include enough information for the
+ user or user agent to fix the problem; however, that might not be
+ possible and is not required.
+
+ Conflicts are most likely to occur in response to a PUT request. For
+ example, if versioning were being used and the entity being PUT
+ included changes to a resource which conflict with those made by an
+ earlier (third-party) request, the server might use the 409 response
+ to indicate that it can't complete the request. In this case, the
+ response entity would likely contain a list of the differences
+ between the two versions in a format defined by the response
+ Content-Type.
+
+10.4.11 410 Gone
+
+ The requested resource is no longer available at the server and no
+ forwarding address is known. This condition is expected to be
+ considered permanent. Clients with link editing capabilities SHOULD
+ delete references to the Request-URI after user approval. If the
+ server does not know, or has no facility to determine, whether or not
+ the condition is permanent, the status code 404 (Not Found) SHOULD be
+ used instead. This response is cacheable unless indicated otherwise.
+
+ The 410 response is primarily intended to assist the task of web
+ maintenance by notifying the recipient that the resource is
+ intentionally unavailable and that the server owners desire that
+ remote links to that resource be removed. Such an event is common for
+ limited-time, promotional services and for resources belonging to
+ individuals no longer working at the server's site. It is not
+ necessary to mark all permanently unavailable resources as "gone" or
+ to keep the mark for any length of time -- that is left to the
+ discretion of the server owner.
+
+10.4.12 411 Length Required
+
+ The server refuses to accept the request without a defined Content-
+ Length. The client MAY repeat the request if it adds a valid
+ Content-Length header field containing the length of the message-body
+ in the request message.
+
+10.4.13 412 Precondition Failed
+
+ The precondition given in one or more of the request-header fields
+ evaluated to false when it was tested on the server. This response
+ code allows the client to place preconditions on the current resource
+ metainformation (header field data) and thus prevent the requested
+ method from being applied to a resource other than the one intended.
+
+
+
+Fielding, et al. Standards Track [Page 68]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.4.14 413 Request Entity Too Large
+
+ The server is refusing to process a request because the request
+ entity is larger than the server is willing or able to process. The
+ server MAY close the connection to prevent the client from continuing
+ the request.
+
+ If the condition is temporary, the server SHOULD include a Retry-
+ After header field to indicate that it is temporary and after what
+ time the client MAY try again.
+
+10.4.15 414 Request-URI Too Long
+
+ The server is refusing to service the request because the Request-URI
+ is longer than the server is willing to interpret. This rare
+ condition is only likely to occur when a client has improperly
+ converted a POST request to a GET request with long query
+ information, when the client has descended into a URI "black hole" of
+ redirection (e.g., a redirected URI prefix that points to a suffix of
+ itself), or when the server is under attack by a client attempting to
+ exploit security holes present in some servers using fixed-length
+ buffers for reading or manipulating the Request-URI.
+
+10.4.16 415 Unsupported Media Type
+
+ The server is refusing to service the request because the entity of
+ the request is in a format not supported by the requested resource
+ for the requested method.
+
+10.4.17 416 Requested Range Not Satisfiable
+
+ A server SHOULD return a response with this status code if a request
+ included a Range request-header field (section 14.35), and none of
+ the range-specifier values in this field overlap the current extent
+ of the selected resource, and the request did not include an If-Range
+ request-header field. (For byte-ranges, this means that the first-
+ byte-pos of all of the byte-range-spec values were greater than the
+ current length of the selected resource.)
+
+ When this status code is returned for a byte-range request, the
+ response SHOULD include a Content-Range entity-header field
+ specifying the current length of the selected resource (see section
+ 14.16). This response MUST NOT use the multipart/byteranges content-
+ type.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 69]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.4.18 417 Expectation Failed
+
+ The expectation given in an Expect request-header field (see section
+ 14.20) could not be met by this server, or, if the server is a proxy,
+ the server has unambiguous evidence that the request could not be met
+ by the next-hop server.
+
+10.5 Server Error 5xx
+
+ Response status codes beginning with the digit "5" indicate cases in
+ which the server is aware that it has erred or is incapable of
+ performing the request. Except when responding to a HEAD request, the
+ server SHOULD include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. User agents SHOULD display any included entity to the
+ user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+ The server encountered an unexpected condition which prevented it
+ from fulfilling the request.
+
+10.5.2 501 Not Implemented
+
+ The server does not support the functionality required to fulfill the
+ request. This is the appropriate response when the server does not
+ recognize the request method and is not capable of supporting it for
+ any resource.
+
+10.5.3 502 Bad Gateway
+
+ The server, while acting as a gateway or proxy, received an invalid
+ response from the upstream server it accessed in attempting to
+ fulfill the request.
+
+10.5.4 503 Service Unavailable
+
+ The server is currently unable to handle the request due to a
+ temporary overloading or maintenance of the server. The implication
+ is that this is a temporary condition which will be alleviated after
+ some delay. If known, the length of the delay MAY be indicated in a
+ Retry-After header. If no Retry-After is given, the client SHOULD
+ handle the response as it would for a 500 response.
+
+ Note: The existence of the 503 status code does not imply that a
+ server must use it when becoming overloaded. Some servers may wish
+ to simply refuse the connection.
+
+
+
+
+Fielding, et al. Standards Track [Page 70]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+10.5.5 504 Gateway Timeout
+
+ The server, while acting as a gateway or proxy, did not receive a
+ timely response from the upstream server specified by the URI (e.g.
+ HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
+ to access in attempting to complete the request.
+
+ Note: Note to implementors: some deployed proxies are known to
+ return 400 or 500 when DNS lookups time out.
+
+10.5.6 505 HTTP Version Not Supported
+
+ The server does not support, or refuses to support, the HTTP protocol
+ version that was used in the request message. The server is
+ indicating that it is unable or unwilling to complete the request
+ using the same major version as the client, as described in section
+ 3.1, other than with this error message. The response SHOULD contain
+ an entity describing why that version is not supported and what other
+ protocols are supported by that server.
+
+11 Access Authentication
+
+ HTTP provides several OPTIONAL challenge-response authentication
+ mechanisms which can be used by a server to challenge a client
+ request and by a client to provide authentication information. The
+ general framework for access authentication, and the specification of
+ "basic" and "digest" authentication, are specified in "HTTP
+ Authentication: Basic and Digest Access Authentication" [43]. This
+ specification adopts the definitions of "challenge" and "credentials"
+ from that specification.
+
+12 Content Negotiation
+
+ Most HTTP responses include an entity which contains information for
+ interpretation by a human user. Naturally, it is desirable to supply
+ the user with the "best available" entity corresponding to the
+ request. Unfortunately for servers and caches, not all users have the
+ same preferences for what is "best," and not all user agents are
+ equally capable of rendering all entity types. For that reason, HTTP
+ has provisions for several mechanisms for "content negotiation" --
+ the process of selecting the best representation for a given response
+ when there are multiple representations available.
+
+ Note: This is not called "format negotiation" because the
+ alternate representations may be of the same media type, but use
+ different capabilities of that type, be in different languages,
+ etc.
+
+
+
+
+Fielding, et al. Standards Track [Page 71]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Any response containing an entity-body MAY be subject to negotiation,
+ including error responses.
+
+ There are two kinds of content negotiation which are possible in
+ HTTP: server-driven and agent-driven negotiation. These two kinds of
+ negotiation are orthogonal and thus may be used separately or in
+ combination. One method of combination, referred to as transparent
+ negotiation, occurs when a cache uses the agent-driven negotiation
+ information provided by the origin server in order to provide
+ server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+ If the selection of the best representation for a response is made by
+ an algorithm located at the server, it is called server-driven
+ negotiation. Selection is based on the available representations of
+ the response (the dimensions over which it can vary; e.g. language,
+ content-coding, etc.) and the contents of particular header fields in
+ the request message or on other information pertaining to the request
+ (such as the network address of the client).
+
+ Server-driven negotiation is advantageous when the algorithm for
+ selecting from among the available representations is difficult to
+ describe to the user agent, or when the server desires to send its
+ "best guess" to the client along with the first response (hoping to
+ avoid the round-trip delay of a subsequent request if the "best
+ guess" is good enough for the user). In order to improve the server's
+ guess, the user agent MAY include request header fields (Accept,
+ Accept-Language, Accept-Encoding, etc.) which describe its
+ preferences for such a response.
+
+ Server-driven negotiation has disadvantages:
+
+ 1. It is impossible for the server to accurately determine what
+ might be "best" for any given user, since that would require
+ complete knowledge of both the capabilities of the user agent
+ and the intended use for the response (e.g., does the user want
+ to view it on screen or print it on paper?).
+
+ 2. Having the user agent describe its capabilities in every
+ request can be both very inefficient (given that only a small
+ percentage of responses have multiple representations) and a
+ potential violation of the user's privacy.
+
+ 3. It complicates the implementation of an origin server and the
+ algorithms for generating responses to a request.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 72]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 4. It may limit a public cache's ability to use the same response
+ for multiple user's requests.
+
+ HTTP/1.1 includes the following request-header fields for enabling
+ server-driven negotiation through description of user agent
+ capabilities and user preferences: Accept (section 14.1), Accept-
+ Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+ Language (section 14.4), and User-Agent (section 14.43). However, an
+ origin server is not limited to these dimensions and MAY vary the
+ response based on any aspect of the request, including information
+ outside the request-header fields or within extension header fields
+ not defined by this specification.
+
+ The Vary header field can be used to express the parameters the
+ server uses to select a representation that is subject to server-
+ driven negotiation. See section 13.6 for use of the Vary header field
+ by caches and section 14.44 for use of the Vary header field by
+ servers.
+
+12.2 Agent-driven Negotiation
+
+ With agent-driven negotiation, selection of the best representation
+ for a response is performed by the user agent after receiving an
+ initial response from the origin server. Selection is based on a list
+ of the available representations of the response included within the
+ header fields or entity-body of the initial response, with each
+ representation identified by its own URI. Selection from among the
+ representations may be performed automatically (if the user agent is
+ capable of doing so) or manually by the user selecting from a
+ generated (possibly hypertext) menu.
+
+ Agent-driven negotiation is advantageous when the response would vary
+ over commonly-used dimensions (such as type, language, or encoding),
+ when the origin server is unable to determine a user agent's
+ capabilities from examining the request, and generally when public
+ caches are used to distribute server load and reduce network usage.
+
+ Agent-driven negotiation suffers from the disadvantage of needing a
+ second request to obtain the best alternate representation. This
+ second request is only efficient when caching is used. In addition,
+ this specification does not define any mechanism for supporting
+ automatic selection, though it also does not prevent any such
+ mechanism from being developed as an extension and used within
+ HTTP/1.1.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 73]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+ status codes for enabling agent-driven negotiation when the server is
+ unwilling or unable to provide a varying response using server-driven
+ negotiation.
+
+12.3 Transparent Negotiation
+
+ Transparent negotiation is a combination of both server-driven and
+ agent-driven negotiation. When a cache is supplied with a form of the
+ list of available representations of the response (as in agent-driven
+ negotiation) and the dimensions of variance are completely understood
+ by the cache, then the cache becomes capable of performing server-
+ driven negotiation on behalf of the origin server for subsequent
+ requests on that resource.
+
+ Transparent negotiation has the advantage of distributing the
+ negotiation work that would otherwise be required of the origin
+ server and also removing the second request delay of agent-driven
+ negotiation when the cache is able to correctly guess the right
+ response.
+
+ This specification does not define any mechanism for transparent
+ negotiation, though it also does not prevent any such mechanism from
+ being developed as an extension that could be used within HTTP/1.1.
+
+13 Caching in HTTP
+
+ HTTP is typically used for distributed information systems, where
+ performance can be improved by the use of response caches. The
+ HTTP/1.1 protocol includes a number of elements intended to make
+ caching work as well as possible. Because these elements are
+ inextricable from other aspects of the protocol, and because they
+ interact with each other, it is useful to describe the basic caching
+ design of HTTP separately from the detailed descriptions of methods,
+ headers, response codes, etc.
+
+ Caching would be useless if it did not significantly improve
+ performance. The goal of caching in HTTP/1.1 is to eliminate the need
+ to send requests in many cases, and to eliminate the need to send
+ full responses in many other cases. The former reduces the number of
+ network round-trips required for many operations; we use an
+ "expiration" mechanism for this purpose (see section 13.2). The
+ latter reduces network bandwidth requirements; we use a "validation"
+ mechanism for this purpose (see section 13.3).
+
+ Requirements for performance, availability, and disconnected
+ operation require us to be able to relax the goal of semantic
+ transparency. The HTTP/1.1 protocol allows origin servers, caches,
+
+
+
+Fielding, et al. Standards Track [Page 74]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ and clients to explicitly reduce transparency when necessary.
+ However, because non-transparent operation may confuse non-expert
+ users, and might be incompatible with certain server applications
+ (such as those for ordering merchandise), the protocol requires that
+ transparency be relaxed
+
+ - only by an explicit protocol-level request when relaxed by
+ client or origin server
+
+ - only with an explicit warning to the end user when relaxed by
+ cache or client
+
+ Therefore, the HTTP/1.1 protocol provides these important elements:
+
+ 1. Protocol features that provide full semantic transparency when
+ this is required by all parties.
+
+ 2. Protocol features that allow an origin server or user agent to
+ explicitly request and control non-transparent operation.
+
+ 3. Protocol features that allow a cache to attach warnings to
+ responses that do not preserve the requested approximation of
+ semantic transparency.
+
+ A basic principle is that it must be possible for the clients to
+ detect any potential relaxation of semantic transparency.
+
+ Note: The server, cache, or client implementor might be faced with
+ design decisions not explicitly discussed in this specification.
+ If a decision might affect semantic transparency, the implementor
+ ought to err on the side of maintaining transparency unless a
+ careful and complete analysis shows significant benefits in
+ breaking transparency.
+
+13.1.1 Cache Correctness
+
+ A correct cache MUST respond to a request with the most up-to-date
+ response held by the cache that is appropriate to the request (see
+ sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+ conditions:
+
+ 1. It has been checked for equivalence with what the origin server
+ would have returned by revalidating the response with the
+ origin server (section 13.3);
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 75]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 2. It is "fresh enough" (see section 13.2). In the default case,
+ this means it meets the least restrictive freshness requirement
+ of the client, origin server, and cache (see section 14.9); if
+ the origin server so specifies, it is the freshness requirement
+ of the origin server alone.
+
+ If a stored response is not "fresh enough" by the most
+ restrictive freshness requirement of both the client and the
+ origin server, in carefully considered circumstances the cache
+ MAY still return the response with the appropriate Warning
+ header (see section 13.1.5 and 14.46), unless such a response
+ is prohibited (e.g., by a "no-store" cache-directive, or by a
+ "no-cache" cache-request-directive; see section 14.9).
+
+ 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+ or error (4xx or 5xx) response message.
+
+ If the cache can not communicate with the origin server, then a
+ correct cache SHOULD respond as above if the response can be
+ correctly served from the cache; if not it MUST return an error or
+ warning indicating that there was a communication failure.
+
+ If a cache receives a response (either an entire response, or a 304
+ (Not Modified) response) that it would normally forward to the
+ requesting client, and the received response is no longer fresh, the
+ cache SHOULD forward it to the requesting client without adding a new
+ Warning (but without removing any existing Warning headers). A cache
+ SHOULD NOT attempt to revalidate a response simply because that
+ response became stale in transit; this might lead to an infinite
+ loop. A user agent that receives a stale response without a Warning
+ MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+ Whenever a cache returns a response that is neither first-hand nor
+ "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+ MUST attach a warning to that effect, using a Warning general-header.
+ The Warning header and the currently defined warnings are described
+ in section 14.46. The warning allows clients to take appropriate
+ action.
+
+ Warnings MAY be used for other purposes, both cache-related and
+ otherwise. The use of a warning, rather than an error status code,
+ distinguish these responses from true failures.
+
+ Warnings are assigned three digit warn-codes. The first digit
+ indicates whether the Warning MUST or MUST NOT be deleted from a
+ stored cache entry after a successful revalidation:
+
+
+
+Fielding, et al. Standards Track [Page 76]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 1xx Warnings that describe the freshness or revalidation status of
+ the response, and so MUST be deleted after a successful
+ revalidation. 1XX warn-codes MAY be generated by a cache only when
+ validating a cached entry. It MUST NOT be generated by clients.
+
+ 2xx Warnings that describe some aspect of the entity body or entity
+ headers that is not rectified by a revalidation (for example, a
+ lossy compression of the entity bodies) and which MUST NOT be
+ deleted after a successful revalidation.
+
+ See section 14.46 for the definitions of the codes themselves.
+
+ HTTP/1.0 caches will cache all Warnings in responses, without
+ deleting the ones in the first category. Warnings in responses that
+ are passed to HTTP/1.0 caches carry an extra warning-date field,
+ which prevents a future HTTP/1.1 recipient from believing an
+ erroneously cached Warning.
+
+ Warnings also carry a warning text. The text MAY be in any
+ appropriate natural language (perhaps based on the client's Accept
+ headers), and include an OPTIONAL indication of what character set is
+ used.
+
+ Multiple warnings MAY be attached to a response (either by the origin
+ server or by a cache), including multiple warnings with the same code
+ number. For example, a server might provide the same warning with
+ texts in both English and Basque.
+
+ When multiple warnings are attached to a response, it might not be
+ practical or reasonable to display all of them to the user. This
+ version of HTTP does not specify strict priority rules for deciding
+ which warnings to display and in what order, but does suggest some
+ heuristics.
+
+13.1.3 Cache-control Mechanisms
+
+ The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+ times and validators) are implicit directives to caches. In some
+ cases, a server or client might need to provide explicit directives
+ to the HTTP caches. We use the Cache-Control header for this purpose.
+
+ The Cache-Control header allows a client or server to transmit a
+ variety of directives in either requests or responses. These
+ directives typically override the default caching algorithms. As a
+ general rule, if there is any apparent conflict between header
+ values, the most restrictive interpretation is applied (that is, the
+ one that is most likely to preserve semantic transparency). However,
+
+
+
+
+Fielding, et al. Standards Track [Page 77]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ in some cases, cache-control directives are explicitly specified as
+ weakening the approximation of semantic transparency (for example,
+ "max-stale" or "public").
+
+ The cache-control directives are described in detail in section 14.9.
+
+13.1.4 Explicit User Agent Warnings
+
+ Many user agents make it possible for users to override the basic
+ caching mechanisms. For example, the user agent might allow the user
+ to specify that cached entities (even explicitly stale ones) are
+ never validated. Or the user agent might habitually add "Cache-
+ Control: max-stale=3600" to every request. The user agent SHOULD NOT
+ default to either non-transparent behavior, or behavior that results
+ in abnormally ineffective caching, but MAY be explicitly configured
+ to do so by an explicit action of the user.
+
+ If the user has overridden the basic caching mechanisms, the user
+ agent SHOULD explicitly indicate to the user whenever this results in
+ the display of information that might not meet the server's
+ transparency requirements (in particular, if the displayed entity is
+ known to be stale). Since the protocol normally allows the user agent
+ to determine if responses are stale or not, this indication need only
+ be displayed when this actually happens. The indication need not be a
+ dialog box; it could be an icon (for example, a picture of a rotting
+ fish) or some other indicator.
+
+ If the user has overridden the caching mechanisms in a way that would
+ abnormally reduce the effectiveness of caches, the user agent SHOULD
+ continually indicate this state to the user (for example, by a
+ display of a picture of currency in flames) so that the user does not
+ inadvertently consume excess resources or suffer from excessive
+ latency.
+
+13.1.5 Exceptions to the Rules and Warnings
+
+ In some cases, the operator of a cache MAY choose to configure it to
+ return stale responses even when not requested by clients. This
+ decision ought not be made lightly, but may be necessary for reasons
+ of availability or performance, especially when the cache is poorly
+ connected to the origin server. Whenever a cache returns a stale
+ response, it MUST mark it as such (using a Warning header) enabling
+ the client software to alert the user that there might be a potential
+ problem.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 78]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ It also allows the user agent to take steps to obtain a first-hand or
+ fresh response. For this reason, a cache SHOULD NOT return a stale
+ response if the client explicitly requests a first-hand or fresh one,
+ unless it is impossible to comply for technical or policy reasons.
+
+13.1.6 Client-controlled Behavior
+
+ While the origin server (and to a lesser extent, intermediate caches,
+ by their contribution to the age of a response) are the primary
+ source of expiration information, in some cases the client might need
+ to control a cache's decision about whether to return a cached
+ response without validating it. Clients do this using several
+ directives of the Cache-Control header.
+
+ A client's request MAY specify the maximum age it is willing to
+ accept of an unvalidated response; specifying a value of zero forces
+ the cache(s) to revalidate all responses. A client MAY also specify
+ the minimum time remaining before a response expires. Both of these
+ options increase constraints on the behavior of caches, and so cannot
+ further relax the cache's approximation of semantic transparency.
+
+ A client MAY also specify that it will accept stale responses, up to
+ some maximum amount of staleness. This loosens the constraints on the
+ caches, and so might violate the origin server's specified
+ constraints on semantic transparency, but might be necessary to
+ support disconnected operation, or high availability in the face of
+ poor connectivity.
+
+13.2 Expiration Model
+
+13.2.1 Server-Specified Expiration
+
+ HTTP caching works best when caches can entirely avoid making
+ requests to the origin server. The primary mechanism for avoiding
+ requests is for an origin server to provide an explicit expiration
+ time in the future, indicating that a response MAY be used to satisfy
+ subsequent requests. In other words, a cache can return a fresh
+ response without first contacting the server.
+
+ Our expectation is that servers will assign future explicit
+ expiration times to responses in the belief that the entity is not
+ likely to change, in a semantically significant way, before the
+ expiration time is reached. This normally preserves semantic
+ transparency, as long as the server's expiration times are carefully
+ chosen.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 79]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The expiration mechanism applies only to responses taken from a cache
+ and not to first-hand responses forwarded immediately to the
+ requesting client.
+
+ If an origin server wishes to force a semantically transparent cache
+ to validate every request, it MAY assign an explicit expiration time
+ in the past. This means that the response is always stale, and so the
+ cache SHOULD validate it before using it for subsequent requests. See
+ section 14.9.4 for a more restrictive way to force revalidation.
+
+ If an origin server wishes to force any HTTP/1.1 cache, no matter how
+ it is configured, to validate every request, it SHOULD use the "must-
+ revalidate" cache-control directive (see section 14.9).
+
+ Servers specify explicit expiration times using either the Expires
+ header, or the max-age directive of the Cache-Control header.
+
+ An expiration time cannot be used to force a user agent to refresh
+ its display or reload a resource; its semantics apply only to caching
+ mechanisms, and such mechanisms need only check a resource's
+ expiration status when a new request for that resource is initiated.
+ See section 13.13 for an explanation of the difference between caches
+ and history mechanisms.
+
+13.2.2 Heuristic Expiration
+
+ Since origin servers do not always provide explicit expiration times,
+ HTTP caches typically assign heuristic expiration times, employing
+ algorithms that use other header values (such as the Last-Modified
+ time) to estimate a plausible expiration time. The HTTP/1.1
+ specification does not provide specific algorithms, but does impose
+ worst-case constraints on their results. Since heuristic expiration
+ times might compromise semantic transparency, they ought to used
+ cautiously, and we encourage origin servers to provide explicit
+ expiration times as much as possible.
+
+13.2.3 Age Calculations
+
+ In order to know if a cached entry is fresh, a cache needs to know if
+ its age exceeds its freshness lifetime. We discuss how to calculate
+ the latter in section 13.2.4; this section describes how to calculate
+ the age of a response or cache entry.
+
+ In this discussion, we use the term "now" to mean "the current value
+ of the clock at the host performing the calculation." Hosts that use
+ HTTP, but especially hosts running origin servers and caches, SHOULD
+ use NTP [28] or some similar protocol to synchronize their clocks to
+ a globally accurate time standard.
+
+
+
+Fielding, et al. Standards Track [Page 80]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ HTTP/1.1 requires origin servers to send a Date header, if possible,
+ with every response, giving the time at which the response was
+ generated (see section 14.18). We use the term "date_value" to denote
+ the value of the Date header, in a form appropriate for arithmetic
+ operations.
+
+ HTTP/1.1 uses the Age response-header to convey the estimated age of
+ the response message when obtained from a cache. The Age field value
+ is the cache's estimate of the amount of time since the response was
+ generated or revalidated by the origin server.
+
+ In essence, the Age value is the sum of the time that the response
+ has been resident in each of the caches along the path from the
+ origin server, plus the amount of time it has been in transit along
+ network paths.
+
+ We use the term "age_value" to denote the value of the Age header, in
+ a form appropriate for arithmetic operations.
+
+ A response's age can be calculated in two entirely independent ways:
+
+ 1. now minus date_value, if the local clock is reasonably well
+ synchronized to the origin server's clock. If the result is
+ negative, the result is replaced by zero.
+
+ 2. age_value, if all of the caches along the response path
+ implement HTTP/1.1.
+
+ Given that we have two independent ways to compute the age of a
+ response when it is received, we can combine these as
+
+ corrected_received_age = max(now - date_value, age_value)
+
+ and as long as we have either nearly synchronized clocks or all-
+ HTTP/1.1 paths, one gets a reliable (conservative) result.
+
+ Because of network-imposed delays, some significant interval might
+ pass between the time that a server generates a response and the time
+ it is received at the next outbound cache or client. If uncorrected,
+ this delay could result in improperly low ages.
+
+ Because the request that resulted in the returned Age value must have
+ been initiated prior to that Age value's generation, we can correct
+ for delays imposed by the network by recording the time at which the
+ request was initiated. Then, when an Age value is received, it MUST
+ be interpreted relative to the time the request was initiated, not
+
+
+
+
+
+Fielding, et al. Standards Track [Page 81]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ the time that the response was received. This algorithm results in
+ conservative behavior no matter how much delay is experienced. So, we
+ compute:
+
+ corrected_initial_age = corrected_received_age
+ + (now - request_time)
+
+ where "request_time" is the time (according to the local clock) when
+ the request that elicited this response was sent.
+
+ Summary of age calculation algorithm, when a cache receives a
+ response:
+
+ /*
+ * age_value
+ * is the value of Age: header received by the cache with
+ * this response.
+ * date_value
+ * is the value of the origin server's Date: header
+ * request_time
+ * is the (local) time when the cache made the request
+ * that resulted in this cached response
+ * response_time
+ * is the (local) time when the cache received the
+ * response
+ * now
+ * is the current (local) time
+ */
+
+ apparent_age = max(0, response_time - date_value);
+ corrected_received_age = max(apparent_age, age_value);
+ response_delay = response_time - request_time;
+ corrected_initial_age = corrected_received_age + response_delay;
+ resident_time = now - response_time;
+ current_age = corrected_initial_age + resident_time;
+
+ The current_age of a cache entry is calculated by adding the amount
+ of time (in seconds) since the cache entry was last validated by the
+ origin server to the corrected_initial_age. When a response is
+ generated from a cache entry, the cache MUST include a single Age
+ header field in the response with a value equal to the cache entry's
+ current_age.
+
+ The presence of an Age header field in a response implies that a
+ response is not first-hand. However, the converse is not true, since
+ the lack of an Age header field in a response does not imply that the
+
+
+
+
+
+Fielding, et al. Standards Track [Page 82]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ response is first-hand unless all caches along the request path are
+ compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
+ the Age header field).
+
+13.2.4 Expiration Calculations
+
+ In order to decide whether a response is fresh or stale, we need to
+ compare its freshness lifetime to its age. The age is calculated as
+ described in section 13.2.3; this section describes how to calculate
+ the freshness lifetime, and to determine if a response has expired.
+ In the discussion below, the values can be represented in any form
+ appropriate for arithmetic operations.
+
+ We use the term "expires_value" to denote the value of the Expires
+ header. We use the term "max_age_value" to denote an appropriate
+ value of the number of seconds carried by the "max-age" directive of
+ the Cache-Control header in a response (see section 14.9.3).
+
+ The max-age directive takes priority over Expires, so if max-age is
+ present in a response, the calculation is simply:
+
+ freshness_lifetime = max_age_value
+
+ Otherwise, if Expires is present in the response, the calculation is:
+
+ freshness_lifetime = expires_value - date_value
+
+ Note that neither of these calculations is vulnerable to clock skew,
+ since all of the information comes from the origin server.
+
+ If none of Expires, Cache-Control: max-age, or Cache-Control: s-
+ maxage (see section 14.9.3) appears in the response, and the response
+ does not include other restrictions on caching, the cache MAY compute
+ a freshness lifetime using a heuristic. The cache MUST attach Warning
+ 113 to any response whose age is more than 24 hours if such warning
+ has not already been added.
+
+ Also, if the response does have a Last-Modified time, the heuristic
+ expiration value SHOULD be no more than some fraction of the interval
+ since that time. A typical setting of this fraction might be 10%.
+
+ The calculation to determine if a response has expired is quite
+ simple:
+
+ response_is_fresh = (freshness_lifetime > current_age)
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 83]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.2.5 Disambiguating Expiration Values
+
+ Because expiration values are assigned optimistically, it is possible
+ for two caches to contain fresh values for the same resource that are
+ different.
+
+ If a client performing a retrieval receives a non-first-hand response
+ for a request that was already fresh in its own cache, and the Date
+ header in its existing cache entry is newer than the Date on the new
+ response, then the client MAY ignore the response. If so, it MAY
+ retry the request with a "Cache-Control: max-age=0" directive (see
+ section 14.9), to force a check with the origin server.
+
+ If a cache has two fresh responses for the same representation with
+ different validators, it MUST use the one with the more recent Date
+ header. This situation might arise because the cache is pooling
+ responses from other caches, or because a client has asked for a
+ reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+ Because a client might be receiving responses via multiple paths, so
+ that some responses flow through one set of caches and other
+ responses flow through a different set of caches, a client might
+ receive responses in an order different from that in which the origin
+ server sent them. We would like the client to use the most recently
+ generated response, even if older responses are still apparently
+ fresh.
+
+ Neither the entity tag nor the expiration value can impose an
+ ordering on responses, since it is possible that a later response
+ intentionally carries an earlier expiration time. The Date values are
+ ordered to a granularity of one second.
+
+ When a client tries to revalidate a cache entry, and the response it
+ receives contains a Date header that appears to be older than the one
+ for the existing entry, then the client SHOULD repeat the request
+ unconditionally, and include
+
+ Cache-Control: max-age=0
+
+ to force any intermediate caches to validate their copies directly
+ with the origin server, or
+
+ Cache-Control: no-cache
+
+ to force any intermediate caches to obtain a new copy from the origin
+ server.
+
+
+
+Fielding, et al. Standards Track [Page 84]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If the Date values are equal, then the client MAY use either response
+ (or MAY, if it is being extremely prudent, request a new response).
+ Servers MUST NOT depend on clients being able to choose
+ deterministically between responses generated during the same second,
+ if their expiration times overlap.
+
+13.3 Validation Model
+
+ When a cache has a stale entry that it would like to use as a
+ response to a client's request, it first has to check with the origin
+ server (or possibly an intermediate cache with a fresh response) to
+ see if its cached entry is still usable. We call this "validating"
+ the cache entry. Since we do not want to have to pay the overhead of
+ retransmitting the full response if the cached entry is good, and we
+ do not want to pay the overhead of an extra round trip if the cached
+ entry is invalid, the HTTP/1.1 protocol supports the use of
+ conditional methods.
+
+ The key protocol features for supporting conditional methods are
+ those concerned with "cache validators." When an origin server
+ generates a full response, it attaches some sort of validator to it,
+ which is kept with the cache entry. When a client (user agent or
+ proxy cache) makes a conditional request for a resource for which it
+ has a cache entry, it includes the associated validator in the
+ request.
+
+ The server then checks that validator against the current validator
+ for the entity, and, if they match (see section 13.3.3), it responds
+ with a special status code (usually, 304 (Not Modified)) and no
+ entity-body. Otherwise, it returns a full response (including
+ entity-body). Thus, we avoid transmitting the full response if the
+ validator matches, and we avoid an extra round trip if it does not
+ match.
+
+ In HTTP/1.1, a conditional request looks exactly the same as a normal
+ request for the same resource, except that it carries a special
+ header (which includes the validator) that implicitly turns the
+ method (usually, GET) into a conditional.
+
+ The protocol includes both positive and negative senses of cache-
+ validating conditions. That is, it is possible to request either that
+ a method be performed if and only if a validator matches or if and
+ only if no validators match.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 85]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Note: a response that lacks a validator may still be cached, and
+ served from cache until it expires, unless this is explicitly
+ prohibited by a cache-control directive. However, a cache cannot
+ do a conditional retrieval if it does not have a validator for the
+ entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-Modified Dates
+
+ The Last-Modified entity-header field value is often used as a cache
+ validator. In simple terms, a cache entry is considered to be valid
+ if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+ The ETag response-header field value, an entity tag, provides for an
+ "opaque" cache validator. This might allow more reliable validation
+ in situations where it is inconvenient to store modification dates,
+ where the one-second resolution of HTTP date values is not
+ sufficient, or where the origin server wishes to avoid certain
+ paradoxes that might arise from the use of modification dates.
+
+ Entity Tags are described in section 3.11. The headers used with
+ entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
+
+13.3.3 Weak and Strong Validators
+
+ Since both origin servers and caches will compare two validators to
+ decide if they represent the same or different entities, one normally
+ would expect that if the entity (the entity-body or any entity-
+ headers) changes in any way, then the associated validator would
+ change as well. If this is true, then we call this validator a
+ "strong validator."
+
+ However, there might be cases when a server prefers to change the
+ validator only on semantically significant changes, and not when
+ insignificant aspects of the entity change. A validator that does not
+ always change when the resource changes is a "weak validator."
+
+ Entity tags are normally "strong validators," but the protocol
+ provides a mechanism to tag an entity tag as "weak." One can think of
+ a strong validator as one that changes whenever the bits of an entity
+ changes, while a weak value changes whenever the meaning of an entity
+ changes. Alternatively, one can think of a strong validator as part
+ of an identifier for a specific entity, while a weak validator is
+ part of an identifier for a set of semantically equivalent entities.
+
+ Note: One example of a strong validator is an integer that is
+ incremented in stable storage every time an entity is changed.
+
+
+
+Fielding, et al. Standards Track [Page 86]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ An entity's modification time, if represented with one-second
+ resolution, could be a weak validator, since it is possible that
+ the resource might be modified twice during a single second.
+
+ Support for weak validators is optional. However, weak validators
+ allow for more efficient caching of equivalent objects; for
+ example, a hit counter on a site is probably good enough if it is
+ updated every few days or weeks, and any value during that period
+ is likely "good enough" to be equivalent.
+
+ A "use" of a validator is either when a client generates a request
+ and includes the validator in a validating header field, or when a
+ server compares two validators.
+
+ Strong validators are usable in any context. Weak validators are only
+ usable in contexts that do not depend on exact equality of an entity.
+ For example, either kind is usable for a conditional GET of a full
+ entity. However, only a strong validator is usable for a sub-range
+ retrieval, since otherwise the client might end up with an internally
+ inconsistent entity.
+
+ Clients MAY issue simple (non-subrange) GET requests with either weak
+ validators or strong validators. Clients MUST NOT use weak validators
+ in other forms of request.
+
+ The only function that the HTTP/1.1 protocol defines on validators is
+ comparison. There are two validator comparison functions, depending
+ on whether the comparison context allows the use of weak validators
+ or not:
+
+ - The strong comparison function: in order to be considered equal,
+ both validators MUST be identical in every way, and both MUST
+ NOT be weak.
+
+ - The weak comparison function: in order to be considered equal,
+ both validators MUST be identical in every way, but either or
+ both of them MAY be tagged as "weak" without affecting the
+ result.
+
+ An entity tag is strong unless it is explicitly tagged as weak.
+ Section 3.11 gives the syntax for entity tags.
+
+ A Last-Modified time, when used as a validator in a request, is
+ implicitly weak unless it is possible to deduce that it is strong,
+ using the following rules:
+
+ - The validator is being compared by an origin server to the
+ actual current validator for the entity and,
+
+
+
+Fielding, et al. Standards Track [Page 87]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - That origin server reliably knows that the associated entity did
+ not change twice during the second covered by the presented
+ validator.
+
+ or
+
+ - The validator is about to be used by a client in an If-
+ Modified-Since or If-Unmodified-Since header, because the client
+ has a cache entry for the associated entity, and
+
+ - That cache entry includes a Date value, which gives the time
+ when the origin server sent the original response, and
+
+ - The presented Last-Modified time is at least 60 seconds before
+ the Date value.
+
+ or
+
+ - The validator is being compared by an intermediate cache to the
+ validator stored in its cache entry for the entity, and
+
+ - That cache entry includes a Date value, which gives the time
+ when the origin server sent the original response, and
+
+ - The presented Last-Modified time is at least 60 seconds before
+ the Date value.
+
+ This method relies on the fact that if two different responses were
+ sent by the origin server during the same second, but both had the
+ same Last-Modified time, then at least one of those responses would
+ have a Date value equal to its Last-Modified time. The arbitrary 60-
+ second limit guards against the possibility that the Date and Last-
+ Modified values are generated from different clocks, or at somewhat
+ different times during the preparation of the response. An
+ implementation MAY use a value larger than 60 seconds, if it is
+ believed that 60 seconds is too short.
+
+ If a client wishes to perform a sub-range retrieval on a value for
+ which it has only a Last-Modified time and no opaque validator, it
+ MAY do this only if the Last-Modified time is strong in the sense
+ described here.
+
+ A cache or origin server receiving a conditional request, other than
+ a full-body GET request, MUST use the strong comparison function to
+ evaluate the condition.
+
+ These rules allow HTTP/1.1 caches and clients to safely perform sub-
+ range retrievals on values that have been obtained from HTTP/1.0
+
+
+
+Fielding, et al. Standards Track [Page 88]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ servers.
+
+13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
+
+ We adopt a set of rules and recommendations for origin servers,
+ clients, and caches regarding when various validator types ought to
+ be used, and for what purposes.
+
+ HTTP/1.1 origin servers:
+
+ - SHOULD send an entity tag validator unless it is not feasible to
+ generate one.
+
+ - MAY send a weak entity tag instead of a strong entity tag, if
+ performance considerations support the use of weak entity tags,
+ or if it is unfeasible to send a strong entity tag.
+
+ - SHOULD send a Last-Modified value if it is feasible to send one,
+ unless the risk of a breakdown in semantic transparency that
+ could result from using this date in an If-Modified-Since header
+ would lead to serious problems.
+
+ In other words, the preferred behavior for an HTTP/1.1 origin server
+ is to send both a strong entity tag and a Last-Modified value.
+
+ In order to be legal, a strong entity tag MUST change whenever the
+ associated entity value changes in any way. A weak entity tag SHOULD
+ change whenever the associated entity changes in a semantically
+ significant way.
+
+ Note: in order to provide semantically transparent caching, an
+ origin server must avoid reusing a specific strong entity tag
+ value for two different entities, or reusing a specific weak
+ entity tag value for two semantically different entities. Cache
+ entries might persist for arbitrarily long periods, regardless of
+ expiration times, so it might be inappropriate to expect that a
+ cache will never again attempt to validate an entry using a
+ validator that it obtained at some point in the past.
+
+ HTTP/1.1 clients:
+
+ - If an entity tag has been provided by the origin server, MUST
+ use that entity tag in any cache-conditional request (using If-
+ Match or If-None-Match).
+
+ - If only a Last-Modified value has been provided by the origin
+ server, SHOULD use that value in non-subrange cache-conditional
+ requests (using If-Modified-Since).
+
+
+
+Fielding, et al. Standards Track [Page 89]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - If only a Last-Modified value has been provided by an HTTP/1.0
+ origin server, MAY use that value in subrange cache-conditional
+ requests (using If-Unmodified-Since:). The user agent SHOULD
+ provide a way to disable this, in case of difficulty.
+
+ - If both an entity tag and a Last-Modified value have been
+ provided by the origin server, SHOULD use both validators in
+ cache-conditional requests. This allows both HTTP/1.0 and
+ HTTP/1.1 caches to respond appropriately.
+
+ An HTTP/1.1 origin server, upon receiving a conditional request that
+ includes both a Last-Modified date (e.g., in an If-Modified-Since or
+ If-Unmodified-Since header field) and one or more entity tags (e.g.,
+ in an If-Match, If-None-Match, or If-Range header field) as cache
+ validators, MUST NOT return a response status of 304 (Not Modified)
+ unless doing so is consistent with all of the conditional header
+ fields in the request.
+
+ An HTTP/1.1 caching proxy, upon receiving a conditional request that
+ includes both a Last-Modified date and one or more entity tags as
+ cache validators, MUST NOT return a locally cached response to the
+ client unless that cached response is consistent with all of the
+ conditional header fields in the request.
+
+ Note: The general principle behind these rules is that HTTP/1.1
+ servers and clients should transmit as much non-redundant
+ information as is available in their responses and requests.
+ HTTP/1.1 systems receiving this information will make the most
+ conservative assumptions about the validators they receive.
+
+ HTTP/1.0 clients and caches will ignore entity tags. Generally,
+ last-modified values received or used by these systems will
+ support transparent and efficient caching, and so HTTP/1.1 origin
+ servers should provide Last-Modified values. In those rare cases
+ where the use of a Last-Modified value as a validator by an
+ HTTP/1.0 system could result in a serious problem, then HTTP/1.1
+ origin servers should not provide one.
+
+13.3.5 Non-validating Conditionals
+
+ The principle behind entity tags is that only the service author
+ knows the semantics of a resource well enough to select an
+ appropriate cache validation mechanism, and the specification of any
+ validator comparison function more complex than byte-equality would
+ open up a can of worms. Thus, comparisons of any other headers
+ (except Last-Modified, for compatibility with HTTP/1.0) are never
+ used for purposes of validating a cache entry.
+
+
+
+
+Fielding, et al. Standards Track [Page 90]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.4 Response Cacheability
+
+ Unless specifically constrained by a cache-control (section 14.9)
+ directive, a caching system MAY always store a successful response
+ (see section 13.8) as a cache entry, MAY return it without validation
+ if it is fresh, and MAY return it after successful validation. If
+ there is neither a cache validator nor an explicit expiration time
+ associated with a response, we do not expect it to be cached, but
+ certain caches MAY violate this expectation (for example, when little
+ or no network connectivity is available). A client can usually detect
+ that such a response was taken from a cache by comparing the Date
+ header to the current time.
+
+ Note: some HTTP/1.0 caches are known to violate this expectation
+ without providing any Warning.
+
+ However, in some cases it might be inappropriate for a cache to
+ retain an entity, or to return it in response to a subsequent
+ request. This might be because absolute semantic transparency is
+ deemed necessary by the service author, or because of security or
+ privacy considerations. Certain cache-control directives are
+ therefore provided so that the server can indicate that certain
+ resource entities, or portions thereof, are not to be cached
+ regardless of other considerations.
+
+ Note that section 14.8 normally prevents a shared cache from saving
+ and returning a response to a previous request if that request
+ included an Authorization header.
+
+ A response received with a status code of 200, 203, 206, 300, 301 or
+ 410 MAY be stored by a cache and used in reply to a subsequent
+ request, subject to the expiration mechanism, unless a cache-control
+ directive prohibits caching. However, a cache that does not support
+ the Range and Content-Range headers MUST NOT cache 206 (Partial
+ Content) responses.
+
+ A response received with any other status code (e.g. status codes 302
+ and 307) MUST NOT be returned in a reply to a subsequent request
+ unless there are cache-control directives or another header(s) that
+ explicitly allow it. For example, these include the following: an
+ Expires header (section 14.21); a "max-age", "s-maxage", "must-
+ revalidate", "proxy-revalidate", "public" or "private" cache-control
+ directive (section 14.9).
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 91]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.5 Constructing Responses From Caches
+
+ The purpose of an HTTP cache is to store information received in
+ response to requests for use in responding to future requests. In
+ many cases, a cache simply returns the appropriate parts of a
+ response to the requester. However, if the cache holds a cache entry
+ based on a previous response, it might have to combine parts of a new
+ response with what is held in the cache entry.
+
+13.5.1 End-to-end and Hop-by-hop Headers
+
+ For the purpose of defining the behavior of caches and non-caching
+ proxies, we divide HTTP headers into two categories:
+
+ - End-to-end headers, which are transmitted to the ultimate
+ recipient of a request or response. End-to-end headers in
+ responses MUST be stored as part of a cache entry and MUST be
+ transmitted in any response formed from a cache entry.
+
+ - Hop-by-hop headers, which are meaningful only for a single
+ transport-level connection, and are not stored by caches or
+ forwarded by proxies.
+
+ The following HTTP/1.1 headers are hop-by-hop headers:
+
+ - Connection
+ - Keep-Alive
+ - Proxy-Authenticate
+ - Proxy-Authorization
+ - TE
+ - Trailers
+ - Transfer-Encoding
+ - Upgrade
+
+ All other headers defined by HTTP/1.1 are end-to-end headers.
+
+ Other hop-by-hop headers MUST be listed in a Connection header,
+ (section 14.10) to be introduced into HTTP/1.1 (or later).
+
+13.5.2 Non-modifiable Headers
+
+ Some features of the HTTP/1.1 protocol, such as Digest
+ Authentication, depend on the value of certain end-to-end headers. A
+ transparent proxy SHOULD NOT modify an end-to-end header unless the
+ definition of that header requires or specifically allows that.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 92]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ A transparent proxy MUST NOT modify any of the following fields in a
+ request or response, and it MUST NOT add any of these fields if not
+ already present:
+
+ - Content-Location
+
+ - Content-MD5
+
+ - ETag
+
+ - Last-Modified
+
+ A transparent proxy MUST NOT modify any of the following fields in a
+ response:
+
+ - Expires
+
+ but it MAY add any of these fields if not already present. If an
+ Expires header is added, it MUST be given a field-value identical to
+ that of the Date header in that response.
+
+ A proxy MUST NOT modify or add any of the following fields in a
+ message that contains the no-transform cache-control directive, or in
+ any request:
+
+ - Content-Encoding
+
+ - Content-Range
+
+ - Content-Type
+
+ A non-transparent proxy MAY modify or add these fields to a message
+ that does not include no-transform, but if it does so, it MUST add a
+ Warning 214 (Transformation applied) if one does not already appear
+ in the message (see section 14.46).
+
+ Warning: unnecessary modification of end-to-end headers might
+ cause authentication failures if stronger authentication
+ mechanisms are introduced in later versions of HTTP. Such
+ authentication mechanisms MAY rely on the values of header fields
+ not listed here.
+
+ The Content-Length field of a request or response is added or deleted
+ according to the rules in section 4.4. A transparent proxy MUST
+ preserve the entity-length (section 7.2.2) of the entity-body,
+ although it MAY change the transfer-length (section 4.4).
+
+
+
+
+
+Fielding, et al. Standards Track [Page 93]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.5.3 Combining Headers
+
+ When a cache makes a validating request to a server, and the server
+ provides a 304 (Not Modified) response or a 206 (Partial Content)
+ response, the cache then constructs a response to send to the
+ requesting client.
+
+ If the status code is 304 (Not Modified), the cache uses the entity-
+ body stored in the cache entry as the entity-body of this outgoing
+ response. If the status code is 206 (Partial Content) and the ETag or
+ Last-Modified headers match exactly, the cache MAY combine the
+ contents stored in the cache entry with the new contents received in
+ the response and use the result as the entity-body of this outgoing
+ response, (see 13.5.4).
+
+ The end-to-end headers stored in the cache entry are used for the
+ constructed response, except that
+
+ - any stored Warning headers with warn-code 1xx (see section
+ 14.46) MUST be deleted from the cache entry and the forwarded
+ response.
+
+ - any stored Warning headers with warn-code 2xx MUST be retained
+ in the cache entry and the forwarded response.
+
+ - any end-to-end headers provided in the 304 or 206 response MUST
+ replace the corresponding headers from the cache entry.
+
+ Unless the cache decides to remove the cache entry, it MUST also
+ replace the end-to-end headers stored with the cache entry with
+ corresponding headers received in the incoming response, except for
+ Warning headers as described immediately above. If a header field-
+ name in the incoming response matches more than one header in the
+ cache entry, all such old headers MUST be replaced.
+
+ In other words, the set of end-to-end headers received in the
+ incoming response overrides all corresponding end-to-end headers
+ stored with the cache entry (except for stored Warning headers with
+ warn-code 1xx, which are deleted even if not overridden).
+
+ Note: this rule allows an origin server to use a 304 (Not
+ Modified) or a 206 (Partial Content) response to update any header
+ associated with a previous response for the same entity or sub-
+ ranges thereof, although it might not always be meaningful or
+ correct to do so. This rule does not allow an origin server to use
+ a 304 (Not Modified) or a 206 (Partial Content) response to
+ entirely delete a header that it had provided with a previous
+ response.
+
+
+
+Fielding, et al. Standards Track [Page 94]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.5.4 Combining Byte Ranges
+
+ A response might transfer only a subrange of the bytes of an entity-
+ body, either because the request included one or more Range
+ specifications, or because a connection was broken prematurely. After
+ several such transfers, a cache might have received several ranges of
+ the same entity-body.
+
+ If a cache has a stored non-empty set of subranges for an entity, and
+ an incoming response transfers another subrange, the cache MAY
+ combine the new subrange with the existing set if both the following
+ conditions are met:
+
+ - Both the incoming response and the cache entry have a cache
+ validator.
+
+ - The two cache validators match using the strong comparison
+ function (see section 13.3.3).
+
+ If either requirement is not met, the cache MUST use only the most
+ recent partial response (based on the Date values transmitted with
+ every response, and using the incoming response if these values are
+ equal or missing), and MUST discard the other partial information.
+
+13.6 Caching Negotiated Responses
+
+ Use of server-driven content negotiation (section 12.1), as indicated
+ by the presence of a Vary header field in a response, alters the
+ conditions and procedure by which a cache can use the response for
+ subsequent requests. See section 14.44 for use of the Vary header
+ field by servers.
+
+ A server SHOULD use the Vary header field to inform a cache of what
+ request-header fields were used to select among multiple
+ representations of a cacheable response subject to server-driven
+ negotiation. The set of header fields named by the Vary field value
+ is known as the "selecting" request-headers.
+
+ When the cache receives a subsequent request whose Request-URI
+ specifies one or more cache entries including a Vary header field,
+ the cache MUST NOT use such a cache entry to construct a response to
+ the new request unless all of the selecting request-headers present
+ in the new request match the corresponding stored request-headers in
+ the original request.
+
+ The selecting request-headers from two requests are defined to match
+ if and only if the selecting request-headers in the first request can
+ be transformed to the selecting request-headers in the second request
+
+
+
+Fielding, et al. Standards Track [Page 95]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ by adding or removing linear white space (LWS) at places where this
+ is allowed by the corresponding BNF, and/or combining multiple
+ message-header fields with the same field name following the rules
+ about message headers in section 4.2.
+
+ A Vary header field-value of "*" always fails to match and subsequent
+ requests on that resource can only be properly interpreted by the
+ origin server.
+
+ If the selecting request header fields for the cached entry do not
+ match the selecting request header fields of the new request, then
+ the cache MUST NOT use a cached entry to satisfy the request unless
+ it first relays the new request to the origin server in a conditional
+ request and the server responds with 304 (Not Modified), including an
+ entity tag or Content-Location that indicates the entity to be used.
+
+ If an entity tag was assigned to a cached representation, the
+ forwarded request SHOULD be conditional and include the entity tags
+ in an If-None-Match header field from all its cache entries for the
+ resource. This conveys to the server the set of entities currently
+ held by the cache, so that if any one of these entities matches the
+ requested entity, the server can use the ETag header field in its 304
+ (Not Modified) response to tell the cache which entry is appropriate.
+ If the entity-tag of the new response matches that of an existing
+ entry, the new response SHOULD be used to update the header fields of
+ the existing entry, and the result MUST be returned to the client.
+
+ If any of the existing cache entries contains only partial content
+ for the associated entity, its entity-tag SHOULD NOT be included in
+ the If-None-Match header field unless the request is for a range that
+ would be fully satisfied by that entry.
+
+ If a cache receives a successful response whose Content-Location
+ field matches that of an existing cache entry for the same Request-
+ ]URI, whose entity-tag differs from that of the existing entry, and
+ whose Date is more recent than that of the existing entry, the
+ existing entry SHOULD NOT be returned in response to future requests
+ and SHOULD be deleted from the cache.
+
+13.7 Shared and Non-Shared Caches
+
+ For reasons of security and privacy, it is necessary to make a
+ distinction between "shared" and "non-shared" caches. A non-shared
+ cache is one that is accessible only to a single user. Accessibility
+ in this case SHOULD be enforced by appropriate security mechanisms.
+ All other caches are considered to be "shared." Other sections of
+
+
+
+
+
+Fielding, et al. Standards Track [Page 96]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ this specification place certain constraints on the operation of
+ shared caches in order to prevent loss of privacy or failure of
+ access controls.
+
+13.8 Errors or Incomplete Response Cache Behavior
+
+ A cache that receives an incomplete response (for example, with fewer
+ bytes of data than specified in a Content-Length header) MAY store
+ the response. However, the cache MUST treat this as a partial
+ response. Partial responses MAY be combined as described in section
+ 13.5.4; the result might be a full response or might still be
+ partial. A cache MUST NOT return a partial response to a client
+ without explicitly marking it as such, using the 206 (Partial
+ Content) status code. A cache MUST NOT return a partial response
+ using a status code of 200 (OK).
+
+ If a cache receives a 5xx response while attempting to revalidate an
+ entry, it MAY either forward this response to the requesting client,
+ or act as if the server failed to respond. In the latter case, it MAY
+ return a previously received response unless the cached entry
+ includes the "must-revalidate" cache-control directive (see section
+ 14.9).
+
+13.9 Side Effects of GET and HEAD
+
+ Unless the origin server explicitly prohibits the caching of their
+ responses, the application of GET and HEAD methods to any resources
+ SHOULD NOT have side effects that would lead to erroneous behavior if
+ these responses are taken from a cache. They MAY still have side
+ effects, but a cache is not required to consider such side effects in
+ its caching decisions. Caches are always expected to observe an
+ origin server's explicit restrictions on caching.
+
+ We note one exception to this rule: since some applications have
+ traditionally used GETs and HEADs with query URLs (those containing a
+ "?" in the rel_path part) to perform operations with significant side
+ effects, caches MUST NOT treat responses to such URIs as fresh unless
+ the server provides an explicit expiration time. This specifically
+ means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
+ be taken from a cache. See section 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+ The effect of certain methods performed on a resource at the origin
+ server might cause one or more existing cache entries to become non-
+ transparently invalid. That is, although they might continue to be
+ "fresh," they do not accurately reflect what the origin server would
+ return for a new request on that resource.
+
+
+
+Fielding, et al. Standards Track [Page 97]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ There is no way for the HTTP protocol to guarantee that all such
+ cache entries are marked invalid. For example, the request that
+ caused the change at the origin server might not have gone through
+ the proxy where a cache entry is stored. However, several rules help
+ reduce the likelihood of erroneous behavior.
+
+ In this section, the phrase "invalidate an entity" means that the
+ cache will either remove all instances of that entity from its
+ storage, or will mark these as "invalid" and in need of a mandatory
+ revalidation before they can be returned in response to a subsequent
+ request.
+
+ Some HTTP methods MUST cause a cache to invalidate an entity. This is
+ either the entity referred to by the Request-URI, or by the Location
+ or Content-Location headers (if present). These methods are:
+
+ - PUT
+
+ - DELETE
+
+ - POST
+
+ In order to prevent denial of service attacks, an invalidation based
+ on the URI in a Location or Content-Location header MUST only be
+ performed if the host part is the same as in the Request-URI.
+
+ A cache that passes through requests for methods it does not
+ understand SHOULD invalidate any entities referred to by the
+ Request-URI.
+
+13.11 Write-Through Mandatory
+
+ All methods that might be expected to cause modifications to the
+ origin server's resources MUST be written through to the origin
+ server. This currently includes all methods except for GET and HEAD.
+ A cache MUST NOT reply to such a request from a client before having
+ transmitted the request to the inbound server, and having received a
+ corresponding response from the inbound server. This does not prevent
+ a proxy cache from sending a 100 (Continue) response before the
+ inbound server has sent its final reply.
+
+ The alternative (known as "write-back" or "copy-back" caching) is not
+ allowed in HTTP/1.1, due to the difficulty of providing consistent
+ updates and the problems arising from server, cache, or network
+ failure prior to write-back.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 98]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+13.12 Cache Replacement
+
+ If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+ response is received from a resource while any existing responses for
+ the same resource are cached, the cache SHOULD use the new response
+ to reply to the current request. It MAY insert it into cache storage
+ and MAY, if it meets all other requirements, use it to respond to any
+ future requests that would previously have caused the old response to
+ be returned. If it inserts the new response into cache storage the
+ rules in section 13.5.3 apply.
+
+ Note: a new response that has an older Date header value than
+ existing cached responses is not cacheable.
+
+13.13 History Lists
+
+ User agents often have history mechanisms, such as "Back" buttons and
+ history lists, which can be used to redisplay an entity retrieved
+ earlier in a session.
+
+ History mechanisms and caches are different. In particular history
+ mechanisms SHOULD NOT try to show a semantically transparent view of
+ the current state of a resource. Rather, a history mechanism is meant
+ to show exactly what the user saw at the time when the resource was
+ retrieved.
+
+ By default, an expiration time does not apply to history mechanisms.
+ If the entity is still in storage, a history mechanism SHOULD display
+ it even if the entity has expired, unless the user has specifically
+ configured the agent to refresh expired history documents.
+
+ This is not to be construed to prohibit the history mechanism from
+ telling the user that a view might be stale.
+
+ Note: if history list mechanisms unnecessarily prevent users from
+ viewing stale resources, this will tend to force service authors
+ to avoid using HTTP expiration controls and cache controls when
+ they would otherwise like to. Service authors may consider it
+ important that users not be presented with error messages or
+ warning messages when they use navigation controls (such as BACK)
+ to view previously fetched resources. Even though sometimes such
+ resources ought not to cached, or ought to expire quickly, user
+ interface considerations may force service authors to resort to
+ other means of preventing caching (e.g. "once-only" URLs) in order
+ not to suffer the effects of improperly functioning history
+ mechanisms.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 99]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14 Header Field Definitions
+
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
+
+14.1 Accept
+
+ The Accept request-header field can be used to specify certain media
+ types which are acceptable for the response. Accept headers can be
+ used to indicate that the request is specifically limited to a small
+ set of desired types, as in the case of a request for an in-line
+ image.
+
+ Accept = "Accept" ":"
+ #( media-range [ accept-params ] )
+
+ media-range = ( "*/*"
+ | ( type "/" "*" )
+ | ( type "/" subtype )
+ ) *( ";" parameter )
+ accept-params = ";" "q" "=" qvalue *( accept-extension )
+ accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+ The asterisk "*" character is used to group media types into ranges,
+ with "*/*" indicating all media types and "type/*" indicating all
+ subtypes of that type. The media-range MAY include media type
+ parameters that are applicable to that range.
+
+ Each media-range MAY be followed by one or more accept-params,
+ beginning with the "q" parameter for indicating a relative quality
+ factor. The first "q" parameter (if any) separates the media-range
+ parameter(s) from the accept-params. Quality factors allow the user
+ or user agent to indicate the relative degree of preference for that
+ media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+ default value is q=1.
+
+ Note: Use of the "q" parameter name to separate media type
+ parameters from Accept extension parameters is due to historical
+ practice. Although this prevents any media type parameter named
+ "q" from being used with a media range, such an event is believed
+ to be unlikely given the lack of any "q" parameters in the IANA
+ media type registry and the rare usage of any media type
+ parameters in Accept. Future media types are discouraged from
+ registering any parameter named "q".
+
+
+
+
+
+Fielding, et al. Standards Track [Page 100]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The example
+
+ Accept: audio/*; q=0.2, audio/basic
+
+ SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+ type if it is the best available after an 80% mark-down in quality."
+
+ If no Accept header field is present, then it is assumed that the
+ client accepts all media types. If an Accept header field is present,
+ and if the server cannot send a response which is acceptable
+ according to the combined Accept field value, then the server SHOULD
+ send a 406 (not acceptable) response.
+
+ A more elaborate example is
+
+ Accept: text/plain; q=0.5, text/html,
+ text/x-dvi; q=0.8, text/x-c
+
+ Verbally, this would be interpreted as "text/html and text/x-c are
+ the preferred media types, but if they do not exist, then send the
+ text/x-dvi entity, and if that does not exist, send the text/plain
+ entity."
+
+ Media ranges can be overridden by more specific media ranges or
+ specific media types. If more than one media range applies to a given
+ type, the most specific reference has precedence. For example,
+
+ Accept: text/*, text/html, text/html;level=1, */*
+
+ have the following precedence:
+
+ 1) text/html;level=1
+ 2) text/html
+ 3) text/*
+ 4) */*
+
+ The media type quality factor associated with a given type is
+ determined by finding the media range with the highest precedence
+ which matches that type. For example,
+
+ Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+ text/html;level=2;q=0.4, */*;q=0.5
+
+ would cause the following values to be associated:
+
+ text/html;level=1 = 1
+ text/html = 0.7
+ text/plain = 0.3
+
+
+
+Fielding, et al. Standards Track [Page 101]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ image/jpeg = 0.5
+ text/html;level=2 = 0.4
+ text/html;level=3 = 0.7
+
+ Note: A user agent might be provided with a default set of quality
+ values for certain media ranges. However, unless the user agent is
+ a closed system which cannot interact with other rendering agents,
+ this default set ought to be configurable by the user.
+
+14.2 Accept-Charset
+
+ The Accept-Charset request-header field can be used to indicate what
+ character sets are acceptable for the response. This field allows
+ clients capable of understanding more comprehensive or special-
+ purpose character sets to signal that capability to a server which is
+ capable of representing documents in those character sets.
+
+ Accept-Charset = "Accept-Charset" ":"
+ 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
+
+
+ Character set values are described in section 3.4. Each charset MAY
+ be given an associated quality value which represents the user's
+ preference for that charset. The default value is q=1. An example is
+
+ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+ The special value "*", if present in the Accept-Charset field,
+ matches every character set (including ISO-8859-1) which is not
+ mentioned elsewhere in the Accept-Charset field. If no "*" is present
+ in an Accept-Charset field, then all character sets not explicitly
+ mentioned get a quality value of 0, except for ISO-8859-1, which gets
+ a quality value of 1 if not explicitly mentioned.
+
+ If no Accept-Charset header is present, the default is that any
+ character set is acceptable. If an Accept-Charset header is present,
+ and if the server cannot send a response which is acceptable
+ according to the Accept-Charset header, then the server SHOULD send
+ an error response with the 406 (not acceptable) status code, though
+ the sending of an unacceptable response is also allowed.
+
+14.3 Accept-Encoding
+
+ The Accept-Encoding request-header field is similar to Accept, but
+ restricts the content-codings (section 3.5) that are acceptable in
+ the response.
+
+ Accept-Encoding = "Accept-Encoding" ":"
+
+
+
+Fielding, et al. Standards Track [Page 102]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 1#( codings [ ";" "q" "=" qvalue ] )
+ codings = ( content-coding | "*" )
+
+ Examples of its use are:
+
+ Accept-Encoding: compress, gzip
+ Accept-Encoding:
+ Accept-Encoding: *
+ Accept-Encoding: compress;q=0.5, gzip;q=1.0
+ Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
+
+ A server tests whether a content-coding is acceptable, according to
+ an Accept-Encoding field, using these rules:
+
+ 1. If the content-coding is one of the content-codings listed in
+ the Accept-Encoding field, then it is acceptable, unless it is
+ accompanied by a qvalue of 0. (As defined in section 3.9, a
+ qvalue of 0 means "not acceptable.")
+
+ 2. The special "*" symbol in an Accept-Encoding field matches any
+ available content-coding not explicitly listed in the header
+ field.
+
+ 3. If multiple content-codings are acceptable, then the acceptable
+ content-coding with the highest non-zero qvalue is preferred.
+
+ 4. The "identity" content-coding is always acceptable, unless
+ specifically refused because the Accept-Encoding field includes
+ "identity;q=0", or because the field includes "*;q=0" and does
+ not explicitly include the "identity" content-coding. If the
+ Accept-Encoding field-value is empty, then only the "identity"
+ encoding is acceptable.
+
+ If an Accept-Encoding field is present in a request, and if the
+ server cannot send a response which is acceptable according to the
+ Accept-Encoding header, then the server SHOULD send an error response
+ with the 406 (Not Acceptable) status code.
+
+ If no Accept-Encoding field is present in a request, the server MAY
+ assume that the client will accept any content coding. In this case,
+ if "identity" is one of the available content-codings, then the
+ server SHOULD use the "identity" content-coding, unless it has
+ additional information that a different content-coding is meaningful
+ to the client.
+
+ Note: If the request does not include an Accept-Encoding field,
+ and if the "identity" content-coding is unavailable, then
+ content-codings commonly understood by HTTP/1.0 clients (i.e.,
+
+
+
+Fielding, et al. Standards Track [Page 103]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ "gzip" and "compress") are preferred; some older clients
+ improperly display messages sent with other content-codings. The
+ server might also make this decision based on information about
+ the particular user-agent or client.
+
+ Note: Most HTTP/1.0 applications do not recognize or obey qvalues
+ associated with content-codings. This means that qvalues will not
+ work and are not permitted with x-gzip or x-compress.
+
+14.4 Accept-Language
+
+ The Accept-Language request-header field is similar to Accept, but
+ restricts the set of natural languages that are preferred as a
+ response to the request. Language tags are defined in section 3.10.
+
+ Accept-Language = "Accept-Language" ":"
+ 1#( language-range [ ";" "q" "=" qvalue ] )
+ language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+
+ Each language-range MAY be given an associated quality value which
+ represents an estimate of the user's preference for the languages
+ specified by that range. The quality value defaults to "q=1". For
+ example,
+
+ Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+ would mean: "I prefer Danish, but will accept British English and
+ other types of English." A language-range matches a language-tag if
+ it exactly equals the tag, or if it exactly equals a prefix of the
+ tag such that the first tag character following the prefix is "-".
+ The special range "*", if present in the Accept-Language field,
+ matches every tag not matched by any other range present in the
+ Accept-Language field.
+
+ Note: This use of a prefix matching rule does not imply that
+ language tags are assigned to languages in such a way that it is
+ always true that if a user understands a language with a certain
+ tag, then this user will also understand all languages with tags
+ for which this tag is a prefix. The prefix rule simply allows the
+ use of prefix tags if this is the case.
+
+ The language quality factor assigned to a language-tag by the
+ Accept-Language field is the quality value of the longest language-
+ range in the field that matches the language-tag. If no language-
+ range in the field matches the tag, the language quality factor
+ assigned is 0. If no Accept-Language header is present in the
+ request, the server
+
+
+
+
+Fielding, et al. Standards Track [Page 104]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ SHOULD assume that all languages are equally acceptable. If an
+ Accept-Language header is present, then all languages which are
+ assigned a quality factor greater than 0 are acceptable.
+
+ It might be contrary to the privacy expectations of the user to send
+ an Accept-Language header with the complete linguistic preferences of
+ the user in every request. For a discussion of this issue, see
+ section 15.1.4.
+
+ As intelligibility is highly dependent on the individual user, it is
+ recommended that client applications make the choice of linguistic
+ preference available to the user. If the choice is not made
+ available, then the Accept-Language header field MUST NOT be given in
+ the request.
+
+ Note: When making the choice of linguistic preference available to
+ the user, we remind implementors of the fact that users are not
+ familiar with the details of language matching as described above,
+ and should provide appropriate guidance. As an example, users
+ might assume that on selecting "en-gb", they will be served any
+ kind of English document if British English is not available. A
+ user agent might suggest in such a case to add "en" to get the
+ best matching behavior.
+
+14.5 Accept-Ranges
+
+ The Accept-Ranges response-header field allows the server to
+ indicate its acceptance of range requests for a resource:
+
+ Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
+ acceptable-ranges = 1#range-unit | "none"
+
+ Origin servers that accept byte-range requests MAY send
+
+ Accept-Ranges: bytes
+
+ but are not required to do so. Clients MAY generate byte-range
+ requests without having received this header for the resource
+ involved. Range units are defined in section 3.12.
+
+ Servers that do not accept any kind of range request for a
+ resource MAY send
+
+ Accept-Ranges: none
+
+ to advise the client not to attempt a range request.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 105]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.6 Age
+
+ The Age response-header field conveys the sender's estimate of the
+ amount of time since the response (or its revalidation) was
+ generated at the origin server. A cached response is "fresh" if
+ its age does not exceed its freshness lifetime. Age values are
+ calculated as specified in section 13.2.3.
+
+ Age = "Age" ":" age-value
+ age-value = delta-seconds
+
+ Age values are non-negative decimal integers, representing time in
+ seconds.
+
+ If a cache receives a value larger than the largest positive
+ integer it can represent, or if any of its age calculations
+ overflows, it MUST transmit an Age header with a value of
+ 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
+ include an Age header field in every response generated from its
+ own cache. Caches SHOULD use an arithmetic type of at least 31
+ bits of range.
+
+14.7 Allow
+
+ The Allow entity-header field lists the set of methods supported
+ by the resource identified by the Request-URI. The purpose of this
+ field is strictly to inform the recipient of valid methods
+ associated with the resource. An Allow header field MUST be
+ present in a 405 (Method Not Allowed) response.
+
+ Allow = "Allow" ":" #Method
+
+ Example of use:
+
+ Allow: GET, HEAD, PUT
+
+ This field cannot prevent a client from trying other methods.
+ However, the indications given by the Allow header field value
+ SHOULD be followed. The actual set of allowed methods is defined
+ by the origin server at the time of each request.
+
+ The Allow header field MAY be provided with a PUT request to
+ recommend the methods to be supported by the new or modified
+ resource. The server is not required to support these methods and
+ SHOULD include an Allow header in the response giving the actual
+ supported methods.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 106]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ A proxy MUST NOT modify the Allow header field even if it does not
+ understand all the methods specified, since the user agent might
+ have other means of communicating with the origin server.
+
+14.8 Authorization
+
+ A user agent that wishes to authenticate itself with a server--
+ usually, but not necessarily, after receiving a 401 response--does
+ so by including an Authorization request-header field with the
+ request. The Authorization field value consists of credentials
+ containing the authentication information of the user agent for
+ the realm of the resource being requested.
+
+ Authorization = "Authorization" ":" credentials
+
+ HTTP access authentication is described in "HTTP Authentication:
+ Basic and Digest Access Authentication" [43]. If a request is
+ authenticated and a realm specified, the same credentials SHOULD
+ be valid for all other requests within this realm (assuming that
+ the authentication scheme itself does not require otherwise, such
+ as credentials that vary according to a challenge value or using
+ synchronized clocks).
+
+ When a shared cache (see section 13.7) receives a request
+ containing an Authorization field, it MUST NOT return the
+ corresponding response as a reply to any other request, unless one
+ of the following specific exceptions holds:
+
+ 1. If the response includes the "s-maxage" cache-control
+ directive, the cache MAY use that response in replying to a
+ subsequent request. But (if the specified maximum age has
+ passed) a proxy cache MUST first revalidate it with the origin
+ server, using the request-headers from the new request to allow
+ the origin server to authenticate the new request. (This is the
+ defined behavior for s-maxage.) If the response includes "s-
+ maxage=0", the proxy MUST always revalidate it before re-using
+ it.
+
+ 2. If the response includes the "must-revalidate" cache-control
+ directive, the cache MAY use that response in replying to a
+ subsequent request. But if the response is stale, all caches
+ MUST first revalidate it with the origin server, using the
+ request-headers from the new request to allow the origin server
+ to authenticate the new request.
+
+ 3. If the response includes the "public" cache-control directive,
+ it MAY be returned in reply to any subsequent request.
+
+
+
+
+Fielding, et al. Standards Track [Page 107]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.9 Cache-Control
+
+ The Cache-Control general-header field is used to specify directives
+ that MUST be obeyed by all caching mechanisms along the
+ request/response chain. The directives specify behavior intended to
+ prevent caches from adversely interfering with the request or
+ response. These directives typically override the default caching
+ algorithms. Cache directives are unidirectional in that the presence
+ of a directive in a request does not imply that the same directive is
+ to be given in the response.
+
+ Note that HTTP/1.0 caches might not implement Cache-Control and
+ might only implement Pragma: no-cache (see section 14.32).
+
+ Cache directives MUST be passed through by a proxy or gateway
+ application, regardless of their significance to that application,
+ since the directives might be applicable to all recipients along the
+ request/response chain. It is not possible to specify a cache-
+ directive for a specific cache.
+
+ Cache-Control = "Cache-Control" ":" 1#cache-directive
+
+ cache-directive = cache-request-directive
+ | cache-response-directive
+
+ cache-request-directive =
+ "no-cache" ; Section 14.9.1
+ | "no-store" ; Section 14.9.2
+ | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
+ | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
+ | "min-fresh" "=" delta-seconds ; Section 14.9.3
+ | "no-transform" ; Section 14.9.5
+ | "only-if-cached" ; Section 14.9.4
+ | cache-extension ; Section 14.9.6
+
+ cache-response-directive =
+ "public" ; Section 14.9.1
+ | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
+ | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
+ | "no-store" ; Section 14.9.2
+ | "no-transform" ; Section 14.9.5
+ | "must-revalidate" ; Section 14.9.4
+ | "proxy-revalidate" ; Section 14.9.4
+ | "max-age" "=" delta-seconds ; Section 14.9.3
+ | "s-maxage" "=" delta-seconds ; Section 14.9.3
+ | cache-extension ; Section 14.9.6
+
+ cache-extension = token [ "=" ( token | quoted-string ) ]
+
+
+
+Fielding, et al. Standards Track [Page 108]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ When a directive appears without any 1#field-name parameter, the
+ directive applies to the entire request or response. When such a
+ directive appears with a 1#field-name parameter, it applies only to
+ the named field or fields, and not to the rest of the request or
+ response. This mechanism supports extensibility; implementations of
+ future versions of the HTTP protocol might apply these directives to
+ header fields not defined in HTTP/1.1.
+
+ The cache-control directives can be broken down into these general
+ categories:
+
+ - Restrictions on what are cacheable; these may only be imposed by
+ the origin server.
+
+ - Restrictions on what may be stored by a cache; these may be
+ imposed by either the origin server or the user agent.
+
+ - Modifications of the basic expiration mechanism; these may be
+ imposed by either the origin server or the user agent.
+
+ - Controls over cache revalidation and reload; these may only be
+ imposed by a user agent.
+
+ - Control over transformation of entities.
+
+ - Extensions to the caching system.
+
+14.9.1 What is Cacheable
+
+ By default, a response is cacheable if the requirements of the
+ request method, request header fields, and the response status
+ indicate that it is cacheable. Section 13.4 summarizes these defaults
+ for cacheability. The following Cache-Control response directives
+ allow an origin server to override the default cacheability of a
+ response:
+
+ public
+ Indicates that the response MAY be cached by any cache, even if it
+ would normally be non-cacheable or cacheable only within a non-
+ shared cache. (See also Authorization, section 14.8, for
+ additional details.)
+
+ private
+ Indicates that all or part of the response message is intended for
+ a single user and MUST NOT be cached by a shared cache. This
+ allows an origin server to state that the specified parts of the
+
+
+
+
+
+Fielding, et al. Standards Track [Page 109]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ response are intended for only one user and are not a valid
+ response for requests by other users. A private (non-shared) cache
+ MAY cache the response.
+
+ Note: This usage of the word private only controls where the
+ response may be cached, and cannot ensure the privacy of the
+ message content.
+
+ no-cache
+ If the no-cache directive does not specify a field-name, then a
+ cache MUST NOT use the response to satisfy a subsequent request
+ without successful revalidation with the origin server. This
+ allows an origin server to prevent caching even by caches that
+ have been configured to return stale responses to client requests.
+
+ If the no-cache directive does specify one or more field-names,
+ then a cache MAY use the response to satisfy a subsequent request,
+ subject to any other restrictions on caching. However, the
+ specified field-name(s) MUST NOT be sent in the response to a
+ subsequent request without successful revalidation with the origin
+ server. This allows an origin server to prevent the re-use of
+ certain header fields in a response, while still allowing caching
+ of the rest of the response.
+
+ Note: Most HTTP/1.0 caches will not recognize or obey this
+ directive.
+
+14.9.2 What May be Stored by Caches
+
+ no-store
+ The purpose of the no-store directive is to prevent the
+ inadvertent release or retention of sensitive information (for
+ example, on backup tapes). The no-store directive applies to the
+ entire message, and MAY be sent either in a response or in a
+ request. If sent in a request, a cache MUST NOT store any part of
+ either this request or any response to it. If sent in a response,
+ a cache MUST NOT store any part of either this response or the
+ request that elicited it. This directive applies to both non-
+ shared and shared caches. "MUST NOT store" in this context means
+ that the cache MUST NOT intentionally store the information in
+ non-volatile storage, and MUST make a best-effort attempt to
+ remove the information from volatile storage as promptly as
+ possible after forwarding it.
+
+ Even when this directive is associated with a response, users
+ might explicitly store such a response outside of the caching
+ system (e.g., with a "Save As" dialog). History buffers MAY store
+ such responses as part of their normal operation.
+
+
+
+Fielding, et al. Standards Track [Page 110]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The purpose of this directive is to meet the stated requirements
+ of certain users and service authors who are concerned about
+ accidental releases of information via unanticipated accesses to
+ cache data structures. While the use of this directive might
+ improve privacy in some cases, we caution that it is NOT in any
+ way a reliable or sufficient mechanism for ensuring privacy. In
+ particular, malicious or compromised caches might not recognize or
+ obey this directive, and communications networks might be
+ vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+ The expiration time of an entity MAY be specified by the origin
+ server using the Expires header (see section 14.21). Alternatively,
+ it MAY be specified using the max-age directive in a response. When
+ the max-age cache-control directive is present in a cached response,
+ the response is stale if its current age is greater than the age
+ value given (in seconds) at the time of a new request for that
+ resource. The max-age directive on a response implies that the
+ response is cacheable (i.e., "public") unless some other, more
+ restrictive cache directive is also present.
+
+ If a response includes both an Expires header and a max-age
+ directive, the max-age directive overrides the Expires header, even
+ if the Expires header is more restrictive. This rule allows an origin
+ server to provide, for a given response, a longer expiration time to
+ an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
+ useful if certain HTTP/1.0 caches improperly calculate ages or
+ expiration times, perhaps due to desynchronized clocks.
+
+ Many HTTP/1.0 cache implementations will treat an Expires value that
+ is less than or equal to the response Date value as being equivalent
+ to the Cache-Control response directive "no-cache". If an HTTP/1.1
+ cache receives such a response, and the response does not include a
+ Cache-Control header field, it SHOULD consider the response to be
+ non-cacheable in order to retain compatibility with HTTP/1.0 servers.
+
+ Note: An origin server might wish to use a relatively new HTTP
+ cache control feature, such as the "private" directive, on a
+ network including older caches that do not understand that
+ feature. The origin server will need to combine the new feature
+ with an Expires field whose value is less than or equal to the
+ Date value. This will prevent older caches from improperly
+ caching the response.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 111]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ s-maxage
+ If a response includes an s-maxage directive, then for a shared
+ cache (but not for a private cache), the maximum age specified by
+ this directive overrides the maximum age specified by either the
+ max-age directive or the Expires header. The s-maxage directive
+ also implies the semantics of the proxy-revalidate directive (see
+ section 14.9.4), i.e., that the shared cache must not use the
+ entry after it becomes stale to respond to a subsequent request
+ without first revalidating it with the origin server. The s-
+ maxage directive is always ignored by a private cache.
+
+ Note that most older caches, not compliant with this specification,
+ do not implement any cache-control directives. An origin server
+ wishing to use a cache-control directive that restricts, but does not
+ prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
+ requirement that the max-age directive overrides the Expires header,
+ and the fact that pre-HTTP/1.1-compliant caches do not observe the
+ max-age directive.
+
+ Other directives allow a user agent to modify the basic expiration
+ mechanism. These directives MAY be specified on a request:
+
+ max-age
+ Indicates that the client is willing to accept a response whose
+ age is no greater than the specified time in seconds. Unless max-
+ stale directive is also included, the client is not willing to
+ accept a stale response.
+
+ min-fresh
+ Indicates that the client is willing to accept a response whose
+ freshness lifetime is no less than its current age plus the
+ specified time in seconds. That is, the client wants a response
+ that will still be fresh for at least the specified number of
+ seconds.
+
+ max-stale
+ Indicates that the client is willing to accept a response that has
+ exceeded its expiration time. If max-stale is assigned a value,
+ then the client is willing to accept a response that has exceeded
+ its expiration time by no more than the specified number of
+ seconds. If no value is assigned to max-stale, then the client is
+ willing to accept a stale response of any age.
+
+ If a cache returns a stale response, either because of a max-stale
+ directive on a request, or because the cache is configured to
+ override the expiration time of a response, the cache MUST attach a
+ Warning header to the stale response, using Warning 110 (Response is
+ stale).
+
+
+
+Fielding, et al. Standards Track [Page 112]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ A cache MAY be configured to return stale responses without
+ validation, but only if this does not conflict with any "MUST"-level
+ requirements concerning cache validation (e.g., a "must-revalidate"
+ cache-control directive).
+
+ If both the new request and the cached entry include "max-age"
+ directives, then the lesser of the two values is used for determining
+ the freshness of the cached entry for that request.
+
+14.9.4 Cache Revalidation and Reload Controls
+
+ Sometimes a user agent might want or need to insist that a cache
+ revalidate its cache entry with the origin server (and not just with
+ the next cache along the path to the origin server), or to reload its
+ cache entry from the origin server. End-to-end revalidation might be
+ necessary if either the cache or the origin server has overestimated
+ the expiration time of the cached response. End-to-end reload may be
+ necessary if the cache entry has become corrupted for some reason.
+
+ End-to-end revalidation may be requested either when the client does
+ not have its own local cached copy, in which case we call it
+ "unspecified end-to-end revalidation", or when the client does have a
+ local cached copy, in which case we call it "specific end-to-end
+ revalidation."
+
+ The client can specify these three kinds of action using Cache-
+ Control request directives:
+
+ End-to-end reload
+ The request includes a "no-cache" cache-control directive or, for
+ compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
+ names MUST NOT be included with the no-cache directive in a
+ request. The server MUST NOT use a cached copy when responding to
+ such a request.
+
+ Specific end-to-end revalidation
+ The request includes a "max-age=0" cache-control directive, which
+ forces each cache along the path to the origin server to
+ revalidate its own entry, if any, with the next cache or server.
+ The initial request includes a cache-validating conditional with
+ the client's current validator.
+
+ Unspecified end-to-end revalidation
+ The request includes "max-age=0" cache-control directive, which
+ forces each cache along the path to the origin server to
+ revalidate its own entry, if any, with the next cache or server.
+ The initial request does not include a cache-validating
+
+
+
+
+Fielding, et al. Standards Track [Page 113]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ conditional; the first cache along the path (if any) that holds a
+ cache entry for this resource includes a cache-validating
+ conditional with its current validator.
+
+ max-age
+ When an intermediate cache is forced, by means of a max-age=0
+ directive, to revalidate its own cache entry, and the client has
+ supplied its own validator in the request, the supplied validator
+ might differ from the validator currently stored with the cache
+ entry. In this case, the cache MAY use either validator in making
+ its own request without affecting semantic transparency.
+
+ However, the choice of validator might affect performance. The
+ best approach is for the intermediate cache to use its own
+ validator when making its request. If the server replies with 304
+ (Not Modified), then the cache can return its now validated copy
+ to the client with a 200 (OK) response. If the server replies with
+ a new entity and cache validator, however, the intermediate cache
+ can compare the returned validator with the one provided in the
+ client's request, using the strong comparison function. If the
+ client's validator is equal to the origin server's, then the
+ intermediate cache simply returns 304 (Not Modified). Otherwise,
+ it returns the new entity with a 200 (OK) response.
+
+ If a request includes the no-cache directive, it SHOULD NOT
+ include min-fresh, max-stale, or max-age.
+
+ only-if-cached
+ In some cases, such as times of extremely poor network
+ connectivity, a client may want a cache to return only those
+ responses that it currently has stored, and not to reload or
+ revalidate with the origin server. To do this, the client may
+ include the only-if-cached directive in a request. If it receives
+ this directive, a cache SHOULD either respond using a cached entry
+ that is consistent with the other constraints of the request, or
+ respond with a 504 (Gateway Timeout) status. However, if a group
+ of caches is being operated as a unified system with good internal
+ connectivity, such a request MAY be forwarded within that group of
+ caches.
+
+ must-revalidate
+ Because a cache MAY be configured to ignore a server's specified
+ expiration time, and because a client request MAY include a max-
+ stale directive (which has a similar effect), the protocol also
+ includes a mechanism for the origin server to require revalidation
+ of a cache entry on any subsequent use. When the must-revalidate
+ directive is present in a response received by a cache, that cache
+ MUST NOT use the entry after it becomes stale to respond to a
+
+
+
+Fielding, et al. Standards Track [Page 114]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ subsequent request without first revalidating it with the origin
+ server. (I.e., the cache MUST do an end-to-end revalidation every
+ time, if, based solely on the origin server's Expires or max-age
+ value, the cached response is stale.)
+
+ The must-revalidate directive is necessary to support reliable
+ operation for certain protocol features. In all circumstances an
+ HTTP/1.1 cache MUST obey the must-revalidate directive; in
+ particular, if the cache cannot reach the origin server for any
+ reason, it MUST generate a 504 (Gateway Timeout) response.
+
+ Servers SHOULD send the must-revalidate directive if and only if
+ failure to revalidate a request on the entity could result in
+ incorrect operation, such as a silently unexecuted financial
+ transaction. Recipients MUST NOT take any automated action that
+ violates this directive, and MUST NOT automatically provide an
+ unvalidated copy of the entity if revalidation fails.
+
+ Although this is not recommended, user agents operating under
+ severe connectivity constraints MAY violate this directive but, if
+ so, MUST explicitly warn the user that an unvalidated response has
+ been provided. The warning MUST be provided on each unvalidated
+ access, and SHOULD require explicit user confirmation.
+
+ proxy-revalidate
+ The proxy-revalidate directive has the same meaning as the must-
+ revalidate directive, except that it does not apply to non-shared
+ user agent caches. It can be used on a response to an
+ authenticated request to permit the user's cache to store and
+ later return the response without needing to revalidate it (since
+ it has already been authenticated once by that user), while still
+ requiring proxies that service many users to revalidate each time
+ (in order to make sure that each user has been authenticated).
+ Note that such authenticated responses also need the public cache
+ control directive in order to allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+ no-transform
+ Implementors of intermediate caches (proxies) have found it useful
+ to convert the media type of certain entity bodies. A non-
+ transparent proxy might, for example, convert between image
+ formats in order to save cache space or to reduce the amount of
+ traffic on a slow link.
+
+ Serious operational problems occur, however, when these
+ transformations are applied to entity bodies intended for certain
+ kinds of applications. For example, applications for medical
+
+
+
+Fielding, et al. Standards Track [Page 115]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ imaging, scientific data analysis and those using end-to-end
+ authentication, all depend on receiving an entity body that is bit
+ for bit identical to the original entity-body.
+
+ Therefore, if a message includes the no-transform directive, an
+ intermediate cache or proxy MUST NOT change those headers that are
+ listed in section 13.5.2 as being subject to the no-transform
+ directive. This implies that the cache or proxy MUST NOT change
+ any aspect of the entity-body that is specified by these headers,
+ including the value of the entity-body itself.
+
+14.9.6 Cache Control Extensions
+
+ The Cache-Control header field can be extended through the use of one
+ or more cache-extension tokens, each with an optional assigned value.
+ Informational extensions (those which do not require a change in
+ cache behavior) MAY be added without changing the semantics of other
+ directives. Behavioral extensions are designed to work by acting as
+ modifiers to the existing base of cache directives. Both the new
+ directive and the standard directive are supplied, such that
+ applications which do not understand the new directive will default
+ to the behavior specified by the standard directive, and those that
+ understand the new directive will recognize it as modifying the
+ requirements associated with the standard directive. In this way,
+ extensions to the cache-control directives can be made without
+ requiring changes to the base protocol.
+
+ This extension mechanism depends on an HTTP cache obeying all of the
+ cache-control directives defined for its native HTTP-version, obeying
+ certain extensions, and ignoring all directives that it does not
+ understand.
+
+ For example, consider a hypothetical new response directive called
+ community which acts as a modifier to the private directive. We
+ define this new directive to mean that, in addition to any non-shared
+ cache, any cache which is shared only by members of the community
+ named within its value may cache the response. An origin server
+ wishing to allow the UCI community to use an otherwise private
+ response in their shared cache(s) could do so by including
+
+ Cache-Control: private, community="UCI"
+
+ A cache seeing this header field will act correctly even if the cache
+ does not understand the community cache-extension, since it will also
+ see and understand the private directive and thus default to the safe
+ behavior.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 116]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Unrecognized cache-directives MUST be ignored; it is assumed that any
+ cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+ be combined with standard directives (or the response's default
+ cacheability) such that the cache behavior will remain minimally
+ correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+ The Connection general-header field allows the sender to specify
+ options that are desired for that particular connection and MUST NOT
+ be communicated by proxies over further connections.
+
+ The Connection header has the following grammar:
+
+ Connection = "Connection" ":" 1#(connection-token)
+ connection-token = token
+
+ HTTP/1.1 proxies MUST parse the Connection header field before a
+ message is forwarded and, for each connection-token in this field,
+ remove any header field(s) from the message with the same name as the
+ connection-token. Connection options are signaled by the presence of
+ a connection-token in the Connection header field, not by any
+ corresponding additional header field(s), since the additional header
+ field may not be sent if there are no parameters associated with that
+ connection option.
+
+ Message headers listed in the Connection header MUST NOT include
+ end-to-end headers, such as Cache-Control.
+
+ HTTP/1.1 defines the "close" connection option for the sender to
+ signal that the connection will be closed after completion of the
+ response. For example,
+
+ Connection: close
+
+ in either the request or the response header fields indicates that
+ the connection SHOULD NOT be considered `persistent' (section 8.1)
+ after the current request/response is complete.
+
+ HTTP/1.1 applications that do not support persistent connections MUST
+ include the "close" connection option in every message.
+
+ A system receiving an HTTP/1.0 (or lower-version) message that
+ includes a Connection header MUST, for each connection-token in this
+ field, remove and ignore any header field(s) from the message with
+ the same name as the connection-token. This protects against mistaken
+ forwarding of such header fields by pre-HTTP/1.1 proxies. See section
+ 19.6.2.
+
+
+
+Fielding, et al. Standards Track [Page 117]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.11 Content-Encoding
+
+ The Content-Encoding entity-header field is used as a modifier to the
+ media-type. When present, its value indicates what additional content
+ codings have been applied to the entity-body, and thus what decoding
+ mechanisms must be applied in order to obtain the media-type
+ referenced by the Content-Type header field. Content-Encoding is
+ primarily used to allow a document to be compressed without losing
+ the identity of its underlying media type.
+
+ Content-Encoding = "Content-Encoding" ":" 1#content-coding
+
+ Content codings are defined in section 3.5. An example of its use is
+
+ Content-Encoding: gzip
+
+ The content-coding is a characteristic of the entity identified by
+ the Request-URI. Typically, the entity-body is stored with this
+ encoding and is only decoded before rendering or analogous usage.
+ However, a non-transparent proxy MAY modify the content-coding if the
+ new coding is known to be acceptable to the recipient, unless the
+ "no-transform" cache-control directive is present in the message.
+
+ If the content-coding of an entity is not "identity", then the
+ response MUST include a Content-Encoding entity-header (section
+ 14.11) that lists the non-identity content-coding(s) used.
+
+ If the content-coding of an entity in a request message is not
+ acceptable to the origin server, the server SHOULD respond with a
+ status code of 415 (Unsupported Media Type).
+
+ If multiple encodings have been applied to an entity, the content
+ codings MUST be listed in the order in which they were applied.
+ Additional information about the encoding parameters MAY be provided
+ by other entity-header fields not defined by this specification.
+
+14.12 Content-Language
+
+ The Content-Language entity-header field describes the natural
+ language(s) of the intended audience for the enclosed entity. Note
+ that this might not be equivalent to all the languages used within
+ the entity-body.
+
+ Content-Language = "Content-Language" ":" 1#language-tag
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 118]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Language tags are defined in section 3.10. The primary purpose of
+ Content-Language is to allow a user to identify and differentiate
+ entities according to the user's own preferred language. Thus, if the
+ body content is intended only for a Danish-literate audience, the
+ appropriate field is
+
+ Content-Language: da
+
+ If no Content-Language is specified, the default is that the content
+ is intended for all language audiences. This might mean that the
+ sender does not consider it to be specific to any natural language,
+ or that the sender does not know for which language it is intended.
+
+ Multiple languages MAY be listed for content that is intended for
+ multiple audiences. For example, a rendition of the "Treaty of
+ Waitangi," presented simultaneously in the original Maori and English
+ versions, would call for
+
+ Content-Language: mi, en
+
+ However, just because multiple languages are present within an entity
+ does not mean that it is intended for multiple linguistic audiences.
+ An example would be a beginner's language primer, such as "A First
+ Lesson in Latin," which is clearly intended to be used by an
+ English-literate audience. In this case, the Content-Language would
+ properly only include "en".
+
+ Content-Language MAY be applied to any media type -- it is not
+ limited to textual documents.
+
+14.13 Content-Length
+
+ The Content-Length entity-header field indicates the size of the
+ entity-body, in decimal number of OCTETs, sent to the recipient or,
+ in the case of the HEAD method, the size of the entity-body that
+ would have been sent had the request been a GET.
+
+ Content-Length = "Content-Length" ":" 1*DIGIT
+
+ An example is
+
+ Content-Length: 3495
+
+ Applications SHOULD use this field to indicate the transfer-length of
+ the message-body, unless this is prohibited by the rules in section
+ 4.4.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 119]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Any Content-Length greater than or equal to zero is a valid value.
+ Section 4.4 describes how to determine the length of a message-body
+ if a Content-Length is not given.
+
+ Note that the meaning of this field is significantly different from
+ the corresponding definition in MIME, where it is an optional field
+ used within the "message/external-body" content-type. In HTTP, it
+ SHOULD be sent whenever the message's length can be determined prior
+ to being transferred, unless this is prohibited by the rules in
+ section 4.4.
+
+14.14 Content-Location
+
+ The Content-Location entity-header field MAY be used to supply the
+ resource location for the entity enclosed in the message when that
+ entity is accessible from a location separate from the requested
+ resource's URI. A server SHOULD provide a Content-Location for the
+ variant corresponding to the response entity; especially in the case
+ where a resource has multiple entities associated with it, and those
+ entities actually have separate locations by which they might be
+ individually accessed, the server SHOULD provide a Content-Location
+ for the particular variant which is returned.
+
+ Content-Location = "Content-Location" ":"
+ ( absoluteURI | relativeURI )
+
+ The value of Content-Location also defines the base URI for the
+ entity.
+
+ The Content-Location value is not a replacement for the original
+ requested URI; it is only a statement of the location of the resource
+ corresponding to this particular entity at the time of the request.
+ Future requests MAY specify the Content-Location URI as the request-
+ URI if the desire is to identify the source of that particular
+ entity.
+
+ A cache cannot assume that an entity with a Content-Location
+ different from the URI used to retrieve it can be used to respond to
+ later requests on that Content-Location URI. However, the Content-
+ Location can be used to differentiate between multiple entities
+ retrieved from a single requested resource, as described in section
+ 13.6.
+
+ If the Content-Location is a relative URI, the relative URI is
+ interpreted relative to the Request-URI.
+
+ The meaning of the Content-Location header in PUT or POST requests is
+ undefined; servers are free to ignore it in those cases.
+
+
+
+Fielding, et al. Standards Track [Page 120]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.15 Content-MD5
+
+ The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+ an MD5 digest of the entity-body for the purpose of providing an
+ end-to-end message integrity check (MIC) of the entity-body. (Note: a
+ MIC is good for detecting accidental modification of the entity-body
+ in transit, but is not proof against malicious attacks.)
+
+ Content-MD5 = "Content-MD5" ":" md5-digest
+ md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+ The Content-MD5 header field MAY be generated by an origin server or
+ client to function as an integrity check of the entity-body. Only
+ origin servers or clients MAY generate the Content-MD5 header field;
+ proxies and gateways MUST NOT generate it, as this would defeat its
+ value as an end-to-end integrity check. Any recipient of the entity-
+ body, including gateways and proxies, MAY check that the digest value
+ in this header field matches that of the entity-body as received.
+
+ The MD5 digest is computed based on the content of the entity-body,
+ including any content-coding that has been applied, but not including
+ any transfer-encoding applied to the message-body. If the message is
+ received with a transfer-encoding, that encoding MUST be removed
+ prior to checking the Content-MD5 value against the received entity.
+
+ This has the result that the digest is computed on the octets of the
+ entity-body exactly as, and in the order that, they would be sent if
+ no transfer-encoding were being applied.
+
+ HTTP extends RFC 1864 to permit the digest to be computed for MIME
+ composite media-types (e.g., multipart/* and message/rfc822), but
+ this does not change how the digest is computed as defined in the
+ preceding paragraph.
+
+ There are several consequences of this. The entity-body for composite
+ types MAY contain many body-parts, each with its own MIME and HTTP
+ headers (including Content-MD5, Content-Transfer-Encoding, and
+ Content-Encoding headers). If a body-part has a Content-Transfer-
+ Encoding or Content-Encoding header, it is assumed that the content
+ of the body-part has had the encoding applied, and the body-part is
+ included in the Content-MD5 digest as is -- i.e., after the
+ application. The Transfer-Encoding header field is not allowed within
+ body-parts.
+
+ Conversion of all line breaks to CRLF MUST NOT be done before
+ computing or checking the digest: the line break convention used in
+ the text actually transmitted MUST be left unaltered when computing
+ the digest.
+
+
+
+Fielding, et al. Standards Track [Page 121]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Note: while the definition of Content-MD5 is exactly the same for
+ HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+ in which the application of Content-MD5 to HTTP entity-bodies
+ differs from its application to MIME entity-bodies. One is that
+ HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
+ does use Transfer-Encoding and Content-Encoding. Another is that
+ HTTP more frequently uses binary content types than MIME, so it is
+ worth noting that, in such cases, the byte order used to compute
+ the digest is the transmission byte order defined for the type.
+ Lastly, HTTP allows transmission of text types with any of several
+ line break conventions and not just the canonical form using CRLF.
+
+14.16 Content-Range
+
+ The Content-Range entity-header is sent with a partial entity-body to
+ specify where in the full entity-body the partial body should be
+ applied. Range units are defined in section 3.12.
+
+ Content-Range = "Content-Range" ":" content-range-spec
+
+ content-range-spec = byte-content-range-spec
+ byte-content-range-spec = bytes-unit SP
+ byte-range-resp-spec "/"
+ ( instance-length | "*" )
+
+ byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+ | "*"
+ instance-length = 1*DIGIT
+
+ The header SHOULD indicate the total length of the full entity-body,
+ unless this length is unknown or difficult to determine. The asterisk
+ "*" character means that the instance-length is unknown at the time
+ when the response was generated.
+
+ Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
+ range-resp-spec MUST only specify one range, and MUST contain
+ absolute byte positions for both the first and last byte of the
+ range.
+
+ A byte-content-range-spec with a byte-range-resp-spec whose last-
+ byte-pos value is less than its first-byte-pos value, or whose
+ instance-length value is less than or equal to its last-byte-pos
+ value, is invalid. The recipient of an invalid byte-content-range-
+ spec MUST ignore it and any content transferred along with it.
+
+ A server sending a response with status code 416 (Requested range not
+ satisfiable) SHOULD include a Content-Range field with a byte-range-
+ resp-spec of "*". The instance-length specifies the current length of
+
+
+
+Fielding, et al. Standards Track [Page 122]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ the selected resource. A response with status code 206 (Partial
+ Content) MUST NOT include a Content-Range field with a byte-range-
+ resp-spec of "*".
+
+ Examples of byte-content-range-spec values, assuming that the entity
+ contains a total of 1234 bytes:
+
+ . The first 500 bytes:
+ bytes 0-499/1234
+
+ . The second 500 bytes:
+ bytes 500-999/1234
+
+ . All except for the first 500 bytes:
+ bytes 500-1233/1234
+
+ . The last 500 bytes:
+ bytes 734-1233/1234
+
+ When an HTTP message includes the content of a single range (for
+ example, a response to a request for a single range, or to a request
+ for a set of ranges that overlap without any holes), this content is
+ transmitted with a Content-Range header, and a Content-Length header
+ showing the number of bytes actually transferred. For example,
+
+ HTTP/1.1 206 Partial content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-Range: bytes 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+
+ When an HTTP message includes the content of multiple ranges (for
+ example, a response to a request for multiple non-overlapping
+ ranges), these are transmitted as a multipart message. The multipart
+ media type used for this purpose is "multipart/byteranges" as defined
+ in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
+
+ A response to a request for a single range MUST NOT be sent using the
+ multipart/byteranges media type. A response to a request for
+ multiple ranges, whose result is a single range, MAY be sent as a
+ multipart/byteranges media type with one part. A client that cannot
+ decode a multipart/byteranges message MUST NOT ask for multiple
+ byte-ranges in a single request.
+
+ When a client requests multiple byte-ranges in one request, the
+ server SHOULD return them in the order that they appeared in the
+ request.
+
+
+
+Fielding, et al. Standards Track [Page 123]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If the server ignores a byte-range-spec because it is syntactically
+ invalid, the server SHOULD treat the request as if the invalid Range
+ header field did not exist. (Normally, this means return a 200
+ response containing the full entity).
+
+ If the server receives a request (other than one including an If-
+ Range request-header field) with an unsatisfiable Range request-
+ header field (that is, all of whose byte-range-spec values have a
+ first-byte-pos value greater than the current length of the selected
+ resource), it SHOULD return a response code of 416 (Requested range
+ not satisfiable) (section 10.4.17).
+
+ Note: clients cannot depend on servers to send a 416 (Requested
+ range not satisfiable) response instead of a 200 (OK) response for
+ an unsatisfiable Range request-header, since not all servers
+ implement this request-header.
+
+14.17 Content-Type
+
+ The Content-Type entity-header field indicates the media type of the
+ entity-body sent to the recipient or, in the case of the HEAD method,
+ the media type that would have been sent had the request been a GET.
+
+ Content-Type = "Content-Type" ":" media-type
+
+ Media types are defined in section 3.7. An example of the field is
+
+ Content-Type: text/html; charset=ISO-8859-4
+
+ Further discussion of methods for identifying the media type of an
+ entity is provided in section 7.2.1.
+
+14.18 Date
+
+ The Date general-header field represents the date and time at which
+ the message was originated, having the same semantics as orig-date in
+ RFC 822. The field value is an HTTP-date, as described in section
+ 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
+
+ Date = "Date" ":" HTTP-date
+
+ An example is
+
+ Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+ Origin servers MUST include a Date header field in all responses,
+ except in these cases:
+
+
+
+
+Fielding, et al. Standards Track [Page 124]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 1. If the response status code is 100 (Continue) or 101 (Switching
+ Protocols), the response MAY include a Date header field, at
+ the server's option.
+
+ 2. If the response status code conveys a server error, e.g. 500
+ (Internal Server Error) or 503 (Service Unavailable), and it is
+ inconvenient or impossible to generate a valid Date.
+
+ 3. If the server does not have a clock that can provide a
+ reasonable approximation of the current time, its responses
+ MUST NOT include a Date header field. In this case, the rules
+ in section 14.18.1 MUST be followed.
+
+ A received message that does not have a Date header field MUST be
+ assigned one by the recipient if the message will be cached by that
+ recipient or gatewayed via a protocol which requires a Date. An HTTP
+ implementation without a clock MUST NOT cache responses without
+ revalidating them on every use. An HTTP cache, especially a shared
+ cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
+ clock with a reliable external standard.
+
+ Clients SHOULD only send a Date header field in messages that include
+ an entity-body, as in the case of the PUT and POST requests, and even
+ then it is optional. A client without a clock MUST NOT send a Date
+ header field in a request.
+
+ The HTTP-date sent in a Date header SHOULD NOT represent a date and
+ time subsequent to the generation of the message. It SHOULD represent
+ the best available approximation of the date and time of message
+ generation, unless the implementation has no means of generating a
+ reasonably accurate date and time. In theory, the date ought to
+ represent the moment just before the entity is generated. In
+ practice, the date can be generated at any time during the message
+ origination without affecting its semantic value.
+
+14.18.1 Clockless Origin Server Operation
+
+ Some origin server implementations might not have a clock available.
+ An origin server without a clock MUST NOT assign Expires or Last-
+ Modified values to a response, unless these values were associated
+ with the resource by a system or user with a reliable clock. It MAY
+ assign an Expires value that is known, at or before server
+ configuration time, to be in the past (this allows "pre-expiration"
+ of responses without storing separate Expires values for each
+ resource).
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 125]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.19 ETag
+
+ The ETag response-header field provides the current value of the
+ entity tag for the requested variant. The headers used with entity
+ tags are described in sections 14.24, 14.26 and 14.44. The entity tag
+ MAY be used for comparison with other entities from the same resource
+ (see section 13.3.3).
+
+ ETag = "ETag" ":" entity-tag
+
+ Examples:
+
+ ETag: "xyzzy"
+ ETag: W/"xyzzy"
+ ETag: ""
+
+14.20 Expect
+
+ The Expect request-header field is used to indicate that particular
+ server behaviors are required by the client.
+
+ Expect = "Expect" ":" 1#expectation
+
+ expectation = "100-continue" | expectation-extension
+ expectation-extension = token [ "=" ( token | quoted-string )
+ *expect-params ]
+ expect-params = ";" token [ "=" ( token | quoted-string ) ]
+
+
+ A server that does not understand or is unable to comply with any of
+ the expectation values in the Expect field of a request MUST respond
+ with appropriate error status. The server MUST respond with a 417
+ (Expectation Failed) status if any of the expectations cannot be met
+ or, if there are other problems with the request, some other 4xx
+ status.
+
+ This header field is defined with extensible syntax to allow for
+ future extensions. If a server receives a request containing an
+ Expect field that includes an expectation-extension that it does not
+ support, it MUST respond with a 417 (Expectation Failed) status.
+
+ Comparison of expectation values is case-insensitive for unquoted
+ tokens (including the 100-continue token), and is case-sensitive for
+ quoted-string expectation-extensions.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 126]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
+ return a 417 (Expectation Failed) status if it receives a request
+ with an expectation that it cannot meet. However, the Expect
+ request-header itself is end-to-end; it MUST be forwarded if the
+ request is forwarded.
+
+ Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
+ Expect header.
+
+ See section 8.2.3 for the use of the 100 (continue) status.
+
+14.21 Expires
+
+ The Expires entity-header field gives the date/time after which the
+ response is considered stale. A stale cache entry may not normally be
+ returned by a cache (either a proxy cache or a user agent cache)
+ unless it is first validated with the origin server (or with an
+ intermediate cache that has a fresh copy of the entity). See section
+ 13.2 for further discussion of the expiration model.
+
+ The presence of an Expires field does not imply that the original
+ resource will change or cease to exist at, before, or after that
+ time.
+
+ The format is an absolute date and time as defined by HTTP-date in
+ section 3.3.1; it MUST be in RFC 1123 date format:
+
+ Expires = "Expires" ":" HTTP-date
+
+ An example of its use is
+
+ Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+ Note: if a response includes a Cache-Control field with the max-
+ age directive (see section 14.9.3), that directive overrides the
+ Expires field.
+
+ HTTP/1.1 clients and caches MUST treat other invalid date formats,
+ especially including the value "0", as in the past (i.e., "already
+ expired").
+
+ To mark a response as "already expired," an origin server sends an
+ Expires date that is equal to the Date header value. (See the rules
+ for expiration calculations in section 13.2.4.)
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 127]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ To mark a response as "never expires," an origin server sends an
+ Expires date approximately one year from the time the response is
+ sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
+ year in the future.
+
+ The presence of an Expires header field with a date value of some
+ time in the future on a response that otherwise would by default be
+ non-cacheable indicates that the response is cacheable, unless
+ indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 From
+
+ The From request-header field, if given, SHOULD contain an Internet
+ e-mail address for the human user who controls the requesting user
+ agent. The address SHOULD be machine-usable, as defined by "mailbox"
+ in RFC 822 [9] as updated by RFC 1123 [8]:
+
+ From = "From" ":" mailbox
+
+ An example is:
+
+ From: webmaster@w3.org
+
+ This header field MAY be used for logging purposes and as a means for
+ identifying the source of invalid or unwanted requests. It SHOULD NOT
+ be used as an insecure form of access protection. The interpretation
+ of this field is that the request is being performed on behalf of the
+ person given, who accepts responsibility for the method performed. In
+ particular, robot agents SHOULD include this header so that the
+ person responsible for running the robot can be contacted if problems
+ occur on the receiving end.
+
+ The Internet e-mail address in this field MAY be separate from the
+ Internet host which issued the request. For example, when a request
+ is passed through a proxy the original issuer's address SHOULD be
+ used.
+
+ The client SHOULD NOT send the From header field without the user's
+ approval, as it might conflict with the user's privacy interests or
+ their site's security policy. It is strongly recommended that the
+ user be able to disable, enable, and modify the value of this field
+ at any time prior to a request.
+
+14.23 Host
+
+ The Host request-header field specifies the Internet host and port
+ number of the resource being requested, as obtained from the original
+ URI given by the user or referring resource (generally an HTTP URL,
+
+
+
+Fielding, et al. Standards Track [Page 128]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ as described in section 3.2.2). The Host field value MUST represent
+ the naming authority of the origin server or gateway given by the
+ original URL. This allows the origin server or gateway to
+ differentiate between internally-ambiguous URLs, such as the root "/"
+ URL of a server for multiple host names on a single IP address.
+
+ Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
+
+ A "host" without any trailing port information implies the default
+ port for the service requested (e.g., "80" for an HTTP URL). For
+ example, a request on the origin server for
+ <http://www.w3.org/pub/WWW/> would properly include:
+
+ GET /pub/WWW/ HTTP/1.1
+ Host: www.w3.org
+
+ A client MUST include a Host header field in all HTTP/1.1 request
+ messages . If the requested URI does not include an Internet host
+ name for the service being requested, then the Host header field MUST
+ be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
+ request message it forwards does contain an appropriate Host header
+ field that identifies the service being requested by the proxy. All
+ Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
+ status code to any HTTP/1.1 request message which lacks a Host header
+ field.
+
+ See sections 5.2 and 19.6.1.1 for other requirements relating to
+ Host.
+
+14.24 If-Match
+
+ The If-Match request-header field is used with a method to make it
+ conditional. A client that has one or more entities previously
+ obtained from the resource can verify that one of those entities is
+ current by including a list of their associated entity tags in the
+ If-Match header field. Entity tags are defined in section 3.11. The
+ purpose of this feature is to allow efficient updates of cached
+ information with a minimum amount of transaction overhead. It is also
+ used, on updating requests, to prevent inadvertent modification of
+ the wrong version of a resource. As a special case, the value "*"
+ matches any current entity of the resource.
+
+ If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+ If any of the entity tags match the entity tag of the entity that
+ would have been returned in the response to a similar GET request
+ (without the If-Match header) on that resource, or if "*" is given
+
+
+
+
+Fielding, et al. Standards Track [Page 129]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ and any current entity exists for that resource, then the server MAY
+ perform the requested method as if the If-Match header field did not
+ exist.
+
+ A server MUST use the strong comparison function (see section 13.3.3)
+ to compare the entity tags in If-Match.
+
+ If none of the entity tags match, or if "*" is given and no current
+ entity exists, the server MUST NOT perform the requested method, and
+ MUST return a 412 (Precondition Failed) response. This behavior is
+ most useful when the client wants to prevent an updating method, such
+ as PUT, from modifying a resource that has changed since the client
+ last retrieved it.
+
+ If the request would, without the If-Match header field, result in
+ anything other than a 2xx or 412 status, then the If-Match header
+ MUST be ignored.
+
+ The meaning of "If-Match: *" is that the method SHOULD be performed
+ if the representation selected by the origin server (or by a cache,
+ possibly using the Vary mechanism, see section 14.44) exists, and
+ MUST NOT be performed if the representation does not exist.
+
+ A request intended to update a resource (e.g., a PUT) MAY include an
+ If-Match header field to signal that the request method MUST NOT be
+ applied if the entity corresponding to the If-Match value (a single
+ entity tag) is no longer a representation of that resource. This
+ allows the user to indicate that they do not wish the request to be
+ successful if the resource has been changed without their knowledge.
+ Examples:
+
+ If-Match: "xyzzy"
+ If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-Match: *
+
+ The result of a request having both an If-Match header field and
+ either an If-None-Match or an If-Modified-Since header fields is
+ undefined by this specification.
+
+14.25 If-Modified-Since
+
+ The If-Modified-Since request-header field is used with a method to
+ make it conditional: if the requested variant has not been modified
+ since the time specified in this field, an entity will not be
+ returned from the server; instead, a 304 (not modified) response will
+ be returned without any message-body.
+
+ If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+
+
+Fielding, et al. Standards Track [Page 130]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ An example of the field is:
+
+ If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+ A GET method with an If-Modified-Since header and no Range header
+ requests that the identified entity be transferred only if it has
+ been modified since the date given by the If-Modified-Since header.
+ The algorithm for determining this includes the following cases:
+
+ a) If the request would normally result in anything other than a
+ 200 (OK) status, or if the passed If-Modified-Since date is
+ invalid, the response is exactly the same as for a normal GET.
+ A date which is later than the server's current time is
+ invalid.
+
+ b) If the variant has been modified since the If-Modified-Since
+ date, the response is exactly the same as for a normal GET.
+
+ c) If the variant has not been modified since a valid If-
+ Modified-Since date, the server SHOULD return a 304 (Not
+ Modified) response.
+
+ The purpose of this feature is to allow efficient updates of cached
+ information with a minimum amount of transaction overhead.
+
+ Note: The Range request-header field modifies the meaning of If-
+ Modified-Since; see section 14.35 for full details.
+
+ Note: If-Modified-Since times are interpreted by the server, whose
+ clock might not be synchronized with the client.
+
+ Note: When handling an If-Modified-Since header field, some
+ servers will use an exact date comparison function, rather than a
+ less-than function, for deciding whether to send a 304 (Not
+ Modified) response. To get best results when sending an If-
+ Modified-Since header field for cache validation, clients are
+ advised to use the exact date string received in a previous Last-
+ Modified header field whenever possible.
+
+ Note: If a client uses an arbitrary date in the If-Modified-Since
+ header instead of a date taken from the Last-Modified header for
+ the same request, the client should be aware of the fact that this
+ date is interpreted in the server's understanding of time. The
+ client should consider unsynchronized clocks and rounding problems
+ due to the different encodings of time between the client and
+ server. This includes the possibility of race conditions if the
+ document has changed between the time it was first requested and
+ the If-Modified-Since date of a subsequent request, and the
+
+
+
+Fielding, et al. Standards Track [Page 131]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ possibility of clock-skew-related problems if the If-Modified-
+ Since date is derived from the client's clock without correction
+ to the server's clock. Corrections for different time bases
+ between client and server are at best approximate due to network
+ latency.
+
+ The result of a request having both an If-Modified-Since header field
+ and either an If-Match or an If-Unmodified-Since header fields is
+ undefined by this specification.
+
+14.26 If-None-Match
+
+ The If-None-Match request-header field is used with a method to make
+ it conditional. A client that has one or more entities previously
+ obtained from the resource can verify that none of those entities is
+ current by including a list of their associated entity tags in the
+ If-None-Match header field. The purpose of this feature is to allow
+ efficient updates of cached information with a minimum amount of
+ transaction overhead. It is also used to prevent a method (e.g. PUT)
+ from inadvertently modifying an existing resource when the client
+ believes that the resource does not exist.
+
+ As a special case, the value "*" matches any current entity of the
+ resource.
+
+ If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+ If any of the entity tags match the entity tag of the entity that
+ would have been returned in the response to a similar GET request
+ (without the If-None-Match header) on that resource, or if "*" is
+ given and any current entity exists for that resource, then the
+ server MUST NOT perform the requested method, unless required to do
+ so because the resource's modification date fails to match that
+ supplied in an If-Modified-Since header field in the request.
+ Instead, if the request method was GET or HEAD, the server SHOULD
+ respond with a 304 (Not Modified) response, including the cache-
+ related header fields (particularly ETag) of one of the entities that
+ matched. For all other request methods, the server MUST respond with
+ a status of 412 (Precondition Failed).
+
+ See section 13.3.3 for rules on how to determine if two entities tags
+ match. The weak comparison function can only be used with GET or HEAD
+ requests.
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 132]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If none of the entity tags match, then the server MAY perform the
+ requested method as if the If-None-Match header field did not exist,
+ but MUST also ignore any If-Modified-Since header field(s) in the
+ request. That is, if no entity tags match, then the server MUST NOT
+ return a 304 (Not Modified) response.
+
+ If the request would, without the If-None-Match header field, result
+ in anything other than a 2xx or 304 status, then the If-None-Match
+ header MUST be ignored. (See section 13.3.4 for a discussion of
+ server behavior when both If-Modified-Since and If-None-Match appear
+ in the same request.)
+
+ The meaning of "If-None-Match: *" is that the method MUST NOT be
+ performed if the representation selected by the origin server (or by
+ a cache, possibly using the Vary mechanism, see section 14.44)
+ exists, and SHOULD be performed if the representation does not exist.
+ This feature is intended to be useful in preventing races between PUT
+ operations.
+
+ Examples:
+
+ If-None-Match: "xyzzy"
+ If-None-Match: W/"xyzzy"
+ If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+ If-None-Match: *
+
+ The result of a request having both an If-None-Match header field and
+ either an If-Match or an If-Unmodified-Since header fields is
+ undefined by this specification.
+
+14.27 If-Range
+
+ If a client has a partial copy of an entity in its cache, and wishes
+ to have an up-to-date copy of the entire entity in its cache, it
+ could use the Range request-header with a conditional GET (using
+ either or both of If-Unmodified-Since and If-Match.) However, if the
+ condition fails because the entity has been modified, the client
+ would then have to make a second request to obtain the entire current
+ entity-body.
+
+ The If-Range header allows a client to "short-circuit" the second
+ request. Informally, its meaning is `if the entity is unchanged, send
+ me the part(s) that I am missing; otherwise, send me the entire new
+ entity'.
+
+ If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+
+
+
+Fielding, et al. Standards Track [Page 133]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If the client has no entity tag for an entity, but does have a Last-
+ Modified date, it MAY use that date in an If-Range header. (The
+ server can distinguish between a valid HTTP-date and any form of
+ entity-tag by examining no more than two characters.) The If-Range
+ header SHOULD only be used together with a Range header, and MUST be
+ ignored if the request does not include a Range header, or if the
+ server does not support the sub-range operation.
+
+ If the entity tag given in the If-Range header matches the current
+ entity tag for the entity, then the server SHOULD provide the
+ specified sub-range of the entity using a 206 (Partial content)
+ response. If the entity tag does not match, then the server SHOULD
+ return the entire entity using a 200 (OK) response.
+
+14.28 If-Unmodified-Since
+
+ The If-Unmodified-Since request-header field is used with a method to
+ make it conditional. If the requested resource has not been modified
+ since the time specified in this field, the server SHOULD perform the
+ requested operation as if the If-Unmodified-Since header were not
+ present.
+
+ If the requested variant has been modified since the specified time,
+ the server MUST NOT perform the requested operation, and MUST return
+ a 412 (Precondition Failed).
+
+ If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+ An example of the field is:
+
+ If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+ If the request normally (i.e., without the If-Unmodified-Since
+ header) would result in anything other than a 2xx or 412 status, the
+ If-Unmodified-Since header SHOULD be ignored.
+
+ If the specified date is invalid, the header is ignored.
+
+ The result of a request having both an If-Unmodified-Since header
+ field and either an If-None-Match or an If-Modified-Since header
+ fields is undefined by this specification.
+
+14.29 Last-Modified
+
+ The Last-Modified entity-header field indicates the date and time at
+ which the origin server believes the variant was last modified.
+
+ Last-Modified = "Last-Modified" ":" HTTP-date
+
+
+
+Fielding, et al. Standards Track [Page 134]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ An example of its use is
+
+ Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+ The exact meaning of this header field depends on the implementation
+ of the origin server and the nature of the original resource. For
+ files, it may be just the file system last-modified time. For
+ entities with dynamically included parts, it may be the most recent
+ of the set of last-modify times for its component parts. For database
+ gateways, it may be the last-update time stamp of the record. For
+ virtual objects, it may be the last time the internal state changed.
+
+ An origin server MUST NOT send a Last-Modified date which is later
+ than the server's time of message origination. In such cases, where
+ the resource's last modification would indicate some time in the
+ future, the server MUST replace that date with the message
+ origination date.
+
+ An origin server SHOULD obtain the Last-Modified value of the entity
+ as close as possible to the time that it generates the Date value of
+ its response. This allows a recipient to make an accurate assessment
+ of the entity's modification time, especially if the entity changes
+ near the time that the response is generated.
+
+ HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 Location
+
+ The Location response-header field is used to redirect the recipient
+ to a location other than the Request-URI for completion of the
+ request or identification of a new resource. For 201 (Created)
+ responses, the Location is that of the new resource which was created
+ by the request. For 3xx responses, the location SHOULD indicate the
+ server's preferred URI for automatic redirection to the resource. The
+ field value consists of a single absolute URI.
+
+ Location = "Location" ":" absoluteURI
+
+ An example is:
+
+ Location: http://www.w3.org/pub/WWW/People.html
+
+ Note: The Content-Location header field (section 14.14) differs
+ from Location in that the Content-Location identifies the original
+ location of the entity enclosed in the request. It is therefore
+ possible for a response to contain header fields for both Location
+ and Content-Location. Also see section 13.10 for cache
+ requirements of some methods.
+
+
+
+Fielding, et al. Standards Track [Page 135]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.31 Max-Forwards
+
+ The Max-Forwards request-header field provides a mechanism with the
+ TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
+ number of proxies or gateways that can forward the request to the
+ next inbound server. This can be useful when the client is attempting
+ to trace a request chain which appears to be failing or looping in
+ mid-chain.
+
+ Max-Forwards = "Max-Forwards" ":" 1*DIGIT
+
+ The Max-Forwards value is a decimal integer indicating the remaining
+ number of times this request message may be forwarded.
+
+ Each proxy or gateway recipient of a TRACE or OPTIONS request
+ containing a Max-Forwards header field MUST check and update its
+ value prior to forwarding the request. If the received value is zero
+ (0), the recipient MUST NOT forward the request; instead, it MUST
+ respond as the final recipient. If the received Max-Forwards value is
+ greater than zero, then the forwarded message MUST contain an updated
+ Max-Forwards field with a value decremented by one (1).
+
+ The Max-Forwards header field MAY be ignored for all other methods
+ defined by this specification and for any extension methods for which
+ it is not explicitly referred to as part of that method definition.
+
+14.32 Pragma
+
+ The Pragma general-header field is used to include implementation-
+ specific directives that might apply to any recipient along the
+ request/response chain. All pragma directives specify optional
+ behavior from the viewpoint of the protocol; however, some systems
+ MAY require that behavior be consistent with the directives.
+
+ Pragma = "Pragma" ":" 1#pragma-directive
+ pragma-directive = "no-cache" | extension-pragma
+ extension-pragma = token [ "=" ( token | quoted-string ) ]
+
+ When the no-cache directive is present in a request message, an
+ application SHOULD forward the request toward the origin server even
+ if it has a cached copy of what is being requested. This pragma
+ directive has the same semantics as the no-cache cache-directive (see
+ section 14.9) and is defined here for backward compatibility with
+ HTTP/1.0. Clients SHOULD include both header fields when a no-cache
+ request is sent to a server not known to be HTTP/1.1 compliant.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 136]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Pragma directives MUST be passed through by a proxy or gateway
+ application, regardless of their significance to that application,
+ since the directives might be applicable to all recipients along the
+ request/response chain. It is not possible to specify a pragma for a
+ specific recipient; however, any pragma directive not relevant to a
+ recipient SHOULD be ignored by that recipient.
+
+ HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
+ sent "Cache-Control: no-cache". No new Pragma directives will be
+ defined in HTTP.
+
+ Note: because the meaning of "Pragma: no-cache as a response
+ header field is not actually specified, it does not provide a
+ reliable replacement for "Cache-Control: no-cache" in a response
+
+14.33 Proxy-Authenticate
+
+ The Proxy-Authenticate response-header field MUST be included as part
+ of a 407 (Proxy Authentication Required) response. The field value
+ consists of a challenge that indicates the authentication scheme and
+ parameters applicable to the proxy for this Request-URI.
+
+ Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
+
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" [43]. Unlike
+ WWW-Authenticate, the Proxy-Authenticate header field applies only to
+ the current connection and SHOULD NOT be passed on to downstream
+ clients. However, an intermediate proxy might need to obtain its own
+ credentials by requesting them from the downstream client, which in
+ some circumstances will appear as if the proxy is forwarding the
+ Proxy-Authenticate header field.
+
+14.34 Proxy-Authorization
+
+ The Proxy-Authorization request-header field allows the client to
+ identify itself (or its user) to a proxy which requires
+ authentication. The Proxy-Authorization field value consists of
+ credentials containing the authentication information of the user
+ agent for the proxy and/or realm of the resource being requested.
+
+ Proxy-Authorization = "Proxy-Authorization" ":" credentials
+
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" [43] . Unlike
+ Authorization, the Proxy-Authorization header field applies only to
+ the next outbound proxy that demanded authentication using the Proxy-
+ Authenticate field. When multiple proxies are used in a chain, the
+
+
+
+Fielding, et al. Standards Track [Page 137]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Proxy-Authorization header field is consumed by the first outbound
+ proxy that was expecting to receive credentials. A proxy MAY relay
+ the credentials from the client request to the next proxy if that is
+ the mechanism by which the proxies cooperatively authenticate a given
+ request.
+
+14.35 Range
+
+14.35.1 Byte Ranges
+
+ Since all HTTP entities are represented in HTTP messages as sequences
+ of bytes, the concept of a byte range is meaningful for any HTTP
+ entity. (However, not all clients and servers need to support byte-
+ range operations.)
+
+ Byte range specifications in HTTP apply to the sequence of bytes in
+ the entity-body (not necessarily the same as the message-body).
+
+ A byte range operation MAY specify a single range of bytes, or a set
+ of ranges within a single entity.
+
+ ranges-specifier = byte-ranges-specifier
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+ byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
+ byte-range-spec = first-byte-pos "-" [last-byte-pos]
+ first-byte-pos = 1*DIGIT
+ last-byte-pos = 1*DIGIT
+
+ The first-byte-pos value in a byte-range-spec gives the byte-offset
+ of the first byte in a range. The last-byte-pos value gives the
+ byte-offset of the last byte in the range; that is, the byte
+ positions specified are inclusive. Byte offsets start at zero.
+
+ If the last-byte-pos value is present, it MUST be greater than or
+ equal to the first-byte-pos in that byte-range-spec, or the byte-
+ range-spec is syntactically invalid. The recipient of a byte-range-
+ set that includes one or more syntactically invalid byte-range-spec
+ values MUST ignore the header field that includes that byte-range-
+ set.
+
+ If the last-byte-pos value is absent, or if the value is greater than
+ or equal to the current length of the entity-body, last-byte-pos is
+ taken to be equal to one less than the current length of the entity-
+ body in bytes.
+
+ By its choice of last-byte-pos, a client can limit the number of
+ bytes retrieved without knowing the size of the entity.
+
+
+
+
+Fielding, et al. Standards Track [Page 138]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ suffix-byte-range-spec = "-" suffix-length
+ suffix-length = 1*DIGIT
+
+ A suffix-byte-range-spec is used to specify the suffix of the
+ entity-body, of a length given by the suffix-length value. (That is,
+ this form specifies the last N bytes of an entity-body.) If the
+ entity is shorter than the specified suffix-length, the entire
+ entity-body is used.
+
+ If a syntactically valid byte-range-set includes at least one byte-
+ range-spec whose first-byte-pos is less than the current length of
+ the entity-body, or at least one suffix-byte-range-spec with a non-
+ zero suffix-length, then the byte-range-set is satisfiable.
+ Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
+ is unsatisfiable, the server SHOULD return a response with a status
+ of 416 (Requested range not satisfiable). Otherwise, the server
+ SHOULD return a response with a status of 206 (Partial Content)
+ containing the satisfiable ranges of the entity-body.
+
+ Examples of byte-ranges-specifier values (assuming an entity-body of
+ length 10000):
+
+ - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
+ 499
+
+ - The second 500 bytes (byte offsets 500-999, inclusive):
+ bytes=500-999
+
+ - The final 500 bytes (byte offsets 9500-9999, inclusive):
+ bytes=-500
+
+ - Or bytes=9500-
+
+ - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
+
+ - Several legal but not canonical specifications of the second 500
+ bytes (byte offsets 500-999, inclusive):
+ bytes=500-600,601-999
+ bytes=500-700,601-999
+
+14.35.2 Range Retrieval Requests
+
+ HTTP retrieval requests using conditional or unconditional GET
+ methods MAY request one or more sub-ranges of the entity, instead of
+ the entire entity, using the Range request header, which applies to
+ the entity returned as the result of the request:
+
+ Range = "Range" ":" ranges-specifier
+
+
+
+Fielding, et al. Standards Track [Page 139]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ A server MAY ignore the Range header. However, HTTP/1.1 origin
+ servers and intermediate caches ought to support byte ranges when
+ possible, since Range supports efficient recovery from partially
+ failed transfers, and supports efficient partial retrieval of large
+ entities.
+
+ If the server supports the Range header and the specified range or
+ ranges are appropriate for the entity:
+
+ - The presence of a Range header in an unconditional GET modifies
+ what is returned if the GET is otherwise successful. In other
+ words, the response carries a status code of 206 (Partial
+ Content) instead of 200 (OK).
+
+ - The presence of a Range header in a conditional GET (a request
+ using one or both of If-Modified-Since and If-None-Match, or
+ one or both of If-Unmodified-Since and If-Match) modifies what
+ is returned if the GET is otherwise successful and the
+ condition is true. It does not affect the 304 (Not Modified)
+ response returned if the conditional is false.
+
+ In some cases, it might be more appropriate to use the If-Range
+ header (see section 14.27) in addition to the Range header.
+
+ If a proxy that supports ranges receives a Range request, forwards
+ the request to an inbound server, and receives an entire entity in
+ reply, it SHOULD only return the requested range to its client. It
+ SHOULD store the entire received response in its cache if that is
+ consistent with its cache allocation policies.
+
+14.36 Referer
+
+ The Referer[sic] request-header field allows the client to specify,
+ for the server's benefit, the address (URI) of the resource from
+ which the Request-URI was obtained (the "referrer", although the
+ header field is misspelled.) The Referer request-header allows a
+ server to generate lists of back-links to resources for interest,
+ logging, optimized caching, etc. It also allows obsolete or mistyped
+ links to be traced for maintenance. The Referer field MUST NOT be
+ sent if the Request-URI was obtained from a source that does not have
+ its own URI, such as input from the user keyboard.
+
+ Referer = "Referer" ":" ( absoluteURI | relativeURI )
+
+ Example:
+
+ Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+
+
+
+Fielding, et al. Standards Track [Page 140]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If the field value is a relative URI, it SHOULD be interpreted
+ relative to the Request-URI. The URI MUST NOT include a fragment. See
+ section 15.1.3 for security considerations.
+
+14.37 Retry-After
+
+ The Retry-After response-header field can be used with a 503 (Service
+ Unavailable) response to indicate how long the service is expected to
+ be unavailable to the requesting client. This field MAY also be used
+ with any 3xx (Redirection) response to indicate the minimum time the
+ user-agent is asked wait before issuing the redirected request. The
+ value of this field can be either an HTTP-date or an integer number
+ of seconds (in decimal) after the time of the response.
+
+ Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+ Two examples of its use are
+
+ Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+ Retry-After: 120
+
+ In the latter example, the delay is 2 minutes.
+
+14.38 Server
+
+ The Server response-header field contains information about the
+ software used by the origin server to handle the request. The field
+ can contain multiple product tokens (section 3.8) and comments
+ identifying the server and any significant subproducts. The product
+ tokens are listed in order of their significance for identifying the
+ application.
+
+ Server = "Server" ":" 1*( product | comment )
+
+ Example:
+
+ Server: CERN/3.0 libwww/2.17
+
+ If the response is being forwarded through a proxy, the proxy
+ application MUST NOT modify the Server response-header. Instead, it
+ SHOULD include a Via field (as described in section 14.45).
+
+ Note: Revealing the specific software version of the server might
+ allow the server machine to become more vulnerable to attacks
+ against software that is known to contain security holes. Server
+ implementors are encouraged to make this field a configurable
+ option.
+
+
+
+
+Fielding, et al. Standards Track [Page 141]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+14.39 TE
+
+ The TE request-header field indicates what extension transfer-codings
+ it is willing to accept in the response and whether or not it is
+ willing to accept trailer fields in a chunked transfer-coding. Its
+ value may consist of the keyword "trailers" and/or a comma-separated
+ list of extension transfer-coding names with optional accept
+ parameters (as described in section 3.6).
+
+ TE = "TE" ":" #( t-codings )
+ t-codings = "trailers" | ( transfer-extension [ accept-params ] )
+
+ The presence of the keyword "trailers" indicates that the client is
+ willing to accept trailer fields in a chunked transfer-coding, as
+ defined in section 3.6.1. This keyword is reserved for use with
+ transfer-coding values even though it does not itself represent a
+ transfer-coding.
+
+ Examples of its use are:
+
+ TE: deflate
+ TE:
+ TE: trailers, deflate;q=0.5
+
+ The TE header field only applies to the immediate connection.
+ Therefore, the keyword MUST be supplied within a Connection header
+ field (section 14.10) whenever TE is present in an HTTP/1.1 message.
+
+ A server tests whether a transfer-coding is acceptable, according to
+ a TE field, using these rules:
+
+ 1. The "chunked" transfer-coding is always acceptable. If the
+ keyword "trailers" is listed, the client indicates that it is
+ willing to accept trailer fields in the chunked response on
+ behalf of itself and any downstream clients. The implication is
+ that, if given, the client is stating that either all
+ downstream clients are willing to accept trailer fields in the
+ forwarded response, or that it will attempt to buffer the
+ response on behalf of downstream recipients.
+
+ Note: HTTP/1.1 does not define any means to limit the size of a
+ chunked response such that a client can be assured of buffering
+ the entire response.
+
+ 2. If the transfer-coding being tested is one of the transfer-
+ codings listed in the TE field, then it is acceptable unless it
+ is accompanied by a qvalue of 0. (As defined in section 3.9, a
+ qvalue of 0 means "not acceptable.")
+
+
+
+Fielding, et al. Standards Track [Page 142]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 3. If multiple transfer-codings are acceptable, then the
+ acceptable transfer-coding with the highest non-zero qvalue is
+ preferred. The "chunked" transfer-coding always has a qvalue
+ of 1.
+
+ If the TE field-value is empty or if no TE field is present, the only
+ transfer-coding is "chunked". A message with no transfer-coding is
+ always acceptable.
+
+14.40 Trailer
+
+ The Trailer general field value indicates that the given set of
+ header fields is present in the trailer of a message encoded with
+ chunked transfer-coding.
+
+ Trailer = "Trailer" ":" 1#field-name
+
+ An HTTP/1.1 message SHOULD include a Trailer header field in a
+ message using chunked transfer-coding with a non-empty trailer. Doing
+ so allows the recipient to know which header fields to expect in the
+ trailer.
+
+ If no Trailer header field is present, the trailer SHOULD NOT include
+ any header fields. See section 3.6.1 for restrictions on the use of
+ trailer fields in a "chunked" transfer-coding.
+
+ Message header fields listed in the Trailer header field MUST NOT
+ include the following header fields:
+
+ . Transfer-Encoding
+
+ . Content-Length
+
+ . Trailer
+
+14.41 Transfer-Encoding
+
+ The Transfer-Encoding general-header field indicates what (if any)
+ type of transformation has been applied to the message body in order
+ to safely transfer it between the sender and the recipient. This
+ differs from the content-coding in that the transfer-coding is a
+ property of the message, not of the entity.
+
+ Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
+
+ Transfer-codings are defined in section 3.6. An example is:
+
+ Transfer-Encoding: chunked
+
+
+
+Fielding, et al. Standards Track [Page 143]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ If multiple encodings have been applied to an entity, the transfer-
+ codings MUST be listed in the order in which they were applied.
+ Additional information about the encoding parameters MAY be provided
+ by other entity-header fields not defined by this specification.
+
+ Many older HTTP/1.0 applications do not understand the Transfer-
+ Encoding header.
+
+14.42 Upgrade
+
+ The Upgrade general-header allows the client to specify what
+ additional communication protocols it supports and would like to use
+ if the server finds it appropriate to switch protocols. The server
+ MUST use the Upgrade header field within a 101 (Switching Protocols)
+ response to indicate which protocol(s) are being switched.
+
+ Upgrade = "Upgrade" ":" 1#product
+
+ For example,
+
+ Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+ The Upgrade header field is intended to provide a simple mechanism
+ for transition from HTTP/1.1 to some other, incompatible protocol. It
+ does so by allowing the client to advertise its desire to use another
+ protocol, such as a later version of HTTP with a higher major version
+ number, even though the current request has been made using HTTP/1.1.
+ This eases the difficult transition between incompatible protocols by
+ allowing the client to initiate a request in the more commonly
+ supported protocol while indicating to the server that it would like
+ to use a "better" protocol if available (where "better" is determined
+ by the server, possibly according to the nature of the method and/or
+ resource being requested).
+
+ The Upgrade header field only applies to switching application-layer
+ protocols upon the existing transport-layer connection. Upgrade
+ cannot be used to insist on a protocol change; its acceptance and use
+ by the server is optional. The capabilities and nature of the
+ application-layer communication after the protocol change is entirely
+ dependent upon the new protocol chosen, although the first action
+ after changing the protocol MUST be a response to the initial HTTP
+ request containing the Upgrade header field.
+
+ The Upgrade header field only applies to the immediate connection.
+ Therefore, the upgrade keyword MUST be supplied within a Connection
+ header field (section 14.10) whenever Upgrade is present in an
+ HTTP/1.1 message.
+
+
+
+
+Fielding, et al. Standards Track [Page 144]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The Upgrade header field cannot be used to indicate a switch to a
+ protocol on a different connection. For that purpose, it is more
+ appropriate to use a 301, 302, 303, or 305 redirection response.
+
+ This specification only defines the protocol name "HTTP" for use by
+ the family of Hypertext Transfer Protocols, as defined by the HTTP
+ version rules of section 3.1 and future updates to this
+ specification. Any token can be used as a protocol name; however, it
+ will only be useful if both the client and server associate the name
+ with the same protocol.
+
+14.43 User-Agent
+
+ The User-Agent request-header field contains information about the
+ user agent originating the request. This is for statistical purposes,
+ the tracing of protocol violations, and automated recognition of user
+ agents for the sake of tailoring responses to avoid particular user
+ agent limitations. User agents SHOULD include this field with
+ requests. The field can contain multiple product tokens (section 3.8)
+ and comments identifying the agent and any subproducts which form a
+ significant part of the user agent. By convention, the product tokens
+ are listed in order of their significance for identifying the
+ application.
+
+ User-Agent = "User-Agent" ":" 1*( product | comment )
+
+ Example:
+
+ User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+14.44 Vary
+
+ The Vary field value indicates the set of request-header fields that
+ fully determines, while the response is fresh, whether a cache is
+ permitted to use the response to reply to a subsequent request
+ without revalidation. For uncacheable or stale responses, the Vary
+ field value advises the user agent about the criteria that were used
+ to select the representation. A Vary field value of "*" implies that
+ a cache cannot determine from the request headers of a subsequent
+ request whether this response is the appropriate representation. See
+ section 13.6 for use of the Vary header field by caches.
+
+ Vary = "Vary" ":" ( "*" | 1#field-name )
+
+ An HTTP/1.1 server SHOULD include a Vary header field with any
+ cacheable response that is subject to server-driven negotiation.
+ Doing so allows a cache to properly interpret future requests on that
+ resource and informs the user agent about the presence of negotiation
+
+
+
+Fielding, et al. Standards Track [Page 145]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ on that resource. A server MAY include a Vary header field with a
+ non-cacheable response that is subject to server-driven negotiation,
+ since this might provide the user agent with useful information about
+ the dimensions over which the response varies at the time of the
+ response.
+
+ A Vary field value consisting of a list of field-names signals that
+ the representation selected for the response is based on a selection
+ algorithm which considers ONLY the listed request-header field values
+ in selecting the most appropriate representation. A cache MAY assume
+ that the same selection will be made for future requests with the
+ same values for the listed field names, for the duration of time for
+ which the response is fresh.
+
+ The field-names given are not limited to the set of standard
+ request-header fields defined by this specification. Field names are
+ case-insensitive.
+
+ A Vary field value of "*" signals that unspecified parameters not
+ limited to the request-headers (e.g., the network address of the
+ client), play a role in the selection of the response representation.
+ The "*" value MUST NOT be generated by a proxy server; it may only be
+ generated by an origin server.
+
+14.45 Via
+
+ The Via general-header field MUST be used by gateways and proxies to
+ indicate the intermediate protocols and recipients between the user
+ agent and the server on requests, and between the origin server and
+ the client on responses. It is analogous to the "Received" field of
+ RFC 822 [9] and is intended to be used for tracking message forwards,
+ avoiding request loops, and identifying the protocol capabilities of
+ all senders along the request/response chain.
+
+ Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
+ received-protocol = [ protocol-name "/" ] protocol-version
+ protocol-name = token
+ protocol-version = token
+ received-by = ( host [ ":" port ] ) | pseudonym
+ pseudonym = token
+
+ The received-protocol indicates the protocol version of the message
+ received by the server or client along each segment of the
+ request/response chain. The received-protocol version is appended to
+ the Via field value when the message is forwarded so that information
+ about the protocol capabilities of upstream applications remains
+ visible to all recipients.
+
+
+
+
+Fielding, et al. Standards Track [Page 146]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The protocol-name is optional if and only if it would be "HTTP". The
+ received-by field is normally the host and optional port number of a
+ recipient server or client that subsequently forwarded the message.
+ However, if the real host is considered to be sensitive information,
+ it MAY be replaced by a pseudonym. If the port is not given, it MAY
+ be assumed to be the default port of the received-protocol.
+
+ Multiple Via field values represents each proxy or gateway that has
+ forwarded the message. Each recipient MUST append its information
+ such that the end result is ordered according to the sequence of
+ forwarding applications.
+
+ Comments MAY be used in the Via header field to identify the software
+ of the recipient proxy or gateway, analogous to the User-Agent and
+ Server header fields. However, all comments in the Via field are
+ optional and MAY be removed by any recipient prior to forwarding the
+ message.
+
+ For example, a request message could be sent from an HTTP/1.0 user
+ agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
+ forward the request to a public proxy at nowhere.com, which completes
+ the request by forwarding it to the origin server at www.ics.uci.edu.
+ The request received by www.ics.uci.edu would then have the following
+ Via header field:
+
+ Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+ Proxies and gateways used as a portal through a network firewall
+ SHOULD NOT, by default, forward the names and ports of hosts within
+ the firewall region. This information SHOULD only be propagated if
+ explicitly enabled. If not enabled, the received-by host of any host
+ behind the firewall SHOULD be replaced by an appropriate pseudonym
+ for that host.
+
+ For organizations that have strong privacy requirements for hiding
+ internal structures, a proxy MAY combine an ordered subsequence of
+ Via header field entries with identical received-protocol values into
+ a single such entry. For example,
+
+ Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+ could be collapsed to
+
+ Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 147]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Applications SHOULD NOT combine multiple entries unless they are all
+ under the same organizational control and the hosts have already been
+ replaced by pseudonyms. Applications MUST NOT combine entries which
+ have different received-protocol values.
+
+14.46 Warning
+
+ The Warning general-header field is used to carry additional
+ information about the status or transformation of a message which
+ might not be reflected in the message. This information is typically
+ used to warn about a possible lack of semantic transparency from
+ caching operations or transformations applied to the entity body of
+ the message.
+
+ Warning headers are sent with responses using:
+
+ Warning = "Warning" ":" 1#warning-value
+
+ warning-value = warn-code SP warn-agent SP warn-text
+ [SP warn-date]
+
+ warn-code = 3DIGIT
+ warn-agent = ( host [ ":" port ] ) | pseudonym
+ ; the name or pseudonym of the server adding
+ ; the Warning header, for use in debugging
+ warn-text = quoted-string
+ warn-date = <"> HTTP-date <">
+
+ A response MAY carry more than one Warning header.
+
+ The warn-text SHOULD be in a natural language and character set that
+ is most likely to be intelligible to the human user receiving the
+ response. This decision MAY be based on any available knowledge, such
+ as the location of the cache or user, the Accept-Language field in a
+ request, the Content-Language field in a response, etc. The default
+ language is English and the default character set is ISO-8859-1.
+
+ If a character set other than ISO-8859-1 is used, it MUST be encoded
+ in the warn-text using the method described in RFC 2047 [14].
+
+ Warning headers can in general be applied to any message, however
+ some specific warn-codes are specific to caches and can only be
+ applied to response messages. New Warning headers SHOULD be added
+ after any existing Warning headers. A cache MUST NOT delete any
+ Warning header that it received with a message. However, if a cache
+ successfully validates a cache entry, it SHOULD remove any Warning
+ headers previously attached to that entry except as specified for
+
+
+
+
+Fielding, et al. Standards Track [Page 148]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ specific Warning codes. It MUST then add any Warning headers received
+ in the validating response. In other words, Warning headers are those
+ that would be attached to the most recent relevant response.
+
+ When multiple Warning headers are attached to a response, the user
+ agent ought to inform the user of as many of them as possible, in the
+ order that they appear in the response. If it is not possible to
+ inform the user of all of the warnings, the user agent SHOULD follow
+ these heuristics:
+
+ - Warnings that appear early in the response take priority over
+ those appearing later in the response.
+
+ - Warnings in the user's preferred character set take priority
+ over warnings in other character sets but with identical warn-
+ codes and warn-agents.
+
+ Systems that generate multiple Warning headers SHOULD order them with
+ this user agent behavior in mind.
+
+ Requirements for the behavior of caches with respect to Warnings are
+ stated in section 13.1.2.
+
+ This is a list of the currently-defined warn-codes, each with a
+ recommended warn-text in English, and a description of its meaning.
+
+ 110 Response is stale
+ MUST be included whenever the returned response is stale.
+
+ 111 Revalidation failed
+ MUST be included if a cache returns a stale response because an
+ attempt to revalidate the response failed, due to an inability to
+ reach the server.
+
+ 112 Disconnected operation
+ SHOULD be included if the cache is intentionally disconnected from
+ the rest of the network for a period of time.
+
+ 113 Heuristic expiration
+ MUST be included if the cache heuristically chose a freshness
+ lifetime greater than 24 hours and the response's age is greater
+ than 24 hours.
+
+ 199 Miscellaneous warning
+ The warning text MAY include arbitrary information to be presented
+ to a human user, or logged. A system receiving this warning MUST
+ NOT take any automated action, besides presenting the warning to
+ the user.
+
+
+
+Fielding, et al. Standards Track [Page 149]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 214 Transformation applied
+ MUST be added by an intermediate cache or proxy if it applies any
+ transformation changing the content-coding (as specified in the
+ Content-Encoding header) or media-type (as specified in the
+ Content-Type header) of the response, or the entity-body of the
+ response, unless this Warning code already appears in the response.
+
+ 299 Miscellaneous persistent warning
+ The warning text MAY include arbitrary information to be presented
+ to a human user, or logged. A system receiving this warning MUST
+ NOT take any automated action.
+
+ If an implementation sends a message with one or more Warning headers
+ whose version is HTTP/1.0 or lower, then the sender MUST include in
+ each warning-value a warn-date that matches the date in the response.
+
+ If an implementation receives a message with a warning-value that
+ includes a warn-date, and that warn-date is different from the Date
+ value in the response, then that warning-value MUST be deleted from
+ the message before storing, forwarding, or using it. (This prevents
+ bad consequences of naive caching of Warning header fields.) If all
+ of the warning-values are deleted for this reason, the Warning header
+ MUST be deleted as well.
+
+14.47 WWW-Authenticate
+
+ The WWW-Authenticate response-header field MUST be included in 401
+ (Unauthorized) response messages. The field value consists of at
+ least one challenge that indicates the authentication scheme(s) and
+ parameters applicable to the Request-URI.
+
+ WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
+
+ The HTTP access authentication process is described in "HTTP
+ Authentication: Basic and Digest Access Authentication" [43]. User
+ agents are advised to take special care in parsing the WWW-
+ Authenticate field value as it might contain more than one challenge,
+ or if more than one WWW-Authenticate header field is provided, the
+ contents of a challenge itself can contain a comma-separated list of
+ authentication parameters.
+
+15 Security Considerations
+
+ This section is meant to inform application developers, information
+ providers, and users of the security limitations in HTTP/1.1 as
+ described by this document. The discussion does not include
+ definitive solutions to the problems revealed, though it does make
+ some suggestions for reducing security risks.
+
+
+
+Fielding, et al. Standards Track [Page 150]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+15.1 Personal Information
+
+ HTTP clients are often privy to large amounts of personal information
+ (e.g. the user's name, location, mail address, passwords, encryption
+ keys, etc.), and SHOULD be very careful to prevent unintentional
+ leakage of this information via the HTTP protocol to other sources.
+ We very strongly recommend that a convenient interface be provided
+ for the user to control dissemination of such information, and that
+ designers and implementors be particularly careful in this area.
+ History shows that errors in this area often create serious security
+ and/or privacy problems and generate highly adverse publicity for the
+ implementor's company.
+
+15.1.1 Abuse of Server Log Information
+
+ A server is in the position to save personal data about a user's
+ requests which might identify their reading patterns or subjects of
+ interest. This information is clearly confidential in nature and its
+ handling can be constrained by law in certain countries. People using
+ the HTTP protocol to provide data are responsible for ensuring that
+ such material is not distributed without the permission of any
+ individuals that are identifiable by the published results.
+
+15.1.2 Transfer of Sensitive Information
+
+ Like any generic data transfer protocol, HTTP cannot regulate the
+ content of the data that is transferred, nor is there any a priori
+ method of determining the sensitivity of any particular piece of
+ information within the context of any given request. Therefore,
+ applications SHOULD supply as much control over this information as
+ possible to the provider of that information. Four header fields are
+ worth special mention in this context: Server, Via, Referer and From.
+
+ Revealing the specific software version of the server might allow the
+ server machine to become more vulnerable to attacks against software
+ that is known to contain security holes. Implementors SHOULD make the
+ Server header field a configurable option.
+
+ Proxies which serve as a portal through a network firewall SHOULD
+ take special precautions regarding the transfer of header information
+ that identifies the hosts behind the firewall. In particular, they
+ SHOULD remove, or replace with sanitized versions, any Via fields
+ generated behind the firewall.
+
+ The Referer header allows reading patterns to be studied and reverse
+ links drawn. Although it can be very useful, its power can be abused
+ if user details are not separated from the information contained in
+
+
+
+
+Fielding, et al. Standards Track [Page 151]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ the Referer. Even when the personal information has been removed, the
+ Referer header might indicate a private document's URI whose
+ publication would be inappropriate.
+
+ The information sent in the From field might conflict with the user's
+ privacy interests or their site's security policy, and hence it
+ SHOULD NOT be transmitted without the user being able to disable,
+ enable, and modify the contents of the field. The user MUST be able
+ to set the contents of this field within a user preference or
+ application defaults configuration.
+
+ We suggest, though do not require, that a convenient toggle interface
+ be provided for the user to enable or disable the sending of From and
+ Referer information.
+
+ The User-Agent (section 14.43) or Server (section 14.38) header
+ fields can sometimes be used to determine that a specific client or
+ server have a particular security hole which might be exploited.
+ Unfortunately, this same information is often used for other valuable
+ purposes for which HTTP currently has no better mechanism.
+
+15.1.3 Encoding Sensitive Information in URI's
+
+ Because the source of a link might be private information or might
+ reveal an otherwise private information source, it is strongly
+ recommended that the user be able to select whether or not the
+ Referer field is sent. For example, a browser client could have a
+ toggle switch for browsing openly/anonymously, which would
+ respectively enable/disable the sending of Referer and From
+ information.
+
+ Clients SHOULD NOT include a Referer header field in a (non-secure)
+ HTTP request if the referring page was transferred with a secure
+ protocol.
+
+ Authors of services which use the HTTP protocol SHOULD NOT use GET
+ based forms for the submission of sensitive data, because this will
+ cause this data to be encoded in the Request-URI. Many existing
+ servers, proxies, and user agents will log the request URI in some
+ place where it might be visible to third parties. Servers can use
+ POST-based form submission instead
+
+15.1.4 Privacy Issues Connected to Accept Headers
+
+ Accept request-headers can reveal information about the user to all
+ servers which are accessed. The Accept-Language header in particular
+ can reveal information the user would consider to be of a private
+ nature, because the understanding of particular languages is often
+
+
+
+Fielding, et al. Standards Track [Page 152]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ strongly correlated to the membership of a particular ethnic group.
+ User agents which offer the option to configure the contents of an
+ Accept-Language header to be sent in every request are strongly
+ encouraged to let the configuration process include a message which
+ makes the user aware of the loss of privacy involved.
+
+ An approach that limits the loss of privacy would be for a user agent
+ to omit the sending of Accept-Language headers by default, and to ask
+ the user whether or not to start sending Accept-Language headers to a
+ server if it detects, by looking for any Vary response-header fields
+ generated by the server, that such sending could improve the quality
+ of service.
+
+ Elaborate user-customized accept header fields sent in every request,
+ in particular if these include quality values, can be used by servers
+ as relatively reliable and long-lived user identifiers. Such user
+ identifiers would allow content providers to do click-trail tracking,
+ and would allow collaborating content providers to match cross-server
+ click-trails or form submissions of individual users. Note that for
+ many users not behind a proxy, the network address of the host
+ running the user agent will also serve as a long-lived user
+ identifier. In environments where proxies are used to enhance
+ privacy, user agents ought to be conservative in offering accept
+ header configuration options to end users. As an extreme privacy
+ measure, proxies could filter the accept headers in relayed requests.
+ General purpose user agents which provide a high degree of header
+ configurability SHOULD warn users about the loss of privacy which can
+ be involved.
+
+15.2 Attacks Based On File and Path Names
+
+ Implementations of HTTP origin servers SHOULD be careful to restrict
+ the documents returned by HTTP requests to be only those that were
+ intended by the server administrators. If an HTTP server translates
+ HTTP URIs directly into file system calls, the server MUST take
+ special care not to serve files that were not intended to be
+ delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
+ other operating systems use ".." as a path component to indicate a
+ directory level above the current one. On such a system, an HTTP
+ server MUST disallow any such construct in the Request-URI if it
+ would otherwise allow access to a resource outside those intended to
+ be accessible via the HTTP server. Similarly, files intended for
+ reference only internally to the server (such as access control
+ files, configuration files, and script code) MUST be protected from
+ inappropriate retrieval, since they might contain sensitive
+ information. Experience has shown that minor bugs in such HTTP server
+ implementations have turned into security risks.
+
+
+
+
+Fielding, et al. Standards Track [Page 153]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+15.3 DNS Spoofing
+
+ Clients using HTTP rely heavily on the Domain Name Service, and are
+ thus generally prone to security attacks based on the deliberate
+ mis-association of IP addresses and DNS names. Clients need to be
+ cautious in assuming the continuing validity of an IP number/DNS name
+ association.
+
+ In particular, HTTP clients SHOULD rely on their name resolver for
+ confirmation of an IP number/DNS name association, rather than
+ caching the result of previous host name lookups. Many platforms
+ already can cache host name lookups locally when appropriate, and
+ they SHOULD be configured to do so. It is proper for these lookups to
+ be cached, however, only when the TTL (Time To Live) information
+ reported by the name server makes it likely that the cached
+ information will remain useful.
+
+ If HTTP clients cache the results of host name lookups in order to
+ achieve a performance improvement, they MUST observe the TTL
+ information reported by DNS.
+
+ If HTTP clients do not observe this rule, they could be spoofed when
+ a previously-accessed server's IP address changes. As network
+ renumbering is expected to become increasingly common [24], the
+ possibility of this form of attack will grow. Observing this
+ requirement thus reduces this potential security vulnerability.
+
+ This requirement also improves the load-balancing behavior of clients
+ for replicated servers using the same DNS name and reduces the
+ likelihood of a user's experiencing failure in accessing sites which
+ use that strategy.
+
+15.4 Location Headers and Spoofing
+
+ If a single server supports multiple organizations that do not trust
+ one another, then it MUST check the values of Location and Content-
+ Location headers in responses that are generated under control of
+ said organizations to make sure that they do not attempt to
+ invalidate resources over which they have no authority.
+
+15.5 Content-Disposition Issues
+
+ RFC 1806 [35], from which the often implemented Content-Disposition
+ (see section 19.5.1) header in HTTP is derived, has a number of very
+ serious security considerations. Content-Disposition is not part of
+ the HTTP standard, but since it is widely implemented, we are
+ documenting its use and risks for implementors. See RFC 2183 [49]
+ (which updates RFC 1806) for details.
+
+
+
+Fielding, et al. Standards Track [Page 154]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+15.6 Authentication Credentials and Idle Clients
+
+ Existing HTTP clients and user agents typically retain authentication
+ information indefinitely. HTTP/1.1. does not provide a method for a
+ server to direct clients to discard these cached credentials. This is
+ a significant defect that requires further extensions to HTTP.
+ Circumstances under which credential caching can interfere with the
+ application's security model include but are not limited to:
+
+ - Clients which have been idle for an extended period following
+ which the server might wish to cause the client to reprompt the
+ user for credentials.
+
+ - Applications which include a session termination indication
+ (such as a `logout' or `commit' button on a page) after which
+ the server side of the application `knows' that there is no
+ further reason for the client to retain the credentials.
+
+ This is currently under separate study. There are a number of work-
+ arounds to parts of this problem, and we encourage the use of
+ password protection in screen savers, idle time-outs, and other
+ methods which mitigate the security problems inherent in this
+ problem. In particular, user agents which cache credentials are
+ encouraged to provide a readily accessible mechanism for discarding
+ cached credentials under user control.
+
+15.7 Proxies and Caching
+
+ By their very nature, HTTP proxies are men-in-the-middle, and
+ represent an opportunity for man-in-the-middle attacks. Compromise of
+ the systems on which the proxies run can result in serious security
+ and privacy problems. Proxies have access to security-related
+ information, personal information about individual users and
+ organizations, and proprietary information belonging to users and
+ content providers. A compromised proxy, or a proxy implemented or
+ configured without regard to security and privacy considerations,
+ might be used in the commission of a wide range of potential attacks.
+
+ Proxy operators should protect the systems on which proxies run as
+ they would protect any system that contains or transports sensitive
+ information. In particular, log information gathered at proxies often
+ contains highly sensitive personal information, and/or information
+ about organizations. Log information should be carefully guarded, and
+ appropriate guidelines for use developed and followed. (Section
+ 15.1.1).
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 155]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Caching proxies provide additional potential vulnerabilities, since
+ the contents of the cache represent an attractive target for
+ malicious exploitation. Because cache contents persist after an HTTP
+ request is complete, an attack on the cache can reveal information
+ long after a user believes that the information has been removed from
+ the network. Therefore, cache contents should be protected as
+ sensitive information.
+
+ Proxy implementors should consider the privacy and security
+ implications of their design and coding decisions, and of the
+ configuration options they provide to proxy operators (especially the
+ default configuration).
+
+ Users of a proxy need to be aware that they are no trustworthier than
+ the people who run the proxy; HTTP itself cannot solve this problem.
+
+ The judicious use of cryptography, when appropriate, may suffice to
+ protect against a broad range of security and privacy attacks. Such
+ cryptography is beyond the scope of the HTTP/1.1 specification.
+
+15.7.1 Denial of Service Attacks on Proxies
+
+ They exist. They are hard to defend against. Research continues.
+ Beware.
+
+16 Acknowledgments
+
+ This specification makes heavy use of the augmented BNF and generic
+ constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
+ reuses many of the definitions provided by Nathaniel Borenstein and
+ Ned Freed for MIME [7]. We hope that their inclusion in this
+ specification will help reduce past confusion over the relationship
+ between HTTP and Internet mail message formats.
+
+ The HTTP protocol has evolved considerably over the years. It has
+ benefited from a large and active developer community--the many
+ people who have participated on the www-talk mailing list--and it is
+ that community which has been most responsible for the success of
+ HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
+ Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
+ Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
+ McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
+ VanHeyningen deserve special recognition for their efforts in
+ defining early aspects of the protocol.
+
+ This document has benefited greatly from the comments of all those
+ participating in the HTTP-WG. In addition to those already mentioned,
+ the following individuals have contributed to this specification:
+
+
+
+Fielding, et al. Standards Track [Page 156]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Gary Adams Ross Patterson
+ Harald Tveit Alvestrand Albert Lunde
+ Keith Ball John C. Mallery
+ Brian Behlendorf Jean-Philippe Martin-Flatin
+ Paul Burchard Mitra
+ Maurizio Codogno David Morris
+ Mike Cowlishaw Gavin Nicol
+ Roman Czyborra Bill Perry
+ Michael A. Dolan Jeffrey Perry
+ David J. Fiander Scott Powers
+ Alan Freier Owen Rees
+ Marc Hedlund Luigi Rizzo
+ Greg Herlihy David Robinson
+ Koen Holtman Marc Salomon
+ Alex Hopmann Rich Salz
+ Bob Jernigan Allan M. Schiffman
+ Shel Kaphan Jim Seidman
+ Rohit Khare Chuck Shotton
+ John Klensin Eric W. Sink
+ Martijn Koster Simon E. Spero
+ Alexei Kosut Richard N. Taylor
+ David M. Kristol Robert S. Thau
+ Daniel LaLiberte Bill (BearHeart) Weinman
+ Ben Laurie Francois Yergeau
+ Paul J. Leach Mary Ellen Zurko
+ Daniel DuBois Josh Cohen
+
+
+ Much of the content and presentation of the caching design is due to
+ suggestions and comments from individuals including: Shel Kaphan,
+ Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+ Most of the specification of ranges is based on work originally done
+ by Ari Luotonen and John Franks, with additional input from Steve
+ Zilles.
+
+ Thanks to the "cave men" of Palo Alto. You know who you are.
+
+ Jim Gettys (the current editor of this document) wishes particularly
+ to thank Roy Fielding, the previous editor of this document, along
+ with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+ Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
+ Larry Masinter for their help. And thanks go particularly to Jeff
+ Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 157]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
+ Frystyk implemented RFC 2068 early, and we wish to thank them for the
+ discovery of many of the problems that this document attempts to
+ rectify.
+
+17 References
+
+ [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
+ 1766, March 1995.
+
+ [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+ D. and B. Alberti, "The Internet Gopher Protocol (a distributed
+ document search and retrieval protocol)", RFC 1436, March 1993.
+
+ [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
+ 1630, June 1994.
+
+ [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, December 1994.
+
+ [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
+ 2.0", RFC 1866, November 1995.
+
+ [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
+ Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+ [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [8] Braden, R., "Requirements for Internet Hosts -- Communication
+ Layers", STD 3, RFC 1123, October 1989.
+
+ [9] Crocker, D., "Standard for The Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+ Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
+ Functional Specification," (v1.5), Thinking Machines
+ Corporation, April 1990.
+
+ [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
+ June 1995.
+
+ [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
+ Messages", RFC 1036, December 1987.
+
+
+
+
+
+Fielding, et al. Standards Track [Page 158]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
+ 977, February 1986.
+
+ [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+ Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+ November 1996.
+
+ [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
+ 1867, November 1995.
+
+ [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ August 1982.
+
+ [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
+ November 1996.
+
+ [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
+ 959, October 1985.
+
+ [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ October 1994.
+
+ [20] Sollins, K. and L. Masinter, "Functional Requirements for
+ Uniform Resource Names", RFC 1737, December 1994.
+
+ [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+ Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+ [22] ISO-8859. International Standard -- Information Processing --
+ 8-bit Single-Byte Coded Graphic Character Sets --
+ Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
+ Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
+ Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
+ Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
+ Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
+ Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
+ Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
+ Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
+ Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
+
+ [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
+ 1864, October 1995.
+
+ [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+ 1900, February 1996.
+
+ [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
+ 1952, May 1996.
+
+
+
+Fielding, et al. Standards Track [Page 159]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
+ Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
+ Dec. 1995. Slightly revised version of paper in Proc. 2nd
+ International WWW Conference '94: Mosaic and the Web, Oct. 1994,
+ which is available at
+ http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
+ ency.html.
+
+ [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
+ Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
+ ISI Research Report ISI/RR-98-463, (original report dated Aug.
+ 1996), USC/Information Sciences Institute, August 1998.
+
+ [28] Mills, D., "Network Time Protocol (Version 3) Specification,
+ Implementation and Analysis", RFC 1305, March 1992.
+
+ [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+ version 1.3", RFC 1951, May 1996.
+
+ [30] S. Spero, "Analysis of HTTP Performance Problems,"
+ http://sunsite.unc.edu/mdma-release/http-prob.html.
+
+ [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+ Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
+ Digest Access Authentication", RFC 2069, January 1997.
+
+ [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [35] Troost, R. and Dorner, S., "Communicating Presentation
+ Information in Internet Messages: The Content-Disposition
+ Header", RFC 1806, June 1995.
+
+ [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
+ Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
+ [jg639]
+
+ [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
+ 1997. [jg640]
+
+
+
+
+
+Fielding, et al. Standards Track [Page 160]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
+ ISO-10646", RFC 2279, January 1998. [jg641]
+
+ [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
+ Lie, H., and C. Lilley. "Network Performance Effects of
+ HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
+ France, September 1997.[jg642]
+
+ [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996. [jg643]
+
+ [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+ BCP 18, RFC 2277, January 1998. [jg644]
+
+ [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
+ August 1998. [jg645]
+
+ [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+ Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication", RFC
+ 2617, June 1999. [jg646]
+
+ [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
+ servers," Work in Progress. [jg647]
+
+ [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
+ Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
+ 1997.
+
+ [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
+ (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+ [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Five: Conformance Criteria and Examples",
+ RFC 2049, November 1996.
+
+ [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
+ Information in Internet Messages: The Content-Disposition Header
+ Field", RFC 2183, August 1997.
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 161]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+18 Authors' Addresses
+
+ Roy T. Fielding
+ Information and Computer Science
+ University of California, Irvine
+ Irvine, CA 92697-3425, USA
+
+ Fax: +1 (949) 824-1715
+ EMail: fielding@ics.uci.edu
+
+
+ James Gettys
+ World Wide Web Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: jg@w3.org
+
+
+ Jeffrey C. Mogul
+ Western Research Laboratory
+ Compaq Computer Corporation
+ 250 University Avenue
+ Palo Alto, California, 94305, USA
+
+ EMail: mogul@wrl.dec.com
+
+
+ Henrik Frystyk Nielsen
+ World Wide Web Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: frystyk@w3.org
+
+
+ Larry Masinter
+ Xerox Corporation
+ 3333 Coyote Hill Road
+ Palo Alto, CA 94034, USA
+
+ EMail: masinter@parc.xerox.com
+
+
+
+
+
+Fielding, et al. Standards Track [Page 162]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052, USA
+
+ EMail: paulle@microsoft.com
+
+
+ Tim Berners-Lee
+ Director, World Wide Web Consortium
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139, USA
+
+ Fax: +1 (617) 258 8682
+ EMail: timbl@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 163]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http and application/http
+
+ In addition to defining the HTTP/1.1 protocol, this document serves
+ as the specification for the Internet media type "message/http" and
+ "application/http". The message/http type can be used to enclose a
+ single HTTP request or response message, provided that it obeys the
+ MIME restrictions for all "message" types regarding line length and
+ encodings. The application/http type can be used to enclose a
+ pipeline of one or more HTTP request or response messages (not
+ intermixed). The following is to be registered with IANA [17].
+
+ Media Type name: message
+ Media subtype name: http
+ Required parameters: none
+ Optional parameters: version, msgtype
+ version: The HTTP-Version number of the enclosed message
+ (e.g., "1.1"). If not present, the version can be
+ determined from the first line of the body.
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first
+ line of the body.
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+ Security considerations: none
+
+ Media Type name: application
+ Media subtype name: http
+ Required parameters: none
+ Optional parameters: version, msgtype
+ version: The HTTP-Version number of the enclosed messages
+ (e.g., "1.1"). If not present, the version can be
+ determined from the first line of the body.
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first
+ line of the body.
+ Encoding considerations: HTTP messages enclosed by this type
+ are in "binary" format; use of an appropriate
+ Content-Transfer-Encoding is required when
+ transmitted via E-mail.
+ Security considerations: none
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 164]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+19.2 Internet Media Type multipart/byteranges
+
+ When an HTTP 206 (Partial Content) response message includes the
+ content of multiple ranges (a response to a request for multiple
+ non-overlapping ranges), these are transmitted as a multipart
+ message-body. The media type for this purpose is called
+ "multipart/byteranges".
+
+ The multipart/byteranges media type includes two or more parts, each
+ with its own Content-Type and Content-Range fields. The required
+ boundary parameter specifies the boundary string used to separate
+ each body-part.
+
+ Media Type name: multipart
+ Media subtype name: byteranges
+ Required parameters: boundary
+ Optional parameters: none
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+ Security considerations: none
+
+
+ For example:
+
+ HTTP/1.1 206 Partial Content
+ Date: Wed, 15 Nov 1995 06:25:24 GMT
+ Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+ Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 500-999/8000
+
+ ...the first range...
+ --THIS_STRING_SEPARATES
+ Content-type: application/pdf
+ Content-range: bytes 7000-7999/8000
+
+ ...the second range
+ --THIS_STRING_SEPARATES--
+
+ Notes:
+
+ 1) Additional CRLFs may precede the first boundary string in the
+ entity.
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 165]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ 2) Although RFC 2046 [40] permits the boundary string to be
+ quoted, some existing implementations handle a quoted boundary
+ string incorrectly.
+
+ 3) A number of browsers and servers were coded to an early draft
+ of the byteranges specification to use a media type of
+ multipart/x-byteranges, which is almost, but not quite
+ compatible with the version documented in HTTP/1.1.
+
+19.3 Tolerant Applications
+
+ Although this document specifies the requirements for the generation
+ of HTTP/1.1 messages, not all applications will be correct in their
+ implementation. We therefore recommend that operational applications
+ be tolerant of deviations whenever those deviations can be
+ interpreted unambiguously.
+
+ Clients SHOULD be tolerant in parsing the Status-Line and servers
+ tolerant when parsing the Request-Line. In particular, they SHOULD
+ accept any amount of SP or HT characters between fields, even though
+ only a single SP is required.
+
+ The line terminator for message-header fields is the sequence CRLF.
+ However, we recommend that applications, when parsing such headers,
+ recognize a single LF as a line terminator and ignore the leading CR.
+
+ The character set of an entity-body SHOULD be labeled as the lowest
+ common denominator of the character codes used within that body, with
+ the exception that not labeling the entity is preferred over labeling
+ the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
+ and 3.4.1.
+
+ Additional rules for requirements on parsing and encoding of dates
+ and other potential problems with date encodings include:
+
+ - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
+ which appears to be more than 50 years in the future is in fact
+ in the past (this helps solve the "year 2000" problem).
+
+ - An HTTP/1.1 implementation MAY internally represent a parsed
+ Expires date as earlier than the proper value, but MUST NOT
+ internally represent a parsed Expires date as later than the
+ proper value.
+
+ - All expiration-related calculations MUST be done in GMT. The
+ local time zone MUST NOT influence the calculation or comparison
+ of an age or expiration time.
+
+
+
+
+Fielding, et al. Standards Track [Page 166]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - If an HTTP header incorrectly carries a date value with a time
+ zone other than GMT, it MUST be converted into GMT using the
+ most conservative possible conversion.
+
+19.4 Differences Between HTTP Entities and RFC 2045 Entities
+
+ HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+ 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
+ allow entities to be transmitted in an open variety of
+ representations and with extensible mechanisms. However, RFC 2045
+ discusses mail, and HTTP has a few features that are different from
+ those described in RFC 2045. These differences were carefully chosen
+ to optimize performance over binary connections, to allow greater
+ freedom in the use of new media types, to make date comparisons
+ easier, and to acknowledge the practice of some early HTTP servers
+ and clients.
+
+ This appendix describes specific areas where HTTP differs from RFC
+ 2045. Proxies and gateways to strict MIME environments SHOULD be
+ aware of these differences and provide the appropriate conversions
+ where necessary. Proxies and gateways from MIME environments to HTTP
+ also need to be aware of the differences because some conversions
+ might be required.
+
+19.4.1 MIME-Version
+
+ HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
+ include a single MIME-Version general-header field to indicate what
+ version of the MIME protocol was used to construct the message. Use
+ of the MIME-Version header field indicates that the message is in
+ full compliance with the MIME protocol (as defined in RFC 2045[7]).
+ Proxies/gateways are responsible for ensuring full compliance (where
+ possible) when exporting HTTP messages to strict MIME environments.
+
+ MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ MIME version "1.0" is the default for use in HTTP/1.1. However,
+ HTTP/1.1 message parsing and semantics are defined by this document
+ and not the MIME specification.
+
+19.4.2 Conversion to Canonical Form
+
+ RFC 2045 [7] requires that an Internet mail entity be converted to
+ canonical form prior to being transferred, as described in section 4
+ of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
+ allowed for subtypes of the "text" media type when transmitted over
+ HTTP. RFC 2046 requires that content with a type of "text" represent
+ line breaks as CRLF and forbids the use of CR or LF outside of line
+
+
+
+Fielding, et al. Standards Track [Page 167]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
+ line break within text content when a message is transmitted over
+ HTTP.
+
+ Where it is possible, a proxy or gateway from HTTP to a strict MIME
+ environment SHOULD translate all line breaks within the text media
+ types described in section 3.7.1 of this document to the RFC 2049
+ canonical form of CRLF. Note, however, that this might be complicated
+ by the presence of a Content-Encoding and by the fact that HTTP
+ allows the use of some character sets which do not use octets 13 and
+ 10 to represent CR and LF, as is the case for some multi-byte
+ character sets.
+
+ Implementors should note that conversion will break any cryptographic
+ checksums applied to the original content unless the original content
+ is already in canonical form. Therefore, the canonical form is
+ recommended for any content that uses such checksums in HTTP.
+
+19.4.3 Conversion of Date Formats
+
+ HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
+ simplify the process of date comparison. Proxies and gateways from
+ other protocols SHOULD ensure that any Date header field present in a
+ message conforms to one of the HTTP/1.1 formats and rewrite the date
+ if necessary.
+
+19.4.4 Introduction of Content-Encoding
+
+ RFC 2045 does not include any concept equivalent to HTTP/1.1's
+ Content-Encoding header field. Since this acts as a modifier on the
+ media type, proxies and gateways from HTTP to MIME-compliant
+ protocols MUST either change the value of the Content-Type header
+ field or decode the entity-body before forwarding the message. (Some
+ experimental applications of Content-Type for Internet mail have used
+ a media-type parameter of ";conversions=<content-coding>" to perform
+ a function equivalent to Content-Encoding. However, this parameter is
+ not part of RFC 2045.)
+
+19.4.5 No Content-Transfer-Encoding
+
+ HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+ 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
+ remove any non-identity CTE ("quoted-printable" or "base64") encoding
+ prior to delivering the response message to an HTTP client.
+
+ Proxies and gateways from HTTP to MIME-compliant protocols are
+ responsible for ensuring that the message is in the correct format
+ and encoding for safe transport on that protocol, where "safe
+
+
+
+Fielding, et al. Standards Track [Page 168]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ transport" is defined by the limitations of the protocol being used.
+ Such a proxy or gateway SHOULD label the data with an appropriate
+ Content-Transfer-Encoding if doing so will improve the likelihood of
+ safe transport over the destination protocol.
+
+19.4.6 Introduction of Transfer-Encoding
+
+ HTTP/1.1 introduces the Transfer-Encoding header field (section
+ 14.41). Proxies/gateways MUST remove any transfer-coding prior to
+ forwarding a message via a MIME-compliant protocol.
+
+ A process for decoding the "chunked" transfer-coding (section 3.6)
+ can be represented in pseudo-code as:
+
+ length := 0
+ read chunk-size, chunk-extension (if any) and CRLF
+ while (chunk-size > 0) {
+ read chunk-data and CRLF
+ append chunk-data to entity-body
+ length := length + chunk-size
+ read chunk-size and CRLF
+ }
+ read entity-header
+ while (entity-header not empty) {
+ append entity-header to existing header fields
+ read entity-header
+ }
+ Content-Length := length
+ Remove "chunked" from Transfer-Encoding
+
+19.4.7 MHTML and Line Length Limitations
+
+ HTTP implementations which share code with MHTML [45] implementations
+ need to be aware of MIME line length limitations. Since HTTP does not
+ have this limitation, HTTP does not fold long lines. MHTML messages
+ being transported by HTTP follow all conventions of MHTML, including
+ line length limitations and folding, canonicalization, etc., since
+ HTTP transports all message-bodies as payload (see section 3.7.2) and
+ does not interpret the content or any MIME header lines that might be
+ contained therein.
+
+19.5 Additional Features
+
+ RFC 1945 and RFC 2068 document protocol elements used by some
+ existing HTTP implementations, but not consistently and correctly
+ across most HTTP/1.1 applications. Implementors are advised to be
+ aware of these features, but cannot rely upon their presence in, or
+ interoperability with, other HTTP/1.1 applications. Some of these
+
+
+
+Fielding, et al. Standards Track [Page 169]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ describe proposed experimental features, and some describe features
+ that experimental deployment found lacking that are now addressed in
+ the base HTTP/1.1 specification.
+
+ A number of other headers, such as Content-Disposition and Title,
+ from SMTP and MIME are also often implemented (see RFC 2076 [37]).
+
+19.5.1 Content-Disposition
+
+ The Content-Disposition response-header field has been proposed as a
+ means for the origin server to suggest a default filename if the user
+ requests that the content is saved to a file. This usage is derived
+ from the definition of Content-Disposition in RFC 1806 [35].
+
+ content-disposition = "Content-Disposition" ":"
+ disposition-type *( ";" disposition-parm )
+ disposition-type = "attachment" | disp-extension-token
+ disposition-parm = filename-parm | disp-extension-parm
+ filename-parm = "filename" "=" quoted-string
+ disp-extension-token = token
+ disp-extension-parm = token "=" ( token | quoted-string )
+
+ An example is
+
+ Content-Disposition: attachment; filename="fname.ext"
+
+ The receiving user agent SHOULD NOT respect any directory path
+ information present in the filename-parm parameter, which is the only
+ parameter believed to apply to HTTP implementations at this time. The
+ filename SHOULD be treated as a terminal component only.
+
+ If this header is used in a response with the application/octet-
+ stream content-type, the implied suggestion is that the user agent
+ should not display the response, but directly enter a `save response
+ as...' dialog.
+
+ See section 15.5 for Content-Disposition security issues.
+
+19.6 Compatibility with Previous Versions
+
+ It is beyond the scope of a protocol specification to mandate
+ compliance with previous versions. HTTP/1.1 was deliberately
+ designed, however, to make supporting previous versions easy. It is
+ worth noting that, at the time of composing this specification
+ (1996), we would expect commercial HTTP/1.1 servers to:
+
+ - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
+ 1.1 requests;
+
+
+
+Fielding, et al. Standards Track [Page 170]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ - understand any valid request in the format of HTTP/0.9, 1.0, or
+ 1.1;
+
+ - respond appropriately with a message in the same major version
+ used by the client.
+
+ And we would expect HTTP/1.1 clients to:
+
+ - recognize the format of the Status-Line for HTTP/1.0 and 1.1
+ responses;
+
+ - understand any valid response in the format of HTTP/0.9, 1.0, or
+ 1.1.
+
+ For most implementations of HTTP/1.0, each connection is established
+ by the client prior to the request and closed by the server after
+ sending the response. Some implementations implement the Keep-Alive
+ version of persistent connections described in section 19.7.1 of RFC
+ 2068 [33].
+
+19.6.1 Changes from HTTP/1.0
+
+ This section summarizes major differences between versions HTTP/1.0
+ and HTTP/1.1.
+
+19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
+ Addresses
+
+ The requirements that clients and servers support the Host request-
+ header, report an error if the Host request-header (section 14.23) is
+ missing from an HTTP/1.1 request, and accept absolute URIs (section
+ 5.1.2) are among the most important changes defined by this
+ specification.
+
+ Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+ addresses and servers; there was no other established mechanism for
+ distinguishing the intended server of a request than the IP address
+ to which that request was directed. The changes outlined above will
+ allow the Internet, once older HTTP clients are no longer common, to
+ support multiple Web sites from a single IP address, greatly
+ simplifying large operational Web servers, where allocation of many
+ IP addresses to a single host has created serious problems. The
+ Internet will also be able to recover the IP addresses that have been
+ allocated for the sole purpose of allowing special-purpose domain
+ names to be used in root-level HTTP URLs. Given the rate of growth of
+ the Web, and the number of servers already deployed, it is extremely
+
+
+
+
+
+Fielding, et al. Standards Track [Page 171]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ important that all implementations of HTTP (including updates to
+ existing HTTP/1.0 applications) correctly implement these
+ requirements:
+
+ - Both clients and servers MUST support the Host request-header.
+
+ - A client that sends an HTTP/1.1 request MUST send a Host header.
+
+ - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+ request does not include a Host request-header.
+
+ - Servers MUST accept absolute URIs.
+
+19.6.2 Compatibility with HTTP/1.0 Persistent Connections
+
+ Some clients and servers might wish to be compatible with some
+ previous implementations of persistent connections in HTTP/1.0
+ clients and servers. Persistent connections in HTTP/1.0 are
+ explicitly negotiated as they are not the default behavior. HTTP/1.0
+ experimental implementations of persistent connections are faulty,
+ and the new facilities in HTTP/1.1 are designed to rectify these
+ problems. The problem was that some existing 1.0 clients may be
+ sending Keep-Alive to a proxy server that doesn't understand
+ Connection, which would then erroneously forward it to the next
+ inbound server, which would establish the Keep-Alive connection and
+ result in a hung HTTP/1.0 proxy waiting for the close on the
+ response. The result is that HTTP/1.0 clients must be prevented from
+ using Keep-Alive when talking to proxies.
+
+ However, talking to proxies is the most important use of persistent
+ connections, so that prohibition is clearly unacceptable. Therefore,
+ we need some other mechanism for indicating a persistent connection
+ is desired, which is safe to use even when talking to an old proxy
+ that ignores Connection. Persistent connections are the default for
+ HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+ declaring non-persistence. See section 14.10.
+
+ The original HTTP/1.0 form of persistent connections (the Connection:
+ Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
+
+19.6.3 Changes from RFC 2068
+
+ This specification has been carefully audited to correct and
+ disambiguate key word usage; RFC 2068 had many problems in respect to
+ the conventions laid out in RFC 2119 [34].
+
+ Clarified which error code should be used for inbound server failures
+ (e.g. DNS failures). (Section 10.5.5).
+
+
+
+Fielding, et al. Standards Track [Page 172]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ CREATE had a race that required an Etag be sent when a resource is
+ first created. (Section 10.2.2).
+
+ Content-Base was deleted from the specification: it was not
+ implemented widely, and there is no simple, safe way to introduce it
+ without a robust extension mechanism. In addition, it is used in a
+ similar, but not identical fashion in MHTML [45].
+
+ Transfer-coding and message lengths all interact in ways that
+ required fixing exactly when chunked encoding is used (to allow for
+ transfer encoding that may not be self delimiting); it was important
+ to straighten out exactly how message lengths are computed. (Sections
+ 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
+
+ A content-coding of "identity" was introduced, to solve problems
+ discovered in caching. (section 3.5)
+
+ Quality Values of zero should indicate that "I don't want something"
+ to allow clients to refuse a representation. (Section 3.9)
+
+ The use and interpretation of HTTP version numbers has been clarified
+ by RFC 2145. Require proxies to upgrade requests to highest protocol
+ version they support to deal with problems discovered in HTTP/1.0
+ implementations (Section 3.1)
+
+ Charset wildcarding is introduced to avoid explosion of character set
+ names in accept headers. (Section 14.2)
+
+ A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
+ was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
+ 14.9.3)
+
+ The Cache-Control: max-age directive was not properly defined for
+ responses. (Section 14.9.3)
+
+ There are situations where a server (especially a proxy) does not
+ know the full length of a response but is capable of serving a
+ byterange request. We therefore need a mechanism to allow byteranges
+ with a content-range not indicating the full length of the message.
+ (Section 14.16)
+
+ Range request responses would become very verbose if all meta-data
+ were always returned; by allowing the server to only send needed
+ headers in a 206 response, this problem can be avoided. (Section
+ 10.2.7, 13.5.3, and 14.27)
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 173]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Fix problem with unsatisfiable range requests; there are two cases:
+ syntactic problems, and range doesn't exist in the document. The 416
+ status code was needed to resolve this ambiguity needed to indicate
+ an error for a byte range request that falls outside of the actual
+ contents of a document. (Section 10.4.17, 14.16)
+
+ Rewrite of message transmission requirements to make it much harder
+ for implementors to get it wrong, as the consequences of errors here
+ can have significant impact on the Internet, and to deal with the
+ following problems:
+
+ 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
+ this was incorrectly placing a requirement on the behavior of
+ an implementation of a future version of HTTP/1.x
+
+ 2. Made it clear that user-agents should retry requests, not
+ "clients" in general.
+
+ 3. Converted requirements for clients to ignore unexpected 100
+ (Continue) responses, and for proxies to forward 100 responses,
+ into a general requirement for 1xx responses.
+
+ 4. Modified some TCP-specific language, to make it clearer that
+ non-TCP transports are possible for HTTP.
+
+ 5. Require that the origin server MUST NOT wait for the request
+ body before it sends a required 100 (Continue) response.
+
+ 6. Allow, rather than require, a server to omit 100 (Continue) if
+ it has already seen some of the request body.
+
+ 7. Allow servers to defend against denial-of-service attacks and
+ broken clients.
+
+ This change adds the Expect header and 417 status code. The message
+ transmission requirements fixes are in sections 8.2, 10.4.18,
+ 8.1.2.2, 13.11, and 14.20.
+
+ Proxies should be able to add Content-Length when appropriate.
+ (Section 13.5.2)
+
+ Clean up confusion between 403 and 404 responses. (Section 10.4.4,
+ 10.4.5, and 10.4.11)
+
+ Warnings could be cached incorrectly, or not updated appropriately.
+ (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
+ also needed to be a general header, as PUT or other methods may have
+ need for it in requests.
+
+
+
+Fielding, et al. Standards Track [Page 174]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+ Transfer-coding had significant problems, particularly with
+ interactions with chunked encoding. The solution is that transfer-
+ codings become as full fledged as content-codings. This involves
+ adding an IANA registry for transfer-codings (separate from content
+ codings), a new header field (TE) and enabling trailer headers in the
+ future. Transfer encoding is a major performance benefit, so it was
+ worth fixing [39]. TE also solves another, obscure, downward
+ interoperability problem that could have occurred due to interactions
+ between authentication trailers, chunked encoding and HTTP/1.0
+ clients.(Section 3.6, 3.6.1, and 14.39)
+
+ The PATCH, LINK, UNLINK methods were defined but not commonly
+ implemented in previous versions of this specification. See RFC 2068
+ [33].
+
+ The Alternates, Content-Version, Derived-From, Link, URI, Public and
+ Content-Base header fields were defined in previous versions of this
+ specification, but not commonly implemented. See RFC 2068 [33].
+
+20 Index
+
+ Please see the PostScript version of this RFC for the INDEX.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 175]
+\f
+RFC 2616 HTTP/1.1 June 1999
+
+
+21. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 176]
+\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Belshe
+Request for Comments: 7540 BitGo
+Category: Standards Track R. Peon
+ISSN: 2070-1721 Google, Inc
+ M. Thomson, Ed.
+ Mozilla
+ May 2015
+
+
+ Hypertext Transfer Protocol Version 2 (HTTP/2)
+
+Abstract
+
+ This specification describes an optimized expression of the semantics
+ of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
+ version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
+ resources and a reduced perception of latency by introducing header
+ field compression and allowing multiple concurrent exchanges on the
+ same connection. It also introduces unsolicited push of
+ representations from servers to clients.
+
+ This specification is an alternative to, but does not obsolete, the
+ HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7540.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 1]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. HTTP/2 Protocol Overview ........................................5
+ 2.1. Document Organization ......................................6
+ 2.2. Conventions and Terminology ................................6
+ 3. Starting HTTP/2 .................................................7
+ 3.1. HTTP/2 Version Identification ..............................8
+ 3.2. Starting HTTP/2 for "http" URIs ............................8
+ 3.2.1. HTTP2-Settings Header Field .........................9
+ 3.3. Starting HTTP/2 for "https" URIs ..........................10
+ 3.4. Starting HTTP/2 with Prior Knowledge ......................10
+ 3.5. HTTP/2 Connection Preface .................................11
+ 4. HTTP Frames ....................................................12
+ 4.1. Frame Format ..............................................12
+ 4.2. Frame Size ................................................13
+ 4.3. Header Compression and Decompression ......................14
+ 5. Streams and Multiplexing .......................................15
+ 5.1. Stream States .............................................16
+ 5.1.1. Stream Identifiers .................................21
+ 5.1.2. Stream Concurrency .................................22
+ 5.2. Flow Control ..............................................22
+ 5.2.1. Flow-Control Principles ............................23
+ 5.2.2. Appropriate Use of Flow Control ....................24
+ 5.3. Stream Priority ...........................................24
+ 5.3.1. Stream Dependencies ................................25
+ 5.3.2. Dependency Weighting ...............................26
+ 5.3.3. Reprioritization ...................................26
+ 5.3.4. Prioritization State Management ....................27
+ 5.3.5. Default Priorities .................................28
+ 5.4. Error Handling ............................................28
+ 5.4.1. Connection Error Handling ..........................29
+ 5.4.2. Stream Error Handling ..............................29
+
+
+
+Belshe, et al. Standards Track [Page 2]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ 5.4.3. Connection Termination .............................30
+ 5.5. Extending HTTP/2 ..........................................30
+ 6. Frame Definitions ..............................................31
+ 6.1. DATA ......................................................31
+ 6.2. HEADERS ...................................................32
+ 6.3. PRIORITY ..................................................34
+ 6.4. RST_STREAM ................................................36
+ 6.5. SETTINGS ..................................................36
+ 6.5.1. SETTINGS Format ....................................38
+ 6.5.2. Defined SETTINGS Parameters ........................38
+ 6.5.3. Settings Synchronization ...........................39
+ 6.6. PUSH_PROMISE ..............................................40
+ 6.7. PING ......................................................42
+ 6.8. GOAWAY ....................................................43
+ 6.9. WINDOW_UPDATE .............................................46
+ 6.9.1. The Flow-Control Window ............................47
+ 6.9.2. Initial Flow-Control Window Size ...................48
+ 6.9.3. Reducing the Stream Window Size ....................49
+ 6.10. CONTINUATION .............................................49
+ 7. Error Codes ....................................................50
+ 8. HTTP Message Exchanges .........................................51
+ 8.1. HTTP Request/Response Exchange ............................52
+ 8.1.1. Upgrading from HTTP/2 ..............................53
+ 8.1.2. HTTP Header Fields .................................53
+ 8.1.3. Examples ...........................................57
+ 8.1.4. Request Reliability Mechanisms in HTTP/2 ...........60
+ 8.2. Server Push ...............................................60
+ 8.2.1. Push Requests ......................................61
+ 8.2.2. Push Responses .....................................63
+ 8.3. The CONNECT Method ........................................64
+ 9. Additional HTTP Requirements/Considerations ....................65
+ 9.1. Connection Management .....................................65
+ 9.1.1. Connection Reuse ...................................66
+ 9.1.2. The 421 (Misdirected Request) Status Code ..........66
+ 9.2. Use of TLS Features .......................................67
+ 9.2.1. TLS 1.2 Features ...................................67
+ 9.2.2. TLS 1.2 Cipher Suites ..............................68
+ 10. Security Considerations .......................................69
+ 10.1. Server Authority .........................................69
+ 10.2. Cross-Protocol Attacks ...................................69
+ 10.3. Intermediary Encapsulation Attacks .......................70
+ 10.4. Cacheability of Pushed Responses .........................70
+ 10.5. Denial-of-Service Considerations .........................70
+ 10.5.1. Limits on Header Block Size .......................71
+ 10.5.2. CONNECT Issues ....................................72
+ 10.6. Use of Compression .......................................72
+ 10.7. Use of Padding ...........................................73
+ 10.8. Privacy Considerations ...................................73
+
+
+
+Belshe, et al. Standards Track [Page 3]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ 11. IANA Considerations ...........................................74
+ 11.1. Registration of HTTP/2 Identification Strings ............74
+ 11.2. Frame Type Registry ......................................75
+ 11.3. Settings Registry ........................................75
+ 11.4. Error Code Registry ......................................76
+ 11.5. HTTP2-Settings Header Field Registration .................77
+ 11.6. PRI Method Registration ..................................78
+ 11.7. The 421 (Misdirected Request) HTTP Status Code ...........78
+ 11.8. The h2c Upgrade Token ....................................78
+ 12. References ....................................................79
+ 12.1. Normative References .....................................79
+ 12.2. Informative References ...................................81
+ Appendix A. TLS 1.2 Cipher Suite Black List .......................83
+ Acknowledgements ..................................................95
+ Authors' Addresses ................................................96
+
+1. Introduction
+
+ The Hypertext Transfer Protocol (HTTP) is a wildly successful
+ protocol. However, the way HTTP/1.1 uses the underlying transport
+ ([RFC7230], Section 6) has several characteristics that have a
+ negative overall effect on application performance today.
+
+ In particular, HTTP/1.0 allowed only one request to be outstanding at
+ a time on a given TCP connection. HTTP/1.1 added request pipelining,
+ but this only partially addressed request concurrency and still
+ suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1
+ clients that need to make many requests use multiple connections to a
+ server in order to achieve concurrency and thereby reduce latency.
+
+ Furthermore, HTTP header fields are often repetitive and verbose,
+ causing unnecessary network traffic as well as causing the initial
+ TCP [TCP] congestion window to quickly fill. This can result in
+ excessive latency when multiple requests are made on a new TCP
+ connection.
+
+ HTTP/2 addresses these issues by defining an optimized mapping of
+ HTTP's semantics to an underlying connection. Specifically, it
+ allows interleaving of request and response messages on the same
+ connection and uses an efficient coding for HTTP header fields. It
+ also allows prioritization of requests, letting more important
+ requests complete more quickly, further improving performance.
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 4]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ The resulting protocol is more friendly to the network because fewer
+ TCP connections can be used in comparison to HTTP/1.x. This means
+ less competition with other flows and longer-lived connections, which
+ in turn lead to better utilization of available network capacity.
+
+ Finally, HTTP/2 also enables more efficient processing of messages
+ through use of binary message framing.
+
+2. HTTP/2 Protocol Overview
+
+ HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2
+ supports all of the core features of HTTP/1.1 but aims to be more
+ efficient in several ways.
+
+ The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each
+ frame type serves a different purpose. For example, HEADERS and DATA
+ frames form the basis of HTTP requests and responses (Section 8.1);
+ other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are
+ used in support of other HTTP/2 features.
+
+ Multiplexing of requests is achieved by having each HTTP request/
+ response exchange associated with its own stream (Section 5).
+ Streams are largely independent of each other, so a blocked or
+ stalled request or response does not prevent progress on other
+ streams.
+
+ Flow control and prioritization ensure that it is possible to
+ efficiently use multiplexed streams. Flow control (Section 5.2)
+ helps to ensure that only data that can be used by a receiver is
+ transmitted. Prioritization (Section 5.3) ensures that limited
+ resources can be directed to the most important streams first.
+
+ HTTP/2 adds a new interaction mode whereby a server can push
+ responses to a client (Section 8.2). Server push allows a server to
+ speculatively send data to a client that the server anticipates the
+ client will need, trading off some network usage against a potential
+ latency gain. The server does this by synthesizing a request, which
+ it sends as a PUSH_PROMISE frame. The server is then able to send a
+ response to the synthetic request on a separate stream.
+
+ Because HTTP header fields used in a connection can contain large
+ amounts of redundant data, frames that contain them are compressed
+ (Section 4.3). This has especially advantageous impact upon request
+ sizes in the common case, allowing many requests to be compressed
+ into one packet.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 5]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+2.1. Document Organization
+
+ The HTTP/2 specification is split into four parts:
+
+ o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is
+ initiated.
+
+ o The frame (Section 4) and stream (Section 5) layers describe the
+ way HTTP/2 frames are structured and formed into multiplexed
+ streams.
+
+ o Frame (Section 6) and error (Section 7) definitions include
+ details of the frame and error types used in HTTP/2.
+
+ o HTTP mappings (Section 8) and additional requirements (Section 9)
+ describe how HTTP semantics are expressed using frames and
+ streams.
+
+ While some of the frame and stream layer concepts are isolated from
+ HTTP, this specification does not define a completely generic frame
+ layer. The frame and stream layers are tailored to the needs of the
+ HTTP protocol and server push.
+
+2.2. Conventions and Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ All numeric values are in network byte order. Values are unsigned
+ unless otherwise indicated. Literal values are provided in decimal
+ or hexadecimal as appropriate. Hexadecimal literals are prefixed
+ with "0x" to distinguish them from decimal literals.
+
+ The following terms are used:
+
+ client: The endpoint that initiates an HTTP/2 connection. Clients
+ send HTTP requests and receive HTTP responses.
+
+ connection: A transport-layer connection between two endpoints.
+
+ connection error: An error that affects the entire HTTP/2
+ connection.
+
+ endpoint: Either the client or server of the connection.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 6]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ frame: The smallest unit of communication within an HTTP/2
+ connection, consisting of a header and a variable-length sequence
+ of octets structured according to the frame type.
+
+ peer: An endpoint. When discussing a particular endpoint, "peer"
+ refers to the endpoint that is remote to the primary subject of
+ discussion.
+
+ receiver: An endpoint that is receiving frames.
+
+ sender: An endpoint that is transmitting frames.
+
+ server: The endpoint that accepts an HTTP/2 connection. Servers
+ receive HTTP requests and send HTTP responses.
+
+ stream: A bidirectional flow of frames within the HTTP/2 connection.
+
+ stream error: An error on the individual HTTP/2 stream.
+
+ Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
+ are defined in Section 2.3 of [RFC7230]. Intermediaries act as both
+ client and server at different times.
+
+ The term "payload body" is defined in Section 3.3 of [RFC7230].
+
+3. Starting HTTP/2
+
+ An HTTP/2 connection is an application-layer protocol running on top
+ of a TCP connection ([TCP]). The client is the TCP connection
+ initiator.
+
+ HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1.
+ HTTP/2 shares the same default port numbers: 80 for "http" URIs and
+ 443 for "https" URIs. As a result, implementations processing
+ requests for target resource URIs like "http://example.org/foo" or
+ "https://example.com/bar" are required to first discover whether the
+ upstream server (the immediate peer to which the client wishes to
+ establish a connection) supports HTTP/2.
+
+ The means by which support for HTTP/2 is determined is different for
+ "http" and "https" URIs. Discovery for "http" URIs is described in
+ Section 3.2. Discovery for "https" URIs is described in Section 3.3.
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 7]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+3.1. HTTP/2 Version Identification
+
+ The protocol defined in this document has two identifiers.
+
+ o The string "h2" identifies the protocol where HTTP/2 uses
+ Transport Layer Security (TLS) [TLS12]. This identifier is used
+ in the TLS application-layer protocol negotiation (ALPN) extension
+ [TLS-ALPN] field and in any place where HTTP/2 over TLS is
+ identified.
+
+ The "h2" string is serialized into an ALPN protocol identifier as
+ the two-octet sequence: 0x68, 0x32.
+
+ o The string "h2c" identifies the protocol where HTTP/2 is run over
+ cleartext TCP. This identifier is used in the HTTP/1.1 Upgrade
+ header field and in any place where HTTP/2 over TCP is identified.
+
+ The "h2c" string is reserved from the ALPN identifier space but
+ describes a protocol that does not use TLS.
+
+ Negotiating "h2" or "h2c" implies the use of the transport, security,
+ framing, and message semantics described in this document.
+
+3.2. Starting HTTP/2 for "http" URIs
+
+ A client that makes a request for an "http" URI without prior
+ knowledge about support for HTTP/2 on the next hop uses the HTTP
+ Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by
+ making an HTTP/1.1 request that includes an Upgrade header field with
+ the "h2c" token. Such an HTTP/1.1 request MUST include exactly one
+ HTTP2-Settings (Section 3.2.1) header field.
+
+ For example:
+
+ GET / HTTP/1.1
+ Host: server.example.com
+ Connection: Upgrade, HTTP2-Settings
+ Upgrade: h2c
+ HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
+
+ Requests that contain a payload body MUST be sent in their entirety
+ before the client can send HTTP/2 frames. This means that a large
+ request can block the use of the connection until it is completely
+ sent.
+
+ If concurrency of an initial request with subsequent requests is
+ important, an OPTIONS request can be used to perform the upgrade to
+ HTTP/2, at the cost of an additional round trip.
+
+
+
+Belshe, et al. Standards Track [Page 8]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A server that does not support HTTP/2 can respond to the request as
+ though the Upgrade header field were absent:
+
+ HTTP/1.1 200 OK
+ Content-Length: 243
+ Content-Type: text/html
+
+ ...
+
+ A server MUST ignore an "h2" token in an Upgrade header field.
+ Presence of a token with "h2" implies HTTP/2 over TLS, which is
+ instead negotiated as described in Section 3.3.
+
+ A server that supports HTTP/2 accepts the upgrade with a 101
+ (Switching Protocols) response. After the empty line that terminates
+ the 101 response, the server can begin sending HTTP/2 frames. These
+ frames MUST include a response to the request that initiated the
+ upgrade.
+
+ For example:
+
+ HTTP/1.1 101 Switching Protocols
+ Connection: Upgrade
+ Upgrade: h2c
+
+ [ HTTP/2 connection ...
+
+ The first HTTP/2 frame sent by the server MUST be a server connection
+ preface (Section 3.5) consisting of a SETTINGS frame (Section 6.5).
+ Upon receiving the 101 response, the client MUST send a connection
+ preface (Section 3.5), which includes a SETTINGS frame.
+
+ The HTTP/1.1 request that is sent prior to upgrade is assigned a
+ stream identifier of 1 (see Section 5.1.1) with default priority
+ values (Section 5.3.5). Stream 1 is implicitly "half-closed" from
+ the client toward the server (see Section 5.1), since the request is
+ completed as an HTTP/1.1 request. After commencing the HTTP/2
+ connection, stream 1 is used for the response.
+
+3.2.1. HTTP2-Settings Header Field
+
+ A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly
+ one "HTTP2-Settings" header field. The HTTP2-Settings header field
+ is a connection-specific header field that includes parameters that
+ govern the HTTP/2 connection, provided in anticipation of the server
+ accepting the request to upgrade.
+
+ HTTP2-Settings = token68
+
+
+
+Belshe, et al. Standards Track [Page 9]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A server MUST NOT upgrade the connection to HTTP/2 if this header
+ field is not present or if more than one is present. A server MUST
+ NOT send this header field.
+
+ The content of the HTTP2-Settings header field is the payload of a
+ SETTINGS frame (Section 6.5), encoded as a base64url string (that is,
+ the URL- and filename-safe Base64 encoding described in Section 5 of
+ [RFC4648], with any trailing '=' characters omitted). The ABNF
+ [RFC5234] production for "token68" is defined in Section 2.1 of
+ [RFC7235].
+
+ Since the upgrade is only intended to apply to the immediate
+ connection, a client sending the HTTP2-Settings header field MUST
+ also send "HTTP2-Settings" as a connection option in the Connection
+ header field to prevent it from being forwarded (see Section 6.1 of
+ [RFC7230]).
+
+ A server decodes and interprets these values as it would any other
+ SETTINGS frame. Explicit acknowledgement of these settings
+ (Section 6.5.3) is not necessary, since a 101 response serves as
+ implicit acknowledgement. Providing these values in the upgrade
+ request gives a client an opportunity to provide parameters prior to
+ receiving any frames from the server.
+
+3.3. Starting HTTP/2 for "https" URIs
+
+ A client that makes a request to an "https" URI uses TLS [TLS12] with
+ the application-layer protocol negotiation (ALPN) extension
+ [TLS-ALPN].
+
+ HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c"
+ protocol identifier MUST NOT be sent by a client or selected by a
+ server; the "h2c" protocol identifier describes a protocol that does
+ not use TLS.
+
+ Once TLS negotiation is complete, both the client and the server MUST
+ send a connection preface (Section 3.5).
+
+3.4. Starting HTTP/2 with Prior Knowledge
+
+ A client can learn that a particular server supports HTTP/2 by other
+ means. For example, [ALT-SVC] describes a mechanism for advertising
+ this capability.
+
+ A client MUST send the connection preface (Section 3.5) and then MAY
+ immediately send HTTP/2 frames to such a server; servers can identify
+ these connections by the presence of the connection preface. This
+
+
+
+
+Belshe, et al. Standards Track [Page 10]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ only affects the establishment of HTTP/2 connections over cleartext
+ TCP; implementations that support HTTP/2 over TLS MUST use protocol
+ negotiation in TLS [TLS-ALPN].
+
+ Likewise, the server MUST send a connection preface (Section 3.5).
+
+ Without additional information, prior support for HTTP/2 is not a
+ strong signal that a given server will support HTTP/2 for future
+ connections. For example, it is possible for server configurations
+ to change, for configurations to differ between instances in
+ clustered servers, or for network conditions to change.
+
+3.5. HTTP/2 Connection Preface
+
+ In HTTP/2, each endpoint is required to send a connection preface as
+ a final confirmation of the protocol in use and to establish the
+ initial settings for the HTTP/2 connection. The client and server
+ each send a different connection preface.
+
+ The client connection preface starts with a sequence of 24 octets,
+ which in hex notation is:
+
+ 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
+
+ That is, the connection preface starts with the string "PRI *
+ HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence MUST be followed by a
+ SETTINGS frame (Section 6.5), which MAY be empty. The client sends
+ the client connection preface immediately upon receipt of a 101
+ (Switching Protocols) response (indicating a successful upgrade) or
+ as the first application data octets of a TLS connection. If
+ starting an HTTP/2 connection with prior knowledge of server support
+ for the protocol, the client connection preface is sent upon
+ connection establishment.
+
+ Note: The client connection preface is selected so that a large
+ proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do
+ not attempt to process further frames. Note that this does not
+ address the concerns raised in [TALKING].
+
+ The server connection preface consists of a potentially empty
+ SETTINGS frame (Section 6.5) that MUST be the first frame the server
+ sends in the HTTP/2 connection.
+
+ The SETTINGS frames received from a peer as part of the connection
+ preface MUST be acknowledged (see Section 6.5.3) after sending the
+ connection preface.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 11]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ To avoid unnecessary latency, clients are permitted to send
+ additional frames to the server immediately after sending the client
+ connection preface, without waiting to receive the server connection
+ preface. It is important to note, however, that the server
+ connection preface SETTINGS frame might include parameters that
+ necessarily alter how a client is expected to communicate with the
+ server. Upon receiving the SETTINGS frame, the client is expected to
+ honor any parameters established. In some configurations, it is
+ possible for the server to transmit SETTINGS before the client sends
+ additional frames, providing an opportunity to avoid this issue.
+
+ Clients and servers MUST treat an invalid connection preface as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR. A GOAWAY
+ frame (Section 6.8) MAY be omitted in this case, since an invalid
+ preface indicates that the peer is not using HTTP/2.
+
+4. HTTP Frames
+
+ Once the HTTP/2 connection is established, endpoints can begin
+ exchanging frames.
+
+4.1. Frame Format
+
+ All frames begin with a fixed 9-octet header followed by a variable-
+ length payload.
+
+ +-----------------------------------------------+
+ | Length (24) |
+ +---------------+---------------+---------------+
+ | Type (8) | Flags (8) |
+ +-+-------------+---------------+-------------------------------+
+ |R| Stream Identifier (31) |
+ +=+=============================================================+
+ | Frame Payload (0...) ...
+ +---------------------------------------------------------------+
+
+ Figure 1: Frame Layout
+
+ The fields of the frame header are defined as:
+
+ Length: The length of the frame payload expressed as an unsigned
+ 24-bit integer. Values greater than 2^14 (16,384) MUST NOT be
+ sent unless the receiver has set a larger value for
+ SETTINGS_MAX_FRAME_SIZE.
+
+ The 9 octets of the frame header are not included in this value.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 12]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Type: The 8-bit type of the frame. The frame type determines the
+ format and semantics of the frame. Implementations MUST ignore
+ and discard any frame that has a type that is unknown.
+
+ Flags: An 8-bit field reserved for boolean flags specific to the
+ frame type.
+
+ Flags are assigned semantics specific to the indicated frame type.
+ Flags that have no defined semantics for a particular frame type
+ MUST be ignored and MUST be left unset (0x0) when sending.
+
+ R: A reserved 1-bit field. The semantics of this bit are undefined,
+ and the bit MUST remain unset (0x0) when sending and MUST be
+ ignored when receiving.
+
+ Stream Identifier: A stream identifier (see Section 5.1.1) expressed
+ as an unsigned 31-bit integer. The value 0x0 is reserved for
+ frames that are associated with the connection as a whole as
+ opposed to an individual stream.
+
+ The structure and content of the frame payload is dependent entirely
+ on the frame type.
+
+4.2. Frame Size
+
+ The size of a frame payload is limited by the maximum size that a
+ receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This
+ setting can have any value between 2^14 (16,384) and 2^24-1
+ (16,777,215) octets, inclusive.
+
+ All implementations MUST be capable of receiving and minimally
+ processing frames up to 2^14 octets in length, plus the 9-octet frame
+ header (Section 4.1). The size of the frame header is not included
+ when describing frame sizes.
+
+ Note: Certain frame types, such as PING (Section 6.7), impose
+ additional limits on the amount of payload data allowed.
+
+ An endpoint MUST send an error code of FRAME_SIZE_ERROR if a frame
+ exceeds the size defined in SETTINGS_MAX_FRAME_SIZE, exceeds any
+ limit defined for the frame type, or is too small to contain
+ mandatory frame data. A frame size error in a frame that could alter
+ the state of the entire connection MUST be treated as a connection
+ error (Section 5.4.1); this includes any frame carrying a header
+ block (Section 4.3) (that is, HEADERS, PUSH_PROMISE, and
+ CONTINUATION), SETTINGS, and any frame with a stream identifier of 0.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 13]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Endpoints are not obligated to use all available space in a frame.
+ Responsiveness can be improved by using frames that are smaller than
+ the permitted maximum size. Sending large frames can result in
+ delays in sending time-sensitive frames (such as RST_STREAM,
+ WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of
+ a large frame, could affect performance.
+
+4.3. Header Compression and Decompression
+
+ Just as in HTTP/1, a header field in HTTP/2 is a name with one or
+ more associated values. Header fields are used within HTTP request
+ and response messages as well as in server push operations (see
+ Section 8.2).
+
+ Header lists are collections of zero or more header fields. When
+ transmitted over a connection, a header list is serialized into a
+ header block using HTTP header compression [COMPRESSION]. The
+ serialized header block is then divided into one or more octet
+ sequences, called header block fragments, and transmitted within the
+ payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6), or
+ CONTINUATION (Section 6.10) frames.
+
+ The Cookie header field [COOKIE] is treated specially by the HTTP
+ mapping (see Section 8.1.2.5).
+
+ A receiving endpoint reassembles the header block by concatenating
+ its fragments and then decompresses the block to reconstruct the
+ header list.
+
+ A complete header block consists of either:
+
+ o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
+ set, or
+
+ o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
+ and one or more CONTINUATION frames, where the last CONTINUATION
+ frame has the END_HEADERS flag set.
+
+ Header compression is stateful. One compression context and one
+ decompression context are used for the entire connection. A decoding
+ error in a header block MUST be treated as a connection error
+ (Section 5.4.1) of type COMPRESSION_ERROR.
+
+ Each header block is processed as a discrete unit. Header blocks
+ MUST be transmitted as a contiguous sequence of frames, with no
+ interleaved frames of any other type or from any other stream. The
+ last frame in a sequence of HEADERS or CONTINUATION frames has the
+
+
+
+
+Belshe, et al. Standards Track [Page 14]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE
+ or CONTINUATION frames has the END_HEADERS flag set. This allows a
+ header block to be logically equivalent to a single frame.
+
+ Header block fragments can only be sent as the payload of HEADERS,
+ PUSH_PROMISE, or CONTINUATION frames because these frames carry data
+ that can modify the compression context maintained by a receiver. An
+ endpoint receiving HEADERS, PUSH_PROMISE, or CONTINUATION frames
+ needs to reassemble header blocks and perform decompression even if
+ the frames are to be discarded. A receiver MUST terminate the
+ connection with a connection error (Section 5.4.1) of type
+ COMPRESSION_ERROR if it does not decompress a header block.
+
+5. Streams and Multiplexing
+
+ A "stream" is an independent, bidirectional sequence of frames
+ exchanged between the client and server within an HTTP/2 connection.
+ Streams have several important characteristics:
+
+ o A single HTTP/2 connection can contain multiple concurrently open
+ streams, with either endpoint interleaving frames from multiple
+ streams.
+
+ o Streams can be established and used unilaterally or shared by
+ either the client or server.
+
+ o Streams can be closed by either endpoint.
+
+ o The order in which frames are sent on a stream is significant.
+ Recipients process frames in the order they are received. In
+ particular, the order of HEADERS and DATA frames is semantically
+ significant.
+
+ o Streams are identified by an integer. Stream identifiers are
+ assigned to streams by the endpoint initiating the stream.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 15]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+5.1. Stream States
+
+ The lifecycle of a stream is shown in Figure 2.
+
+ +--------+
+ send PP | | recv PP
+ ,--------| idle |--------.
+ / | | \
+ v +--------+ v
+ +----------+ | +----------+
+ | | | send H / | |
+ ,------| reserved | | recv H | reserved |------.
+ | | (local) | | | (remote) | |
+ | +----------+ v +----------+ |
+ | | +--------+ | |
+ | | recv ES | | send ES | |
+ | send H | ,-------| open |-------. | recv H |
+ | | / | | \ | |
+ | v v +--------+ v v |
+ | +----------+ | +----------+ |
+ | | half | | | half | |
+ | | closed | | send R / | closed | |
+ | | (remote) | | recv R | (local) | |
+ | +----------+ | +----------+ |
+ | | | | |
+ | | send ES / | recv ES / | |
+ | | send R / v send R / | |
+ | | recv R +--------+ recv R | |
+ | send R / `----------->| |<-----------' send R / |
+ | recv R | closed | recv R |
+ `----------------------->| |<----------------------'
+ +--------+
+
+ send: endpoint sends this frame
+ recv: endpoint receives this frame
+
+ H: HEADERS frame (with implied CONTINUATIONs)
+ PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
+ ES: END_STREAM flag
+ R: RST_STREAM frame
+
+ Figure 2: Stream States
+
+ Note that this diagram shows stream state transitions and the frames
+ and flags that affect those transitions only. In this regard,
+ CONTINUATION frames do not result in state transitions; they are
+ effectively part of the HEADERS or PUSH_PROMISE that they follow.
+
+
+
+
+Belshe, et al. Standards Track [Page 16]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ For the purpose of state transitions, the END_STREAM flag is
+ processed as a separate event to the frame that bears it; a HEADERS
+ frame with the END_STREAM flag set can cause two state transitions.
+
+ Both endpoints have a subjective view of the state of a stream that
+ could be different when frames are in transit. Endpoints do not
+ coordinate the creation of streams; they are created unilaterally by
+ either endpoint. The negative consequences of a mismatch in states
+ are limited to the "closed" state after sending RST_STREAM, where
+ frames might be received for some time after closing.
+
+ Streams have the following states:
+
+ idle:
+ All streams start in the "idle" state.
+
+ The following transitions are valid from this state:
+
+ * Sending or receiving a HEADERS frame causes the stream to
+ become "open". The stream identifier is selected as described
+ in Section 5.1.1. The same HEADERS frame can also cause a
+ stream to immediately become "half-closed".
+
+ * Sending a PUSH_PROMISE frame on another stream reserves the
+ idle stream that is identified for later use. The stream state
+ for the reserved stream transitions to "reserved (local)".
+
+ * Receiving a PUSH_PROMISE frame on another stream reserves an
+ idle stream that is identified for later use. The stream state
+ for the reserved stream transitions to "reserved (remote)".
+
+ * Note that the PUSH_PROMISE frame is not sent on the idle stream
+ but references the newly reserved stream in the Promised Stream
+ ID field.
+
+ Receiving any frame other than HEADERS or PRIORITY on a stream in
+ this state MUST be treated as a connection error (Section 5.4.1)
+ of type PROTOCOL_ERROR.
+
+ reserved (local):
+ A stream in the "reserved (local)" state is one that has been
+ promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame
+ reserves an idle stream by associating the stream with an open
+ stream that was initiated by the remote peer (see Section 8.2).
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 17]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ In this state, only the following transitions are possible:
+
+ * The endpoint can send a HEADERS frame. This causes the stream
+ to open in a "half-closed (remote)" state.
+
+ * Either endpoint can send a RST_STREAM frame to cause the stream
+ to become "closed". This releases the stream reservation.
+
+
+ An endpoint MUST NOT send any type of frame other than HEADERS,
+ RST_STREAM, or PRIORITY in this state.
+
+ A PRIORITY or WINDOW_UPDATE frame MAY be received in this state.
+ Receiving any type of frame other than RST_STREAM, PRIORITY, or
+ WINDOW_UPDATE on a stream in this state MUST be treated as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ reserved (remote):
+ A stream in the "reserved (remote)" state has been reserved by a
+ remote peer.
+
+ In this state, only the following transitions are possible:
+
+ * Receiving a HEADERS frame causes the stream to transition to
+ "half-closed (local)".
+
+ * Either endpoint can send a RST_STREAM frame to cause the stream
+ to become "closed". This releases the stream reservation.
+
+ An endpoint MAY send a PRIORITY frame in this state to
+ reprioritize the reserved stream. An endpoint MUST NOT send any
+ type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in
+ this state.
+
+ Receiving any type of frame other than HEADERS, RST_STREAM, or
+ PRIORITY on a stream in this state MUST be treated as a connection
+ error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ open:
+ A stream in the "open" state may be used by both peers to send
+ frames of any type. In this state, sending peers observe
+ advertised stream-level flow-control limits (Section 5.2).
+
+ From this state, either endpoint can send a frame with an
+ END_STREAM flag set, which causes the stream to transition into
+ one of the "half-closed" states. An endpoint sending an
+
+
+
+
+
+Belshe, et al. Standards Track [Page 18]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ END_STREAM flag causes the stream state to become "half-closed
+ (local)"; an endpoint receiving an END_STREAM flag causes the
+ stream state to become "half-closed (remote)".
+
+ Either endpoint can send a RST_STREAM frame from this state,
+ causing it to transition immediately to "closed".
+
+ half-closed (local):
+ A stream that is in the "half-closed (local)" state cannot be used
+ for sending frames other than WINDOW_UPDATE, PRIORITY, and
+ RST_STREAM.
+
+ A stream transitions from this state to "closed" when a frame that
+ contains an END_STREAM flag is received or when either peer sends
+ a RST_STREAM frame.
+
+ An endpoint can receive any type of frame in this state.
+ Providing flow-control credit using WINDOW_UPDATE frames is
+ necessary to continue receiving flow-controlled frames. In this
+ state, a receiver can ignore WINDOW_UPDATE frames, which might
+ arrive for a short period after a frame bearing the END_STREAM
+ flag is sent.
+
+ PRIORITY frames received in this state are used to reprioritize
+ streams that depend on the identified stream.
+
+ half-closed (remote):
+ A stream that is "half-closed (remote)" is no longer being used by
+ the peer to send frames. In this state, an endpoint is no longer
+ obligated to maintain a receiver flow-control window.
+
+ If an endpoint receives additional frames, other than
+ WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in
+ this state, it MUST respond with a stream error (Section 5.4.2) of
+ type STREAM_CLOSED.
+
+ A stream that is "half-closed (remote)" can be used by the
+ endpoint to send frames of any type. In this state, the endpoint
+ continues to observe advertised stream-level flow-control limits
+ (Section 5.2).
+
+ A stream can transition from this state to "closed" by sending a
+ frame that contains an END_STREAM flag or when either peer sends a
+ RST_STREAM frame.
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 19]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ closed:
+ The "closed" state is the terminal state.
+
+ An endpoint MUST NOT send frames other than PRIORITY on a closed
+ stream. An endpoint that receives any frame other than PRIORITY
+ after receiving a RST_STREAM MUST treat that as a stream error
+ (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint
+ that receives any frames after receiving a frame with the
+ END_STREAM flag set MUST treat that as a connection error
+ (Section 5.4.1) of type STREAM_CLOSED, unless the frame is
+ permitted as described below.
+
+ WINDOW_UPDATE or RST_STREAM frames can be received in this state
+ for a short period after a DATA or HEADERS frame containing an
+ END_STREAM flag is sent. Until the remote peer receives and
+ processes RST_STREAM or the frame bearing the END_STREAM flag, it
+ might send frames of these types. Endpoints MUST ignore
+ WINDOW_UPDATE or RST_STREAM frames received in this state, though
+ endpoints MAY choose to treat frames that arrive a significant
+ time after sending END_STREAM as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ PRIORITY frames can be sent on closed streams to prioritize
+ streams that are dependent on the closed stream. Endpoints SHOULD
+ process PRIORITY frames, though they can be ignored if the stream
+ has been removed from the dependency tree (see Section 5.3.4).
+
+ If this state is reached as a result of sending a RST_STREAM
+ frame, the peer that receives the RST_STREAM might have already
+ sent -- or enqueued for sending -- frames on the stream that
+ cannot be withdrawn. An endpoint MUST ignore frames that it
+ receives on closed streams after it has sent a RST_STREAM frame.
+ An endpoint MAY choose to limit the period over which it ignores
+ frames and treat frames that arrive after this time as being in
+ error.
+
+ Flow-controlled frames (i.e., DATA) received after sending
+ RST_STREAM are counted toward the connection flow-control window.
+ Even though these frames might be ignored, because they are sent
+ before the sender receives the RST_STREAM, the sender will
+ consider the frames to count against the flow-control window.
+
+ An endpoint might receive a PUSH_PROMISE frame after it sends
+ RST_STREAM. PUSH_PROMISE causes a stream to become "reserved"
+ even if the associated stream has been reset. Therefore, a
+ RST_STREAM is needed to close an unwanted promised stream.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 20]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ In the absence of more specific guidance elsewhere in this document,
+ implementations SHOULD treat the receipt of a frame that is not
+ expressly permitted in the description of a state as a connection
+ error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
+ be sent and received in any stream state. Frames of unknown types
+ are ignored.
+
+ An example of the state transitions for an HTTP request/response
+ exchange can be found in Section 8.1. An example of the state
+ transitions for server push can be found in Sections 8.2.1 and 8.2.2.
+
+5.1.1. Stream Identifiers
+
+ Streams are identified with an unsigned 31-bit integer. Streams
+ initiated by a client MUST use odd-numbered stream identifiers; those
+ initiated by the server MUST use even-numbered stream identifiers. A
+ stream identifier of zero (0x0) is used for connection control
+ messages; the stream identifier of zero cannot be used to establish a
+ new stream.
+
+ HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are
+ responded to with a stream identifier of one (0x1). After the
+ upgrade completes, stream 0x1 is "half-closed (local)" to the client.
+ Therefore, stream 0x1 cannot be selected as a new stream identifier
+ by a client that upgrades from HTTP/1.1.
+
+ The identifier of a newly established stream MUST be numerically
+ greater than all streams that the initiating endpoint has opened or
+ reserved. This governs streams that are opened using a HEADERS frame
+ and streams that are reserved using PUSH_PROMISE. An endpoint that
+ receives an unexpected stream identifier MUST respond with a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ The first use of a new stream identifier implicitly closes all
+ streams in the "idle" state that might have been initiated by that
+ peer with a lower-valued stream identifier. For example, if a client
+ sends a HEADERS frame on stream 7 without ever sending a frame on
+ stream 5, then stream 5 transitions to the "closed" state when the
+ first frame for stream 7 is sent or received.
+
+ Stream identifiers cannot be reused. Long-lived connections can
+ result in an endpoint exhausting the available range of stream
+ identifiers. A client that is unable to establish a new stream
+ identifier can establish a new connection for new streams. A server
+ that is unable to establish a new stream identifier can send a GOAWAY
+ frame so that the client is forced to open a new connection for new
+ streams.
+
+
+
+
+Belshe, et al. Standards Track [Page 21]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+5.1.2. Stream Concurrency
+
+ A peer can limit the number of concurrently active streams using the
+ SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within
+ a SETTINGS frame. The maximum concurrent streams setting is specific
+ to each endpoint and applies only to the peer that receives the
+ setting. That is, clients specify the maximum number of concurrent
+ streams the server can initiate, and servers specify the maximum
+ number of concurrent streams the client can initiate.
+
+ Streams that are in the "open" state or in either of the "half-
+ closed" states count toward the maximum number of streams that an
+ endpoint is permitted to open. Streams in any of these three states
+ count toward the limit advertised in the
+ SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the
+ "reserved" states do not count toward the stream limit.
+
+ Endpoints MUST NOT exceed the limit set by their peer. An endpoint
+ that receives a HEADERS frame that causes its advertised concurrent
+ stream limit to be exceeded MUST treat this as a stream error
+ (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice
+ of error code determines whether the endpoint wishes to enable
+ automatic retry (see Section 8.1.4) for details).
+
+ An endpoint that wishes to reduce the value of
+ SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current
+ number of open streams can either close streams that exceed the new
+ value or allow streams to complete.
+
+5.2. Flow Control
+
+ Using streams for multiplexing introduces contention over use of the
+ TCP connection, resulting in blocked streams. A flow-control scheme
+ ensures that streams on the same connection do not destructively
+ interfere with each other. Flow control is used for both individual
+ streams and for the connection as a whole.
+
+ HTTP/2 provides for flow control through use of the WINDOW_UPDATE
+ frame (Section 6.9).
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 22]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+5.2.1. Flow-Control Principles
+
+ HTTP/2 stream flow control aims to allow a variety of flow-control
+ algorithms to be used without requiring protocol changes. Flow
+ control in HTTP/2 has the following characteristics:
+
+ 1. Flow control is specific to a connection. Both types of flow
+ control are between the endpoints of a single hop and not over
+ the entire end-to-end path.
+
+ 2. Flow control is based on WINDOW_UPDATE frames. Receivers
+ advertise how many octets they are prepared to receive on a
+ stream and for the entire connection. This is a credit-based
+ scheme.
+
+ 3. Flow control is directional with overall control provided by the
+ receiver. A receiver MAY choose to set any window size that it
+ desires for each stream and for the entire connection. A sender
+ MUST respect flow-control limits imposed by a receiver. Clients,
+ servers, and intermediaries all independently advertise their
+ flow-control window as a receiver and abide by the flow-control
+ limits set by their peer when sending.
+
+ 4. The initial value for the flow-control window is 65,535 octets
+ for both new streams and the overall connection.
+
+ 5. The frame type determines whether flow control applies to a
+ frame. Of the frames specified in this document, only DATA
+ frames are subject to flow control; all other frame types do not
+ consume space in the advertised flow-control window. This
+ ensures that important control frames are not blocked by flow
+ control.
+
+ 6. Flow control cannot be disabled.
+
+ 7. HTTP/2 defines only the format and semantics of the WINDOW_UPDATE
+ frame (Section 6.9). This document does not stipulate how a
+ receiver decides when to send this frame or the value that it
+ sends, nor does it specify how a sender chooses to send packets.
+ Implementations are able to select any algorithm that suits their
+ needs.
+
+ Implementations are also responsible for managing how requests and
+ responses are sent based on priority, choosing how to avoid head-of-
+ line blocking for requests, and managing the creation of new streams.
+ Algorithm choices for these could interact with any flow-control
+ algorithm.
+
+
+
+
+Belshe, et al. Standards Track [Page 23]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+5.2.2. Appropriate Use of Flow Control
+
+ Flow control is defined to protect endpoints that are operating under
+ resource constraints. For example, a proxy needs to share memory
+ between many connections and also might have a slow upstream
+ connection and a fast downstream one. Flow-control addresses cases
+ where the receiver is unable to process data on one stream yet wants
+ to continue to process other streams in the same connection.
+
+ Deployments that do not require this capability can advertise a flow-
+ control window of the maximum size (2^31-1) and can maintain this
+ window by sending a WINDOW_UPDATE frame when any data is received.
+ This effectively disables flow control for that receiver.
+ Conversely, a sender is always subject to the flow-control window
+ advertised by the receiver.
+
+ Deployments with constrained resources (for example, memory) can
+ employ flow control to limit the amount of memory a peer can consume.
+ Note, however, that this can lead to suboptimal use of available
+ network resources if flow control is enabled without knowledge of the
+ bandwidth-delay product (see [RFC7323]).
+
+ Even with full awareness of the current bandwidth-delay product,
+ implementation of flow control can be difficult. When using flow
+ control, the receiver MUST read from the TCP receive buffer in a
+ timely fashion. Failure to do so could lead to a deadlock when
+ critical frames, such as WINDOW_UPDATE, are not read and acted upon.
+
+5.3. Stream Priority
+
+ A client can assign a priority for a new stream by including
+ prioritization information in the HEADERS frame (Section 6.2) that
+ opens the stream. At any other time, the PRIORITY frame
+ (Section 6.3) can be used to change the priority of a stream.
+
+ The purpose of prioritization is to allow an endpoint to express how
+ it would prefer its peer to allocate resources when managing
+ concurrent streams. Most importantly, priority can be used to select
+ streams for transmitting frames when there is limited capacity for
+ sending.
+
+ Streams can be prioritized by marking them as dependent on the
+ completion of other streams (Section 5.3.1). Each dependency is
+ assigned a relative weight, a number that is used to determine the
+ relative proportion of available resources that are assigned to
+ streams dependent on the same stream.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 24]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Explicitly setting the priority for a stream is input to a
+ prioritization process. It does not guarantee any particular
+ processing or transmission order for the stream relative to any other
+ stream. An endpoint cannot force a peer to process concurrent
+ streams in a particular order using priority. Expressing priority is
+ therefore only a suggestion.
+
+ Prioritization information can be omitted from messages. Defaults
+ are used prior to any explicit values being provided (Section 5.3.5).
+
+5.3.1. Stream Dependencies
+
+ Each stream can be given an explicit dependency on another stream.
+ Including a dependency expresses a preference to allocate resources
+ to the identified stream rather than to the dependent stream.
+
+ A stream that is not dependent on any other stream is given a stream
+ dependency of 0x0. In other words, the non-existent stream 0 forms
+ the root of the tree.
+
+ A stream that depends on another stream is a dependent stream. The
+ stream upon which a stream is dependent is a parent stream. A
+ dependency on a stream that is not currently in the tree -- such as a
+ stream in the "idle" state -- results in that stream being given a
+ default priority (Section 5.3.5).
+
+ When assigning a dependency on another stream, the stream is added as
+ a new dependency of the parent stream. Dependent streams that share
+ the same parent are not ordered with respect to each other. For
+ example, if streams B and C are dependent on stream A, and if stream
+ D is created with a dependency on stream A, this results in a
+ dependency order of A followed by B, C, and D in any order.
+
+ A A
+ / \ ==> /|\
+ B C B D C
+
+ Figure 3: Example of Default Dependency Creation
+
+ An exclusive flag allows for the insertion of a new level of
+ dependencies. The exclusive flag causes the stream to become the
+ sole dependency of its parent stream, causing other dependencies to
+ become dependent on the exclusive stream. In the previous example,
+ if stream D is created with an exclusive dependency on stream A, this
+ results in D becoming the dependency parent of B and C.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 25]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A
+ A |
+ / \ ==> D
+ B C / \
+ B C
+
+ Figure 4: Example of Exclusive Dependency Creation
+
+ Inside the dependency tree, a dependent stream SHOULD only be
+ allocated resources if either all of the streams that it depends on
+ (the chain of parent streams up to 0x0) are closed or it is not
+ possible to make progress on them.
+
+ A stream cannot depend on itself. An endpoint MUST treat this as a
+ stream error (Section 5.4.2) of type PROTOCOL_ERROR.
+
+5.3.2. Dependency Weighting
+
+ All dependent streams are allocated an integer weight between 1 and
+ 256 (inclusive).
+
+ Streams with the same parent SHOULD be allocated resources
+ proportionally based on their weight. Thus, if stream B depends on
+ stream A with weight 4, stream C depends on stream A with weight 12,
+ and no progress can be made on stream A, stream B ideally receives
+ one-third of the resources allocated to stream C.
+
+5.3.3. Reprioritization
+
+ Stream priorities are changed using the PRIORITY frame. Setting a
+ dependency causes a stream to become dependent on the identified
+ parent stream.
+
+ Dependent streams move with their parent stream if the parent is
+ reprioritized. Setting a dependency with the exclusive flag for a
+ reprioritized stream causes all the dependencies of the new parent
+ stream to become dependent on the reprioritized stream.
+
+ If a stream is made dependent on one of its own dependencies, the
+ formerly dependent stream is first moved to be dependent on the
+ reprioritized stream's previous parent. The moved dependency retains
+ its weight.
+
+ For example, consider an original dependency tree where B and C
+ depend on A, D and E depend on C, and F depends on D. If A is made
+ dependent on D, then D takes the place of A. All other dependency
+ relationships stay the same, except for F, which becomes dependent on
+ A if the reprioritization is exclusive.
+
+
+
+Belshe, et al. Standards Track [Page 26]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ x x x x
+ | / \ | |
+ A D A D D
+ / \ / / \ / \ |
+ B C ==> F B C ==> F A OR A
+ / \ | / \ /|\
+ D E E B C B C F
+ | | |
+ F E E
+ (intermediate) (non-exclusive) (exclusive)
+
+ Figure 5: Example of Dependency Reordering
+
+5.3.4. Prioritization State Management
+
+ When a stream is removed from the dependency tree, its dependencies
+ can be moved to become dependent on the parent of the closed stream.
+ The weights of new dependencies are recalculated by distributing the
+ weight of the dependency of the closed stream proportionally based on
+ the weights of its dependencies.
+
+ Streams that are removed from the dependency tree cause some
+ prioritization information to be lost. Resources are shared between
+ streams with the same parent stream, which means that if a stream in
+ that set closes or becomes blocked, any spare capacity allocated to a
+ stream is distributed to the immediate neighbors of the stream.
+ However, if the common dependency is removed from the tree, those
+ streams share resources with streams at the next highest level.
+
+ For example, assume streams A and B share a parent, and streams C and
+ D both depend on stream A. Prior to the removal of stream A, if
+ streams A and D are unable to proceed, then stream C receives all the
+ resources dedicated to stream A. If stream A is removed from the
+ tree, the weight of stream A is divided between streams C and D. If
+ stream D is still unable to proceed, this results in stream C
+ receiving a reduced proportion of resources. For equal starting
+ weights, C receives one third, rather than one half, of available
+ resources.
+
+ It is possible for a stream to become closed while prioritization
+ information that creates a dependency on that stream is in transit.
+ If a stream identified in a dependency has no associated priority
+ information, then the dependent stream is instead assigned a default
+ priority (Section 5.3.5). This potentially creates suboptimal
+ prioritization, since the stream could be given a priority that is
+ different from what is intended.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 27]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ To avoid these problems, an endpoint SHOULD retain stream
+ prioritization state for a period after streams become closed. The
+ longer state is retained, the lower the chance that streams are
+ assigned incorrect or default priority values.
+
+ Similarly, streams that are in the "idle" state can be assigned
+ priority or become a parent of other streams. This allows for the
+ creation of a grouping node in the dependency tree, which enables
+ more flexible expressions of priority. Idle streams begin with a
+ default priority (Section 5.3.5).
+
+ The retention of priority information for streams that are not
+ counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could
+ create a large state burden for an endpoint. Therefore, the amount
+ of prioritization state that is retained MAY be limited.
+
+ The amount of additional state an endpoint maintains for
+ prioritization could be dependent on load; under high load,
+ prioritization state can be discarded to limit resource commitments.
+ In extreme cases, an endpoint could even discard prioritization state
+ for active or reserved streams. If a limit is applied, endpoints
+ SHOULD maintain state for at least as many streams as allowed by
+ their setting for SETTINGS_MAX_CONCURRENT_STREAMS. Implementations
+ SHOULD also attempt to retain state for streams that are in active
+ use in the priority tree.
+
+ If it has retained enough state to do so, an endpoint receiving a
+ PRIORITY frame that changes the priority of a closed stream SHOULD
+ alter the dependencies of the streams that depend on it.
+
+5.3.5. Default Priorities
+
+ All streams are initially assigned a non-exclusive dependency on
+ stream 0x0. Pushed streams (Section 8.2) initially depend on their
+ associated stream. In both cases, streams are assigned a default
+ weight of 16.
+
+5.4. Error Handling
+
+ HTTP/2 framing permits two classes of error:
+
+ o An error condition that renders the entire connection unusable is
+ a connection error.
+
+ o An error in an individual stream is a stream error.
+
+ A list of error codes is included in Section 7.
+
+
+
+
+Belshe, et al. Standards Track [Page 28]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+5.4.1. Connection Error Handling
+
+ A connection error is any error that prevents further processing of
+ the frame layer or corrupts any connection state.
+
+ An endpoint that encounters a connection error SHOULD first send a
+ GOAWAY frame (Section 6.8) with the stream identifier of the last
+ stream that it successfully received from its peer. The GOAWAY frame
+ includes an error code that indicates why the connection is
+ terminating. After sending the GOAWAY frame for an error condition,
+ the endpoint MUST close the TCP connection.
+
+ It is possible that the GOAWAY will not be reliably received by the
+ receiving endpoint ([RFC7230], Section 6.6 describes how an immediate
+ connection close can result in data loss). In the event of a
+ connection error, GOAWAY only provides a best-effort attempt to
+ communicate with the peer about why the connection is being
+ terminated.
+
+ An endpoint can end a connection at any time. In particular, an
+ endpoint MAY choose to treat a stream error as a connection error.
+ Endpoints SHOULD send a GOAWAY frame when ending a connection,
+ providing that circumstances permit it.
+
+5.4.2. Stream Error Handling
+
+ A stream error is an error related to a specific stream that does not
+ affect processing of other streams.
+
+ An endpoint that detects a stream error sends a RST_STREAM frame
+ (Section 6.4) that contains the stream identifier of the stream where
+ the error occurred. The RST_STREAM frame includes an error code that
+ indicates the type of error.
+
+ A RST_STREAM is the last frame that an endpoint can send on a stream.
+ The peer that sends the RST_STREAM frame MUST be prepared to receive
+ any frames that were sent or enqueued for sending by the remote peer.
+ These frames can be ignored, except where they modify connection
+ state (such as the state maintained for header compression
+ (Section 4.3) or flow control).
+
+ Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
+ for any stream. However, an endpoint MAY send additional RST_STREAM
+ frames if it receives frames on a closed stream after more than a
+ round-trip time. This behavior is permitted to deal with misbehaving
+ implementations.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 29]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ To avoid looping, an endpoint MUST NOT send a RST_STREAM in response
+ to a RST_STREAM frame.
+
+5.4.3. Connection Termination
+
+ If the TCP connection is closed or reset while streams remain in
+ "open" or "half-closed" state, then the affected streams cannot be
+ automatically retried (see Section 8.1.4 for details).
+
+5.5. Extending HTTP/2
+
+ HTTP/2 permits extension of the protocol. Within the limitations
+ described in this section, protocol extensions can be used to provide
+ additional services or alter any aspect of the protocol. Extensions
+ are effective only within the scope of a single HTTP/2 connection.
+
+ This applies to the protocol elements defined in this document. This
+ does not affect the existing options for extending HTTP, such as
+ defining new methods, status codes, or header fields.
+
+ Extensions are permitted to use new frame types (Section 4.1), new
+ settings (Section 6.5.2), or new error codes (Section 7). Registries
+ are established for managing these extension points: frame types
+ (Section 11.2), settings (Section 11.3), and error codes
+ (Section 11.4).
+
+ Implementations MUST ignore unknown or unsupported values in all
+ extensible protocol elements. Implementations MUST discard frames
+ that have unknown or unsupported types. This means that any of these
+ extension points can be safely used by extensions without prior
+ arrangement or negotiation. However, extension frames that appear in
+ the middle of a header block (Section 4.3) are not permitted; these
+ MUST be treated as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ Extensions that could change the semantics of existing protocol
+ components MUST be negotiated before being used. For example, an
+ extension that changes the layout of the HEADERS frame cannot be used
+ until the peer has given a positive signal that this is acceptable.
+ In this case, it could also be necessary to coordinate when the
+ revised layout comes into effect. Note that treating any frames
+ other than DATA frames as flow controlled is such a change in
+ semantics and can only be done through negotiation.
+
+ This document doesn't mandate a specific method for negotiating the
+ use of an extension but notes that a setting (Section 6.5.2) could be
+ used for that purpose. If both peers set a value that indicates
+ willingness to use the extension, then the extension can be used. If
+
+
+
+Belshe, et al. Standards Track [Page 30]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ a setting is used for extension negotiation, the initial value MUST
+ be defined in such a fashion that the extension is initially
+ disabled.
+
+6. Frame Definitions
+
+ This specification defines a number of frame types, each identified
+ by a unique 8-bit type code. Each frame type serves a distinct
+ purpose in the establishment and management either of the connection
+ as a whole or of individual streams.
+
+ The transmission of specific frame types can alter the state of a
+ connection. If endpoints fail to maintain a synchronized view of the
+ connection state, successful communication within the connection will
+ no longer be possible. Therefore, it is important that endpoints
+ have a shared comprehension of how the state is affected by the use
+ any given frame.
+
+6.1. DATA
+
+ DATA frames (type=0x0) convey arbitrary, variable-length sequences of
+ octets associated with a stream. One or more DATA frames are used,
+ for instance, to carry HTTP request or response payloads.
+
+ DATA frames MAY also contain padding. Padding can be added to DATA
+ frames to obscure the size of messages. Padding is a security
+ feature; see Section 10.7.
+
+ +---------------+
+ |Pad Length? (8)|
+ +---------------+-----------------------------------------------+
+ | Data (*) ...
+ +---------------------------------------------------------------+
+ | Padding (*) ...
+ +---------------------------------------------------------------+
+
+ Figure 6: DATA Frame Payload
+
+ The DATA frame contains the following fields:
+
+ Pad Length: An 8-bit field containing the length of the frame
+ padding in units of octets. This field is conditional (as
+ signified by a "?" in the diagram) and is only present if the
+ PADDED flag is set.
+
+ Data: Application data. The amount of data is the remainder of the
+ frame payload after subtracting the length of the other fields
+ that are present.
+
+
+
+Belshe, et al. Standards Track [Page 31]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Padding: Padding octets that contain no application semantic value.
+ Padding octets MUST be set to zero when sending. A receiver is
+ not obligated to verify padding but MAY treat non-zero padding as
+ a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ The DATA frame defines the following flags:
+
+ END_STREAM (0x1): When set, bit 0 indicates that this frame is the
+ last that the endpoint will send for the identified stream.
+ Setting this flag causes the stream to enter one of the "half-
+ closed" states or the "closed" state (Section 5.1).
+
+ PADDED (0x8): When set, bit 3 indicates that the Pad Length field
+ and any padding that it describes are present.
+
+ DATA frames MUST be associated with a stream. If a DATA frame is
+ received whose stream identifier field is 0x0, the recipient MUST
+ respond with a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ DATA frames are subject to flow control and can only be sent when a
+ stream is in the "open" or "half-closed (remote)" state. The entire
+ DATA frame payload is included in flow control, including the Pad
+ Length and Padding fields if present. If a DATA frame is received
+ whose stream is not in "open" or "half-closed (local)" state, the
+ recipient MUST respond with a stream error (Section 5.4.2) of type
+ STREAM_CLOSED.
+
+ The total number of padding octets is determined by the value of the
+ Pad Length field. If the length of the padding is the length of the
+ frame payload or greater, the recipient MUST treat this as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ Note: A frame can be increased in size by one octet by including a
+ Pad Length field with a value of zero.
+
+6.2. HEADERS
+
+ The HEADERS frame (type=0x1) is used to open a stream (Section 5.1),
+ and additionally carries a header block fragment. HEADERS frames can
+ be sent on a stream in the "idle", "reserved (local)", "open", or
+ "half-closed (remote)" state.
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 32]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ +---------------+
+ |Pad Length? (8)|
+ +-+-------------+-----------------------------------------------+
+ |E| Stream Dependency? (31) |
+ +-+-------------+-----------------------------------------------+
+ | Weight? (8) |
+ +-+-------------+-----------------------------------------------+
+ | Header Block Fragment (*) ...
+ +---------------------------------------------------------------+
+ | Padding (*) ...
+ +---------------------------------------------------------------+
+
+ Figure 7: HEADERS Frame Payload
+
+ The HEADERS frame payload has the following fields:
+
+ Pad Length: An 8-bit field containing the length of the frame
+ padding in units of octets. This field is only present if the
+ PADDED flag is set.
+
+ E: A single-bit flag indicating that the stream dependency is
+ exclusive (see Section 5.3). This field is only present if the
+ PRIORITY flag is set.
+
+ Stream Dependency: A 31-bit stream identifier for the stream that
+ this stream depends on (see Section 5.3). This field is only
+ present if the PRIORITY flag is set.
+
+ Weight: An unsigned 8-bit integer representing a priority weight for
+ the stream (see Section 5.3). Add one to the value to obtain a
+ weight between 1 and 256. This field is only present if the
+ PRIORITY flag is set.
+
+ Header Block Fragment: A header block fragment (Section 4.3).
+
+ Padding: Padding octets.
+
+ The HEADERS frame defines the following flags:
+
+ END_STREAM (0x1): When set, bit 0 indicates that the header block
+ (Section 4.3) is the last that the endpoint will send for the
+ identified stream.
+
+ A HEADERS frame carries the END_STREAM flag that signals the end
+ of a stream. However, a HEADERS frame with the END_STREAM flag
+ set can be followed by CONTINUATION frames on the same stream.
+ Logically, the CONTINUATION frames are part of the HEADERS frame.
+
+
+
+
+Belshe, et al. Standards Track [Page 33]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ END_HEADERS (0x4): When set, bit 2 indicates that this frame
+ contains an entire header block (Section 4.3) and is not followed
+ by any CONTINUATION frames.
+
+ A HEADERS frame without the END_HEADERS flag set MUST be followed
+ by a CONTINUATION frame for the same stream. A receiver MUST
+ treat the receipt of any other type of frame or a frame on a
+ different stream as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ PADDED (0x8): When set, bit 3 indicates that the Pad Length field
+ and any padding that it describes are present.
+
+ PRIORITY (0x20): When set, bit 5 indicates that the Exclusive Flag
+ (E), Stream Dependency, and Weight fields are present; see
+ Section 5.3.
+
+ The payload of a HEADERS frame contains a header block fragment
+ (Section 4.3). A header block that does not fit within a HEADERS
+ frame is continued in a CONTINUATION frame (Section 6.10).
+
+ HEADERS frames MUST be associated with a stream. If a HEADERS frame
+ is received whose stream identifier field is 0x0, the recipient MUST
+ respond with a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ The HEADERS frame changes the connection state as described in
+ Section 4.3.
+
+ The HEADERS frame can include padding. Padding fields and flags are
+ identical to those defined for DATA frames (Section 6.1). Padding
+ that exceeds the size remaining for the header block fragment MUST be
+ treated as a PROTOCOL_ERROR.
+
+ Prioritization information in a HEADERS frame is logically equivalent
+ to a separate PRIORITY frame, but inclusion in HEADERS avoids the
+ potential for churn in stream prioritization when new streams are
+ created. Prioritization fields in HEADERS frames subsequent to the
+ first on a stream reprioritize the stream (Section 5.3.3).
+
+6.3. PRIORITY
+
+ The PRIORITY frame (type=0x2) specifies the sender-advised priority
+ of a stream (Section 5.3). It can be sent in any stream state,
+ including idle or closed streams.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 34]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ +-+-------------------------------------------------------------+
+ |E| Stream Dependency (31) |
+ +-+-------------+-----------------------------------------------+
+ | Weight (8) |
+ +-+-------------+
+
+ Figure 8: PRIORITY Frame Payload
+
+ The payload of a PRIORITY frame contains the following fields:
+
+ E: A single-bit flag indicating that the stream dependency is
+ exclusive (see Section 5.3).
+
+ Stream Dependency: A 31-bit stream identifier for the stream that
+ this stream depends on (see Section 5.3).
+
+ Weight: An unsigned 8-bit integer representing a priority weight for
+ the stream (see Section 5.3). Add one to the value to obtain a
+ weight between 1 and 256.
+
+ The PRIORITY frame does not define any flags.
+
+ The PRIORITY frame always identifies a stream. If a PRIORITY frame
+ is received with a stream identifier of 0x0, the recipient MUST
+ respond with a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ The PRIORITY frame can be sent on a stream in any state, though it
+ cannot be sent between consecutive frames that comprise a single
+ header block (Section 4.3). Note that this frame could arrive after
+ processing or frame sending has completed, which would cause it to
+ have no effect on the identified stream. For a stream that is in the
+ "half-closed (remote)" or "closed" state, this frame can only affect
+ processing of the identified stream and its dependent streams; it
+ does not affect frame transmission on that stream.
+
+ The PRIORITY frame can be sent for a stream in the "idle" or "closed"
+ state. This allows for the reprioritization of a group of dependent
+ streams by altering the priority of an unused or closed parent
+ stream.
+
+ A PRIORITY frame with a length other than 5 octets MUST be treated as
+ a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR.
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 35]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+6.4. RST_STREAM
+
+ The RST_STREAM frame (type=0x3) allows for immediate termination of a
+ stream. RST_STREAM is sent to request cancellation of a stream or to
+ indicate that an error condition has occurred.
+
+ +---------------------------------------------------------------+
+ | Error Code (32) |
+ +---------------------------------------------------------------+
+
+ Figure 9: RST_STREAM Frame Payload
+
+ The RST_STREAM frame contains a single unsigned, 32-bit integer
+ identifying the error code (Section 7). The error code indicates why
+ the stream is being terminated.
+
+ The RST_STREAM frame does not define any flags.
+
+ The RST_STREAM frame fully terminates the referenced stream and
+ causes it to enter the "closed" state. After receiving a RST_STREAM
+ on a stream, the receiver MUST NOT send additional frames for that
+ stream, with the exception of PRIORITY. However, after sending the
+ RST_STREAM, the sending endpoint MUST be prepared to receive and
+ process additional frames sent on the stream that might have been
+ sent by the peer prior to the arrival of the RST_STREAM.
+
+ RST_STREAM frames MUST be associated with a stream. If a RST_STREAM
+ frame is received with a stream identifier of 0x0, the recipient MUST
+ treat this as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ RST_STREAM frames MUST NOT be sent for a stream in the "idle" state.
+ If a RST_STREAM frame identifying an idle stream is received, the
+ recipient MUST treat this as a connection error (Section 5.4.1) of
+ type PROTOCOL_ERROR.
+
+ A RST_STREAM frame with a length other than 4 octets MUST be treated
+ as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
+
+6.5. SETTINGS
+
+ The SETTINGS frame (type=0x4) conveys configuration parameters that
+ affect how endpoints communicate, such as preferences and constraints
+ on peer behavior. The SETTINGS frame is also used to acknowledge the
+ receipt of those parameters. Individually, a SETTINGS parameter can
+ also be referred to as a "setting".
+
+
+
+
+
+Belshe, et al. Standards Track [Page 36]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ SETTINGS parameters are not negotiated; they describe characteristics
+ of the sending peer, which are used by the receiving peer. Different
+ values for the same parameter can be advertised by each peer. For
+ example, a client might set a high initial flow-control window,
+ whereas a server might set a lower value to conserve resources.
+
+ A SETTINGS frame MUST be sent by both endpoints at the start of a
+ connection and MAY be sent at any other time by either endpoint over
+ the lifetime of the connection. Implementations MUST support all of
+ the parameters defined by this specification.
+
+ Each parameter in a SETTINGS frame replaces any existing value for
+ that parameter. Parameters are processed in the order in which they
+ appear, and a receiver of a SETTINGS frame does not need to maintain
+ any state other than the current value of its parameters. Therefore,
+ the value of a SETTINGS parameter is the last value that is seen by a
+ receiver.
+
+ SETTINGS parameters are acknowledged by the receiving peer. To
+ enable this, the SETTINGS frame defines the following flag:
+
+ ACK (0x1): When set, bit 0 indicates that this frame acknowledges
+ receipt and application of the peer's SETTINGS frame. When this
+ bit is set, the payload of the SETTINGS frame MUST be empty.
+ Receipt of a SETTINGS frame with the ACK flag set and a length
+ field value other than 0 MUST be treated as a connection error
+ (Section 5.4.1) of type FRAME_SIZE_ERROR. For more information,
+ see Section 6.5.3 ("Settings Synchronization").
+
+ SETTINGS frames always apply to a connection, never a single stream.
+ The stream identifier for a SETTINGS frame MUST be zero (0x0). If an
+ endpoint receives a SETTINGS frame whose stream identifier field is
+ anything other than 0x0, the endpoint MUST respond with a connection
+ error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ The SETTINGS frame affects connection state. A badly formed or
+ incomplete SETTINGS frame MUST be treated as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ A SETTINGS frame with a length other than a multiple of 6 octets MUST
+ be treated as a connection error (Section 5.4.1) of type
+ FRAME_SIZE_ERROR.
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 37]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+6.5.1. SETTINGS Format
+
+ The payload of a SETTINGS frame consists of zero or more parameters,
+ each consisting of an unsigned 16-bit setting identifier and an
+ unsigned 32-bit value.
+
+ +-------------------------------+
+ | Identifier (16) |
+ +-------------------------------+-------------------------------+
+ | Value (32) |
+ +---------------------------------------------------------------+
+
+ Figure 10: Setting Format
+
+6.5.2. Defined SETTINGS Parameters
+
+ The following parameters are defined:
+
+ SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the
+ remote endpoint of the maximum size of the header compression
+ table used to decode header blocks, in octets. The encoder can
+ select any size equal to or less than this value by using
+ signaling specific to the header compression format inside a
+ header block (see [COMPRESSION]). The initial value is 4,096
+ octets.
+
+ SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable
+ server push (Section 8.2). An endpoint MUST NOT send a
+ PUSH_PROMISE frame if it receives this parameter set to a value of
+ 0. An endpoint that has both set this parameter to 0 and had it
+ acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ The initial value is 1, which indicates that server push is
+ permitted. Any value other than 0 or 1 MUST be treated as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number
+ of concurrent streams that the sender will allow. This limit is
+ directional: it applies to the number of streams that the sender
+ permits the receiver to create. Initially, there is no limit to
+ this value. It is recommended that this value be no smaller than
+ 100, so as to not unnecessarily limit parallelism.
+
+ A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
+ treated as special by endpoints. A zero value does prevent the
+ creation of new streams; however, this can also happen for any
+
+
+
+
+Belshe, et al. Standards Track [Page 38]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ limit that is exhausted with active streams. Servers SHOULD only
+ set a zero value for short durations; if a server does not wish to
+ accept requests, closing the connection is more appropriate.
+
+ SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
+ window size (in octets) for stream-level flow control. The
+ initial value is 2^16-1 (65,535) octets.
+
+ This setting affects the window size of all streams (see
+ Section 6.9.2).
+
+ Values above the maximum flow-control window size of 2^31-1 MUST
+ be treated as a connection error (Section 5.4.1) of type
+ FLOW_CONTROL_ERROR.
+
+ SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest
+ frame payload that the sender is willing to receive, in octets.
+
+ The initial value is 2^14 (16,384) octets. The value advertised
+ by an endpoint MUST be between this initial value and the maximum
+ allowed frame size (2^24-1 or 16,777,215 octets), inclusive.
+ Values outside this range MUST be treated as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a
+ peer of the maximum size of header list that the sender is
+ prepared to accept, in octets. The value is based on the
+ uncompressed size of header fields, including the length of the
+ name and value in octets plus an overhead of 32 octets for each
+ header field.
+
+ For any given request, a lower limit than what is advertised MAY
+ be enforced. The initial value of this setting is unlimited.
+
+ An endpoint that receives a SETTINGS frame with any unknown or
+ unsupported identifier MUST ignore that setting.
+
+6.5.3. Settings Synchronization
+
+ Most values in SETTINGS benefit from or require an understanding of
+ when the peer has received and applied the changed parameter values.
+ In order to provide such synchronization timepoints, the recipient of
+ a SETTINGS frame in which the ACK flag is not set MUST apply the
+ updated parameters as soon as possible upon receipt.
+
+ The values in the SETTINGS frame MUST be processed in the order they
+ appear, with no other frame processing between values. Unsupported
+ parameters MUST be ignored. Once all values have been processed, the
+
+
+
+Belshe, et al. Standards Track [Page 39]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ recipient MUST immediately emit a SETTINGS frame with the ACK flag
+ set. Upon receiving a SETTINGS frame with the ACK flag set, the
+ sender of the altered parameters can rely on the setting having been
+ applied.
+
+ If the sender of a SETTINGS frame does not receive an acknowledgement
+ within a reasonable amount of time, it MAY issue a connection error
+ (Section 5.4.1) of type SETTINGS_TIMEOUT.
+
+6.6. PUSH_PROMISE
+
+ The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
+ in advance of streams the sender intends to initiate. The
+ PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
+ stream the endpoint plans to create along with a set of headers that
+ provide additional context for the stream. Section 8.2 contains a
+ thorough description of the use of PUSH_PROMISE frames.
+
+ +---------------+
+ |Pad Length? (8)|
+ +-+-------------+-----------------------------------------------+
+ |R| Promised Stream ID (31) |
+ +-+-----------------------------+-------------------------------+
+ | Header Block Fragment (*) ...
+ +---------------------------------------------------------------+
+ | Padding (*) ...
+ +---------------------------------------------------------------+
+
+ Figure 11: PUSH_PROMISE Payload Format
+
+ The PUSH_PROMISE frame payload has the following fields:
+
+ Pad Length: An 8-bit field containing the length of the frame
+ padding in units of octets. This field is only present if the
+ PADDED flag is set.
+
+ R: A single reserved bit.
+
+ Promised Stream ID: An unsigned 31-bit integer that identifies the
+ stream that is reserved by the PUSH_PROMISE. The promised stream
+ identifier MUST be a valid choice for the next stream sent by the
+ sender (see "new stream identifier" in Section 5.1.1).
+
+ Header Block Fragment: A header block fragment (Section 4.3)
+ containing request header fields.
+
+ Padding: Padding octets.
+
+
+
+
+Belshe, et al. Standards Track [Page 40]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ The PUSH_PROMISE frame defines the following flags:
+
+ END_HEADERS (0x4): When set, bit 2 indicates that this frame
+ contains an entire header block (Section 4.3) and is not followed
+ by any CONTINUATION frames.
+
+ A PUSH_PROMISE frame without the END_HEADERS flag set MUST be
+ followed by a CONTINUATION frame for the same stream. A receiver
+ MUST treat the receipt of any other type of frame or a frame on a
+ different stream as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ PADDED (0x8): When set, bit 3 indicates that the Pad Length field
+ and any padding that it describes are present.
+
+ PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that
+ is in either the "open" or "half-closed (remote)" state. The stream
+ identifier of a PUSH_PROMISE frame indicates the stream it is
+ associated with. If the stream identifier field specifies the value
+ 0x0, a recipient MUST respond with a connection error (Section 5.4.1)
+ of type PROTOCOL_ERROR.
+
+ Promised streams are not required to be used in the order they are
+ promised. The PUSH_PROMISE only reserves stream identifiers for
+ later use.
+
+ PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of
+ the peer endpoint is set to 0. An endpoint that has set this setting
+ and has received acknowledgement MUST treat the receipt of a
+ PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ Recipients of PUSH_PROMISE frames can choose to reject promised
+ streams by returning a RST_STREAM referencing the promised stream
+ identifier back to the sender of the PUSH_PROMISE.
+
+ A PUSH_PROMISE frame modifies the connection state in two ways.
+ First, the inclusion of a header block (Section 4.3) potentially
+ modifies the state maintained for header compression. Second,
+ PUSH_PROMISE also reserves a stream for later use, causing the
+ promised stream to enter the "reserved" state. A sender MUST NOT
+ send a PUSH_PROMISE on a stream unless that stream is either "open"
+ or "half-closed (remote)"; the sender MUST ensure that the promised
+ stream is a valid choice for a new stream identifier (Section 5.1.1)
+ (that is, the promised stream MUST be in the "idle" state).
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 41]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame
+ causes the stream state to become indeterminate. A receiver MUST
+ treat the receipt of a PUSH_PROMISE on a stream that is neither
+ "open" nor "half-closed (local)" as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that
+ has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE
+ frames that might have been created before the RST_STREAM frame is
+ received and processed.
+
+ A receiver MUST treat the receipt of a PUSH_PROMISE that promises an
+ illegal stream identifier (Section 5.1.1) as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR. Note that an illegal stream
+ identifier is an identifier for a stream that is not currently in the
+ "idle" state.
+
+ The PUSH_PROMISE frame can include padding. Padding fields and flags
+ are identical to those defined for DATA frames (Section 6.1).
+
+6.7. PING
+
+ The PING frame (type=0x6) is a mechanism for measuring a minimal
+ round-trip time from the sender, as well as determining whether an
+ idle connection is still functional. PING frames can be sent from
+ any endpoint.
+
+ +---------------------------------------------------------------+
+ | |
+ | Opaque Data (64) |
+ | |
+ +---------------------------------------------------------------+
+
+ Figure 12: PING Payload Format
+
+ In addition to the frame header, PING frames MUST contain 8 octets of
+ opaque data in the payload. A sender can include any value it
+ chooses and use those octets in any fashion.
+
+ Receivers of a PING frame that does not include an ACK flag MUST send
+ a PING frame with the ACK flag set in response, with an identical
+ payload. PING responses SHOULD be given higher priority than any
+ other frame.
+
+ The PING frame defines the following flags:
+
+ ACK (0x1): When set, bit 0 indicates that this PING frame is a PING
+ response. An endpoint MUST set this flag in PING responses. An
+ endpoint MUST NOT respond to PING frames containing this flag.
+
+
+
+
+Belshe, et al. Standards Track [Page 42]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ PING frames are not associated with any individual stream. If a PING
+ frame is received with a stream identifier field value other than
+ 0x0, the recipient MUST respond with a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ Receipt of a PING frame with a length field value other than 8 MUST
+ be treated as a connection error (Section 5.4.1) of type
+ FRAME_SIZE_ERROR.
+
+6.8. GOAWAY
+
+ The GOAWAY frame (type=0x7) is used to initiate shutdown of a
+ connection or to signal serious error conditions. GOAWAY allows an
+ endpoint to gracefully stop accepting new streams while still
+ finishing processing of previously established streams. This enables
+ administrative actions, like server maintenance.
+
+ There is an inherent race condition between an endpoint starting new
+ streams and the remote sending a GOAWAY frame. To deal with this
+ case, the GOAWAY contains the stream identifier of the last peer-
+ initiated stream that was or might be processed on the sending
+ endpoint in this connection. For instance, if the server sends a
+ GOAWAY frame, the identified stream is the highest-numbered stream
+ initiated by the client.
+
+ Once sent, the sender will ignore frames sent on streams initiated by
+ the receiver if the stream has an identifier higher than the included
+ last stream identifier. Receivers of a GOAWAY frame MUST NOT open
+ additional streams on the connection, although a new connection can
+ be established for new streams.
+
+ If the receiver of the GOAWAY has sent data on streams with a higher
+ stream identifier than what is indicated in the GOAWAY frame, those
+ streams are not or will not be processed. The receiver of the GOAWAY
+ frame can treat the streams as though they had never been created at
+ all, thereby allowing those streams to be retried later on a new
+ connection.
+
+ Endpoints SHOULD always send a GOAWAY frame before closing a
+ connection so that the remote peer can know whether a stream has been
+ partially processed or not. For example, if an HTTP client sends a
+ POST at the same time that a server closes a connection, the client
+ cannot know if the server started to process that POST request if the
+ server does not send a GOAWAY frame to indicate what streams it might
+ have acted on.
+
+ An endpoint might choose to close a connection without sending a
+ GOAWAY for misbehaving peers.
+
+
+
+Belshe, et al. Standards Track [Page 43]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A GOAWAY frame might not immediately precede closing of the
+ connection; a receiver of a GOAWAY that has no more use for the
+ connection SHOULD still send a GOAWAY frame before terminating the
+ connection.
+
+ +-+-------------------------------------------------------------+
+ |R| Last-Stream-ID (31) |
+ +-+-------------------------------------------------------------+
+ | Error Code (32) |
+ +---------------------------------------------------------------+
+ | Additional Debug Data (*) |
+ +---------------------------------------------------------------+
+
+ Figure 13: GOAWAY Payload Format
+
+ The GOAWAY frame does not define any flags.
+
+ The GOAWAY frame applies to the connection, not a specific stream.
+ An endpoint MUST treat a GOAWAY frame with a stream identifier other
+ than 0x0 as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR.
+
+ The last stream identifier in the GOAWAY frame contains the highest-
+ numbered stream identifier for which the sender of the GOAWAY frame
+ might have taken some action on or might yet take action on. All
+ streams up to and including the identified stream might have been
+ processed in some way. The last stream identifier can be set to 0 if
+ no streams were processed.
+
+ Note: In this context, "processed" means that some data from the
+ stream was passed to some higher layer of software that might have
+ taken some action as a result.
+
+ If a connection terminates without a GOAWAY frame, the last stream
+ identifier is effectively the highest possible stream identifier.
+
+ On streams with lower- or equal-numbered identifiers that were not
+ closed completely prior to the connection being closed, reattempting
+ requests, transactions, or any protocol activity is not possible,
+ with the exception of idempotent actions like HTTP GET, PUT, or
+ DELETE. Any protocol activity that uses higher-numbered streams can
+ be safely retried using a new connection.
+
+ Activity on streams numbered lower or equal to the last stream
+ identifier might still complete successfully. The sender of a GOAWAY
+ frame might gracefully shut down a connection by sending a GOAWAY
+ frame, maintaining the connection in an "open" state until all in-
+ progress streams complete.
+
+
+
+Belshe, et al. Standards Track [Page 44]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ An endpoint MAY send multiple GOAWAY frames if circumstances change.
+ For instance, an endpoint that sends GOAWAY with NO_ERROR during
+ graceful shutdown could subsequently encounter a condition that
+ requires immediate termination of the connection. The last stream
+ identifier from the last GOAWAY frame received indicates which
+ streams could have been acted upon. Endpoints MUST NOT increase the
+ value they send in the last stream identifier, since the peers might
+ already have retried unprocessed requests on another connection.
+
+ A client that is unable to retry requests loses all requests that are
+ in flight when the server closes the connection. This is especially
+ true for intermediaries that might not be serving clients using
+ HTTP/2. A server that is attempting to gracefully shut down a
+ connection SHOULD send an initial GOAWAY frame with the last stream
+ identifier set to 2^31-1 and a NO_ERROR code. This signals to the
+ client that a shutdown is imminent and that initiating further
+ requests is prohibited. After allowing time for any in-flight stream
+ creation (at least one round-trip time), the server can send another
+ GOAWAY frame with an updated last stream identifier. This ensures
+ that a connection can be cleanly shut down without losing requests.
+
+ After sending a GOAWAY frame, the sender can discard frames for
+ streams initiated by the receiver with identifiers higher than the
+ identified last stream. However, any frames that alter connection
+ state cannot be completely ignored. For instance, HEADERS,
+ PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
+ ensure the state maintained for header compression is consistent (see
+ Section 4.3); similarly, DATA frames MUST be counted toward the
+ connection flow-control window. Failure to process these frames can
+ cause flow control or header compression state to become
+ unsynchronized.
+
+ The GOAWAY frame also contains a 32-bit error code (Section 7) that
+ contains the reason for closing the connection.
+
+ Endpoints MAY append opaque data to the payload of any GOAWAY frame.
+ Additional debug data is intended for diagnostic purposes only and
+ carries no semantic value. Debug information could contain security-
+ or privacy-sensitive data. Logged or otherwise persistently stored
+ debug data MUST have adequate safeguards to prevent unauthorized
+ access.
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 45]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+6.9. WINDOW_UPDATE
+
+ The WINDOW_UPDATE frame (type=0x8) is used to implement flow control;
+ see Section 5.2 for an overview.
+
+ Flow control operates at two levels: on each individual stream and on
+ the entire connection.
+
+ Both types of flow control are hop by hop, that is, only between the
+ two endpoints. Intermediaries do not forward WINDOW_UPDATE frames
+ between dependent connections. However, throttling of data transfer
+ by any receiver can indirectly cause the propagation of flow-control
+ information toward the original sender.
+
+ Flow control only applies to frames that are identified as being
+ subject to flow control. Of the frame types defined in this
+ document, this includes only DATA frames. Frames that are exempt
+ from flow control MUST be accepted and processed, unless the receiver
+ is unable to assign resources to handling the frame. A receiver MAY
+ respond with a stream error (Section 5.4.2) or connection error
+ (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept
+ a frame.
+
+ +-+-------------------------------------------------------------+
+ |R| Window Size Increment (31) |
+ +-+-------------------------------------------------------------+
+
+ Figure 14: WINDOW_UPDATE Payload Format
+
+ The payload of a WINDOW_UPDATE frame is one reserved bit plus an
+ unsigned 31-bit integer indicating the number of octets that the
+ sender can transmit in addition to the existing flow-control window.
+ The legal range for the increment to the flow-control window is 1 to
+ 2^31-1 (2,147,483,647) octets.
+
+ The WINDOW_UPDATE frame does not define any flags.
+
+ The WINDOW_UPDATE frame can be specific to a stream or to the entire
+ connection. In the former case, the frame's stream identifier
+ indicates the affected stream; in the latter, the value "0" indicates
+ that the entire connection is the subject of the frame.
+
+ A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an
+ flow-control window increment of 0 as a stream error (Section 5.4.2)
+ of type PROTOCOL_ERROR; errors on the connection flow-control window
+ MUST be treated as a connection error (Section 5.4.1).
+
+
+
+
+
+Belshe, et al. Standards Track [Page 46]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the
+ END_STREAM flag. This means that a receiver could receive a
+ WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream.
+ A receiver MUST NOT treat this as an error (see Section 5.1).
+
+ A receiver that receives a flow-controlled frame MUST always account
+ for its contribution against the connection flow-control window,
+ unless the receiver treats this as a connection error
+ (Section 5.4.1). This is necessary even if the frame is in error.
+ The sender counts the frame toward the flow-control window, but if
+ the receiver does not, the flow-control window at the sender and
+ receiver can become different.
+
+ A WINDOW_UPDATE frame with a length other than 4 octets MUST be
+ treated as a connection error (Section 5.4.1) of type
+ FRAME_SIZE_ERROR.
+
+6.9.1. The Flow-Control Window
+
+ Flow control in HTTP/2 is implemented using a window kept by each
+ sender on every stream. The flow-control window is a simple integer
+ value that indicates how many octets of data the sender is permitted
+ to transmit; as such, its size is a measure of the buffering capacity
+ of the receiver.
+
+ Two flow-control windows are applicable: the stream flow-control
+ window and the connection flow-control window. The sender MUST NOT
+ send a flow-controlled frame with a length that exceeds the space
+ available in either of the flow-control windows advertised by the
+ receiver. Frames with zero length with the END_STREAM flag set (that
+ is, an empty DATA frame) MAY be sent if there is no available space
+ in either flow-control window.
+
+ For flow-control calculations, the 9-octet frame header is not
+ counted.
+
+ After sending a flow-controlled frame, the sender reduces the space
+ available in both windows by the length of the transmitted frame.
+
+ The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
+ data and frees up space in flow-control windows. Separate
+ WINDOW_UPDATE frames are sent for the stream- and connection-level
+ flow-control windows.
+
+ A sender that receives a WINDOW_UPDATE frame updates the
+ corresponding window by the amount specified in the frame.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 47]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A sender MUST NOT allow a flow-control window to exceed 2^31-1
+ octets. If a sender receives a WINDOW_UPDATE that causes a flow-
+ control window to exceed this maximum, it MUST terminate either the
+ stream or the connection, as appropriate. For streams, the sender
+ sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
+ connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
+ is sent.
+
+ Flow-controlled frames from the sender and WINDOW_UPDATE frames from
+ the receiver are completely asynchronous with respect to each other.
+ This property allows a receiver to aggressively update the window
+ size kept by the sender to prevent streams from stalling.
+
+6.9.2. Initial Flow-Control Window Size
+
+ When an HTTP/2 connection is first established, new streams are
+ created with an initial flow-control window size of 65,535 octets.
+ The connection flow-control window is also 65,535 octets. Both
+ endpoints can adjust the initial window size for new streams by
+ including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS
+ frame that forms part of the connection preface. The connection
+ flow-control window can only be changed using WINDOW_UPDATE frames.
+
+ Prior to receiving a SETTINGS frame that sets a value for
+ SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default
+ initial window size when sending flow-controlled frames. Similarly,
+ the connection flow-control window is set to the default initial
+ window size until a WINDOW_UPDATE frame is received.
+
+ In addition to changing the flow-control window for streams that are
+ not yet active, a SETTINGS frame can alter the initial flow-control
+ window size for streams with active flow-control windows (that is,
+ streams in the "open" or "half-closed (remote)" state). When the
+ value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust
+ the size of all stream flow-control windows that it maintains by the
+ difference between the new value and the old value.
+
+ A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available
+ space in a flow-control window to become negative. A sender MUST
+ track the negative flow-control window and MUST NOT send new flow-
+ controlled frames until it receives WINDOW_UPDATE frames that cause
+ the flow-control window to become positive.
+
+ For example, if the client sends 60 KB immediately on connection
+ establishment and the server sets the initial window size to be 16
+ KB, the client will recalculate the available flow-control window to
+
+
+
+
+
+Belshe, et al. Standards Track [Page 48]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ be -44 KB on receipt of the SETTINGS frame. The client retains a
+ negative flow-control window until WINDOW_UPDATE frames restore the
+ window to being positive, after which the client can resume sending.
+
+ A SETTINGS frame cannot alter the connection flow-control window.
+
+ An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE that
+ causes any flow-control window to exceed the maximum size as a
+ connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
+
+6.9.3. Reducing the Stream Window Size
+
+ A receiver that wishes to use a smaller flow-control window than the
+ current size can send a new SETTINGS frame. However, the receiver
+ MUST be prepared to receive data that exceeds this window size, since
+ the sender might send data that exceeds the lower limit prior to
+ processing the SETTINGS frame.
+
+ After sending a SETTINGS frame that reduces the initial flow-control
+ window size, a receiver MAY continue to process streams that exceed
+ flow-control limits. Allowing streams to continue does not allow the
+ receiver to immediately reduce the space it reserves for flow-control
+ windows. Progress on these streams can also stall, since
+ WINDOW_UPDATE frames are needed to allow the sender to resume
+ sending. The receiver MAY instead send a RST_STREAM with an error
+ code of FLOW_CONTROL_ERROR for the affected streams.
+
+6.10. CONTINUATION
+
+ The CONTINUATION frame (type=0x9) is used to continue a sequence of
+ header block fragments (Section 4.3). Any number of CONTINUATION
+ frames can be sent, as long as the preceding frame is on the same
+ stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without
+ the END_HEADERS flag set.
+
+ +---------------------------------------------------------------+
+ | Header Block Fragment (*) ...
+ +---------------------------------------------------------------+
+
+ Figure 15: CONTINUATION Frame Payload
+
+ The CONTINUATION frame payload contains a header block fragment
+ (Section 4.3).
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 49]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ The CONTINUATION frame defines the following flag:
+
+ END_HEADERS (0x4): When set, bit 2 indicates that this frame ends a
+ header block (Section 4.3).
+
+ If the END_HEADERS bit is not set, this frame MUST be followed by
+ another CONTINUATION frame. A receiver MUST treat the receipt of
+ any other type of frame or a frame on a different stream as a
+ connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+ The CONTINUATION frame changes the connection state as defined in
+ Section 4.3.
+
+ CONTINUATION frames MUST be associated with a stream. If a
+ CONTINUATION frame is received whose stream identifier field is 0x0,
+ the recipient MUST respond with a connection error (Section 5.4.1) of
+ type PROTOCOL_ERROR.
+
+ A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or
+ CONTINUATION frame without the END_HEADERS flag set. A recipient
+ that observes violation of this rule MUST respond with a connection
+ error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+7. Error Codes
+
+ Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY
+ frames to convey the reasons for the stream or connection error.
+
+ Error codes share a common code space. Some error codes apply only
+ to either streams or the entire connection and have no defined
+ semantics in the other context.
+
+ The following error codes are defined:
+
+ NO_ERROR (0x0): The associated condition is not a result of an
+ error. For example, a GOAWAY might include this code to indicate
+ graceful shutdown of a connection.
+
+ PROTOCOL_ERROR (0x1): The endpoint detected an unspecific protocol
+ error. This error is for use when a more specific error code is
+ not available.
+
+ INTERNAL_ERROR (0x2): The endpoint encountered an unexpected
+ internal error.
+
+ FLOW_CONTROL_ERROR (0x3): The endpoint detected that its peer
+ violated the flow-control protocol.
+
+
+
+
+Belshe, et al. Standards Track [Page 50]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ SETTINGS_TIMEOUT (0x4): The endpoint sent a SETTINGS frame but did
+ not receive a response in a timely manner. See Section 6.5.3
+ ("Settings Synchronization").
+
+ STREAM_CLOSED (0x5): The endpoint received a frame after a stream
+ was half-closed.
+
+ FRAME_SIZE_ERROR (0x6): The endpoint received a frame with an
+ invalid size.
+
+ REFUSED_STREAM (0x7): The endpoint refused the stream prior to
+ performing any application processing (see Section 8.1.4 for
+ details).
+
+ CANCEL (0x8): Used by the endpoint to indicate that the stream is no
+ longer needed.
+
+ COMPRESSION_ERROR (0x9): The endpoint is unable to maintain the
+ header compression context for the connection.
+
+ CONNECT_ERROR (0xa): The connection established in response to a
+ CONNECT request (Section 8.3) was reset or abnormally closed.
+
+ ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is
+ exhibiting a behavior that might be generating excessive load.
+
+ INADEQUATE_SECURITY (0xc): The underlying transport has properties
+ that do not meet minimum security requirements (see Section 9.2).
+
+ HTTP_1_1_REQUIRED (0xd): The endpoint requires that HTTP/1.1 be used
+ instead of HTTP/2.
+
+ Unknown or unsupported error codes MUST NOT trigger any special
+ behavior. These MAY be treated by an implementation as being
+ equivalent to INTERNAL_ERROR.
+
+8. HTTP Message Exchanges
+
+ HTTP/2 is intended to be as compatible as possible with current uses
+ of HTTP. This means that, from the application perspective, the
+ features of the protocol are largely unchanged. To achieve this, all
+ request and response semantics are preserved, although the syntax of
+ conveying those semantics has changed.
+
+ Thus, the specification and requirements of HTTP/1.1 Semantics and
+ Content [RFC7231], Conditional Requests [RFC7232], Range Requests
+ [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
+ applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax
+
+
+
+Belshe, et al. Standards Track [Page 51]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
+ also applicable in HTTP/2, but the expression of those semantics for
+ this protocol are defined in the sections below.
+
+8.1. HTTP Request/Response Exchange
+
+ A client sends an HTTP request on a new stream, using a previously
+ unused stream identifier (Section 5.1.1). A server sends an HTTP
+ response on the same stream as the request.
+
+ An HTTP message (request or response) consists of:
+
+ 1. for a response only, zero or more HEADERS frames (each followed
+ by zero or more CONTINUATION frames) containing the message
+ headers of informational (1xx) HTTP responses (see [RFC7230],
+ Section 3.2 and [RFC7231], Section 6.2),
+
+ 2. one HEADERS frame (followed by zero or more CONTINUATION frames)
+ containing the message headers (see [RFC7230], Section 3.2),
+
+ 3. zero or more DATA frames containing the payload body (see
+ [RFC7230], Section 3.3), and
+
+ 4. optionally, one HEADERS frame, followed by zero or more
+ CONTINUATION frames containing the trailer-part, if present (see
+ [RFC7230], Section 4.1.2).
+
+ The last frame in the sequence bears an END_STREAM flag, noting that
+ a HEADERS frame bearing the END_STREAM flag can be followed by
+ CONTINUATION frames that carry any remaining portions of the header
+ block.
+
+ Other frames (from any stream) MUST NOT occur between the HEADERS
+ frame and any CONTINUATION frames that might follow.
+
+ HTTP/2 uses DATA frames to carry message payloads. The "chunked"
+ transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be
+ used in HTTP/2.
+
+ Trailing header fields are carried in a header block that also
+ terminates the stream. Such a header block is a sequence starting
+ with a HEADERS frame, followed by zero or more CONTINUATION frames,
+ where the HEADERS frame bears an END_STREAM flag. Header blocks
+ after the first that do not terminate the stream are not part of an
+ HTTP request or response.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 52]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A HEADERS frame (and associated CONTINUATION frames) can only appear
+ at the start or end of a stream. An endpoint that receives a HEADERS
+ frame without the END_STREAM flag set after receiving a final (non-
+ informational) status code MUST treat the corresponding request or
+ response as malformed (Section 8.1.2.6).
+
+ An HTTP request/response exchange fully consumes a single stream. A
+ request starts with the HEADERS frame that puts the stream into an
+ "open" state. The request ends with a frame bearing END_STREAM,
+ which causes the stream to become "half-closed (local)" for the
+ client and "half-closed (remote)" for the server. A response starts
+ with a HEADERS frame and ends with a frame bearing END_STREAM, which
+ places the stream in the "closed" state.
+
+ An HTTP response is complete after the server sends -- or the client
+ receives -- a frame with the END_STREAM flag set (including any
+ CONTINUATION frames needed to complete a header block). A server can
+ send a complete response prior to the client sending an entire
+ request if the response does not depend on any portion of the request
+ that has not been sent and received. When this is true, a server MAY
+ request that the client abort transmission of a request without error
+ by sending a RST_STREAM with an error code of NO_ERROR after sending
+ a complete response (i.e., a frame with the END_STREAM flag).
+ Clients MUST NOT discard responses as a result of receiving such a
+ RST_STREAM, though clients can always discard responses at their
+ discretion for other reasons.
+
+8.1.1. Upgrading from HTTP/2
+
+ HTTP/2 removes support for the 101 (Switching Protocols)
+ informational status code ([RFC7231], Section 6.2.2).
+
+ The semantics of 101 (Switching Protocols) aren't applicable to a
+ multiplexed protocol. Alternative protocols are able to use the same
+ mechanisms that HTTP/2 uses to negotiate their use (see Section 3).
+
+8.1.2. HTTP Header Fields
+
+ HTTP header fields carry information as a series of key-value pairs.
+ For a listing of registered HTTP headers, see the "Message Header
+ Field" registry maintained at <https://www.iana.org/assignments/
+ message-headers>.
+
+ Just as in HTTP/1.x, header field names are strings of ASCII
+ characters that are compared in a case-insensitive fashion. However,
+ header field names MUST be converted to lowercase prior to their
+ encoding in HTTP/2. A request or response containing uppercase
+ header field names MUST be treated as malformed (Section 8.1.2.6).
+
+
+
+Belshe, et al. Standards Track [Page 53]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.1.2.1. Pseudo-Header Fields
+
+ While HTTP/1.x used the message start-line (see [RFC7230],
+ Section 3.1) to convey the target URI, the method of the request, and
+ the status code for the response, HTTP/2 uses special pseudo-header
+ fields beginning with ':' character (ASCII 0x3a) for this purpose.
+
+ Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
+ generate pseudo-header fields other than those defined in this
+ document.
+
+ Pseudo-header fields are only valid in the context in which they are
+ defined. Pseudo-header fields defined for requests MUST NOT appear
+ in responses; pseudo-header fields defined for responses MUST NOT
+ appear in requests. Pseudo-header fields MUST NOT appear in
+ trailers. Endpoints MUST treat a request or response that contains
+ undefined or invalid pseudo-header fields as malformed
+ (Section 8.1.2.6).
+
+ All pseudo-header fields MUST appear in the header block before
+ regular header fields. Any request or response that contains a
+ pseudo-header field that appears in a header block after a regular
+ header field MUST be treated as malformed (Section 8.1.2.6).
+
+8.1.2.2. Connection-Specific Header Fields
+
+ HTTP/2 does not use the Connection header field to indicate
+ connection-specific header fields; in this protocol, connection-
+ specific metadata is conveyed by other means. An endpoint MUST NOT
+ generate an HTTP/2 message containing connection-specific header
+ fields; any message containing connection-specific header fields MUST
+ be treated as malformed (Section 8.1.2.6).
+
+ The only exception to this is the TE header field, which MAY be
+ present in an HTTP/2 request; when it is, it MUST NOT contain any
+ value other than "trailers".
+
+ This means that an intermediary transforming an HTTP/1.x message to
+ HTTP/2 will need to remove any header fields nominated by the
+ Connection header field, along with the Connection header field
+ itself. Such intermediaries SHOULD also remove other connection-
+ specific header fields, such as Keep-Alive, Proxy-Connection,
+ Transfer-Encoding, and Upgrade, even if they are not nominated by the
+ Connection header field.
+
+ Note: HTTP/2 purposefully does not support upgrade to another
+ protocol. The handshake methods described in Section 3 are
+ believed sufficient to negotiate the use of alternative protocols.
+
+
+
+Belshe, et al. Standards Track [Page 54]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.1.2.3. Request Pseudo-Header Fields
+
+ The following pseudo-header fields are defined for HTTP/2 requests:
+
+ o The ":method" pseudo-header field includes the HTTP method
+ ([RFC7231], Section 4).
+
+ o The ":scheme" pseudo-header field includes the scheme portion of
+ the target URI ([RFC3986], Section 3.1).
+
+ ":scheme" is not restricted to "http" and "https" schemed URIs. A
+ proxy or gateway can translate requests for non-HTTP schemes,
+ enabling the use of HTTP to interact with non-HTTP services.
+
+ o The ":authority" pseudo-header field includes the authority
+ portion of the target URI ([RFC3986], Section 3.2). The authority
+ MUST NOT include the deprecated "userinfo" subcomponent for "http"
+ or "https" schemed URIs.
+
+ To ensure that the HTTP/1.1 request line can be reproduced
+ accurately, this pseudo-header field MUST be omitted when
+ translating from an HTTP/1.1 request that has a request target in
+ origin or asterisk form (see [RFC7230], Section 5.3). Clients
+ that generate HTTP/2 requests directly SHOULD use the ":authority"
+ pseudo-header field instead of the Host header field. An
+ intermediary that converts an HTTP/2 request to HTTP/1.1 MUST
+ create a Host header field if one is not present in a request by
+ copying the value of the ":authority" pseudo-header field.
+
+ o The ":path" pseudo-header field includes the path and query parts
+ of the target URI (the "path-absolute" production and optionally a
+ '?' character followed by the "query" production (see Sections 3.3
+ and 3.4 of [RFC3986]). A request in asterisk form includes the
+ value '*' for the ":path" pseudo-header field.
+
+ This pseudo-header field MUST NOT be empty for "http" or "https"
+ URIs; "http" or "https" URIs that do not contain a path component
+ MUST include a value of '/'. The exception to this rule is an
+ OPTIONS request for an "http" or "https" URI that does not include
+ a path component; these MUST include a ":path" pseudo-header field
+ with a value of '*' (see [RFC7230], Section 5.3.4).
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 55]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ All HTTP/2 requests MUST include exactly one valid value for the
+ ":method", ":scheme", and ":path" pseudo-header fields, unless it is
+ a CONNECT request (Section 8.3). An HTTP request that omits
+ mandatory pseudo-header fields is malformed (Section 8.1.2.6).
+
+ HTTP/2 does not define a way to carry the version identifier that is
+ included in the HTTP/1.1 request line.
+
+8.1.2.4. Response Pseudo-Header Fields
+
+ For HTTP/2 responses, a single ":status" pseudo-header field is
+ defined that carries the HTTP status code field (see [RFC7231],
+ Section 6). This pseudo-header field MUST be included in all
+ responses; otherwise, the response is malformed (Section 8.1.2.6).
+
+ HTTP/2 does not define a way to carry the version or reason phrase
+ that is included in an HTTP/1.1 status line.
+
+8.1.2.5. Compressing the Cookie Header Field
+
+ The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
+ cookie-pairs (or "crumbs"). This header field doesn't follow the
+ list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
+ prevents cookie-pairs from being separated into different name-value
+ pairs. This can significantly reduce compression efficiency as
+ individual cookie-pairs are updated.
+
+ To allow for better compression efficiency, the Cookie header field
+ MAY be split into separate header fields, each with one or more
+ cookie-pairs. If there are multiple Cookie header fields after
+ decompression, these MUST be concatenated into a single octet string
+ using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
+ before being passed into a non-HTTP/2 context, such as an HTTP/1.1
+ connection, or a generic HTTP server application.
+
+ Therefore, the following two lists of Cookie header fields are
+ semantically equivalent.
+
+ cookie: a=b; c=d; e=f
+
+ cookie: a=b
+ cookie: c=d
+ cookie: e=f
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 56]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.1.2.6. Malformed Requests and Responses
+
+ A malformed request or response is one that is an otherwise valid
+ sequence of HTTP/2 frames but is invalid due to the presence of
+ extraneous frames, prohibited header fields, the absence of mandatory
+ header fields, or the inclusion of uppercase header field names.
+
+ A request or response that includes a payload body can include a
+ content-length header field. A request or response is also malformed
+ if the value of a content-length header field does not equal the sum
+ of the DATA frame payload lengths that form the body. A response
+ that is defined to have no payload, as described in [RFC7230],
+ Section 3.3.2, can have a non-zero content-length header field, even
+ though no content is included in DATA frames.
+
+ Intermediaries that process HTTP requests or responses (i.e., any
+ intermediary not acting as a tunnel) MUST NOT forward a malformed
+ request or response. Malformed requests or responses that are
+ detected MUST be treated as a stream error (Section 5.4.2) of type
+ PROTOCOL_ERROR.
+
+ For malformed requests, a server MAY send an HTTP response prior to
+ closing or resetting the stream. Clients MUST NOT accept a malformed
+ response. Note that these requirements are intended to protect
+ against several types of common attacks against HTTP; they are
+ deliberately strict because being permissive can expose
+ implementations to these vulnerabilities.
+
+8.1.3. Examples
+
+ This section shows HTTP/1.1 requests and responses, with
+ illustrations of equivalent HTTP/2 requests and responses.
+
+ An HTTP GET request includes request header fields and no payload
+ body and is therefore transmitted as a single HEADERS frame, followed
+ by zero or more CONTINUATION frames containing the serialized block
+ of request header fields. The HEADERS frame in the following has
+ both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames
+ are sent.
+
+ GET /resource HTTP/1.1 HEADERS
+ Host: example.org ==> + END_STREAM
+ Accept: image/jpeg + END_HEADERS
+ :method = GET
+ :scheme = https
+ :path = /resource
+ host = example.org
+ accept = image/jpeg
+
+
+
+Belshe, et al. Standards Track [Page 57]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Similarly, a response that includes only response header fields is
+ transmitted as a HEADERS frame (again, followed by zero or more
+ CONTINUATION frames) containing the serialized block of response
+ header fields.
+
+ HTTP/1.1 304 Not Modified HEADERS
+ ETag: "xyzzy" ==> + END_STREAM
+ Expires: Thu, 23 Jan ... + END_HEADERS
+ :status = 304
+ etag = "xyzzy"
+ expires = Thu, 23 Jan ...
+
+ An HTTP POST request that includes request header fields and payload
+ data is transmitted as one HEADERS frame, followed by zero or more
+ CONTINUATION frames containing the request header fields, followed by
+ one or more DATA frames, with the last CONTINUATION (or HEADERS)
+ frame having the END_HEADERS flag set and the final DATA frame having
+ the END_STREAM flag set:
+
+ POST /resource HTTP/1.1 HEADERS
+ Host: example.org ==> - END_STREAM
+ Content-Type: image/jpeg - END_HEADERS
+ Content-Length: 123 :method = POST
+ :path = /resource
+ {binary data} :scheme = https
+
+ CONTINUATION
+ + END_HEADERS
+ content-type = image/jpeg
+ host = example.org
+ content-length = 123
+
+ DATA
+ + END_STREAM
+ {binary data}
+
+ Note that data contributing to any given header field could be spread
+ between header block fragments. The allocation of header fields to
+ frames in this example is illustrative only.
+
+ A response that includes header fields and payload data is
+ transmitted as a HEADERS frame, followed by zero or more CONTINUATION
+ frames, followed by one or more DATA frames, with the last DATA frame
+ in the sequence having the END_STREAM flag set:
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 58]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ HTTP/1.1 200 OK HEADERS
+ Content-Type: image/jpeg ==> - END_STREAM
+ Content-Length: 123 + END_HEADERS
+ :status = 200
+ {binary data} content-type = image/jpeg
+ content-length = 123
+
+ DATA
+ + END_STREAM
+ {binary data}
+
+ An informational response using a 1xx status code other than 101 is
+ transmitted as a HEADERS frame, followed by zero or more CONTINUATION
+ frames.
+
+ Trailing header fields are sent as a header block after both the
+ request or response header block and all the DATA frames have been
+ sent. The HEADERS frame starting the trailers header block has the
+ END_STREAM flag set.
+
+ The following example includes both a 100 (Continue) status code,
+ which is sent in response to a request containing a "100-continue"
+ token in the Expect header field, and trailing header fields:
+
+ HTTP/1.1 100 Continue HEADERS
+ Extension-Field: bar ==> - END_STREAM
+ + END_HEADERS
+ :status = 100
+ extension-field = bar
+
+ HTTP/1.1 200 OK HEADERS
+ Content-Type: image/jpeg ==> - END_STREAM
+ Transfer-Encoding: chunked + END_HEADERS
+ Trailer: Foo :status = 200
+ content-length = 123
+ 123 content-type = image/jpeg
+ {binary data} trailer = Foo
+ 0
+ Foo: bar DATA
+ - END_STREAM
+ {binary data}
+
+ HEADERS
+ + END_STREAM
+ + END_HEADERS
+ foo = bar
+
+
+
+
+
+Belshe, et al. Standards Track [Page 59]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.1.4. Request Reliability Mechanisms in HTTP/2
+
+ In HTTP/1.1, an HTTP client is unable to retry a non-idempotent
+ request when an error occurs because there is no means to determine
+ the nature of the error. It is possible that some server processing
+ occurred prior to the error, which could result in undesirable
+ effects if the request were reattempted.
+
+ HTTP/2 provides two mechanisms for providing a guarantee to a client
+ that a request has not been processed:
+
+ o The GOAWAY frame indicates the highest stream number that might
+ have been processed. Requests on streams with higher numbers are
+ therefore guaranteed to be safe to retry.
+
+ o The REFUSED_STREAM error code can be included in a RST_STREAM
+ frame to indicate that the stream is being closed prior to any
+ processing having occurred. Any request that was sent on the
+ reset stream can be safely retried.
+
+ Requests that have not been processed have not failed; clients MAY
+ automatically retry them, even those with non-idempotent methods.
+
+ A server MUST NOT indicate that a stream has not been processed
+ unless it can guarantee that fact. If frames that are on a stream
+ are passed to the application layer for any stream, then
+ REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame
+ MUST include a stream identifier that is greater than or equal to the
+ given stream identifier.
+
+ In addition to these mechanisms, the PING frame provides a way for a
+ client to easily test a connection. Connections that remain idle can
+ become broken as some middleboxes (for instance, network address
+ translators or load balancers) silently discard connection bindings.
+ The PING frame allows a client to safely test whether a connection is
+ still active without sending a request.
+
+8.2. Server Push
+
+ HTTP/2 allows a server to pre-emptively send (or "push") responses
+ (along with corresponding "promised" requests) to a client in
+ association with a previous client-initiated request. This can be
+ useful when the server knows the client will need to have those
+ responses available in order to fully process the response to the
+ original request.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 60]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A client can request that server push be disabled, though this is
+ negotiated for each hop independently. The SETTINGS_ENABLE_PUSH
+ setting can be set to 0 to indicate that server push is disabled.
+
+ Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3),
+ MUST be safe (see [RFC7231], Section 4.2.1), and MUST NOT include a
+ request body. Clients that receive a promised request that is not
+ cacheable, that is not known to be safe, or that indicates the
+ presence of a request body MUST reset the promised stream with a
+ stream error (Section 5.4.2) of type PROTOCOL_ERROR. Note this could
+ result in the promised stream being reset if the client does not
+ recognize a newly defined method as being safe.
+
+ Pushed responses that are cacheable (see [RFC7234], Section 3) can be
+ stored by the client, if it implements an HTTP cache. Pushed
+ responses are considered successfully validated on the origin server
+ (e.g., if the "no-cache" cache response directive is present
+ ([RFC7234], Section 5.2.2)) while the stream identified by the
+ promised stream ID is still open.
+
+ Pushed responses that are not cacheable MUST NOT be stored by any
+ HTTP cache. They MAY be made available to the application
+ separately.
+
+ The server MUST include a value in the ":authority" pseudo-header
+ field for which the server is authoritative (see Section 10.1). A
+ client MUST treat a PUSH_PROMISE for which the server is not
+ authoritative as a stream error (Section 5.4.2) of type
+ PROTOCOL_ERROR.
+
+ An intermediary can receive pushes from the server and choose not to
+ forward them on to the client. In other words, how to make use of
+ the pushed information is up to that intermediary. Equally, the
+ intermediary might choose to make additional pushes to the client,
+ without any action taken by the server.
+
+ A client cannot push. Thus, servers MUST treat the receipt of a
+ PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
+ PROTOCOL_ERROR. Clients MUST reject any attempt to change the
+ SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the
+ message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
+
+8.2.1. Push Requests
+
+ Server push is semantically equivalent to a server responding to a
+ request; however, in this case, that request is also sent by the
+ server, as a PUSH_PROMISE frame.
+
+
+
+
+Belshe, et al. Standards Track [Page 61]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ The PUSH_PROMISE frame includes a header block that contains a
+ complete set of request header fields that the server attributes to
+ the request. It is not possible to push a response to a request that
+ includes a request body.
+
+ Pushed responses are always associated with an explicit request from
+ the client. The PUSH_PROMISE frames sent by the server are sent on
+ that explicit request's stream. The PUSH_PROMISE frame also includes
+ a promised stream identifier, chosen from the stream identifiers
+ available to the server (see Section 5.1.1).
+
+ The header fields in PUSH_PROMISE and any subsequent CONTINUATION
+ frames MUST be a valid and complete set of request header fields
+ (Section 8.1.2.3). The server MUST include a method in the ":method"
+ pseudo-header field that is safe and cacheable. If a client receives
+ a PUSH_PROMISE that does not include a complete and valid set of
+ header fields or the ":method" pseudo-header field identifies a
+ method that is not safe, it MUST respond with a stream error
+ (Section 5.4.2) of type PROTOCOL_ERROR.
+
+ The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
+ sending any frames that reference the promised responses. This
+ avoids a race where clients issue requests prior to receiving any
+ PUSH_PROMISE frames.
+
+ For example, if the server receives a request for a document
+ containing embedded links to multiple image files and the server
+ chooses to push those additional images to the client, sending
+ PUSH_PROMISE frames before the DATA frames that contain the image
+ links ensures that the client is able to see that a resource will be
+ pushed before discovering embedded links. Similarly, if the server
+ pushes responses referenced by the header block (for instance, in
+ Link header fields), sending a PUSH_PROMISE before sending the header
+ block ensures that clients do not request those resources.
+
+ PUSH_PROMISE frames MUST NOT be sent by the client.
+
+ PUSH_PROMISE frames can be sent by the server in response to any
+ client-initiated stream, but the stream MUST be in either the "open"
+ or "half-closed (remote)" state with respect to the server.
+ PUSH_PROMISE frames are interspersed with the frames that comprise a
+ response, though they cannot be interspersed with HEADERS and
+ CONTINUATION frames that comprise a single header block.
+
+ Sending a PUSH_PROMISE frame creates a new stream and puts the stream
+ into the "reserved (local)" state for the server and the "reserved
+ (remote)" state for the client.
+
+
+
+
+Belshe, et al. Standards Track [Page 62]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.2.2. Push Responses
+
+ After sending the PUSH_PROMISE frame, the server can begin delivering
+ the pushed response as a response (Section 8.1.2.4) on a server-
+ initiated stream that uses the promised stream identifier. The
+ server uses this stream to transmit an HTTP response, using the same
+ sequence of frames as defined in Section 8.1. This stream becomes
+ "half-closed" to the client (Section 5.1) after the initial HEADERS
+ frame is sent.
+
+ Once a client receives a PUSH_PROMISE frame and chooses to accept the
+ pushed response, the client SHOULD NOT issue any requests for the
+ promised response until after the promised stream has closed.
+
+ If the client determines, for any reason, that it does not wish to
+ receive the pushed response from the server or if the server takes
+ too long to begin sending the promised response, the client can send
+ a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code
+ and referencing the pushed stream's identifier.
+
+ A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
+ the number of responses that can be concurrently pushed by a server.
+ Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
+ server push by preventing the server from creating the necessary
+ streams. This does not prohibit a server from sending PUSH_PROMISE
+ frames; clients need to reset any promised streams that are not
+ wanted.
+
+ Clients receiving a pushed response MUST validate that either the
+ server is authoritative (see Section 10.1) or the proxy that provided
+ the pushed response is configured for the corresponding request. For
+ example, a server that offers a certificate for only the
+ "example.com" DNS-ID or Common Name is not permitted to push a
+ response for "https://www.example.org/doc".
+
+ The response for a PUSH_PROMISE stream begins with a HEADERS frame,
+ which immediately puts the stream into the "half-closed (remote)"
+ state for the server and "half-closed (local)" state for the client,
+ and ends with a frame bearing END_STREAM, which places the stream in
+ the "closed" state.
+
+ Note: The client never sends a frame with the END_STREAM flag for
+ a server push.
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 63]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+8.3. The CONNECT Method
+
+ In HTTP/1.x, the pseudo-method CONNECT ([RFC7231], Section 4.3.6) is
+ used to convert an HTTP connection into a tunnel to a remote host.
+ CONNECT is primarily used with HTTP proxies to establish a TLS
+ session with an origin server for the purposes of interacting with
+ "https" resources.
+
+ In HTTP/2, the CONNECT method is used to establish a tunnel over a
+ single HTTP/2 stream to a remote host for similar purposes. The HTTP
+ header field mapping works as defined in Section 8.1.2.3 ("Request
+ Pseudo-Header Fields"), with a few differences. Specifically:
+
+ o The ":method" pseudo-header field is set to "CONNECT".
+
+ o The ":scheme" and ":path" pseudo-header fields MUST be omitted.
+
+ o The ":authority" pseudo-header field contains the host and port to
+ connect to (equivalent to the authority-form of the request-target
+ of CONNECT requests (see [RFC7230], Section 5.3)).
+
+ A CONNECT request that does not conform to these restrictions is
+ malformed (Section 8.1.2.6).
+
+ A proxy that supports CONNECT establishes a TCP connection [TCP] to
+ the server identified in the ":authority" pseudo-header field. Once
+ this connection is successfully established, the proxy sends a
+ HEADERS frame containing a 2xx series status code to the client, as
+ defined in [RFC7231], Section 4.3.6.
+
+ After the initial HEADERS frame sent by each peer, all subsequent
+ DATA frames correspond to data sent on the TCP connection. The
+ payload of any DATA frames sent by the client is transmitted by the
+ proxy to the TCP server; data received from the TCP server is
+ assembled into DATA frames by the proxy. Frame types other than DATA
+ or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
+ MUST NOT be sent on a connected stream and MUST be treated as a
+ stream error (Section 5.4.2) if received.
+
+ The TCP connection can be closed by either peer. The END_STREAM flag
+ on a DATA frame is treated as being equivalent to the TCP FIN bit. A
+ client is expected to send a DATA frame with the END_STREAM flag set
+ after receiving a frame bearing the END_STREAM flag. A proxy that
+ receives a DATA frame with the END_STREAM flag set sends the attached
+ data with the FIN bit set on the last TCP segment. A proxy that
+ receives a TCP segment with the FIN bit set sends a DATA frame with
+ the END_STREAM flag set. Note that the final TCP segment or DATA
+ frame could be empty.
+
+
+
+Belshe, et al. Standards Track [Page 64]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ A TCP connection error is signaled with RST_STREAM. A proxy treats
+ any error in the TCP connection, which includes receiving a TCP
+ segment with the RST bit set, as a stream error (Section 5.4.2) of
+ type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment
+ with the RST bit set if it detects an error with the stream or the
+ HTTP/2 connection.
+
+9. Additional HTTP Requirements/Considerations
+
+ This section outlines attributes of the HTTP protocol that improve
+ interoperability, reduce exposure to known security vulnerabilities,
+ or reduce the potential for implementation variation.
+
+9.1. Connection Management
+
+ HTTP/2 connections are persistent. For best performance, it is
+ expected that clients will not close connections until it is
+ determined that no further communication with a server is necessary
+ (for example, when a user navigates away from a particular web page)
+ or until the server closes the connection.
+
+ Clients SHOULD NOT open more than one HTTP/2 connection to a given
+ host and port pair, where the host is derived from a URI, a selected
+ alternative service [ALT-SVC], or a configured proxy.
+
+ A client can create additional connections as replacements, either to
+ replace connections that are near to exhausting the available stream
+ identifier space (Section 5.1.1), to refresh the keying material for
+ a TLS connection, or to replace connections that have encountered
+ errors (Section 5.4.1).
+
+ A client MAY open multiple connections to the same IP address and TCP
+ port using different Server Name Indication [TLS-EXT] values or to
+ provide different TLS client certificates but SHOULD avoid creating
+ multiple connections with the same configuration.
+
+ Servers are encouraged to maintain open connections for as long as
+ possible but are permitted to terminate idle connections if
+ necessary. When either endpoint chooses to close the transport-layer
+ TCP connection, the terminating endpoint SHOULD first send a GOAWAY
+ (Section 6.8) frame so that both endpoints can reliably determine
+ whether previously sent frames have been processed and gracefully
+ complete or terminate any necessary remaining tasks.
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 65]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+9.1.1. Connection Reuse
+
+ Connections that are made to an origin server, either directly or
+ through a tunnel created using the CONNECT method (Section 8.3), MAY
+ be reused for requests with multiple different URI authority
+ components. A connection can be reused as long as the origin server
+ is authoritative (Section 10.1). For TCP connections without TLS,
+ this depends on the host having resolved to the same IP address.
+
+ For "https" resources, connection reuse additionally depends on
+ having a certificate that is valid for the host in the URI. The
+ certificate presented by the server MUST satisfy any checks that the
+ client would perform when forming a new TLS connection for the host
+ in the URI.
+
+ An origin server might offer a certificate with multiple
+ "subjectAltName" attributes or names with wildcards, one of which is
+ valid for the authority in the URI. For example, a certificate with
+ a "subjectAltName" of "*.example.com" might permit the use of the
+ same connection for requests to URIs starting with
+ "https://a.example.com/" and "https://b.example.com/".
+
+ In some deployments, reusing a connection for multiple origins can
+ result in requests being directed to the wrong origin server. For
+ example, TLS termination might be performed by a middlebox that uses
+ the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
+ origin server. This means that it is possible for clients to send
+ confidential information to servers that might not be the intended
+ target for the request, even though the server is otherwise
+ authoritative.
+
+ A server that does not wish clients to reuse connections can indicate
+ that it is not authoritative for a request by sending a 421
+ (Misdirected Request) status code in response to the request (see
+ Section 9.1.2).
+
+ A client that is configured to use a proxy over HTTP/2 directs
+ requests to that proxy through a single connection. That is, all
+ requests sent via a proxy reuse the connection to the proxy.
+
+9.1.2. The 421 (Misdirected Request) Status Code
+
+ The 421 (Misdirected Request) status code indicates that the request
+ was directed at a server that is not able to produce a response.
+ This can be sent by a server that is not configured to produce
+ responses for the combination of scheme and authority that are
+ included in the request URI.
+
+
+
+
+Belshe, et al. Standards Track [Page 66]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Clients receiving a 421 (Misdirected Request) response from a server
+ MAY retry the request -- whether the request method is idempotent or
+ not -- over a different connection. This is possible if a connection
+ is reused (Section 9.1.1) or if an alternative service is selected
+ [ALT-SVC].
+
+ This status code MUST NOT be generated by proxies.
+
+ A 421 response is cacheable by default, i.e., unless otherwise
+ indicated by the method definition or explicit cache controls (see
+ Section 4.2.2 of [RFC7234]).
+
+9.2. Use of TLS Features
+
+ Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher
+ for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP]
+ SHOULD be followed, with some additional restrictions that are
+ specific to HTTP/2.
+
+ The TLS implementation MUST support the Server Name Indication (SNI)
+ [TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target
+ domain name when negotiating TLS.
+
+ Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only
+ support and use the SNI extension; deployments of TLS 1.2 are subject
+ to the requirements in the following sections. Implementations are
+ encouraged to provide defaults that comply, but it is recognized that
+ deployments are ultimately responsible for compliance.
+
+9.2.1. TLS 1.2 Features
+
+ This section describes restrictions on the TLS 1.2 feature set that
+ can be used with HTTP/2. Due to deployment limitations, it might not
+ be possible to fail TLS negotiation when these restrictions are not
+ met. An endpoint MAY immediately terminate an HTTP/2 connection that
+ does not meet these TLS requirements with a connection error
+ (Section 5.4.1) of type INADEQUATE_SECURITY.
+
+ A deployment of HTTP/2 over TLS 1.2 MUST disable compression. TLS
+ compression can lead to the exposure of information that would not
+ otherwise be revealed [RFC3749]. Generic compression is unnecessary
+ since HTTP/2 provides compression features that are more aware of
+ context and therefore likely to be more appropriate for use for
+ performance, security, or other reasons.
+
+ A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An
+ endpoint MUST treat a TLS renegotiation as a connection error
+ (Section 5.4.1) of type PROTOCOL_ERROR. Note that disabling
+
+
+
+Belshe, et al. Standards Track [Page 67]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ renegotiation can result in long-lived connections becoming unusable
+ due to limits on the number of messages the underlying cipher suite
+ can encipher.
+
+ An endpoint MAY use renegotiation to provide confidentiality
+ protection for client credentials offered in the handshake, but any
+ renegotiation MUST occur prior to sending the connection preface. A
+ server SHOULD request a client certificate if it sees a renegotiation
+ request immediately after establishing a connection.
+
+ This effectively prevents the use of renegotiation in response to a
+ request for a specific protected resource. A future specification
+ might provide a way to support this use case. Alternatively, a
+ server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to
+ request the client use a protocol that supports renegotiation.
+
+ Implementations MUST support ephemeral key exchange sizes of at least
+ 2048 bits for cipher suites that use ephemeral finite field Diffie-
+ Hellman (DHE) [TLS12] and 224 bits for cipher suites that use
+ ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients
+ MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat
+ negotiation of key sizes smaller than the lower limits as a
+ connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
+
+9.2.2. TLS 1.2 Cipher Suites
+
+ A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher
+ suites that are listed in the cipher suite black list (Appendix A).
+
+ Endpoints MAY choose to generate a connection error (Section 5.4.1)
+ of type INADEQUATE_SECURITY if one of the cipher suites from the
+ black list is negotiated. A deployment that chooses to use a black-
+ listed cipher suite risks triggering a connection error unless the
+ set of potential peers is known to accept that cipher suite.
+
+ Implementations MUST NOT generate this error in reaction to the
+ negotiation of a cipher suite that is not on the black list.
+ Consequently, when clients offer a cipher suite that is not on the
+ black list, they have to be prepared to use that cipher suite with
+ HTTP/2.
+
+ The black list includes the cipher suite that TLS 1.2 makes
+ mandatory, which means that TLS 1.2 deployments could have non-
+ intersecting sets of permitted cipher suites. To avoid this problem
+ causing TLS handshake failures, deployments of HTTP/2 that use TLS
+ 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
+ with the P-256 elliptic curve [FIPS186].
+
+
+
+
+Belshe, et al. Standards Track [Page 68]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Note that clients might advertise support of cipher suites that are
+ on the black list in order to allow for connection to servers that do
+ not support HTTP/2. This allows servers to select HTTP/1.1 with a
+ cipher suite that is on the HTTP/2 black list. However, this can
+ result in HTTP/2 being negotiated with a black-listed cipher suite if
+ the application protocol and cipher suite are independently selected.
+
+10. Security Considerations
+
+10.1. Server Authority
+
+ HTTP/2 relies on the HTTP/1.1 definition of authority for determining
+ whether a server is authoritative in providing a given response (see
+ [RFC7230], Section 9.1). This relies on local name resolution for
+ the "http" URI scheme and the authenticated server identity for the
+ "https" scheme (see [RFC2818], Section 3).
+
+10.2. Cross-Protocol Attacks
+
+ In a cross-protocol attack, an attacker causes a client to initiate a
+ transaction in one protocol toward a server that understands a
+ different protocol. An attacker might be able to cause the
+ transaction to appear as a valid transaction in the second protocol.
+ In combination with the capabilities of the web context, this can be
+ used to interact with poorly protected servers in private networks.
+
+ Completing a TLS handshake with an ALPN identifier for HTTP/2 can be
+ considered sufficient protection against cross-protocol attacks.
+ ALPN provides a positive indication that a server is willing to
+ proceed with HTTP/2, which prevents attacks on other TLS-based
+ protocols.
+
+ The encryption in TLS makes it difficult for attackers to control the
+ data that could be used in a cross-protocol attack on a cleartext
+ protocol.
+
+ The cleartext version of HTTP/2 has minimal protection against cross-
+ protocol attacks. The connection preface (Section 3.5) contains a
+ string that is designed to confuse HTTP/1.1 servers, but no special
+ protection is offered for other protocols. A server that is willing
+ to ignore parts of an HTTP/1.1 request containing an Upgrade header
+ field in addition to the client connection preface could be exposed
+ to a cross-protocol attack.
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 69]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+10.3. Intermediary Encapsulation Attacks
+
+ The HTTP/2 header field encoding allows the expression of names that
+ are not valid field names in the Internet Message Syntax used by
+ HTTP/1.1. Requests or responses containing invalid header field
+ names MUST be treated as malformed (Section 8.1.2.6). An
+ intermediary therefore cannot translate an HTTP/2 request or response
+ containing an invalid field name into an HTTP/1.1 message.
+
+ Similarly, HTTP/2 allows header field values that are not valid.
+ While most of the values that can be encoded will not alter header
+ field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII
+ 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by
+ an attacker if they are translated verbatim. Any request or response
+ that contains a character not permitted in a header field value MUST
+ be treated as malformed (Section 8.1.2.6). Valid characters are
+ defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230].
+
+10.4. Cacheability of Pushed Responses
+
+ Pushed responses do not have an explicit request from the client; the
+ request is provided by the server in the PUSH_PROMISE frame.
+
+ Caching responses that are pushed is possible based on the guidance
+ provided by the origin server in the Cache-Control header field.
+ However, this can cause issues if a single server hosts more than one
+ tenant. For example, a server might offer multiple users each a
+ small portion of its URI space.
+
+ Where multiple tenants share space on the same server, that server
+ MUST ensure that tenants are not able to push representations of
+ resources that they do not have authority over. Failure to enforce
+ this would allow a tenant to provide a representation that would be
+ served out of cache, overriding the actual representation that the
+ authoritative tenant provides.
+
+ Pushed responses for which an origin server is not authoritative (see
+ Section 10.1) MUST NOT be used or cached.
+
+10.5. Denial-of-Service Considerations
+
+ An HTTP/2 connection can demand a greater commitment of resources to
+ operate than an HTTP/1.1 connection. The use of header compression
+ and flow control depend on a commitment of resources for storing a
+ greater amount of state. Settings for these features ensure that
+ memory commitments for these features are strictly bounded.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 70]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ The number of PUSH_PROMISE frames is not constrained in the same
+ fashion. A client that accepts server push SHOULD limit the number
+ of streams it allows to be in the "reserved (remote)" state. An
+ excessive number of server push streams can be treated as a stream
+ error (Section 5.4.2) of type ENHANCE_YOUR_CALM.
+
+ Processing capacity cannot be guarded as effectively as state
+ capacity.
+
+ The SETTINGS frame can be abused to cause a peer to expend additional
+ processing time. This might be done by pointlessly changing SETTINGS
+ parameters, setting multiple undefined parameters, or changing the
+ same setting multiple times in the same frame. WINDOW_UPDATE or
+ PRIORITY frames can be abused to cause an unnecessary waste of
+ resources.
+
+ Large numbers of small or empty frames can be abused to cause a peer
+ to expend time processing frame headers. Note, however, that some
+ uses are entirely legitimate, such as the sending of an empty DATA or
+ CONTINUATION frame at the end of a stream.
+
+ Header compression also offers some opportunities to waste processing
+ resources; see Section 7 of [COMPRESSION] for more details on
+ potential abuses.
+
+ Limits in SETTINGS parameters cannot be reduced instantaneously,
+ which leaves an endpoint exposed to behavior from a peer that could
+ exceed the new limits. In particular, immediately after establishing
+ a connection, limits set by a server are not known to clients and
+ could be exceeded without being an obvious protocol violation.
+
+ All these features -- i.e., SETTINGS changes, small frames, header
+ compression -- have legitimate uses. These features become a burden
+ only when they are used unnecessarily or to excess.
+
+ An endpoint that doesn't monitor this behavior exposes itself to a
+ risk of denial-of-service attack. Implementations SHOULD track the
+ use of these features and set limits on their use. An endpoint MAY
+ treat activity that is suspicious as a connection error
+ (Section 5.4.1) of type ENHANCE_YOUR_CALM.
+
+10.5.1. Limits on Header Block Size
+
+ A large header block (Section 4.3) can cause an implementation to
+ commit a large amount of state. Header fields that are critical for
+ routing can appear toward the end of a header block, which prevents
+ streaming of header fields to their ultimate destination. This
+ ordering and other reasons, such as ensuring cache correctness, mean
+
+
+
+Belshe, et al. Standards Track [Page 71]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ that an endpoint might need to buffer the entire header block. Since
+ there is no hard limit to the size of a header block, some endpoints
+ could be forced to commit a large amount of available memory for
+ header fields.
+
+ An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers
+ of limits that might apply on the size of header blocks. This
+ setting is only advisory, so endpoints MAY choose to send header
+ blocks that exceed this limit and risk having the request or response
+ being treated as malformed. This setting is specific to a
+ connection, so any request or response could encounter a hop with a
+ lower, unknown limit. An intermediary can attempt to avoid this
+ problem by passing on values presented by different peers, but they
+ are not obligated to do so.
+
+ A server that receives a larger header block than it is willing to
+ handle can send an HTTP 431 (Request Header Fields Too Large) status
+ code [RFC6585]. A client can discard responses that it cannot
+ process. The header block MUST be processed to ensure a consistent
+ connection state, unless the connection is closed.
+
+10.5.2. CONNECT Issues
+
+ The CONNECT method can be used to create disproportionate load on an
+ proxy, since stream creation is relatively inexpensive when compared
+ to the creation and maintenance of a TCP connection. A proxy might
+ also maintain some resources for a TCP connection beyond the closing
+ of the stream that carries the CONNECT request, since the outgoing
+ TCP connection remains in the TIME_WAIT state. Therefore, a proxy
+ cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the
+ resources consumed by CONNECT requests.
+
+10.6. Use of Compression
+
+ Compression can allow an attacker to recover secret data when it is
+ compressed in the same context as data under attacker control.
+ HTTP/2 enables compression of header fields (Section 4.3); the
+ following concerns also apply to the use of HTTP compressed content-
+ codings ([RFC7231], Section 3.1.2.1).
+
+ There are demonstrable attacks on compression that exploit the
+ characteristics of the web (e.g., [BREACH]). The attacker induces
+ multiple requests containing varying plaintext, observing the length
+ of the resulting ciphertext in each, which reveals a shorter length
+ when a guess about the secret is correct.
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 72]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Implementations communicating on a secure channel MUST NOT compress
+ content that includes both confidential and attacker-controlled data
+ unless separate compression dictionaries are used for each source of
+ data. Compression MUST NOT be used if the source of data cannot be
+ reliably determined. Generic stream compression, such as that
+ provided by TLS, MUST NOT be used with HTTP/2 (see Section 9.2).
+
+ Further considerations regarding the compression of header fields are
+ described in [COMPRESSION].
+
+10.7. Use of Padding
+
+ Padding within HTTP/2 is not intended as a replacement for general
+ purpose padding, such as might be provided by TLS [TLS12]. Redundant
+ padding could even be counterproductive. Correct application can
+ depend on having specific knowledge of the data that is being padded.
+
+ To mitigate attacks that rely on compression, disabling or limiting
+ compression might be preferable to padding as a countermeasure.
+
+ Padding can be used to obscure the exact size of frame content and is
+ provided to mitigate specific attacks within HTTP, for example,
+ attacks where compressed content includes both attacker-controlled
+ plaintext and secret data (e.g., [BREACH]).
+
+ Use of padding can result in less protection than might seem
+ immediately obvious. At best, padding only makes it more difficult
+ for an attacker to infer length information by increasing the number
+ of frames an attacker has to observe. Incorrectly implemented
+ padding schemes can be easily defeated. In particular, randomized
+ padding with a predictable distribution provides very little
+ protection; similarly, padding payloads to a fixed size exposes
+ information as payload sizes cross the fixed-sized boundary, which
+ could be possible if an attacker can control plaintext.
+
+ Intermediaries SHOULD retain padding for DATA frames but MAY drop
+ padding for HEADERS and PUSH_PROMISE frames. A valid reason for an
+ intermediary to change the amount of padding of frames is to improve
+ the protections that padding provides.
+
+10.8. Privacy Considerations
+
+ Several characteristics of HTTP/2 provide an observer an opportunity
+ to correlate actions of a single client or server over time. These
+ include the value of settings, the manner in which flow-control
+ windows are managed, the way priorities are allocated to streams, the
+ timing of reactions to stimulus, and the handling of any features
+ that are controlled by settings.
+
+
+
+Belshe, et al. Standards Track [Page 73]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ As far as these create observable differences in behavior, they could
+ be used as a basis for fingerprinting a specific client, as defined
+ in Section 1.8 of [HTML5].
+
+ HTTP/2's preference for using a single TCP connection allows
+ correlation of a user's activity on a site. Reusing connections for
+ different origins allows tracking across those origins.
+
+ Because the PING and SETTINGS frames solicit immediate responses,
+ they can be used by an endpoint to measure latency to their peer.
+ This might have privacy implications in certain scenarios.
+
+11. IANA Considerations
+
+ A string for identifying HTTP/2 is entered into the "Application-
+ Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
+ in [TLS-ALPN].
+
+ This document establishes a registry for frame types, settings, and
+ error codes. These new registries appear in the new "Hypertext
+ Transfer Protocol version 2 (HTTP/2) Parameters" section.
+
+ This document registers the HTTP2-Settings header field for use in
+ HTTP; it also registers the 421 (Misdirected Request) status code.
+
+ This document registers the "PRI" method for use in HTTP to avoid
+ collisions with the connection preface (Section 3.5).
+
+11.1. Registration of HTTP/2 Identification Strings
+
+ This document creates two registrations for the identification of
+ HTTP/2 (see Section 3.3) in the "Application-Layer Protocol
+ Negotiation (ALPN) Protocol IDs" registry established in [TLS-ALPN].
+
+ The "h2" string identifies HTTP/2 when used over TLS:
+
+ Protocol: HTTP/2 over TLS
+
+ Identification Sequence: 0x68 0x32 ("h2")
+
+ Specification: This document
+
+ The "h2c" string identifies HTTP/2 when used over cleartext TCP:
+
+ Protocol: HTTP/2 over TCP
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 74]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Identification Sequence: 0x68 0x32 0x63 ("h2c")
+
+ Specification: This document
+
+11.2. Frame Type Registry
+
+ This document establishes a registry for HTTP/2 frame type codes.
+ The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2
+ Frame Type" registry operates under either of the "IETF Review" or
+ "IESG Approval" policies [RFC5226] for values between 0x00 and 0xef,
+ with values between 0xf0 and 0xff being reserved for Experimental
+ Use.
+
+ New entries in this registry require the following information:
+
+ Frame Type: A name or label for the frame type.
+
+ Code: The 8-bit code assigned to the frame type.
+
+ Specification: A reference to a specification that includes a
+ description of the frame layout, its semantics, and flags that the
+ frame type uses, including any parts of the frame that are
+ conditionally present based on the value of flags.
+
+ The entries in the following table are registered by this document.
+
+ +---------------+------+--------------+
+ | Frame Type | Code | Section |
+ +---------------+------+--------------+
+ | DATA | 0x0 | Section 6.1 |
+ | HEADERS | 0x1 | Section 6.2 |
+ | PRIORITY | 0x2 | Section 6.3 |
+ | RST_STREAM | 0x3 | Section 6.4 |
+ | SETTINGS | 0x4 | Section 6.5 |
+ | PUSH_PROMISE | 0x5 | Section 6.6 |
+ | PING | 0x6 | Section 6.7 |
+ | GOAWAY | 0x7 | Section 6.8 |
+ | WINDOW_UPDATE | 0x8 | Section 6.9 |
+ | CONTINUATION | 0x9 | Section 6.10 |
+ +---------------+------+--------------+
+
+11.3. Settings Registry
+
+ This document establishes a registry for HTTP/2 settings. The
+ "HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2
+ Settings" registry operates under the "Expert Review" policy
+ [RFC5226] for values in the range from 0x0000 to 0xefff, with values
+ between and 0xf000 and 0xffff being reserved for Experimental Use.
+
+
+
+Belshe, et al. Standards Track [Page 75]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ New registrations are advised to provide the following information:
+
+ Name: A symbolic name for the setting. Specifying a setting name is
+ optional.
+
+ Code: The 16-bit code assigned to the setting.
+
+ Initial Value: An initial value for the setting.
+
+ Specification: An optional reference to a specification that
+ describes the use of the setting.
+
+ The entries in the following table are registered by this document.
+
+ +------------------------+------+---------------+---------------+
+ | Name | Code | Initial Value | Specification |
+ +------------------------+------+---------------+---------------+
+ | HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 |
+ | ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 |
+ | MAX_CONCURRENT_STREAMS | 0x3 | (infinite) | Section 6.5.2 |
+ | INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 |
+ | MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 |
+ | MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 |
+ +------------------------+------+---------------+---------------+
+
+11.4. Error Code Registry
+
+ This document establishes a registry for HTTP/2 error codes. The
+ "HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2
+ Error Code" registry operates under the "Expert Review" policy
+ [RFC5226].
+
+ Registrations for error codes are required to include a description
+ of the error code. An expert reviewer is advised to examine new
+ registrations for possible duplication with existing error codes.
+ Use of existing registrations is to be encouraged, but not mandated.
+
+ New registrations are advised to provide the following information:
+
+ Name: A name for the error code. Specifying an error code name is
+ optional.
+
+ Code: The 32-bit error code value.
+
+ Description: A brief description of the error code semantics, longer
+ if no detailed specification is provided.
+
+
+
+
+
+Belshe, et al. Standards Track [Page 76]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Specification: An optional reference for a specification that
+ defines the error code.
+
+ The entries in the following table are registered by this document.
+
+ +---------------------+------+----------------------+---------------+
+ | Name | Code | Description | Specification |
+ +---------------------+------+----------------------+---------------+
+ | NO_ERROR | 0x0 | Graceful shutdown | Section 7 |
+ | PROTOCOL_ERROR | 0x1 | Protocol error | Section 7 |
+ | | | detected | |
+ | INTERNAL_ERROR | 0x2 | Implementation fault | Section 7 |
+ | FLOW_CONTROL_ERROR | 0x3 | Flow-control limits | Section 7 |
+ | | | exceeded | |
+ | SETTINGS_TIMEOUT | 0x4 | Settings not | Section 7 |
+ | | | acknowledged | |
+ | STREAM_CLOSED | 0x5 | Frame received for | Section 7 |
+ | | | closed stream | |
+ | FRAME_SIZE_ERROR | 0x6 | Frame size incorrect | Section 7 |
+ | REFUSED_STREAM | 0x7 | Stream not processed | Section 7 |
+ | CANCEL | 0x8 | Stream cancelled | Section 7 |
+ | COMPRESSION_ERROR | 0x9 | Compression state | Section 7 |
+ | | | not updated | |
+ | CONNECT_ERROR | 0xa | TCP connection error | Section 7 |
+ | | | for CONNECT method | |
+ | ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 |
+ | | | exceeded | |
+ | INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 |
+ | | | parameters not | |
+ | | | acceptable | |
+ | HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for the | Section 7 |
+ | | | request | |
+ +---------------------+------+----------------------+---------------+
+
+11.5. HTTP2-Settings Header Field Registration
+
+ This section registers the HTTP2-Settings header field in the
+ "Permanent Message Header Field Names" registry [BCP90].
+
+ Header field name: HTTP2-Settings
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+
+
+
+
+Belshe, et al. Standards Track [Page 77]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ Specification document(s): Section 3.2.1 of this document
+
+ Related information: This header field is only used by an HTTP/2
+ client for Upgrade-based negotiation.
+
+11.6. PRI Method Registration
+
+ This section registers the "PRI" method in the "HTTP Method Registry"
+ ([RFC7231], Section 8.1).
+
+ Method Name: PRI
+
+ Safe: Yes
+
+ Idempotent: Yes
+
+ Specification document(s): Section 3.5 of this document
+
+ Related information: This method is never used by an actual client.
+ This method will appear to be used when an HTTP/1.1 server or
+ intermediary attempts to parse an HTTP/2 connection preface.
+
+11.7. The 421 (Misdirected Request) HTTP Status Code
+
+ This document registers the 421 (Misdirected Request) HTTP status
+ code in the "HTTP Status Codes" registry ([RFC7231], Section 8.2).
+
+ Status Code: 421
+
+ Short Description: Misdirected Request
+
+ Specification: Section 9.1.2 of this document
+
+11.8. The h2c Upgrade Token
+
+ This document registers the "h2c" upgrade token in the "HTTP Upgrade
+ Tokens" registry ([RFC7230], Section 8.6).
+
+ Value: h2c
+
+ Description: Hypertext Transfer Protocol version 2 (HTTP/2)
+
+ Expected Version Tokens: None
+
+ Reference: Section 3.2 of this document
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 78]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+12. References
+
+12.1. Normative References
+
+ [COMPRESSION] Peon, R. and H. Ruellan, "HPACK: Header Compression for
+ HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
+ <http://www.rfc-editor.org/info/rfc7541>.
+
+ [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
+ DOI 10.17487/RFC6265, April 2011,
+ <http://www.rfc-editor.org/info/rfc6265>.
+
+ [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB
+ 186-4, July 2013,
+ <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
+ RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
+ RFC2818, May 2000,
+ <http://www.rfc-editor.org/info/rfc2818>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <http://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October
+ 2006, <http://www.rfc-editor.org/info/rfc4648>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26,
+ RFC 5226, DOI 10.17487/RFC5226, May 2008,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/ RFC5234, January 2008,
+ <http://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Message Syntax and
+ Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <http://www.rfc-editor.org/info/rfc7230>.
+
+
+
+Belshe, et al. Standards Track [Page 79]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Semantics and Content",
+ RFC 7231, DOI 10.17487/RFC7231, June 2014,
+ <http://www.rfc-editor.org/info/rfc7231>.
+
+ [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Conditional Requests",
+ RFC 7232, DOI 10.17487/RFC7232, June 2014,
+ <http://www.rfc-editor.org/info/rfc7232>.
+
+ [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
+ "Hypertext Transfer Protocol (HTTP/1.1): Range
+ Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
+ <http://www.rfc-editor.org/info/rfc7233>.
+
+ [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+ RFC 7234, DOI 10.17487/RFC7234, June 2014,
+ <http://www.rfc-editor.org/info/rfc7234>.
+
+ [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Authentication",
+ RFC 7235, DOI 10.17487/RFC7235, June 2014,
+ <http://www.rfc-editor.org/info/rfc7235>.
+
+ [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, DOI 10.17487/RFC0793, September 1981,
+ <http://www.rfc-editor.org/info/rfc793>.
+
+ [TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
+ "Transport Layer Security (TLS) Application-Layer
+ Protocol Negotiation Extension", RFC 7301,
+ DOI 10.17487/RFC7301, July 2014,
+ <http://www.rfc-editor.org/info/rfc7301>.
+
+ [TLS-ECDHE] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
+ SHA-256/384 and AES Galois Counter Mode (GCM)",
+ RFC 5289, DOI 10.17487/RFC5289, August 2008,
+ <http://www.rfc-editor.org/info/rfc5289>.
+
+ [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
+ Extensions: Extension Definitions", RFC 6066,
+ DOI 10.17487/RFC6066, January 2011,
+ <http://www.rfc-editor.org/info/rfc6066>.
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 80]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/ RFC5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+12.2. Informative References
+
+ [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
+ Alternative Services", Work in Progress, draft-ietf-
+ httpbis-alt-svc-06, February 2015.
+
+ [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90,
+ RFC 3864, September 2004,
+ <http://www.rfc-editor.org/info/bcp90>.
+
+ [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving
+ the CRIME Attack", July 2013,
+ <http://breachattack.com/resources/
+ BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
+
+ [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
+ Doyle Navara, E., O'Connor, E., and S. Pfeiffer,
+ "HTML5", W3C Recommendation REC-html5-20141028, October
+ 2014, <http://www.w3.org/TR/2014/REC-html5-20141028/>.
+
+ [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
+ Compression Methods", RFC 3749, DOI 10.17487/RFC3749,
+ May 2004, <http://www.rfc-editor.org/info/rfc3749>.
+
+ [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
+ B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher
+ Suites for Transport Layer Security (TLS)", RFC 4492,
+ DOI 10.17487/RFC4492, May 2006,
+ <http://www.rfc-editor.org/info/rfc4492>.
+
+ [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
+ Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
+ <http://www.rfc-editor.org/info/rfc6585>.
+
+ [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
+ Scheffenegger, Ed., "TCP Extensions for High
+ Performance", RFC 7323, DOI 10.17487/RFC7323, September
+ 2014, <http://www.rfc-editor.org/info/rfc7323>.
+
+ [TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C.
+ Jackson, "Talking to Yourself for Fun and Profit",
+ 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
+
+
+
+Belshe, et al. Standards Track [Page 81]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
+ "Recommendations for Secure Use of Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+ 2015, <http://www.rfc-editor.org/info/rfc7525>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 82]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+Appendix A. TLS 1.2 Cipher Suite Black List
+
+ An HTTP/2 implementation MAY treat the negotiation of any of the
+ following cipher suites with TLS 1.2 as a connection error
+ (Section 5.4.1) of type INADEQUATE_SECURITY:
+
+ o TLS_NULL_WITH_NULL_NULL
+
+ o TLS_RSA_WITH_NULL_MD5
+
+ o TLS_RSA_WITH_NULL_SHA
+
+ o TLS_RSA_EXPORT_WITH_RC4_40_MD5
+
+ o TLS_RSA_WITH_RC4_128_MD5
+
+ o TLS_RSA_WITH_RC4_128_SHA
+
+ o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+
+ o TLS_RSA_WITH_IDEA_CBC_SHA
+
+ o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
+
+ o TLS_RSA_WITH_DES_CBC_SHA
+
+ o TLS_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
+
+ o TLS_DH_DSS_WITH_DES_CBC_SHA
+
+ o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
+
+ o TLS_DH_RSA_WITH_DES_CBC_SHA
+
+ o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_DES_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 83]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_DHE_RSA_WITH_DES_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+
+ o TLS_DH_anon_WITH_RC4_128_MD5
+
+ o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+
+ o TLS_DH_anon_WITH_DES_CBC_SHA
+
+ o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_KRB5_WITH_DES_CBC_SHA
+
+ o TLS_KRB5_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_KRB5_WITH_RC4_128_SHA
+
+ o TLS_KRB5_WITH_IDEA_CBC_SHA
+
+ o TLS_KRB5_WITH_DES_CBC_MD5
+
+ o TLS_KRB5_WITH_3DES_EDE_CBC_MD5
+
+ o TLS_KRB5_WITH_RC4_128_MD5
+
+ o TLS_KRB5_WITH_IDEA_CBC_MD5
+
+ o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
+
+ o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
+
+ o TLS_KRB5_EXPORT_WITH_RC4_40_SHA
+
+ o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
+
+ o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
+
+ o TLS_KRB5_EXPORT_WITH_RC4_40_MD5
+
+ o TLS_PSK_WITH_NULL_SHA
+
+ o TLS_DHE_PSK_WITH_NULL_SHA
+
+ o TLS_RSA_PSK_WITH_NULL_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 84]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_DH_DSS_WITH_AES_128_CBC_SHA
+
+ o TLS_DH_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_AES_128_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_DH_anon_WITH_AES_128_CBC_SHA
+
+ o TLS_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_DH_DSS_WITH_AES_256_CBC_SHA
+
+ o TLS_DH_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_AES_256_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_DH_anon_WITH_AES_256_CBC_SHA
+
+ o TLS_RSA_WITH_NULL_SHA256
+
+ o TLS_RSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_RSA_WITH_AES_256_CBC_SHA256
+
+ o TLS_DH_DSS_WITH_AES_128_CBC_SHA256
+
+ o TLS_DH_RSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
+
+ o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
+
+ o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
+
+ o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
+
+ o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 85]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_DH_DSS_WITH_AES_256_CBC_SHA256
+
+ o TLS_DH_RSA_WITH_AES_256_CBC_SHA256
+
+ o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
+
+ o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
+
+ o TLS_DH_anon_WITH_AES_128_CBC_SHA256
+
+ o TLS_DH_anon_WITH_AES_256_CBC_SHA256
+
+ o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
+
+ o TLS_PSK_WITH_RC4_128_SHA
+
+ o TLS_PSK_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_PSK_WITH_AES_128_CBC_SHA
+
+ o TLS_PSK_WITH_AES_256_CBC_SHA
+
+ o TLS_DHE_PSK_WITH_RC4_128_SHA
+
+ o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
+
+ o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
+
+ o TLS_RSA_PSK_WITH_RC4_128_SHA
+
+ o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_RSA_PSK_WITH_AES_128_CBC_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 86]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
+
+ o TLS_RSA_WITH_SEED_CBC_SHA
+
+ o TLS_DH_DSS_WITH_SEED_CBC_SHA
+
+ o TLS_DH_RSA_WITH_SEED_CBC_SHA
+
+ o TLS_DHE_DSS_WITH_SEED_CBC_SHA
+
+ o TLS_DHE_RSA_WITH_SEED_CBC_SHA
+
+ o TLS_DH_anon_WITH_SEED_CBC_SHA
+
+ o TLS_RSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_RSA_WITH_AES_256_GCM_SHA384
+
+ o TLS_DH_RSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_DH_RSA_WITH_AES_256_GCM_SHA384
+
+ o TLS_DH_DSS_WITH_AES_128_GCM_SHA256
+
+ o TLS_DH_DSS_WITH_AES_256_GCM_SHA384
+
+ o TLS_DH_anon_WITH_AES_128_GCM_SHA256
+
+ o TLS_DH_anon_WITH_AES_256_GCM_SHA384
+
+ o TLS_PSK_WITH_AES_128_GCM_SHA256
+
+ o TLS_PSK_WITH_AES_256_GCM_SHA384
+
+ o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
+
+ o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
+
+ o TLS_PSK_WITH_AES_128_CBC_SHA256
+
+ o TLS_PSK_WITH_AES_256_CBC_SHA384
+
+ o TLS_PSK_WITH_NULL_SHA256
+
+ o TLS_PSK_WITH_NULL_SHA384
+
+ o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
+
+
+
+
+Belshe, et al. Standards Track [Page 87]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
+
+ o TLS_DHE_PSK_WITH_NULL_SHA256
+
+ o TLS_DHE_PSK_WITH_NULL_SHA384
+
+ o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
+
+ o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
+
+ o TLS_RSA_PSK_WITH_NULL_SHA256
+
+ o TLS_RSA_PSK_WITH_NULL_SHA384
+
+ o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
+
+ o TLS_EMPTY_RENEGOTIATION_INFO_SCSV
+
+ o TLS_ECDH_ECDSA_WITH_NULL_SHA
+
+ o TLS_ECDH_ECDSA_WITH_RC4_128_SHA
+
+ o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 88]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_NULL_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDH_RSA_WITH_NULL_SHA
+
+ o TLS_ECDH_RSA_WITH_RC4_128_SHA
+
+ o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDHE_RSA_WITH_NULL_SHA
+
+ o TLS_ECDHE_RSA_WITH_RC4_128_SHA
+
+ o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDH_anon_WITH_NULL_SHA
+
+ o TLS_ECDH_anon_WITH_RC4_128_SHA
+
+ o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDH_anon_WITH_AES_128_CBC_SHA
+
+ o TLS_ECDH_anon_WITH_AES_256_CBC_SHA
+
+ o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA
+
+
+
+
+Belshe, et al. Standards Track [Page 89]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_SRP_SHA_WITH_AES_128_CBC_SHA
+
+ o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
+
+ o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
+
+ o TLS_SRP_SHA_WITH_AES_256_CBC_SHA
+
+ o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
+
+ o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
+
+ o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
+
+ o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
+
+ o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
+
+ o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
+
+ o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
+
+ o TLS_ECDHE_PSK_WITH_RC4_128_SHA
+
+ o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
+
+ o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
+
+ o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
+
+ o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
+
+ o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
+
+
+
+
+Belshe, et al. Standards Track [Page 90]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_ECDHE_PSK_WITH_NULL_SHA
+
+ o TLS_ECDHE_PSK_WITH_NULL_SHA256
+
+ o TLS_ECDHE_PSK_WITH_NULL_SHA384
+
+ o TLS_RSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_RSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_RSA_WITH_ARIA_128_GCM_SHA256
+
+
+
+
+Belshe, et al. Standards Track [Page 91]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_RSA_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_PSK_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_PSK_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_PSK_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_PSK_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
+
+ o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
+
+ o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
+
+ o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
+
+ o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
+
+
+
+
+Belshe, et al. Standards Track [Page 92]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
+
+ o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
+
+ o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256
+
+
+
+
+Belshe, et al. Standards Track [Page 93]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+ o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
+
+ o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
+
+ o TLS_RSA_WITH_AES_128_CCM
+
+ o TLS_RSA_WITH_AES_256_CCM
+
+ o TLS_RSA_WITH_AES_128_CCM_8
+
+ o TLS_RSA_WITH_AES_256_CCM_8
+
+ o TLS_PSK_WITH_AES_128_CCM
+
+ o TLS_PSK_WITH_AES_256_CCM
+
+ o TLS_PSK_WITH_AES_128_CCM_8
+
+ o TLS_PSK_WITH_AES_256_CCM_8
+
+ Note: This list was assembled from the set of registered TLS
+ cipher suites at the time of writing. This list includes those
+ cipher suites that do not offer an ephemeral key exchange and
+ those that are based on the TLS null, stream, or block cipher type
+ (as defined in Section 6.2.3 of [TLS12]). Additional cipher
+ suites with these properties could be defined; these would not be
+ explicitly prohibited.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 94]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+Acknowledgements
+
+ This document includes substantial input from the following
+ individuals:
+
+ o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa
+ Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam
+ Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
+ Paul Amer, Fan Yang, and Jonathan Leighton (SPDY contributors).
+
+ o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
+
+ o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
+ Jitu Padhye, Roberto Peon, and Rob Trace (Flow control).
+
+ o Mike Bishop (Extensibility).
+
+ o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
+ Bishop, and Herve Ruellan (Substantial editorial contributions).
+
+ o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp,
+ and Jonathan Thackray.
+
+ o Alexey Melnikov, who was an editor of this document in 2013.
+
+ A substantial proportion of Martin's contribution was supported by
+ Microsoft during his employment there.
+
+ The Japanese HTTP/2 community provided invaluable contributions,
+ including a number of implementations as well as numerous technical
+ and editorial contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 95]
+\f
+RFC 7540 HTTP/2 May 2015
+
+
+Authors' Addresses
+
+ Mike Belshe
+ BitGo
+
+ EMail: mike@belshe.com
+
+
+ Roberto Peon
+ Google, Inc
+
+ EMail: fenix@google.com
+
+
+ Martin Thomson (editor)
+ Mozilla
+ 331 E Evelyn Street
+ Mountain View, CA 94041
+ United States
+
+ EMail: martin.thomson@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Belshe, et al. Standards Track [Page 96]
+\f
--- /dev/null
+
+
+
+
+Internet Engineering Task Force (IETF) R. Fielding, Ed.
+Request for Comments: 9112 Adobe
+STD: 99 M. Nottingham, Ed.
+Obsoletes: 7230 Fastly
+Category: Standards Track J. Reschke, Ed.
+ISSN: 2070-1721 greenbytes
+ June 2022
+
+
+ HTTP/1.1
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) is a stateless application-
+ level protocol for distributed, collaborative, hypertext information
+ systems. This document specifies the HTTP/1.1 message syntax,
+ message parsing, connection management, and related security
+ concerns.
+
+ This document obsoletes portions of RFC 7230.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9112.
+
+Copyright Notice
+
+ Copyright (c) 2022 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Requirements Notation
+ 1.2. Syntax Notation
+ 2. Message
+ 2.1. Message Format
+ 2.2. Message Parsing
+ 2.3. HTTP Version
+ 3. Request Line
+ 3.1. Method
+ 3.2. Request Target
+ 3.2.1. origin-form
+ 3.2.2. absolute-form
+ 3.2.3. authority-form
+ 3.2.4. asterisk-form
+ 3.3. Reconstructing the Target URI
+ 4. Status Line
+ 5. Field Syntax
+ 5.1. Field Line Parsing
+ 5.2. Obsolete Line Folding
+ 6. Message Body
+ 6.1. Transfer-Encoding
+ 6.2. Content-Length
+ 6.3. Message Body Length
+ 7. Transfer Codings
+ 7.1. Chunked Transfer Coding
+ 7.1.1. Chunk Extensions
+ 7.1.2. Chunked Trailer Section
+ 7.1.3. Decoding Chunked
+ 7.2. Transfer Codings for Compression
+ 7.3. Transfer Coding Registry
+ 7.4. Negotiating Transfer Codings
+ 8. Handling Incomplete Messages
+ 9. Connection Management
+ 9.1. Establishment
+ 9.2. Associating a Response to a Request
+ 9.3. Persistence
+ 9.3.1. Retrying Requests
+ 9.3.2. Pipelining
+ 9.4. Concurrency
+ 9.5. Failures and Timeouts
+ 9.6. Tear-down
+ 9.7. TLS Connection Initiation
+ 9.8. TLS Connection Closure
+ 10. Enclosing Messages as Data
+ 10.1. Media Type message/http
+ 10.2. Media Type application/http
+ 11. Security Considerations
+ 11.1. Response Splitting
+ 11.2. Request Smuggling
+ 11.3. Message Integrity
+ 11.4. Message Confidentiality
+ 12. IANA Considerations
+ 12.1. Field Name Registration
+ 12.2. Media Type Registration
+ 12.3. Transfer Coding Registration
+ 12.4. ALPN Protocol ID Registration
+ 13. References
+ 13.1. Normative References
+ 13.2. Informative References
+ Appendix A. Collected ABNF
+ Appendix B. Differences between HTTP and MIME
+ B.1. MIME-Version
+ B.2. Conversion to Canonical Form
+ B.3. Conversion of Date Formats
+ B.4. Conversion of Content-Encoding
+ B.5. Conversion of Content-Transfer-Encoding
+ B.6. MHTML and Line Length Limitations
+ Appendix C. Changes from Previous RFCs
+ C.1. Changes from HTTP/0.9
+ C.2. Changes from HTTP/1.0
+ C.2.1. Multihomed Web Servers
+ C.2.2. Keep-Alive Connections
+ C.2.3. Introduction of Transfer-Encoding
+ C.3. Changes from RFC 7230
+ Acknowledgements
+ Index
+ Authors' Addresses
+
+1. Introduction
+
+ The Hypertext Transfer Protocol (HTTP) is a stateless application-
+ level request/response protocol that uses extensible semantics and
+ self-descriptive messages for flexible interaction with network-based
+ hypertext information systems. HTTP/1.1 is defined by:
+
+ * This document
+
+ * "HTTP Semantics" [HTTP]
+
+ * "HTTP Caching" [CACHING]
+
+ This document specifies how HTTP semantics are conveyed using the
+ HTTP/1.1 message syntax, framing, and connection management
+ mechanisms. Its goal is to define the complete set of requirements
+ for HTTP/1.1 message parsers and message-forwarding intermediaries.
+
+ This document obsoletes the portions of RFC 7230 related to HTTP/1.1
+ messaging and connection management, with the changes being
+ summarized in Appendix C.3. The other parts of RFC 7230 are
+ obsoleted by "HTTP Semantics" [HTTP].
+
+1.1. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+ Conformance criteria and considerations regarding error handling are
+ defined in Section 2 of [HTTP].
+
+1.2. Syntax Notation
+
+ This specification uses the Augmented Backus-Naur Form (ABNF)
+ notation of [RFC5234], extended with the notation for case-
+ sensitivity in strings defined in [RFC7405].
+
+ It also uses a list extension, defined in Section 5.6.1 of [HTTP],
+ that allows for compact definition of comma-separated lists using a
+ "#" operator (similar to how the "*" operator indicates repetition).
+ Appendix A shows the collected grammar with all list operators
+ expanded to standard ABNF notation.
+
+ As a convention, ABNF rule names prefixed with "obs-" denote obsolete
+ grammar rules that appear for historical reasons.
+
+ The following core rules are included by reference, as defined in
+ [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
+ (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
+ HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
+ feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
+ visible [USASCII] character).
+
+ The rules below are defined in [HTTP]:
+
+ BWS = <BWS, see [HTTP], Section 5.6.3>
+ OWS = <OWS, see [HTTP], Section 5.6.3>
+ RWS = <RWS, see [HTTP], Section 5.6.3>
+ absolute-path = <absolute-path, see [HTTP], Section 4.1>
+ field-name = <field-name, see [HTTP], Section 5.1>
+ field-value = <field-value, see [HTTP], Section 5.5>
+ obs-text = <obs-text, see [HTTP], Section 5.6.4>
+ quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
+ token = <token, see [HTTP], Section 5.6.2>
+ transfer-coding =
+ <transfer-coding, see [HTTP], Section 10.1.4>
+
+ The rules below are defined in [URI]:
+
+ absolute-URI = <absolute-URI, see [URI], Section 4.3>
+ authority = <authority, see [URI], Section 3.2>
+ uri-host = <host, see [URI], Section 3.2.2>
+ port = <port, see [URI], Section 3.2.3>
+ query = <query, see [URI], Section 3.4>
+
+2. Message
+
+ HTTP/1.1 clients and servers communicate by sending messages. See
+ Section 3 of [HTTP] for the general terminology and core concepts of
+ HTTP.
+
+2.1. Message Format
+
+ An HTTP/1.1 message consists of a start-line followed by a CRLF and a
+ sequence of octets in a format similar to the Internet Message Format
+ [RFC5322]: zero or more header field lines (collectively referred to
+ as the "headers" or the "header section"), an empty line indicating
+ the end of the header section, and an optional message body.
+
+ HTTP-message = start-line CRLF
+ *( field-line CRLF )
+ CRLF
+ [ message-body ]
+
+ A message can be either a request from client to server or a response
+ from server to client. Syntactically, the two types of messages
+ differ only in the start-line, which is either a request-line (for
+ requests) or a status-line (for responses), and in the algorithm for
+ determining the length of the message body (Section 6).
+
+ start-line = request-line / status-line
+
+ In theory, a client could receive requests and a server could receive
+ responses, distinguishing them by their different start-line formats.
+ In practice, servers are implemented to only expect a request (a
+ response is interpreted as an unknown or invalid request method), and
+ clients are implemented to only expect a response.
+
+ HTTP makes use of some protocol elements similar to the Multipurpose
+ Internet Mail Extensions (MIME) [RFC2045]. See Appendix B for the
+ differences between HTTP and MIME messages.
+
+2.2. Message Parsing
+
+ The normal procedure for parsing an HTTP message is to read the
+ start-line into a structure, read each header field line into a hash
+ table by field name until the empty line, and then use the parsed
+ data to determine if a message body is expected. If a message body
+ has been indicated, then it is read as a stream until an amount of
+ octets equal to the message body length is read or the connection is
+ closed.
+
+ A recipient MUST parse an HTTP message as a sequence of octets in an
+ encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
+ message as a stream of Unicode characters, without regard for the
+ specific encoding, creates security vulnerabilities due to the
+ varying ways that string processing libraries handle invalid
+ multibyte character sequences that contain the octet LF (%x0A).
+ String-based parsers can only be safely used within protocol elements
+ after the element has been extracted from the message, such as within
+ a header field line value after message parsing has delineated the
+ individual field lines.
+
+ Although the line terminator for the start-line and fields is the
+ sequence CRLF, a recipient MAY recognize a single LF as a line
+ terminator and ignore any preceding CR.
+
+ A sender MUST NOT generate a bare CR (a CR character not immediately
+ followed by LF) within any protocol elements other than the content.
+ A recipient of such a bare CR MUST consider that element to be
+ invalid or replace each bare CR with SP before processing the element
+ or forwarding the message.
+
+ Older HTTP/1.0 user agent implementations might send an extra CRLF
+ after a POST request as a workaround for some early server
+ applications that failed to read message body content that was not
+ terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
+ or follow a request with an extra CRLF. If terminating the request
+ message body with a line-ending is desired, then the user agent MUST
+ count the terminating CRLF octets as part of the message body length.
+
+ In the interest of robustness, a server that is expecting to receive
+ and parse a request-line SHOULD ignore at least one empty line (CRLF)
+ received prior to the request-line.
+
+ A sender MUST NOT send whitespace between the start-line and the
+ first header field.
+
+ A recipient that receives whitespace between the start-line and the
+ first header field MUST either reject the message as invalid or
+ consume each whitespace-preceded line without further processing of
+ it (i.e., ignore the entire line, along with any subsequent lines
+ preceded by whitespace, until a properly formed header field is
+ received or the header section is terminated). Rejection or removal
+ of invalid whitespace-preceded lines is necessary to prevent their
+ misinterpretation by downstream recipients that might be vulnerable
+ to request smuggling (Section 11.2) or response splitting
+ (Section 11.1) attacks.
+
+ When a server listening only for HTTP request messages, or processing
+ what appears from the start-line to be an HTTP request message,
+ receives a sequence of octets that does not match the HTTP-message
+ grammar aside from the robustness exceptions listed above, the server
+ SHOULD respond with a 400 (Bad Request) response and close the
+ connection.
+
+2.3. HTTP Version
+
+ HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+ of the protocol. This specification defines version "1.1".
+ Section 2.5 of [HTTP] specifies the semantics of HTTP version
+ numbers.
+
+ The version of an HTTP/1.x message is indicated by an HTTP-version
+ field in the start-line. HTTP-version is case-sensitive.
+
+ HTTP-version = HTTP-name "/" DIGIT "." DIGIT
+ HTTP-name = %s"HTTP"
+
+ When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [HTTP/1.0]
+ or a recipient whose version is unknown, the HTTP/1.1 message is
+ constructed such that it can be interpreted as a valid HTTP/1.0
+ message if all of the newer features are ignored. This specification
+ places recipient-version requirements on some new features so that a
+ conformant sender will only use compatible features until it has
+ determined, through configuration or the receipt of a message, that
+ the recipient supports HTTP/1.1.
+
+ Intermediaries that process HTTP messages (i.e., all intermediaries
+ other than those acting as tunnels) MUST send their own HTTP-version
+ in forwarded messages, unless it is purposefully downgraded as a
+ workaround for an upstream issue. In other words, an intermediary is
+ not allowed to blindly forward the start-line without ensuring that
+ the protocol version in that message matches a version to which that
+ intermediary is conformant for both the receiving and sending of
+ messages. Forwarding an HTTP message without rewriting the HTTP-
+ version might result in communication errors when downstream
+ recipients use the message sender's version to determine what
+ features are safe to use for later communication with that sender.
+
+ A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
+ is known or suspected that the client incorrectly implements the HTTP
+ specification and is incapable of correctly processing later version
+ responses, such as when a client fails to parse the version number
+ correctly or when an intermediary is known to blindly forward the
+ HTTP-version even when it doesn't conform to the given minor version
+ of the protocol. Such protocol downgrades SHOULD NOT be performed
+ unless triggered by specific client attributes, such as when one or
+ more of the request header fields (e.g., User-Agent) uniquely match
+ the values sent by a client known to be in error.
+
+3. Request Line
+
+ A request-line begins with a method token, followed by a single space
+ (SP), the request-target, and another single space (SP), and ends
+ with the protocol version.
+
+ request-line = method SP request-target SP HTTP-version
+
+ Although the request-line grammar rule requires that each of the
+ component elements be separated by a single SP octet, recipients MAY
+ instead parse on whitespace-delimited word boundaries and, aside from
+ the CRLF terminator, treat any form of whitespace as the SP separator
+ while ignoring preceding or trailing whitespace; such whitespace
+ includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
+ (%x0C), or bare CR. However, lenient parsing can result in request
+ smuggling security vulnerabilities if there are multiple recipients
+ of the message and each has its own unique interpretation of
+ robustness (see Section 11.2).
+
+ HTTP does not place a predefined limit on the length of a request-
+ line, as described in Section 2.3 of [HTTP]. A server that receives
+ a method longer than any that it implements SHOULD respond with a 501
+ (Not Implemented) status code. A server that receives a request-
+ target longer than any URI it wishes to parse MUST respond with a 414
+ (URI Too Long) status code (see Section 15.5.15 of [HTTP]).
+
+ Various ad hoc limitations on request-line length are found in
+ practice. It is RECOMMENDED that all HTTP senders and recipients
+ support, at a minimum, request-line lengths of 8000 octets.
+
+3.1. Method
+
+ The method token indicates the request method to be performed on the
+ target resource. The request method is case-sensitive.
+
+ method = token
+
+ The request methods defined by this specification can be found in
+ Section 9 of [HTTP], along with information regarding the HTTP method
+ registry and considerations for defining new methods.
+
+3.2. Request Target
+
+ The request-target identifies the target resource upon which to apply
+ the request. The client derives a request-target from its desired
+ target URI. There are four distinct formats for the request-target,
+ depending on both the method being requested and whether the request
+ is to a proxy.
+
+ request-target = origin-form
+ / absolute-form
+ / authority-form
+ / asterisk-form
+
+ No whitespace is allowed in the request-target. Unfortunately, some
+ user agents fail to properly encode or exclude whitespace found in
+ hypertext references, resulting in those disallowed characters being
+ sent as the request-target in a malformed request-line.
+
+ Recipients of an invalid request-line SHOULD respond with either a
+ 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
+ the request-target properly encoded. A recipient SHOULD NOT attempt
+ to autocorrect and then process the request without a redirect, since
+ the invalid request-line might be deliberately crafted to bypass
+ security filters along the request chain.
+
+ A client MUST send a Host header field (Section 7.2 of [HTTP]) in all
+ HTTP/1.1 request messages. If the target URI includes an authority
+ component, then a client MUST send a field value for Host that is
+ identical to that authority component, excluding any userinfo
+ subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). If the
+ authority component is missing or undefined for the target URI, then
+ a client MUST send a Host header field with an empty field value.
+
+ A server MUST respond with a 400 (Bad Request) status code to any
+ HTTP/1.1 request message that lacks a Host header field and to any
+ request message that contains more than one Host header field line or
+ a Host header field with an invalid field value.
+
+3.2.1. origin-form
+
+ The most common form of request-target is the "origin-form".
+
+ origin-form = absolute-path [ "?" query ]
+
+ When making a request directly to an origin server, other than a
+ CONNECT or server-wide OPTIONS request (as detailed below), a client
+ MUST send only the absolute path and query components of the target
+ URI as the request-target. If the target URI's path component is
+ empty, the client MUST send "/" as the path within the origin-form of
+ request-target. A Host header field is also sent, as defined in
+ Section 7.2 of [HTTP].
+
+ For example, a client wishing to retrieve a representation of the
+ resource identified as
+
+ http://www.example.org/where?q=now
+
+ directly from the origin server would open (or reuse) a TCP
+ connection to port 80 of the host "www.example.org" and send the
+ lines:
+
+ GET /where?q=now HTTP/1.1
+ Host: www.example.org
+
+ followed by the remainder of the request message.
+
+3.2.2. absolute-form
+
+ When making a request to a proxy, other than a CONNECT or server-wide
+ OPTIONS request (as detailed below), a client MUST send the target
+ URI in "absolute-form" as the request-target.
+
+ absolute-form = absolute-URI
+
+ The proxy is requested to either service that request from a valid
+ cache, if possible, or make the same request on the client's behalf
+ either to the next inbound proxy server or directly to the origin
+ server indicated by the request-target. Requirements on such
+ "forwarding" of messages are defined in Section 7.6 of [HTTP].
+
+ An example absolute-form of request-line would be:
+
+ GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
+
+ A client MUST send a Host header field in an HTTP/1.1 request even if
+ the request-target is in the absolute-form, since this allows the
+ Host information to be forwarded through ancient HTTP/1.0 proxies
+ that might not have implemented Host.
+
+ When a proxy receives a request with an absolute-form of request-
+ target, the proxy MUST ignore the received Host header field (if any)
+ and instead replace it with the host information of the request-
+ target. A proxy that forwards such a request MUST generate a new
+ Host field value based on the received request-target rather than
+ forward the received Host field value.
+
+ When an origin server receives a request with an absolute-form of
+ request-target, the origin server MUST ignore the received Host
+ header field (if any) and instead use the host information of the
+ request-target. Note that if the request-target does not have an
+ authority component, an empty Host header field will be sent in this
+ case.
+
+ A server MUST accept the absolute-form in requests even though most
+ HTTP/1.1 clients will only send the absolute-form to a proxy.
+
+3.2.3. authority-form
+
+ The "authority-form" of request-target is only used for CONNECT
+ requests (Section 9.3.6 of [HTTP]). It consists of only the uri-host
+ and port number of the tunnel destination, separated by a colon
+ (":").
+
+ authority-form = uri-host ":" port
+
+ When making a CONNECT request to establish a tunnel through one or
+ more proxies, a client MUST send only the host and port of the tunnel
+ destination as the request-target. The client obtains the host and
+ port from the target URI's authority component, except that it sends
+ the scheme's default port if the target URI elides the port. For
+ example, a CONNECT request to "http://www.example.com" looks like the
+ following:
+
+ CONNECT www.example.com:80 HTTP/1.1
+ Host: www.example.com
+
+3.2.4. asterisk-form
+
+ The "asterisk-form" of request-target is only used for a server-wide
+ OPTIONS request (Section 9.3.7 of [HTTP]).
+
+ asterisk-form = "*"
+
+ When a client wishes to request OPTIONS for the server as a whole, as
+ opposed to a specific named resource of that server, the client MUST
+ send only "*" (%x2A) as the request-target. For example,
+
+ OPTIONS * HTTP/1.1
+
+ If a proxy receives an OPTIONS request with an absolute-form of
+ request-target in which the URI has an empty path and no query
+ component, then the last proxy on the request chain MUST send a
+ request-target of "*" when it forwards the request to the indicated
+ origin server.
+
+ For example, the request
+
+ OPTIONS http://www.example.org:8001 HTTP/1.1
+
+ would be forwarded by the final proxy as
+
+ OPTIONS * HTTP/1.1
+ Host: www.example.org:8001
+
+ after connecting to port 8001 of host "www.example.org".
+
+3.3. Reconstructing the Target URI
+
+ The target URI is the request-target when the request-target is in
+ absolute-form. In that case, a server will parse the URI into its
+ generic components for further evaluation.
+
+ Otherwise, the server reconstructs the target URI from the connection
+ context and various parts of the request message in order to identify
+ the target resource (Section 7.1 of [HTTP]):
+
+ * If the server's configuration provides for a fixed URI scheme, or
+ a scheme is provided by a trusted outbound gateway, that scheme is
+ used for the target URI. This is common in large-scale
+ deployments because a gateway server will receive the client's
+ connection context and replace that with their own connection to
+ the inbound server. Otherwise, if the request is received over a
+ secured connection, the target URI's scheme is "https"; if not,
+ the scheme is "http".
+
+ * If the request-target is in authority-form, the target URI's
+ authority component is the request-target. Otherwise, the target
+ URI's authority component is the field value of the Host header
+ field. If there is no Host header field or if its field value is
+ empty or invalid, the target URI's authority component is empty.
+
+ * If the request-target is in authority-form or asterisk-form, the
+ target URI's combined path and query component is empty.
+ Otherwise, the target URI's combined path and query component is
+ the request-target.
+
+ * The components of a reconstructed target URI, once determined as
+ above, can be recombined into absolute-URI form by concatenating
+ the scheme, "://", authority, and combined path and query
+ component.
+
+ Example 1: The following message received over a secure connection
+
+ GET /pub/WWW/TheProject.html HTTP/1.1
+ Host: www.example.org
+
+ has a target URI of
+
+ https://www.example.org/pub/WWW/TheProject.html
+
+ Example 2: The following message received over an insecure connection
+
+ OPTIONS * HTTP/1.1
+ Host: www.example.org:8080
+
+ has a target URI of
+
+ http://www.example.org:8080
+
+ If the target URI's authority component is empty and its URI scheme
+ requires a non-empty authority (as is the case for "http" and
+ "https"), the server can reject the request or determine whether a
+ configured default applies that is consistent with the incoming
+ connection's context. Context might include connection details like
+ address and port, what security has been applied, and locally defined
+ information specific to that server's configuration. An empty
+ authority is replaced with the configured default before further
+ processing of the request.
+
+ Supplying a default name for authority within the context of a
+ secured connection is inherently unsafe if there is any chance that
+ the user agent's intended authority might differ from the default. A
+ server that can uniquely identify an authority from the request
+ context MAY use that identity as a default without this risk.
+ Alternatively, it might be better to redirect the request to a safe
+ resource that explains how to obtain a new client.
+
+ Note that reconstructing the client's target URI is only half of the
+ process for identifying a target resource. The other half is
+ determining whether that target URI identifies a resource for which
+ the server is willing and able to send a response, as defined in
+ Section 7.4 of [HTTP].
+
+4. Status Line
+
+ The first line of a response message is the status-line, consisting
+ of the protocol version, a space (SP), the status code, and another
+ space and ending with an OPTIONAL textual phrase describing the
+ status code.
+
+ status-line = HTTP-version SP status-code SP [ reason-phrase ]
+
+ Although the status-line grammar rule requires that each of the
+ component elements be separated by a single SP octet, recipients MAY
+ instead parse on whitespace-delimited word boundaries and, aside from
+ the line terminator, treat any form of whitespace as the SP separator
+ while ignoring preceding or trailing whitespace; such whitespace
+ includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
+ (%x0C), or bare CR. However, lenient parsing can result in response
+ splitting security vulnerabilities if there are multiple recipients
+ of the message and each has its own unique interpretation of
+ robustness (see Section 11.1).
+
+ The status-code element is a 3-digit integer code describing the
+ result of the server's attempt to understand and satisfy the client's
+ corresponding request. A recipient parses and interprets the
+ remainder of the response message in light of the semantics defined
+ for that status code, if the status code is recognized by that
+ recipient, or in accordance with the class of that status code when
+ the specific code is unrecognized.
+
+ status-code = 3DIGIT
+
+ HTTP's core status codes are defined in Section 15 of [HTTP], along
+ with the classes of status codes, considerations for the definition
+ of new status codes, and the IANA registry for collecting such
+ definitions.
+
+ The reason-phrase element exists for the sole purpose of providing a
+ textual description associated with the numeric status code, mostly
+ out of deference to earlier Internet application protocols that were
+ more frequently used with interactive text clients.
+
+ reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
+
+ A client SHOULD ignore the reason-phrase content because it is not a
+ reliable channel for information (it might be translated for a given
+ locale, overwritten by intermediaries, or discarded when the message
+ is forwarded via other versions of HTTP). A server MUST send the
+ space that separates the status-code from the reason-phrase even when
+ the reason-phrase is absent (i.e., the status-line would end with the
+ space).
+
+5. Field Syntax
+
+ Each field line consists of a case-insensitive field name followed by
+ a colon (":"), optional leading whitespace, the field line value, and
+ optional trailing whitespace.
+
+ field-line = field-name ":" OWS field-value OWS
+
+ Rules for parsing within field values are defined in Section 5.5 of
+ [HTTP]. This section covers the generic syntax for header field
+ inclusion within, and extraction from, HTTP/1.1 messages.
+
+5.1. Field Line Parsing
+
+ Messages are parsed using a generic algorithm, independent of the
+ individual field names. The contents within a given field line value
+ are not parsed until a later stage of message interpretation (usually
+ after the message's entire field section has been processed).
+
+ No whitespace is allowed between the field name and colon. In the
+ past, differences in the handling of such whitespace have led to
+ security vulnerabilities in request routing and response handling. A
+ server MUST reject, with a response status code of 400 (Bad Request),
+ any received request message that contains whitespace between a
+ header field name and colon. A proxy MUST remove any such whitespace
+ from a response message before forwarding the message downstream.
+
+ A field line value might be preceded and/or followed by optional
+ whitespace (OWS); a single SP preceding the field line value is
+ preferred for consistent readability by humans. The field line value
+ does not include that leading or trailing whitespace: OWS occurring
+ before the first non-whitespace octet of the field line value, or
+ after the last non-whitespace octet of the field line value, is
+ excluded by parsers when extracting the field line value from a field
+ line.
+
+5.2. Obsolete Line Folding
+
+ Historically, HTTP/1.x field values could be extended over multiple
+ lines by preceding each extra line with at least one space or
+ horizontal tab (obs-fold). This specification deprecates such line
+ folding except within the "message/http" media type (Section 10.1).
+
+ obs-fold = OWS CRLF RWS
+ ; obsolete line folding
+
+ A sender MUST NOT generate a message that includes line folding
+ (i.e., that has any field line value that contains a match to the
+ obs-fold rule) unless the message is intended for packaging within
+ the "message/http" media type.
+
+ A server that receives an obs-fold in a request message that is not
+ within a "message/http" container MUST either reject the message by
+ sending a 400 (Bad Request), preferably with a representation
+ explaining that obsolete line folding is unacceptable, or replace
+ each received obs-fold with one or more SP octets prior to
+ interpreting the field value or forwarding the message downstream.
+
+ A proxy or gateway that receives an obs-fold in a response message
+ that is not within a "message/http" container MUST either discard the
+ message and replace it with a 502 (Bad Gateway) response, preferably
+ with a representation explaining that unacceptable line folding was
+ received, or replace each received obs-fold with one or more SP
+ octets prior to interpreting the field value or forwarding the
+ message downstream.
+
+ A user agent that receives an obs-fold in a response message that is
+ not within a "message/http" container MUST replace each received
+ obs-fold with one or more SP octets prior to interpreting the field
+ value.
+
+6. Message Body
+
+ The message body (if any) of an HTTP/1.1 message is used to carry
+ content (Section 6.4 of [HTTP]) for the request or response. The
+ message body is identical to the content unless a transfer coding has
+ been applied, as described in Section 6.1.
+
+ message-body = *OCTET
+
+ The rules for determining when a message body is present in an
+ HTTP/1.1 message differ for requests and responses.
+
+ The presence of a message body in a request is signaled by a
+ Content-Length or Transfer-Encoding header field. Request message
+ framing is independent of method semantics.
+
+ The presence of a message body in a response, as detailed in
+ Section 6.3, depends on both the request method to which it is
+ responding and the response status code. This corresponds to when
+ response content is allowed by HTTP semantics (Section 6.4.1 of
+ [HTTP]).
+
+6.1. Transfer-Encoding
+
+ The Transfer-Encoding header field lists the transfer coding names
+ corresponding to the sequence of transfer codings that have been (or
+ will be) applied to the content in order to form the message body.
+ Transfer codings are defined in Section 7.
+
+ Transfer-Encoding = #transfer-coding
+ ; defined in [HTTP], Section 10.1.4
+
+ Transfer-Encoding is analogous to the Content-Transfer-Encoding field
+ of MIME, which was designed to enable safe transport of binary data
+ over a 7-bit transport service ([RFC2045], Section 6). However, safe
+ transport has a different focus for an 8bit-clean transfer protocol.
+ In HTTP's case, Transfer-Encoding is primarily intended to accurately
+ delimit dynamically generated content. It also serves to distinguish
+ encodings that are only applied in transit from the encodings that
+ are a characteristic of the selected representation.
+
+ A recipient MUST be able to parse the chunked transfer coding
+ (Section 7.1) because it plays a crucial role in framing messages
+ when the content size is not known in advance. A sender MUST NOT
+ apply the chunked transfer coding more than once to a message body
+ (i.e., chunking an already chunked message is not allowed). If any
+ transfer coding other than chunked is applied to a request's content,
+ the sender MUST apply chunked as the final transfer coding to ensure
+ that the message is properly framed. If any transfer coding other
+ than chunked is applied to a response's content, the sender MUST
+ either apply chunked as the final transfer coding or terminate the
+ message by closing the connection.
+
+ For example,
+
+ Transfer-Encoding: gzip, chunked
+
+ indicates that the content has been compressed using the gzip coding
+ and then chunked using the chunked coding while forming the message
+ body.
+
+ Unlike Content-Encoding (Section 8.4.1 of [HTTP]), Transfer-Encoding
+ is a property of the message, not of the representation. Any
+ recipient along the request/response chain MAY decode the received
+ transfer coding(s) or apply additional transfer coding(s) to the
+ message body, assuming that corresponding changes are made to the
+ Transfer-Encoding field value. Additional information about the
+ encoding parameters can be provided by other header fields not
+ defined by this specification.
+
+ Transfer-Encoding MAY be sent in a response to a HEAD request or in a
+ 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET
+ request, neither of which includes a message body, to indicate that
+ the origin server would have applied a transfer coding to the message
+ body if the request had been an unconditional GET. This indication
+ is not required, however, because any recipient on the response chain
+ (including the origin server) can remove transfer codings when they
+ are not needed.
+
+ A server MUST NOT send a Transfer-Encoding header field in any
+ response with a status code of 1xx (Informational) or 204 (No
+ Content). A server MUST NOT send a Transfer-Encoding header field in
+ any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of
+ [HTTP]).
+
+ A server that receives a request message with a transfer coding it
+ does not understand SHOULD respond with 501 (Not Implemented).
+
+ Transfer-Encoding was added in HTTP/1.1. It is generally assumed
+ that implementations advertising only HTTP/1.0 support will not
+ understand how to process transfer-encoded content, and that an
+ HTTP/1.0 message received with a Transfer-Encoding is likely to have
+ been forwarded without proper handling of the chunked transfer coding
+ in transit.
+
+ A client MUST NOT send a request containing Transfer-Encoding unless
+ it knows the server will handle HTTP/1.1 requests (or later minor
+ revisions); such knowledge might be in the form of specific user
+ configuration or by remembering the version of a prior received
+ response. A server MUST NOT send a response containing Transfer-
+ Encoding unless the corresponding request indicates HTTP/1.1 (or
+ later minor revisions).
+
+ Early implementations of Transfer-Encoding would occasionally send
+ both a chunked transfer coding for message framing and an estimated
+ Content-Length header field for use by progress bars. This is why
+ Transfer-Encoding is defined as overriding Content-Length, as opposed
+ to them being mutually incompatible. Unfortunately, forwarding such
+ a message can lead to vulnerabilities regarding request smuggling
+ (Section 11.2) or response splitting (Section 11.1) attacks if any
+ downstream recipient fails to parse the message according to this
+ specification, particularly when a downstream recipient only
+ implements HTTP/1.0.
+
+ A server MAY reject a request that contains both Content-Length and
+ Transfer-Encoding or process such a request in accordance with the
+ Transfer-Encoding alone. Regardless, the server MUST close the
+ connection after responding to such a request to avoid the potential
+ attacks.
+
+ A server or client that receives an HTTP/1.0 message containing a
+ Transfer-Encoding header field MUST treat the message as if the
+ framing is faulty, even if a Content-Length is present, and close the
+ connection after processing the message. The message sender might
+ have retained a portion of the message, in buffer, that could be
+ misinterpreted by further use of the connection.
+
+6.2. Content-Length
+
+ When a message does not have a Transfer-Encoding header field, a
+ Content-Length header field (Section 8.6 of [HTTP]) can provide the
+ anticipated size, as a decimal number of octets, for potential
+ content. For messages that do include content, the Content-Length
+ field value provides the framing information necessary for
+ determining where the data (and message) ends. For messages that do
+ not include content, the Content-Length indicates the size of the
+ selected representation (Section 8.6 of [HTTP]).
+
+ A sender MUST NOT send a Content-Length header field in any message
+ that contains a Transfer-Encoding header field.
+
+ | *Note:* HTTP's use of Content-Length for message framing
+ | differs significantly from the same field's use in MIME, where
+ | it is an optional field used only within the "message/external-
+ | body" media-type.
+
+6.3. Message Body Length
+
+ The length of a message body is determined by one of the following
+ (in order of precedence):
+
+ 1. Any response to a HEAD request and any response with a 1xx
+ (Informational), 204 (No Content), or 304 (Not Modified) status
+ code is always terminated by the first empty line after the
+ header fields, regardless of the header fields present in the
+ message, and thus cannot contain a message body or trailer
+ section.
+
+ 2. Any 2xx (Successful) response to a CONNECT request implies that
+ the connection will become a tunnel immediately after the empty
+ line that concludes the header fields. A client MUST ignore any
+ Content-Length or Transfer-Encoding header fields received in
+ such a message.
+
+ 3. If a message is received with both a Transfer-Encoding and a
+ Content-Length header field, the Transfer-Encoding overrides the
+ Content-Length. Such a message might indicate an attempt to
+ perform request smuggling (Section 11.2) or response splitting
+ (Section 11.1) and ought to be handled as an error. An
+ intermediary that chooses to forward the message MUST first
+ remove the received Content-Length field and process the
+ Transfer-Encoding (as described below) prior to forwarding the
+ message downstream.
+
+ 4. If a Transfer-Encoding header field is present and the chunked
+ transfer coding (Section 7.1) is the final encoding, the message
+ body length is determined by reading and decoding the chunked
+ data until the transfer coding indicates the data is complete.
+
+ If a Transfer-Encoding header field is present in a response and
+ the chunked transfer coding is not the final encoding, the
+ message body length is determined by reading the connection until
+ it is closed by the server.
+
+ If a Transfer-Encoding header field is present in a request and
+ the chunked transfer coding is not the final encoding, the
+ message body length cannot be determined reliably; the server
+ MUST respond with the 400 (Bad Request) status code and then
+ close the connection.
+
+ 5. If a message is received without Transfer-Encoding and with an
+ invalid Content-Length header field, then the message framing is
+ invalid and the recipient MUST treat it as an unrecoverable
+ error, unless the field value can be successfully parsed as a
+ comma-separated list (Section 5.6.1 of [HTTP]), all values in the
+ list are valid, and all values in the list are the same (in which
+ case, the message is processed with that single value used as the
+ Content-Length field value). If the unrecoverable error is in a
+ request message, the server MUST respond with a 400 (Bad Request)
+ status code and then close the connection. If it is in a
+ response message received by a proxy, the proxy MUST close the
+ connection to the server, discard the received response, and send
+ a 502 (Bad Gateway) response to the client. If it is in a
+ response message received by a user agent, the user agent MUST
+ close the connection to the server and discard the received
+ response.
+
+ 6. If a valid Content-Length header field is present without
+ Transfer-Encoding, its decimal value defines the expected message
+ body length in octets. If the sender closes the connection or
+ the recipient times out before the indicated number of octets are
+ received, the recipient MUST consider the message to be
+ incomplete and close the connection.
+
+ 7. If this is a request message and none of the above are true, then
+ the message body length is zero (no message body is present).
+
+ 8. Otherwise, this is a response message without a declared message
+ body length, so the message body length is determined by the
+ number of octets received prior to the server closing the
+ connection.
+
+ Since there is no way to distinguish a successfully completed, close-
+ delimited response message from a partially received message
+ interrupted by network failure, a server SHOULD generate encoding or
+ length-delimited messages whenever possible. The close-delimiting
+ feature exists primarily for backwards compatibility with HTTP/1.0.
+
+ | *Note:* Request messages are never close-delimited because they
+ | are always explicitly framed by length or transfer coding, with
+ | the absence of both implying the request ends immediately after
+ | the header section.
+
+ A server MAY reject a request that contains a message body but not a
+ Content-Length by responding with 411 (Length Required).
+
+ Unless a transfer coding other than chunked has been applied, a
+ client that sends a request containing a message body SHOULD use a
+ valid Content-Length header field if the message body length is known
+ in advance, rather than the chunked transfer coding, since some
+ existing services respond to chunked with a 411 (Length Required)
+ status code even though they understand the chunked transfer coding.
+ This is typically because such services are implemented via a gateway
+ that requires a content length in advance of being called, and the
+ server is unable or unwilling to buffer the entire request before
+ processing.
+
+ A user agent that sends a request that contains a message body MUST
+ send either a valid Content-Length header field or use the chunked
+ transfer coding. A client MUST NOT use the chunked transfer coding
+ unless it knows the server will handle HTTP/1.1 (or later) requests;
+ such knowledge can be in the form of specific user configuration or
+ by remembering the version of a prior received response.
+
+ If the final response to the last request on a connection has been
+ completely received and there remains additional data to read, a user
+ agent MAY discard the remaining data or attempt to determine if that
+ data belongs as part of the prior message body, which might be the
+ case if the prior message's Content-Length value is incorrect. A
+ client MUST NOT process, cache, or forward such extra data as a
+ separate response, since such behavior would be vulnerable to cache
+ poisoning.
+
+7. Transfer Codings
+
+ Transfer coding names are used to indicate an encoding transformation
+ that has been, can be, or might need to be applied to a message's
+ content 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 rather than a property of the representation
+ that is being transferred.
+
+ All transfer-coding names are case-insensitive and ought to be
+ registered within the HTTP Transfer Coding registry, as defined in
+ Section 7.3. They are used in the Transfer-Encoding (Section 6.1)
+ and TE (Section 10.1.4 of [HTTP]) header fields (the latter also
+ defining the "transfer-coding" grammar).
+
+7.1. Chunked Transfer Coding
+
+ The chunked transfer coding wraps content in order to transfer it as
+ a series of chunks, each with its own size indicator, followed by an
+ OPTIONAL trailer section containing trailer fields. Chunked enables
+ content streams of unknown size to be transferred as a sequence of
+ length-delimited buffers, which enables the sender to retain
+ connection persistence and the recipient to know when it has received
+ the entire message.
+
+ chunked-body = *chunk
+ last-chunk
+ trailer-section
+ CRLF
+
+ chunk = chunk-size [ chunk-ext ] CRLF
+ chunk-data CRLF
+ chunk-size = 1*HEXDIG
+ last-chunk = 1*("0") [ chunk-ext ] CRLF
+
+ chunk-data = 1*OCTET ; a sequence of chunk-size octets
+
+ The chunk-size field is a string of hex digits indicating the size of
+ the chunk-data in octets. The chunked transfer coding is complete
+ when a chunk with a chunk-size of zero is received, possibly followed
+ by a trailer section, and finally terminated by an empty line.
+
+ A recipient MUST be able to parse and decode the chunked transfer
+ coding.
+
+ HTTP/1.1 does not define any means to limit the size of a chunked
+ response such that an intermediary can be assured of buffering the
+ entire response. Additionally, very large chunk sizes may cause
+ overflows or loss of precision if their values are not represented
+ accurately in a receiving implementation. Therefore, recipients MUST
+ anticipate potentially large hexadecimal numerals and prevent parsing
+ errors due to integer conversion overflows or precision loss due to
+ integer representation.
+
+ The chunked coding does not define any parameters. Their presence
+ SHOULD be treated as an error.
+
+7.1.1. Chunk Extensions
+
+ The chunked coding allows each chunk to include zero or more chunk
+ extensions, immediately following the chunk-size, for the sake of
+ supplying per-chunk metadata (such as a signature or hash), mid-
+ message control information, or randomization of message body size.
+
+ chunk-ext = *( BWS ";" BWS chunk-ext-name
+ [ BWS "=" BWS chunk-ext-val ] )
+
+ chunk-ext-name = token
+ chunk-ext-val = token / quoted-string
+
+ The chunked coding is specific to each connection and is likely to be
+ removed or recoded by each recipient (including intermediaries)
+ before any higher-level application would have a chance to inspect
+ the extensions. Hence, the use of chunk extensions is generally
+ limited to specialized HTTP services such as "long polling" (where
+ client and server can have shared expectations regarding the use of
+ chunk extensions) or for padding within an end-to-end secured
+ connection.
+
+ A recipient MUST ignore unrecognized chunk extensions. A server
+ ought to limit the total length of chunk extensions received in a
+ request to an amount reasonable for the services provided, in the
+ same way that it applies length limitations and timeouts for other
+ parts of a message, and generate an appropriate 4xx (Client Error)
+ response if that amount is exceeded.
+
+7.1.2. Chunked Trailer Section
+
+ A trailer section allows the sender to include additional fields at
+ the end of a chunked message in order to supply metadata that might
+ be dynamically generated while the content is sent, such as a message
+ integrity check, digital signature, or post-processing status. The
+ proper use and limitations of trailer fields are defined in
+ Section 6.5 of [HTTP].
+
+ trailer-section = *( field-line CRLF )
+
+ A recipient that removes the chunked coding from a message MAY
+ selectively retain or discard the received trailer fields. A
+ recipient that retains a received trailer field MUST either store/
+ forward the trailer field separately from the received header fields
+ or merge the received trailer field into the header section. A
+ recipient MUST NOT merge a received trailer field into the header
+ section unless its corresponding header field definition explicitly
+ permits and instructs how the trailer field value can be safely
+ merged.
+
+7.1.3. Decoding Chunked
+
+ A process for decoding the chunked transfer coding can be represented
+ in pseudo-code as:
+
+ length := 0
+ read chunk-size, chunk-ext (if any), and CRLF
+ while (chunk-size > 0) {
+ read chunk-data and CRLF
+ append chunk-data to content
+ length := length + chunk-size
+ read chunk-size, chunk-ext (if any), and CRLF
+ }
+ read trailer field
+ while (trailer field is not empty) {
+ if (trailer fields are stored/forwarded separately) {
+ append trailer field to existing trailer fields
+ }
+ else if (trailer field is understood and defined as mergeable) {
+ merge trailer field with existing header fields
+ }
+ else {
+ discard trailer field
+ }
+ read trailer field
+ }
+ Content-Length := length
+ Remove "chunked" from Transfer-Encoding
+
+7.2. Transfer Codings for Compression
+
+ The following transfer coding names for compression are defined by
+ the same algorithm as their corresponding content coding:
+
+ compress (and x-compress)
+ See Section 8.4.1.1 of [HTTP].
+
+ deflate
+ See Section 8.4.1.2 of [HTTP].
+
+ gzip (and x-gzip)
+ See Section 8.4.1.3 of [HTTP].
+
+ The compression codings do not define any parameters. The presence
+ of parameters with any of these compression codings SHOULD be treated
+ as an error.
+
+7.3. Transfer Coding Registry
+
+ The "HTTP Transfer Coding Registry" defines the namespace for
+ transfer coding names. It is maintained at
+ <https://www.iana.org/assignments/http-parameters>.
+
+ Registrations MUST include the following fields:
+
+ * Name
+
+ * Description
+
+ * Pointer to specification text
+
+ Names of transfer codings MUST NOT overlap with names of content
+ codings (Section 8.4.1 of [HTTP]) unless the encoding transformation
+ is identical, as is the case for the compression codings defined in
+ Section 7.2.
+
+ The TE header field (Section 10.1.4 of [HTTP]) uses a pseudo-
+ parameter named "q" as the rank value when multiple transfer codings
+ are acceptable. Future registrations of transfer codings SHOULD NOT
+ define parameters called "q" (case-insensitively) in order to avoid
+ ambiguities.
+
+ Values to be added to this namespace require IETF Review (see
+ Section 4.8 of [RFC8126]) and MUST conform to the purpose of transfer
+ coding defined in this specification.
+
+ Use of program names for the identification of encoding formats is
+ not desirable and is discouraged for future encodings.
+
+7.4. Negotiating Transfer Codings
+
+ The TE field (Section 10.1.4 of [HTTP]) is used in HTTP/1.1 to
+ indicate what transfer codings, besides chunked, the client is
+ willing to accept in the response and whether the client is willing
+ to preserve trailer fields in a chunked transfer coding.
+
+ A client MUST NOT send the chunked transfer coding name in TE;
+ chunked is always acceptable for HTTP/1.1 recipients.
+
+ Three examples of TE use are below.
+
+ TE: deflate
+ TE:
+ TE: trailers, deflate;q=0.5
+
+ When multiple transfer codings are acceptable, the client MAY rank
+ the codings by preference using a case-insensitive "q" parameter
+ (similar to the qvalues used in content negotiation fields; see
+ Section 12.4.2 of [HTTP]). The rank value is a real number in the
+ range 0 through 1, where 0.001 is the least preferred and 1 is the
+ most preferred; a value of 0 means "not acceptable".
+
+ If the TE field value is empty or if no TE field is present, the only
+ acceptable transfer coding is chunked. A message with no transfer
+ coding is always acceptable.
+
+ The keyword "trailers" indicates that the sender will not discard
+ trailer fields, as described in Section 6.5 of [HTTP].
+
+ Since the TE header field only applies to the immediate connection, a
+ sender of TE MUST also send a "TE" connection option within the
+ Connection header field (Section 7.6.1 of [HTTP]) in order to prevent
+ the TE header field from being forwarded by intermediaries that do
+ not support its semantics.
+
+8. Handling Incomplete Messages
+
+ A server that receives an incomplete request message, usually due to
+ a canceled request or a triggered timeout exception, MAY send an
+ error response prior to closing the connection.
+
+ A client that receives an incomplete response message, which can
+ occur when a connection is closed prematurely or when decoding a
+ supposedly chunked transfer coding fails, MUST record the message as
+ incomplete. Cache requirements for incomplete responses are defined
+ in Section 3.3 of [CACHING].
+
+ If a response terminates in the middle of the header section (before
+ the empty line is received) and the status code might rely on header
+ fields to convey the full meaning of the response, then the client
+ cannot assume that meaning has been conveyed; the client might need
+ to repeat the request in order to determine what action to take next.
+
+ A message body that uses the chunked transfer coding is incomplete if
+ the zero-sized chunk that terminates the encoding has not been
+ received. A message that uses a valid Content-Length is incomplete
+ if the size of the message body received (in octets) is less than the
+ value given by Content-Length. A response that has neither chunked
+ transfer coding nor Content-Length is terminated by closure of the
+ connection and, if the header section was received intact, is
+ considered complete unless an error was indicated by the underlying
+ connection (e.g., an "incomplete close" in TLS would leave the
+ response incomplete, as described in Section 9.8).
+
+9. Connection Management
+
+ HTTP messaging is independent of the underlying transport- or
+ session-layer connection protocol(s). HTTP only presumes a reliable
+ transport with in-order delivery of requests and the corresponding
+ in-order delivery of responses. The mapping of HTTP request and
+ response structures onto the data units of an underlying transport
+ protocol is outside the scope of this specification.
+
+ As described in Section 7.3 of [HTTP], the specific connection
+ protocols to be used for an HTTP interaction are determined by client
+ configuration and the target URI. For example, the "http" URI scheme
+ (Section 4.2.1 of [HTTP]) indicates a default connection of TCP over
+ IP, with a default TCP port of 80, but the client might be configured
+ to use a proxy via some other connection, port, or protocol.
+
+ HTTP implementations are expected to engage in connection management,
+ which includes maintaining the state of current connections,
+ establishing a new connection or reusing an existing connection,
+ processing messages received on a connection, detecting connection
+ failures, and closing each connection. Most clients maintain
+ multiple connections in parallel, including more than one connection
+ per server endpoint. Most servers are designed to maintain thousands
+ of concurrent connections, while controlling request queues to enable
+ fair use and detect denial-of-service attacks.
+
+9.1. Establishment
+
+ It is beyond the scope of this specification to describe how
+ connections are established via various transport- or session-layer
+ protocols. Each HTTP connection maps to one underlying transport
+ connection.
+
+9.2. Associating a Response to a Request
+
+ HTTP/1.1 does not include a request identifier for associating a
+ given request message with its corresponding one or more response
+ messages. Hence, it relies on the order of response arrival to
+ correspond exactly to the order in which requests are made on the
+ same connection. More than one response message per request only
+ occurs when one or more informational responses (1xx; see
+ Section 15.2 of [HTTP]) precede a final response to the same request.
+
+ A client that has more than one outstanding request on a connection
+ MUST maintain a list of outstanding requests in the order sent and
+ MUST associate each received response message on that connection to
+ the first outstanding request that has not yet received a final (non-
+ 1xx) response.
+
+ If a client receives data on a connection that doesn't have
+ outstanding requests, the client MUST NOT consider that data to be a
+ valid response; the client SHOULD close the connection, since message
+ delimitation is now ambiguous, unless the data consists only of one
+ or more CRLF (which can be discarded per Section 2.2).
+
+9.3. Persistence
+
+ HTTP/1.1 defaults to the use of "persistent connections", allowing
+ multiple requests and responses to be carried over a single
+ connection. HTTP implementations SHOULD support persistent
+ connections.
+
+ A recipient determines whether a connection is persistent or not
+ based on the protocol version and Connection header field
+ (Section 7.6.1 of [HTTP]) in the most recently received message, if
+ any:
+
+ * If the "close" connection option is present (Section 9.6), the
+ connection will not persist after the current response; else,
+
+ * If the received protocol is HTTP/1.1 (or later), the connection
+ will persist after the current response; else,
+
+ * If the received protocol is HTTP/1.0, the "keep-alive" connection
+ option is present, either the recipient is not a proxy or the
+ message is a response, and the recipient wishes to honor the
+ HTTP/1.0 "keep-alive" mechanism, the connection will persist after
+ the current response; otherwise,
+
+ * The connection will close after the current response.
+
+ A client that does not support persistent connections MUST send the
+ "close" connection option in every request message.
+
+ A server that does not support persistent connections MUST send the
+ "close" connection option in every response message that does not
+ have a 1xx (Informational) status code.
+
+ A client MAY send additional requests on a persistent connection
+ until it sends or receives a "close" connection option or receives an
+ HTTP/1.0 response without a "keep-alive" connection option.
+
+ In order to remain persistent, all messages on a connection need to
+ have a self-defined message length (i.e., one not defined by closure
+ of the connection), as described in Section 6. A server MUST read
+ the entire request message body or close the connection after sending
+ its response; otherwise, the remaining data on a persistent
+ connection would be misinterpreted as the next request. Likewise, a
+ client MUST read the entire response message body if it intends to
+ reuse the same connection for a subsequent request.
+
+ A proxy server MUST NOT maintain a persistent connection with an
+ HTTP/1.0 client (see Appendix C.2.2 for information and discussion of
+ the problems with the Keep-Alive header field implemented by many
+ HTTP/1.0 clients).
+
+ See Appendix C.2.2 for more information on backwards compatibility
+ with HTTP/1.0 clients.
+
+9.3.1. Retrying Requests
+
+ Connections can be closed at any time, with or without intention.
+ Implementations ought to anticipate the need to recover from
+ asynchronous close events. The conditions under which a client can
+ automatically retry a sequence of outstanding requests are defined in
+ Section 9.2.2 of [HTTP].
+
+9.3.2. Pipelining
+
+ A client that supports persistent connections MAY "pipeline" its
+ requests (i.e., send multiple requests without waiting for each
+ response). A server MAY process a sequence of pipelined requests in
+ parallel if they all have safe methods (Section 9.2.1 of [HTTP]), but
+ it MUST send the corresponding responses in the same order that the
+ requests were received.
+
+ A client that pipelines requests SHOULD retry unanswered requests if
+ the connection closes before it receives all of the corresponding
+ responses. When retrying pipelined requests after a failed
+ connection (a connection not explicitly closed by the server in its
+ last complete response), a client MUST NOT pipeline immediately after
+ connection establishment, since the first remaining request in the
+ prior pipeline might have caused an error response that can be lost
+ again if multiple requests are sent on a prematurely closed
+ connection (see the TCP reset problem described in Section 9.6).
+
+ Idempotent methods (Section 9.2.2 of [HTTP]) are significant to
+ pipelining because they can be automatically retried after a
+ connection failure. A user agent SHOULD NOT pipeline requests after
+ a non-idempotent method, until the final response status code for
+ that method has been received, unless the user agent has a means to
+ detect and recover from partial failure conditions involving the
+ pipelined sequence.
+
+ An intermediary that receives pipelined requests MAY pipeline those
+ requests when forwarding them inbound, since it can rely on the
+ outbound user agent(s) to determine what requests can be safely
+ pipelined. If the inbound connection fails before receiving a
+ response, the pipelining intermediary MAY attempt to retry a sequence
+ of requests that have yet to receive a response if the requests all
+ have idempotent methods; otherwise, the pipelining intermediary
+ SHOULD forward any received responses and then close the
+ corresponding outbound connection(s) so that the outbound user
+ agent(s) can recover accordingly.
+
+9.4. Concurrency
+
+ A client ought to limit the number of simultaneous open connections
+ that it maintains to a given server.
+
+ Previous revisions of HTTP gave a specific number of connections as a
+ ceiling, but this was found to be impractical for many applications.
+ As a result, this specification does not mandate a particular maximum
+ number of connections but, instead, encourages clients to be
+ conservative when opening multiple connections.
+
+ Multiple connections are typically used to avoid the "head-of-line
+ blocking" problem, wherein a request that takes significant server-
+ side processing and/or transfers very large content would block
+ subsequent requests on the same connection. However, each connection
+ consumes server resources.
+
+ Furthermore, using multiple connections can cause undesirable side
+ effects in congested networks. Using larger numbers of connections
+ can also cause side effects in otherwise uncongested networks,
+ because their aggregate and initially synchronized sending behavior
+ can cause congestion that would not have been present if fewer
+ parallel connections had been used.
+
+ Note that a server might reject traffic that it deems abusive or
+ characteristic of a denial-of-service attack, such as an excessive
+ number of open connections from a single client.
+
+9.5. Failures and Timeouts
+
+ Servers will usually have some timeout value beyond which they will
+ no longer maintain an inactive connection. Proxy servers might make
+ this a higher value since it is likely that the client will be making
+ more connections through the same proxy server. The use of
+ persistent connections places no requirements on the length (or
+ existence) of this timeout for either the client or the server.
+
+ A client or server that wishes to time out SHOULD issue a graceful
+ close on the connection. Implementations SHOULD constantly monitor
+ open connections for a received closure signal and respond to it as
+ appropriate, since prompt closure of both sides of a connection
+ enables allocated system resources to be reclaimed.
+
+ A client, server, or proxy MAY close the transport connection at any
+ time. For example, a client might have started to send a new request
+ at the same time that the server has decided to close the "idle"
+ connection. From the server's point of view, the connection is being
+ closed while it was idle, but from the client's point of view, a
+ request is in progress.
+
+ A server SHOULD sustain persistent connections, when possible, and
+ allow the underlying transport's flow-control mechanisms to resolve
+ temporary overloads rather than terminate connections with the
+ expectation that clients will retry. The latter technique can
+ exacerbate network congestion or server load.
+
+ A client sending a message body SHOULD monitor the network connection
+ for an error response while it is transmitting the request. If the
+ client sees a response that indicates the server does not wish to
+ receive the message body and is closing the connection, the client
+ SHOULD immediately cease transmitting the body and close its side of
+ the connection.
+
+9.6. Tear-down
+
+ The "close" connection option is defined as a signal that the sender
+ will close this connection after completion of the response. A
+ sender SHOULD send a Connection header field (Section 7.6.1 of
+ [HTTP]) containing the "close" connection option when it intends to
+ close a connection. For example,
+
+ Connection: close
+
+ as a request header field indicates that this is the last request
+ that the client will send on this connection, while in a response,
+ the same field indicates that the server is going to close this
+ connection after the response message is complete.
+
+ Note that the field name "Close" is reserved, since using that name
+ as a header field might conflict with the "close" connection option.
+
+ A client that sends a "close" connection option MUST NOT send further
+ requests on that connection (after the one containing the "close")
+ and MUST close the connection after reading the final response
+ message corresponding to this request.
+
+ A server that receives a "close" connection option MUST initiate
+ closure of the connection (see below) after it sends the final
+ response to the request that contained the "close" connection option.
+ The server SHOULD send a "close" connection option in its final
+ response on that connection. The server MUST NOT process any further
+ requests received on that connection.
+
+ A server that sends a "close" connection option MUST initiate closure
+ of the connection (see below) after it sends the response containing
+ the "close" connection option. The server MUST NOT process any
+ further requests received on that connection.
+
+ A client that receives a "close" connection option MUST cease sending
+ requests on that connection and close the connection after reading
+ the response message containing the "close" connection option; if
+ additional pipelined requests had been sent on the connection, the
+ client SHOULD NOT assume that they will be processed by the server.
+
+ If a server performs an immediate close of a TCP connection, there is
+ a significant risk that the client will not be able to read the last
+ HTTP response. If the server receives additional data from the
+ client on a fully closed connection, such as another request sent by
+ the client before receiving the server's response, the server's TCP
+ stack will send a reset packet to the client; unfortunately, the
+ reset packet might erase the client's unacknowledged input buffers
+ before they can be read and interpreted by the client's HTTP parser.
+
+ To avoid the TCP reset problem, servers typically close a connection
+ in stages. First, the server performs a half-close by closing only
+ the write side of the read/write connection. The server then
+ continues to read from the connection until it receives a
+ corresponding close by the client, or until the server is reasonably
+ certain that its own TCP stack has received the client's
+ acknowledgement of the packet(s) containing the server's last
+ response. Finally, the server fully closes the connection.
+
+ It is unknown whether the reset problem is exclusive to TCP or might
+ also be found in other transport connection protocols.
+
+ Note that a TCP connection that is half-closed by the client does not
+ delimit a request message, nor does it imply that the client is no
+ longer interested in a response. In general, transport signals
+ cannot be relied upon to signal edge cases, since HTTP/1.1 is
+ independent of transport.
+
+9.7. TLS Connection Initiation
+
+ Conceptually, HTTP/TLS is simply sending HTTP messages over a
+ connection secured via TLS [TLS13].
+
+ The HTTP client also acts as the TLS client. It initiates a
+ connection to the server on the appropriate port and sends the TLS
+ ClientHello to begin the TLS handshake. When the TLS handshake has
+ finished, the client may then initiate the first HTTP request. All
+ HTTP data MUST be sent as TLS "application data" but is otherwise
+ treated like a normal connection for HTTP (including potential reuse
+ as a persistent connection).
+
+9.8. TLS Connection Closure
+
+ TLS uses an exchange of closure alerts prior to (non-error)
+ connection closure to provide secure connection closure; see
+ Section 6.1 of [TLS13]. When a valid closure alert is received, an
+ implementation can be assured that no further data will be received
+ on that connection.
+
+ When an implementation knows that it has sent or received all the
+ message data that it cares about, typically by detecting HTTP message
+ boundaries, it might generate an "incomplete close" by sending a
+ closure alert and then closing the connection without waiting to
+ receive the corresponding closure alert from its peer.
+
+ An incomplete close does not call into question the security of the
+ data already received, but it could indicate that subsequent data
+ might have been truncated. As TLS is not directly aware of HTTP
+ message framing, it is necessary to examine the HTTP data itself to
+ determine whether messages are complete. Handling of incomplete
+ messages is defined in Section 8.
+
+ When encountering an incomplete close, a client SHOULD treat as
+ completed all requests for which it has received either
+
+ 1. as much data as specified in the Content-Length header field or
+
+ 2. the terminal zero-length chunk (when Transfer-Encoding of chunked
+ is used).
+
+ A response that has neither chunked transfer coding nor Content-
+ Length is complete only if a valid closure alert has been received.
+ Treating an incomplete message as complete could expose
+ implementations to attack.
+
+ A client detecting an incomplete close SHOULD recover gracefully.
+
+ Clients MUST send a closure alert before closing the connection.
+ Clients that do not expect to receive any more data MAY choose not to
+ wait for the server's closure alert and simply close the connection,
+ thus generating an incomplete close on the server side.
+
+ Servers SHOULD be prepared to receive an incomplete close from the
+ client, since the client can often locate the end of server data.
+
+ Servers MUST attempt to initiate an exchange of closure alerts with
+ the client before closing the connection. Servers MAY close the
+ connection after sending the closure alert, thus generating an
+ incomplete close on the client side.
+
+10. Enclosing Messages as Data
+
+10.1. Media Type message/http
+
+ The "message/http" media type can be used to enclose a single HTTP
+ request or response message, provided that it obeys the MIME
+ restrictions for all "message" types regarding line length and
+ encodings. Because of the line length limitations, field values
+ within "message/http" are allowed to use line folding (obs-fold), as
+ described in Section 5.2, to convey the field value over multiple
+ lines. A recipient of "message/http" data MUST replace any obsolete
+ line folding with one or more SP characters when the message is
+ consumed.
+
+ Type name: message
+
+ Subtype name: http
+
+ Required parameters: N/A
+
+ Optional parameters: version, msgtype
+
+ version: The HTTP-version number of the enclosed message (e.g.,
+ "1.1"). If not present, the version can be determined from the
+ first line of the body.
+
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first line of the
+ body.
+
+ Encoding considerations: only "7bit", "8bit", or "binary" are
+ permitted
+
+ Security considerations: see Section 11
+
+ Interoperability considerations: N/A
+
+ Published specification: RFC 9112 (see Section 10.1).
+
+ Applications that use this media type: N/A
+
+ Fragment identifier considerations: N/A
+
+ Additional information: Magic number(s): N/A
+
+ Deprecated alias names for this type: N/A
+
+ File extension(s): N/A
+
+ Macintosh file type code(s): N/A
+
+ Person and email address to contact for further information: See Aut
+ hors' Addresses section.
+
+ Intended usage: COMMON
+
+ Restrictions on usage: N/A
+
+ Author: See Authors' Addresses section.
+
+ Change controller: IESG
+
+10.2. Media Type application/http
+
+ The "application/http" media type can be used to enclose a pipeline
+ of one or more HTTP request or response messages (not intermixed).
+
+ Type name: application
+
+ Subtype name: http
+
+ Required parameters: N/A
+
+ Optional parameters: version, msgtype
+
+ version: The HTTP-version number of the enclosed messages (e.g.,
+ "1.1"). If not present, the version can be determined from the
+ first line of the body.
+
+ msgtype: The message type -- "request" or "response". If not
+ present, the type can be determined from the first line of the
+ body.
+
+ Encoding considerations: HTTP messages enclosed by this type are in
+ "binary" format; use of an appropriate Content-Transfer-Encoding
+ is required when transmitted via email.
+
+ Security considerations: see Section 11
+
+ Interoperability considerations: N/A
+
+ Published specification: RFC 9112 (see Section 10.2).
+
+ Applications that use this media type: N/A
+
+ Fragment identifier considerations: N/A
+
+ Additional information: Deprecated alias names for this type: N/A
+
+ Magic number(s): N/A
+
+ File extension(s): N/A
+
+ Macintosh file type code(s): N/A
+
+ Person and email address to contact for further information: See Aut
+ hors' Addresses section.
+
+ Intended usage: COMMON
+
+ Restrictions on usage: N/A
+
+ Author: See Authors' Addresses section.
+
+ Change controller: IESG
+
+11. Security Considerations
+
+ This section is meant to inform developers, information providers,
+ and users about known security considerations relevant to HTTP
+ message syntax and parsing. Security considerations about HTTP
+ semantics, content, and routing are addressed in [HTTP].
+
+11.1. Response Splitting
+
+ Response splitting (a.k.a. CRLF injection) is a common technique,
+ used in various attacks on Web usage, that exploits the line-based
+ nature of HTTP message framing and the ordered association of
+ requests to responses on persistent connections [Klein]. This
+ technique can be particularly damaging when the requests pass through
+ a shared cache.
+
+ Response splitting exploits a vulnerability in servers (usually
+ within an application server) where an attacker can send encoded data
+ within some parameter of the request that is later decoded and echoed
+ within any of the response header fields of the response. If the
+ decoded data is crafted to look like the response has ended and a
+ subsequent response has begun, the response has been split, and the
+ content within the apparent second response is controlled by the
+ attacker. The attacker can then make any other request on the same
+ persistent connection and trick the recipients (including
+ intermediaries) into believing that the second half of the split is
+ an authoritative answer to the second request.
+
+ For example, a parameter within the request-target might be read by
+ an application server and reused within a redirect, resulting in the
+ same parameter being echoed in the Location header field of the
+ response. If the parameter is decoded by the application and not
+ properly encoded when placed in the response field, the attacker can
+ send encoded CRLF octets and other content that will make the
+ application's single response look like two or more responses.
+
+ A common defense against response splitting is to filter requests for
+ data that looks like encoded CR and LF (e.g., "%0D" and "%0A").
+ However, that assumes the application server is only performing URI
+ decoding rather than more obscure data transformations like charset
+ transcoding, XML entity translation, base64 decoding, sprintf
+ reformatting, etc. A more effective mitigation is to prevent
+ anything other than the server's core protocol libraries from sending
+ a CR or LF within the header section, which means restricting the
+ output of header fields to APIs that filter for bad octets and not
+ allowing application servers to write directly to the protocol
+ stream.
+
+11.2. Request Smuggling
+
+ Request smuggling ([Linhart]) is a technique that exploits
+ differences in protocol parsing among various recipients to hide
+ additional requests (which might otherwise be blocked or disabled by
+ policy) within an apparently harmless request. Like response
+ splitting, request smuggling can lead to a variety of attacks on HTTP
+ usage.
+
+ This specification has introduced new requirements on request
+ parsing, particularly with regard to message framing in Section 6.3,
+ to reduce the effectiveness of request smuggling.
+
+11.3. Message Integrity
+
+ HTTP does not define a specific mechanism for ensuring message
+ integrity, instead relying on the error-detection ability of
+ underlying transport protocols and the use of length or chunk-
+ delimited framing to detect completeness. Historically, the lack of
+ a single integrity mechanism has been justified by the informal
+ nature of most HTTP communication. However, the prevalence of HTTP
+ as an information access mechanism has resulted in its increasing use
+ within environments where verification of message integrity is
+ crucial.
+
+ The mechanisms provided with the "https" scheme, such as
+ authenticated encryption, provide protection against modification of
+ messages. Care is needed, however, to ensure that connection closure
+ cannot be used to truncate messages (see Section 9.8). User agents
+ might refuse to accept incomplete messages or treat them specially.
+ For example, a browser being used to view medical history or drug
+ interaction information needs to indicate to the user when such
+ information is detected by the protocol to be incomplete, expired, or
+ corrupted during transfer. Such mechanisms might be selectively
+ enabled via user agent extensions or the presence of message
+ integrity metadata in a response.
+
+ The "http" scheme provides no protection against accidental or
+ malicious modification of messages.
+
+ Extensions to the protocol might be used to mitigate the risk of
+ unwanted modification of messages by intermediaries, even when the
+ "https" scheme is used. Integrity might be assured by using message
+ authentication codes or digital signatures that are selectively added
+ to messages via extensible metadata fields.
+
+11.4. Message Confidentiality
+
+ HTTP relies on underlying transport protocols to provide message
+ confidentiality when that is desired. HTTP has been specifically
+ designed to be independent of the transport protocol, such that it
+ can be used over many forms of encrypted connection, with the
+ selection of such transports being identified by the choice of URI
+ scheme or within user agent configuration.
+
+ The "https" scheme can be used to identify resources that require a
+ confidential connection, as described in Section 4.2.2 of [HTTP].
+
+12. IANA Considerations
+
+ The change controller for the following registrations is: "IETF
+ (iesg@ietf.org) - Internet Engineering Task Force".
+
+12.1. Field Name Registration
+
+ IANA has added the following field names to the "Hypertext Transfer
+ Protocol (HTTP) Field Name Registry" at
+ <https://www.iana.org/assignments/http-fields>, as described in
+ Section 18.4 of [HTTP].
+
+ +===================+===========+=========+============+
+ | Field Name | Status | Section | Comments |
+ +===================+===========+=========+============+
+ | Close | permanent | 9.6 | (reserved) |
+ +-------------------+-----------+---------+------------+
+ | MIME-Version | permanent | B.1 | |
+ +-------------------+-----------+---------+------------+
+ | Transfer-Encoding | permanent | 6.1 | |
+ +-------------------+-----------+---------+------------+
+
+ Table 1
+
+12.2. Media Type Registration
+
+ IANA has updated the "Media Types" registry at
+ <https://www.iana.org/assignments/media-types> with the registration
+ information in Sections 10.1 and 10.2 for the media types "message/
+ http" and "application/http", respectively.
+
+12.3. Transfer Coding Registration
+
+ IANA has updated the "HTTP Transfer Coding Registry" at
+ <https://www.iana.org/assignments/http-parameters/> with the
+ registration procedure of Section 7.3 and the content coding names
+ summarized in the table below.
+
+ +============+===========================================+=========+
+ | Name | Description | Section |
+ +============+===========================================+=========+
+ | chunked | Transfer in a series of chunks | 7.1 |
+ +------------+-------------------------------------------+---------+
+ | compress | UNIX "compress" data format [Welch] | 7.2 |
+ +------------+-------------------------------------------+---------+
+ | deflate | "deflate" compressed data ([RFC1951]) | 7.2 |
+ | | inside the "zlib" data format ([RFC1950]) | |
+ +------------+-------------------------------------------+---------+
+ | gzip | GZIP file format [RFC1952] | 7.2 |
+ +------------+-------------------------------------------+---------+
+ | trailers | (reserved) | 12.3 |
+ +------------+-------------------------------------------+---------+
+ | x-compress | Deprecated (alias for compress) | 7.2 |
+ +------------+-------------------------------------------+---------+
+ | x-gzip | Deprecated (alias for gzip) | 7.2 |
+ +------------+-------------------------------------------+---------+
+
+ Table 2
+
+ | *Note:* the coding name "trailers" is reserved because its use
+ | would conflict with the keyword "trailers" in the TE header
+ | field (Section 10.1.4 of [HTTP]).
+
+12.4. ALPN Protocol ID Registration
+
+ IANA has updated the "TLS Application-Layer Protocol Negotiation
+ (ALPN) Protocol IDs" registry at <https://www.iana.org/assignments/
+ tls-extensiontype-values/> with the registration below:
+
+ +==========+=============================+===========+
+ | Protocol | Identification Sequence | Reference |
+ +==========+=============================+===========+
+ | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | RFC 9112 |
+ | | 0x31 0x2e 0x31 ("http/1.1") | |
+ +----------+-----------------------------+-----------+
+
+ Table 3
+
+13. References
+
+13.1. Normative References
+
+ [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "HTTP Caching", STD 98, RFC 9111,
+ DOI 10.17487/RFC9111, June 2022,
+ <https://www.rfc-editor.org/info/rfc9111>.
+
+ [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "HTTP Semantics", STD 97, RFC 9110,
+ DOI 10.17487/RFC9110, June 2022,
+ <https://www.rfc-editor.org/info/rfc9110>.
+
+ [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950,
+ DOI 10.17487/RFC1950, May 1996,
+ <https://www.rfc-editor.org/info/rfc1950>.
+
+ [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
+ version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
+ <https://www.rfc-editor.org/info/rfc1951>.
+
+ [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
+ RFC 1952, DOI 10.17487/RFC1952, May 1996,
+ <https://www.rfc-editor.org/info/rfc1952>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <https://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
+ RFC 7405, DOI 10.17487/RFC7405, December 2014,
+ <https://www.rfc-editor.org/info/rfc7405>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, DOI 10.17487/RFC3986, January 2005,
+ <https://www.rfc-editor.org/info/rfc3986>.
+
+ [USASCII] American National Standards Institute, "Coded Character
+ Set -- 7-bit American Standard Code for Information
+ Interchange", ANSI X3.4, 1986.
+
+ [Welch] Welch, T., "A Technique for High-Performance Data
+ Compression", IEEE Computer 17(6),
+ DOI 10.1109/MC.1984.1659158, June 1984,
+ <https://ieeexplore.ieee.org/document/1659158/>.
+
+13.2. Informative References
+
+ [HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+ Transfer Protocol -- HTTP/1.0", RFC 1945,
+ DOI 10.17487/RFC1945, May 1996,
+ <https://www.rfc-editor.org/info/rfc1945>.
+
+ [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
+ Web Cache Poisoning Attacks, and Related Topics", March
+ 2004, <https://packetstormsecurity.com/papers/general/
+ whitepaper_httpresponse.pdf>.
+
+ [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
+ Request Smuggling", June 2005,
+ <https://www.cgisecurity.com/lib/HTTP-Request-
+ Smuggling.pdf>.
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
+ <https://www.rfc-editor.org/info/rfc2045>.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ DOI 10.17487/RFC2046, November 1996,
+ <https://www.rfc-editor.org/info/rfc2046>.
+
+ [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Five: Conformance Criteria and
+ Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
+ <https://www.rfc-editor.org/info/rfc2049>.
+
+ [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
+ RFC 2068, DOI 10.17487/RFC2068, January 1997,
+ <https://www.rfc-editor.org/info/rfc2068>.
+
+ [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
+ Encapsulation of Aggregate Documents, such as HTML
+ (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
+ <https://www.rfc-editor.org/info/rfc2557>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Message Syntax and Routing",
+ RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <https://www.rfc-editor.org/info/rfc7230>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+Appendix A. Collected ABNF
+
+ In the collected ABNF below, list rules are expanded per
+ Section 5.6.1 of [HTTP].
+
+ BWS = <BWS, see [HTTP], Section 5.6.3>
+
+ HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
+ message-body ]
+ HTTP-name = %x48.54.54.50 ; HTTP
+ HTTP-version = HTTP-name "/" DIGIT "." DIGIT
+
+ OWS = <OWS, see [HTTP], Section 5.6.3>
+
+ RWS = <RWS, see [HTTP], Section 5.6.3>
+
+ Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
+ ) ]
+
+ absolute-URI = <absolute-URI, see [URI], Section 4.3>
+ absolute-form = absolute-URI
+ absolute-path = <absolute-path, see [HTTP], Section 4.1>
+ asterisk-form = "*"
+ authority = <authority, see [URI], Section 3.2>
+ authority-form = uri-host ":" port
+
+ chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
+ chunk-data = 1*OCTET
+ chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
+ ] )
+ chunk-ext-name = token
+ chunk-ext-val = token / quoted-string
+ chunk-size = 1*HEXDIG
+ chunked-body = *chunk last-chunk trailer-section CRLF
+
+ field-line = field-name ":" OWS field-value OWS
+ field-name = <field-name, see [HTTP], Section 5.1>
+ field-value = <field-value, see [HTTP], Section 5.5>
+
+ last-chunk = 1*"0" [ chunk-ext ] CRLF
+
+ message-body = *OCTET
+ method = token
+
+ obs-fold = OWS CRLF RWS
+ obs-text = <obs-text, see [HTTP], Section 5.6.4>
+ origin-form = absolute-path [ "?" query ]
+
+ port = <port, see [URI], Section 3.2.3>
+
+ query = <query, see [URI], Section 3.4>
+ quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
+
+ reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
+ request-line = method SP request-target SP HTTP-version
+ request-target = origin-form / absolute-form / authority-form /
+ asterisk-form
+
+ start-line = request-line / status-line
+ status-code = 3DIGIT
+ status-line = HTTP-version SP status-code SP [ reason-phrase ]
+
+ token = <token, see [HTTP], Section 5.6.2>
+ trailer-section = *( field-line CRLF )
+ transfer-coding = <transfer-coding, see [HTTP], Section 10.1.4>
+
+ uri-host = <host, see [URI], Section 3.2.2>
+
+Appendix B. Differences between HTTP and MIME
+
+ HTTP/1.1 uses many of the constructs defined for the Internet Message
+ Format [RFC5322] and Multipurpose Internet Mail Extensions (MIME)
+ [RFC2045] to allow a message body to be transmitted in an open
+ variety of representations and with extensible fields. However, some
+ of these constructs have been reinterpreted to better fit the needs
+ of interactive communication, leading to some differences in how MIME
+ constructs are used within HTTP. These differences were carefully
+ chosen to optimize performance over binary connections, allow greater
+ freedom in the use of new media types, ease date comparisons, and
+ accommodate common implementations.
+
+ This appendix describes specific areas where HTTP differs from MIME.
+ Proxies and gateways to and from strict MIME environments need to be
+ aware of these differences and provide the appropriate conversions
+ where necessary.
+
+B.1. MIME-Version
+
+ HTTP is not a MIME-compliant protocol. However, messages can include
+ a single MIME-Version header field to indicate what version of the
+ MIME protocol was used to construct the message. Use of the MIME-
+ Version header field indicates that the message is in full
+ conformance with the MIME protocol (as defined in [RFC2045]).
+ Senders are responsible for ensuring full conformance (where
+ possible) when exporting HTTP messages to strict MIME environments.
+
+B.2. Conversion to Canonical Form
+
+ MIME requires that an Internet mail body part be converted to
+ canonical form prior to being transferred, as described in Section 4
+ of [RFC2049], and that content with a type of "text" represents line
+ breaks as CRLF, forbidding the use of CR or LF outside of line break
+ sequences [RFC2046]. In contrast, HTTP does not care whether CRLF,
+ bare CR, or bare LF are used to indicate a line break within content.
+
+ A proxy or gateway from HTTP to a strict MIME environment ought to
+ translate all line breaks within text media types to the RFC 2049
+ canonical form of CRLF. Note, however, this might be complicated by
+ the presence of a Content-Encoding and by the fact that HTTP allows
+ the use of some charsets that do not use octets 13 and 10 to
+ represent CR and LF, respectively.
+
+ Conversion will break any cryptographic checksums applied to the
+ original content unless the original content is already in canonical
+ form. Therefore, the canonical form is recommended for any content
+ that uses such checksums in HTTP.
+
+B.3. Conversion of Date Formats
+
+ HTTP/1.1 uses a restricted set of date formats (Section 5.6.7 of
+ [HTTP]) to simplify the process of date comparison. Proxies and
+ gateways from other protocols ought to ensure that any Date header
+ field present in a message conforms to one of the HTTP/1.1 formats
+ and rewrite the date if necessary.
+
+B.4. Conversion of Content-Encoding
+
+ MIME does not include any concept equivalent to HTTP's Content-
+ Encoding header field. Since this acts as a modifier on the media
+ type, proxies and gateways from HTTP to MIME-compliant protocols
+ ought to either change the value of the Content-Type header field or
+ decode the representation before forwarding the message. (Some
+ experimental applications of Content-Type for Internet mail have used
+ a media-type parameter of ";conversions=<content-coding>" to perform
+ a function equivalent to Content-Encoding. However, this parameter
+ is not part of the MIME standards.)
+
+B.5. Conversion of Content-Transfer-Encoding
+
+ HTTP does not use the Content-Transfer-Encoding field of MIME.
+ Proxies and gateways from MIME-compliant protocols to HTTP need to
+ remove any Content-Transfer-Encoding prior to delivering the response
+ message to an HTTP client.
+
+ Proxies and gateways from HTTP to MIME-compliant protocols are
+ responsible for ensuring that the message is in the correct format
+ and encoding for safe transport on that protocol, where "safe
+ transport" is defined by the limitations of the protocol being used.
+ Such a proxy or gateway ought to transform and label the data with an
+ appropriate Content-Transfer-Encoding if doing so will improve the
+ likelihood of safe transport over the destination protocol.
+
+B.6. MHTML and Line Length Limitations
+
+ HTTP implementations that share code with MHTML [RFC2557]
+ implementations need to be aware of MIME line length limitations.
+ Since HTTP does not have this limitation, HTTP does not fold long
+ lines. MHTML messages being transported by HTTP follow all
+ conventions of MHTML, including line length limitations and folding,
+ canonicalization, etc., since HTTP transfers message-bodies without
+ modification and, aside from the "multipart/byteranges" type
+ (Section 14.6 of [HTTP]), does not interpret the content or any MIME
+ header lines that might be contained therein.
+
+Appendix C. Changes from Previous RFCs
+
+C.1. Changes from HTTP/0.9
+
+ Since HTTP/0.9 did not support header fields in a request, there is
+ no mechanism for it to support name-based virtual hosts (selection of
+ resource by inspection of the Host header field). Any server that
+ implements name-based virtual hosts ought to disable support for
+ HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
+ badly constructed HTTP/1.x requests caused by a client failing to
+ properly encode the request-target.
+
+C.2. Changes from HTTP/1.0
+
+C.2.1. Multihomed Web Servers
+
+ The requirements that clients and servers support the Host header
+ field (Section 7.2 of [HTTP]), report an error if it is missing from
+ an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are among
+ the most important changes defined by HTTP/1.1.
+
+ Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+ addresses and servers; there was no established mechanism for
+ distinguishing the intended server of a request other than the IP
+ address to which that request was directed. The Host header field
+ was introduced during the development of HTTP/1.1 and, though it was
+ quickly implemented by most HTTP/1.0 browsers, additional
+ requirements were placed on all HTTP/1.1 requests in order to ensure
+ complete adoption. At the time of this writing, most HTTP-based
+ services are dependent upon the Host header field for targeting
+ requests.
+
+C.2.2. Keep-Alive Connections
+
+ In HTTP/1.0, each connection is established by the client prior to
+ the request and closed by the server after sending the response.
+ However, some implementations implement the explicitly negotiated
+ ("Keep-Alive") version of persistent connections described in
+ Section 19.7.1 of [RFC2068].
+
+ Some clients and servers might wish to be compatible with these
+ previous approaches to persistent connections, by explicitly
+ negotiating for them with a "Connection: keep-alive" request header
+ field. However, some experimental implementations of HTTP/1.0
+ persistent connections are faulty; for example, if an HTTP/1.0 proxy
+ server doesn't understand Connection, it will erroneously forward
+ that header field to the next inbound server, which would result in a
+ hung connection.
+
+ One attempted solution was the introduction of a Proxy-Connection
+ header field, targeted specifically at proxies. In practice, this
+ was also unworkable, because proxies are often deployed in multiple
+ layers, bringing about the same problem discussed above.
+
+ As a result, clients are encouraged not to send the Proxy-Connection
+ header field in any requests.
+
+ Clients are also encouraged to consider the use of "Connection: keep-
+ alive" in requests carefully; while they can enable persistent
+ connections with HTTP/1.0 servers, clients using them will need to
+ monitor the connection for "hung" requests (which indicate that the
+ client ought to stop sending the header field), and this mechanism
+ ought not be used by clients at all when a proxy is being used.
+
+C.2.3. Introduction of Transfer-Encoding
+
+ HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1).
+ Transfer codings need to be decoded prior to forwarding an HTTP
+ message over a MIME-compliant protocol.
+
+C.3. Changes from RFC 7230
+
+ Most of the sections introducing HTTP's design goals, history,
+ architecture, conformance criteria, protocol versioning, URIs,
+ message routing, and header fields have been moved to [HTTP]. This
+ document has been reduced to just the messaging syntax and connection
+ management requirements specific to HTTP/1.1.
+
+ Bare CRs have been prohibited outside of content. (Section 2.2)
+
+ The ABNF definition of authority-form has changed from the more
+ general authority component of a URI (in which port is optional) to
+ the specific host:port format that is required by CONNECT.
+ (Section 3.2.3)
+
+ Recipients are required to avoid smuggling/splitting attacks when
+ processing an ambiguous message framing. (Section 6.1)
+
+ In the ABNF for chunked extensions, (bad) whitespace around ";" and
+ "=" has been reintroduced. Whitespace was removed in [RFC7230], but
+ that change was found to break existing implementations.
+ (Section 7.1.1)
+
+ Trailer field semantics now transcend the specifics of chunked
+ transfer coding. The decoding algorithm for chunked (Section 7.1.3)
+ has been updated to encourage storage/forwarding of trailer fields
+ separately from the header section, to only allow merging into the
+ header section if the recipient knows the corresponding field
+ definition permits and defines how to merge, and otherwise to discard
+ the trailer fields instead of merging. The trailer part is now
+ called the trailer section to be more consistent with the header
+ section and more distinct from a body part. (Section 7.1.2)
+
+ Transfer coding parameters called "q" are disallowed in order to
+ avoid conflicts with the use of ranks in the TE header field.
+ (Section 7.3)
+
+Acknowledgements
+
+ See Appendix "Acknowledgements" of [HTTP], which applies to this
+ document as well.
+
+Index
+
+ A C D F G H M O R T X
+
+ A
+
+ absolute-form (of request-target) Section 3.2.2
+ application/http Media Type *_Section 10.2_*
+ asterisk-form (of request-target) Section 3.2.4
+ authority-form (of request-target) Section 3.2.3
+
+ C
+
+ chunked (Coding Format) Section 6.1; Section 6.3
+ chunked (transfer coding) *_Section 7.1_*
+ close Section 9.3; *_Section 9.6_*
+ compress (transfer coding) *_Section 7.2_*
+ Connection header field Section 9.6
+ Content-Length header field Section 6.2
+ Content-Transfer-Encoding header field Appendix B.5
+
+ D
+
+ deflate (transfer coding) *_Section 7.2_*
+
+ F
+
+ Fields
+ Close *_Section 9.6, Paragraph 4_*
+ MIME-Version *_Appendix B.1_*
+ Transfer-Encoding *_Section 6.1_*
+
+ G
+
+ Grammar
+ ALPHA *_Section 1.2_*
+ CR *_Section 1.2_*
+ CRLF *_Section 1.2_*
+ CTL *_Section 1.2_*
+ DIGIT *_Section 1.2_*
+ DQUOTE *_Section 1.2_*
+ HEXDIG *_Section 1.2_*
+ HTAB *_Section 1.2_*
+ HTTP-message *_Section 2.1_*
+ HTTP-name *_Section 2.3_*
+ HTTP-version *_Section 2.3_*
+ LF *_Section 1.2_*
+ OCTET *_Section 1.2_*
+ SP *_Section 1.2_*
+ Transfer-Encoding *_Section 6.1_*
+ VCHAR *_Section 1.2_*
+ absolute-form Section 3.2; *_Section 3.2.2_*
+ asterisk-form Section 3.2; *_Section 3.2.4_*
+ authority-form Section 3.2; *_Section 3.2.3_*
+ chunk *_Section 7.1_*
+ chunk-data *_Section 7.1_*
+ chunk-ext Section 7.1; *_Section 7.1.1_*
+ chunk-ext-name *_Section 7.1.1_*
+ chunk-ext-val *_Section 7.1.1_*
+ chunk-size *_Section 7.1_*
+ chunked-body *_Section 7.1_*
+ field-line *_Section 5_*; Section 7.1.2
+ field-name Section 5
+ field-value Section 5
+ last-chunk *_Section 7.1_*
+ message-body *_Section 6_*
+ method *_Section 3.1_*
+ obs-fold *_Section 5.2_*
+ origin-form Section 3.2; *_Section 3.2.1_*
+ reason-phrase *_Section 4_*
+ request-line *_Section 3_*
+ request-target *_Section 3.2_*
+ start-line *_Section 2.1_*
+ status-code *_Section 4_*
+ status-line *_Section 4_*
+ trailer-section Section 7.1; *_Section 7.1.2_*
+ gzip (transfer coding) *_Section 7.2_*
+
+ H
+
+ Header Fields
+ MIME-Version *_Appendix B.1_*
+ Transfer-Encoding *_Section 6.1_*
+ header line Section 2.1
+ header section Section 2.1
+ headers Section 2.1
+
+ M
+
+ Media Type
+ application/http *_Section 10.2_*
+ message/http *_Section 10.1_*
+ message/http Media Type *_Section 10.1_*
+ method *_Section 3.1_*
+ MIME-Version header field *_Appendix B.1_*
+
+ O
+
+ origin-form (of request-target) Section 3.2.1
+
+ R
+
+ request-target *_Section 3.2_*
+
+ T
+
+ Transfer-Encoding header field *_Section 6.1_*
+
+ X
+
+ x-compress (transfer coding) *_Section 7.2_*
+ x-gzip (transfer coding) *_Section 7.2_*
+
+Authors' Addresses
+
+ Roy T. Fielding (editor)
+ Adobe
+ 345 Park Ave
+ San Jose, CA 95110
+ United States of America
+ Email: fielding@gbiv.com
+ URI: https://roy.gbiv.com/
+
+
+ Mark Nottingham (editor)
+ Fastly
+ Prahran
+ Australia
+ Email: mnot@mnot.net
+ URI: https://www.mnot.net/
+
+
+ Julian Reschke (editor)
+ greenbytes GmbH
+ Hafenweg 16
+ 48155 Münster
+ Germany
+ Email: julian.reschke@greenbytes.de
+ URI: https://greenbytes.de/tech/webdav/
Soft'N'Design Software / projects / webserver.git / commitdiff
