------------------------------------------------------------ revno: 13457 revision-id: squid3@treenet.co.nz-20140609013806-uob2o1zmrbsa778a parent: squid3@treenet.co.nz-20140607102347-5zs9naleqh2qxj9m committer: Amos Jeffries branch nick: trunk timestamp: Sun 2014-06-08 18:38:06 -0700 message: RFC2616 obsoleted by RFC 7230 et al ------------------------------------------------------------ # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: squid3@treenet.co.nz-20140609013806-uob2o1zmrbsa778a # target_branch: http://bzr.squid-cache.org/bzr/squid3/trunk/ # testament_sha1: ead62e4e73fba2c04a6ff331c2fe246ff3ce06da # timestamp: 2014-06-09 01:53:45 +0000 # source_branch: http://bzr.squid-cache.org/bzr/squid3/trunk/ # base_revision_id: squid3@treenet.co.nz-20140607102347-\ # 5zs9naleqh2qxj9m # # Begin patch === modified file 'doc/rfc/1-index.txt' --- doc/rfc/1-index.txt 2013-06-02 11:47:05 +0000 +++ doc/rfc/1-index.txt 2014-06-09 01:38:06 +0000 @@ -69,9 +69,6 @@ HTTP Extensions for Distributed Authoring -- WEBDAV Numerous extension methods to HTTP -rfc2616.txt - Hypertext Transfer Protocol -- HTTP/1.1 - rfc2617.txt HTTP/1.1 Basic and Digest authentication @@ -166,3 +163,41 @@ Multicast DNS Details the DNS requirements on the Squid internal DNS client for resolving URLs in the .local domain. + +rfc7230.txt + Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing + Details the message 'frame' delimiters, first-line, and URL + syntax, generic parsing rules, connection management, routing, + and transfer encoding. + +rfc7231.txt + Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content + Details the basic HTTP methods, headers and status code values + and behaviour requirements imposed by each. + +rfc7232.txt + Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests + Last-Modified and Etag validator headers, + If-* conditional headers, + 304 and 412 status codes. + +rfc7233.txt + Hypertext Transfer Protocol (HTTP/1.1): Range Requests + Defines range requests and the rules for constructing and + combining responses to those requests. + +rfc7234.txt + Hypertext Transfer Protocol (HTTP/1.1): Caching + Defines HTTP caches and the associated header fields that + control cache behavior or indicate cacheable response messages. + +rfc7235.txt + Hypertext Transfer Protocol (HTTP/1.1): Authentication + +rfc7238.txt + The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) + +rfc7239.txt + Forwarded HTTP Extension + Details the Forwarded: header replacement for X-Forwarded-For + and other X-Forwarded-* variants === removed file 'doc/rfc/rfc2616.txt' --- doc/rfc/rfc2616.txt 2005-01-10 23:45:42 +0000 +++ doc/rfc/rfc2616.txt 1970-01-01 00:00:00 +0000 @@ -1,9859 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 "*element" indicating at least and at most - 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] - -RFC 2616 HTTP/1.1 June 1999 - - - N rule - Specific repetition: "(element)" is equivalent to - "*(element)"; that is, exactly 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 "#element" indicating at least - and at most 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] - -RFC 2616 HTTP/1.1 June 1999 - - - OCTET = - CHAR = - UPALPHA = - LOALPHA = - ALPHA = UPALPHA | LOALPHA - DIGIT = - CTL = - CR = - LF = - SP = - HT = - <"> = - - 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 = - - 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] - -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* - 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 = - - A string of text is parsed as a single word if it is quoted using - double-quote marks. - - quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) - qdtext = > - - 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 "." 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 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 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 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 - | - - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 = * - - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 = - - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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 - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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", , - 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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=" 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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - === added file 'doc/rfc/rfc7230.txt' --- doc/rfc/rfc7230.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7230.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,4987 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7230 Adobe +Obsoletes: 2145, 2616 J. Reschke, Ed. +Updates: 2817, 2818 greenbytes +Category: Standards Track June 2014 +ISSN: 2070-1721 + + + Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document provides an overview of HTTP architecture and + its associated terminology, defines the "http" and "https" Uniform + Resource Identifier (URI) schemes, defines the HTTP/1.1 message + syntax and parsing requirements, and describes related security + concerns for implementations. + +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/rfc7230. + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 1] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + 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 ....................................................5 + 1.1. Requirements Notation ......................................6 + 1.2. Syntax Notation ............................................6 + 2. Architecture ....................................................6 + 2.1. Client/Server Messaging ....................................7 + 2.2. Implementation Diversity ...................................8 + 2.3. Intermediaries .............................................9 + 2.4. Caches ....................................................11 + 2.5. Conformance and Error Handling ............................12 + 2.6. Protocol Versioning .......................................13 + 2.7. Uniform Resource Identifiers ..............................16 + 2.7.1. http URI Scheme ....................................17 + 2.7.2. https URI Scheme ...................................18 + 2.7.3. http and https URI Normalization and Comparison ....19 + 3. Message Format .................................................19 + 3.1. Start Line ................................................20 + 3.1.1. Request Line .......................................21 + 3.1.2. Status Line ........................................22 + 3.2. Header Fields .............................................22 + + + +Fielding & Reschke Standards Track [Page 2] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 3.2.1. Field Extensibility ................................23 + 3.2.2. Field Order ........................................23 + 3.2.3. Whitespace .........................................24 + 3.2.4. Field Parsing ......................................25 + 3.2.5. Field Limits .......................................26 + 3.2.6. Field Value Components .............................27 + 3.3. Message Body ..............................................28 + 3.3.1. Transfer-Encoding ..................................28 + 3.3.2. Content-Length .....................................30 + 3.3.3. Message Body Length ................................32 + 3.4. Handling Incomplete Messages ..............................34 + 3.5. Message Parsing Robustness ................................34 + 4. Transfer Codings ...............................................35 + 4.1. Chunked Transfer Coding ...................................36 + 4.1.1. Chunk Extensions ...................................36 + 4.1.2. Chunked Trailer Part ...............................37 + 4.1.3. Decoding Chunked ...................................38 + 4.2. Compression Codings .......................................38 + 4.2.1. Compress Coding ....................................38 + 4.2.2. Deflate Coding .....................................38 + 4.2.3. Gzip Coding ........................................39 + 4.3. TE ........................................................39 + 4.4. Trailer ...................................................40 + 5. Message Routing ................................................40 + 5.1. Identifying a Target Resource .............................40 + 5.2. Connecting Inbound ........................................41 + 5.3. Request Target ............................................41 + 5.3.1. origin-form ........................................42 + 5.3.2. absolute-form ......................................42 + 5.3.3. authority-form .....................................43 + 5.3.4. asterisk-form ......................................43 + 5.4. Host ......................................................44 + 5.5. Effective Request URI .....................................45 + 5.6. Associating a Response to a Request .......................46 + 5.7. Message Forwarding ........................................47 + 5.7.1. Via ................................................47 + 5.7.2. Transformations ....................................49 + 6. Connection Management ..........................................50 + 6.1. Connection ................................................51 + 6.2. Establishment .............................................52 + 6.3. Persistence ...............................................52 + 6.3.1. Retrying Requests ..................................53 + 6.3.2. Pipelining .........................................54 + 6.4. Concurrency ...............................................55 + 6.5. Failures and Timeouts .....................................55 + 6.6. Tear-down .................................................56 + 6.7. Upgrade ...................................................57 + 7. ABNF List Extension: #rule .....................................59 + + + +Fielding & Reschke Standards Track [Page 3] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 8. IANA Considerations ............................................61 + 8.1. Header Field Registration .................................61 + 8.2. URI Scheme Registration ...................................62 + 8.3. Internet Media Type Registration ..........................62 + 8.3.1. Internet Media Type message/http ...................62 + 8.3.2. Internet Media Type application/http ...............63 + 8.4. Transfer Coding Registry ..................................64 + 8.4.1. Procedure ..........................................65 + 8.4.2. Registration .......................................65 + 8.5. Content Coding Registration ...............................66 + 8.6. Upgrade Token Registry ....................................66 + 8.6.1. Procedure ..........................................66 + 8.6.2. Upgrade Token Registration .........................67 + 9. Security Considerations ........................................67 + 9.1. Establishing Authority ....................................67 + 9.2. Risks of Intermediaries ...................................68 + 9.3. Attacks via Protocol Element Length .......................69 + 9.4. Response Splitting ........................................69 + 9.5. Request Smuggling .........................................70 + 9.6. Message Integrity .........................................70 + 9.7. Message Confidentiality ...................................71 + 9.8. Privacy of Server Log Information .........................71 + 10. Acknowledgments ...............................................72 + 11. References ....................................................74 + 11.1. Normative References .....................................74 + 11.2. Informative References ...................................75 + Appendix A. HTTP Version History ..................................78 + A.1. Changes from HTTP/1.0 ....................................78 + A.1.1. Multihomed Web Servers ............................78 + A.1.2. Keep-Alive Connections ............................79 + A.1.3. Introduction of Transfer-Encoding .................79 + A.2. Changes from RFC 2616 ....................................80 + Appendix B. Collected ABNF ........................................82 + Index .............................................................85 + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 4] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +1. Introduction + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level request/response protocol that uses extensible semantics and + self-descriptive message payloads for flexible interaction with + network-based hypertext information systems. This document is the + first in a series of documents that collectively form the HTTP/1.1 + specification: + + 1. "Message Syntax and Routing" (this document) + + 2. "Semantics and Content" [RFC7231] + + 3. "Conditional Requests" [RFC7232] + + 4. "Range Requests" [RFC7233] + + 5. "Caching" [RFC7234] + + 6. "Authentication" [RFC7235] + + This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP + versioning). This specification also updates the use of CONNECT to + establish a tunnel, previously defined in RFC 2817, and defines the + "https" URI scheme that was described informally in RFC 2818. + + HTTP is a generic interface protocol for information systems. It is + designed to hide the details of how a service is implemented by + presenting a uniform interface to clients that is independent of the + types of resources provided. Likewise, servers do not need to be + aware of each client's purpose: an HTTP request can be considered in + isolation rather than being associated with a specific type of client + or a predetermined sequence of application steps. The result is a + protocol that can be used effectively in many different contexts and + for which implementations can evolve independently over time. + + HTTP is also designed for use as an intermediation protocol for + translating communication to and from non-HTTP information systems. + HTTP proxies and gateways can provide access to alternative + information services by translating their diverse protocols into a + hypertext format that can be viewed and manipulated by clients in the + same way as HTTP services. + + One consequence of this flexibility is that the protocol cannot be + defined in terms of what occurs behind the interface. Instead, we + are limited to defining the syntax of communication, the intent of + received communication, and the expected behavior of recipients. If + the communication is considered in isolation, then successful actions + + + +Fielding & Reschke Standards Track [Page 5] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + ought to be reflected in corresponding changes to the observable + interface provided by servers. However, since multiple clients might + act in parallel and perhaps at cross-purposes, we cannot require that + such changes be observable beyond the scope of a single response. + + This document describes the architectural elements that are used or + referred to in HTTP, defines the "http" and "https" URI schemes, + describes overall network operation and connection management, and + defines HTTP message framing and forwarding requirements. Our goal + is to define all of the mechanisms necessary for HTTP message + handling that are independent of message semantics, thereby defining + the complete set of requirements for message parsers and message- + forwarding intermediaries. + +1.1. Requirements Notation + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7, + that allows for compact definition of comma-separated lists using a + '#' operator (similar to how the '*' operator indicates repetition). + Appendix B shows the collected grammar with all list operators + expanded to standard ABNF notation. + + 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). + + As a convention, ABNF rule names prefixed with "obs-" denote + "obsolete" grammar rules that appear for historical reasons. + +2. Architecture + + HTTP was created for the World Wide Web (WWW) architecture and has + evolved over time to support the scalability needs of a worldwide + hypertext system. Much of that architecture is reflected in the + terminology and syntax productions used to define HTTP. + + + +Fielding & Reschke Standards Track [Page 6] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +2.1. Client/Server Messaging + + HTTP is a stateless request/response protocol that operates by + exchanging messages (Section 3) across a reliable transport- or + session-layer "connection" (Section 6). An HTTP "client" is a + program that establishes a connection to a server for the purpose of + sending one or more HTTP requests. An HTTP "server" is a program + that accepts connections in order to service HTTP requests by sending + HTTP responses. + + The terms "client" and "server" refer only to the roles that these + programs perform for a particular connection. The same program might + act as a client on some connections and a server on others. The term + "user agent" refers to any of the various client programs that + initiate a request, including (but not limited to) browsers, spiders + (web-based robots), command-line tools, custom applications, and + mobile apps. The term "origin server" refers to the program that can + originate authoritative responses for a given target resource. The + terms "sender" and "recipient" refer to any implementation that sends + or receives a given message, respectively. + + HTTP relies upon the Uniform Resource Identifier (URI) standard + [RFC3986] to indicate the target resource (Section 5.1) and + relationships between resources. Messages are passed in a format + similar to that used by Internet mail [RFC5322] and the Multipurpose + Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of + [RFC7231] for the differences between HTTP and MIME messages). + + Most HTTP communication consists of a retrieval request (GET) for a + representation of some resource identified by a URI. In the simplest + case, this might be accomplished via a single bidirectional + connection (===) between the user agent (UA) and the origin + server (O). + + request > + UA ======================================= O + < response + + A client sends an HTTP request to a server in the form of a request + message, beginning with a request-line that includes a method, URI, + and protocol version (Section 3.1.1), followed by header fields + containing request modifiers, client information, and representation + metadata (Section 3.2), an empty line to indicate the end of the + header section, and finally a message body containing the payload + body (if any, Section 3.3). + + + + + + +Fielding & Reschke Standards Track [Page 7] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A server responds to a client's request by sending one or more HTTP + response messages, each beginning with a status line that includes + the protocol version, a success or error code, and textual reason + phrase (Section 3.1.2), possibly followed by header fields containing + server information, resource metadata, and representation metadata + (Section 3.2), an empty line to indicate the end of the header + section, and finally a message body containing the payload body (if + any, Section 3.3). + + A connection might be used for multiple request/response exchanges, + as defined in Section 6.3. + + The following example illustrates a typical message exchange for a + GET request (Section 4.3.1 of [RFC7231]) on the URI + "http://www.example.com/hello.txt": + + Client request: + + GET /hello.txt HTTP/1.1 + User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 + Host: www.example.com + Accept-Language: en, mi + + + Server response: + + HTTP/1.1 200 OK + Date: Mon, 27 Jul 2009 12:28:53 GMT + Server: Apache + Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT + ETag: "34aa387-d-1568eb00" + Accept-Ranges: bytes + Content-Length: 51 + Vary: Accept-Encoding + Content-Type: text/plain + + Hello World! My payload includes a trailing CRLF. + +2.2. Implementation Diversity + + When considering the design of HTTP, it is easy to fall into a trap + of thinking that all user agents are general-purpose browsers and all + origin servers are large public websites. That is not the case in + practice. Common HTTP user agents include household appliances, + stereos, scales, firmware update scripts, command-line programs, + mobile apps, and communication devices in a multitude of shapes and + sizes. Likewise, common HTTP origin servers include home automation + + + + +Fielding & Reschke Standards Track [Page 8] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + units, configurable networking components, office machines, + autonomous robots, news feeds, traffic cameras, ad selectors, and + video-delivery platforms. + + The term "user agent" does not imply that there is a human user + directly interacting with the software agent at the time of a + request. In many cases, a user agent is installed or configured to + run in the background and save its results for later inspection (or + save only a subset of those results that might be interesting or + erroneous). Spiders, for example, are typically given a start URI + and configured to follow certain behavior while crawling the Web as a + hypertext graph. + + The implementation diversity of HTTP means that not all user agents + can make interactive suggestions to their user or provide adequate + warning for security or privacy concerns. In the few cases where + this specification requires reporting of errors to the user, it is + acceptable for such reporting to only be observable in an error + console or log file. Likewise, requirements that an automated action + be confirmed by the user before proceeding might be met via advance + configuration choices, run-time options, or simple avoidance of the + unsafe action; confirmation does not imply any specific user + interface or interruption of normal processing if the user has + already made that choice. + +2.3. Intermediaries + + HTTP enables the use of intermediaries to satisfy requests through a + chain of connections. There are three common forms of HTTP + intermediary: proxy, gateway, and tunnel. In some cases, a single + intermediary might act as an origin server, proxy, gateway, or + tunnel, switching behavior based on the nature of each request. + + > > > > + UA =========== A =========== B =========== C =========== O + < < < < + + 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. + Some HTTP communication options might apply only to the connection + with the nearest, non-tunnel neighbor, only to the endpoints of the + chain, or to all connections along the chain. Although the diagram + is linear, each participant might be engaged in multiple, + simultaneous communications. For example, B might 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 + + + + +Fielding & Reschke Standards Track [Page 9] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + request. Likewise, later requests might be sent through a different + path of connections, often based on dynamic configuration for load + balancing. + + The terms "upstream" and "downstream" are used to describe + directional requirements in relation to the message flow: all + messages flow from upstream to downstream. The terms "inbound" and + "outbound" are used to describe directional requirements in relation + to the request route: "inbound" means toward the origin server and + "outbound" means toward the user agent. + + A "proxy" is a message-forwarding agent that is selected by the + client, usually via local configuration rules, to receive requests + for some type(s) of absolute URI and attempt to satisfy those + requests via translation through the HTTP interface. Some + translations are minimal, such as for proxy requests for "http" URIs, + whereas other requests might require translation to and from entirely + different application-level protocols. Proxies are often used to + group an organization's HTTP requests through a common intermediary + for the sake of security, annotation services, or shared caching. + Some proxies are designed to apply transformations to selected + messages or payloads while they are being forwarded, as described in + Section 5.7.2. + + A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as + an origin server for the outbound connection but translates received + requests and forwards them inbound to another server or servers. + Gateways are often used to encapsulate legacy or untrusted + information services, to improve server performance through + "accelerator" caching, and to enable partitioning or load balancing + of HTTP services across multiple machines. + + All HTTP requirements applicable to an origin server also apply to + the outbound communication of a gateway. A gateway communicates with + inbound servers using any protocol that it desires, including private + extensions to HTTP that are outside the scope of this specification. + However, an HTTP-to-HTTP gateway that wishes to interoperate with + third-party HTTP servers ought to conform to user agent requirements + on the gateway's inbound connection. + + A "tunnel" acts as a blind relay between two connections without + changing the messages. Once active, a tunnel is not considered a + party to the HTTP communication, though the tunnel might have been + initiated by an HTTP request. A tunnel ceases to exist when both + ends of the relayed connection are closed. Tunnels are used to + extend a virtual connection through an intermediary, such as when + Transport Layer Security (TLS, [RFC5246]) is used to establish + confidential communication through a shared firewall proxy. + + + +Fielding & Reschke Standards Track [Page 10] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + The above categories for intermediary only consider those acting as + participants in the HTTP communication. There are also + intermediaries that can act on lower layers of the network protocol + stack, filtering or redirecting HTTP traffic without the knowledge or + permission of message senders. Network intermediaries are + indistinguishable (at a protocol level) from a man-in-the-middle + attack, often introducing security flaws or interoperability problems + due to mistakenly violating HTTP semantics. + + For example, an "interception proxy" [RFC3040] (also commonly known + as a "transparent proxy" [RFC1919] or "captive portal") differs from + an HTTP proxy because it is not selected by the client. Instead, an + interception proxy filters or redirects outgoing TCP port 80 packets + (and occasionally other common port traffic). Interception proxies + are commonly found on public network access points, as a means of + enforcing account subscription prior to allowing use of non-local + Internet services, and within corporate firewalls to enforce network + usage policies. + + HTTP is defined as a stateless protocol, meaning that each request + message can be understood in isolation. Many implementations depend + on HTTP's stateless design in order to reuse proxied connections or + dynamically load balance requests across multiple servers. Hence, a + server MUST NOT assume that two requests on the same connection are + from the same user agent unless the connection is secured and + specific to that agent. Some non-standard HTTP extensions (e.g., + [RFC4559]) have been known to violate this requirement, resulting in + security and interoperability problems. + +2.4. Caches + + A "cache" is a local store of previous 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 employ a cache, though a cache + cannot be used by a server while it is acting as a tunnel. + + 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 that has not been cached by UA or A. + + > > + UA =========== A =========== B - - - - - - C - - - - - - O + < < + + + + +Fielding & Reschke Standards Track [Page 11] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A response is "cacheable" if a cache is allowed to store a copy of + the response message for use in answering subsequent requests. Even + when a response is cacheable, there might be additional constraints + placed by the client or by the origin server on when that cached + response can be used for a particular request. HTTP requirements for + cache behavior and cacheable responses are defined in Section 2 of + [RFC7234]. + + There is a wide variety of architectures and configurations of caches + deployed across the World Wide Web and inside large organizations. + These include national hierarchies of proxy caches to save + transoceanic bandwidth, collaborative systems that broadcast or + multicast cache entries, archives of pre-fetched cache entries for + use in off-line or high-latency environments, and so on. + +2.5. Conformance and Error Handling + + This specification targets conformance criteria according to the role + of a participant in HTTP communication. Hence, HTTP requirements are + placed on senders, recipients, clients, servers, user agents, + intermediaries, origin servers, proxies, gateways, or caches, + depending on what behavior is being constrained by the requirement. + Additional (social) requirements are placed on implementations, + resource owners, and protocol element registrations when they apply + beyond the scope of a single communication. + + The verb "generate" is used instead of "send" where a requirement + differentiates between creating a protocol element and merely + forwarding a received element downstream. + + An implementation is considered conformant if it complies with all of + the requirements associated with the roles it partakes in HTTP. + + Conformance includes both the syntax and semantics of protocol + elements. A sender MUST NOT generate protocol elements that convey a + meaning that is known by that sender to be false. A sender MUST NOT + generate protocol elements that do not match the grammar defined by + the corresponding ABNF rules. Within a given message, a sender MUST + NOT generate protocol elements or syntax alternatives that are only + allowed to be generated by participants in other roles (i.e., a role + that the sender does not have for that message). + + When a received protocol element is parsed, the recipient MUST be + able to parse any value of reasonable length that is applicable to + the recipient's role and that matches the grammar defined by the + corresponding ABNF rules. Note, however, that some received protocol + elements might not be parsed. For example, an intermediary + + + + +Fielding & Reschke Standards Track [Page 12] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + forwarding a message might parse a header-field into generic + field-name and field-value components, but then forward the header + field without further parsing inside the field-value. + + HTTP does not have specific length limitations for many of its + protocol elements because the lengths that might be appropriate will + vary widely, depending on the deployment context and purpose of the + implementation. Hence, interoperability between senders and + recipients depends on shared expectations regarding what is a + reasonable length for each protocol element. Furthermore, what is + commonly understood to be a reasonable length for some protocol + elements has changed over the course of the past two decades of HTTP + use and is expected to continue changing in the future. + + At a minimum, a recipient MUST be able to parse and process protocol + element lengths that are at least as long as the values that it + generates for those same protocol elements in other messages. For + example, an origin server that publishes very long URI references to + its own resources needs to be able to parse and process those same + references when received as a request target. + + A recipient MUST interpret a received protocol element according to + the semantics defined for it by this specification, including + extensions to this specification, unless the recipient has determined + (through experience or configuration) that the sender incorrectly + implements what is implied by those semantics. For example, an + origin server might disregard the contents of a received + Accept-Encoding header field if inspection of the User-Agent header + field indicates a specific implementation version that is known to + fail on receipt of certain content codings. + + Unless noted otherwise, a recipient MAY attempt to recover a usable + protocol element from an invalid construct. HTTP does not define + specific error handling mechanisms except when they have a direct + impact on security, since different applications of the protocol + require different error handling strategies. For example, a Web + browser might wish to transparently recover from a response where the + Location header field doesn't parse according to the ABNF, whereas a + systems control client might consider any form of error recovery to + be dangerous. + +2.6. Protocol Versioning + + HTTP uses a "." numbering scheme to indicate versions + of the protocol. This specification defines version "1.1". The + protocol version as a whole indicates the sender's conformance with + the set of requirements laid out in that version's corresponding + specification of HTTP. + + + +Fielding & Reschke Standards Track [Page 13] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + The version of an HTTP message is indicated by an HTTP-version field + in the first line of the message. HTTP-version is case-sensitive. + + HTTP-version = HTTP-name "/" DIGIT "." DIGIT + HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive + + The HTTP version number consists of two decimal digits separated by a + "." (period or decimal point). The first digit ("major version") + indicates the HTTP messaging syntax, whereas the second digit ("minor + version") indicates the highest minor version within that major + version to which the sender is conformant and able to understand for + future communication. The minor version advertises the sender's + communication capabilities even when the sender is only using a + backwards-compatible subset of the protocol, thereby letting the + recipient know that more advanced features can be used in response + (by servers) or in future requests (by clients). + + When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] + 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. + + The interpretation of a header field does not change between minor + versions of the same major HTTP version, though the default behavior + of a recipient in the absence of such a field can change. Unless + specified otherwise, header fields defined in HTTP/1.1 are defined + for all versions of HTTP/1.x. In particular, the Host and Connection + header fields ought to be implemented by all HTTP/1.x implementations + whether or not they advertise conformance with HTTP/1.1. + + New header fields can be introduced without changing the protocol + version if their defined semantics allow them to be safely ignored by + recipients that do not recognize them. Header field extensibility is + discussed in Section 3.2.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. In other words, they are not allowed to + blindly forward the first line of an HTTP message 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 + + + + + +Fielding & Reschke Standards Track [Page 14] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 client SHOULD send a request version equal to the highest version + to which the client is conformant and whose major version is no + higher than the highest version supported by the server, if this is + known. A client MUST NOT send a version to which it is not + conformant. + + A client MAY send a lower request version if it is known that the + server incorrectly implements the HTTP specification, but only after + the client has attempted at least one normal request and determined + from the response status code or header fields (e.g., Server) that + the server improperly handles higher request versions. + + A server SHOULD send a response version equal to the highest version + to which the server is conformant that has a major version less than + or equal to the one received in the request. A server MUST NOT send + a version to which it is not conformant. A server can send a 505 + (HTTP Version Not Supported) response if it wishes, for any reason, + to refuse service of the client's major protocol version. + + A server MAY send an HTTP/1.0 response to a 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. + + The intention of HTTP's versioning design is that the major number + will only be incremented if an incompatible message syntax is + introduced, and that the minor number will only be incremented when + changes made to the protocol have the effect of adding to the message + semantics or implying additional capabilities of the sender. + However, the minor version was not incremented for the changes + introduced between [RFC2068] and [RFC2616], and this revision has + specifically avoided any such changes to the protocol. + + When an HTTP message is received with a major version number that the + recipient implements, but a higher minor version number than what the + recipient implements, the recipient SHOULD process the message as if + it were in the highest minor version within that major version to + which the recipient is conformant. A recipient can assume that a + + + +Fielding & Reschke Standards Track [Page 15] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + message with a higher minor version, when sent to a recipient that + has not yet indicated support for that higher version, is + sufficiently backwards-compatible to be safely processed by any + implementation of the same major version. + +2.7. Uniform Resource Identifiers + + Uniform Resource Identifiers (URIs) [RFC3986] are used throughout + HTTP as the means for identifying resources (Section 2 of [RFC7231]). + URI references are used to target requests, indicate redirects, and + define relationships. + + The definitions of "URI-reference", "absolute-URI", "relative-part", + "scheme", "authority", "port", "host", "path-abempty", "segment", + "query", and "fragment" are adopted from the URI generic syntax. An + "absolute-path" rule is defined for protocol elements that can + contain a non-empty path component. (This rule differs slightly from + the path-abempty rule of RFC 3986, which allows for an empty path to + be used in references, and path-absolute rule, which does not allow + paths that begin with "//".) A "partial-URI" rule is defined for + protocol elements that can contain a relative URI but not a fragment + component. + + URI-reference = + absolute-URI = + relative-part = + scheme = + authority = + uri-host = + port = + path-abempty = + segment = + query = + fragment = + + absolute-path = 1*( "/" segment ) + partial-URI = relative-part [ "?" query ] + + Each protocol element in HTTP that allows a URI reference will + indicate in its ABNF production whether the element allows any form + of reference (URI-reference), only a URI in absolute form + (absolute-URI), only the path and optional query components, or some + combination of the above. Unless otherwise indicated, URI references + are parsed relative to the effective request URI (Section 5.5). + + + + + + + +Fielding & Reschke Standards Track [Page 16] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +2.7.1. http URI Scheme + + The "http" URI scheme is hereby defined for the purpose of minting + identifiers according to their association with the hierarchical + namespace governed by a potential HTTP origin server listening for + TCP ([RFC0793]) connections on a given port. + + http-URI = "http:" "//" authority path-abempty [ "?" query ] + [ "#" fragment ] + + The origin server for an "http" URI is identified by the authority + component, which includes a host identifier and optional TCP port + ([RFC3986], Section 3.2.2). The hierarchical path component and + optional query component serve as an identifier for a potential + target resource within that origin server's name space. The optional + fragment component allows for indirect identification of a secondary + resource, independent of the URI scheme, as defined in Section 3.5 of + [RFC3986]. + + A sender MUST NOT generate an "http" URI with an empty host + identifier. A recipient that processes such a URI reference MUST + reject it as invalid. + + If the host identifier is provided as an IP address, the origin + server is the listener (if any) on the indicated TCP port at that IP + address. If host is a registered name, the registered name is an + indirect identifier for use with a name resolution service, such as + DNS, to find an address for that origin server. If the port + subcomponent is empty or not given, TCP port 80 (the reserved port + for WWW services) is the default. + + Note that the presence of a URI with a given authority component does + not imply that there is always an HTTP server listening for + connections on that host and port. Anyone can mint a URI. What the + authority component determines is who has the right to respond + authoritatively to requests that target the identified resource. The + delegated nature of registered names and IP addresses creates a + federated namespace, based on control over the indicated host and + port, whether or not an HTTP server is present. See Section 9.1 for + security considerations related to establishing authority. + + When an "http" URI is used within a context that calls for access to + the indicated resource, a client MAY attempt access by resolving the + host to an IP address, establishing a TCP connection to that address + on the indicated port, and sending an HTTP request message + (Section 3) containing the URI's identifying data (Section 5) to the + server. If the server responds to that request with a non-interim + + + + +Fielding & Reschke Standards Track [Page 17] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + HTTP response message, as described in Section 6 of [RFC7231], then + that response is considered an authoritative answer to the client's + request. + + Although HTTP is independent of the transport protocol, the "http" + scheme is specific to TCP-based services because the name delegation + process depends on TCP for establishing authority. An HTTP service + based on some other underlying connection protocol would presumably + be identified using a different URI scheme, just as the "https" + scheme (below) is used for resources that require an end-to-end + secured connection. Other protocols might also be used to provide + access to "http" identified resources -- it is only the authoritative + interface that is specific to TCP. + + The URI generic syntax for authority also includes a deprecated + userinfo subcomponent ([RFC3986], Section 3.2.1) for including user + authentication information in the URI. Some implementations make use + of the userinfo component for internal configuration of + authentication information, such as within command invocation + options, configuration files, or bookmark lists, even though such + usage might expose a user identifier or password. A sender MUST NOT + generate the userinfo subcomponent (and its "@" delimiter) when an + "http" URI reference is generated within a message as a request + target or header field value. Before making use of an "http" URI + reference received from an untrusted source, a recipient SHOULD parse + for userinfo and treat its presence as an error; it is likely being + used to obscure the authority for the sake of phishing attacks. + +2.7.2. https URI Scheme + + The "https" URI scheme is hereby defined for the purpose of minting + identifiers according to their association with the hierarchical + namespace governed by a potential HTTP origin server listening to a + given TCP port for TLS-secured connections ([RFC5246]). + + All of the requirements listed above for the "http" scheme are also + requirements for the "https" scheme, except that TCP port 443 is the + default if the port subcomponent is empty or not given, and the user + agent MUST ensure that its connection to the origin server is secured + through the use of strong encryption, end-to-end, prior to sending + the first HTTP request. + + https-URI = "https:" "//" authority path-abempty [ "?" query ] + [ "#" fragment ] + + Note that the "https" URI scheme depends on both TLS and TCP for + establishing authority. Resources made available via the "https" + scheme have no shared identity with the "http" scheme even if their + + + +Fielding & Reschke Standards Track [Page 18] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + resource identifiers indicate the same authority (the same host + listening to the same TCP port). They are distinct namespaces and + are considered to be distinct origin servers. However, an extension + to HTTP that is defined to apply to entire host domains, such as the + Cookie protocol [RFC6265], can allow information set by one service + to impact communication with other services within a matching group + of host domains. + + The process for authoritative access to an "https" identified + resource is defined in [RFC2818]. + +2.7.3. http and https URI Normalization and Comparison + + Since the "http" and "https" schemes conform to the URI generic + syntax, such URIs are normalized and compared according to the + algorithm defined in Section 6 of [RFC3986], using the defaults + described above for each scheme. + + If the port is equal to the default port for a scheme, the normal + form is to omit the port subcomponent. When not being used in + absolute form as the request target of an OPTIONS request, an empty + path component is equivalent to an absolute path of "/", so the + normal form is to provide a path of "/" instead. The scheme and host + are case-insensitive and normally provided in lowercase; all other + components are compared in a case-sensitive manner. Characters other + than those in the "reserved" set are equivalent to their + percent-encoded octets: the normal form is to not encode them (see + Sections 2.1 and 2.2 of [RFC3986]). + + For example, the following three URIs are equivalent: + + http://example.com:80/~smith/home.html + http://EXAMPLE.com/%7Esmith/home.html + http://EXAMPLE.com:/%7esmith/home.html + +3. Message Format + + All HTTP/1.1 messages consist of a start-line followed by a sequence + of octets in a format similar to the Internet Message Format + [RFC5322]: zero or more header fields (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 + *( header-field CRLF ) + CRLF + [ message-body ] + + + + +Fielding & Reschke Standards Track [Page 19] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + The normal procedure for parsing an HTTP message is to read the + start-line into a structure, read each header field 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-value after message parsing has delineated the + individual fields. + + An HTTP message can be parsed as a stream for incremental processing + or forwarding downstream. However, recipients cannot rely on + incremental delivery of partial messages, since some implementations + will buffer or delay message forwarding for the sake of network + efficiency, security checks, or payload transformations. + + 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). + + The presence of such whitespace in a request might be an attempt to + trick a server into ignoring that field or processing the line after + it as a new request, either of which might result in a security + vulnerability if other implementations within the request chain + interpret the same message differently. Likewise, the presence of + such whitespace in a response might be ignored by some clients or + cause others to cease parsing. + +3.1. Start Line + + An HTTP message can be either a request from client to server or a + response from server to client. Syntactically, the two types of + message 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 3.3). + + + + +Fielding & Reschke Standards Track [Page 20] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + In theory, a client could receive requests and a server could receive + responses, distinguishing them by their different start-line formats, + but, 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. + + start-line = request-line / status-line + +3.1.1. Request Line + + A request-line begins with a method token, followed by a single space + (SP), the request-target, another single space (SP), the protocol + version, and ends with CRLF. + + request-line = method SP request-target SP HTTP-version CRLF + + 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 4 of [RFC7231], along with information regarding the HTTP + method registry and considerations for defining new methods. + + The request-target identifies the target resource upon which to apply + the request, as defined in Section 5.3. + + Recipients typically parse the request-line into its component parts + by splitting on whitespace (see Section 3.5), since no whitespace is + allowed in the three components. Unfortunately, some user agents + fail to properly encode or exclude whitespace found in hypertext + references, resulting in those disallowed characters being sent in a + request-target. + + 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. + + HTTP does not place a predefined limit on the length of a + request-line, as described in Section 2.5. 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 + + + + + +Fielding & Reschke Standards Track [Page 21] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + request-target longer than any URI it wishes to parse MUST respond + with a 414 (URI Too Long) status code (see Section 6.5.12 of + [RFC7231]). + + 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.2. Status Line + + The first line of a response message is the status-line, consisting + of the protocol version, a space (SP), the status code, another + space, a possibly empty textual phrase describing the status code, + and ending with CRLF. + + status-line = HTTP-version SP status-code SP reason-phrase CRLF + + 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. The rest of the response message is to be + interpreted in light of the semantics defined for that status code. + See Section 6 of [RFC7231] for information about the semantics of + status codes, including the classes of status code (indicated by the + first digit), the status codes defined by this specification, + considerations for the definition of new status codes, and the IANA + registry. + + status-code = 3DIGIT + + 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. A client SHOULD + ignore the reason-phrase content. + + reason-phrase = *( HTAB / SP / VCHAR / obs-text ) + +3.2. Header Fields + + Each header field consists of a case-insensitive field name followed + by a colon (":"), optional leading whitespace, the field value, and + optional trailing whitespace. + + + + + + + + + +Fielding & Reschke Standards Track [Page 22] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + header-field = field-name ":" OWS field-value OWS + + field-name = token + field-value = *( field-content / obs-fold ) + field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] + field-vchar = VCHAR / obs-text + + obs-fold = CRLF 1*( SP / HTAB ) + ; obsolete line folding + ; see Section 3.2.4 + + The field-name token labels the corresponding field-value as having + the semantics defined by that header field. For example, the Date + header field is defined in Section 7.1.1.2 of [RFC7231] as containing + the origination timestamp for the message in which it appears. + +3.2.1. Field Extensibility + + Header fields are fully extensible: there is no limit on the + introduction of new field names, each presumably defining new + semantics, nor on the number of header fields used in a given + message. Existing fields are defined in each part of this + specification and in many other specifications outside this document + set. + + New header fields can be defined such that, when they are understood + by a recipient, they might override or enhance the interpretation of + previously defined header fields, define preconditions on request + evaluation, or refine the meaning of responses. + + A proxy MUST forward unrecognized header fields unless the field-name + is listed in the Connection header field (Section 6.1) or the proxy + is specifically configured to block, or otherwise transform, such + fields. Other recipients SHOULD ignore unrecognized header fields. + These requirements allow HTTP's functionality to be enhanced without + requiring prior update of deployed intermediaries. + + All defined header fields ought to be registered with IANA in the + "Message Headers" registry, as described in Section 8.3 of [RFC7231]. + +3.2.2. Field Order + + The order in which header fields with differing field names are + received is not significant. However, it is good practice to send + header fields that contain control data first, such as Host on + requests and Date on responses, so that implementations can decide + when not to handle a message as early as possible. A server MUST NOT + apply a request to the target resource until the entire request + + + +Fielding & Reschke Standards Track [Page 23] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + header section is received, since later header fields might include + conditionals, authentication credentials, or deliberately misleading + duplicate header fields that would impact request processing. + + A sender MUST NOT generate multiple header fields with the same field + name in a message unless either the entire field value for that + header field is defined as a comma-separated list [i.e., #(values)] + or the header field is a well-known exception (as noted below). + + A recipient MAY combine multiple header fields with the same field + name into one "field-name: field-value" pair, without changing the + semantics of the message, by appending each subsequent field value to + the combined field value in order, 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; a proxy MUST NOT change the order of these field values when + forwarding a message. + + Note: In practice, the "Set-Cookie" header field ([RFC6265]) often + appears multiple times in a response message and does not use the + list syntax, violating the above requirements on multiple header + fields with the same name. Since it cannot be combined into a + single field-value, recipients ought to handle "Set-Cookie" as a + special case while processing header fields. (See Appendix A.2.3 + of [Kri2001] for details.) + +3.2.3. Whitespace + + This specification uses three rules to denote the use of linear + whitespace: OWS (optional whitespace), RWS (required whitespace), and + BWS ("bad" whitespace). + + The OWS rule is used where zero or more linear whitespace octets + might appear. For protocol elements where optional whitespace is + preferred to improve readability, a sender SHOULD generate the + optional whitespace as a single SP; otherwise, a sender SHOULD NOT + generate optional whitespace except as needed to white out invalid or + unwanted protocol elements during in-place message filtering. + + The RWS rule is used when at least one linear whitespace octet is + required to separate field tokens. A sender SHOULD generate RWS as a + single SP. + + The BWS rule is used where the grammar allows optional whitespace + only for historical reasons. A sender MUST NOT generate BWS in + messages. A recipient MUST parse for such bad whitespace and remove + it before interpreting the protocol element. + + + + +Fielding & Reschke Standards Track [Page 24] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + OWS = *( SP / HTAB ) + ; optional whitespace + RWS = 1*( SP / HTAB ) + ; required whitespace + BWS = OWS + ; "bad" whitespace + +3.2.4. Field Parsing + + Messages are parsed using a generic algorithm, independent of the + individual header field names. The contents within a given field + value are not parsed until a later stage of message interpretation + (usually after the message's entire header section has been + processed). Consequently, this specification does not use ABNF rules + to define each "Field-Name: Field Value" pair, as was done in + previous editions. Instead, this specification uses ABNF rules that + are named according to each registered field name, wherein the rule + defines the valid grammar for that field's corresponding field values + (i.e., after the field-value has been extracted from the header + section by a generic field parser). + + No whitespace is allowed between the header 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 any received request message that contains + whitespace between a header field-name and colon with a response code + of 400 (Bad Request). A proxy MUST remove any such whitespace from a + response message before forwarding the message downstream. + + A field value might be preceded and/or followed by optional + whitespace (OWS); a single SP preceding the field-value is preferred + for consistent readability by humans. The field value does not + include any leading or trailing whitespace: OWS occurring before the + first non-whitespace octet of the field value or after the last + non-whitespace octet of the field value ought to be excluded by + parsers when extracting the field value from a header field. + + Historically, HTTP header 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 8.3.1). A sender MUST NOT generate a message that includes + line folding (i.e., that has any field-value that contains a match to + the obs-fold rule) unless the message is intended for packaging + within the message/http media type. + + + + + + +Fielding & Reschke Standards Track [Page 25] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + + Historically, HTTP has allowed field content with text in the + ISO-8859-1 charset [ISO-8859-1], supporting other charsets only + through use of [RFC2047] encoding. In practice, most HTTP header + field values use only a subset of the US-ASCII charset [USASCII]. + Newly defined header fields SHOULD limit their field values to + US-ASCII octets. A recipient SHOULD treat other octets in field + content (obs-text) as opaque data. + +3.2.5. Field Limits + + HTTP does not place a predefined limit on the length of each header + field or on the length of the header section as a whole, as described + in Section 2.5. Various ad hoc limitations on individual header + field length are found in practice, often depending on the specific + field semantics. + + A server that receives a request header field, or set of fields, + larger than it wishes to process MUST respond with an appropriate 4xx + (Client Error) status code. Ignoring such header fields would + increase the server's vulnerability to request smuggling attacks + (Section 9.5). + + A client MAY discard or truncate received header fields that are + larger than the client wishes to process if the field semantics are + such that the dropped value(s) can be safely ignored without changing + the message framing or response semantics. + + + + + +Fielding & Reschke Standards Track [Page 26] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +3.2.6. Field Value Components + + Most HTTP header field values are defined using common syntax + components (token, quoted-string, and comment) separated by + whitespace or specific delimiting characters. Delimiters are chosen + from the set of US-ASCII visual characters not allowed in a token + (DQUOTE and "(),/:;<=>?@[\]{}"). + + token = 1*tchar + + tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" + / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" + / DIGIT / ALPHA + ; any VCHAR, except delimiters + + A string of text is parsed as a single value if it is quoted using + double-quote marks. + + quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE + qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text + obs-text = %x80-FF + + 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. + + comment = "(" *( ctext / quoted-pair / comment ) ")" + ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text + + The backslash octet ("\") can be used as a single-octet quoting + mechanism within quoted-string and comment constructs. Recipients + that process the value of a quoted-string MUST handle a quoted-pair + as if it were replaced by the octet following the backslash. + + quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) + + A sender SHOULD NOT generate a quoted-pair in a quoted-string except + where necessary to quote DQUOTE and backslash octets occurring within + that string. A sender SHOULD NOT generate a quoted-pair in a comment + except where necessary to quote parentheses ["(" and ")"] and + backslash octets occurring within that comment. + + + + + + + + + + +Fielding & Reschke Standards Track [Page 27] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +3.3. Message Body + + The message body (if any) of an HTTP message is used to carry the + payload body of that request or response. The message body is + identical to the payload body unless a transfer coding has been + applied, as described in Section 3.3.1. + + message-body = *OCTET + + 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 a + Content-Length or Transfer-Encoding header field. Request message + framing is independent of method semantics, even if the method does + not define any use for a message body. + + The presence of a message body in a response depends on both the + request method to which it is responding and the response status code + (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 + of [RFC7231]) never include a message body because the associated + response header fields (e.g., Transfer-Encoding, Content-Length, + etc.), if present, indicate only what their values would have been if + the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx + (Successful) responses to a CONNECT request method (Section 4.3.6 of + [RFC7231]) switch to tunnel mode instead of having a message body. + All 1xx (Informational), 204 (No Content), and 304 (Not Modified) + responses do not include a message body. All other responses do + include a message body, although the body might be of zero length. + +3.3.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 payload body in order to form the message + body. Transfer codings are defined in Section 4. + + Transfer-Encoding = 1#transfer-coding + + 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 a dynamically generated payload and to distinguish payload + encodings that are only applied for transport efficiency or security + from those that are characteristics of the selected resource. + + + + +Fielding & Reschke Standards Track [Page 28] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A recipient MUST be able to parse the chunked transfer coding + (Section 4.1) because it plays a crucial role in framing messages + when the payload body size is not known in advance. A sender MUST + NOT apply chunked 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 payload body, 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 payload body, 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 payload body has been compressed using the gzip + coding and then chunked using the chunked coding while forming the + message body. + + Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), + Transfer-Encoding is a property of the message, not of the + representation, and 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 4.1 of [RFC7232]) 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 4.3.6 of + [RFC7231]). + + 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 a transfer-encoded payload. A client MUST + NOT send a request containing Transfer-Encoding unless it knows the + + + +Fielding & Reschke Standards Track [Page 29] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + server will handle HTTP/1.1 (or later) requests; 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). + + A server that receives a request message with a transfer coding it + does not understand SHOULD respond with 501 (Not Implemented). + +3.3.2. Content-Length + + When a message does not have a Transfer-Encoding header field, a + Content-Length header field can provide the anticipated size, as a + decimal number of octets, for a potential payload body. For messages + that do include a payload body, the Content-Length field-value + provides the framing information necessary for determining where the + body (and message) ends. For messages that do not include a payload + body, the Content-Length indicates the size of the selected + representation (Section 3 of [RFC7231]). + + Content-Length = 1*DIGIT + + An example is + + Content-Length: 3495 + + A sender MUST NOT send a Content-Length header field in any message + that contains a Transfer-Encoding header field. + + A user agent SHOULD send a Content-Length in a request message when + no Transfer-Encoding is sent and the request method defines a meaning + for an enclosed payload body. For example, a Content-Length header + field is normally sent in a POST request even when the value is 0 + (indicating an empty payload body). A user agent SHOULD NOT send a + Content-Length header field when the request message does not contain + a payload body and the method semantics do not anticipate such a + body. + + A server MAY send a Content-Length header field in a response to a + HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send + Content-Length in such a response unless its field-value equals the + decimal number of octets that would have been sent in the payload + body of a response if the same request had used the GET method. + + A server MAY send a Content-Length header field in a 304 (Not + Modified) response to a conditional GET request (Section 4.1 of + [RFC7232]); a server MUST NOT send Content-Length in such a response + + + + +Fielding & Reschke Standards Track [Page 30] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + unless its field-value equals the decimal number of octets that would + have been sent in the payload body of a 200 (OK) response to the same + request. + + A server MUST NOT send a Content-Length header field in any response + with a status code of 1xx (Informational) or 204 (No Content). A + server MUST NOT send a Content-Length header field in any 2xx + (Successful) response to a CONNECT request (Section 4.3.6 of + [RFC7231]). + + Aside from the cases defined above, in the absence of + Transfer-Encoding, an origin server SHOULD send a Content-Length + header field when the payload body size is known prior to sending the + complete header section. This will allow downstream recipients to + measure transfer progress, know when a received message is complete, + and potentially reuse the connection for additional requests. + + Any Content-Length field value greater than or equal to zero is + valid. Since there is no predefined limit to the length of a + payload, a recipient MUST anticipate potentially large decimal + numerals and prevent parsing errors due to integer conversion + overflows (Section 9.3). + + If a message is received that has multiple Content-Length header + fields with field-values consisting of the same decimal value, or a + single Content-Length header field with a field value containing a + list of identical decimal values (e.g., "Content-Length: 42, 42"), + indicating that duplicate Content-Length header fields have been + generated or combined by an upstream message processor, then the + recipient MUST either reject the message as invalid or replace the + duplicated field-values with a single valid Content-Length field + containing that decimal value prior to determining the message body + length or forwarding the message. + + 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. + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 31] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +3.3.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. + + 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 Transfer-Encoding header field is present and the chunked + transfer coding (Section 4.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. + + 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 9.5) or response splitting + (Section 9.4) and ought to be handled as an error. A sender MUST + remove the received Content-Length field prior to forwarding such + a message downstream. + + 4. If a message is received without Transfer-Encoding and with + either multiple Content-Length header fields having differing + field-values or a single Content-Length header field having an + invalid value, then the message framing is invalid and the + recipient MUST treat it as an unrecoverable error. If this is a + request message, the server MUST respond with a 400 (Bad Request) + status code and then close the connection. If this is 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 + + + +Fielding & Reschke Standards Track [Page 32] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Gateway) response to the client. If this is a response message + received by a user agent, the user agent MUST close the + connection to the server and discard the received response. + + 5. 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. + + 6. 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). + + 7. 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 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. + + 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 containing a message body MUST send + a valid Content-Length header field if it does not know 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 + + + +Fielding & Reschke Standards Track [Page 33] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + data belongs as part of the prior response 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. + +3.4. 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 of [RFC7234]. + + 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, thus, is considered complete regardless of the number + of message body octets received, provided that the header section was + received intact. + +3.5. Message Parsing Robustness + + 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. + + + + +Fielding & Reschke Standards Track [Page 34] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Although the line terminator for the start-line and header fields is + the sequence CRLF, a recipient MAY recognize a single LF as a line + terminator and ignore any preceding CR. + + Although the request-line and status-line grammar rules require 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 security vulnerabilities if there are multiple recipients + of the message and each has its own unique interpretation of + robustness (see Section 9.5). + + 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. + +4. 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 payload 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 rather than a property of the representation + that is being transferred. + + transfer-coding = "chunked" ; Section 4.1 + / "compress" ; Section 4.2.1 + / "deflate" ; Section 4.2.2 + / "gzip" ; Section 4.2.3 + / transfer-extension + transfer-extension = token *( OWS ";" OWS transfer-parameter ) + + Parameters are in the form of a name or name=value pair. + + transfer-parameter = token BWS "=" BWS ( token / quoted-string ) + + All transfer-coding names are case-insensitive and ought to be + registered within the HTTP Transfer Coding registry, as defined in + Section 8.4. They are used in the TE (Section 4.3) and + Transfer-Encoding (Section 3.3.1) header fields. + + + + + + +Fielding & Reschke Standards Track [Page 35] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +4.1. Chunked Transfer Coding + + The chunked transfer coding wraps the payload body in order to + transfer it as a series of chunks, each with its own size indicator, + followed by an OPTIONAL trailer containing header 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-part + 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, and finally terminated by an empty line. + + A recipient MUST be able to parse and decode the chunked transfer + coding. + +4.1.1. Chunk Extensions + + The chunked encoding 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 = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) + + chunk-ext-name = token + chunk-ext-val = token / quoted-string + + The chunked encoding 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, use of chunk extensions is generally limited + + + + +Fielding & Reschke Standards Track [Page 36] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + +4.1.2. Chunked Trailer Part + + A trailer 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 message body is sent, such as a + message integrity check, digital signature, or post-processing + status. The trailer fields are identical to header fields, except + they are sent in a chunked trailer instead of the message's header + section. + + trailer-part = *( header-field CRLF ) + + A sender MUST NOT generate a trailer that contains a field necessary + for message framing (e.g., Transfer-Encoding and Content-Length), + routing (e.g., Host), request modifiers (e.g., controls and + conditionals in Section 5 of [RFC7231]), authentication (e.g., see + [RFC7235] and [RFC6265]), response control data (e.g., see Section + 7.1 of [RFC7231]), or determining how to process the payload (e.g., + Content-Encoding, Content-Type, Content-Range, and Trailer). + + When a chunked message containing a non-empty trailer is received, + the recipient MAY process the fields (aside from those forbidden + above) as if they were appended to the message's header section. A + recipient MUST ignore (or consider as an error) any fields that are + forbidden to be sent in a trailer, since processing them as if they + were present in the header section might bypass external security + filters. + + Unless the request includes a TE header field indicating "trailers" + is acceptable, as described in Section 4.3, a server SHOULD NOT + generate trailer fields that it believes are necessary for the user + agent to receive. Without a TE containing "trailers", the server + ought to assume that the trailer fields might be silently discarded + along the path to the user agent. This requirement allows + intermediaries to forward a de-chunked message to an HTTP/1.0 + recipient without buffering the entire response. + + + + +Fielding & Reschke Standards Track [Page 37] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +4.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 decoded-body + length := length + chunk-size + read chunk-size, chunk-ext (if any), and CRLF + } + read trailer field + while (trailer field is not empty) { + if (trailer field is allowed to be sent in a trailer) { + append trailer field to existing header fields + } + read trailer-field + } + Content-Length := length + Remove "chunked" from Transfer-Encoding + Remove Trailer from existing header fields + +4.2. Compression Codings + + The codings defined below can be used to compress the payload of a + message. + +4.2.1. Compress Coding + + The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding + [Welch] that is commonly produced by the UNIX file compression + program "compress". A recipient SHOULD consider "x-compress" to be + equivalent to "compress". + +4.2.2. Deflate Coding + + The "deflate" coding is a "zlib" data format [RFC1950] containing a + "deflate" compressed data stream [RFC1951] that uses a combination of + the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. + + Note: Some non-conformant implementations send the "deflate" + compressed data without the zlib wrapper. + + + + + + + +Fielding & Reschke Standards Track [Page 38] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +4.2.3. Gzip Coding + + The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy + Check (CRC) that is commonly produced by the gzip file compression + program [RFC1952]. A recipient SHOULD consider "x-gzip" to be + equivalent to "gzip". + +4.3. TE + + The "TE" header field in a request indicates what transfer codings, + besides chunked, the client is willing to accept in response, and + whether or not the client is willing to accept trailer fields in a + chunked transfer coding. + + The TE field-value consists of a comma-separated list of transfer + coding names, each allowing for optional parameters (as described in + Section 4), and/or the keyword "trailers". A client MUST NOT send + the chunked transfer coding name in TE; chunked is always acceptable + for HTTP/1.1 recipients. + + TE = #t-codings + t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) + t-ranking = OWS ";" OWS "q=" rank + rank = ( "0" [ "." 0*3DIGIT ] ) + / ( "1" [ "." 0*3("0") ] ) + + Three examples of TE use are below. + + TE: deflate + TE: + TE: trailers, deflate;q=0.5 + + 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 4.1.2, on behalf of itself and any downstream + clients. For requests from an intermediary, this implies that + either: (a) all downstream clients are willing to accept trailer + fields in the forwarded response; or, (b) the intermediary will + attempt to buffer the response on behalf of downstream recipients. + Note that 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. + + 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, Section + + + + + +Fielding & Reschke Standards Track [Page 39] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 5.3.1 of [RFC7231]). 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. + + 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 6.1) in order to prevent the TE + field from being forwarded by intermediaries that do not support its + semantics. + +4.4. Trailer + + When a message includes a message body encoded with the chunked + transfer coding and the sender desires to send metadata in the form + of trailer fields at the end of the message, the sender SHOULD + generate a Trailer header field before the message body to indicate + which fields will be present in the trailers. This allows the + recipient to prepare for receipt of that metadata before it starts + processing the body, which is useful if the message is being streamed + and the recipient wishes to confirm an integrity check on the fly. + + Trailer = 1#field-name + +5. Message Routing + + HTTP request message routing is determined by each client based on + the target resource, the client's proxy configuration, and + establishment or reuse of an inbound connection. The corresponding + response routing follows the same connection chain back to the + client. + +5.1. Identifying a Target Resource + + HTTP is used in a wide variety of applications, ranging from + general-purpose computers to home appliances. In some cases, + communication options are hard-coded in a client's configuration. + However, most HTTP clients rely on the same resource identification + mechanism and configuration techniques as general-purpose Web + browsers. + + HTTP communication is initiated by a user agent for some purpose. + The purpose is a combination of request semantics, which are defined + in [RFC7231], and a target resource upon which to apply those + semantics. A URI reference (Section 2.7) is typically used as an + + + +Fielding & Reschke Standards Track [Page 40] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + identifier for the "target resource", which a user agent would + resolve to its absolute form in order to obtain the "target URI". + The target URI excludes the reference's fragment component, if any, + since fragment identifiers are reserved for client-side processing + ([RFC3986], Section 3.5). + +5.2. Connecting Inbound + + Once the target URI is determined, a client needs to decide whether a + network request is necessary to accomplish the desired semantics and, + if so, where that request is to be directed. + + If the client has a cache [RFC7234] and the request can be satisfied + by it, then the request is usually directed there first. + + If the request is not satisfied by a cache, then a typical client + will check its configuration to determine whether a proxy is to be + used to satisfy the request. Proxy configuration is implementation- + dependent, but is often based on URI prefix matching, selective + authority matching, or both, and the proxy itself is usually + identified by an "http" or "https" URI. If a proxy is applicable, + the client connects inbound by establishing (or reusing) a connection + to that proxy. + + If no proxy is applicable, a typical client will invoke a handler + routine, usually specific to the target URI's scheme, to connect + directly to an authority for the target resource. How that is + accomplished is dependent on the target URI scheme and defined by its + associated specification, similar to how this specification defines + origin server access for resolution of the "http" (Section 2.7.1) and + "https" (Section 2.7.2) schemes. + + HTTP requirements regarding connection management are defined in + Section 6. + +5.3. Request Target + + Once an inbound connection is obtained, the client sends an HTTP + request message (Section 3) with a request-target derived from the + 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 + + + + +Fielding & Reschke Standards Track [Page 41] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +5.3.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 5.4. + + 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. + +5.3.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 + to either 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 5.7. + + An example absolute-form of request-line would be: + + GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 + + + + + + +Fielding & Reschke Standards Track [Page 42] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + To allow for transition to the absolute-form for all requests in some + future version of HTTP, a server MUST accept the absolute-form in + requests, even though HTTP/1.1 clients will only send them in + requests to proxies. + +5.3.3. authority-form + + The authority-form of request-target is only used for CONNECT + requests (Section 4.3.6 of [RFC7231]). + + authority-form = authority + + When making a CONNECT request to establish a tunnel through one or + more proxies, a client MUST send only the target URI's authority + component (excluding any userinfo and its "@" delimiter) as the + request-target. For example, + + CONNECT www.example.com:80 HTTP/1.1 + +5.3.4. asterisk-form + + The asterisk-form of request-target is only used for a server-wide + OPTIONS request (Section 4.3.7 of [RFC7231]). + + 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". + + + +Fielding & Reschke Standards Track [Page 43] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +5.4. Host + + The "Host" header field in a request provides the host and port + information from the target URI, enabling the origin server to + distinguish among resources while servicing requests for multiple + host names on a single IP address. + + Host = uri-host [ ":" port ] ; Section 2.7.1 + + A client MUST send a Host header field 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 2.7.1). 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. + + Since the Host field-value is critical information for handling a + request, a user agent SHOULD generate Host as the first header field + following the request-line. + + For example, a GET request to the origin server for + would begin with: + + GET /pub/WWW/ HTTP/1.1 + Host: www.example.org + + 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. + + Since the Host header field acts as an application-level routing + mechanism, it is a frequent target for malware seeking to poison a + shared cache or redirect a request to an unintended server. An + interception proxy is particularly vulnerable if it relies on the + Host field-value for redirecting requests to internal servers, or for + use as a cache key in a shared cache, without first verifying that + the intercepted connection is targeting a valid IP address for that + host. + + + + +Fielding & Reschke Standards Track [Page 44] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 or a + Host header field with an invalid field-value. + +5.5. Effective Request URI + + Since the request-target often contains only part of the user agent's + target URI, a server reconstructs the intended target as an + "effective request URI" to properly service the request. This + reconstruction involves both the server's local configuration and + information communicated in the request-target, Host header field, + and connection context. + + For a user agent, the effective request URI is the target URI. + + If the request-target is in absolute-form, the effective request URI + is the same as the request-target. Otherwise, the effective request + URI is constructed as follows: + + If the server's configuration (or outbound gateway) provides a + fixed URI scheme, that scheme is used for the effective request + URI. Otherwise, if the request is received over a TLS-secured TCP + connection, the effective request URI's scheme is "https"; if not, + the scheme is "http". + + If the server's configuration (or outbound gateway) provides a + fixed URI authority component, that authority is used for the + effective request URI. If not, then if the request-target is in + authority-form, the effective request URI's authority component is + the same as the request-target. If not, then if a Host header + field is supplied with a non-empty field-value, the authority + component is the same as the Host field-value. Otherwise, the + authority component is assigned the default name configured for + the server and, if the connection's incoming TCP port number + differs from the default port for the effective request URI's + scheme, then a colon (":") and the incoming port number (in + decimal form) are appended to the authority component. + + If the request-target is in authority-form or asterisk-form, the + effective request URI's combined path and query component is + empty. Otherwise, the combined path and query component is the + same as the request-target. + + The components of the effective request URI, once determined as + above, can be combined into absolute-URI form by concatenating the + scheme, "://", authority, and combined path and query component. + + + + +Fielding & Reschke Standards Track [Page 45] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Example 1: the following message received over an insecure TCP + connection + + GET /pub/WWW/TheProject.html HTTP/1.1 + Host: www.example.org:8080 + + has an effective request URI of + + http://www.example.org:8080/pub/WWW/TheProject.html + + Example 2: the following message received over a TLS-secured TCP + connection + + OPTIONS * HTTP/1.1 + Host: www.example.org + + has an effective request URI of + + https://www.example.org + + Recipients of an HTTP/1.0 request that lacks a Host header field + might need to use heuristics (e.g., examination of the URI path for + something unique to a particular host) in order to guess the + effective request URI's authority component. + + Once the effective request URI has been constructed, an origin server + needs to decide whether or not to provide service for that URI via + the connection in which the request was received. For example, the + request might have been misdirected, deliberately or accidentally, + such that the information within a received request-target or Host + header field differs from the host or port upon which the connection + has been made. If the connection is from a trusted gateway, that + inconsistency might be expected; otherwise, it might indicate an + attempt to bypass security filters, trick the server into delivering + non-public content, or poison a cache. See Section 9 for security + considerations regarding message routing. + +5.6. Associating a Response to a Request + + HTTP 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 6.2 of + [RFC7231]) precede a final response to the same request. + + + + + +Fielding & Reschke Standards Track [Page 46] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 highest ordered request that has not yet received a final + (non-1xx) response. + +5.7. Message Forwarding + + As described in Section 2.3, intermediaries can serve a variety of + roles in the processing of HTTP requests and responses. Some + intermediaries are used to improve performance or availability. + Others are used for access control or to filter content. Since an + HTTP stream has characteristics similar to a pipe-and-filter + architecture, there are no inherent limits to the extent an + intermediary can enhance (or interfere) with either direction of the + stream. + + An intermediary not acting as a tunnel MUST implement the Connection + header field, as specified in Section 6.1, and exclude fields from + being forwarded that are only intended for the incoming connection. + + An intermediary MUST NOT forward a message to itself unless it is + protected from an infinite request loop. In general, an intermediary + ought to recognize its own server names, including any aliases, local + variations, or literal IP addresses, and respond to such requests + directly. + +5.7.1. Via + + The "Via" header field indicates the presence of intermediate + protocols and recipients between the user agent and the server (on + requests) or between the origin server and the client (on responses), + similar to the "Received" header field in email (Section 3.6.7 of + [RFC5322]). Via can be used for tracking message forwards, avoiding + request loops, and identifying the protocol capabilities of senders + along the request/response chain. + + Via = 1#( received-protocol RWS received-by [ RWS comment ] ) + + received-protocol = [ protocol-name "/" ] protocol-version + ; see Section 6.7 + received-by = ( uri-host [ ":" port ] ) / pseudonym + pseudonym = token + + Multiple Via field values represent each proxy or gateway that has + forwarded the message. Each intermediary appends its own information + about how the message was received, such that the end result is + ordered according to the sequence of forwarding recipients. + + + +Fielding & Reschke Standards Track [Page 47] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A proxy MUST send an appropriate Via header field, as described + below, in each message that it forwards. An HTTP-to-HTTP gateway + MUST send an appropriate Via header field in each inbound request + message and MAY send a Via header field in forwarded response + messages. + + For each intermediary, the received-protocol indicates the protocol + and protocol version used by the upstream sender of the message. + Hence, the Via field value records the advertised protocol + capabilities of the request/response chain such that they remain + visible to downstream recipients; this can be useful for determining + what backwards-incompatible features might be safe to use in + response, or within a later request, as described in Section 2.6. + For brevity, the protocol-name is omitted when the received protocol + is HTTP. + + The received-by portion of the field value 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, a sender MAY replace it with + a pseudonym. If a port is not provided, a recipient MAY interpret + that as meaning it was received on the default TCP port, if any, for + the received-protocol. + + A sender MAY generate comments in the Via header field to identify + the software of each recipient, analogous to the User-Agent and + Server header fields. However, all comments in the Via field are + optional, and a recipient MAY remove them 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 p.example.net, which + completes the request by forwarding it to the origin server at + www.example.com. The request received by www.example.com would then + have the following Via header field: + + Via: 1.0 fred, 1.1 p.example.net + + An intermediary used as a portal through a network firewall SHOULD + NOT forward the names and ports of hosts within the firewall region + unless it is explicitly enabled to do so. If not enabled, such an + intermediary SHOULD replace each received-by host of any host behind + the firewall by an appropriate pseudonym for that host. + + + + + + + +Fielding & Reschke Standards Track [Page 48] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + An intermediary MAY combine an ordered subsequence of Via header + field entries into a single such entry if the entries have identical + received-protocol values. 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 + + A sender SHOULD NOT combine multiple entries unless they are all + under the same organizational control and the hosts have already been + replaced by pseudonyms. A sender MUST NOT combine entries that have + different received-protocol values. + +5.7.2. Transformations + + Some intermediaries include features for transforming messages and + their payloads. 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. However, operational problems might occur + when these transformations are applied to payloads intended for + critical applications, such as medical imaging or scientific data + analysis, particularly when integrity checks or digital signatures + are used to ensure that the payload received is identical to the + original. + + An HTTP-to-HTTP proxy is called a "transforming proxy" if it is + designed or configured to modify messages in a semantically + meaningful way (i.e., modifications, beyond those required by normal + HTTP processing, that change the message in a way that would be + significant to the original sender or potentially significant to + downstream recipients). For example, a transforming proxy might be + acting as a shared annotation server (modifying responses to include + references to a local annotation database), a malware filter, a + format transcoder, or a privacy filter. Such transformations are + presumed to be desired by whichever client (or client organization) + selected the proxy. + + If a proxy receives a request-target with a host name that is not a + fully qualified domain name, it MAY add its own domain to the host + name it received when forwarding the request. A proxy MUST NOT + change the host name if the request-target contains a fully qualified + domain name. + + + + + + + +Fielding & Reschke Standards Track [Page 49] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A proxy MUST NOT modify the "absolute-path" and "query" parts of the + received request-target when forwarding it to the next inbound + server, except as noted above to replace an empty path with "/" or + "*". + + A proxy MAY modify the message body through application or removal of + a transfer coding (Section 4). + + A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of + a message that contains a no-transform cache-control directive + (Section 5.2 of [RFC7234]). + + A proxy MAY transform the payload of a message that does not contain + a no-transform cache-control directive. A proxy that transforms a + payload MUST add a Warning header field with the warn-code of 214 + ("Transformation Applied") if one is not already in the message (see + Section 5.5 of [RFC7234]). A proxy that transforms the payload of a + 200 (OK) response can further inform downstream recipients that a + transformation has been applied by changing the response status code + to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]). + + A proxy SHOULD NOT modify header fields that provide information + about the endpoints of the communication chain, the resource state, + or the selected representation (other than the payload) unless the + field's definition specifically allows such modification or the + modification is deemed necessary for privacy or security. + +6. 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 5.2, 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 2.7.1) 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. + + + + + + + + + +Fielding & Reschke Standards Track [Page 50] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + +6.1. Connection + + The "Connection" header field allows the sender to indicate desired + control options for the current connection. In order to avoid + confusing downstream recipients, a proxy or gateway MUST remove or + replace any received connection options before forwarding the + message. + + When a header field aside from Connection is used to supply control + information for or about the current connection, the sender MUST list + the corresponding field-name within the Connection header field. A + proxy or gateway MUST parse a received Connection header field before + a message is forwarded and, for each connection-option in this field, + remove any header field(s) from the message with the same name as the + connection-option, and then remove the Connection header field itself + (or replace it with the intermediary's own connection options for the + forwarded message). + + Hence, the Connection header field provides a declarative way of + distinguishing header fields that are only intended for the immediate + recipient ("hop-by-hop") from those fields that are intended for all + recipients on the chain ("end-to-end"), enabling the message to be + self-descriptive and allowing future connection-specific extensions + to be deployed without fear that they will be blindly forwarded by + older intermediaries. + + The Connection header field's value has the following grammar: + + Connection = 1#connection-option + connection-option = token + + Connection options are case-insensitive. + + A sender MUST NOT send a connection option corresponding to a header + field that is intended for all recipients of the payload. For + example, Cache-Control is never appropriate as a connection option + (Section 5.2 of [RFC7234]). + + + + +Fielding & Reschke Standards Track [Page 51] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + The connection options do not always correspond to a header field + present in the message, since a connection-specific header field + might not be needed if there are no parameters associated with a + connection option. In contrast, a connection-specific header field + that is received without a corresponding connection option usually + indicates that the field has been improperly forwarded by an + intermediary and ought to be ignored by the recipient. + + When defining new connection options, specification authors ought to + survey existing header field names and ensure that the new connection + option does not share the same name as an already deployed header + field. Defining a new connection option essentially reserves that + potential field-name for carrying additional information related to + the connection option, since it would be unwise for senders to use + that field-name for anything else. + + The "close" connection option is defined for a sender to signal that + this 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 sender is going to close the connection after the current + request/response is complete (Section 6.6). + + 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. + +6.2. Establishment + + It is beyond the scope of this specification to describe how + connections are established via various transport- or session-layer + protocols. Each connection applies to only one transport link. + +6.3. Persistence + + HTTP/1.1 defaults to the use of "persistent connections", allowing + multiple requests and responses to be carried over a single + connection. The "close" connection option is used to signal that a + connection will not persist after the current request/response. HTTP + implementations SHOULD support persistent connections. + + + + + +Fielding & Reschke Standards Track [Page 52] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + A recipient determines whether a connection is persistent or not + based on the most recently received message's protocol version and + Connection header field (if any): + + o If the "close" connection option is present, the connection will + not persist after the current response; else, + + o If the received protocol is HTTP/1.1 (or later), the connection + will persist after the current response; else, + + o If the received protocol is HTTP/1.0, the "keep-alive" connection + option is present, the recipient is not a proxy, and the recipient + wishes to honor the HTTP/1.0 "keep-alive" mechanism, the + connection will persist after the current response; otherwise, + + o The connection will close after the current response. + + 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 3.3. A server MUST read + the entire request message body or close the connection after sending + its response, since 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 Section 19.7.1 of [RFC2068] for information and + discussion of the problems with the Keep-Alive header field + implemented by many HTTP/1.0 clients). + + See Appendix A.1.2 for more information on backwards compatibility + with HTTP/1.0 clients. + +6.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. + + + + + + + + +Fielding & Reschke Standards Track [Page 53] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + When an inbound connection is closed prematurely, a client MAY open a + new connection and automatically retransmit an aborted sequence of + requests if all of those requests have idempotent methods (Section + 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry + non-idempotent requests. + + A user agent MUST NOT automatically retry a request with a non- + idempotent method unless it has some means to know that the request + semantics are actually idempotent, regardless of the method, or some + means to detect that the original request was never applied. For + example, a user agent that knows (through design or configuration) + that a POST request to a given resource is safe can repeat that + request automatically. Likewise, a user agent designed specifically + to operate on a version control repository might be able to recover + from partial failure conditions by checking the target resource + revision(s) after a failed connection, reverting or fixing any + changes that were partially applied, and then automatically retrying + the requests that failed. + + A client SHOULD NOT automatically retry a failed automatic retry. + +6.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 4.2.1 of [RFC7231]), + 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 6.6). + + Idempotent methods (Section 4.2.2 of [RFC7231]) 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. + + + + +Fielding & Reschke Standards Track [Page 54] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + +6.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 has a large payload blocks subsequent + requests on the same connection. However, each connection consumes + server resources. Furthermore, using multiple connections can cause + undesirable side effects in congested networks. + + 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. + +6.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. + + + + +Fielding & Reschke Standards Track [Page 55] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + + 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. + +6.6. Tear-down + + The Connection header field (Section 6.1) provides a "close" + connection option that a sender SHOULD send when it wishes to close + the connection after the current request/response pair. + + A client that sends a "close" connection option MUST NOT send further + requests on that connection (after the one containing "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 a + close of the connection (see below) after it sends the final response + to the request that contained "close". 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 a close + of the connection (see below) after it sends the response containing + "close". 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"; if additional pipelined + requests had been sent on the connection, the client SHOULD NOT + assume that they will be processed by the server. + + + +Fielding & Reschke Standards Track [Page 56] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 that was + 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. + +6.7. Upgrade + + The "Upgrade" header field is intended to provide a simple mechanism + for transitioning from HTTP/1.1 to some other protocol on the same + connection. A client MAY send a list of protocols in the Upgrade + header field of a request to invite the server to switch to one or + more of those protocols, in order of descending preference, before + sending the final response. A server MAY ignore a received Upgrade + header field if it wishes to continue using the current protocol on + that connection. Upgrade cannot be used to insist on a protocol + change. + + Upgrade = 1#protocol + + protocol = protocol-name ["/" protocol-version] + protocol-name = token + protocol-version = token + + A server that sends a 101 (Switching Protocols) response MUST send an + Upgrade header field to indicate the new protocol(s) to which the + connection is being switched; if multiple protocol layers are being + switched, the sender MUST list the protocols in layer-ascending + order. A server MUST NOT switch to a protocol that was not indicated + by the client in the corresponding request's Upgrade header field. A + + + + + +Fielding & Reschke Standards Track [Page 57] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + server MAY choose to ignore the order of preference indicated by the + client and select the new protocol(s) based on other factors, such as + the nature of the request or the current load on the server. + + A server that sends a 426 (Upgrade Required) response MUST send an + Upgrade header field to indicate the acceptable protocols, in order + of descending preference. + + A server MAY send an Upgrade header field in any other response to + advertise that it implements support for upgrading to the listed + protocols, in order of descending preference, when appropriate for a + future request. + + The following is a hypothetical example sent by a client: + + GET /hello.txt HTTP/1.1 + Host: www.example.com + Connection: upgrade + Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 + + + The capabilities and nature of the application-level communication + after the protocol change is entirely dependent upon the new + protocol(s) chosen. However, immediately after sending the 101 + (Switching Protocols) response, the server is expected to continue + responding to the original request as if it had received its + equivalent within the new protocol (i.e., the server still has an + outstanding request to satisfy after the protocol has been changed, + and is expected to do so without requiring the request to be + repeated). + + For example, if the Upgrade header field is received in a GET request + and the server decides to switch protocols, it first responds with a + 101 (Switching Protocols) message in HTTP/1.1 and then immediately + follows that with the new protocol's equivalent of a response to a + GET on the target resource. This allows a connection to be upgraded + to protocols with the same semantics as HTTP without the latency cost + of an additional round trip. A server MUST NOT switch protocols + unless the received message semantics can be honored by the new + protocol; an OPTIONS request can be honored by any protocol. + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 58] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + The following is an example response to the above hypothetical + request: + + HTTP/1.1 101 Switching Protocols + Connection: upgrade + Upgrade: HTTP/2.0 + + [... data stream switches to HTTP/2.0 with an appropriate response + (as defined by new protocol) to the "GET /hello.txt" request ...] + + When Upgrade is sent, the sender MUST also send a Connection header + field (Section 6.1) that contains an "upgrade" connection option, in + order to prevent Upgrade from being accidentally forwarded by + intermediaries that might not implement the listed protocols. A + server MUST ignore an Upgrade header field that is received in an + HTTP/1.0 request. + + A client cannot begin using an upgraded protocol on the connection + until it has completely sent the request message (i.e., the client + can't change the protocol it is sending in the middle of a message). + If a server receives both an Upgrade and an Expect header field with + the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the + server MUST send a 100 (Continue) response before sending a 101 + (Switching Protocols) response. + + The Upgrade header field only applies to switching protocols on top + of the existing connection; it cannot be used to switch the + underlying connection (transport) protocol, nor to switch the + existing communication to a different connection. For those + purposes, it is more appropriate to use a 3xx (Redirection) response + (Section 6.4 of [RFC7231]). + + 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 2.6 and future updates to this + specification. Additional tokens ought to be registered with IANA + using the registration procedure defined in Section 8.6. + +7. ABNF List Extension: #rule + + A #rule extension to the ABNF rules of [RFC5234] is used to improve + readability in the definitions of some header field values. + + A construct "#" is defined, similar to "*", for defining + comma-delimited lists of elements. The full form is "#element" + indicating at least and at most elements, each separated by a + single comma (",") and optional whitespace (OWS). + + + + +Fielding & Reschke Standards Track [Page 59] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + In any production that uses the list construct, a sender MUST NOT + generate empty list elements. In other words, a sender MUST generate + lists that satisfy the following syntax: + + 1#element => element *( OWS "," OWS element ) + + and: + + #element => [ 1#element ] + + and for n >= 1 and m > 1: + + #element => element *( OWS "," OWS element ) + + For compatibility with legacy list rules, a recipient MUST parse and + ignore a reasonable number of empty list elements: enough to handle + common mistakes by senders that merge values, but not so much that + they could be used as a denial-of-service mechanism. In other words, + a recipient MUST accept lists that satisfy the following syntax: + + #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] + + 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) + + Empty elements do not contribute to the count of elements present. + For example, given these ABNF productions: + + example-list = 1#example-list-elmt + example-list-elmt = token ; see Section 3.2.6 + + Then the following are valid values for example-list (not including + the double quotes, which are present for delimitation only): + + "foo,bar" + "foo ,bar," + "foo , ,bar,charlie " + + In contrast, the following values would be invalid, since at least + one non-empty element is required by the example-list production: + + "" + "," + ", ," + + Appendix B shows the collected ABNF for recipients after the list + constructs have been expanded. + + + + + +Fielding & Reschke Standards Track [Page 60] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +8. IANA Considerations + +8.1. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + This document defines the following HTTP header fields, so the + "Permanent Message Header Field Names" registry has been updated + accordingly (see [BCP90]). + + +-------------------+----------+----------+---------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+---------------+ + | Connection | http | standard | Section 6.1 | + | Content-Length | http | standard | Section 3.3.2 | + | Host | http | standard | Section 5.4 | + | TE | http | standard | Section 4.3 | + | Trailer | http | standard | Section 4.4 | + | Transfer-Encoding | http | standard | Section 3.3.1 | + | Upgrade | http | standard | Section 6.7 | + | Via | http | standard | Section 5.7.1 | + +-------------------+----------+----------+---------------+ + + Furthermore, the header field-name "Close" has been registered as + "reserved", since using that name as an HTTP header field might + conflict with the "close" connection option of the Connection header + field (Section 6.1). + + +-------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-------------+ + | Close | http | reserved | Section 8.1 | + +-------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 61] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +8.2. URI Scheme Registration + + IANA maintains the registry of URI Schemes [BCP115] at + . + + This document defines the following URI schemes, so the "Permanent + URI Schemes" registry has been updated accordingly. + + +------------+------------------------------------+---------------+ + | URI Scheme | Description | Reference | + +------------+------------------------------------+---------------+ + | http | Hypertext Transfer Protocol | Section 2.7.1 | + | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | + +------------+------------------------------------+---------------+ + +8.3. Internet Media Type Registration + + IANA maintains the registry of Internet media types [BCP13] at + . + + This document serves as the specification for the Internet media + types "message/http" and "application/http". The following has been + registered with IANA. + +8.3.1. Internet Media Type message/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. + + 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 + + + +Fielding & Reschke Standards Track [Page 62] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Security considerations: see Section 9 + + Interoperability considerations: N/A + + Published specification: This specification (see Section 8.3.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 Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + +8.3.2. Internet Media Type application/http + + The application/http 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. + + + + +Fielding & Reschke Standards Track [Page 63] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 9 + + Interoperability considerations: N/A + + Published specification: This specification (see Section 8.3.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 Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + +8.4. Transfer Coding Registry + + The "HTTP Transfer Coding Registry" defines the namespace for + transfer coding names. It is maintained at + . + + + + + + + +Fielding & Reschke Standards Track [Page 64] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +8.4.1. Procedure + + Registrations MUST include the following fields: + + o Name + + o Description + + o Pointer to specification text + + Names of transfer codings MUST NOT overlap with names of content + codings (Section 3.1.2.1 of [RFC7231]) unless the encoding + transformation is identical, as is the case for the compression + codings defined in Section 4.2. + + Values to be added to this namespace require IETF Review (see Section + 4.1 of [RFC5226]), 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. + +8.4.2. Registration + + The "HTTP Transfer Coding Registry" has been updated with the + registrations below: + + +------------+--------------------------------------+---------------+ + | Name | Description | Reference | + +------------+--------------------------------------+---------------+ + | chunked | Transfer in a series of chunks | Section 4.1 | + | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | + | deflate | "deflate" compressed data | Section 4.2.2 | + | | ([RFC1951]) inside the "zlib" data | | + | | format ([RFC1950]) | | + | gzip | GZIP file format [RFC1952] | Section 4.2.3 | + | x-compress | Deprecated (alias for compress) | Section 4.2.1 | + | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | + +------------+--------------------------------------+---------------+ + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 65] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +8.5. Content Coding Registration + + IANA maintains the "HTTP Content Coding Registry" at + . + + The "HTTP Content Coding Registry" has been updated with the + registrations below: + + +------------+--------------------------------------+---------------+ + | Name | Description | Reference | + +------------+--------------------------------------+---------------+ + | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | + | deflate | "deflate" compressed data | Section 4.2.2 | + | | ([RFC1951]) inside the "zlib" data | | + | | format ([RFC1950]) | | + | gzip | GZIP file format [RFC1952] | Section 4.2.3 | + | x-compress | Deprecated (alias for compress) | Section 4.2.1 | + | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | + +------------+--------------------------------------+---------------+ + +8.6. Upgrade Token Registry + + The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" + defines the namespace for protocol-name tokens used to identify + protocols in the Upgrade header field. The registry is maintained at + . + +8.6.1. Procedure + + Each registered protocol name is associated with contact information + and an optional set of specifications that details how the connection + will be processed after it has been upgraded. + + Registrations happen on a "First Come First Served" basis (see + Section 4.1 of [RFC5226]) and are subject to the following rules: + + 1. A protocol-name token, once registered, stays registered forever. + + 2. The registration MUST name a responsible party for the + registration. + + 3. The registration MUST name a point of contact. + + 4. The registration MAY name a set of specifications associated with + that token. Such specifications need not be publicly available. + + 5. The registration SHOULD name a set of expected "protocol-version" + tokens associated with that token at the time of registration. + + + +Fielding & Reschke Standards Track [Page 66] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 6. The responsible party MAY change the registration at any time. + The IANA will keep a record of all such changes, and make them + available upon request. + + 7. The IESG MAY reassign responsibility for a protocol token. This + will normally only be used in the case when a responsible party + cannot be contacted. + + This registration procedure for HTTP Upgrade Tokens replaces that + previously defined in Section 7.2 of [RFC2817]. + +8.6.2. Upgrade Token Registration + + The "HTTP" entry in the upgrade token registry has been updated with + the registration below: + + +-------+----------------------+----------------------+-------------+ + | Value | Description | Expected Version | Reference | + | | | Tokens | | + +-------+----------------------+----------------------+-------------+ + | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | + | | Protocol | (e.g, "2.0") | | + +-------+----------------------+----------------------+-------------+ + + The responsible party is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +9. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security considerations relevant to HTTP message + syntax, parsing, and routing. Security considerations about HTTP + semantics and payloads are addressed in [RFC7231]. + +9.1. Establishing Authority + + HTTP relies on the notion of an authoritative response: a response + that has been determined by (or at the direction of) the authority + identified within the target URI to be the most appropriate response + for that request given the state of the target resource at the time + of response message origination. Providing a response from a + non-authoritative source, such as a shared cache, is often useful to + improve performance and availability, but only to the extent that the + source can be trusted or the distrusted response can be safely used. + + Unfortunately, establishing authority can be difficult. For example, + phishing is an attack on the user's perception of authority, where + that perception can be misled by presenting similar branding in + + + +Fielding & Reschke Standards Track [Page 67] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + hypertext, possibly aided by userinfo obfuscating the authority + component (see Section 2.7.1). User agents can reduce the impact of + phishing attacks by enabling users to easily inspect a target URI + prior to making an action, by prominently distinguishing (or + rejecting) userinfo when present, and by not sending stored + credentials and cookies when the referring document is from an + unknown or untrusted source. + + When a registered name is used in the authority component, the "http" + URI scheme (Section 2.7.1) relies on the user's local name resolution + service to determine where it can find authoritative responses. This + means that any attack on a user's network host table, cached names, + or name resolution libraries becomes an avenue for attack on + establishing authority. Likewise, the user's choice of server for + Domain Name Service (DNS), and the hierarchy of servers from which it + obtains resolution results, could impact the authenticity of address + mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to + improve authenticity. + + Furthermore, after an IP address is obtained, establishing authority + for an "http" URI is vulnerable to attacks on Internet Protocol + routing. + + The "https" scheme (Section 2.7.2) is intended to prevent (or at + least reveal) many of these potential attacks on establishing + authority, provided that the negotiated TLS connection is secured and + the client properly verifies that the communicating server's identity + matches the target URI's authority component (see [RFC2818]). + Correctly implementing such verification can be difficult (see + [Georgiev]). + +9.2. Risks of Intermediaries + + By their very nature, HTTP intermediaries are men-in-the-middle and, + thus, represent an opportunity for man-in-the-middle attacks. + Compromise of the systems on which the intermediaries run can result + in serious security and privacy problems. Intermediaries might have + access to security-related information, personal information about + individual users and organizations, and proprietary information + belonging to users and content providers. A compromised + intermediary, or an intermediary implemented or configured without + regard to security and privacy considerations, might be used in the + commission of a wide range of potential attacks. + + Intermediaries that contain a shared cache are especially vulnerable + to cache poisoning attacks, as described in Section 8 of [RFC7234]. + + + + + +Fielding & Reschke Standards Track [Page 68] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Implementers need to consider the privacy and security implications + of their design and coding decisions, and of the configuration + options they provide to operators (especially the default + configuration). + + Users need to be aware that intermediaries are no more trustworthy + than the people who run them; HTTP itself cannot solve this problem. + +9.3. Attacks via Protocol Element Length + + Because HTTP uses mostly textual, character-delimited fields, parsers + are often vulnerable to attacks based on sending very long (or very + slow) streams of data, particularly where an implementation is + expecting a protocol element with no predefined length. + + To promote interoperability, specific recommendations are made for + minimum size limits on request-line (Section 3.1.1) and header fields + (Section 3.2). These are minimum recommendations, chosen to be + supportable even by implementations with limited resources; it is + expected that most implementations will choose substantially higher + limits. + + A server can reject a message that has a request-target that is too + long (Section 6.5.12 of [RFC7231]) or a request payload that is too + large (Section 6.5.11 of [RFC7231]). Additional status codes related + to capacity limits have been defined by extensions to HTTP [RFC6585]. + + Recipients ought to carefully limit the extent to which they process + other protocol elements, including (but not limited to) request + methods, response status phrases, header field-names, numeric values, + and body chunks. Failure to limit such processing can result in + buffer overflows, arithmetic overflows, or increased vulnerability to + denial-of-service attacks. + +9.4. 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 + + + +Fielding & Reschke Standards Track [Page 69] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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. + +9.5. 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 3.3.3, to reduce the effectiveness of request smuggling. + +9.6. 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. Additional integrity + mechanisms, such as hash functions or digital signatures applied to + the content, can be selectively added to messages via extensible + + + +Fielding & Reschke Standards Track [Page 70] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + metadata header fields. 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. + + User agents are encouraged to implement configurable means for + detecting and reporting failures of message integrity such that those + means can be enabled within environments for which integrity is + necessary. 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. At a minimum, user agents + ought to provide some indication that allows a user to distinguish + between a complete and incomplete response message (Section 3.4) when + such verification is desired. + +9.7. 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 different 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 2.7.2. + +9.8. Privacy of Server Log Information + + A server is in the position to save personal data about a user's + requests over time, which might identify their reading patterns or + subjects of interest. In particular, log information gathered at an + intermediary often contains a history of user agent interaction, + across a multitude of sites, that can be traced to individual users. + + HTTP log information is confidential in nature; its handling is often + constrained by laws and regulations. Log information needs to be + securely stored and appropriate guidelines followed for its analysis. + Anonymization of personal information within individual entries + helps, but it is generally not sufficient to prevent real log traces + from being re-identified based on correlation with other access + characteristics. As such, access traces that are keyed to a specific + client are unsafe to publish even if the key is pseudonymous. + + + + +Fielding & Reschke Standards Track [Page 71] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + To minimize the risk of theft or accidental publication, log + information ought to be purged of personally identifiable + information, including user identifiers, IP addresses, and + user-provided query parameters, as soon as that information is no + longer necessary to support operational needs for security, auditing, + or fraud control. + +10. Acknowledgments + + This edition of HTTP/1.1 builds on the many contributions that went + into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including + substantial contributions made by the previous authors, editors, and + Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, + Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, + and Paul J. Leach. Mark Nottingham oversaw this effort as Working + Group Chair. + + Since 1999, the following contributors have helped improve the HTTP + specification by reporting bugs, asking smart questions, drafting or + reviewing text, and evaluating open issues: + + Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole, + Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek + Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha + Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, + Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, + Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander + Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin + Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern + Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, + Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens, + Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, + Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus + Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, + Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave + Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty, + Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan + Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D. + Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik + Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian + Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, + Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, + Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz + Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik + Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, + Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido + Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, + James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie + + + +Fielding & Reschke Standards Track [Page 72] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with + the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim + Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel + Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp, + John Panzer, John Schneider, John Stracke, John Sullivan, Jonas + Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, + Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien + Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin + James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith + Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin + Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault, + Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark + Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, + Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, + Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge, + Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael + Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, + Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, + Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas + Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, + Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. + Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska, + Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil + Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul- + Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto + Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby + Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert + O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de + Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny + Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam + Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence + (who maintained the original issues list), Sean B. Palmer, Sean + Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon + Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane + Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart + Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares, + Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya + Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas + Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim + Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent + Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez + Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, + Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, + Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the + editor team), Zed A. Shaw, and Zhong Yu. + + See Section 16 of [RFC2616] for additional acknowledgements from + prior revisions. + + + +Fielding & Reschke Standards Track [Page 73] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +11. References + +11.1. Normative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data + Format Specification version 3.3", RFC 1950, May 1996. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3", RFC 1951, May 1996. + + [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and + G. Randers-Pehrson, "GZIP file format specification + version 4.3", RFC 1952, May 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Semantics and Content", + RFC 7231, June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Conditional Requests", + RFC 7232, June 2014. + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range + Requests", RFC 7233, June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Authentication", + RFC 7235, June 2014. + + + + +Fielding & Reschke Standards Track [Page 74] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + [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), June 1984. + +11.2. Informative References + + [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines + and Registration Procedures for New URI Schemes", + BCP 115, RFC 4395, February 2006. + + [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, January 2013. + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, + RFC 3864, September 2004. + + [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., + Boneh, D., and V. Shmatikov, "The Most Dangerous Code + in the World: Validating SSL Certificates in Non- + browser Software", In Proceedings of the 2012 ACM + Conference on Computer and Communications Security (CCS + '12), pp. 38-49, October 2012, + . + + [ISO-8859-1] International Organization for Standardization, + "Information technology -- 8-bit single-byte coded + graphic character sets -- Part 1: Latin alphabet No. + 1", ISO/IEC 8859-1:1998, 1998. + + [Klein] Klein, A., "Divide and Conquer - HTTP Response + Splitting, Web Cache Poisoning Attacks, and Related + Topics", March 2004, . + + [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and + Politics", ACM Transactions on Internet + Technology 1(2), November 2001, + . + + [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP + Request Smuggling", June 2005, + . + + + + +Fielding & Reschke Standards Track [Page 75] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", + RFC 1919, March 1996. + + [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, + "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, + May 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text", RFC 2047, November 1996. + + [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and + T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2068, January 1997. + + [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, + "Use and Interpretation of HTTP Version Numbers", + RFC 2145, May 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, May 2000. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web + Replication and Caching Taxonomy", RFC 3040, + January 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based + Kerberos and NTLM HTTP Authentication in Microsoft + Windows", RFC 4559, June 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, + RFC 5226, May 2008. + + + + +Fielding & Reschke Standards Track [Page 76] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, + October 2008. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + + [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status + Codes", RFC 6585, April 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 77] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +Appendix A. HTTP Version History + + HTTP has been in use since 1990. The first version, later referred + to as HTTP/0.9, was a simple protocol for hypertext data transfer + across the Internet, using only a single request method (GET) and no + metadata. HTTP/1.0, as defined by [RFC1945], added a range of + request methods and MIME-like messaging, allowing for metadata to be + transferred and modifiers placed on the request/response semantics. + However, HTTP/1.0 did not sufficiently take into consideration the + effects of hierarchical proxies, caching, the need for persistent + connections, or name-based virtual hosts. The proliferation of + incompletely implemented applications calling themselves "HTTP/1.0" + further necessitated a protocol version change in order for two + communicating applications to determine each other's true + capabilities. + + HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent + requirements that enable reliable implementations, adding only those + features that can either be safely ignored by an HTTP/1.0 recipient + or only be sent when communicating with a party advertising + conformance with HTTP/1.1. + + HTTP/1.1 has been designed to make supporting previous versions easy. + A general-purpose HTTP/1.1 server ought to be able to understand any + valid request in the format of HTTP/1.0, responding appropriately + with an HTTP/1.1 message that only uses features understood (or + safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client + can be expected to understand any valid HTTP/1.0 response. + + 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. + +A.1. Changes from HTTP/1.0 + + This section summarizes major differences between versions HTTP/1.0 + and HTTP/1.1. + +A.1.1. Multihomed Web Servers + + The requirements that clients and servers support the Host header + field (Section 5.4), report an error if it is missing from an + HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among + the most important changes defined by HTTP/1.1. + + + +Fielding & Reschke Standards Track [Page 78] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + 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 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. + +A.1.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 stop sending the header field), and this mechanism ought + not be used by clients at all when a proxy is being used. + +A.1.3. Introduction of Transfer-Encoding + + HTTP/1.1 introduces the Transfer-Encoding header field + (Section 3.3.1). Transfer codings need to be decoded prior to + forwarding an HTTP message over a MIME-compliant protocol. + + + +Fielding & Reschke Standards Track [Page 79] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +A.2. Changes from RFC 2616 + + HTTP's approach to error handling has been explained. (Section 2.5) + + The HTTP-version ABNF production has been clarified to be case- + sensitive. Additionally, version numbers have been restricted to + single digits, due to the fact that implementations are known to + handle multi-digit version numbers incorrectly. (Section 2.6) + + Userinfo (i.e., username and password) are now disallowed in HTTP and + HTTPS URIs, because of security issues related to their transmission + on the wire. (Section 2.7.1) + + The HTTPS URI scheme is now defined by this specification; + previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it + implies end-to-end security. (Section 2.7.2) + + HTTP messages can be (and often are) buffered by implementations; + despite it sometimes being available as a stream, HTTP is + fundamentally a message-oriented protocol. Minimum supported sizes + for various protocol elements have been suggested, to improve + interoperability. (Section 3) + + Invalid whitespace around field-names is now required to be rejected, + because accepting it represents a security vulnerability. The ABNF + productions defining header fields now only list the field value. + (Section 3.2) + + Rules about implicit linear whitespace between certain grammar + productions have been removed; now whitespace is only allowed where + specifically defined in the ABNF. (Section 3.2.3) + + Header fields that span multiple lines ("line folding") are + deprecated. (Section 3.2.4) + + The NUL octet is no longer allowed in comment and quoted-string text, + and handling of backslash-escaping in them has been clarified. The + quoted-pair rule no longer allows escaping control characters other + than HTAB. Non-US-ASCII content in header fields and the reason + phrase has been obsoleted and made opaque (the TEXT rule was + removed). (Section 3.2.6) + + Bogus Content-Length header fields are now required to be handled as + errors by recipients. (Section 3.3.2) + + The algorithm for determining the message body length has been + clarified to indicate all of the special cases (e.g., driven by + methods or status codes) that affect it, and that new protocol + + + +Fielding & Reschke Standards Track [Page 80] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + elements cannot define such special cases. CONNECT is a new, special + case in determining message body length. "multipart/byteranges" is no + longer a way of determining message body length detection. + (Section 3.3.3) + + The "identity" transfer coding token has been removed. (Sections 3.3 + and 4) + + Chunk length does not include the count of the octets in the chunk + header and trailer. Line folding in chunk extensions is disallowed. + (Section 4.1) + + The meaning of the "deflate" content coding has been clarified. + (Section 4.2.2) + + The segment + query components of RFC 3986 have been used to define + the request-target, instead of abs_path from RFC 1808. The + asterisk-form of the request-target is only allowed with the OPTIONS + method. (Section 5.3) + + The term "Effective Request URI" has been introduced. (Section 5.5) + + Gateways do not need to generate Via header fields anymore. + (Section 5.7.1) + + Exactly when "close" connection options have to be sent has been + clarified. Also, "hop-by-hop" header fields are required to appear + in the Connection header field; just because they're defined as hop- + by-hop in this specification doesn't exempt them. (Section 6.1) + + The limit of two connections per server has been removed. An + idempotent sequence of requests is no longer required to be retried. + The requirement to retry requests under certain circumstances when + the server prematurely closes the connection has been removed. Also, + some extraneous requirements about when servers are allowed to close + connections prematurely have been removed. (Section 6.3) + + The semantics of the Upgrade header field is now defined in responses + other than 101 (this was incorporated from [RFC2817]). Furthermore, + the ordering in the field value is now significant. (Section 6.7) + + Empty list elements in list productions (e.g., a list header field + containing ", ,") have been deprecated. (Section 7) + + Registration of Transfer Codings now requires IETF Review + (Section 8.4) + + + + + +Fielding & Reschke Standards Track [Page 81] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + This specification now defines the Upgrade Token Registry, previously + defined in Section 7.2 of [RFC2817]. (Section 8.6) + + The expectation to support HTTP/0.9 requests has been removed. + (Appendix A) + + Issues with the Keep-Alive and Proxy-Connection header fields in + requests are pointed out, with use of the latter being discouraged + altogether. (Appendix A.1.2) + +Appendix B. Collected ABNF + + BWS = OWS + + Connection = *( "," OWS ) connection-option *( OWS "," [ OWS + connection-option ] ) + + Content-Length = 1*DIGIT + + HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body + ] + HTTP-name = %x48.54.54.50 ; HTTP + HTTP-version = HTTP-name "/" DIGIT "." DIGIT + Host = uri-host [ ":" port ] + + OWS = *( SP / HTAB ) + + RWS = 1*( SP / HTAB ) + + TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] + Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) + Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS + transfer-coding ] ) + + URI-reference = + Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) + + Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment + ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS + comment ] ) ] ) + + absolute-URI = + absolute-form = absolute-URI + absolute-path = 1*( "/" segment ) + asterisk-form = "*" + authority = + authority-form = authority + + + + +Fielding & Reschke Standards Track [Page 82] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF + chunk-data = 1*OCTET + chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) + chunk-ext-name = token + chunk-ext-val = token / quoted-string + chunk-size = 1*HEXDIG + chunked-body = *chunk last-chunk trailer-part CRLF + comment = "(" *( ctext / quoted-pair / comment ) ")" + connection-option = token + ctext = HTAB / SP / %x21-27 ; '!'-''' + / %x2A-5B ; '*'-'[' + / %x5D-7E ; ']'-'~' + / obs-text + + field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] + field-name = token + field-value = *( field-content / obs-fold ) + field-vchar = VCHAR / obs-text + fragment = + + header-field = field-name ":" OWS field-value OWS + http-URI = "http://" authority path-abempty [ "?" query ] [ "#" + fragment ] + https-URI = "https://" authority path-abempty [ "?" query ] [ "#" + fragment ] + + last-chunk = 1*"0" [ chunk-ext ] CRLF + + message-body = *OCTET + method = token + + obs-fold = CRLF 1*( SP / HTAB ) + obs-text = %x80-FF + origin-form = absolute-path [ "?" query ] + + partial-URI = relative-part [ "?" query ] + path-abempty = + port = + protocol = protocol-name [ "/" protocol-version ] + protocol-name = token + protocol-version = token + pseudonym = token + + qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' + / %x5D-7E ; ']'-'~' + / obs-text + query = + quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) + + + +Fielding & Reschke Standards Track [Page 83] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE + + rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) + reason-phrase = *( HTAB / SP / VCHAR / obs-text ) + received-by = ( uri-host [ ":" port ] ) / pseudonym + received-protocol = [ protocol-name "/" ] protocol-version + relative-part = + request-line = method SP request-target SP HTTP-version CRLF + request-target = origin-form / absolute-form / authority-form / + asterisk-form + + scheme = + segment = + start-line = request-line / status-line + status-code = 3DIGIT + status-line = HTTP-version SP status-code SP reason-phrase CRLF + + t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) + t-ranking = OWS ";" OWS "q=" rank + tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / + "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA + token = 1*tchar + trailer-part = *( header-field CRLF ) + transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / + transfer-extension + transfer-extension = token *( OWS ";" OWS transfer-parameter ) + transfer-parameter = token BWS "=" BWS ( token / quoted-string ) + + uri-host = + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 84] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +Index + + A + absolute-form (of request-target) 42 + accelerator 10 + application/http Media Type 63 + asterisk-form (of request-target) 43 + authoritative response 67 + authority-form (of request-target) 42-43 + + B + browser 7 + + C + cache 11 + cacheable 12 + captive portal 11 + chunked (Coding Format) 28, 32, 36 + client 7 + close 51, 56 + compress (Coding Format) 38 + connection 7 + Connection header field 51, 56 + Content-Length header field 30 + + D + deflate (Coding Format) 38 + Delimiters 27 + downstream 10 + + E + effective request URI 45 + + G + gateway 10 + Grammar + absolute-form 42 + absolute-path 16 + absolute-URI 16 + ALPHA 6 + asterisk-form 41, 43 + authority 16 + authority-form 42-43 + BWS 25 + chunk 36 + chunk-data 36 + chunk-ext 36 + chunk-ext-name 36 + + + +Fielding & Reschke Standards Track [Page 85] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + chunk-ext-val 36 + chunk-size 36 + chunked-body 36 + comment 27 + Connection 51 + connection-option 51 + Content-Length 30 + CR 6 + CRLF 6 + ctext 27 + CTL 6 + DIGIT 6 + DQUOTE 6 + field-content 23 + field-name 23, 40 + field-value 23 + field-vchar 23 + fragment 16 + header-field 23, 37 + HEXDIG 6 + Host 44 + HTAB 6 + HTTP-message 19 + HTTP-name 14 + http-URI 17 + HTTP-version 14 + https-URI 18 + last-chunk 36 + LF 6 + message-body 28 + method 21 + obs-fold 23 + obs-text 27 + OCTET 6 + origin-form 42 + OWS 25 + partial-URI 16 + port 16 + protocol-name 47 + protocol-version 47 + pseudonym 47 + qdtext 27 + query 16 + quoted-pair 27 + quoted-string 27 + rank 39 + reason-phrase 22 + received-by 47 + + + +Fielding & Reschke Standards Track [Page 86] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + received-protocol 47 + request-line 21 + request-target 41 + RWS 25 + scheme 16 + segment 16 + SP 6 + start-line 21 + status-code 22 + status-line 22 + t-codings 39 + t-ranking 39 + tchar 27 + TE 39 + token 27 + Trailer 40 + trailer-part 37 + transfer-coding 35 + Transfer-Encoding 28 + transfer-extension 35 + transfer-parameter 35 + Upgrade 57 + uri-host 16 + URI-reference 16 + VCHAR 6 + Via 47 + gzip (Coding Format) 39 + + H + header field 19 + header section 19 + headers 19 + Host header field 44 + http URI scheme 17 + https URI scheme 17 + I + inbound 9 + interception proxy 11 + intermediary 9 + + M + Media Type + application/http 63 + message/http 62 + message 7 + message/http Media Type 62 + method 21 + + + + +Fielding & Reschke Standards Track [Page 87] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + + N + non-transforming proxy 49 + + O + origin server 7 + origin-form (of request-target) 42 + outbound 10 + + P + phishing 67 + proxy 10 + + R + recipient 7 + request 7 + request-target 21 + resource 16 + response 7 + reverse proxy 10 + + S + sender 7 + server 7 + spider 7 + + T + target resource 40 + target URI 40 + TE header field 39 + Trailer header field 40 + Transfer-Encoding header field 28 + transforming proxy 49 + transparent proxy 11 + tunnel 10 + + U + Upgrade header field 57 + upstream 9 + URI scheme + http 17 + https 17 + user agent 7 + + V + Via header field 47 + + + + + + +Fielding & Reschke Standards Track [Page 88] + +RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 + + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 89] + === added file 'doc/rfc/rfc7231.txt' --- doc/rfc/rfc7231.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7231.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,5659 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7231 Adobe +Obsoletes: 2616 J. Reschke, Ed. +Updates: 2817 greenbytes +Category: Standards Track June 2014 +ISSN: 2070-1721 + + + Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document defines the semantics of HTTP/1.1 messages, + as expressed by request methods, request header fields, response + status codes, and response header fields, along with the payload of + messages (metadata and body content) and mechanisms for content + negotiation. + +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/rfc7231. + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 1] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 2] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +Table of Contents + + 1. Introduction ....................................................6 + 1.1. Conformance and Error Handling .............................6 + 1.2. Syntax Notation ............................................6 + 2. Resources .......................................................7 + 3. Representations .................................................7 + 3.1. Representation Metadata ....................................8 + 3.1.1. Processing Representation Data ......................8 + 3.1.2. Encoding for Compression or Integrity ..............11 + 3.1.3. Audience Language ..................................13 + 3.1.4. Identification .....................................14 + 3.2. Representation Data .......................................17 + 3.3. Payload Semantics .........................................17 + 3.4. Content Negotiation .......................................18 + 3.4.1. Proactive Negotiation ..............................19 + 3.4.2. Reactive Negotiation ...............................20 + 4. Request Methods ................................................21 + 4.1. Overview ..................................................21 + 4.2. Common Method Properties ..................................22 + 4.2.1. Safe Methods .......................................22 + 4.2.2. Idempotent Methods .................................23 + 4.2.3. Cacheable Methods ..................................24 + 4.3. Method Definitions ........................................24 + 4.3.1. GET ................................................24 + 4.3.2. HEAD ...............................................25 + 4.3.3. POST ...............................................25 + 4.3.4. PUT ................................................26 + 4.3.5. DELETE .............................................29 + 4.3.6. CONNECT ............................................30 + 4.3.7. OPTIONS ............................................31 + 4.3.8. TRACE ..............................................32 + 5. Request Header Fields ..........................................33 + 5.1. Controls ..................................................33 + 5.1.1. Expect .............................................34 + 5.1.2. Max-Forwards .......................................36 + 5.2. Conditionals ..............................................36 + 5.3. Content Negotiation .......................................37 + 5.3.1. Quality Values .....................................37 + 5.3.2. Accept .............................................38 + 5.3.3. Accept-Charset .....................................40 + 5.3.4. Accept-Encoding ....................................41 + 5.3.5. Accept-Language ....................................42 + 5.4. Authentication Credentials ................................44 + 5.5. Request Context ...........................................44 + 5.5.1. From ...............................................44 + 5.5.2. Referer ............................................45 + 5.5.3. User-Agent .........................................46 + + + +Fielding & Reschke Standards Track [Page 3] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 6. Response Status Codes ..........................................47 + 6.1. Overview of Status Codes ..................................48 + 6.2. Informational 1xx .........................................50 + 6.2.1. 100 Continue .......................................50 + 6.2.2. 101 Switching Protocols ............................50 + 6.3. Successful 2xx ............................................51 + 6.3.1. 200 OK .............................................51 + 6.3.2. 201 Created ........................................52 + 6.3.3. 202 Accepted .......................................52 + 6.3.4. 203 Non-Authoritative Information ..................52 + 6.3.5. 204 No Content .....................................53 + 6.3.6. 205 Reset Content ..................................53 + 6.4. Redirection 3xx ...........................................54 + 6.4.1. 300 Multiple Choices ...............................55 + 6.4.2. 301 Moved Permanently ..............................56 + 6.4.3. 302 Found ..........................................56 + 6.4.4. 303 See Other ......................................57 + 6.4.5. 305 Use Proxy ......................................58 + 6.4.6. 306 (Unused) .......................................58 + 6.4.7. 307 Temporary Redirect .............................58 + 6.5. Client Error 4xx ..........................................58 + 6.5.1. 400 Bad Request ....................................58 + 6.5.2. 402 Payment Required ...............................59 + 6.5.3. 403 Forbidden ......................................59 + 6.5.4. 404 Not Found ......................................59 + 6.5.5. 405 Method Not Allowed .............................59 + 6.5.6. 406 Not Acceptable .................................60 + 6.5.7. 408 Request Timeout ................................60 + 6.5.8. 409 Conflict .......................................60 + 6.5.9. 410 Gone ...........................................60 + 6.5.10. 411 Length Required ...............................61 + 6.5.11. 413 Payload Too Large .............................61 + 6.5.12. 414 URI Too Long ..................................61 + 6.5.13. 415 Unsupported Media Type ........................62 + 6.5.14. 417 Expectation Failed ............................62 + 6.5.15. 426 Upgrade Required ..............................62 + 6.6. Server Error 5xx ..........................................62 + 6.6.1. 500 Internal Server Error ..........................63 + 6.6.2. 501 Not Implemented ................................63 + 6.6.3. 502 Bad Gateway ....................................63 + 6.6.4. 503 Service Unavailable ............................63 + 6.6.5. 504 Gateway Timeout ................................63 + 6.6.6. 505 HTTP Version Not Supported .....................64 + 7. Response Header Fields .........................................64 + 7.1. Control Data ..............................................64 +ed 7.1.1. Origination Date ...................................65 + 7.1.2. Location ...........................................68 + 7.1.3. Retry-After ........................................69 + + + +Fielding & Reschke Standards Track [Page 4] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 7.1.4. Vary ...............................................70 + 7.2. Validator Header Fields ...................................71 + 7.3. Authentication Challenges .................................72 + 7.4. Response Context ..........................................72 + 7.4.1. Allow ..............................................72 + 7.4.2. Server .............................................73 + 8. IANA Considerations ............................................73 + 8.1. Method Registry ...........................................73 + 8.1.1. Procedure ..........................................74 + 8.1.2. Considerations for New Methods .....................74 + 8.1.3. Registrations ......................................75 + 8.2. Status Code Registry ......................................75 + 8.2.1. Procedure ..........................................75 + 8.2.2. Considerations for New Status Codes ................76 + 8.2.3. Registrations ......................................76 + 8.3. Header Field Registry .....................................77 + 8.3.1. Considerations for New Header Fields ...............78 + 8.3.2. Registrations ......................................80 + 8.4. Content Coding Registry ...................................81 + 8.4.1. Procedure ..........................................81 + 8.4.2. Registrations ......................................81 + 9. Security Considerations ........................................81 + 9.1. Attacks Based on File and Path Names ......................82 + 9.2. Attacks Based on Command, Code, or Query Injection ........82 + 9.3. Disclosure of Personal Information ........................83 + 9.4. Disclosure of Sensitive Information in URIs ...............83 + 9.5. Disclosure of Fragment after Redirects ....................84 + 9.6. Disclosure of Product Information .........................84 + 9.7. Browser Fingerprinting ....................................84 + 10. Acknowledgments ...............................................85 + 11. References ....................................................85 + 11.1. Normative References .....................................85 + 11.2. Informative References ...................................86 + Appendix A. Differences between HTTP and MIME .....................89 + A.1. MIME-Version ..............................................89 + A.2. Conversion to Canonical Form ..............................89 + A.3. Conversion of Date Formats ................................90 + A.4. Conversion of Content-Encoding ............................90 + A.5. Conversion of Content-Transfer-Encoding ...................90 + A.6. MHTML and Line Length Limitations .........................90 + Appendix B. Changes from RFC 2616 .................................91 + Appendix C. Imported ABNF .........................................93 + Appendix D. Collected ABNF ........................................94 + Index .............................................................97 + + + + + + + +Fielding & Reschke Standards Track [Page 5] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +1. Introduction + + Each Hypertext Transfer Protocol (HTTP) message is either a request + or a response. A server listens on a connection for a request, + parses each message received, interprets the message semantics in + relation to the identified request target, and responds to that + request with one or more response messages. A client constructs + request messages to communicate specific intentions, examines + received responses to see if the intentions were carried out, and + determines how to interpret the results. This document defines + HTTP/1.1 request and response semantics in terms of the architecture + defined in [RFC7230]. + + HTTP provides a uniform interface for interacting with a resource + (Section 2), regardless of its type, nature, or implementation, via + the manipulation and transfer of representations (Section 3). + + HTTP semantics include the intentions defined by each request method + (Section 4), extensions to those semantics that might be described in + request header fields (Section 5), the meaning of status codes to + indicate a machine-readable response (Section 6), and the meaning of + other control data and resource metadata that might be given in + response header fields (Section 7). + + This document also defines representation metadata that describe how + a payload is intended to be interpreted by a recipient, the request + header fields that might influence content selection, and the various + selection algorithms that are collectively referred to as "content + negotiation" (Section 3.4). + +1.1. Conformance and Error Handling + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + repetition). Appendix C describes rules imported from other + documents. Appendix D shows the collected grammar with all list + operators expanded to standard ABNF notation. + + + +Fielding & Reschke Standards Track [Page 6] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + This specification uses the terms "character", "character encoding + scheme", "charset", and "protocol element" as they are defined in + [RFC6365]. + +2. Resources + + The target of an HTTP request is called a "resource". HTTP does not + limit the nature of a resource; it merely defines an interface that + might be used to interact with resources. Each resource is + identified by a Uniform Resource Identifier (URI), as described in + Section 2.7 of [RFC7230]. + + When a client constructs an HTTP/1.1 request message, it sends the + target URI in one of various forms, as defined in (Section 5.3 of + [RFC7230]). When a request is received, the server reconstructs an + effective request URI for the target resource (Section 5.5 of + [RFC7230]). + + One design goal of HTTP is to separate resource identification from + request semantics, which is made possible by vesting the request + semantics in the request method (Section 4) and a few + request-modifying header fields (Section 5). If there is a conflict + between the method semantics and any semantic implied by the URI + itself, as described in Section 4.2.1, the method semantics take + precedence. + +3. Representations + + Considering that a resource could be anything, and that the uniform + interface provided by HTTP is similar to a window through which one + can observe and act upon such a thing only through the communication + of messages to some independent actor on the other side, an + abstraction is needed to represent ("take the place of") the current + or desired state of that thing in our communications. That + abstraction is called a representation [REST]. + + For the purposes of HTTP, a "representation" is information that is + intended to reflect a past, current, or desired state of a given + resource, in a format that can be readily communicated via the + protocol, and that consists of a set of representation metadata and a + potentially unbounded stream of representation data. + + An origin server might be provided with, or be capable of generating, + multiple representations that are each intended to reflect the + current state of a target resource. In such cases, some algorithm is + used by the origin server to select one of those representations as + most applicable to a given request, usually based on content + negotiation. This "selected representation" is used to provide the + + + +Fielding & Reschke Standards Track [Page 7] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + data and metadata for evaluating conditional requests [RFC7232] and + constructing the payload for 200 (OK) and 304 (Not Modified) + responses to GET (Section 4.3.1). + +3.1. Representation Metadata + + Representation header fields provide metadata about the + representation. When a message includes a payload body, the + representation header fields describe how to interpret the + representation data enclosed in the payload body. In a response to a + HEAD request, the representation header fields describe the + representation data that would have been enclosed in the payload body + if the same request had been a GET. + + The following header fields convey representation metadata: + + +-------------------+-----------------+ + | Header Field Name | Defined in... | + +-------------------+-----------------+ + | Content-Type | Section 3.1.1.5 | + | Content-Encoding | Section 3.1.2.2 | + | Content-Language | Section 3.1.3.2 | + | Content-Location | Section 3.1.4.2 | + +-------------------+-----------------+ + +3.1.1. Processing Representation Data + +3.1.1.1. Media Type + + HTTP uses Internet media types [RFC2046] in the Content-Type + (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order + to provide open and extensible data typing and type negotiation. + Media types define both a data format and various processing models: + how to process that data in accordance with each context in which it + is received. + + media-type = type "/" subtype *( OWS ";" OWS parameter ) + type = token + subtype = token + + The type/subtype MAY be followed by parameters in the form of + name=value pairs. + + parameter = token "=" ( token / quoted-string ) + + + + + + + +Fielding & Reschke Standards Track [Page 8] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The type, subtype, and parameter name tokens are case-insensitive. + Parameter values might or might not be case-sensitive, depending on + the semantics of the parameter name. 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. + + A parameter value that matches the token production can be + transmitted either as a token or within a quoted-string. The quoted + and unquoted values are equivalent. For example, the following + examples are all equivalent, but the first is preferred for + consistency: + + text/html;charset=utf-8 + text/html;charset=UTF-8 + Text/HTML;Charset="utf-8" + text/html; charset="utf-8" + + Internet media types ought to be registered with IANA according to + the procedures defined in [BCP13]. + + Note: Unlike some similar constructs in other header fields, media + type parameters do not allow whitespace (even "bad" whitespace) + around the "=" character. + +3.1.1.2. Charset + + HTTP uses charset names to indicate or negotiate the character + encoding scheme of a textual representation [RFC6365]. A charset is + identified by a case-insensitive token. + + charset = token + + Charset names ought to be registered in the IANA "Character Sets" + registry () according + to the procedures defined in [RFC2978]. + +3.1.1.3. Canonicalization and Text Defaults + + Internet media types are registered with a canonical form in order to + be interoperable among systems with varying native encoding formats. + Representations selected or transferred via HTTP ought to be in + canonical form, for many of the same reasons described by the + Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the + performance characteristics of email deployments (i.e., store and + forward messages to peers) are significantly different from those + common to HTTP and the Web (server-based information services). + Furthermore, MIME's constraints for the sake of compatibility with + older mail transfer protocols do not apply to HTTP (see Appendix A). + + + +Fielding & Reschke Standards Track [Page 9] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + MIME's canonical form requires that media subtypes of the "text" type + use CRLF as the text line break. HTTP allows the transfer of text + media with plain CR or LF alone representing a line break, when such + line breaks are consistent for an entire representation. An HTTP + sender MAY generate, and a recipient MUST be able to parse, line + breaks in text media that consist of CRLF, bare CR, or bare LF. In + addition, text media in HTTP is not limited to charsets that use + octets 13 and 10 for CR and LF, respectively. This flexibility + regarding line breaks applies only to text within a representation + that has been assigned a "text" media type; it does not apply to + "multipart" types or HTTP elements outside the payload body (e.g., + header fields). + + If a representation is encoded with a content-coding, the underlying + data ought to be in a form defined above prior to being encoded. + +3.1.1.4. Multipart Types + + MIME provides for a number of "multipart" types -- encapsulations of + one or more representations within a single message body. All + multipart types share a common syntax, as defined in Section 5.1.1 of + [RFC2046], and include a boundary parameter as part of the media type + value. The message body is itself a protocol element; a sender MUST + generate only CRLF to represent line breaks between body parts. + + HTTP message framing does not use the multipart boundary as an + indicator of message body length, though it might be used by + implementations that generate or process the payload. For example, + the "multipart/form-data" type is often used for carrying form data + in a request, as described in [RFC2388], and the "multipart/ + byteranges" type is defined by this specification for use in some 206 + (Partial Content) responses [RFC7233]. + +3.1.1.5. Content-Type + + The "Content-Type" header field indicates the media type of the + associated representation: either the representation enclosed in the + message payload or the selected representation, as determined by the + message semantics. The indicated media type defines both the data + format and how that data is intended to be processed by a recipient, + within the scope of the received message semantics, after any content + codings indicated by Content-Encoding are decoded. + + Content-Type = media-type + + + + + + + +Fielding & Reschke Standards Track [Page 10] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Media types are defined in Section 3.1.1.1. An example of the field + is + + Content-Type: text/html; charset=ISO-8859-4 + + A sender that generates a message containing a payload body SHOULD + generate a Content-Type header field in that message unless the + intended media type of the enclosed representation is unknown to the + sender. If a Content-Type header field is not present, the recipient + MAY either assume a media type of "application/octet-stream" + ([RFC2046], Section 4.5.1) or examine the data to determine its type. + + In practice, resource owners do not always properly configure their + origin server to provide the correct Content-Type for a given + representation, with the result that some clients will examine a + payload's content and override the specified type. Clients that do + so risk drawing incorrect conclusions, which might expose additional + security risks (e.g., "privilege escalation"). Furthermore, it is + impossible to determine the sender's intent by examining the data + format: many data formats match multiple media types that differ only + in processing semantics. Implementers are encouraged to provide a + means of disabling such "content sniffing" when it is used. + +3.1.2. Encoding for Compression or Integrity + +3.1.2.1. Content Codings + + Content coding values indicate an encoding transformation that has + been or can be applied to a representation. Content codings are + primarily used to allow a representation to be compressed or + otherwise usefully transformed without losing the identity of its + underlying media type and without loss of information. Frequently, + the representation is stored in coded form, transmitted directly, and + only decoded by the final recipient. + + content-coding = token + + All content-coding values are case-insensitive and ought to be + registered within the "HTTP Content Coding Registry", as defined in + Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) + and Content-Encoding (Section 3.1.2.2) header fields. + + + + + + + + + + +Fielding & Reschke Standards Track [Page 11] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The following content-coding values are defined by this + specification: + + compress (and x-compress): See Section 4.2.1 of [RFC7230]. + + deflate: See Section 4.2.2 of [RFC7230]. + + gzip (and x-gzip): See Section 4.2.3 of [RFC7230]. + +3.1.2.2. Content-Encoding + + The "Content-Encoding" header field indicates what content codings + have been applied to the representation, beyond those inherent in the + media type, and thus what decoding mechanisms have to be applied in + order to obtain data in the media type referenced by the Content-Type + header field. Content-Encoding is primarily used to allow a + representation's data to be compressed without losing the identity of + its underlying media type. + + Content-Encoding = 1#content-coding + + An example of its use is + + Content-Encoding: gzip + + If one or more encodings have been applied to a representation, the + sender that applied the encodings MUST generate a Content-Encoding + header field that lists the content codings in the order in which + they were applied. Additional information about the encoding + parameters can be provided by other header fields not defined by this + specification. + + Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), the codings + listed in Content-Encoding are a characteristic of the + representation; the representation is defined in terms of the coded + form, and all other metadata about the representation is about the + coded form unless otherwise noted in the metadata definition. + Typically, the representation is only decoded just prior to rendering + or analogous usage. + + If the media type includes an inherent encoding, such as a data + format that is always compressed, then that encoding would not be + restated in Content-Encoding even if it happens to be the same + algorithm as one of the content codings. Such a content coding would + only be listed if, for some bizarre reason, it is applied a second + time to form the representation. Likewise, an origin server might + choose to publish the same data as multiple representations that + differ only in whether the coding is defined as part of Content-Type + + + +Fielding & Reschke Standards Track [Page 12] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + or Content-Encoding, since some user agents will behave differently + in their handling of each response (e.g., open a "Save as ..." dialog + instead of automatic decompression and rendering of content). + + An origin server MAY respond with a status code of 415 (Unsupported + Media Type) if a representation in the request message has a content + coding that is not acceptable. + +3.1.3. Audience Language + +3.1.3.1. Language Tags + + A language tag, as defined in [RFC5646], 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 header fields. Accept-Language uses the broader + language-range production defined in Section 5.3.5, whereas + Content-Language uses the language-tag production defined below. + + language-tag = + + A language tag is a sequence of one or more case-insensitive subtags, + each separated by a hyphen character ("-", %x2D). In most cases, a + language tag consists of a primary language subtag that identifies a + broad family of related languages (e.g., "en" = English), which is + optionally followed by a series of subtags that refine or narrow that + language's range (e.g., "en-CA" = the variety of English as + communicated in Canada). Whitespace is not allowed within a language + tag. Example tags include: + + fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN + + See [RFC5646] for further information. + +3.1.3.2. Content-Language + + The "Content-Language" header field describes the natural language(s) + of the intended audience for the representation. Note that this + might not be equivalent to all the languages used within the + representation. + + Content-Language = 1#language-tag + + + + + + +Fielding & Reschke Standards Track [Page 13] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Language tags are defined in Section 3.1.3.1. The primary purpose of + Content-Language is to allow a user to identify and differentiate + representations according to the users' own preferred language. + Thus, if the 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 a + representation 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. + +3.1.4. Identification + +3.1.4.1. Identifying a Representation + + When a complete or partial representation is transferred in a message + payload, it is often desirable for the sender to supply, or the + recipient to determine, an identifier for a resource corresponding to + that representation. + + For a request message: + + o If the request has a Content-Location header field, then the + sender asserts that the payload is a representation of the + resource identified by the Content-Location field-value. However, + such an assertion cannot be trusted unless it can be verified by + other means (not defined by this specification). The information + might still be useful for revision history links. + + + + +Fielding & Reschke Standards Track [Page 14] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o Otherwise, the payload is unidentified. + + For a response message, the following rules are applied in order + until a match is found: + + 1. If the request method is GET or HEAD and the response status code + is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not + Modified), the payload is a representation of the resource + identified by the effective request URI (Section 5.5 of + [RFC7230]). + + 2. If the request method is GET or HEAD and the response status code + is 203 (Non-Authoritative Information), the payload is a + potentially modified or enhanced representation of the target + resource as provided by an intermediary. + + 3. If the response has a Content-Location header field and its + field-value is a reference to the same URI as the effective + request URI, the payload is a representation of the resource + identified by the effective request URI. + + 4. If the response has a Content-Location header field and its + field-value is a reference to a URI different from the effective + request URI, then the sender asserts that the payload is a + representation of the resource identified by the Content-Location + field-value. However, such an assertion cannot be trusted unless + it can be verified by other means (not defined by this + specification). + + 5. Otherwise, the payload is unidentified. + +3.1.4.2. Content-Location + + The "Content-Location" header field references a URI that can be used + as an identifier for a specific resource corresponding to the + representation in this message's payload. In other words, if one + were to perform a GET request on this URI at the time of this + message's generation, then a 200 (OK) response would contain the same + representation that is enclosed as payload in this message. + + Content-Location = absolute-URI / partial-URI + + The Content-Location value is not a replacement for the effective + Request URI (Section 5.5 of [RFC7230]). It is representation + metadata. It has the same syntax and semantics as the header field + of the same name defined for MIME body parts in Section 4 of + [RFC2557]. However, its appearance in an HTTP message has some + special implications for HTTP recipients. + + + +Fielding & Reschke Standards Track [Page 15] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + If Content-Location is included in a 2xx (Successful) response + message and its value refers (after conversion to absolute form) to a + URI that is the same as the effective request URI, then the recipient + MAY consider the payload to be a current representation of that + resource at the time indicated by the message origination date. For + a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the + same as the default semantics when no Content-Location is provided by + the server. For a state-changing request like PUT (Section 4.3.4) or + POST (Section 4.3.3), it implies that the server's response contains + the new representation of that resource, thereby distinguishing it + from representations that might only report about the action (e.g., + "It worked!"). This allows authoring applications to update their + local copies without the need for a subsequent GET request. + + If Content-Location is included in a 2xx (Successful) response + message and its field-value refers to a URI that differs from the + effective request URI, then the origin server claims that the URI is + an identifier for a different resource corresponding to the enclosed + representation. Such a claim can only be trusted if both identifiers + share the same resource owner, which cannot be programmatically + determined via HTTP. + + o For a response to a GET or HEAD request, this is an indication + that the effective request URI refers to a resource that is + subject to content negotiation and the Content-Location + field-value is a more specific identifier for the selected + representation. + + o For a 201 (Created) response to a state-changing method, a + Content-Location field-value that is identical to the Location + field-value indicates that this payload is a current + representation of the newly created resource. + + o Otherwise, such a Content-Location indicates that this payload is + a representation reporting on the requested action's status and + that the same report is available (for future access with GET) at + the given URI. For example, a purchase transaction made via a + POST request might include a receipt document as the payload of + the 200 (OK) response; the Content-Location field-value provides + an identifier for retrieving a copy of that same receipt in the + future. + + A user agent that sends Content-Location in a request message is + stating that its value refers to where the user agent originally + obtained the content of the enclosed representation (prior to any + modifications made by that user agent). In other words, the user + agent is providing a back link to the source of the original + representation. + + + +Fielding & Reschke Standards Track [Page 16] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + An origin server that receives a Content-Location field in a request + message MUST treat the information as transitory request context + rather than as metadata to be saved verbatim as part of the + representation. An origin server MAY use that context to guide in + processing the request or to save it for other uses, such as within + source links or versioning metadata. However, an origin server MUST + NOT use such context information to alter the request semantics. + + For example, if a client makes a PUT request on a negotiated resource + and the origin server accepts that PUT (without redirection), then + the new state of that resource is expected to be consistent with the + one representation supplied in that PUT; the Content-Location cannot + be used as a form of reverse content selection identifier to update + only one of the negotiated representations. If the user agent had + wanted the latter semantics, it would have applied the PUT directly + to the Content-Location URI. + +3.2. Representation Data + + The representation data associated with an HTTP message is either + provided as the payload body of the message or referred to by the + message semantics and the effective request URI. The representation + data is in a format and encoding defined by the representation + metadata header fields. + + The data type of the representation data is determined via the header + fields Content-Type and Content-Encoding. These define a two-layer, + ordered encoding model: + + representation-data := Content-Encoding( Content-Type( bits ) ) + +3.3. Payload Semantics + + Some HTTP messages transfer a complete or partial representation as + the message "payload". In some cases, a payload might contain only + the associated representation's header fields (e.g., responses to + HEAD) or only some part(s) of the representation data (e.g., the 206 + (Partial Content) status code). + + The purpose of a payload in a request is defined by the method + semantics. For example, a representation in the payload of a PUT + request (Section 4.3.4) represents the desired state of the target + resource if the request is successfully applied, whereas a + representation in the payload of a POST request (Section 4.3.3) + represents information to be processed by the target resource. + + + + + + +Fielding & Reschke Standards Track [Page 17] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + In a response, the payload's purpose is defined by both the request + method and the response status code. For example, the payload of a + 200 (OK) response to GET (Section 4.3.1) represents the current state + of the target resource, as observed at the time of the message + origination date (Section 7.1.1.2), whereas the payload of the same + status code in a response to POST might represent either the + processing result or the new state of the target resource after + applying the processing. Response messages with an error status code + usually contain a payload that represents the error condition, such + that it describes the error state and what next steps are suggested + for resolving it. + + Header fields that specifically describe the payload, rather than the + associated representation, are referred to as "payload header + fields". Payload header fields are defined in other parts of this + specification, due to their impact on message parsing. + + +-------------------+----------------------------+ + | Header Field Name | Defined in... | + +-------------------+----------------------------+ + | Content-Length | Section 3.3.2 of [RFC7230] | + | Content-Range | Section 4.2 of [RFC7233] | + | Trailer | Section 4.4 of [RFC7230] | + | Transfer-Encoding | Section 3.3.1 of [RFC7230] | + +-------------------+----------------------------+ + +3.4. Content Negotiation + + When responses convey payload information, whether indicating a + success or an error, the origin server often has different ways of + representing that information; for example, in different formats, + languages, or encodings. Likewise, different users or user agents + might have differing capabilities, characteristics, or preferences + that could influence which representation, among those available, + would be best to deliver. For this reason, HTTP provides mechanisms + for content negotiation. + + This specification defines two patterns of content negotiation that + can be made visible within the protocol: "proactive", where the + server selects the representation based upon the user agent's stated + preferences, and "reactive" negotiation, where the server provides a + list of representations for the user agent to choose from. Other + patterns of content negotiation include "conditional content", where + the representation consists of multiple parts that are selectively + rendered based on user agent parameters, "active content", where the + representation contains a script that makes additional (more + specific) requests based on the user agent characteristics, and + "Transparent Content Negotiation" ([RFC2295]), where content + + + +Fielding & Reschke Standards Track [Page 18] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + selection is performed by an intermediary. These patterns are not + mutually exclusive, and each has trade-offs in applicability and + practicality. + + Note that, in all cases, HTTP is not aware of the resource semantics. + The consistency with which an origin server responds to requests, + over time and over the varying dimensions of content negotiation, and + thus the "sameness" of a resource's observed representations over + time, is determined entirely by whatever entity or algorithm selects + or generates those responses. HTTP pays no attention to the man + behind the curtain. + +3.4.1. Proactive Negotiation + + When content negotiation preferences are sent by the user agent in a + request to encourage an algorithm located at the server to select the + preferred representation, it is called proactive negotiation (a.k.a., + server-driven negotiation). Selection is based on the available + representations for a response (the dimensions over which it might + vary, such as language, content-coding, etc.) compared to various + information supplied in the request, including both the explicit + negotiation fields of Section 5.3 and implicit characteristics, such + as the client's network address or parts of the User-Agent field. + + Proactive negotiation is advantageous when the algorithm for + selecting from among the available representations is difficult to + describe to a user agent, or when the server desires to send its + "best guess" to the user agent 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, a user agent MAY send request header fields that + describe its preferences. + + Proactive negotiation has serious disadvantages: + + o 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?); + + o 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 risk + to the user's privacy; + + o It complicates the implementation of an origin server and the + algorithms for generating responses to a request; and, + + + +Fielding & Reschke Standards Track [Page 19] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o It limits the reusability of responses for shared caching. + + A user agent cannot rely on proactive negotiation preferences being + consistently honored, since the origin server might not implement + proactive negotiation for the requested resource or might decide that + sending a response that doesn't conform to the user agent's + preferences is better than sending a 406 (Not Acceptable) response. + + A Vary header field (Section 7.1.4) is often sent in a response + subject to proactive negotiation to indicate what parts of the + request information were used in the selection algorithm. + +3.4.2. Reactive Negotiation + + With reactive negotiation (a.k.a., agent-driven negotiation), + selection of the best response representation (regardless of the + status code) is performed by the user agent after receiving an + initial response from the origin server that contains a list of + resources for alternative representations. If the user agent is not + satisfied by the initial response representation, it can perform a + GET request on one or more of the alternative resources, selected + based on metadata included in the list, to obtain a different form of + representation for that response. Selection of alternatives might be + performed automatically by the user agent or manually by the user + selecting from a generated (possibly hypertext) menu. + + Note that the above refers to representations of the response, in + general, not representations of the resource. The alternative + representations are only considered representations of the target + resource if the response in which those alternatives are provided has + the semantics of being a representation of the target resource (e.g., + a 200 (OK) response to a GET request) or has the semantics of + providing links to alternative representations for the target + resource (e.g., a 300 (Multiple Choices) response to a GET request). + + A server might choose not to send an initial representation, other + than the list of alternatives, and thereby indicate that reactive + negotiation by the user agent is preferred. For example, the + alternatives listed in responses with the 300 (Multiple Choices) and + 406 (Not Acceptable) status codes include information about the + available representations so that the user or user agent can react by + making a selection. + + Reactive 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 & Reschke Standards Track [Page 20] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Reactive negotiation suffers from the disadvantages of transmitting a + list of alternatives to the user agent, which degrades user-perceived + latency if transmitted in the header section, and needing a second + request to obtain an alternate representation. Furthermore, this + specification does not define a mechanism for supporting automatic + selection, though it does not prevent such a mechanism from being + developed as an extension. + +4. Request Methods + +4.1. Overview + + The request method token is the primary source of request semantics; + it indicates the purpose for which the client has made this request + and what is expected by the client as a successful result. + + The request method's semantics might be further specialized by the + semantics of some header fields when present in a request (Section 5) + if those additional semantics do not conflict with the method. For + example, a client can send conditional request header fields + (Section 5.2) to make the requested action conditional on the current + state of the target resource ([RFC7232]). + + method = token + + HTTP was originally designed to be usable as an interface to + distributed object systems. The request method was envisioned as + applying semantics to a target resource in much the same way as + invoking a defined method on an identified object would apply + semantics. The method token is case-sensitive because it might be + used as a gateway to object-based systems with case-sensitive method + names. + + Unlike distributed objects, the standardized request methods in HTTP + are not resource-specific, since uniform interfaces provide for + better visibility and reuse in network-based systems [REST]. Once + defined, a standardized method ought to have the same semantics when + applied to any resource, though each resource determines for itself + whether those semantics are implemented or allowed. + + This specification defines a number of standardized methods that are + commonly used in HTTP, as outlined by the following table. By + convention, standardized methods are defined in all-uppercase + US-ASCII letters. + + + + + + + +Fielding & Reschke Standards Track [Page 21] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + +---------+-------------------------------------------------+-------+ + | Method | Description | Sec. | + +---------+-------------------------------------------------+-------+ + | GET | Transfer a current representation of the target | 4.3.1 | + | | resource. | | + | HEAD | Same as GET, but only transfer the status line | 4.3.2 | + | | and header section. | | + | POST | Perform resource-specific processing on the | 4.3.3 | + | | request payload. | | + | PUT | Replace all current representations of the | 4.3.4 | + | | target resource with the request payload. | | + | DELETE | Remove all current representations of the | 4.3.5 | + | | target resource. | | + | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | + | | the target resource. | | + | OPTIONS | Describe the communication options for the | 4.3.7 | + | | target resource. | | + | TRACE | Perform a message loop-back test along the path | 4.3.8 | + | | to the target resource. | | + +---------+-------------------------------------------------+-------+ + + All general-purpose servers MUST support the methods GET and HEAD. + All other methods are OPTIONAL. + + Additional methods, outside the scope of this specification, have + been standardized for use in HTTP. All such methods ought to be + registered within the "Hypertext Transfer Protocol (HTTP) Method + Registry" maintained by IANA, as defined in Section 8.1. + + The set of methods allowed by a target resource can be listed in an + Allow header field (Section 7.4.1). However, the set of allowed + methods can change dynamically. When a request method is received + that is unrecognized or not implemented by an origin server, the + origin server SHOULD respond with the 501 (Not Implemented) status + code. When a request method is received that is known by an origin + server but not allowed for the target resource, the origin server + SHOULD respond with the 405 (Method Not Allowed) status code. + +4.2. Common Method Properties + +4.2.1. Safe Methods + + Request methods are considered "safe" if their defined semantics are + essentially read-only; i.e., the client does not request, and does + not expect, any state change on the origin server as a result of + applying a safe method to a target resource. Likewise, reasonable + use of a safe method is not expected to cause any harm, loss of + property, or unusual burden on the origin server. + + + +Fielding & Reschke Standards Track [Page 22] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + This definition of safe methods does not prevent an implementation + from including behavior that is potentially harmful, that is not + entirely read-only, or that causes side effects while invoking a safe + method. What is important, however, is that the client did not + request that additional behavior and cannot be held accountable for + it. For example, most servers append request information to access + log files at the completion of every response, regardless of the + method, and that is considered safe even though the log storage might + become full and crash the server. Likewise, a safe request initiated + by selecting an advertisement on the Web will often have the side + effect of charging an advertising account. + + Of the request methods defined by this specification, the GET, HEAD, + OPTIONS, and TRACE methods are defined to be safe. + + The purpose of distinguishing between safe and unsafe methods is to + allow automated retrieval processes (spiders) and cache performance + optimization (pre-fetching) to work without fear of causing harm. In + addition, it allows a user agent to apply appropriate constraints on + the automated use of unsafe methods when processing potentially + untrusted content. + + A user agent SHOULD distinguish between safe and unsafe methods when + presenting potential actions to a user, such that the user can be + made aware of an unsafe action before it is requested. + + When a resource is constructed such that parameters within the + effective request URI have the effect of selecting an action, it is + the resource owner's responsibility to ensure that the action is + consistent with the request method semantics. For example, it is + common for Web-based content editing software to use actions within + query parameters, such as "page?do=delete". If the purpose of such a + resource is to perform an unsafe action, then the resource owner MUST + disable or disallow that action when it is accessed using a safe + request method. Failure to do so will result in unfortunate side + effects when automated processes perform a GET on every URI reference + for the sake of link maintenance, pre-fetching, building a search + index, etc. + +4.2.2. Idempotent Methods + + A request method is considered "idempotent" if the intended effect on + the server of multiple identical requests with that method is the + same as the effect for a single such request. Of the request methods + defined by this specification, PUT, DELETE, and safe request methods + are idempotent. + + + + + +Fielding & Reschke Standards Track [Page 23] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Like the definition of safe, the idempotent property only applies to + what has been requested by the user; a server is free to log each + request separately, retain a revision control history, or implement + other non-idempotent side effects for each idempotent request. + + Idempotent methods are distinguished because the request can be + repeated automatically if a communication failure occurs before the + client is able to read the server's response. For example, if a + client sends a PUT request and the underlying connection is closed + before any response is received, then the client can establish a new + connection and retry the idempotent request. It knows that repeating + the request will have the same intended effect, even if the original + request succeeded, though the response might differ. + +4.2.3. Cacheable Methods + + Request methods can be defined as "cacheable" to indicate that + responses to them are allowed to be stored for future reuse; for + specific requirements see [RFC7234]. In general, safe methods that + do not depend on a current or authoritative response are defined as + cacheable; this specification defines GET, HEAD, and POST as + cacheable, although the overwhelming majority of cache + implementations only support GET and HEAD. + +4.3. Method Definitions + +4.3.1. GET + + The GET method requests transfer of a current selected representation + for the target resource. GET is the primary mechanism of information + retrieval and the focus of almost all performance optimizations. + Hence, when people speak of retrieving some identifiable information + via HTTP, they are generally referring to making a GET request. + + It is tempting to think of resource identifiers as remote file system + pathnames and of representations as being a copy of the contents of + such files. In fact, that is how many resources are implemented (see + Section 9.1 for related security considerations). However, there are + no such limitations in practice. The HTTP interface for a resource + is just as likely to be implemented as a tree of content objects, a + programmatic view on various database records, or a gateway to other + information systems. Even when the URI mapping mechanism is tied to + a file system, an origin server might be configured to execute the + files with the request as input and send the output as the + representation rather than transfer the files directly. Regardless, + only the origin server needs to know how each of its resource + + + + + +Fielding & Reschke Standards Track [Page 24] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + identifiers corresponds to an implementation and how each + implementation manages to select and send a current representation of + the target resource in a response to GET. + + A client can alter the semantics of GET to be a "range request", + requesting transfer of only some part(s) of the selected + representation, by sending a Range header field in the request + ([RFC7233]). + + A payload within a GET request message has no defined semantics; + sending a payload body on a GET request might cause some existing + implementations to reject the request. + + The response to a GET request is cacheable; a cache MAY use it to + satisfy subsequent GET and HEAD requests unless otherwise indicated + by the Cache-Control header field (Section 5.2 of [RFC7234]). + +4.3.2. HEAD + + The HEAD method is identical to GET except that the server MUST NOT + send a message body in the response (i.e., the response terminates at + the end of the header section). The server SHOULD send the same + header fields in response to a HEAD request as it would have sent if + the request had been a GET, except that the payload header fields + (Section 3.3) MAY be omitted. This method can be used for obtaining + metadata about the selected representation without transferring the + representation data and is often used for testing hypertext links for + validity, accessibility, and recent modification. + + A payload within a HEAD request message has no defined semantics; + sending a payload body on a HEAD request might cause some existing + implementations to reject the request. + + The response to a HEAD request is cacheable; a cache MAY use it to + satisfy subsequent HEAD requests unless otherwise indicated by the + Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD + response might also have an effect on previously cached responses to + GET; see Section 4.3.5 of [RFC7234]. + +4.3.3. POST + + The POST method requests that the target resource process the + representation enclosed in the request according to the resource's + own specific semantics. For example, POST is used for the following + functions (among others): + + o Providing a block of data, such as the fields entered into an HTML + form, to a data-handling process; + + + +Fielding & Reschke Standards Track [Page 25] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o Posting a message to a bulletin board, newsgroup, mailing list, + blog, or similar group of articles; + + o Creating a new resource that has yet to be identified by the + origin server; and + + o Appending data to a resource's existing representation(s). + + An origin server indicates response semantics by choosing an + appropriate status code depending on the result of processing the + POST request; almost all of the status codes defined by this + specification might be received in a response to POST (the exceptions + being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not + Satisfiable)). + + If one or more resources has been created on the origin server as a + result of successfully processing a POST request, the origin server + SHOULD send a 201 (Created) response containing a Location header + field that provides an identifier for the primary resource created + (Section 7.1.2) and a representation that describes the status of the + request while referring to the new resource(s). + + Responses to POST requests are only cacheable when they include + explicit freshness information (see Section 4.2.1 of [RFC7234]). + However, POST caching is not widely implemented. For cases where an + origin server wishes the client to be able to cache the result of a + POST in a way that can be reused by a later GET, the origin server + MAY send a 200 (OK) response containing the result and a + Content-Location header field that has the same value as the POST's + effective request URI (Section 3.1.4.2). + + If the result of processing a POST would be equivalent to a + representation of an existing resource, an origin server MAY redirect + the user agent to that resource by sending a 303 (See Other) response + with the existing resource's identifier in the Location field. This + has the benefits of providing the user agent a resource identifier + and transferring the representation via a method more amenable to + shared caching, though at the cost of an extra request if the user + agent does not already have the representation cached. + +4.3.4. PUT + + The PUT method requests that the state of the target resource be + created or replaced with the state defined by the representation + enclosed in the request message payload. A successful PUT of a given + representation would suggest that a subsequent GET on that same + target resource will result in an equivalent representation being + sent in a 200 (OK) response. However, there is no guarantee that + + + +Fielding & Reschke Standards Track [Page 26] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + such a state change will be observable, since the target resource + might be acted upon by other user agents in parallel, or might be + subject to dynamic processing by the origin server, before any + subsequent GET is received. A successful response only implies that + the user agent's intent was achieved at the time of its processing by + the origin server. + + If the target resource does not have a current representation and the + PUT successfully creates one, then the origin server MUST inform the + user agent by sending a 201 (Created) response. If the target + resource does have a current representation and that representation + is successfully modified in accordance with the state of the enclosed + representation, then the origin server MUST send either a 200 (OK) or + a 204 (No Content) response to indicate successful completion of the + request. + + An origin server SHOULD ignore unrecognized header fields received in + a PUT request (i.e., do not save them as part of the resource state). + + An origin server SHOULD verify that the PUT representation is + consistent with any constraints the server has for the target + resource that cannot or will not be changed by the PUT. This is + particularly important when the origin server uses internal + configuration information related to the URI in order to set the + values for representation metadata on GET responses. When a PUT + representation is inconsistent with the target resource, the origin + server SHOULD either make them consistent, by transforming the + representation or changing the resource configuration, or respond + with an appropriate error message containing sufficient information + to explain why the representation is unsuitable. The 409 (Conflict) + or 415 (Unsupported Media Type) status codes are suggested, with the + latter being specific to constraints on Content-Type values. + + For example, if the target resource is configured to always have a + Content-Type of "text/html" and the representation being PUT has a + Content-Type of "image/jpeg", the origin server ought to do one of: + + a. reconfigure the target resource to reflect the new media type; + + b. transform the PUT representation to a format consistent with that + of the resource before saving it as the new resource state; or, + + c. reject the request with a 415 (Unsupported Media Type) response + indicating that the target resource is limited to "text/html", + perhaps including a link to a different resource that would be a + suitable target for the new representation. + + + + + +Fielding & Reschke Standards Track [Page 27] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + HTTP does not define exactly how a PUT method affects the state of an + origin server beyond what can be expressed by the intent of the user + agent request and the semantics of the origin server response. It + does not define what a resource might be, in any sense of that word, + beyond the interface provided via HTTP. It does not define how + resource state is "stored", nor how such storage might change as a + result of a change in resource state, nor how the origin server + translates resource state into representations. Generally speaking, + all implementation details behind the resource interface are + intentionally hidden by the server. + + An origin server MUST NOT send a validator header field + (Section 7.2), such as an ETag or Last-Modified field, in a + successful response to PUT unless the request's representation data + was saved without any transformation applied to the body (i.e., the + resource's new representation data is identical to the representation + data received in the PUT request) and the validator field value + reflects the new representation. This requirement allows a user + agent to know when the representation body it has in memory remains + current as a result of the PUT, thus not in need of being retrieved + again from the origin server, and that the new validator(s) received + in the response can be used for future conditional requests in order + to prevent accidental overwrites (Section 5.2). + + The fundamental difference between the POST and PUT methods is + highlighted by the different intent for the enclosed representation. + The target resource in a POST request is intended to handle the + enclosed representation according to the resource's own semantics, + whereas the enclosed representation in a PUT request is defined as + replacing the state of the target resource. Hence, the intent of PUT + is idempotent and visible to intermediaries, even though the exact + effect is only known by the origin server. + + Proper interpretation of a PUT request presumes that the user agent + knows which target resource is desired. A service that selects a + proper URI on behalf of the client, after receiving a state-changing + request, SHOULD be implemented using the POST method rather than PUT. + If the origin server will not make the requested PUT state change to + the target resource and instead wishes to have it applied to a + different resource, such as when the resource has been moved to a + different URI, then the origin server MUST send an appropriate 3xx + (Redirection) response; the user agent MAY then make its own decision + regarding whether or not to redirect the request. + + A PUT request applied to the target resource can have side effects on + other resources. For example, an article might have a URI for + identifying "the current version" (a resource) that is separate from + the URIs identifying each particular version (different resources + + + +Fielding & Reschke Standards Track [Page 28] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + that at one point shared the same state as the current version + resource). A successful PUT request on "the current version" URI + might therefore create a new version resource in addition to changing + the state of the target resource, and might also cause links to be + added between the related resources. + + An origin server that allows PUT on a given target resource MUST send + a 400 (Bad Request) response to a PUT request that contains a + Content-Range header field (Section 4.2 of [RFC7233]), since the + payload is likely to be partial content that has been mistakenly PUT + as a full representation. Partial content updates are possible by + targeting a separately identified resource with state that overlaps a + portion of the larger resource, or by using a different method that + has been specifically defined for partial updates (for example, the + PATCH method defined in [RFC5789]). + + Responses to the PUT method are not cacheable. If a successful PUT + request passes through a cache that has one or more stored responses + for the effective request URI, those stored responses will be + invalidated (see Section 4.4 of [RFC7234]). + +4.3.5. DELETE + + The DELETE method requests that the origin server remove the + association between the target resource and its current + functionality. In effect, this method is similar to the rm command + in UNIX: it expresses a deletion operation on the URI mapping of the + origin server rather than an expectation that the previously + associated information be deleted. + + If the target resource has one or more current representations, they + might or might not be destroyed by the origin server, and the + associated storage might or might not be reclaimed, depending + entirely on the nature of the resource and its implementation by the + origin server (which are beyond the scope of this specification). + Likewise, other implementation aspects of a resource might need to be + deactivated or archived as a result of a DELETE, such as database or + gateway connections. In general, it is assumed that the origin + server will only allow DELETE on resources for which it has a + prescribed mechanism for accomplishing the deletion. + + Relatively few resources allow the DELETE method -- its primary use + is for remote authoring environments, where the user has some + direction regarding its effect. For example, a resource that was + previously created using a PUT request, or identified via the + Location header field after a 201 (Created) response to a POST + request, might allow a corresponding DELETE request to undo those + actions. Similarly, custom user agent implementations that implement + + + +Fielding & Reschke Standards Track [Page 29] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + an authoring function, such as revision control clients using HTTP + for remote operations, might use DELETE based on an assumption that + the server's URI space has been crafted to correspond to a version + repository. + + If a DELETE method is successfully applied, the origin server SHOULD + send a 202 (Accepted) status code if the action will likely succeed + but has not yet been enacted, a 204 (No Content) status code if the + action has been enacted and no further information is to be supplied, + or a 200 (OK) status code if the action has been enacted and the + response message includes a representation describing the status. + + A payload within a DELETE request message has no defined semantics; + sending a payload body on a DELETE request might cause some existing + implementations to reject the request. + + Responses to the DELETE method are not cacheable. If a DELETE + request passes through a cache that has one or more stored responses + for the effective request URI, those stored responses will be + invalidated (see Section 4.4 of [RFC7234]). + +4.3.6. CONNECT + + The CONNECT method requests that the recipient establish a tunnel to + the destination origin server identified by the request-target and, + if successful, thereafter restrict its behavior to blind forwarding + of packets, in both directions, until the tunnel is closed. Tunnels + are commonly used to create an end-to-end virtual connection, through + one or more proxies, which can then be secured using TLS (Transport + Layer Security, [RFC5246]). + + CONNECT is intended only for use in requests to a proxy. An origin + server that receives a CONNECT request for itself MAY respond with a + 2xx (Successful) status code to indicate that a connection is + established. However, most origin servers do not implement CONNECT. + + A client sending a CONNECT request MUST send the authority form of + request-target (Section 5.3 of [RFC7230]); i.e., the request-target + consists of only the host name and port number of the tunnel + destination, separated by a colon. For example, + + CONNECT server.example.com:80 HTTP/1.1 + Host: server.example.com:80 + + The recipient proxy can establish a tunnel either by directly + connecting to the request-target or, if configured to use another + proxy, by forwarding the CONNECT request to the next inbound proxy. + Any 2xx (Successful) response indicates that the sender (and all + + + +Fielding & Reschke Standards Track [Page 30] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + inbound proxies) will switch to tunnel mode immediately after the + blank line that concludes the successful response's header section; + data received after that blank line is from the server identified by + the request-target. Any response other than a successful response + indicates that the tunnel has not yet been formed and that the + connection remains governed by HTTP. + + A tunnel is closed when a tunnel intermediary detects that either + side has closed its connection: the intermediary MUST attempt to send + any outstanding data that came from the closed side to the other + side, close both connections, and then discard any remaining data + left undelivered. + + Proxy authentication might be used to establish the authority to + create a tunnel. For example, + + CONNECT server.example.com:80 HTTP/1.1 + Host: server.example.com:80 + Proxy-Authorization: basic aGVsbG86d29ybGQ= + + There are significant risks in establishing a tunnel to arbitrary + servers, particularly when the destination is a well-known or + reserved TCP port that is not intended for Web traffic. For example, + a CONNECT to a request-target of "example.com:25" would suggest that + the proxy connect to the reserved port for SMTP traffic; if allowed, + that could trick the proxy into relaying spam email. Proxies that + support CONNECT SHOULD restrict its use to a limited set of known + ports or a configurable whitelist of safe request targets. + + A server MUST NOT send any Transfer-Encoding or Content-Length header + fields in a 2xx (Successful) response to CONNECT. A client MUST + ignore any Content-Length or Transfer-Encoding header fields received + in a successful response to CONNECT. + + A payload within a CONNECT request message has no defined semantics; + sending a payload body on a CONNECT request might cause some existing + implementations to reject the request. + + Responses to the CONNECT method are not cacheable. + +4.3.7. OPTIONS + + The OPTIONS method requests information about the communication + options available for the target resource, at either the origin + server or an intervening intermediary. This method allows a client + to determine the options and/or requirements associated with a + resource, or the capabilities of a server, without implying a + resource action. + + + +Fielding & Reschke Standards Track [Page 31] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + An OPTIONS request with an asterisk ("*") as the request-target + (Section 5.3 of [RFC7230]) applies 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 conformance (or lack thereof). + + If the request-target is not an asterisk, the OPTIONS request applies + to the options that are available when communicating with the target + resource. + + A server generating a successful response to OPTIONS SHOULD send any + header fields that might indicate optional features implemented by + the server and applicable to the target resource (e.g., Allow), + including potential extensions not defined by this specification. + The response payload, if any, might also describe the communication + options in a machine or human-readable representation. A standard + format for such a representation is not defined by this + specification, but might be defined by future extensions to HTTP. A + server MUST generate a Content-Length field with a value of "0" if no + payload body is to be sent in the response. + + A client MAY send a Max-Forwards header field in an OPTIONS request + to target a specific recipient in the request chain (see + Section 5.1.2). A proxy MUST NOT generate a Max-Forwards header + field while forwarding a request unless that request was received + with a Max-Forwards field. + + A client that generates an OPTIONS request containing a payload body + MUST send a valid Content-Type header field describing the + representation media type. Although this specification does not + define any use for such a payload, future extensions to HTTP might + use the OPTIONS body to make more detailed queries about the target + resource. + + Responses to the OPTIONS method are not cacheable. + +4.3.8. TRACE + + The TRACE method requests a remote, application-level loop-back of + the request message. The final recipient of the request SHOULD + reflect the message received, excluding some fields described below, + back to the client as the message body of a 200 (OK) response with a + Content-Type of "message/http" (Section 8.3.1 of [RFC7230]). The + final recipient is either the origin server or the first server to + receive a Max-Forwards value of zero (0) in the request + (Section 5.1.2). + + + +Fielding & Reschke Standards Track [Page 32] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A client MUST NOT generate header fields in a TRACE request + containing sensitive data that might be disclosed by the response. + For example, it would be foolish for a user agent to send stored user + credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The + final recipient of the request SHOULD exclude any request header + fields that are likely to contain sensitive data when that recipient + generates the response body. + + 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 5.7.1 of + [RFC7230]) 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. + + A client MUST NOT send a message body in a TRACE request. + + Responses to the TRACE method are not cacheable. + +5. Request Header Fields + + A client sends request header fields to provide more information + about the request context, make the request conditional based on the + target resource state, suggest preferred formats for the response, + supply authentication credentials, or modify the expected request + processing. These fields act as request modifiers, similar to the + parameters on a programming language method invocation. + +5.1. Controls + + Controls are request header fields that direct specific handling of + the request. + + +-------------------+--------------------------+ + | Header Field Name | Defined in... | + +-------------------+--------------------------+ + | Cache-Control | Section 5.2 of [RFC7234] | + | Expect | Section 5.1.1 | + | Host | Section 5.4 of [RFC7230] | + | Max-Forwards | Section 5.1.2 | + | Pragma | Section 5.4 of [RFC7234] | + | Range | Section 3.1 of [RFC7233] | + | TE | Section 4.3 of [RFC7230] | + +-------------------+--------------------------+ + + + + + + +Fielding & Reschke Standards Track [Page 33] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +5.1.1. Expect + + The "Expect" header field in a request indicates a certain set of + behaviors (expectations) that need to be supported by the server in + order to properly handle this request. The only such expectation + defined by this specification is 100-continue. + + Expect = "100-continue" + + The Expect field-value is case-insensitive. + + A server that receives an Expect field-value other than 100-continue + MAY respond with a 417 (Expectation Failed) status code to indicate + that the unexpected expectation cannot be met. + + A 100-continue expectation informs recipients that the client is + about to send a (presumably large) message body in this request and + wishes to receive a 100 (Continue) interim response if the + request-line and header fields are not sufficient to cause an + immediate success, redirect, or error response. This allows the + client to wait for an indication that it is worthwhile to send the + message body before actually doing so, which can improve efficiency + when the message body is huge or when the client anticipates that an + error is likely (e.g., when sending a state-changing method, for the + first time, without previously verified authentication credentials). + + For example, a request that begins with + + PUT /somewhere/fun HTTP/1.1 + Host: origin.example.com + Content-Type: video/h264 + Content-Length: 1234567890987 + Expect: 100-continue + + + allows the origin server to immediately respond with an error + message, such as 401 (Unauthorized) or 405 (Method Not Allowed), + before the client starts filling the pipes with an unnecessary data + transfer. + + Requirements for clients: + + o A client MUST NOT generate a 100-continue expectation in a request + that does not include a message body. + + o A client that will wait for a 100 (Continue) response before + sending the request message body MUST send an Expect header field + containing a 100-continue expectation. + + + +Fielding & Reschke Standards Track [Page 34] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o A client that sends a 100-continue expectation is not required to + wait for any specific length of time; such a client MAY proceed to + send the message body even if it has not yet received a response. + Furthermore, since 100 (Continue) responses cannot be sent through + an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an + indefinite period before sending the message body. + + o A client that receives a 417 (Expectation Failed) status code in + response to a request containing a 100-continue expectation SHOULD + repeat that request without a 100-continue expectation, since the + 417 response merely indicates that the response chain does not + support expectations (e.g., it passes through an HTTP/1.0 server). + + Requirements for servers: + + o A server that receives a 100-continue expectation in an HTTP/1.0 + request MUST ignore that expectation. + + o A server MAY omit sending a 100 (Continue) response if it has + already received some or all of the message body for the + corresponding request, or if the framing indicates that there is + no message body. + + o A server that sends a 100 (Continue) response MUST ultimately send + a final status code, once the message body is received and + processed, unless the connection is closed prematurely. + + o A server that responds with a final status code before reading the + entire message body SHOULD indicate in that response whether it + intends to close the connection or continue reading and discarding + the request message (see Section 6.6 of [RFC7230]). + + An origin server MUST, upon receiving an HTTP/1.1 (or later) + request-line and a complete header section that contains a + 100-continue expectation and indicates a request message body will + follow, either send an immediate response with a final status code, + if that status can be determined by examining just the request-line + and header fields, or send an immediate 100 (Continue) response to + encourage the client to send the request's message body. The origin + server MUST NOT wait for the message body before sending the 100 + (Continue) response. + + A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and + a complete header section that contains a 100-continue expectation + and indicates a request message body will follow, either send an + immediate response with a final status code, if that status can be + determined by examining just the request-line and header fields, or + begin forwarding the request toward the origin server by sending a + + + +Fielding & Reschke Standards Track [Page 35] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + corresponding request-line and header section to the next inbound + server. If the proxy believes (from configuration or past + interaction) that the next inbound server only supports HTTP/1.0, the + proxy MAY generate an immediate 100 (Continue) response to encourage + the client to begin sending the message body. + + Note: The Expect header field was added after the original + publication of HTTP/1.1 [RFC2068] as both the means to request an + interim 100 (Continue) response and the general mechanism for + indicating must-understand extensions. However, the extension + mechanism has not been used by clients and the must-understand + requirements have not been implemented by many servers, rendering + the extension mechanism useless. This specification has removed + the extension mechanism in order to simplify the definition and + processing of 100-continue. + +5.1.2. Max-Forwards + + The "Max-Forwards" header field provides a mechanism with the TRACE + (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit + the number of times that the request is forwarded by proxies. This + can be useful when the client is attempting to trace a request that + appears to be failing or looping mid-chain. + + Max-Forwards = 1*DIGIT + + The Max-Forwards value is a decimal integer indicating the remaining + number of times this request message can be forwarded. + + Each intermediary that receives 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 + intermediary MUST NOT forward the request; instead, the intermediary + MUST respond as the final recipient. If the received Max-Forwards + value is greater than zero, the intermediary MUST generate an updated + Max-Forwards field in the forwarded message with a field-value that + is the lesser of a) the received value decremented by one (1) or b) + the recipient's maximum supported value for Max-Forwards. + + A recipient MAY ignore a Max-Forwards header field received with any + other request methods. + +5.2. Conditionals + + The HTTP conditional request header fields [RFC7232] allow a client + to place a precondition on the state of the target resource, so that + the action corresponding to the method semantics will not be applied + if the precondition evaluates to false. Each precondition defined by + + + +Fielding & Reschke Standards Track [Page 36] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + this specification consists of a comparison between a set of + validators obtained from prior representations of the target resource + to the current state of validators for the selected representation + (Section 7.2). Hence, these preconditions evaluate whether the state + of the target resource has changed since a given state known by the + client. The effect of such an evaluation depends on the method + semantics and choice of conditional, as defined in Section 5 of + [RFC7232]. + + +---------------------+--------------------------+ + | Header Field Name | Defined in... | + +---------------------+--------------------------+ + | If-Match | Section 3.1 of [RFC7232] | + | If-None-Match | Section 3.2 of [RFC7232] | + | If-Modified-Since | Section 3.3 of [RFC7232] | + | If-Unmodified-Since | Section 3.4 of [RFC7232] | + | If-Range | Section 3.2 of [RFC7233] | + +---------------------+--------------------------+ + +5.3. Content Negotiation + + The following request header fields are sent by a user agent to + engage in proactive negotiation of the response content, as defined + in Section 3.4.1. The preferences sent in these fields apply to any + content in the response, including representations of the target + resource, representations of error or processing status, and + potentially even the miscellaneous text strings that might appear + within the protocol. + + +-------------------+---------------+ + | Header Field Name | Defined in... | + +-------------------+---------------+ + | Accept | Section 5.3.2 | + | Accept-Charset | Section 5.3.3 | + | Accept-Encoding | Section 5.3.4 | + | Accept-Language | Section 5.3.5 | + +-------------------+---------------+ + +5.3.1. Quality Values + + Many of the request header fields for proactive negotiation use a + common parameter, named "q" (case-insensitive), to assign a relative + "weight" to the preference for that associated kind of content. This + weight is referred to as a "quality value" (or "qvalue") because the + same parameter name is often used within server configurations to + assign a weight to the relative quality of the various + representations that can be selected for a resource. + + + + +Fielding & Reschke Standards Track [Page 37] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The weight is normalized to 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 no "q" parameter is present, + the default weight is 1. + + weight = OWS ";" OWS "q=" qvalue + qvalue = ( "0" [ "." 0*3DIGIT ] ) + / ( "1" [ "." 0*3("0") ] ) + + A sender of qvalue MUST NOT generate more than three digits after the + decimal point. User configuration of these values ought to be + limited in the same fashion. + +5.3.2. Accept + + The "Accept" header field can be used by user agents to specify + response media types that are acceptable. Accept header fields 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 = #( media-range [ accept-params ] ) + + media-range = ( "*/*" + / ( type "/" "*" ) + / ( type "/" subtype ) + ) *( OWS ";" OWS parameter ) + accept-params = weight *( accept-ext ) + accept-ext = OWS ";" OWS 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 can include media type + parameters that are applicable to that range. + + Each media-range might be followed by zero or more applicable media + type parameters (e.g., charset), an optional "q" parameter for + indicating a relative weight (Section 5.3.1), and then zero or more + extension parameters. The "q" parameter is necessary if any + extensions (accept-ext) are present, since it acts as a separator + between the two parameter sets. + + 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 + + + + +Fielding & Reschke Standards Track [Page 38] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 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". + + The example + + Accept: audio/*; q=0.2, audio/basic + + is interpreted as "I prefer audio/basic, but send me any audio type + if it is the best available after an 80% markdown in quality". + + A request without any Accept header field implies that the user agent + will accept any media type in response. If the header field is + present in a request and none of the available representations for + the response have a media type that is listed as acceptable, the + origin server can either honor the header field by sending a 406 (Not + Acceptable) response or disregard the header field by treating the + response as if it is not subject to content negotiation. + + 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 equally preferred media types, but if they do not exist, then + send the text/x-dvi representation, and if that does not exist, send + the text/plain representation". + + 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/plain, text/plain;format=flowed, */* + + have the following precedence: + + 1. text/plain;format=flowed + + 2. text/plain + + 3. text/* + + 4. */* + + The media type quality factor associated with a given type is + determined by finding the media range with the highest precedence + that matches the type. For example, + + + +Fielding & Reschke Standards Track [Page 39] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 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: + + +-------------------+---------------+ + | Media Type | Quality Value | + +-------------------+---------------+ + | 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 might be provided with a default set of quality + values for certain media ranges. However, unless the user agent is a + closed system that cannot interact with other rendering agents, this + default set ought to be configurable by the user. + +5.3.3. Accept-Charset + + The "Accept-Charset" header field can be sent by a user agent to + indicate what charsets are acceptable in textual response content. + This field allows user agents capable of understanding more + comprehensive or special-purpose charsets to signal that capability + to an origin server that is capable of representing information in + those charsets. + + Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) + + Charset names are defined in Section 3.1.1.2. A user agent MAY + associate a quality value with each charset to indicate the user's + relative preference for that charset, as defined in Section 5.3.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 charset that is not mentioned elsewhere in the + Accept-Charset field. If no "*" is present in an Accept-Charset + field, then any charsets not explicitly mentioned in the field are + considered "not acceptable" to the client. + + A request without any Accept-Charset header field implies that the + user agent will accept any charset in response. Most general-purpose + user agents do not send Accept-Charset, unless specifically + + + +Fielding & Reschke Standards Track [Page 40] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + configured to do so, because a detailed list of supported charsets + makes it easier for a server to identify an individual by virtue of + the user agent's request characteristics (Section 9.7). + + If an Accept-Charset header field is present in a request and none of + the available representations for the response has a charset that is + listed as acceptable, the origin server can either honor the header + field, by sending a 406 (Not Acceptable) response, or disregard the + header field by treating the resource as if it is not subject to + content negotiation. + +5.3.4. Accept-Encoding + + The "Accept-Encoding" header field can be used by user agents to + indicate what response content-codings (Section 3.1.2.1) are + acceptable in the response. An "identity" token is used as a synonym + for "no encoding" in order to communicate when no encoding is + preferred. + + Accept-Encoding = #( codings [ weight ] ) + codings = content-coding / "identity" / "*" + + Each codings value MAY be given an associated quality value + representing the preference for that encoding, as defined in + Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field + matches any available content-coding not explicitly listed in the + header field. + + For example, + + 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 request without an Accept-Encoding header field implies that the + user agent has no preferences regarding content-codings. Although + this allows the server to use any content-coding in a response, it + does not imply that the user agent will be able to correctly process + all encodings. + + A server tests whether a content-coding for a given representation is + acceptable using these rules: + + 1. If no Accept-Encoding field is in the request, any content-coding + is considered acceptable by the user agent. + + + + +Fielding & Reschke Standards Track [Page 41] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 2. If the representation has no content-coding, then it is + acceptable by default unless specifically excluded by the + Accept-Encoding field stating either "identity;q=0" or "*;q=0" + without a more specific entry for "identity". + + 3. If the representation's 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 5.3.1, a qvalue of 0 means "not acceptable".) + + 4. If multiple content-codings are acceptable, then the acceptable + content-coding with the highest non-zero qvalue is preferred. + + An Accept-Encoding header field with a combined field-value that is + empty implies that the user agent does not want any content-coding in + response. If an Accept-Encoding header field is present in a request + and none of the available representations for the response have a + content-coding that is listed as acceptable, the origin server SHOULD + send a response without any content-coding. + + Note: Most HTTP/1.0 applications do not recognize or obey qvalues + associated with content-codings. This means that qvalues might + not work and are not permitted with x-gzip or x-compress. + +5.3.5. Accept-Language + + The "Accept-Language" header field can be used by user agents to + indicate the set of natural languages that are preferred in the + response. Language tags are defined in Section 3.1.3.1. + + Accept-Language = 1#( language-range [ weight ] ) + language-range = + + + Each language-range can be given an associated quality value + representing an estimate of the user's preference for the languages + specified by that range, as defined in Section 5.3.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 request without any Accept-Language header field implies that the + user agent will accept any language in response. If the header field + is present in a request and none of the available representations for + the response have a matching language tag, the origin server can + either disregard the header field by treating the response as if it + + + +Fielding & Reschke Standards Track [Page 42] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + is not subject to content negotiation or honor the header field by + sending a 406 (Not Acceptable) response. However, the latter is not + encouraged, as doing so can prevent users from accessing content that + they might be able to use (with translation software, for example). + + Note that some recipients treat the order in which language tags are + listed as an indication of descending priority, particularly for tags + that are assigned equal quality values (no value is the same as q=1). + However, this behavior cannot be relied upon. For consistency and to + maximize interoperability, many user agents assign each language tag + a unique quality value while also listing them in order of decreasing + quality. Additional discussion of language priority lists can be + found in Section 2.3 of [RFC4647]. + + For matching, Section 3 of [RFC4647] defines several matching + schemes. Implementations can offer the most appropriate matching + scheme for their requirements. The "Basic Filtering" scheme + ([RFC4647], Section 3.3.1) is identical to the matching scheme that + was previously defined for HTTP in Section 14.4 of [RFC2616]. + + It might be contrary to the privacy expectations of the user to send + an Accept-Language header field with the complete linguistic + preferences of the user in every request (Section 9.7). + + Since intelligibility is highly dependent on the individual user, + user agents need to allow user control over the linguistic preference + (either through configuration of the user agent itself or by + defaulting to a user controllable system setting). A user agent that + does not provide such control to the user MUST NOT send an + Accept-Language header field. + + Note: User agents ought to provide guidance to users when setting + a preference, since users are rarely familiar with the details of + language matching as described above. For 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 the list for + better matching behavior. + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 43] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +5.4. Authentication Credentials + + Two header fields are used for carrying authentication credentials, + as defined in [RFC7235]. Note that various custom mechanisms for + user authentication use the Cookie header field for this purpose, as + defined in [RFC6265]. + + +---------------------+--------------------------+ + | Header Field Name | Defined in... | + +---------------------+--------------------------+ + | Authorization | Section 4.2 of [RFC7235] | + | Proxy-Authorization | Section 4.4 of [RFC7235] | + +---------------------+--------------------------+ + +5.5. Request Context + + The following request header fields provide additional information + about the request context, including information about the user, user + agent, and resource behind the request. + + +-------------------+---------------+ + | Header Field Name | Defined in... | + +-------------------+---------------+ + | From | Section 5.5.1 | + | Referer | Section 5.5.2 | + | User-Agent | Section 5.5.3 | + +-------------------+---------------+ + +5.5.1. From + + The "From" header field contains an Internet email address for a + human user who controls the requesting user agent. The address ought + to be machine-usable, as defined by "mailbox" in Section 3.4 of + [RFC5322]: + + From = mailbox + + mailbox = + + An example is: + + From: webmaster@example.org + + The From header field is rarely sent by non-robotic user agents. A + user agent SHOULD NOT send a From header field without explicit + configuration by the user, since that might conflict with the user's + privacy interests or their site's security policy. + + + + +Fielding & Reschke Standards Track [Page 44] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A robotic user agent SHOULD send a valid From header field so that + the person responsible for running the robot can be contacted if + problems occur on servers, such as if the robot is sending excessive, + unwanted, or invalid requests. + + A server SHOULD NOT use the From header field for access control or + authentication, since most recipients will assume that the field + value is public information. + +5.5.2. Referer + + The "Referer" [sic] header field allows the user agent to specify a + URI reference for the resource from which the target URI was obtained + (i.e., the "referrer", though the field name is misspelled). A user + agent MUST NOT include the fragment and userinfo components of the + URI reference [RFC3986], if any, when generating the Referer field + value. + + Referer = absolute-URI / partial-URI + + The Referer header field allows servers to generate back-links to + other resources for simple analytics, logging, optimized caching, + etc. It also allows obsolete or mistyped links to be found for + maintenance. Some servers use the Referer header field as a means of + denying links from other sites (so-called "deep linking") or + restricting cross-site request forgery (CSRF), but not all requests + contain it. + + Example: + + Referer: http://www.example.org/hypertext/Overview.html + + If the target URI was obtained from a source that does not have its + own URI (e.g., input from the user keyboard, or an entry within the + user's bookmarks/favorites), the user agent MUST either exclude the + Referer field or send it with a value of "about:blank". + + The Referer field has the potential to reveal information about the + request context or browsing history of the user, which is a privacy + concern if the referring resource's identifier reveals personal + information (such as an account name) or a resource that is supposed + to be confidential (such as behind a firewall or internal to a + secured service). Most general-purpose user agents do not send the + Referer header field when the referring resource is a local "file" or + "data" URI. A user agent MUST NOT send a Referer header field in an + unsecured HTTP request if the referring page was received with a + secure protocol. See Section 9.4 for additional security + considerations. + + + +Fielding & Reschke Standards Track [Page 45] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Some intermediaries have been known to indiscriminately remove + Referer header fields from outgoing requests. This has the + unfortunate side effect of interfering with protection against CSRF + attacks, which can be far more harmful to their users. + Intermediaries and user agent extensions that wish to limit + information disclosure in Referer ought to restrict their changes to + specific edits, such as replacing internal domain names with + pseudonyms or truncating the query and/or path components. An + intermediary SHOULD NOT modify or delete the Referer header field + when the field value shares the same scheme and host as the request + target. + +5.5.3. User-Agent + + The "User-Agent" header field contains information about the user + agent originating the request, which is often used by servers to help + identify the scope of reported interoperability problems, to work + around or tailor responses to avoid particular user agent + limitations, and for analytics regarding browser or operating system + use. A user agent SHOULD send a User-Agent field in each request + unless specifically configured not to do so. + + User-Agent = product *( RWS ( product / comment ) ) + + The User-Agent field-value consists of one or more product + identifiers, each followed by zero or more comments (Section 3.2 of + [RFC7230]), which together identify the user agent software and its + significant subproducts. By convention, the product identifiers are + listed in decreasing order of their significance for identifying the + user agent software. Each product identifier consists of a name and + optional version. + + product = token ["/" product-version] + product-version = token + + A sender SHOULD limit generated product identifiers to what is + necessary to identify the product; a sender MUST NOT generate + advertising or other nonessential information within the product + identifier. A sender SHOULD NOT generate information in + product-version that is not a version identifier (i.e., successive + versions of the same product name ought to differ only in the + product-version portion of the product identifier). + + Example: + + User-Agent: CERN-LineMode/2.15 libwww/2.17b3 + + + + + +Fielding & Reschke Standards Track [Page 46] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A user agent SHOULD NOT generate a User-Agent field containing + needlessly fine-grained detail and SHOULD limit the addition of + subproducts by third parties. Overly long and detailed User-Agent + field values increase request latency and the risk of a user being + identified against their wishes ("fingerprinting"). + + Likewise, implementations are encouraged not to use the product + tokens of other implementations in order to declare compatibility + with them, as this circumvents the purpose of the field. If a user + agent masquerades as a different user agent, recipients can assume + that the user intentionally desires to see responses tailored for + that identified user agent, even if they might not work as well for + the actual user agent being used. + +6. Response Status Codes + + The status-code element is a three-digit integer code giving the + result of the attempt to understand and satisfy the request. + + HTTP status codes are extensible. HTTP clients are not required to + understand the meaning of all registered status codes, though such + understanding is obviously desirable. However, a client MUST + understand the class of any status code, as indicated by the first + digit, and treat an unrecognized status code as being equivalent to + the x00 status code of that class, with the exception that a + recipient MUST NOT cache a response with an unrecognized status code. + + For example, if an unrecognized status code of 471 is received by a + client, the client can assume that there was something wrong with its + request and treat the response as if it had received a 400 (Bad + Request) status code. The response message will usually contain a + representation that explains the status. + + The first digit of the status-code defines the class of response. + The last two digits do not have any categorization role. There are + five values for the first digit: + + o 1xx (Informational): The request was received, continuing process + + o 2xx (Successful): The request was successfully received, + understood, and accepted + + o 3xx (Redirection): Further action needs to be taken in order to + complete the request + + o 4xx (Client Error): The request contains bad syntax or cannot be + fulfilled + + + + +Fielding & Reschke Standards Track [Page 47] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o 5xx (Server Error): The server failed to fulfill an apparently + valid request + +6.1. Overview of Status Codes + + The status codes listed below are defined in this specification, + Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of + [RFC7235]. The reason phrases listed here are only recommendations + -- they can be replaced by local equivalents without affecting the + protocol. + + Responses with status codes that are defined as cacheable by default + (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in + this specification) can be reused by a cache with heuristic + expiration unless otherwise indicated by the method definition or + explicit cache controls [RFC7234]; all other status codes are not + cacheable by default. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 48] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + +------+-------------------------------+--------------------------+ + | Code | Reason-Phrase | Defined in... | + +------+-------------------------------+--------------------------+ + | 100 | Continue | Section 6.2.1 | + | 101 | Switching Protocols | Section 6.2.2 | + | 200 | OK | Section 6.3.1 | + | 201 | Created | Section 6.3.2 | + | 202 | Accepted | Section 6.3.3 | + | 203 | Non-Authoritative Information | Section 6.3.4 | + | 204 | No Content | Section 6.3.5 | + | 205 | Reset Content | Section 6.3.6 | + | 206 | Partial Content | Section 4.1 of [RFC7233] | + | 300 | Multiple Choices | Section 6.4.1 | + | 301 | Moved Permanently | Section 6.4.2 | + | 302 | Found | Section 6.4.3 | + | 303 | See Other | Section 6.4.4 | + | 304 | Not Modified | Section 4.1 of [RFC7232] | + | 305 | Use Proxy | Section 6.4.5 | + | 307 | Temporary Redirect | Section 6.4.7 | + | 400 | Bad Request | Section 6.5.1 | + | 401 | Unauthorized | Section 3.1 of [RFC7235] | + | 402 | Payment Required | Section 6.5.2 | + | 403 | Forbidden | Section 6.5.3 | + | 404 | Not Found | Section 6.5.4 | + | 405 | Method Not Allowed | Section 6.5.5 | + | 406 | Not Acceptable | Section 6.5.6 | + | 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] | + | 408 | Request Timeout | Section 6.5.7 | + | 409 | Conflict | Section 6.5.8 | + | 410 | Gone | Section 6.5.9 | + | 411 | Length Required | Section 6.5.10 | + | 412 | Precondition Failed | Section 4.2 of [RFC7232] | + | 413 | Payload Too Large | Section 6.5.11 | + | 414 | URI Too Long | Section 6.5.12 | + | 415 | Unsupported Media Type | Section 6.5.13 | + | 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] | + | 417 | Expectation Failed | Section 6.5.14 | + | 426 | Upgrade Required | Section 6.5.15 | + | 500 | Internal Server Error | Section 6.6.1 | + | 501 | Not Implemented | Section 6.6.2 | + | 502 | Bad Gateway | Section 6.6.3 | + | 503 | Service Unavailable | Section 6.6.4 | + | 504 | Gateway Timeout | Section 6.6.5 | + | 505 | HTTP Version Not Supported | Section 6.6.6 | + +------+-------------------------------+--------------------------+ + + + + + + +Fielding & Reschke Standards Track [Page 49] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Note that this list is not exhaustive -- it does not include + extension status codes defined in other specifications. The complete + list of status codes is maintained by IANA. See Section 8.2 for + details. + +6.2. Informational 1xx + + The 1xx (Informational) class of status code indicates an interim + response for communicating connection status or request progress + prior to completing the requested action and sending a final + response. 1xx responses are terminated by the first empty line after + the status-line (the empty line signaling the end of the header + section). Since HTTP/1.0 did not define any 1xx status codes, a + server MUST NOT send a 1xx response to an HTTP/1.0 client. + + A client MUST be able to parse one or more 1xx responses received + prior to a final response, even if the client does not expect one. A + user agent MAY ignore unexpected 1xx responses. + + A proxy MUST forward 1xx responses unless the proxy itself requested + the generation of the 1xx response. For example, if a proxy adds an + "Expect: 100-continue" field when it forwards a request, then it need + not forward the corresponding 100 (Continue) response(s). + +6.2.1. 100 Continue + + The 100 (Continue) status code indicates that the initial part of a + request has been received and has not yet been rejected by the + server. The server intends to send a final response after the + request has been fully received and acted upon. + + When the request contains an Expect header field that includes a + 100-continue expectation, the 100 response indicates that the server + wishes to receive the request payload body, as described in + Section 5.1.1. The client ought to continue sending the request and + discard the 100 response. + + If the request did not contain an Expect header field containing the + 100-continue expectation, the client can simply discard this interim + response. + +6.2.2. 101 Switching Protocols + + The 101 (Switching Protocols) status code indicates that the server + understands and is willing to comply with the client's request, via + the Upgrade header field (Section 6.7 of [RFC7230]), for a change in + the application protocol being used on this connection. The server + + + + +Fielding & Reschke Standards Track [Page 50] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + MUST generate an Upgrade header field in the response that indicates + which protocol(s) will be switched to immediately after the empty + line that terminates the 101 response. + + It is assumed that the server will only agree to switch protocols + when it is advantageous to do so. For example, switching to a newer + version of HTTP might be advantageous over older versions, and + switching to a real-time, synchronous protocol might be advantageous + when delivering resources that use such features. + +6.3. Successful 2xx + + The 2xx (Successful) class of status code indicates that the client's + request was successfully received, understood, and accepted. + +6.3.1. 200 OK + + The 200 (OK) status code indicates that the request has succeeded. + The payload sent in a 200 response depends on the request method. + For the methods defined by this specification, the intended meaning + of the payload can be summarized as: + + GET a representation of the target resource; + + HEAD the same representation as GET, but without the representation + data; + + POST a representation of the status of, or results obtained from, + the action; + + PUT, DELETE a representation of the status of the action; + + OPTIONS a representation of the communications options; + + TRACE a representation of the request message as received by the end + server. + + Aside from responses to CONNECT, a 200 response always has a payload, + though an origin server MAY generate a payload body of zero length. + If no payload is desired, an origin server ought to send 204 (No + Content) instead. For CONNECT, no payload is allowed because the + successful result is a tunnel, which begins immediately after the 200 + response header section. + + A 200 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]). + + + + +Fielding & Reschke Standards Track [Page 51] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +6.3.2. 201 Created + + The 201 (Created) status code indicates that the request has been + fulfilled and has resulted in one or more new resources being + created. The primary resource created by the request is identified + by either a Location header field in the response or, if no Location + field is received, by the effective request URI. + + The 201 response payload typically describes and links to the + resource(s) created. See Section 7.2 for a discussion of the meaning + and purpose of validator header fields, such as ETag and + Last-Modified, in a 201 response. + +6.3.3. 202 Accepted + + The 202 (Accepted) status code indicates that 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 in HTTP for re-sending a status code from an asynchronous + operation. + + The 202 response is intentionally noncommittal. 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 representation sent with this + response ought to describe the request's current status and point to + (or embed) a status monitor that can provide the user with an + estimate of when the request will be fulfilled. + +6.3.4. 203 Non-Authoritative Information + + The 203 (Non-Authoritative Information) status code indicates that + the request was successful but the enclosed payload has been modified + from that of the origin server's 200 (OK) response by a transforming + proxy (Section 5.7.2 of [RFC7230]). This status code allows the + proxy to notify recipients when a transformation has been applied, + since that knowledge might impact later decisions regarding the + content. For example, future cache validation requests for the + content might only be applicable along the same request path (through + the same proxies). + + The 203 response is similar to the Warning code of 214 Transformation + Applied (Section 5.5 of [RFC7234]), which has the advantage of being + applicable to responses with any status code. + + + + + +Fielding & Reschke Standards Track [Page 52] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A 203 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]). + +6.3.5. 204 No Content + + The 204 (No Content) status code indicates that the server has + successfully fulfilled the request and that there is no additional + content to send in the response payload body. Metadata in the + response header fields refer to the target resource and its selected + representation after the requested action was applied. + + For example, if a 204 status code is received in response to a PUT + request and the response contains an ETag header field, then the PUT + was successful and the ETag field-value contains the entity-tag for + the new representation of that target resource. + + The 204 response allows a server to indicate that the action has been + successfully applied to the target resource, while implying that the + user agent does not need to traverse away from its current "document + view" (if any). The server assumes that the user agent will provide + some indication of the success to its user, in accord with its own + interface, and apply any new or updated metadata in the response to + its active representation. + + For example, a 204 status code is commonly used with document editing + interfaces corresponding to a "save" action, such that the document + being saved remains available to the user for editing. It is also + frequently used with interfaces that expect automated data transfers + to be prevalent, such as within distributed version control systems. + + A 204 response is terminated by the first empty line after the header + fields because it cannot contain a message body. + + A 204 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]). + +6.3.6. 205 Reset Content + + The 205 (Reset Content) status code indicates that the server has + fulfilled the request and desires that the user agent reset the + "document view", which caused the request to be sent, to its original + state as received from the origin server. + + This response is intended to support a common data entry use case + where the user receives content that supports data entry (a form, + notepad, canvas, etc.), enters or manipulates data in that space, + + + +Fielding & Reschke Standards Track [Page 53] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + causes the entered data to be submitted in a request, and then the + data entry mechanism is reset for the next entry so that the user can + easily initiate another input action. + + Since the 205 status code implies that no additional content will be + provided, a server MUST NOT generate a payload in a 205 response. In + other words, a server MUST do one of the following for a 205 + response: a) indicate a zero-length body for the response by + including a Content-Length header field with a value of 0; b) + indicate a zero-length payload for the response by including a + Transfer-Encoding header field with a value of chunked and a message + body consisting of a single chunk of zero-length; or, c) close the + connection immediately after sending the blank line terminating the + header section. + +6.4. Redirection 3xx + + The 3xx (Redirection) class of status code indicates that further + action needs to be taken by the user agent in order to fulfill the + request. If a Location header field (Section 7.1.2) is provided, the + user agent MAY automatically redirect its request to the URI + referenced by the Location field value, even if the specific status + code is not understood. Automatic redirection needs to done with + care for methods not known to be safe, as defined in Section 4.2.1, + since the user might not wish to redirect an unsafe request. + + There are several types of redirects: + + 1. Redirects that indicate the resource might be available at a + different URI, as provided by the Location field, as in the + status codes 301 (Moved Permanently), 302 (Found), and 307 + (Temporary Redirect). + + 2. Redirection that offers a choice of matching resources, each + capable of representing the original request target, as in the + 300 (Multiple Choices) status code. + + 3. Redirection to a different resource, identified by the Location + field, that can represent an indirect response to the request, as + in the 303 (See Other) status code. + + 4. Redirection to a previously cached result, as in the 304 (Not + Modified) status code. + + Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and + 302 (Found) were defined for the first type of redirect + ([RFC1945], Section 9.3). Early user agents split on whether the + method applied to the redirect target would be the same as the + + + +Fielding & Reschke Standards Track [Page 54] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + original request or would be rewritten as GET. Although HTTP + originally defined the former semantics for 301 and 302 (to match + its original implementation at CERN), and defined 303 (See Other) + to match the latter semantics, prevailing practice gradually + converged on the latter semantics for 301 and 302 as well. The + first revision of HTTP/1.1 added 307 (Temporary Redirect) to + indicate the former semantics without being impacted by divergent + practice. Over 10 years later, most user agents still do method + rewriting for 301 and 302; therefore, this specification makes + that behavior conformant when the original request is POST. + + A client SHOULD detect and intervene in cyclical redirections (i.e., + "infinite" redirection loops). + + Note: An earlier version of this specification recommended a + maximum of five redirections ([RFC2068], Section 10.3). Content + developers need to be aware that some clients might implement such + a fixed limitation. + +6.4.1. 300 Multiple Choices + + The 300 (Multiple Choices) status code indicates that the target + resource has more than one representation, each with its own more + specific identifier, and information about the alternatives is being + provided so that the user (or user agent) can select a preferred + representation by redirecting its request to one or more of those + identifiers. In other words, the server desires that the user agent + engage in reactive negotiation to select the most appropriate + representation(s) for its needs (Section 3.4). + + If the server has a preferred choice, the server SHOULD generate a + Location header field containing a preferred choice's URI reference. + The user agent MAY use the Location field value for automatic + redirection. + + For request methods other than HEAD, the server SHOULD generate a + payload in the 300 response containing a list of representation + metadata and URI reference(s) from which the user or user agent can + choose the one most preferred. The user agent MAY make a selection + from that list automatically if it understands the provided media + type. A specific format for automatic selection is not defined by + this specification because HTTP tries to remain orthogonal to the + definition of its payloads. In practice, the representation is + provided in some easily parsed format believed to be acceptable to + the user agent, as determined by shared design or content + negotiation, or in some commonly accepted hypertext format. + + + + + +Fielding & Reschke Standards Track [Page 55] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A 300 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]). + + Note: The original proposal for the 300 status code defined the + URI header field as providing a list of alternative + representations, such that it would be usable for 200, 300, and + 406 responses and be transferred in responses to the HEAD method. + However, lack of deployment and disagreement over syntax led to + both URI and Alternates (a subsequent proposal) being dropped from + this specification. It is possible to communicate the list using + a set of Link header fields [RFC5988], each with a relationship of + "alternate", though deployment is a chicken-and-egg problem. + +6.4.2. 301 Moved Permanently + + The 301 (Moved Permanently) status code indicates that the target + resource has been assigned a new permanent URI and any future + references to this resource ought to use one of the enclosed URIs. + Clients with link-editing capabilities ought to automatically re-link + references to the effective request URI to one or more of the new + references sent by the server, where possible. + + The server SHOULD generate a Location header field in the response + containing a preferred URI reference for the new permanent URI. The + user agent MAY use the Location field value for automatic + redirection. The server's response payload usually contains a short + hypertext note with a hyperlink to the new URI(s). + + Note: For historical reasons, a user agent MAY change the request + method from POST to GET for the subsequent request. If this + behavior is undesired, the 307 (Temporary Redirect) status code + can be used instead. + + A 301 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]). + +6.4.3. 302 Found + + The 302 (Found) status code indicates that the target resource + resides temporarily under a different URI. Since the redirection + might be altered on occasion, the client ought to continue to use the + effective request URI for future requests. + + + + + + + +Fielding & Reschke Standards Track [Page 56] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The server SHOULD generate a Location header field in the response + containing a URI reference for the different URI. The user agent MAY + use the Location field value for automatic redirection. The server's + response payload usually contains a short hypertext note with a + hyperlink to the different URI(s). + + Note: For historical reasons, a user agent MAY change the request + method from POST to GET for the subsequent request. If this + behavior is undesired, the 307 (Temporary Redirect) status code + can be used instead. + +6.4.4. 303 See Other + + The 303 (See Other) status code indicates that the server is + redirecting the user agent to a different resource, as indicated by a + URI in the Location header field, which is intended to provide an + indirect response to the original request. A user agent can perform + a retrieval request targeting that URI (a GET or HEAD request if + using HTTP), which might also be redirected, and present the eventual + result as an answer to the original request. Note that the new URI + in the Location header field is not considered equivalent to the + effective request URI. + + This status code is applicable to any HTTP method. It is primarily + used to allow the output of a POST action to redirect the user agent + to a selected resource, since doing so provides the information + corresponding to the POST response in a form that can be separately + identified, bookmarked, and cached, independent of the original + request. + + A 303 response to a GET request indicates that the origin server does + not have a representation of the target resource that can be + transferred by the server over HTTP. However, the Location field + value refers to a resource that is descriptive of the target + resource, such that making a retrieval request on that other resource + might result in a representation that is useful to recipients without + implying that it represents the original target resource. Note that + answers to the questions of what can be represented, what + representations are adequate, and what might be a useful description + are outside the scope of HTTP. + + Except for responses to a HEAD request, the representation of a 303 + response ought to contain a short hypertext note with a hyperlink to + the same URI reference provided in the Location header field. + + + + + + + +Fielding & Reschke Standards Track [Page 57] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +6.4.5. 305 Use Proxy + + The 305 (Use Proxy) status code was defined in a previous version of + this specification and is now deprecated (Appendix B). + +6.4.6. 306 (Unused) + + The 306 status code was defined in a previous version of this + specification, is no longer used, and the code is reserved. + +6.4.7. 307 Temporary Redirect + + The 307 (Temporary Redirect) status code indicates that the target + resource resides temporarily under a different URI and the user agent + MUST NOT change the request method if it performs an automatic + redirection to that URI. Since the redirection can change over time, + the client ought to continue using the original effective request URI + for future requests. + + The server SHOULD generate a Location header field in the response + containing a URI reference for the different URI. The user agent MAY + use the Location field value for automatic redirection. The server's + response payload usually contains a short hypertext note with a + hyperlink to the different URI(s). + + Note: This status code is similar to 302 (Found), except that it + does not allow changing the request method from POST to GET. This + specification defines no equivalent counterpart for 301 (Moved + Permanently) ([RFC7238], however, defines the status code 308 + (Permanent Redirect) for this purpose). + +6.5. Client Error 4xx + + The 4xx (Client Error) class of status code indicates that the client + seems to have erred. Except when responding to a HEAD request, the + server SHOULD send a representation 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 representation to the user. + +6.5.1. 400 Bad Request + + The 400 (Bad Request) status code indicates that the server cannot or + will not process the request due to something that is perceived to be + a client error (e.g., malformed request syntax, invalid request + message framing, or deceptive request routing). + + + + + +Fielding & Reschke Standards Track [Page 58] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +6.5.2. 402 Payment Required + + The 402 (Payment Required) status code is reserved for future use. + +6.5.3. 403 Forbidden + + The 403 (Forbidden) status code indicates that the server understood + the request but refuses to authorize it. A server that wishes to + make public why the request has been forbidden can describe that + reason in the response payload (if any). + + If authentication credentials were provided in the request, the + server considers them insufficient to grant access. The client + SHOULD NOT automatically repeat the request with the same + credentials. The client MAY repeat the request with new or different + credentials. However, a request might be forbidden for reasons + unrelated to the credentials. + + An origin server that wishes to "hide" the current existence of a + forbidden target resource MAY instead respond with a status code of + 404 (Not Found). + +6.5.4. 404 Not Found + + The 404 (Not Found) status code indicates that the origin server did + not find a current representation for the target resource or is not + willing to disclose that one exists. A 404 status code does not + indicate whether this lack of representation is temporary or + permanent; the 410 (Gone) status code is preferred over 404 if the + origin server knows, presumably through some configurable means, that + the condition is likely to be permanent. + + A 404 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]). + +6.5.5. 405 Method Not Allowed + + The 405 (Method Not Allowed) status code indicates that the method + received in the request-line is known by the origin server but not + supported by the target resource. The origin server MUST generate an + Allow header field in a 405 response containing a list of the target + resource's currently supported methods. + + A 405 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]). + + + + +Fielding & Reschke Standards Track [Page 59] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +6.5.6. 406 Not Acceptable + + The 406 (Not Acceptable) status code indicates that the target + resource does not have a current representation that would be + acceptable to the user agent, according to the proactive negotiation + header fields received in the request (Section 5.3), and the server + is unwilling to supply a default representation. + + The server SHOULD generate a payload containing a list of available + representation characteristics and corresponding resource identifiers + from which the user or user agent can choose the one most + appropriate. A user agent MAY automatically select the most + appropriate choice from that list. However, this specification does + not define any standard for such automatic selection, as described in + Section 6.4.1. + +6.5.7. 408 Request Timeout + + The 408 (Request Timeout) status code indicates that the server did + not receive a complete request message within the time that it was + prepared to wait. A server SHOULD send the "close" connection option + (Section 6.1 of [RFC7230]) in the response, since 408 implies that + the server has decided to close the connection rather than continue + waiting. If the client has an outstanding request in transit, the + client MAY repeat that request on a new connection. + +6.5.8. 409 Conflict + + The 409 (Conflict) status code indicates that the request could not + be completed due to a conflict with the current state of the target + resource. This code is used in situations where the user might be + able to resolve the conflict and resubmit the request. The server + SHOULD generate a payload that includes enough information for a user + to recognize the source of the conflict. + + Conflicts are most likely to occur in response to a PUT request. For + example, if versioning were being used and the representation being + PUT included changes to a resource that conflict with those made by + an earlier (third-party) request, the origin server might use a 409 + response to indicate that it can't complete the request. In this + case, the response representation would likely contain information + useful for merging the differences based on the revision history. + +6.5.9. 410 Gone + + The 410 (Gone) status code indicates that access to the target + resource is no longer available at the origin server and that this + condition is likely to be permanent. If the origin server does not + + + +Fielding & Reschke Standards Track [Page 60] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + know, or has no facility to determine, whether or not the condition + is permanent, the status code 404 (Not Found) ought to be used + instead. + + 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 associated with the origin 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. + + A 410 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]). + +6.5.10. 411 Length Required + + The 411 (Length Required) status code indicates that the server + refuses to accept the request without a defined Content-Length + (Section 3.3.2 of [RFC7230]). 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. + +6.5.11. 413 Payload Too Large + + The 413 (Payload Too Large) status code indicates that the server is + refusing to process a request because the request payload 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 generate a + Retry-After header field to indicate that it is temporary and after + what time the client MAY try again. + +6.5.12. 414 URI Too Long + + The 414 (URI Too Long) status code indicates that the server is + refusing to service the request because the request-target (Section + 5.3 of [RFC7230]) 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 "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 potential security holes. + + + +Fielding & Reschke Standards Track [Page 61] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A 414 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]). + +6.5.13. 415 Unsupported Media Type + + The 415 (Unsupported Media Type) status code indicates that the + origin server is refusing to service the request because the payload + is in a format not supported by this method on the target resource. + The format problem might be due to the request's indicated + Content-Type or Content-Encoding, or as a result of inspecting the + data directly. + +6.5.14. 417 Expectation Failed + + The 417 (Expectation Failed) status code indicates that the + expectation given in the request's Expect header field + (Section 5.1.1) could not be met by at least one of the inbound + servers. + +6.5.15. 426 Upgrade Required + + The 426 (Upgrade Required) status code indicates that the server + refuses to perform the request using the current protocol but might + be willing to do so after the client upgrades to a different + protocol. The server MUST send an Upgrade header field in a 426 + response to indicate the required protocol(s) (Section 6.7 of + [RFC7230]). + + Example: + + HTTP/1.1 426 Upgrade Required + Upgrade: HTTP/3.0 + Connection: Upgrade + Content-Length: 53 + Content-Type: text/plain + + This service requires use of the HTTP/3.0 protocol. + +6.6. Server Error 5xx + + The 5xx (Server Error) class of status code indicates that the server + is aware that it has erred or is incapable of performing the + requested method. Except when responding to a HEAD request, the + server SHOULD send a representation containing an explanation of the + error situation, and whether it is a temporary or permanent + + + + + +Fielding & Reschke Standards Track [Page 62] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + condition. A user agent SHOULD display any included representation + to the user. These response codes are applicable to any request + method. + +6.6.1. 500 Internal Server Error + + The 500 (Internal Server Error) status code indicates that the server + encountered an unexpected condition that prevented it from fulfilling + the request. + +6.6.2. 501 Not Implemented + + The 501 (Not Implemented) status code indicates that 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. + + A 501 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]). + +6.6.3. 502 Bad Gateway + + The 502 (Bad Gateway) status code indicates that the server, while + acting as a gateway or proxy, received an invalid response from an + inbound server it accessed while attempting to fulfill the request. + +6.6.4. 503 Service Unavailable + + The 503 (Service Unavailable) status code indicates that the server + is currently unable to handle the request due to a temporary overload + or scheduled maintenance, which will likely be alleviated after some + delay. The server MAY send a Retry-After header field + (Section 7.1.3) to suggest an appropriate amount of time for the + client to wait before retrying the request. + + Note: The existence of the 503 status code does not imply that a + server has to use it when becoming overloaded. Some servers might + simply refuse the connection. + +6.6.5. 504 Gateway Timeout + + The 504 (Gateway Timeout) status code indicates that the server, + while acting as a gateway or proxy, did not receive a timely response + from an upstream server it needed to access in order to complete the + request. + + + + + +Fielding & Reschke Standards Track [Page 63] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +6.6.6. 505 HTTP Version Not Supported + + The 505 (HTTP Version Not Supported) status code indicates that the + server does not support, or refuses to support, the major version of + HTTP 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 2.6 of + [RFC7230], other than with this error message. The server SHOULD + generate a representation for the 505 response that describes why + that version is not supported and what other protocols are supported + by that server. + +7. Response Header Fields + + The response header fields allow the server to pass additional + information about the response beyond what is placed in the + status-line. These header fields give information about the server, + about further access to the target resource, or about related + resources. + + Although each response header field has a defined meaning, in + general, the precise semantics might be further refined by the + semantics of the request method and/or response status code. + +7.1. Control Data + + Response header fields can supply control data that supplements the + status code, directs caching, or instructs the client where to go + next. + + +-------------------+--------------------------+ + | Header Field Name | Defined in... | + +-------------------+--------------------------+ + | Age | Section 5.1 of [RFC7234] | + | Cache-Control | Section 5.2 of [RFC7234] | + | Expires | Section 5.3 of [RFC7234] | + | Date | Section 7.1.1.2 | + | Location | Section 7.1.2 | + | Retry-After | Section 7.1.3 | + | Vary | Section 7.1.4 | + | Warning | Section 5.5 of [RFC7234] | + +-------------------+--------------------------+ + + + + + + + + + +Fielding & Reschke Standards Track [Page 64] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +7.1.1. Origination Date + +7.1.1.1. Date/Time Formats + + Prior to 1995, there were three different formats commonly used by + servers to communicate timestamps. For compatibility with old + implementations, all three are defined here. The preferred format is + a fixed-length and single-zone subset of the date and time + specification used by the Internet Message Format [RFC5322]. + + HTTP-date = IMF-fixdate / obs-date + + An example of the preferred format is + + Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate + + Examples of the two obsolete formats are + + Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format + Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format + + A recipient that parses a timestamp value in an HTTP header field + MUST accept all three HTTP-date formats. When a sender generates a + header field that contains one or more timestamps defined as + HTTP-date, the sender MUST generate those timestamps in the + IMF-fixdate format. + + An HTTP-date value represents time as an instance of Coordinated + Universal Time (UTC). The first two formats indicate UTC by the + three-letter abbreviation for Greenwich Mean Time, "GMT", a + predecessor of the UTC name; values in the asctime format are assumed + to be in UTC. A sender that generates HTTP-date values from a local + clock ought to use NTP ([RFC5905]) or some similar protocol to + synchronize its clock to UTC. + + Preferred format: + + IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT + ; fixed length/zone/capitalization subset of the format + ; see Section 3.3 of [RFC5322] + + day-name = %x4D.6F.6E ; "Mon", case-sensitive + / %x54.75.65 ; "Tue", case-sensitive + / %x57.65.64 ; "Wed", case-sensitive + / %x54.68.75 ; "Thu", case-sensitive + / %x46.72.69 ; "Fri", case-sensitive + / %x53.61.74 ; "Sat", case-sensitive + / %x53.75.6E ; "Sun", case-sensitive + + + +Fielding & Reschke Standards Track [Page 65] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + date1 = day SP month SP year + ; e.g., 02 Jun 1982 + + day = 2DIGIT + month = %x4A.61.6E ; "Jan", case-sensitive + / %x46.65.62 ; "Feb", case-sensitive + / %x4D.61.72 ; "Mar", case-sensitive + / %x41.70.72 ; "Apr", case-sensitive + / %x4D.61.79 ; "May", case-sensitive + / %x4A.75.6E ; "Jun", case-sensitive + / %x4A.75.6C ; "Jul", case-sensitive + / %x41.75.67 ; "Aug", case-sensitive + / %x53.65.70 ; "Sep", case-sensitive + / %x4F.63.74 ; "Oct", case-sensitive + / %x4E.6F.76 ; "Nov", case-sensitive + / %x44.65.63 ; "Dec", case-sensitive + year = 4DIGIT + + GMT = %x47.4D.54 ; "GMT", case-sensitive + + time-of-day = hour ":" minute ":" second + ; 00:00:00 - 23:59:60 (leap second) + + hour = 2DIGIT + minute = 2DIGIT + second = 2DIGIT + + Obsolete formats: + + obs-date = rfc850-date / asctime-date + + rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT + date2 = day "-" month "-" 2DIGIT + ; e.g., 02-Jun-82 + + day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive + / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive + / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive + / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive + / %x46.72.69.64.61.79 ; "Friday", case-sensitive + / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive + / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive + + + asctime-date = day-name SP date3 SP time-of-day SP year + date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) + ; e.g., Jun 2 + + + + +Fielding & Reschke Standards Track [Page 66] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + HTTP-date is case sensitive. A sender MUST NOT generate additional + whitespace in an HTTP-date beyond that specifically included as SP in + the grammar. The semantics of day-name, day, month, year, and + time-of-day are the same as those defined for the Internet Message + Format constructs with the corresponding name ([RFC5322], Section + 3.3). + + Recipients of a timestamp value in rfc850-date format, which uses a + two-digit year, MUST interpret a timestamp that appears to be more + than 50 years in the future as representing the most recent year in + the past that had the same last two digits. + + Recipients of timestamp values are encouraged to be robust in parsing + timestamps unless otherwise restricted by the field definition. For + example, messages are occasionally forwarded over HTTP from a + non-HTTP source that might generate any of the date and time + specifications defined by the Internet Message Format. + + Note: HTTP requirements for the date/time stamp format apply only + to their usage within the protocol stream. Implementations are + not required to use these formats for user presentation, request + logging, etc. + +7.1.1.2. Date + + The "Date" header field represents the date and time at which the + message was originated, having the same semantics as the Origination + Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The + field value is an HTTP-date, as defined in Section 7.1.1.1. + + Date = HTTP-date + + An example is + + Date: Tue, 15 Nov 1994 08:12:31 GMT + + When a Date header field is generated, the sender SHOULD generate its + field value as the best available approximation of the date and time + of message generation. In theory, the date ought to represent the + moment just before the payload is generated. In practice, the date + can be generated at any time during message origination. + + An origin server MUST NOT send a Date header field if it does not + have a clock capable of providing a reasonable approximation of the + current instance in Coordinated Universal Time. An origin server MAY + send a Date header field if the response is in the 1xx + (Informational) or 5xx (Server Error) class of status codes. An + origin server MUST send a Date header field in all other cases. + + + +Fielding & Reschke Standards Track [Page 67] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + A recipient with a clock that receives a response message without a + Date header field MUST record the time it was received and append a + corresponding Date header field to the message's header section if it + is cached or forwarded downstream. + + A user agent MAY send a Date header field in a request, though + generally will not do so unless it is believed to convey useful + information to the server. For example, custom applications of HTTP + might convey a Date if the server is expected to adjust its + interpretation of the user's request based on differences between the + user agent and server clocks. + +7.1.2. Location + + The "Location" header field is used in some responses to refer to a + specific resource in relation to the response. The type of + relationship is defined by the combination of request method and + status code semantics. + + Location = URI-reference + + The field value consists of a single URI-reference. When it has the + form of a relative reference ([RFC3986], Section 4.2), the final + value is computed by resolving it against the effective request URI + ([RFC3986], Section 5). + + For 201 (Created) responses, the Location value refers to the primary + resource created by the request. For 3xx (Redirection) responses, + the Location value refers to the preferred target resource for + automatically redirecting the request. + + If the Location value provided in a 3xx (Redirection) response does + not have a fragment component, a user agent MUST process the + redirection as if the value inherits the fragment component of the + URI reference used to generate the request target (i.e., the + redirection inherits the original reference's fragment, if any). + + For example, a GET request generated for the URI reference + "http://www.example.org/~tim" might result in a 303 (See Other) + response containing the header field: + + Location: /People.html#tim + + which suggests that the user agent redirect to + "http://www.example.org/People.html#tim" + + + + + + +Fielding & Reschke Standards Track [Page 68] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Likewise, a GET request generated for the URI reference + "http://www.example.org/index.html#larry" might result in a 301 + (Moved Permanently) response containing the header field: + + Location: http://www.example.net/index.html + + which suggests that the user agent redirect to + "http://www.example.net/index.html#larry", preserving the original + fragment identifier. + + There are circumstances in which a fragment identifier in a Location + value would not be appropriate. For example, the Location header + field in a 201 (Created) response is supposed to provide a URI that + is specific to the created resource. + + Note: Some recipients attempt to recover from Location fields that + are not valid URI references. This specification does not mandate + or define such processing, but does allow it for the sake of + robustness. + + Note: The Content-Location header field (Section 3.1.4.2) differs + from Location in that the Content-Location refers to the most + specific resource corresponding to the enclosed representation. + It is therefore possible for a response to contain both the + Location and Content-Location header fields. + +7.1.3. Retry-After + + Servers send the "Retry-After" header field to indicate how long the + user agent ought to wait before making a follow-up request. When + sent with a 503 (Service Unavailable) response, Retry-After indicates + how long the service is expected to be unavailable to the client. + When sent with any 3xx (Redirection) response, Retry-After indicates + the minimum time that the user agent is asked to wait before issuing + the redirected request. + + The value of this field can be either an HTTP-date or a number of + seconds to delay after the response is received. + + Retry-After = HTTP-date / delay-seconds + + A delay-seconds value is a non-negative decimal integer, representing + time in seconds. + + delay-seconds = 1*DIGIT + + + + + + +Fielding & Reschke Standards Track [Page 69] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 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. + +7.1.4. Vary + + The "Vary" header field in a response describes what parts of a + request message, aside from the method, Host header field, and + request target, might influence the origin server's process for + selecting and representing this response. The value consists of + either a single asterisk ("*") or a list of header field names + (case-insensitive). + + Vary = "*" / 1#field-name + + A Vary field value of "*" signals that anything about the request + might play a role in selecting the response representation, possibly + including elements outside the message syntax (e.g., the client's + network address). A recipient will not be able to determine whether + this response is appropriate for a later request without forwarding + the request to the origin server. A proxy MUST NOT generate a Vary + field with a "*" value. + + A Vary field value consisting of a comma-separated list of names + indicates that the named request header fields, known as the + selecting header fields, might have a role in selecting the + representation. The potential selecting header fields are not + limited to those defined by this specification. + + For example, a response that contains + + Vary: accept-encoding, accept-language + + indicates that the origin server might have used the request's + Accept-Encoding and Accept-Language fields (or lack thereof) as + determining factors while choosing the content for this response. + + An origin server might send Vary with a list of fields for two + purposes: + + 1. To inform cache recipients that they MUST NOT use this response + to satisfy a later request unless the later request has the same + values for the listed fields as the original request (Section 4.1 + of [RFC7234]). In other words, Vary expands the cache key + required to match a new request to the stored cache entry. + + + +Fielding & Reschke Standards Track [Page 70] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 2. To inform user agent recipients that this response is subject to + content negotiation (Section 5.3) and that a different + representation might be sent in a subsequent request if + additional parameters are provided in the listed header fields + (proactive negotiation). + + An origin server SHOULD send a Vary header field when its algorithm + for selecting a representation varies based on aspects of the request + message other than the method and request target, unless the variance + cannot be crossed or the origin server has been deliberately + configured to prevent cache transparency. For example, there is no + need to send the Authorization field name in Vary because reuse + across users is constrained by the field definition (Section 4.2 of + [RFC7235]). Likewise, an origin server might use Cache-Control + directives (Section 5.2 of [RFC7234]) to supplant Vary if it + considers the variance less significant than the performance cost of + Vary's impact on caching. + +7.2. Validator Header Fields + + Validator header fields convey metadata about the selected + representation (Section 3). In responses to safe requests, validator + fields describe the selected representation chosen by the origin + server while handling the response. Note that, depending on the + status code semantics, the selected representation for a given + response is not necessarily the same as the representation enclosed + as response payload. + + In a successful response to a state-changing request, validator + fields describe the new representation that has replaced the prior + selected representation as a result of processing the request. + + For example, an ETag header field in a 201 (Created) response + communicates the entity-tag of the newly created resource's + representation, so that it can be used in later conditional requests + to prevent the "lost update" problem [RFC7232]. + + +-------------------+--------------------------+ + | Header Field Name | Defined in... | + +-------------------+--------------------------+ + | ETag | Section 2.3 of [RFC7232] | + | Last-Modified | Section 2.2 of [RFC7232] | + +-------------------+--------------------------+ + + + + + + + + +Fielding & Reschke Standards Track [Page 71] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +7.3. Authentication Challenges + + Authentication challenges indicate what mechanisms are available for + the client to provide authentication credentials in future requests. + + +--------------------+--------------------------+ + | Header Field Name | Defined in... | + +--------------------+--------------------------+ + | WWW-Authenticate | Section 4.1 of [RFC7235] | + | Proxy-Authenticate | Section 4.3 of [RFC7235] | + +--------------------+--------------------------+ + +7.4. Response Context + + The remaining response header fields provide more information about + the target resource for potential use in later requests. + + +-------------------+--------------------------+ + | Header Field Name | Defined in... | + +-------------------+--------------------------+ + | Accept-Ranges | Section 2.3 of [RFC7233] | + | Allow | Section 7.4.1 | + | Server | Section 7.4.2 | + +-------------------+--------------------------+ + +7.4.1. Allow + + The "Allow" header field lists the set of methods advertised as + supported by the target resource. The purpose of this field is + strictly to inform the recipient of valid request methods associated + with the resource. + + Allow = #method + + Example of use: + + Allow: GET, HEAD, PUT + + The actual set of allowed methods is defined by the origin server at + the time of each request. An origin server MUST generate an Allow + field in a 405 (Method Not Allowed) response and MAY do so in any + other response. An empty Allow field value indicates that the + resource allows no methods, which might occur in a 405 response if + the resource has been temporarily disabled by configuration. + + A proxy MUST NOT modify the Allow header field -- it does not need to + understand all of the indicated methods in order to handle them + according to the generic message handling rules. + + + +Fielding & Reschke Standards Track [Page 72] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +7.4.2. Server + + The "Server" header field contains information about the software + used by the origin server to handle the request, which is often used + by clients to help identify the scope of reported interoperability + problems, to work around or tailor requests to avoid particular + server limitations, and for analytics regarding server or operating + system use. An origin server MAY generate a Server field in its + responses. + + Server = product *( RWS ( product / comment ) ) + + The Server field-value consists of one or more product identifiers, + each followed by zero or more comments (Section 3.2 of [RFC7230]), + which together identify the origin server software and its + significant subproducts. By convention, the product identifiers are + listed in decreasing order of their significance for identifying the + origin server software. Each product identifier consists of a name + and optional version, as defined in Section 5.5.3. + + Example: + + Server: CERN/3.0 libwww/2.17 + + An origin server SHOULD NOT generate a Server field containing + needlessly fine-grained detail and SHOULD limit the addition of + subproducts by third parties. Overly long and detailed Server field + values increase response latency and potentially reveal internal + implementation details that might make it (slightly) easier for + attackers to find and exploit known security holes. + +8. IANA Considerations + +8.1. Method Registry + + The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the + namespace for the request method token (Section 4). The method + registry has been created and is now maintained at + . + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 73] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +8.1.1. Procedure + + HTTP method registrations MUST include the following fields: + + o Method Name (see Section 4) + + o Safe ("yes" or "no", see Section 4.2.1) + + o Idempotent ("yes" or "no", see Section 4.2.2) + + o Pointer to specification text + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + +8.1.2. Considerations for New Methods + + Standardized methods are generic; that is, they are potentially + applicable to any resource, not just one particular media type, kind + of resource, or application. As such, it is preferred that new + methods be registered in a document that isn't specific to a single + application or data format, since orthogonal technologies deserve + orthogonal specification. + + Since message parsing (Section 3.3 of [RFC7230]) needs to be + independent of method semantics (aside from responses to HEAD), + definitions of new methods cannot change the parsing algorithm or + prohibit the presence of a message body on either the request or the + response message. Definitions of new methods can specify that only a + zero-length message body is allowed by requiring a Content-Length + header field with a value of "0". + + A new method definition needs to indicate whether it is safe + (Section 4.2.1), idempotent (Section 4.2.2), cacheable + (Section 4.2.3), what semantics are to be associated with the payload + body if any is present in the request and what refinements the method + makes to header field or status code semantics. If the new method is + cacheable, its definition ought to describe how, and under what + conditions, a cache can store a response and use it to satisfy a + subsequent request. The new method ought to describe whether it can + be made conditional (Section 5.2) and, if so, how a server responds + when the condition is false. Likewise, if the new method might have + some use for partial response semantics ([RFC7233]), it ought to + document this, too. + + Note: Avoid defining a method name that starts with "M-", since + that prefix might be misinterpreted as having the semantics + assigned to it by [RFC2774]. + + + +Fielding & Reschke Standards Track [Page 74] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +8.1.3. Registrations + + The "Hypertext Transfer Protocol (HTTP) Method Registry" has been + populated with the registrations below: + + +---------+------+------------+---------------+ + | Method | Safe | Idempotent | Reference | + +---------+------+------------+---------------+ + | CONNECT | no | no | Section 4.3.6 | + | DELETE | no | yes | Section 4.3.5 | + | GET | yes | yes | Section 4.3.1 | + | HEAD | yes | yes | Section 4.3.2 | + | OPTIONS | yes | yes | Section 4.3.7 | + | POST | no | no | Section 4.3.3 | + | PUT | no | yes | Section 4.3.4 | + | TRACE | yes | yes | Section 4.3.8 | + +---------+------+------------+---------------+ + +8.2. Status Code Registry + + The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines + the namespace for the response status-code token (Section 6). The + status code registry is maintained at + . + + This section replaces the registration procedure for HTTP Status + Codes previously defined in Section 7.1 of [RFC2817]. + +8.2.1. Procedure + + A registration MUST include the following fields: + + o Status Code (3 digits) + + o Short Description + + o Pointer to specification text + + Values to be added to the HTTP status code namespace require IETF + Review (see [RFC5226], Section 4.1). + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 75] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +8.2.2. Considerations for New Status Codes + + When it is necessary to express semantics for a response that are not + defined by current status codes, a new status code can be registered. + Status codes are generic; they are potentially applicable to any + resource, not just one particular media type, kind of resource, or + application of HTTP. As such, it is preferred that new status codes + be registered in a document that isn't specific to a single + application. + + New status codes are required to fall under one of the categories + defined in Section 6. To allow existing parsers to process the + response message, new status codes cannot disallow a payload, + although they can mandate a zero-length payload body. + + Proposals for new status codes that are not yet widely deployed ought + to avoid allocating a specific number for the code until there is + clear consensus that it will be registered; instead, early drafts can + use a notation such as "4NN", or "3N0" .. "3N9", to indicate the + class of the proposed status code(s) without consuming a number + prematurely. + + The definition of a new status code ought to explain the request + conditions that would cause a response containing that status code + (e.g., combinations of request header fields and/or method(s)) along + with any dependencies on response header fields (e.g., what fields + are required, what fields can modify the semantics, and what header + field semantics are further refined when used with the new status + code). + + The definition of a new status code ought to specify whether or not + it is cacheable. Note that all status codes can be cached if the + response they occur in has explicit freshness information; however, + status codes that are defined as being cacheable are allowed to be + cached without explicit freshness information. Likewise, the + definition of a status code can place constraints upon cache + behavior. See [RFC7234] for more information. + + Finally, the definition of a new status code ought to indicate + whether the payload has any implied association with an identified + resource (Section 3.1.4.1). + +8.2.3. Registrations + + The status code registry has been updated with the registrations + below: + + + + + +Fielding & Reschke Standards Track [Page 76] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + +-------+-------------------------------+----------------+ + | Value | Description | Reference | + +-------+-------------------------------+----------------+ + | 100 | Continue | Section 6.2.1 | + | 101 | Switching Protocols | Section 6.2.2 | + | 200 | OK | Section 6.3.1 | + | 201 | Created | Section 6.3.2 | + | 202 | Accepted | Section 6.3.3 | + | 203 | Non-Authoritative Information | Section 6.3.4 | + | 204 | No Content | Section 6.3.5 | + | 205 | Reset Content | Section 6.3.6 | + | 300 | Multiple Choices | Section 6.4.1 | + | 301 | Moved Permanently | Section 6.4.2 | + | 302 | Found | Section 6.4.3 | + | 303 | See Other | Section 6.4.4 | + | 305 | Use Proxy | Section 6.4.5 | + | 306 | (Unused) | Section 6.4.6 | + | 307 | Temporary Redirect | Section 6.4.7 | + | 400 | Bad Request | Section 6.5.1 | + | 402 | Payment Required | Section 6.5.2 | + | 403 | Forbidden | Section 6.5.3 | + | 404 | Not Found | Section 6.5.4 | + | 405 | Method Not Allowed | Section 6.5.5 | + | 406 | Not Acceptable | Section 6.5.6 | + | 408 | Request Timeout | Section 6.5.7 | + | 409 | Conflict | Section 6.5.8 | + | 410 | Gone | Section 6.5.9 | + | 411 | Length Required | Section 6.5.10 | + | 413 | Payload Too Large | Section 6.5.11 | + | 414 | URI Too Long | Section 6.5.12 | + | 415 | Unsupported Media Type | Section 6.5.13 | + | 417 | Expectation Failed | Section 6.5.14 | + | 426 | Upgrade Required | Section 6.5.15 | + | 500 | Internal Server Error | Section 6.6.1 | + | 501 | Not Implemented | Section 6.6.2 | + | 502 | Bad Gateway | Section 6.6.3 | + | 503 | Service Unavailable | Section 6.6.4 | + | 504 | Gateway Timeout | Section 6.6.5 | + | 505 | HTTP Version Not Supported | Section 6.6.6 | + +-------+-------------------------------+----------------+ + +8.3. Header Field Registry + + HTTP header fields are registered within the "Message Headers" + registry located at + , as defined by + [BCP90]. + + + + +Fielding & Reschke Standards Track [Page 77] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +8.3.1. Considerations for New Header Fields + + Header fields are key:value pairs that can be used to communicate + data about the message, its payload, the target resource, or the + connection (i.e., control data). See Section 3.2 of [RFC7230] for a + general definition of header field syntax in HTTP messages. + + The requirements for header field names are defined in [BCP90]. + + Authors of specifications defining new fields are advised to keep the + name as short as practical and not to prefix the name with "X-" + unless the header field will never be used on the Internet. (The + "X-" prefix idiom has been extensively misused in practice; it was + intended to only be used as a mechanism for avoiding name collisions + inside proprietary software or intranet processing, since the prefix + would ensure that private names never collide with a newly registered + Internet name; see [BCP178] for further information). + + New header field values typically have their syntax defined using + ABNF ([RFC5234]), using the extension defined in Section 7 of + [RFC7230] as necessary, and are usually constrained to the range of + US-ASCII characters. Header fields needing a greater range of + characters can use an encoding such as the one defined in [RFC5987]. + + Leading and trailing whitespace in raw field values is removed upon + field parsing (Section 3.2.4 of [RFC7230]). Field definitions where + leading or trailing whitespace in values is significant will have to + use a container syntax such as quoted-string (Section 3.2.6 of + [RFC7230]). + + Because commas (",") are used as a generic delimiter between + field-values, they need to be treated with care if they are allowed + in the field-value. Typically, components that might contain a comma + are protected with double-quotes using the quoted-string ABNF + production. + + For example, a textual date and a URI (either of which might contain + a comma) could be safely carried in field-values like these: + + Example-URI-Field: "http://example.com/a.html,foo", + "http://without-a-comma.example.com/" + Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" + + Note that double-quote delimiters almost always are used with the + quoted-string production; using a different syntax inside + double-quotes will likely cause unnecessary confusion. + + + + + +Fielding & Reschke Standards Track [Page 78] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Many header fields use a format including (case-insensitively) named + parameters (for instance, Content-Type, defined in Section 3.1.1.5). + Allowing both unquoted (token) and quoted (quoted-string) syntax for + the parameter value enables recipients to use existing parser + components. When allowing both forms, the meaning of a parameter + value ought to be independent of the syntax used for it (for an + example, see the notes on parameter handling for media types in + Section 3.1.1.1). + + Authors of specifications defining new header fields are advised to + consider documenting: + + o Whether the field is a single value or whether it can be a list + (delimited by commas; see Section 3.2 of [RFC7230]). + + If it does not use the list syntax, document how to treat messages + where the field occurs multiple times (a sensible default would be + to ignore the field, but this might not always be the right + choice). + + Note that intermediaries and software libraries might combine + multiple header field instances into a single one, despite the + field's definition not allowing the list syntax. A robust format + enables recipients to discover these situations (good example: + "Content-Type", as the comma can only appear inside quoted + strings; bad example: "Location", as a comma can occur inside a + URI). + + o Under what conditions the header field can be used; e.g., only in + responses or requests, in all messages, only on responses to a + particular request method, etc. + + o Whether the field should be stored by origin servers that + understand it upon a PUT request. + + o Whether the field semantics are further refined by the context, + such as by existing request methods or status codes. + + o Whether it is appropriate to list the field-name in the Connection + header field (i.e., if the header field is to be hop-by-hop; see + Section 6.1 of [RFC7230]). + + o Under what conditions intermediaries are allowed to insert, + delete, or modify the field's value. + + + + + + + +Fielding & Reschke Standards Track [Page 79] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + o Whether it is appropriate to list the field-name in a Vary + response header field (e.g., when the request header field is used + by an origin server's content selection algorithm; see + Section 7.1.4). + + o Whether the header field is useful or allowable in trailers (see + Section 4.1 of [RFC7230]). + + o Whether the header field ought to be preserved across redirects. + + o Whether it introduces any additional security considerations, such + as disclosure of privacy-related data. + +8.3.2. Registrations + + The "Message Headers" registry has been updated with the following + permanent registrations: + + +-------------------+----------+----------+-----------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-----------------+ + | Accept | http | standard | Section 5.3.2 | + | Accept-Charset | http | standard | Section 5.3.3 | + | Accept-Encoding | http | standard | Section 5.3.4 | + | Accept-Language | http | standard | Section 5.3.5 | + | Allow | http | standard | Section 7.4.1 | + | Content-Encoding | http | standard | Section 3.1.2.2 | + | Content-Language | http | standard | Section 3.1.3.2 | + | Content-Location | http | standard | Section 3.1.4.2 | + | Content-Type | http | standard | Section 3.1.1.5 | + | Date | http | standard | Section 7.1.1.2 | + | Expect | http | standard | Section 5.1.1 | + | From | http | standard | Section 5.5.1 | + | Location | http | standard | Section 7.1.2 | + | Max-Forwards | http | standard | Section 5.1.2 | + | MIME-Version | http | standard | Appendix A.1 | + | Referer | http | standard | Section 5.5.2 | + | Retry-After | http | standard | Section 7.1.3 | + | Server | http | standard | Section 7.4.2 | + | User-Agent | http | standard | Section 5.5.3 | + | Vary | http | standard | Section 7.1.4 | + +-------------------+----------+----------+-----------------+ + + The change controller for the above registrations is: "IETF + (iesg@ietf.org) - Internet Engineering Task Force". + + + + + + +Fielding & Reschke Standards Track [Page 80] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +8.4. Content Coding Registry + + The "HTTP Content Coding Registry" defines the namespace for content + coding names (Section 4.2 of [RFC7230]). The content coding registry + is maintained at . + +8.4.1. Procedure + + Content coding registrations MUST include the following fields: + + o Name + + o Description + + o Pointer to specification text + + Names of content codings MUST NOT overlap with names of transfer + codings (Section 4 of [RFC7230]), unless the encoding transformation + is identical (as is the case for the compression codings defined in + Section 4.2 of [RFC7230]). + + Values to be added to this namespace require IETF Review (see Section + 4.1 of [RFC5226]) and MUST conform to the purpose of content coding + defined in this section. + +8.4.2. Registrations + + The "HTTP Content Coding Registry" has been updated with the + registrations below: + + +----------+----------------------------------------+---------------+ + | Name | Description | Reference | + +----------+----------------------------------------+---------------+ + | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | + | | Accept-Encoding) | | + +----------+----------------------------------------+---------------+ + +9. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns relevant to HTTP semantics and + its use for transferring information over the Internet. + Considerations related to message syntax, parsing, and routing are + discussed in Section 9 of [RFC7230]. + + The list of considerations below is not exhaustive. Most security + concerns related to HTTP semantics are about securing server-side + applications (code behind the HTTP interface), securing user agent + + + +Fielding & Reschke Standards Track [Page 81] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + processing of payloads received via HTTP, or secure use of the + Internet in general, rather than security of the protocol. Various + organizations maintain topical information and links to current + research on Web application security (e.g., [OWASP]). + +9.1. Attacks Based on File and Path Names + + Origin servers frequently make use of their local file system to + manage the mapping from effective request URI to resource + representations. Most file systems are not designed to protect + against malicious file or path names. Therefore, an origin server + needs to avoid accessing names that have a special significance to + the system when mapping the request target to files, folders, or + directories. + + For example, UNIX, Microsoft Windows, and other operating systems use + ".." as a path component to indicate a directory level above the + current one, and they use specially named paths or file names to send + data to system devices. Similar naming conventions might exist + within other types of storage systems. Likewise, local storage + systems have an annoying tendency to prefer user-friendliness over + security when handling invalid or unexpected characters, + recomposition of decomposed characters, and case-normalization of + case-insensitive names. + + Attacks based on such special names tend to focus on either denial- + of-service (e.g., telling the server to read from a COM port) or + disclosure of configuration and source files that are not meant to be + served. + +9.2. Attacks Based on Command, Code, or Query Injection + + Origin servers often use parameters within the URI as a means of + identifying system services, selecting database entries, or choosing + a data source. However, data received in a request cannot be + trusted. An attacker could construct any of the request data + elements (method, request-target, header fields, or body) to contain + data that might be misinterpreted as a command, code, or query when + passed through a command invocation, language interpreter, or + database interface. + + For example, SQL injection is a common attack wherein additional + query language is inserted within some part of the request-target or + header fields (e.g., Host, Referer, etc.). If the received data is + used directly within a SELECT statement, the query language might be + interpreted as a database command instead of a simple string value. + This type of implementation vulnerability is extremely common, in + spite of being easy to prevent. + + + +Fielding & Reschke Standards Track [Page 82] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + In general, resource implementations ought to avoid use of request + data in contexts that are processed or interpreted as instructions. + Parameters ought to be compared to fixed strings and acted upon as a + result of that comparison, rather than passed through an interface + that is not prepared for untrusted data. Received data that isn't + based on fixed parameters ought to be carefully filtered or encoded + to avoid being misinterpreted. + + Similar considerations apply to request data when it is stored and + later processed, such as within log files, monitoring tools, or when + included within a data format that allows embedded scripts. + +9.3. Disclosure of Personal Information + + Clients are often privy to large amounts of personal information, + including both information provided by the user to interact with + resources (e.g., the user's name, location, mail address, passwords, + encryption keys, etc.) and information about the user's browsing + activity over time (e.g., history, bookmarks, etc.). Implementations + need to prevent unintentional disclosure of personal information. + +9.4. Disclosure of Sensitive Information in URIs + + URIs are intended to be shared, not secured, even when they identify + secure resources. URIs are often shown on displays, added to + templates when a page is printed, and stored in a variety of + unprotected bookmark lists. It is therefore unwise to include + information within a URI that is sensitive, personally identifiable, + or a risk to disclose. + + Authors of services ought to avoid GET-based forms for the submission + of sensitive data because that data will be placed in the + request-target. Many existing servers, proxies, and user agents log + or display the request-target in places where it might be visible to + third parties. Such services ought to use POST-based form submission + instead. + + Since the Referer header field tells a target site about the context + that resulted in a request, it has the potential to reveal + information about the user's immediate browsing history and any + personal information that might be found in the referring resource's + URI. Limitations on the Referer header field are described in + Section 5.5.2 to address some of its security considerations. + + + + + + + + +Fielding & Reschke Standards Track [Page 83] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +9.5. Disclosure of Fragment after Redirects + + Although fragment identifiers used within URI references are not sent + in requests, implementers ought to be aware that they will be visible + to the user agent and any extensions or scripts running as a result + of the response. In particular, when a redirect occurs and the + original request's fragment identifier is inherited by the new + reference in Location (Section 7.1.2), this might have the effect of + disclosing one site's fragment to another site. If the first site + uses personal information in fragments, it ought to ensure that + redirects to other sites include a (possibly empty) fragment + component in order to block that inheritance. + +9.6. Disclosure of Product Information + + The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and + Server (Section 7.4.2) header fields often reveal information about + the respective sender's software systems. In theory, this can make + it easier for an attacker to exploit known security holes; in + practice, attackers tend to try all potential holes regardless of the + apparent software versions being used. + + Proxies that serve as a portal through a network firewall ought to + take special precautions regarding the transfer of header information + that might identify hosts behind the firewall. The Via header field + allows intermediaries to replace sensitive machine names with + pseudonyms. + +9.7. Browser Fingerprinting + + Browser fingerprinting is a set of techniques for identifying a + specific user agent over time through its unique set of + characteristics. These characteristics might include information + related to its TCP behavior, feature capabilities, and scripting + environment, though of particular interest here is the set of unique + characteristics that might be communicated via HTTP. Fingerprinting + is considered a privacy concern because it enables tracking of a user + agent's behavior over time without the corresponding controls that + the user might have over other forms of data collection (e.g., + cookies). Many general-purpose user agents (i.e., Web browsers) have + taken steps to reduce their fingerprints. + + There are a number of request header fields that might reveal + information to servers that is sufficiently unique to enable + fingerprinting. The From header field is the most obvious, though it + is expected that From will only be sent when self-identification is + desired by the user. Likewise, Cookie header fields are deliberately + + + + +Fielding & Reschke Standards Track [Page 84] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + designed to enable re-identification, so fingerprinting concerns only + apply to situations where cookies are disabled or restricted by the + user agent's configuration. + + The User-Agent header field might contain enough information to + uniquely identify a specific device, usually when combined with other + characteristics, particularly if the user agent sends excessive + details about the user's system or extensions. However, the source + of unique information that is least expected by users is proactive + negotiation (Section 5.3), including the Accept, Accept-Charset, + Accept-Encoding, and Accept-Language header fields. + + In addition to the fingerprinting concern, detailed use of the + Accept-Language header field can reveal information the user might + consider to be of a private nature. For example, understanding a + given language set might be strongly correlated to membership in a + particular ethnic group. An approach that limits such loss of + privacy would be for a user agent to omit the sending of + Accept-Language except for sites that have been whitelisted, perhaps + via interaction after detecting a Vary header field that indicates + language negotiation might be useful. + + In environments where proxies are used to enhance privacy, user + agents ought to be conservative in sending proactive negotiation + header fields. General-purpose user agents that provide a high + degree of header field configurability ought to inform users about + the loss of privacy that might result if too much detail is provided. + As an extreme privacy measure, proxies could filter the proactive + negotiation header fields in relayed requests. + +10. Acknowledgments + + See Section 10 of [RFC7230]. + +11. References + +11.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +Fielding & Reschke Standards Track [Page 85] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language + Tags", BCP 47, RFC 4647, September 2006. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, September 2009. + + [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in + Internationalization in the IETF", BCP 166, RFC 6365, + September 2011. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + RFC 7233, June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. + +11.2. Informative References + + [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, January 2013. + + [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, + "Deprecating the "X-" Prefix and Similar Constructs in + Application Protocols", BCP 178, RFC 6648, June 2012. + + + + + + +Fielding & Reschke Standards Track [Page 86] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web + Applications and Web Services", The Open Web Application + Security Project (OWASP) 2.0.1, July 2005, + . + + [REST] Fielding, R., "Architectural Styles and the Design of + Network-based Software Architectures", + Doctoral Dissertation, University of California, Irvine, + September 2000, + . + + [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, November 1996. + + [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", + RFC 2068, January 1997. + + [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation + in HTTP", RFC 2295, March 1998. + + [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ + form-data", RFC 2388, August 1998. + + [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, + "MIME Encapsulation of Aggregate Documents, such as HTML + (MHTML)", RFC 2557, March 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP + Extension Framework", RFC 2774, February 2000. + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, May 2000. + + [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2978, October 2000. + + + +Fielding & Reschke Standards Track [Page 87] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, + October 2008. + + [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", + RFC 5789, March 2010. + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + + [RFC5987] Reschke, J., "Character Set and Language Encoding for + Hypertext Transfer Protocol (HTTP) Header Field + Parameters", RFC 5987, August 2010. + + [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + + [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field + in the Hypertext Transfer Protocol (HTTP)", RFC 6266, + June 2011. + + [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) + Status Code 308 (Permanent Redirect)", RFC 7238, + June 2014. + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 88] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +Appendix A. Differences between HTTP and MIME + + HTTP/1.1 uses many of the constructs defined for the Internet Message + Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) + [RFC2045] to allow a message body to be transmitted in an open + variety of representations and with extensible header fields. + However, RFC 2045 is focused only on email; applications of HTTP have + many characteristics that differ from email; hence, HTTP has features + that differ from 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 and from strict MIME environments need to be + aware of these differences and provide the appropriate conversions + where necessary. + +A.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. + +A.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]. Section 3.1.1.3 of this document describes the forms + allowed for subtypes of the "text" media type when transmitted over + HTTP. [RFC2046] 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. + + A proxy or gateway from HTTP to a strict MIME environment ought to + translate all line breaks within the text media types described in + Section 3.1.1.3 of this document 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. + + + + +Fielding & Reschke Standards Track [Page 89] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 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. + +A.3. Conversion of Date Formats + + HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) 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. + +A.4. Conversion 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 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=" + to perform a function equivalent to Content-Encoding. However, this + parameter is not part of the MIME standards). + +A.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. + +A.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 as + + + +Fielding & Reschke Standards Track [Page 90] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + payload and, aside from the "multipart/byteranges" type (Appendix A + of [RFC7233]), does not interpret the content or any MIME header + lines that might be contained therein. + +Appendix B. Changes from RFC 2616 + + The primary changes in this revision have been editorial in nature: + extracting the messaging syntax and partitioning HTTP semantics into + separate documents for the core features, conditional requests, + partial requests, caching, and authentication. The conformance + language has been revised to clearly target requirements and the + terminology has been improved to distinguish payload from + representations and representations from resources. + + A new requirement has been added that semantics embedded in a URI be + disabled when those semantics are inconsistent with the request + method, since this is a common cause of interoperability failure. + (Section 2) + + An algorithm has been added for determining if a payload is + associated with a specific identifier. (Section 3.1.4.1) + + The default charset of ISO-8859-1 for text media types has been + removed; the default is now whatever the media type definition says. + Likewise, special treatment of ISO-8859-1 has been removed from the + Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) + + The definition of Content-Location has been changed to no longer + affect the base URI for resolving relative URI references, due to + poor implementation support and the undesirable effect of potentially + breaking relative links in content-negotiated resources. + (Section 3.1.4.2) + + To be consistent with the method-neutral parsing algorithm of + [RFC7230], the definition of GET has been relaxed so that requests + can have a body, even though a body has no meaning for GET. + (Section 4.3.1) + + Servers are no longer required to handle all Content-* header fields + and use of Content-Range has been explicitly banned in PUT requests. + (Section 4.3.4) + + Definition of the CONNECT method has been moved from [RFC2817] to + this specification. (Section 4.3.6) + + The OPTIONS and TRACE request methods have been defined as being + safe. (Section 4.3.7 and Section 4.3.8) + + + + +Fielding & Reschke Standards Track [Page 91] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The Expect header field's extension mechanism has been removed due to + widely-deployed broken implementations. (Section 5.1.1) + + The Max-Forwards header field has been restricted to the OPTIONS and + TRACE methods; previously, extension methods could have used it as + well. (Section 5.1.2) + + The "about:blank" URI has been suggested as a value for the Referer + header field when no referring URI is applicable, which distinguishes + that case from others where the Referer field is not sent or has been + removed. (Section 5.5.2) + + The following status codes are now cacheable (that is, they can be + stored and reused by a cache without explicit freshness information + present): 204, 404, 405, 414, 501. (Section 6) + + The 201 (Created) status description has been changed to allow for + the possibility that more than one resource has been created. + (Section 6.3.2) + + The definition of 203 (Non-Authoritative Information) has been + broadened to include cases of payload transformations as well. + (Section 6.3.4) + + The set of request methods that are safe to automatically redirect is + no longer closed; user agents are able to make that determination + based upon the request method semantics. The redirect status codes + 301, 302, and 307 no longer have normative requirements on response + payloads and user interaction. (Section 6.4) + + The status codes 301 and 302 have been changed to allow user agents + to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) + + The description of the 303 (See Other) status code has been changed + to allow it to be cached if explicit freshness information is given, + and a specific definition has been added for a 303 response to GET. + (Section 6.4.4) + + The 305 (Use Proxy) status code has been deprecated due to security + concerns regarding in-band configuration of a proxy. (Section 6.4.5) + + The 400 (Bad Request) status code has been relaxed so that it isn't + limited to syntax errors. (Section 6.5.1) + + The 426 (Upgrade Required) status code has been incorporated from + [RFC2817]. (Section 6.5.15) + + + + + +Fielding & Reschke Standards Track [Page 92] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + The target of requirements on HTTP-date and the Date header field + have been reduced to those systems generating the date, rather than + all systems sending a date. (Section 7.1.1) + + The syntax of the Location header field has been changed to allow all + URI references, including relative references and fragments, along + with some clarifications as to when use of fragments would not be + appropriate. (Section 7.1.2) + + Allow has been reclassified as a response header field, removing the + option to specify it in a PUT request. Requirements relating to the + content of Allow have been relaxed; correspondingly, clients are not + required to always trust its value. (Section 7.4.1) + + A Method Registry has been defined. (Section 8.1) + + The Status Code Registry has been redefined by this specification; + previously, it was defined in Section 7.1 of [RFC2817]. + (Section 8.2) + + Registration of content codings has been changed to require IETF + Review. (Section 8.4) + + The Content-Disposition header field has been removed since it is now + defined by [RFC6266]. + + The Content-MD5 header field has been removed because it was + inconsistently implemented with respect to partial responses. + +Appendix C. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: 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 US-ASCII character). + + The rules below are defined in [RFC7230]: + + BWS = + OWS = + RWS = + URI-reference = + absolute-URI = + comment = + field-name = + partial-URI = + + + +Fielding & Reschke Standards Track [Page 93] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + quoted-string = + token = + +Appendix D. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ + OWS ( media-range [ accept-params ] ) ] ) ] + Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS + "," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) + Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS + ( codings [ weight ] ) ] ) ] + Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS + "," [ OWS ( language-range [ weight ] ) ] ) + Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] + + BWS = + + Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS + content-coding ] ) + Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS + language-tag ] ) + Content-Location = absolute-URI / partial-URI + Content-Type = media-type + + Date = HTTP-date + + Expect = "100-continue" + + From = mailbox + + GMT = %x47.4D.54 ; GMT + + HTTP-date = IMF-fixdate / obs-date + + IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT + + Location = URI-reference + + Max-Forwards = 1*DIGIT + + OWS = + + RWS = + Referer = absolute-URI / partial-URI + Retry-After = HTTP-date / delay-seconds + + + +Fielding & Reschke Standards Track [Page 94] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Server = product *( RWS ( product / comment ) ) + + URI-reference = + User-Agent = product *( RWS ( product / comment ) ) + + Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] + ) ) + + absolute-URI = + accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] + accept-params = weight *accept-ext + asctime-date = day-name SP date3 SP time-of-day SP year + + charset = token + codings = content-coding / "identity" / "*" + comment = + content-coding = token + + date1 = day SP month SP year + date2 = day "-" month "-" 2DIGIT + date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) + day = 2DIGIT + day-name = %x4D.6F.6E ; Mon + / %x54.75.65 ; Tue + / %x57.65.64 ; Wed + / %x54.68.75 ; Thu + / %x46.72.69 ; Fri + / %x53.61.74 ; Sat + / %x53.75.6E ; Sun + day-name-l = %x4D.6F.6E.64.61.79 ; Monday + / %x54.75.65.73.64.61.79 ; Tuesday + / %x57.65.64.6E.65.73.64.61.79 ; Wednesday + / %x54.68.75.72.73.64.61.79 ; Thursday + / %x46.72.69.64.61.79 ; Friday + / %x53.61.74.75.72.64.61.79 ; Saturday + / %x53.75.6E.64.61.79 ; Sunday + delay-seconds = 1*DIGIT + + field-name = + + hour = 2DIGIT + + language-range = + language-tag = + + mailbox = + media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS + ";" OWS parameter ) + + + +Fielding & Reschke Standards Track [Page 95] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + media-type = type "/" subtype *( OWS ";" OWS parameter ) + method = token + minute = 2DIGIT + month = %x4A.61.6E ; Jan + / %x46.65.62 ; Feb + / %x4D.61.72 ; Mar + / %x41.70.72 ; Apr + / %x4D.61.79 ; May + / %x4A.75.6E ; Jun + / %x4A.75.6C ; Jul + / %x41.75.67 ; Aug + / %x53.65.70 ; Sep + / %x4F.63.74 ; Oct + / %x4E.6F.76 ; Nov + / %x44.65.63 ; Dec + + obs-date = rfc850-date / asctime-date + + parameter = token "=" ( token / quoted-string ) + partial-URI = + product = token [ "/" product-version ] + product-version = token + quoted-string = + qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) + + rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT + + second = 2DIGIT + subtype = token + + time-of-day = hour ":" minute ":" second + token = + type = token + + weight = OWS ";" OWS "q=" qvalue + + year = 4DIGIT + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 96] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + +Index + + 1 + 1xx Informational (status code class) 50 + + 2 + 2xx Successful (status code class) 51 + + 3 + 3xx Redirection (status code class) 54 + + 4 + 4xx Client Error (status code class) 58 + + 5 + 5xx Server Error (status code class) 62 + + 1 + 100 Continue (status code) 50 + 100-continue (expect value) 34 + 101 Switching Protocols (status code) 50 + + 2 + 200 OK (status code) 51 + 201 Created (status code) 52 + 202 Accepted (status code) 52 + 203 Non-Authoritative Information (status code) 52 + 204 No Content (status code) 53 + 205 Reset Content (status code) 53 + + 3 + 300 Multiple Choices (status code) 55 + 301 Moved Permanently (status code) 56 + 302 Found (status code) 56 + 303 See Other (status code) 57 + 305 Use Proxy (status code) 58 + 306 (Unused) (status code) 58 + 307 Temporary Redirect (status code) 58 + + 4 + 400 Bad Request (status code) 58 + 402 Payment Required (status code) 59 + 403 Forbidden (status code) 59 + 404 Not Found (status code) 59 + 405 Method Not Allowed (status code) 59 + 406 Not Acceptable (status code) 59 + 408 Request Timeout (status code) 60 + 409 Conflict (status code) 60 + + + +Fielding & Reschke Standards Track [Page 97] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + 410 Gone (status code) 60 + 411 Length Required (status code) 61 + 413 Payload Too Large (status code) 61 + 414 URI Too Long (status code) 61 + 415 Unsupported Media Type (status code) 62 + 417 Expectation Failed (status code) 62 + 426 Upgrade Required (status code) 62 + + 5 + 500 Internal Server Error (status code) 63 + 501 Not Implemented (status code) 63 + 502 Bad Gateway (status code) 63 + 503 Service Unavailable (status code) 63 + 504 Gateway Timeout (status code) 63 + 505 HTTP Version Not Supported (status code) 64 + + A + Accept header field 38 + Accept-Charset header field 40 + Accept-Encoding header field 41 + Accept-Language header field 42 + Allow header field 72 + + C + cacheable 24 + compress (content coding) 11 + conditional request 36 + CONNECT method 30 + content coding 11 + content negotiation 6 + Content-Encoding header field 12 + Content-Language header field 13 + Content-Location header field 15 + Content-Transfer-Encoding header field 89 + Content-Type header field 10 + + D + Date header field 67 + deflate (content coding) 11 + DELETE method 29 + + E + Expect header field 34 + + F + From header field 44 + + + + + +Fielding & Reschke Standards Track [Page 98] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + G + GET method 24 + Grammar + Accept 38 + Accept-Charset 40 + Accept-Encoding 41 + accept-ext 38 + Accept-Language 42 + accept-params 38 + Allow 72 + asctime-date 66 + charset 9 + codings 41 + content-coding 11 + Content-Encoding 12 + Content-Language 13 + Content-Location 15 + Content-Type 10 + Date 67 + date1 65 + day 65 + day-name 65 + day-name-l 65 + delay-seconds 69 + Expect 34 + From 44 + GMT 65 + hour 65 + HTTP-date 65 + IMF-fixdate 65 + language-range 42 + language-tag 13 + Location 68 + Max-Forwards 36 + media-range 38 + media-type 8 + method 21 + minute 65 + month 65 + obs-date 66 + parameter 8 + product 46 + product-version 46 + qvalue 38 + Referer 45 + Retry-After 69 + rfc850-date 66 + second 65 + + + +Fielding & Reschke Standards Track [Page 99] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + Server 73 + subtype 8 + time-of-day 65 + type 8 + User-Agent 46 + Vary 70 + weight 38 + year 65 + gzip (content coding) 11 + + H + HEAD method 25 + + I + idempotent 23 + + L + Location header field 68 + + M + Max-Forwards header field 36 + MIME-Version header field 89 + + O + OPTIONS method 31 + + P + payload 17 + POST method 25 + PUT method 26 + + R + Referer header field 45 + representation 7 + Retry-After header field 69 + + S + safe 22 + selected representation 7, 71 + Server header field 73 + Status Codes Classes + 1xx Informational 50 + 2xx Successful 51 + 3xx Redirection 54 + 4xx Client Error 58 + 5xx Server Error 62 + + + + + +Fielding & Reschke Standards Track [Page 100] + +RFC 7231 HTTP/1.1 Semantics and Content June 2014 + + + T + TRACE method 32 + + U + User-Agent header field 46 + + V + Vary header field 70 + + X + x-compress (content coding) 11 + x-gzip (content coding) 11 + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 101] + === added file 'doc/rfc/rfc7232.txt' --- doc/rfc/rfc7232.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7232.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,1571 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7232 Adobe +Obsoletes: 2616 J. Reschke, Ed. +Category: Standards Track greenbytes +ISSN: 2070-1721 June 2014 + + + Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document defines HTTP/1.1 conditional requests, + including metadata header fields for indicating state changes, + request header fields for making preconditions on such state, and + rules for constructing the responses to a conditional request when + one or more preconditions evaluate to false. + +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/rfc7232. + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 1] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 2] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Conformance and Error Handling .............................4 + 1.2. Syntax Notation ............................................4 + 2. Validators ......................................................5 + 2.1. Weak versus Strong .........................................5 + 2.2. Last-Modified ..............................................7 + 2.2.1. Generation ..........................................7 + 2.2.2. Comparison ..........................................8 + 2.3. ETag .......................................................9 + 2.3.1. Generation .........................................10 + 2.3.2. Comparison .........................................10 + 2.3.3. Example: Entity-Tags Varying on + Content-Negotiated Resources .......................11 + 2.4. When to Use Entity-Tags and Last-Modified Dates ...........12 + 3. Precondition Header Fields .....................................13 + 3.1. If-Match ..................................................13 + 3.2. If-None-Match .............................................14 + 3.3. If-Modified-Since .........................................16 + 3.4. If-Unmodified-Since .......................................17 + 3.5. If-Range ..................................................18 + 4. Status Code Definitions ........................................18 + 4.1. 304 Not Modified ..........................................18 + 4.2. 412 Precondition Failed ...................................19 + 5. Evaluation .....................................................19 + 6. Precedence .....................................................20 + 7. IANA Considerations ............................................22 + 7.1. Status Code Registration ..................................22 + 7.2. Header Field Registration .................................22 + 8. Security Considerations ........................................22 + 9. Acknowledgments ................................................23 + 10. References ....................................................24 + 10.1. Normative References .....................................24 + 10.2. Informative References ...................................24 + Appendix A. Changes from RFC 2616 .................................25 + Appendix B. Imported ABNF .........................................25 + Appendix C. Collected ABNF ........................................26 + Index .............................................................27 + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 3] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +1. Introduction + + Conditional requests are HTTP requests [RFC7231] that include one or + more header fields indicating a precondition to be tested before + applying the method semantics to the target resource. This document + defines the HTTP/1.1 conditional request mechanisms in terms of the + architecture, syntax notation, and conformance criteria defined in + [RFC7230]. + + Conditional GET requests are the most efficient mechanism for HTTP + cache updates [RFC7234]. Conditionals can also be applied to + state-changing methods, such as PUT and DELETE, to prevent the "lost + update" problem: one client accidentally overwriting the work of + another client that has been acting in parallel. + + Conditional request preconditions are based on the state of the + target resource as a whole (its current value set) or the state as + observed in a previously obtained representation (one value in that + set). A resource might have multiple current representations, each + with its own observable state. The conditional request mechanisms + assume that the mapping of requests to a "selected representation" + (Section 3 of [RFC7231]) will be consistent over time if the server + intends to take advantage of conditionals. Regardless, if the + mapping is inconsistent and the server is unable to select the + appropriate representation, then no harm will result when the + precondition evaluates to false. + + The conditional request preconditions defined by this specification + (Section 3) are evaluated when applicable to the recipient + (Section 5) according to their order of precedence (Section 6). + +1.1. Conformance and Error Handling + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + + + + + +Fielding & Reschke Standards Track [Page 4] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + repetition). Appendix B describes rules imported from other + documents. Appendix C shows the collected grammar with all list + operators expanded to standard ABNF notation. + +2. Validators + + This specification defines two forms of metadata that are commonly + used to observe resource state and test for preconditions: + modification dates (Section 2.2) and opaque entity tags + (Section 2.3). Additional metadata that reflects resource state has + been defined by various extensions of HTTP, such as Web Distributed + Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the + scope of this specification. A resource metadata value is referred + to as a "validator" when it is used within a precondition. + +2.1. Weak versus Strong + + Validators come in two flavors: strong or weak. Weak validators are + easy to generate but are far less useful for comparisons. Strong + validators are ideal for comparisons but can be very difficult (and + occasionally impossible) to generate efficiently. Rather than impose + that all forms of resource adhere to the same strength of validator, + HTTP exposes the type of validator in use and imposes restrictions on + when weak validators can be used as preconditions. + + A "strong validator" is representation metadata that changes value + whenever a change occurs to the representation data that would be + observable in the payload body of a 200 (OK) response to GET. + + A strong validator might change for reasons other than a change to + the representation data, such as when a semantically significant part + of the representation metadata is changed (e.g., Content-Type), but + it is in the best interests of the origin server to only change the + value when it is necessary to invalidate the stored responses held by + remote caches and authoring tools. + + Cache entries might persist for arbitrarily long periods, regardless + of expiration times. Thus, a cache might attempt to validate an + entry using a validator that it obtained in the distant past. A + strong validator is unique across all versions of all representations + associated with a particular resource over time. However, there is + no implication of uniqueness across representations of different + resources (i.e., the same strong validator might be in use for + representations of multiple resources at the same time and does not + imply that those representations are equivalent). + + + + + + +Fielding & Reschke Standards Track [Page 5] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + There are a variety of strong validators used in practice. The best + are based on strict revision control, wherein each change to a + representation always results in a unique node name and revision + identifier being assigned before the representation is made + accessible to GET. A collision-resistant hash function applied to + the representation data is also sufficient if the data is available + prior to the response header fields being sent and the digest does + not need to be recalculated every time a validation request is + received. However, if a resource has distinct representations that + differ only in their metadata, such as might occur with content + negotiation over media types that happen to share the same data + format, then the origin server needs to incorporate additional + information in the validator to distinguish those representations. + + In contrast, a "weak validator" is representation metadata that might + not change for every change to the representation data. This + weakness might be due to limitations in how the value is calculated, + such as clock resolution, an inability to ensure uniqueness for all + possible representations of the resource, or a desire of the resource + owner to group representations by some self-determined set of + equivalency rather than unique sequences of data. An origin server + SHOULD change a weak entity-tag whenever it considers prior + representations to be unacceptable as a substitute for the current + representation. In other words, a weak entity-tag ought to change + whenever the origin server wants caches to invalidate old responses. + + For example, the representation of a weather report that changes in + content every second, based on dynamic measurements, might be grouped + into sets of equivalent representations (from the origin server's + perspective) with the same weak validator in order to allow cached + representations to be valid for a reasonable period of time (perhaps + adjusted dynamically based on server load or weather quality). + Likewise, a representation's modification time, if defined with only + one-second resolution, might be a weak validator if it is possible + for the representation to be modified twice during a single second + and retrieved between those modifications. + + Likewise, a validator is weak if it is shared by two or more + representations of a given resource at the same time, unless those + representations have identical representation data. For example, if + the origin server sends the same validator for a representation with + a gzip content coding applied as it does for a representation with no + content coding, then that validator is weak. However, two + simultaneous representations might share the same strong validator if + they differ only in the representation metadata, such as when two + different media types are available for the same representation data. + + + + + +Fielding & Reschke Standards Track [Page 6] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + Strong validators are usable for all conditional requests, including + cache validation, partial content ranges, and "lost update" + avoidance. Weak validators are only usable when the client does not + require exact equality with previously obtained representation data, + such as when validating a cache entry or limiting a web traversal to + recent changes. + +2.2. Last-Modified + + The "Last-Modified" header field in a response provides a timestamp + indicating the date and time at which the origin server believes the + selected representation was last modified, as determined at the + conclusion of handling the request. + + Last-Modified = HTTP-date + + An example of its use is + + Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT + +2.2.1. Generation + + An origin server SHOULD send Last-Modified for any selected + representation for which a last modification date can be reasonably + and consistently determined, since its use in conditional requests + and evaluating cache freshness ([RFC7234]) results in a substantial + reduction of HTTP traffic on the Internet and can be a significant + factor in improving service scalability and reliability. + + A representation is typically the sum of many parts behind the + resource interface. The last-modified time would usually be the most + recent time that any of those parts were changed. How that value is + determined for any given resource is an implementation detail beyond + the scope of this specification. What matters to HTTP is how + recipients of the Last-Modified header field can use its value to + make conditional requests and test the validity of locally cached + responses. + + An origin server SHOULD obtain the Last-Modified value of the + representation as close as possible to the time that it generates the + Date field value for its response. This allows a recipient to make + an accurate assessment of the representation's modification time, + especially if the representation changes near the time that the + response is generated. + + An origin server with a clock MUST NOT send a Last-Modified date that + is later than the server's time of message origination (Date). If + the last modification time is derived from implementation-specific + + + +Fielding & Reschke Standards Track [Page 7] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + metadata that evaluates to some time in the future, according to the + origin server's clock, then the origin server MUST replace that value + with the message origination date. This prevents a future + modification date from having an adverse impact on cache validation. + + An origin server without a clock MUST NOT assign Last-Modified values + to a response unless these values were associated with the resource + by some other system or user with a reliable clock. + +2.2.2. Comparison + + 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 representation and, + + o That origin server reliably knows that the associated + representation 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, If-Unmodified-Since, or If-Range header field, + because the client has a cache entry for the associated + representation, 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 representation, 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. + + + + + + +Fielding & Reschke Standards Track [Page 8] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + 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. + +2.3. ETag + + The "ETag" header field in a response provides the current entity-tag + for the selected representation, as determined at the conclusion of + handling the request. An entity-tag is an opaque validator for + differentiating between multiple representations of the same + resource, regardless of whether those multiple representations are + due to resource state changes over time, content negotiation + resulting in multiple representations being valid at the same time, + or both. An entity-tag consists of an opaque quoted string, possibly + prefixed by a weakness indicator. + + ETag = entity-tag + + entity-tag = [ weak ] opaque-tag + weak = %x57.2F ; "W/", case-sensitive + opaque-tag = DQUOTE *etagc DQUOTE + etagc = %x21 / %x23-7E / obs-text + ; VCHAR except double quotes, plus obs-text + + Note: Previously, opaque-tag was defined to be a quoted-string + ([RFC2616], Section 3.11); thus, some recipients might perform + backslash unescaping. Servers therefore ought to avoid backslash + characters in entity tags. + + An entity-tag can be more reliable for validation than a modification + date in situations where it is inconvenient to store modification + dates, where the one-second resolution of HTTP date values is not + sufficient, or where modification dates are not consistently + maintained. + + Examples: + + ETag: "xyzzy" + ETag: W/"xyzzy" + ETag: "" + + + + + +Fielding & Reschke Standards Track [Page 9] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + An entity-tag can be either a weak or strong validator, with strong + being the default. If an origin server provides an entity-tag for a + representation and the generation of that entity-tag does not satisfy + all of the characteristics of a strong validator (Section 2.1), then + the origin server MUST mark the entity-tag as weak by prefixing its + opaque value with "W/" (case-sensitive). + +2.3.1. Generation + + The principle behind entity-tags is that only the service author + knows the implementation of a resource well enough to select the most + accurate and efficient validation mechanism for that resource, and + that any such mechanism can be mapped to a simple sequence of octets + for easy comparison. Since the value is opaque, there is no need for + the client to be aware of how each entity-tag is constructed. + + For example, a resource that has implementation-specific versioning + applied to all changes might use an internal revision number, perhaps + combined with a variance identifier for content negotiation, to + accurately differentiate between representations. Other + implementations might use a collision-resistant hash of + representation content, a combination of various file attributes, or + a modification timestamp that has sub-second resolution. + + An origin server SHOULD send an ETag for any selected representation + for which detection of changes can be reasonably and consistently + determined, since the entity-tag's use in conditional requests and + evaluating cache freshness ([RFC7234]) can result in a substantial + reduction of HTTP network traffic and can be a significant factor in + improving service scalability and reliability. + +2.3.2. Comparison + + There are two entity-tag comparison functions, depending on whether + or not the comparison context allows the use of weak validators: + + o Strong comparison: two entity-tags are equivalent if both are not + weak and their opaque-tags match character-by-character. + + o Weak comparison: two entity-tags are equivalent if their + opaque-tags match character-by-character, regardless of either or + both being tagged as "weak". + + + + + + + + + +Fielding & Reschke Standards Track [Page 10] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + The example below shows the results for a set of entity-tag pairs and + both the weak and strong comparison function results: + + +--------+--------+-------------------+-----------------+ + | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | + +--------+--------+-------------------+-----------------+ + | W/"1" | W/"1" | no match | match | + | W/"1" | W/"2" | no match | no match | + | W/"1" | "1" | no match | match | + | "1" | "1" | match | match | + +--------+--------+-------------------+-----------------+ + +2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources + + Consider a resource that is subject to content negotiation (Section + 3.4 of [RFC7231]), and where the representations sent in response to + a GET request vary based on the Accept-Encoding request header field + (Section 5.3.4 of [RFC7231]): + + >> Request: + + GET /index HTTP/1.1 + Host: www.example.com + Accept-Encoding: gzip + + + In this case, the response might or might not use the gzip content + coding. If it does not, the response might look like: + + >> Response: + + HTTP/1.1 200 OK + Date: Fri, 26 Mar 2010 00:05:00 GMT + ETag: "123-a" + Content-Length: 70 + Vary: Accept-Encoding + Content-Type: text/plain + + Hello World! + Hello World! + Hello World! + Hello World! + Hello World! + + + + + + + + +Fielding & Reschke Standards Track [Page 11] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + An alternative representation that does use gzip content coding would + be: + + >> Response: + + HTTP/1.1 200 OK + Date: Fri, 26 Mar 2010 00:05:00 GMT + ETag: "123-b" + Content-Length: 43 + Vary: Accept-Encoding + Content-Type: text/plain + Content-Encoding: gzip + + ...binary data... + + Note: Content codings are a property of the representation data, + so a strong entity-tag for a content-encoded representation has to + be distinct from the entity tag of an unencoded representation to + prevent potential conflicts during cache updates and range + requests. In contrast, transfer codings (Section 4 of [RFC7230]) + apply only during message transfer and do not result in distinct + entity-tags. + +2.4. When to Use Entity-Tags and Last-Modified Dates + + In 200 (OK) responses to GET or HEAD, an origin server: + + 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. + + In other words, the preferred behavior for an origin server is to + send both a strong entity-tag and a Last-Modified value in successful + responses to a retrieval request. + + A client: + + o MUST send that entity-tag in any cache validation request (using + If-Match or If-None-Match) if an entity-tag has been provided by + the origin server. + + + + + + +Fielding & Reschke Standards Track [Page 12] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + o SHOULD send the Last-Modified value in non-subrange cache + validation requests (using If-Modified-Since) if only a + Last-Modified value has been provided by the origin server. + + o MAY send the Last-Modified value in subrange cache validation + requests (using If-Unmodified-Since) if only a Last-Modified value + has been provided by an HTTP/1.0 origin server. The user agent + SHOULD provide a way to disable this, in case of difficulty. + + o SHOULD send both validators in cache validation requests if both + an entity-tag and a Last-Modified value have been provided by the + origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to + respond appropriately. + +3. Precondition Header Fields + + This section defines the syntax and semantics of HTTP/1.1 header + fields for applying preconditions on requests. Section 5 defines + when the preconditions are applied. Section 6 defines the order of + evaluation when more than one precondition is present. + +3.1. If-Match + + The "If-Match" header field makes the request method conditional on + the recipient origin server either having at least one current + representation of the target resource, when the field-value is "*", + or having a current representation of the target resource that has an + entity-tag matching a member of the list of entity-tags provided in + the field-value. + + An origin server MUST use the strong comparison function when + comparing entity-tags for If-Match (Section 2.3.2), since the client + intends this precondition to prevent the method from being applied if + there have been any changes to the representation data. + + If-Match = "*" / 1#entity-tag + + Examples: + + If-Match: "xyzzy" + If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" + If-Match: * + + If-Match is most often used with state-changing methods (e.g., POST, + PUT, DELETE) to prevent accidental overwrites when multiple user + agents might be acting in parallel on the same resource (i.e., to + + + + + +Fielding & Reschke Standards Track [Page 13] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + prevent the "lost update" problem). It can also be used with safe + methods to abort a request if the selected representation does not + match one already stored (or partially stored) from a prior request. + + An origin server that receives an If-Match header field MUST evaluate + the condition prior to performing the method (Section 5). If the + field-value is "*", the condition is false if the origin server does + not have a current representation for the target resource. If the + field-value is a list of entity-tags, the condition is false if none + of the listed tags match the entity-tag of the selected + representation. + + An origin server MUST NOT perform the requested method if a received + If-Match condition evaluates to false; instead, the origin server + MUST respond with either a) the 412 (Precondition Failed) status code + or b) one of the 2xx (Successful) status codes if the origin server + has verified that a state change is being requested and the final + state is already reflected in the current state of the target + resource (i.e., the change requested by the user agent has already + succeeded, but the user agent might not be aware of it, perhaps + because the prior response was lost or a compatible change was made + by some other user agent). In the latter case, the origin server + MUST NOT send a validator header field in the response unless it can + verify that the request is a duplicate of an immediately prior change + made by the same user agent. + + The If-Match header field can be ignored by caches and intermediaries + because it is not applicable to a stored response. + +3.2. If-None-Match + + The "If-None-Match" header field makes the request method conditional + on a recipient cache or origin server either not having any current + representation of the target resource, when the field-value is "*", + or having a selected representation with an entity-tag that does not + match any of those listed in the field-value. + + A recipient MUST use the weak comparison function when comparing + entity-tags for If-None-Match (Section 2.3.2), since weak entity-tags + can be used for cache validation even if there have been changes to + the representation data. + + If-None-Match = "*" / 1#entity-tag + + + + + + + + +Fielding & Reschke Standards Track [Page 14] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + 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: * + + If-None-Match is primarily used in conditional GET requests to enable + efficient updates of cached information with a minimum amount of + transaction overhead. When a client desires to update one or more + stored responses that have entity-tags, the client SHOULD generate an + If-None-Match header field containing a list of those entity-tags + when making a GET request; this allows recipient servers to send a + 304 (Not Modified) response to indicate when one of those stored + responses matches the selected representation. + + If-None-Match can also be used with a value of "*" to prevent an + unsafe request method (e.g., PUT) from inadvertently modifying an + existing representation of the target resource when the client + believes that the resource does not have a current representation + (Section 4.2.1 of [RFC7231]). This is a variation on the "lost + update" problem that might arise if more than one client attempts to + create an initial representation for the target resource. + + An origin server that receives an If-None-Match header field MUST + evaluate the condition prior to performing the method (Section 5). + If the field-value is "*", the condition is false if the origin + server has a current representation for the target resource. If the + field-value is a list of entity-tags, the condition is false if one + of the listed tags match the entity-tag of the selected + representation. + + An origin server MUST NOT perform the requested method if the + condition evaluates to false; instead, the origin server MUST respond + with either a) the 304 (Not Modified) status code if the request + method is GET or HEAD or b) the 412 (Precondition Failed) status code + for all other request methods. + + Requirements on cache handling of a received If-None-Match header + field are defined in Section 4.3.2 of [RFC7234]. + + + + + + + + + + +Fielding & Reschke Standards Track [Page 15] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +3.3. If-Modified-Since + + The "If-Modified-Since" header field makes a GET or HEAD request + method conditional on the selected representation's modification date + being more recent than the date provided in the field-value. + Transfer of the selected representation's data is avoided if that + data has not changed. + + If-Modified-Since = HTTP-date + + An example of the field is: + + If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT + + A recipient MUST ignore If-Modified-Since if the request contains an + If-None-Match header field; the condition in If-None-Match is + considered to be a more accurate replacement for the condition in + If-Modified-Since, and the two are only combined for the sake of + interoperating with older intermediaries that might not implement + If-None-Match. + + A recipient MUST ignore the If-Modified-Since header field if the + received field-value is not a valid HTTP-date, or if the request + method is neither GET nor HEAD. + + A recipient MUST interpret an If-Modified-Since field-value's + timestamp in terms of the origin server's clock. + + If-Modified-Since is typically used for two distinct purposes: 1) to + allow efficient updates of a cached representation that does not have + an entity-tag and 2) to limit the scope of a web traversal to + resources that have recently changed. + + When used for cache updates, a cache will typically use the value of + the cached message's Last-Modified field to generate the field value + of If-Modified-Since. This behavior is most interoperable for cases + where clocks are poorly synchronized or when the server has chosen to + only honor exact timestamp matches (due to a problem with + Last-Modified dates that appear to go "back in time" when the origin + server's clock is corrected or a representation is restored from an + archived backup). However, caches occasionally generate the field + value based on other data, such as the Date header field of the + cached message or the local clock time that the message was received, + particularly when the cached message does not contain a Last-Modified + field. + + + + + + +Fielding & Reschke Standards Track [Page 16] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + When used for limiting the scope of retrieval to a recent time + window, a user agent will generate an If-Modified-Since field value + based on either its own local clock or a Date header field received + from the server in a prior response. Origin servers that choose an + exact timestamp match based on the selected representation's + Last-Modified field will not be able to help the user agent limit its + data transfers to only those changed during the specified window. + + An origin server that receives an If-Modified-Since header field + SHOULD evaluate the condition prior to performing the method + (Section 5). The origin server SHOULD NOT perform the requested + method if the selected representation's last modification date is + earlier than or equal to the date provided in the field-value; + instead, the origin server SHOULD generate a 304 (Not Modified) + response, including only those metadata that are useful for + identifying or updating a previously cached response. + + Requirements on cache handling of a received If-Modified-Since header + field are defined in Section 4.3.2 of [RFC7234]. + +3.4. If-Unmodified-Since + + The "If-Unmodified-Since" header field makes the request method + conditional on the selected representation's last modification date + being earlier than or equal to the date provided in the field-value. + This field accomplishes the same purpose as If-Match for cases where + the user agent does not have an entity-tag for the representation. + + If-Unmodified-Since = HTTP-date + + An example of the field is: + + If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT + + A recipient MUST ignore If-Unmodified-Since if the request contains + an If-Match header field; the condition in If-Match is considered to + be a more accurate replacement for the condition in + If-Unmodified-Since, and the two are only combined for the sake of + interoperating with older intermediaries that might not implement + If-Match. + + A recipient MUST ignore the If-Unmodified-Since header field if the + received field-value is not a valid HTTP-date. + + A recipient MUST interpret an If-Unmodified-Since field-value's + timestamp in terms of the origin server's clock. + + + + + +Fielding & Reschke Standards Track [Page 17] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + If-Unmodified-Since is most often used with state-changing methods + (e.g., POST, PUT, DELETE) to prevent accidental overwrites when + multiple user agents might be acting in parallel on a resource that + does not supply entity-tags with its representations (i.e., to + prevent the "lost update" problem). It can also be used with safe + methods to abort a request if the selected representation does not + match one already stored (or partially stored) from a prior request. + + An origin server that receives an If-Unmodified-Since header field + MUST evaluate the condition prior to performing the method + (Section 5). The origin server MUST NOT perform the requested method + if the selected representation's last modification date is more + recent than the date provided in the field-value; instead the origin + server MUST respond with either a) the 412 (Precondition Failed) + status code or b) one of the 2xx (Successful) status codes if the + origin server has verified that a state change is being requested and + the final state is already reflected in the current state of the + target resource (i.e., the change requested by the user agent has + already succeeded, but the user agent might not be aware of that + because the prior response message was lost or a compatible change + was made by some other user agent). In the latter case, the origin + server MUST NOT send a validator header field in the response unless + it can verify that the request is a duplicate of an immediately prior + change made by the same user agent. + + The If-Unmodified-Since header field can be ignored by caches and + intermediaries because it is not applicable to a stored response. + +3.5. If-Range + + The "If-Range" header field provides a special conditional request + mechanism that is similar to the If-Match and If-Unmodified-Since + header fields but that instructs the recipient to ignore the Range + header field if the validator doesn't match, resulting in transfer of + the new selected representation instead of a 412 (Precondition + Failed) response. If-Range is defined in Section 3.2 of [RFC7233]. + +4. Status Code Definitions + +4.1. 304 Not Modified + + The 304 (Not Modified) status code indicates that a conditional GET + or HEAD request has been received and would have resulted in a 200 + (OK) response if it were not for the fact that the condition + evaluated to false. In other words, there is no need for the server + to transfer a representation of the target resource because the + request indicates that the client, which made the request + + + + +Fielding & Reschke Standards Track [Page 18] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + conditional, already has a valid representation; the server is + therefore redirecting the client to make use of that stored + representation as if it were the payload of a 200 (OK) response. + + The server generating a 304 response MUST generate any of the + following header fields that would have been sent in a 200 (OK) + response to the same request: Cache-Control, Content-Location, Date, + ETag, Expires, and Vary. + + Since the goal of a 304 response is to minimize information transfer + when the recipient already has one or more cached representations, a + sender SHOULD NOT generate representation metadata other than the + above listed fields unless said metadata exists for the purpose of + guiding cache updates (e.g., Last-Modified might be useful if the + response does not have an ETag field). + + Requirements on a cache that receives a 304 response are defined in + Section 4.3.4 of [RFC7234]. If the conditional request originated + with an outbound client, such as a user agent with its own cache + sending a conditional GET to a shared proxy, then the proxy SHOULD + forward the 304 response to that client. + + A 304 response cannot contain a message-body; it is always terminated + by the first empty line after the header fields. + +4.2. 412 Precondition Failed + + The 412 (Precondition Failed) status code indicates that one or more + conditions given in the request header fields evaluated to false when + tested on the server. This response code allows the client to place + preconditions on the current resource state (its current + representations and metadata) and, thus, prevent the request method + from being applied if the target resource is in an unexpected state. + +5. Evaluation + + Except when excluded below, a recipient cache or origin server MUST + evaluate received request preconditions after it has successfully + performed its normal request checks and just before it would perform + the action associated with the request method. A server MUST ignore + all received preconditions if its response to the same request + without those conditions would have been a status code other than a + 2xx (Successful) or 412 (Precondition Failed). In other words, + redirects and failures take precedence over the evaluation of + preconditions in conditional requests. + + + + + + +Fielding & Reschke Standards Track [Page 19] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + A server that is not the origin server for the target resource and + cannot act as a cache for requests on the target resource MUST NOT + evaluate the conditional request header fields defined by this + specification, and it MUST forward them if the request is forwarded, + since the generating client intends that they be evaluated by a + server that can provide a current representation. Likewise, a server + MUST ignore the conditional request header fields defined by this + specification when received with a request method that does not + involve the selection or modification of a selected representation, + such as CONNECT, OPTIONS, or TRACE. + + Conditional request header fields that are defined by extensions to + HTTP might place conditions on all recipients, on the state of the + target resource in general, or on a group of resources. For + instance, the "If" header field in WebDAV can make a request + conditional on various aspects of multiple resources, such as locks, + if the recipient understands and implements that field ([RFC4918], + Section 10.4). + + Although conditional request header fields are defined as being + usable with the HEAD method (to keep HEAD's semantics consistent with + those of GET), there is no point in sending a conditional HEAD + because a successful response is around the same size as a 304 (Not + Modified) response and more useful than a 412 (Precondition Failed) + response. + +6. Precedence + + When more than one conditional request header field is present in a + request, the order in which the fields are evaluated becomes + important. In practice, the fields defined in this document are + consistently implemented in a single, logical order, since "lost + update" preconditions have more strict requirements than cache + validation, a validated cache is more efficient than a partial + response, and entity tags are presumed to be more accurate than date + validators. + + A recipient cache or origin server MUST evaluate the request + preconditions defined by this specification in the following order: + + 1. When recipient is the origin server and If-Match is present, + evaluate the If-Match precondition: + + * if true, continue to step 3 + + * if false, respond 412 (Precondition Failed) unless it can be + determined that the state-changing request has already + succeeded (see Section 3.1) + + + +Fielding & Reschke Standards Track [Page 20] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + 2. When recipient is the origin server, If-Match is not present, and + If-Unmodified-Since is present, evaluate the If-Unmodified-Since + precondition: + + * if true, continue to step 3 + + * if false, respond 412 (Precondition Failed) unless it can be + determined that the state-changing request has already + succeeded (see Section 3.4) + + 3. When If-None-Match is present, evaluate the If-None-Match + precondition: + + * if true, continue to step 5 + + * if false for GET/HEAD, respond 304 (Not Modified) + + * if false for other methods, respond 412 (Precondition Failed) + + 4. When the method is GET or HEAD, If-None-Match is not present, and + If-Modified-Since is present, evaluate the If-Modified-Since + precondition: + + * if true, continue to step 5 + + * if false, respond 304 (Not Modified) + + 5. When the method is GET and both Range and If-Range are present, + evaluate the If-Range precondition: + + * if the validator matches and the Range specification is + applicable to the selected representation, respond 206 + (Partial Content) [RFC7233] + + 6. Otherwise, + + * all conditions are met, so perform the requested action and + respond according to its success or failure. + + Any extension to HTTP/1.1 that defines additional conditional request + header fields ought to define its own expectations regarding the + order for evaluating such fields in relation to those defined in this + document and other conditionals that might be found in practice. + + + + + + + + +Fielding & Reschke Standards Track [Page 21] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +7. IANA Considerations + +7.1. Status Code Registration + + The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located + at has been + updated with the registrations below: + + +-------+---------------------+-------------+ + | Value | Description | Reference | + +-------+---------------------+-------------+ + | 304 | Not Modified | Section 4.1 | + | 412 | Precondition Failed | Section 4.2 | + +-------+---------------------+-------------+ + +7.2. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + This document defines the following HTTP header fields, so their + associated registry entries have been updated according to the + permanent registrations below (see [BCP90]): + + +---------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +---------------------+----------+----------+-------------+ + | ETag | http | standard | Section 2.3 | + | If-Match | http | standard | Section 3.1 | + | If-Modified-Since | http | standard | Section 3.3 | + | If-None-Match | http | standard | Section 3.2 | + | If-Unmodified-Since | http | standard | Section 3.4 | + | Last-Modified | http | standard | Section 2.2 | + +---------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +8. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns specific to the HTTP conditional + request mechanisms. More general security considerations are + addressed in HTTP "Message Syntax and Routing" [RFC7230] and + "Semantics and Content" [RFC7231]. + + + + + +Fielding & Reschke Standards Track [Page 22] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + + The validators defined by this specification are not intended to + ensure the validity of a representation, guard against malicious + changes, or detect man-in-the-middle attacks. At best, they enable + more efficient cache updates and optimistic concurrent writes when + all participants are behaving nicely. At worst, the conditions will + fail and the client will receive a response that is no more harmful + than an HTTP exchange without conditional requests. + + An entity-tag can be abused in ways that create privacy risks. For + example, a site might deliberately construct a semantically invalid + entity-tag that is unique to the user or user agent, send it in a + cacheable response with a long freshness time, and then read that + entity-tag in later conditional requests as a means of re-identifying + that user or user agent. Such an identifying tag would become a + persistent identifier for as long as the user agent retained the + original cache entry. User agents that cache representations ought + to ensure that the cache is cleared or replaced whenever the user + performs privacy-maintaining actions, such as clearing stored cookies + or changing to a private browsing mode. + +9. Acknowledgments + + See Section 10 of [RFC7230]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 23] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + RFC 7233, June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + +10.2. Informative References + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed + Authoring and Versioning (WebDAV)", RFC 4918, June 2007. + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 24] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Appendix A. Changes from RFC 2616 + + The definition of validator weakness has been expanded and clarified. + (Section 2.1) + + Weak entity-tags are now allowed in all requests except range + requests. (Sections 2.1 and 3.2) + + The ETag header field ABNF has been changed to not use quoted-string, + thus avoiding escaping issues. (Section 2.3) + + ETag is defined to provide an entity tag for the selected + representation, thereby clarifying what it applies to in various + situations (such as a PUT response). (Section 2.3) + + The precedence for evaluation of conditional requests has been + defined. (Section 6) + +Appendix B. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: 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), LF (line feed), OCTET (any + 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII + character). + + The rules below are defined in [RFC7230]: + + OWS = + obs-text = + + The rules below are defined in other parts: + + HTTP-date = + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 25] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Appendix C. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + ETag = entity-tag + + HTTP-date = + + If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS + entity-tag ] ) ) + If-Modified-Since = HTTP-date + If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS + entity-tag ] ) ) + If-Unmodified-Since = HTTP-date + + Last-Modified = HTTP-date + + OWS = + + entity-tag = [ weak ] opaque-tag + etagc = "!" / %x23-7E ; '#'-'~' + / obs-text + + obs-text = + opaque-tag = DQUOTE *etagc DQUOTE + + weak = %x57.2F ; W/ + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 26] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Index + + 3 + 304 Not Modified (status code) 19 + + 4 + 412 Precondition Failed (status code) 18 + + E + ETag header field 9 + + G + Grammar + entity-tag 9 + ETag 9 + etagc 9 + If-Match 13 + If-Modified-Since 15 + If-None-Match 14 + If-Unmodified-Since 17 + Last-Modified 7 + opaque-tag 9 + weak 9 + + I + If-Match header field 13 + If-Modified-Since header field 16 + If-None-Match header field 14 + If-Unmodified-Since header field 17 + + L + Last-Modified header field 7 + + M + metadata 5 + + S + selected representation 4 + + V + validator 5 + strong 5 + weak 5 + + + + + + + + +Fielding & Reschke Standards Track [Page 27] + +RFC 7232 HTTP/1.1 Conditional Requests June 2014 + + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 28] + === added file 'doc/rfc/rfc7233.txt' --- doc/rfc/rfc7233.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7233.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7233 Adobe +Obsoletes: 2616 Y. Lafon, Ed. +Category: Standards Track W3C +ISSN: 2070-1721 J. Reschke, Ed. + greenbytes + June 2014 + + + Hypertext Transfer Protocol (HTTP/1.1): Range Requests + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document defines range requests and the rules for + constructing and combining responses to those requests. + +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/rfc7233. + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 1] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 2] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Conformance and Error Handling .............................4 + 1.2. Syntax Notation ............................................4 + 2. Range Units .....................................................5 + 2.1. Byte Ranges ................................................5 + 2.2. Other Range Units ..........................................7 + 2.3. Accept-Ranges ..............................................7 + 3. Range Requests ..................................................8 + 3.1. Range ......................................................8 + 3.2. If-Range ...................................................9 + 4. Responses to a Range Request ...................................10 + 4.1. 206 Partial Content .......................................10 + 4.2. Content-Range .............................................12 + 4.3. Combining Ranges ..........................................14 + 4.4. 416 Range Not Satisfiable .................................15 + 5. IANA Considerations ............................................16 + 5.1. Range Unit Registry .......................................16 + 5.1.1. Procedure ..........................................16 + 5.1.2. Registrations ......................................16 + 5.2. Status Code Registration ..................................17 + 5.3. Header Field Registration .................................17 + 5.4. Internet Media Type Registration ..........................17 + 5.4.1. Internet Media Type multipart/byteranges ...........18 + 6. Security Considerations ........................................19 + 6.1. Denial-of-Service Attacks Using Range .....................19 + 7. Acknowledgments ................................................19 + 8. References .....................................................20 + 8.1. Normative References ......................................20 + 8.2. Informative References ....................................20 + Appendix A. Internet Media Type multipart/byteranges ..............21 + Appendix B. Changes from RFC 2616 .................................22 + Appendix C. Imported ABNF .........................................22 + Appendix D. Collected ABNF ........................................23 + Index .............................................................24 + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 3] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +1. Introduction + + Hypertext Transfer Protocol (HTTP) clients often encounter + interrupted data transfers as a result of canceled requests or + dropped connections. When a client has stored a partial + representation, it is desirable to request the remainder of that + representation in a subsequent request rather than transfer the + entire representation. Likewise, devices with limited local storage + might benefit from being able to request only a subset of a larger + representation, such as a single page of a very large document, or + the dimensions of an embedded image. + + This document defines HTTP/1.1 range requests, partial responses, and + the multipart/byteranges media type. Range requests are an OPTIONAL + feature of HTTP, designed so that recipients not implementing this + feature (or not supporting it for the target resource) can respond as + if it is a normal GET request without impacting interoperability. + Partial responses are indicated by a distinct status code to not be + mistaken for full responses by caches that might not implement the + feature. + + Although the range request mechanism is designed to allow for + extensible range types, this specification only defines requests for + byte ranges. + +1.1. Conformance and Error Handling + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + repetition). Appendix C describes rules imported from other + documents. Appendix D shows the collected grammar with all list + operators expanded to standard ABNF notation. + + + + + + + + +Fielding, et al. Standards Track [Page 4] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +2. Range Units + + A representation can be partitioned into subranges according to + various structural units, depending on the structure inherent in the + representation's media type. This "range unit" is used in the + Accept-Ranges (Section 2.3) response header field to advertise + support for range requests, the Range (Section 3.1) request header + field to delineate the parts of a representation that are requested, + and the Content-Range (Section 4.2) payload header field to describe + which part of a representation is being transferred. + + range-unit = bytes-unit / other-range-unit + +2.1. Byte Ranges + + Since representation data is transferred in payloads as a sequence of + octets, a byte range is a meaningful substructure for any + representation transferable over HTTP (Section 3 of [RFC7231]). The + "bytes" range unit is defined for expressing subranges of the data's + octet sequence. + + bytes-unit = "bytes" + + A byte-range request can specify a single range of bytes or a set of + ranges within a single representation. + + 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. + + Examples of byte-ranges-specifier values: + + 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 + + + + + +Fielding, et al. Standards Track [Page 5] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + A byte-range-spec is invalid if the last-byte-pos value is present + and less than the first-byte-pos. + + A client can limit the number of bytes requested without knowing the + size of the selected representation. If the last-byte-pos value is + absent, or if the value is greater than or equal to the current + length of the representation data, the byte range is interpreted as + the remainder of the representation (i.e., the server replaces the + value of last-byte-pos with a value that is one less than the current + length of the selected representation). + + A client can request the last N bytes of the selected representation + using a suffix-byte-range-spec. + + suffix-byte-range-spec = "-" suffix-length + suffix-length = 1*DIGIT + + If the selected representation is shorter than the specified + suffix-length, the entire representation is used. + + Additional examples, assuming a representation of length 10000: + + o The final 500 bytes (byte offsets 9500-9999, inclusive): + + bytes=-500 + + Or: + + bytes=9500- + + o The first and last bytes only (bytes 0 and 9999): + + bytes=0-0,-1 + + o Other valid (but not canonical) specifications of the second 500 + bytes (byte offsets 500-999, inclusive): + + bytes=500-600,601-999 + bytes=500-700,601-999 + + If a valid byte-range-set includes at least one byte-range-spec with + a first-byte-pos that is less than the current length of the + representation, 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. + + + + + + +Fielding, et al. Standards Track [Page 6] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + In the byte-range syntax, first-byte-pos, last-byte-pos, and + suffix-length are expressed as decimal number of octets. Since there + is no predefined limit to the length of a payload, recipients MUST + anticipate potentially large decimal numerals and prevent parsing + errors due to integer conversion overflows. + +2.2. Other Range Units + + Range units are intended to be extensible. New range units ought to + be registered with IANA, as defined in Section 5.1. + + other-range-unit = token + +2.3. Accept-Ranges + + The "Accept-Ranges" header field allows a server to indicate that it + supports range requests for the target resource. + + Accept-Ranges = acceptable-ranges + acceptable-ranges = 1#range-unit / "none" + + An origin server that supports byte-range requests for a given target + resource MAY send + + Accept-Ranges: bytes + + to indicate what range units are supported. A client MAY generate + range requests without having received this header field for the + resource involved. Range units are defined in Section 2. + + A server that does not support any kind of range request for the + target resource MAY send + + Accept-Ranges: none + + to advise the client not to attempt a range request. + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 7] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +3. Range Requests + +3.1. Range + + The "Range" header field on a GET request modifies the method + semantics to request transfer of only one or more subranges of the + selected representation data, rather than the entire selected + representation data. + + Range = byte-ranges-specifier / other-ranges-specifier + other-ranges-specifier = other-range-unit "=" other-range-set + other-range-set = 1*VCHAR + + A server MAY ignore the Range header field. However, origin servers + and intermediate caches ought to support byte ranges when possible, + since Range supports efficient recovery from partially failed + transfers and partial retrieval of large representations. A server + MUST ignore a Range header field received with a request method other + than GET. + + An origin server MUST ignore a Range header field that contains a + range unit it does not understand. A proxy MAY discard a Range + header field that contains a range unit it does not understand. + + A server that supports range requests MAY ignore or reject a Range + header field that consists of more than two overlapping ranges, or a + set of many small ranges that are not listed in ascending order, + since both are indications of either a broken client or a deliberate + denial-of-service attack (Section 6.1). A client SHOULD NOT request + multiple ranges that are inherently less efficient to process and + transfer than a single range that encompasses the same data. + + A client that is requesting multiple ranges SHOULD list those ranges + in ascending order (the order in which they would typically be + received in a complete representation) unless there is a specific + need to request a later part earlier. For example, a user agent + processing a large representation with an internal catalog of parts + might need to request later parts first, particularly if the + representation consists of pages stored in reverse order and the user + agent wishes to transfer one page at a time. + + The Range header field is evaluated after evaluating the precondition + header fields defined in [RFC7232], and only if the result in absence + of the Range header field would be a 200 (OK) response. In other + words, Range is ignored when a conditional GET would result in a 304 + (Not Modified) response. + + + + + +Fielding, et al. Standards Track [Page 8] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The If-Range header field (Section 3.2) can be used as a precondition + to applying the Range header field. + + If all of the preconditions are true, the server supports the Range + header field for the target resource, and the specified range(s) are + valid and satisfiable (as defined in Section 2.1), the server SHOULD + send a 206 (Partial Content) response with a payload containing one + or more partial representations that correspond to the satisfiable + ranges requested, as defined in Section 4. + + If all of the preconditions are true, the server supports the Range + header field for the target resource, and the specified range(s) are + invalid or unsatisfiable, the server SHOULD send a 416 (Range Not + Satisfiable) response. + +3.2. If-Range + + If a client has a partial copy of a representation and wishes to have + an up-to-date copy of the entire representation, it could use the + Range header field with a conditional GET (using either or both of + If-Unmodified-Since and If-Match.) However, if the precondition + fails because the representation has been modified, the client would + then have to make a second request to obtain the entire current + representation. + + The "If-Range" header field allows a client to "short-circuit" the + second request. Informally, its meaning is as follows: if the + representation is unchanged, send me the part(s) that I am requesting + in Range; otherwise, send me the entire representation. + + If-Range = entity-tag / HTTP-date + + A client MUST NOT generate an If-Range header field in a request that + does not contain a Range header field. A server MUST ignore an + If-Range header field received in a request that does not contain a + Range header field. An origin server MUST ignore an If-Range header + field received in a request for a target resource that does not + support Range requests. + + A client MUST NOT generate an If-Range header field containing an + entity-tag that is marked as weak. A client MUST NOT generate an + If-Range header field containing an HTTP-date unless the client has + no entity-tag for the corresponding representation and the date is a + strong validator in the sense defined by Section 2.2.2 of [RFC7232]. + + A server that evaluates an If-Range precondition MUST use the strong + comparison function when comparing entity-tags (Section 2.3.2 of + [RFC7232]) and MUST evaluate the condition as false if an HTTP-date + + + +Fielding, et al. Standards Track [Page 9] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + validator is provided that is not a strong validator in the sense + defined by Section 2.2.2 of [RFC7232]. A valid entity-tag can be + distinguished from a valid HTTP-date by examining the first two + characters for a DQUOTE. + + If the validator given in the If-Range header field matches the + current validator for the selected representation of the target + resource, then the server SHOULD process the Range header field as + requested. If the validator does not match, the server MUST ignore + the Range header field. Note that this comparison by exact match, + including when the validator is an HTTP-date, differs from the + "earlier than or equal to" comparison used when evaluating an + If-Unmodified-Since conditional. + +4. Responses to a Range Request + +4.1. 206 Partial Content + + The 206 (Partial Content) status code indicates that the server is + successfully fulfilling a range request for the target resource by + transferring one or more parts of the selected representation that + correspond to the satisfiable ranges found in the request's Range + header field (Section 3.1). + + If a single part is being transferred, the server generating the 206 + response MUST generate a Content-Range header field, describing what + range of the selected representation is enclosed, and a payload + consisting of the range. 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 + + ... 26012 bytes of partial image data ... + + If multiple parts are being transferred, the server generating the + 206 response MUST generate a "multipart/byteranges" payload, as + defined in Appendix A, and a Content-Type header field containing the + multipart/byteranges media type and its required boundary parameter. + To avoid confusion with single-part responses, a server MUST NOT + generate a Content-Range header field in the HTTP header section of a + multiple part response (this field will be sent in each part + instead). + + + + + +Fielding, et al. Standards Track [Page 10] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + Within the header area of each body part in the multipart payload, + the server MUST generate a Content-Range header field corresponding + to the range being enclosed in that body part. If the selected + representation would have had a Content-Type header field in a 200 + (OK) response, the server SHOULD generate that same Content-Type + field in the header area of each body part. 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-Length: 1741 + 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-- + + When multiple ranges are requested, a server MAY coalesce any of the + ranges that overlap, or that are separated by a gap that is smaller + than the overhead of sending multiple parts, regardless of the order + in which the corresponding byte-range-spec appeared in the received + Range header field. Since the typical overhead between parts of a + multipart/byteranges payload is around 80 bytes, depending on the + selected representation's media type and the chosen boundary + parameter length, it can be less efficient to transfer many small + disjoint parts than it is to transfer the entire selected + representation. + + A server MUST NOT generate a multipart response to a request for a + single range, since a client that does not request multiple parts + might not support multipart responses. However, a server MAY + generate a multipart/byteranges payload with only a single body part + if multiple ranges were requested and only one range was found to be + satisfiable or only one range remained after coalescing. A client + that cannot process a multipart/byteranges response MUST NOT generate + a request that asks for multiple ranges. + + When a multipart response payload is generated, the server SHOULD + send the parts in the same order that the corresponding + byte-range-spec appeared in the received Range header field, + + + +Fielding, et al. Standards Track [Page 11] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + excluding those ranges that were deemed unsatisfiable or that were + coalesced into other ranges. A client that receives a multipart + response MUST inspect the Content-Range header field present in each + body part in order to determine which range is contained in that body + part; a client cannot rely on receiving the same ranges that it + requested, nor the same order that it requested. + + When a 206 response is generated, the server MUST generate the + following header fields, in addition to those required above, if the + field would have been sent in a 200 (OK) response to the same + request: Date, Cache-Control, ETag, Expires, Content-Location, and + Vary. + + If a 206 is generated in response to a request with an If-Range + header field, the sender SHOULD NOT generate other representation + header fields beyond those required above, because the client is + understood to already have a prior response containing those header + fields. Otherwise, the sender MUST generate all of the + representation header fields that would have been sent in a 200 (OK) + response to the same request. + + A 206 response is cacheable by default; i.e., unless otherwise + indicated by explicit cache controls (see Section 4.2.2 of + [RFC7234]). + +4.2. Content-Range + + The "Content-Range" header field is sent in a single part 206 + (Partial Content) response to indicate the partial range of the + selected representation enclosed as the message payload, sent in each + part of a multipart 206 response to indicate the range enclosed + within each body part, and sent in 416 (Range Not Satisfiable) + responses to provide information about the selected representation. + + Content-Range = byte-content-range + / other-content-range + + byte-content-range = bytes-unit SP + ( byte-range-resp / unsatisfied-range ) + + byte-range-resp = byte-range "/" ( complete-length / "*" ) + byte-range = first-byte-pos "-" last-byte-pos + unsatisfied-range = "*/" complete-length + + complete-length = 1*DIGIT + + other-content-range = other-range-unit SP other-range-resp + other-range-resp = *CHAR + + + +Fielding, et al. Standards Track [Page 12] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + If a 206 (Partial Content) response contains a Content-Range header + field with a range unit (Section 2) that the recipient does not + understand, the recipient MUST NOT attempt to recombine it with a + stored representation. A proxy that receives such a message SHOULD + forward it downstream. + + For byte ranges, a sender SHOULD indicate the complete length of the + representation from which the range has been extracted, unless the + complete length is unknown or difficult to determine. An asterisk + character ("*") in place of the complete-length indicates that the + representation length was unknown when the header field was + generated. + + The following example illustrates when the complete length of the + selected representation is known by the sender to be 1234 bytes: + + Content-Range: bytes 42-1233/1234 + + and this second example illustrates when the complete length is + unknown: + + Content-Range: bytes 42-1233/* + + A Content-Range field value is invalid if it contains a + byte-range-resp that has a last-byte-pos value less than its + first-byte-pos value, or a complete-length value less than or equal + to its last-byte-pos value. The recipient of an invalid + Content-Range MUST NOT attempt to recombine the received content with + a stored representation. + + A server generating a 416 (Range Not Satisfiable) response to a + byte-range request SHOULD send a Content-Range header field with an + unsatisfied-range value, as in the following example: + + Content-Range: bytes */1234 + + The complete-length in a 416 response indicates the current length of + the selected representation. + + The Content-Range header field has no meaning for status codes that + do not explicitly describe its semantic. For this specification, + only the 206 (Partial Content) and 416 (Range Not Satisfiable) status + codes describe a meaning for Content-Range. + + + + + + + + +Fielding, et al. Standards Track [Page 13] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The following are examples of Content-Range values in which the + selected representation contains a total of 1234 bytes: + + o The first 500 bytes: + + Content-Range: bytes 0-499/1234 + + o The second 500 bytes: + + Content-Range: bytes 500-999/1234 + + o All except for the first 500 bytes: + + Content-Range: bytes 500-1233/1234 + + o The last 500 bytes: + + Content-Range: bytes 734-1233/1234 + +4.3. Combining Ranges + + A response might transfer only a subrange of a representation if the + connection closed prematurely or if the request used one or more + Range specifications. After several such transfers, a client might + have received several ranges of the same representation. These + ranges can only be safely combined if they all have in common the + same strong validator (Section 2.1 of [RFC7232]). + + A client that has received multiple partial responses to GET requests + on a target resource MAY combine those responses into a larger + continuous range if they share the same strong validator. + + If the most recent response is an incomplete 200 (OK) response, then + the header fields of that response are used for any combined response + and replace those of the matching stored responses. + + If the most recent response is a 206 (Partial Content) response and + at least one of the matching stored responses is a 200 (OK), then the + combined response header fields consist of the most recent 200 + response's header fields. If all of the matching stored responses + are 206 responses, then the stored response with the most recent + header fields is used as the source of header fields for the combined + response, except that the client MUST use other header fields + provided in the new response, aside from Content-Range, to replace + all instances of the corresponding header fields in the stored + response. + + + + + +Fielding, et al. Standards Track [Page 14] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + The combined response message body consists of the union of partial + content ranges in the new response and each of the selected + responses. If the union consists of the entire range of the + representation, then the client MUST process the combined response as + if it were a complete 200 (OK) response, including a Content-Length + header field that reflects the complete length. Otherwise, the + client MUST process the set of continuous ranges as one of the + following: an incomplete 200 (OK) response if the combined response + is a prefix of the representation, a single 206 (Partial Content) + response containing a multipart/byteranges body, or multiple 206 + (Partial Content) responses, each with one continuous range that is + indicated by a Content-Range header field. + +4.4. 416 Range Not Satisfiable + + The 416 (Range Not Satisfiable) status code indicates that none of + the ranges in the request's Range header field (Section 3.1) overlap + the current extent of the selected resource or that the set of ranges + requested has been rejected due to invalid ranges or an excessive + request of small or overlapping ranges. + + For byte ranges, failing to overlap the current extent means that the + first-byte-pos of all of the byte-range-spec values were greater than + the current length of the selected representation. When this status + code is generated in response to a byte-range request, the sender + SHOULD generate a Content-Range header field specifying the current + length of the selected representation (Section 4.2). + + For example: + + HTTP/1.1 416 Range Not Satisfiable + Date: Fri, 20 Jan 2012 15:41:54 GMT + Content-Range: bytes */47022 + + Note: Because servers are free to ignore Range, many + implementations will simply respond with the entire selected + representation in a 200 (OK) response. That is partly because + most clients are prepared to receive a 200 (OK) to complete the + task (albeit less efficiently) and partly because clients might + not stop making an invalid partial request until they have + received a complete representation. Thus, clients cannot depend + on receiving a 416 (Range Not Satisfiable) response even when it + is most appropriate. + + + + + + + + +Fielding, et al. Standards Track [Page 15] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5. IANA Considerations + +5.1. Range Unit Registry + + The "HTTP Range Unit Registry" defines the namespace for the range + unit names and refers to their corresponding specifications. The + registry has been created and is now maintained at + . + +5.1.1. Procedure + + Registration of an HTTP Range Unit MUST include the following fields: + + o Name + + o Description + + o Pointer to specification text + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + +5.1.2. Registrations + + The initial range unit registry contains the registrations below: + + +-------------+---------------------------------------+-------------+ + | Range Unit | Description | Reference | + | Name | | | + +-------------+---------------------------------------+-------------+ + | bytes | a range of octets | Section 2.1 | + | none | reserved as keyword, indicating no | Section 2.3 | + | | ranges are supported | | + +-------------+---------------------------------------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 16] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5.2. Status Code Registration + + The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located + at has been + updated to include the registrations below: + + +-------+-----------------------+-------------+ + | Value | Description | Reference | + +-------+-----------------------+-------------+ + | 206 | Partial Content | Section 4.1 | + | 416 | Range Not Satisfiable | Section 4.4 | + +-------+-----------------------+-------------+ + +5.3. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + This document defines the following HTTP header fields, so their + associated registry entries have been updated according to the + permanent registrations below (see [BCP90]): + + +-------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-------------+ + | Accept-Ranges | http | standard | Section 2.3 | + | Content-Range | http | standard | Section 4.2 | + | If-Range | http | standard | Section 3.2 | + | Range | http | standard | Section 3.1 | + +-------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +5.4. Internet Media Type Registration + + IANA maintains the registry of Internet media types [BCP13] at + . + + This document serves as the specification for the Internet media type + "multipart/byteranges". The following has been registered with IANA. + + + + + + + + + +Fielding, et al. Standards Track [Page 17] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +5.4.1. Internet Media Type multipart/byteranges + + Type name: multipart + + Subtype name: byteranges + + Required parameters: boundary + + Optional parameters: N/A + + Encoding considerations: only "7bit", "8bit", or "binary" are + permitted + + Security considerations: see Section 6 + + Interoperability considerations: N/A + + Published specification: This specification (see Appendix A). + + Applications that use this media type: HTTP components supporting + multiple ranges in a single request. + + 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 + Authors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + + + + + + + +Fielding, et al. Standards Track [Page 18] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +6. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns specific to the HTTP range + request mechanisms. More general security considerations are + addressed in HTTP messaging [RFC7230] and semantics [RFC7231]. + +6.1. Denial-of-Service Attacks Using Range + + Unconstrained multiple range requests are susceptible to denial-of- + service attacks because the effort required to request many + overlapping ranges of the same data is tiny compared to the time, + memory, and bandwidth consumed by attempting to serve the requested + data in many parts. Servers ought to ignore, coalesce, or reject + egregious range requests, such as requests for more than two + overlapping ranges or for many small ranges in a single set, + particularly when the ranges are requested out of order for no + apparent reason. Multipart range requests are not designed to + support random access. + +7. Acknowledgments + + See Section 10 of [RFC7230]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 19] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +8. References + +8.1. Normative References + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + +8.2. Informative References + + [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, January 2013. + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + + + +Fielding, et al. Standards Track [Page 20] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix A. Internet Media Type multipart/byteranges + + When a 206 (Partial Content) response message includes the content of + multiple ranges, they are transmitted as body parts in a multipart + message body ([RFC2046], Section 5.1) with the media type of + "multipart/byteranges". + + The multipart/byteranges media type includes one or more body 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. + + Implementation Notes: + + 1. Additional CRLFs might precede the first boundary string in the + body. + + 2. Although [RFC2046] permits the boundary string to be quoted, some + existing implementations handle a quoted boundary string + incorrectly. + + 3. A number of clients and servers were coded to an early draft of + the byteranges specification that used a media type of multipart/ + x-byteranges, which is almost (but not quite) compatible with + this type. + + Despite the name, the "multipart/byteranges" media type is not + limited to byte ranges. The following example uses an "exampleunit" + range unit: + + HTTP/1.1 206 Partial Content + Date: Tue, 14 Nov 1995 06:25:24 GMT + Last-Modified: Tue, 14 July 04:58:08 GMT + Content-Length: 2331785 + Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES + + --THIS_STRING_SEPARATES + Content-Type: video/example + Content-Range: exampleunit 1.2-4.3/25 + + ...the first range... + --THIS_STRING_SEPARATES + Content-Type: video/example + Content-Range: exampleunit 11.2-14.3/25 + + ...the second range + --THIS_STRING_SEPARATES-- + + + + +Fielding, et al. Standards Track [Page 21] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix B. Changes from RFC 2616 + + Servers are given more leeway in how they respond to a range request, + in order to mitigate abuse by malicious (or just greedy) clients. + (Section 3.1) + + A weak validator cannot be used in a 206 response. (Section 4.1) + + The Content-Range header field only has meaning when the status code + explicitly defines its use. (Section 4.2) + + This specification introduces a Range Unit Registry. (Section 5.1) + + multipart/byteranges can consist of a single part. (Appendix A) + +Appendix C. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: 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), LF (line feed), OCTET (any + 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII + character). + + Note that all rules derived from token are to be compared + case-insensitively, like range-unit and acceptable-ranges. + + The rules below are defined in [RFC7230]: + + OWS = + token = + + The rules below are defined in other parts: + + HTTP-date = + entity-tag = + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 22] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + +Appendix D. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + Accept-Ranges = acceptable-ranges + + Content-Range = byte-content-range / other-content-range + + HTTP-date = + + If-Range = entity-tag / HTTP-date + + OWS = + + Range = byte-ranges-specifier / other-ranges-specifier + + acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS + range-unit ] ) ) / "none" + + byte-content-range = bytes-unit SP ( byte-range-resp / + unsatisfied-range ) + byte-range = first-byte-pos "-" last-byte-pos + byte-range-resp = byte-range "/" ( complete-length / "*" ) + byte-range-set = *( "," OWS ) ( byte-range-spec / + suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / + suffix-byte-range-spec ) ] ) + byte-range-spec = first-byte-pos "-" [ last-byte-pos ] + byte-ranges-specifier = bytes-unit "=" byte-range-set + bytes-unit = "bytes" + + complete-length = 1*DIGIT + + entity-tag = + + first-byte-pos = 1*DIGIT + + last-byte-pos = 1*DIGIT + + other-content-range = other-range-unit SP other-range-resp + other-range-resp = *CHAR + other-range-set = 1*VCHAR + other-range-unit = token + other-ranges-specifier = other-range-unit "=" other-range-set + + range-unit = bytes-unit / other-range-unit + + suffix-byte-range-spec = "-" suffix-length + + + +Fielding, et al. Standards Track [Page 23] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + suffix-length = 1*DIGIT + + token = + + unsatisfied-range = "*/" complete-length + +Index + + 2 + 206 Partial Content (status code) 10 + + 4 + 416 Range Not Satisfiable (status code) 15 + + A + Accept-Ranges header field 7 + + C + Content-Range header field 12 + + G + Grammar + Accept-Ranges 7 + acceptable-ranges 7 + byte-content-range 12 + byte-range 12 + byte-range-resp 12 + byte-range-set 5 + byte-range-spec 5 + byte-ranges-specifier 5 + bytes-unit 5 + complete-length 12 + Content-Range 12 + first-byte-pos 5 + If-Range 9 + last-byte-pos 5 + other-content-range 12 + other-range-resp 12 + other-range-unit 5, 7 + Range 8 + range-unit 5 + ranges-specifier 5 + suffix-byte-range-spec 6 + suffix-length 6 + unsatisfied-range 12 + + + + + + +Fielding, et al. Standards Track [Page 24] + +RFC 7233 HTTP/1.1 Range Requests June 2014 + + + I + If-Range header field 9 + + M + Media Type + multipart/byteranges 18, 21 + multipart/x-byteranges 19 + multipart/byteranges Media Type 18, 21 + multipart/x-byteranges Media Type 21 + + R + Range header field 8 + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Yves Lafon (editor) + World Wide Web Consortium + W3C / ERCIM + 2004, rte des Lucioles + Sophia-Antipolis, AM 06902 + France + + EMail: ylafon@w3.org + URI: http://www.raubacapeu.net/people/yves/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + +Fielding, et al. Standards Track [Page 25] + === added file 'doc/rfc/rfc7234.txt' --- doc/rfc/rfc7234.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7234.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7234 Adobe +Obsoletes: 2616 M. Nottingham, Ed. +Category: Standards Track Akamai +ISSN: 2070-1721 J. Reschke, Ed. + greenbytes + June 2014 + + + Hypertext Transfer Protocol (HTTP/1.1): Caching + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document defines HTTP caches and the associated header + fields that control cache behavior or indicate cacheable response + messages. + +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/rfc7234. + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 1] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + 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 ....................................................4 + 1.1. Conformance and Error Handling .............................4 + 1.2. Syntax Notation ............................................4 + 1.2.1. Delta Seconds .......................................5 + 2. Overview of Cache Operation .....................................5 + 3. Storing Responses in Caches .....................................6 + 3.1. Storing Incomplete Responses ...............................7 + 3.2. Storing Responses to Authenticated Requests ................7 + 3.3. Combining Partial Content ..................................8 + 4. Constructing Responses from Caches ..............................8 + 4.1. Calculating Secondary Keys with Vary .......................9 + 4.2. Freshness .................................................11 + 4.2.1. Calculating Freshness Lifetime .....................12 + 4.2.2. Calculating Heuristic Freshness ....................13 + 4.2.3. Calculating Age ....................................13 + 4.2.4. Serving Stale Responses ............................15 + 4.3. Validation ................................................16 + 4.3.1. Sending a Validation Request .......................16 + 4.3.2. Handling a Received Validation Request .............16 + + + +Fielding, et al. Standards Track [Page 2] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + 4.3.3. Handling a Validation Response .....................18 + 4.3.4. Freshening Stored Responses upon Validation ........18 + 4.3.5. Freshening Responses via HEAD ......................19 + 4.4. Invalidation ..............................................20 + 5. Header Field Definitions .......................................21 + 5.1. Age .......................................................21 + 5.2. Cache-Control .............................................21 + 5.2.1. Request Cache-Control Directives ...................22 + 5.2.2. Response Cache-Control Directives ..................24 + 5.2.3. Cache Control Extensions ...........................27 + 5.3. Expires ...................................................28 + 5.4. Pragma ....................................................29 + 5.5. Warning ...................................................29 + 5.5.1. Warning: 110 - "Response is Stale" .................31 + 5.5.2. Warning: 111 - "Revalidation Failed" ...............31 + 5.5.3. Warning: 112 - "Disconnected Operation" ............31 + 5.5.4. Warning: 113 - "Heuristic Expiration" ..............31 + 5.5.5. Warning: 199 - "Miscellaneous Warning" .............32 + 5.5.6. Warning: 214 - "Transformation Applied" ............32 + 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32 + 6. History Lists ..................................................32 + 7. IANA Considerations ............................................32 + 7.1. Cache Directive Registry ..................................32 + 7.1.1. Procedure ..........................................32 + 7.1.2. Considerations for New Cache Control Directives ....33 + 7.1.3. Registrations ......................................33 + 7.2. Warn Code Registry ........................................34 + 7.2.1. Procedure ..........................................34 + 7.2.2. Registrations ......................................34 + 7.3. Header Field Registration .................................34 + 8. Security Considerations ........................................35 + 9. Acknowledgments ................................................36 + 10. References ....................................................36 + 10.1. Normative References .....................................36 + 10.2. Informative References ...................................37 + Appendix A. Changes from RFC 2616 .................................38 + Appendix B. Imported ABNF .........................................39 + Appendix C. Collected ABNF ........................................39 + Index .............................................................41 + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 3] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +1. Introduction + + HTTP is typically used for distributed information systems, where + performance can be improved by the use of response caches. This + document defines aspects of HTTP/1.1 related to caching and reusing + response messages. + + An HTTP cache is a local store of response messages and the subsystem + that controls storage, retrieval, and deletion of messages in it. 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 employ a cache, though a cache cannot be + used by a server that is acting as a tunnel. + + A shared cache is a cache that stores responses to be reused by more + than one user; shared caches are usually (but not always) deployed as + a part of an intermediary. A private cache, in contrast, is + dedicated to a single user; often, they are deployed as a component + of a user agent. + + The goal of caching in HTTP/1.1 is to significantly improve + performance by reusing a prior response message to satisfy a current + request. A stored response is considered "fresh", as defined in + Section 4.2, if the response can be reused without "validation" + (checking with the origin server to see if the cached response + remains valid for this request). A fresh response can therefore + reduce both latency and network overhead each time it is reused. + When a cached response is not fresh, it might still be reusable if it + can be freshened by validation (Section 4.3) or if the origin is + unavailable (Section 4.2.4). + +1.1. Conformance and Error Handling + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + + + + + +Fielding, et al. Standards Track [Page 4] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + repetition). Appendix B describes rules imported from other + documents. Appendix C shows the collected grammar with all list + operators expanded to standard ABNF notation. + +1.2.1. Delta Seconds + + The delta-seconds rule specifies a non-negative integer, representing + time in seconds. + + delta-seconds = 1*DIGIT + + A recipient parsing a delta-seconds value and converting it to binary + form ought to use an arithmetic type of at least 31 bits of + non-negative integer range. If a cache receives a delta-seconds + value greater than the greatest integer it can represent, or if any + of its subsequent calculations overflows, the cache MUST consider the + value to be either 2147483648 (2^31) or the greatest positive integer + it can conveniently represent. + + Note: The value 2147483648 is here for historical reasons, + effectively represents infinity (over 68 years), and does not need + to be stored in binary form; an implementation could produce it as + a canned string if any overflow occurs, even if the calculations + are performed with an arithmetic type incapable of directly + representing that number. What matters here is that an overflow + be detected and not treated as a negative value in later + calculations. + +2. Overview of Cache Operation + + Proper cache operation preserves the semantics of HTTP transfers + ([RFC7231]) while eliminating the transfer of information already + held in the cache. Although caching is an entirely OPTIONAL feature + of HTTP, it can be assumed that reusing a cached response is + desirable and that such reuse is the default behavior when no + requirement or local configuration prevents it. Therefore, HTTP + cache requirements are focused on preventing a cache from either + storing a non-reusable response or reusing a stored response + inappropriately, rather than mandating that caches always store and + reuse particular responses. + + Each cache entry consists of a cache key and one or more HTTP + responses corresponding to prior requests that used the same key. + The most common form of cache entry is a successful result of a + retrieval request: i.e., a 200 (OK) response to a GET request, which + contains a representation of the resource identified by the request + target (Section 4.3.1 of [RFC7231]). However, it is also possible to + cache permanent redirects, negative results (e.g., 404 (Not Found)), + + + +Fielding, et al. Standards Track [Page 5] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + incomplete results (e.g., 206 (Partial Content)), and responses to + methods other than GET if the method's definition allows such caching + and defines something suitable for use as a cache key. + + The primary cache key consists of the request method and target URI. + However, since HTTP caches in common use today are typically limited + to caching responses to GET, many caches simply decline other methods + and use only the URI as the primary cache key. + + If a request target is subject to content negotiation, its cache + entry might consist of multiple stored responses, each differentiated + by a secondary key for the values of the original request's selecting + header fields (Section 4.1). + +3. Storing Responses in Caches + + A cache MUST NOT store a response to any request, unless: + + o The request method is understood by the cache and defined as being + cacheable, and + + o the response status code is understood by the cache, and + + o the "no-store" cache directive (see Section 5.2) does not appear + in request or response header fields, and + + o the "private" response directive (see Section 5.2.2.6) does not + appear in the response, if the cache is shared, and + + o the Authorization header field (see Section 4.2 of [RFC7235]) does + not appear in the request, if the cache is shared, unless the + response explicitly allows it (see Section 3.2), and + + o the response either: + + * contains an Expires header field (see Section 5.3), or + + * contains a max-age response directive (see Section 5.2.2.8), or + + * contains a s-maxage response directive (see Section 5.2.2.9) + and the cache is shared, or + + * contains a Cache Control Extension (see Section 5.2.3) that + allows it to be cached, or + + * has a status code that is defined as cacheable by default (see + Section 4.2.2), or + + + + +Fielding, et al. Standards Track [Page 6] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + * contains a public response directive (see Section 5.2.2.5). + + Note that any of the requirements listed above can be overridden by a + cache-control extension; see Section 5.2.3. + + In this context, a cache has "understood" a request method or a + response status code if it recognizes it and implements all specified + caching-related behavior. + + Note that, in normal operation, some caches will not store a response + that has neither a cache validator nor an explicit expiration time, + as such responses are not usually useful to store. However, caches + are not prohibited from storing such responses. + +3.1. Storing Incomplete Responses + + A response message is considered complete when all of the octets + indicated by the message framing ([RFC7230]) are received prior to + the connection being closed. If the request method is GET, the + response status code is 200 (OK), and the entire response header + section has been received, a cache MAY store an incomplete response + message body if the cache entry is recorded as incomplete. Likewise, + a 206 (Partial Content) response MAY be stored as if it were an + incomplete 200 (OK) cache entry. However, a cache MUST NOT store + incomplete or partial-content responses if it does not support the + Range and Content-Range header fields or if it does not understand + the range units used in those fields. + + A cache MAY complete a stored incomplete response by making a + subsequent range request ([RFC7233]) and combining the successful + response with the stored entry, as defined in Section 3.3. A cache + MUST NOT use an incomplete response to answer requests unless the + response has been made complete or the request is partial and + specifies a range that is wholly within the incomplete response. A + cache MUST NOT send a partial response to a client without explicitly + marking it as such using the 206 (Partial Content) status code. + +3.2. Storing Responses to Authenticated Requests + + A shared cache MUST NOT use a cached response to a request with an + Authorization header field (Section 4.2 of [RFC7235]) to satisfy any + subsequent request unless a cache directive that allows such + responses to be stored is present in the response. + + In this specification, the following Cache-Control response + directives (Section 5.2.2) have such an effect: must-revalidate, + public, and s-maxage. + + + + +Fielding, et al. Standards Track [Page 7] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + Note that cached responses that contain the "must-revalidate" and/or + "s-maxage" response directives are not allowed to be served stale + (Section 4.2.4) by shared caches. In particular, a response with + either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to + satisfy a subsequent request without revalidating it on the origin + server. + +3.3. Combining Partial Content + + A response might transfer only a partial representation if the + connection closed prematurely or if the request used one or more + Range specifiers ([RFC7233]). After several such transfers, a cache + might have received several ranges of the same representation. A + cache MAY combine these ranges into a single stored response, and + reuse that response to satisfy later requests, if they all share the + same strong validator and the cache complies with the client + requirements in Section 4.3 of [RFC7233]. + + When combining the new response with one or more stored responses, a + cache MUST: + + o delete any Warning header fields in the stored response with + warn-code 1xx (see Section 5.5); + + o retain any Warning header fields in the stored response with + warn-code 2xx; and, + + o use other header fields provided in the new response, aside from + Content-Range, to replace all instances of the corresponding + header fields in the stored response. + +4. Constructing Responses from Caches + + When presented with a request, a cache MUST NOT reuse a stored + response, unless: + + o The presented effective request URI (Section 5.5 of [RFC7230]) and + that of the stored response match, and + + o the request method associated with the stored response allows it + to be used for the presented request, and + + o selecting header fields nominated by the stored response (if any) + match those presented (see Section 4.1), and + + + + + + + +Fielding, et al. Standards Track [Page 8] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + o the presented request does not contain the no-cache pragma + (Section 5.4), nor the no-cache cache directive (Section 5.2.1), + unless the stored response is successfully validated + (Section 4.3), and + + o the stored response does not contain the no-cache cache directive + (Section 5.2.2.2), unless it is successfully validated + (Section 4.3), and + + o the stored response is either: + + * fresh (see Section 4.2), or + + * allowed to be served stale (see Section 4.2.4), or + + * successfully validated (see Section 4.3). + + Note that any of the requirements listed above can be overridden by a + cache-control extension; see Section 5.2.3. + + When a stored response is used to satisfy a request without + validation, a cache MUST generate an Age header field (Section 5.1), + replacing any present in the response with a value equal to the + stored response's current_age; see Section 4.2.3. + + A cache MUST write through requests with methods that are unsafe + (Section 4.2.1 of [RFC7231]) to the origin server; i.e., a cache is + not allowed to generate a reply to such a request before having + forwarded the request and having received a corresponding response. + + Also, note that unsafe requests might invalidate already-stored + responses; see Section 4.4. + + When more than one suitable response is stored, a cache MUST use the + most recent response (as determined by the Date header field). It + can also forward the request with "Cache-Control: max-age=0" or + "Cache-Control: no-cache" to disambiguate which response to use. + + A cache that does not have a clock available MUST NOT use stored + responses without revalidating them upon every use. + +4.1. Calculating Secondary Keys with Vary + + When a cache receives a request that can be satisfied by a stored + response that has a Vary header field (Section 7.1.4 of [RFC7231]), + it MUST NOT use that response unless all of the selecting header + + + + + +Fielding, et al. Standards Track [Page 9] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + fields nominated by the Vary header field match in both the original + request (i.e., that associated with the stored response), and the + presented request. + + The selecting header fields from two requests are defined to match if + and only if those in the first request can be transformed to those in + the second request by applying any of the following: + + o adding or removing whitespace, where allowed in the header field's + syntax + + o combining multiple header fields with the same field name (see + Section 3.2 of [RFC7230]) + + o normalizing both header field values in a way that is known to + have identical semantics, according to the header field's + specification (e.g., reordering field values when order is not + significant; case-normalization, where values are defined to be + case-insensitive) + + If (after any normalization that might take place) a header field is + absent from a request, it can only match another request if it is + also absent there. + + A Vary header field-value of "*" always fails to match. + + The stored response with matching selecting header fields is known as + the selected response. + + If multiple selected responses are available (potentially including + responses without a Vary header field), the cache will need to choose + one to use. When a selecting header field has a known mechanism for + doing so (e.g., qvalues on Accept and similar request header fields), + that mechanism MAY be used to select preferred responses; of the + remainder, the most recent response (as determined by the Date header + field) is used, as per Section 4. + + If no selected response is available, the cache cannot satisfy the + presented request. Typically, it is forwarded to the origin server + in a (possibly conditional; see Section 4.3) request. + + + + + + + + + + + +Fielding, et al. Standards Track [Page 10] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +4.2. Freshness + + A fresh response is one whose age has not yet exceeded its freshness + lifetime. Conversely, a stale response is one where it has. + + A response's freshness lifetime is the length of time between its + generation by the origin server and its expiration time. An explicit + expiration time is the time at which the origin server intends that a + stored response can no longer be used by a cache without further + validation, whereas a heuristic expiration time is assigned by a + cache when no explicit expiration time is available. + + A response's age is the time that has passed since it was generated + by, or successfully validated with, the origin server. + + When a response is "fresh" in the cache, it can be used to satisfy + subsequent requests without contacting the origin server, thereby + improving efficiency. + + The primary mechanism for determining freshness is for an origin + server to provide an explicit expiration time in the future, using + either the Expires header field (Section 5.3) or the max-age response + directive (Section 5.2.2.8). Generally, origin servers will assign + future explicit expiration times to responses in the belief that the + representation is not likely to change in a semantically significant + way before the expiration time is reached. + + If an origin server wishes to force a cache to validate every + request, it can assign an explicit expiration time in the past to + indicate that the response is already stale. Compliant caches will + normally validate a stale cached response before reusing it for + subsequent requests (see Section 4.2.4). + + Since origin servers do not always provide explicit expiration times, + caches are also allowed to use a heuristic to determine an expiration + time under certain circumstances (see Section 4.2.2). + + The calculation to determine if a response is fresh is: + + response_is_fresh = (freshness_lifetime > current_age) + + freshness_lifetime is defined in Section 4.2.1; current_age is + defined in Section 4.2.3. + + Clients can send the max-age or min-fresh cache directives in a + request to constrain or relax freshness calculations for the + corresponding response (Section 5.2.1). + + + + +Fielding, et al. Standards Track [Page 11] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + When calculating freshness, to avoid common problems in date parsing: + + o Although all date formats are specified to be case-sensitive, a + cache recipient SHOULD match day, week, and time-zone names + case-insensitively. + + o If a cache recipient's internal implementation of time has less + resolution than the value of an HTTP-date, the recipient MUST + internally represent a parsed Expires date as the nearest time + equal to or earlier than the received value. + + o A cache recipient MUST NOT allow local time zones to influence the + calculation or comparison of an age or expiration time. + + o A cache recipient SHOULD consider a date with a zone abbreviation + other than GMT or UTC to be invalid for calculating expiration. + + Note that freshness applies only to cache operation; it cannot be + used to force a user agent to refresh its display or reload a + resource. See Section 6 for an explanation of the difference between + caches and history mechanisms. + +4.2.1. Calculating Freshness Lifetime + + A cache can calculate the freshness lifetime (denoted as + freshness_lifetime) of a response by using the first match of the + following: + + o If the cache is shared and the s-maxage response directive + (Section 5.2.2.9) is present, use its value, or + + o If the max-age response directive (Section 5.2.2.8) is present, + use its value, or + + o If the Expires response header field (Section 5.3) is present, use + its value minus the value of the Date response header field, or + + o Otherwise, no explicit expiration time is present in the response. + A heuristic freshness lifetime might be applicable; see + Section 4.2.2. + + Note that this calculation is not vulnerable to clock skew, since all + of the information comes from the origin server. + + + + + + + + +Fielding, et al. Standards Track [Page 12] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + When there is more than one value present for a given directive + (e.g., two Expires header fields, multiple Cache-Control: max-age + directives), the directive's value is considered invalid. Caches are + encouraged to consider responses that have invalid freshness + information to be stale. + +4.2.2. Calculating Heuristic Freshness + + Since origin servers do not always provide explicit expiration times, + a cache MAY assign a heuristic expiration time when an explicit time + is not specified, employing algorithms that use other header field + values (such as the Last-Modified time) to estimate a plausible + expiration time. This specification does not provide specific + algorithms, but does impose worst-case constraints on their results. + + A cache MUST NOT use heuristics to determine freshness when an + explicit expiration time is present in the stored response. Because + of the requirements in Section 3, this means that, effectively, + heuristics can only be used on responses without explicit freshness + whose status codes are defined as cacheable by default (see Section + 6.1 of [RFC7231]), and those responses without explicit freshness + that have been marked as explicitly cacheable (e.g., with a "public" + response directive). + + If the response has a Last-Modified header field (Section 2.2 of + [RFC7232]), caches are encouraged to use a heuristic expiration value + that is no more than some fraction of the interval since that time. + A typical setting of this fraction might be 10%. + + When a heuristic is used to calculate freshness lifetime, a cache + SHOULD generate a Warning header field with a 113 warn-code (see + Section 5.5.4) in the response if its current_age is more than 24 + hours and such a warning is not already present. + + Note: Section 13.9 of [RFC2616] prohibited caches from calculating + heuristic freshness for URIs with query components (i.e., those + containing '?'). In practice, this has not been widely + implemented. Therefore, origin servers are encouraged to send + explicit directives (e.g., Cache-Control: no-cache) if they wish + to preclude caching. + +4.2.3. Calculating Age + + The Age header field is used to convey an estimated age of the + response message when obtained from a cache. The Age field value is + the cache's estimate of the number of seconds since the response was + generated or validated by the origin server. In essence, the Age + + + + +Fielding, et al. Standards Track [Page 13] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + 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. + + The following data is used for the age calculation: + + age_value + + The term "age_value" denotes the value of the Age header field + (Section 5.1), in a form appropriate for arithmetic operation; or + 0, if not available. + + date_value + + The term "date_value" denotes the value of the Date header field, + in a form appropriate for arithmetic operations. See Section + 7.1.1.2 of [RFC7231] for the definition of the Date header field, + and for requirements regarding responses without it. + + now + + The term "now" means "the current value of the clock at the host + performing the calculation". A host ought to use NTP ([RFC5905]) + or some similar protocol to synchronize its clocks to Coordinated + Universal Time. + + request_time + + The current value of the clock at the host at the time the request + resulting in the stored response was made. + + response_time + + The current value of the clock at the host at the time the + response was received. + + A response's age can be calculated in two entirely independent ways: + + 1. the "apparent_age": response_time 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. the "corrected_age_value", if all of the caches along the + response path implement HTTP/1.1. A cache MUST interpret this + value relative to the time the request was initiated, not the + time that the response was received. + + + + +Fielding, et al. Standards Track [Page 14] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + apparent_age = max(0, response_time - date_value); + + response_delay = response_time - request_time; + corrected_age_value = age_value + response_delay; + + These are combined as + + corrected_initial_age = max(apparent_age, corrected_age_value); + + unless the cache is confident in the value of the Age header field + (e.g., because there are no HTTP/1.0 hops in the Via header field), + in which case the corrected_age_value MAY be used as the + corrected_initial_age. + + The current_age of a stored response can then be calculated by adding + the amount of time (in seconds) since the stored response was last + validated by the origin server to the corrected_initial_age. + + resident_time = now - response_time; + current_age = corrected_initial_age + resident_time; + +4.2.4. Serving Stale Responses + + A "stale" response is one that either has explicit expiry information + or is allowed to have heuristic expiry calculated, but is not fresh + according to the calculations in Section 4.2. + + A cache MUST NOT generate a stale response if it is prohibited by an + explicit in-protocol directive (e.g., by a "no-store" or "no-cache" + cache directive, a "must-revalidate" cache-response-directive, or an + applicable "s-maxage" or "proxy-revalidate" cache-response-directive; + see Section 5.2.2). + + A cache MUST NOT send stale responses unless it is disconnected + (i.e., it cannot contact the origin server or otherwise find a + forward path) or doing so is explicitly allowed (e.g., by the + max-stale request directive; see Section 5.2.1). + + A cache SHOULD generate a Warning header field with the 110 warn-code + (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD + generate a 112 warn-code (see Section 5.5.3) in stale responses if + the cache is disconnected. + + A cache SHOULD NOT generate a new Warning header field when + forwarding a response that does not have an Age header field, even if + the response is already stale. A cache need not validate a response + that merely became stale in transit. + + + + +Fielding, et al. Standards Track [Page 15] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +4.3. Validation + + When a cache has one or more stored responses for a requested URI, + but cannot serve any of them (e.g., because they are not fresh, or + one cannot be selected; see Section 4.1), it can use the conditional + request mechanism [RFC7232] in the forwarded request to give the next + inbound server an opportunity to select a valid stored response to + use, updating the stored metadata in the process, or to replace the + stored response(s) with a new response. This process is known as + "validating" or "revalidating" the stored response. + +4.3.1. Sending a Validation Request + + When sending a conditional request for cache validation, a cache + sends one or more precondition header fields containing validator + metadata from its stored response(s), which is then compared by + recipients to determine whether a stored response is equivalent to a + current representation of the resource. + + One such validator is the timestamp given in a Last-Modified header + field (Section 2.2 of [RFC7232]), which can be used in an + If-Modified-Since header field for response validation, or in an + If-Unmodified-Since or If-Range header field for representation + selection (i.e., the client is referring specifically to a previously + obtained representation with that timestamp). + + Another validator is the entity-tag given in an ETag header field + (Section 2.3 of [RFC7232]). One or more entity-tags, indicating one + or more stored responses, can be used in an If-None-Match header + field for response validation, or in an If-Match or If-Range header + field for representation selection (i.e., the client is referring + specifically to one or more previously obtained representations with + the listed entity-tags). + +4.3.2. Handling a Received Validation Request + + Each client in the request chain may have its own cache, so it is + common for a cache at an intermediary to receive conditional requests + from other (outbound) caches. Likewise, some user agents make use of + conditional requests to limit data transfers to recently modified + representations or to complete the transfer of a partially retrieved + representation. + + If a cache receives a request that can be satisfied by reusing one of + its stored 200 (OK) or 206 (Partial Content) responses, the cache + SHOULD evaluate any applicable conditional header field preconditions + received in that request with respect to the corresponding validators + contained within the selected response. A cache MUST NOT evaluate + + + +Fielding, et al. Standards Track [Page 16] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + conditional header fields that are only applicable to an origin + server, found in a request with semantics that cannot be satisfied + with a cached response, or applied to a target resource for which it + has no stored responses; such preconditions are likely intended for + some other (inbound) server. + + The proper evaluation of conditional requests by a cache depends on + the received precondition header fields and their precedence, as + defined in Section 6 of [RFC7232]. The If-Match and + If-Unmodified-Since conditional header fields are not applicable to a + cache. + + A request containing an If-None-Match header field (Section 3.2 of + [RFC7232]) indicates that the client wants to validate one or more of + its own stored responses in comparison to whichever stored response + is selected by the cache. If the field-value is "*", or if the + field-value is a list of entity-tags and at least one of them matches + the entity-tag of the selected stored response, a cache recipient + SHOULD generate a 304 (Not Modified) response (using the metadata of + the selected stored response) instead of sending that stored + response. + + When a cache decides to revalidate its own stored responses for a + request that contains an If-None-Match list of entity-tags, the cache + MAY combine the received list with a list of entity-tags from its own + stored set of responses (fresh or stale) and send the union of the + two lists as a replacement If-None-Match header field value in the + forwarded request. If a stored response contains only partial + content, the cache MUST NOT include its entity-tag in the union + unless the request is for a range that would be fully satisfied by + that partial stored response. If the response to the forwarded + request is 304 (Not Modified) and has an ETag header field value with + an entity-tag that is not in the client's list, the cache MUST + generate a 200 (OK) response for the client by reusing its + corresponding stored response, as updated by the 304 response + metadata (Section 4.3.4). + + If an If-None-Match header field is not present, a request containing + an If-Modified-Since header field (Section 3.3 of [RFC7232]) + indicates that the client wants to validate one or more of its own + stored responses by modification date. A cache recipient SHOULD + generate a 304 (Not Modified) response (using the metadata of the + selected stored response) if one of the following cases is true: 1) + the selected stored response has a Last-Modified field-value that is + earlier than or equal to the conditional timestamp; 2) no + Last-Modified field is present in the selected stored response, but + it has a Date field-value that is earlier than or equal to the + conditional timestamp; or, 3) neither Last-Modified nor Date is + + + +Fielding, et al. Standards Track [Page 17] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + present in the selected stored response, but the cache recorded it as + having been received at a time earlier than or equal to the + conditional timestamp. + + A cache that implements partial responses to range requests, as + defined in [RFC7233], also needs to evaluate a received If-Range + header field (Section 3.2 of [RFC7233]) with respect to its selected + stored response. + +4.3.3. Handling a Validation Response + + Cache handling of a response to a conditional request is dependent + upon its status code: + + o A 304 (Not Modified) response status code indicates that the + stored response can be updated and reused; see Section 4.3.4. + + o A full response (i.e., one with a payload body) indicates that + none of the stored responses nominated in the conditional request + is suitable. Instead, the cache MUST use the full response to + satisfy the request and MAY replace the stored response(s). + + o However, if a cache receives a 5xx (Server Error) response while + attempting to validate a response, it can either forward this + response to the requesting client, or act as if the server failed + to respond. In the latter case, the cache MAY send a previously + stored response (see Section 4.2.4). + +4.3.4. Freshening Stored Responses upon Validation + + When a cache receives a 304 (Not Modified) response and already has + one or more stored 200 (OK) responses for the same cache key, the + cache needs to identify which of the stored responses are updated by + this new response and then update the stored response(s) with the new + information provided in the 304 response. + + The stored response to update is identified by using the first match + (if any) of the following: + + o If the new response contains a strong validator (see Section 2.1 + of [RFC7232]), then that strong validator identifies the selected + representation for update. All of the stored responses with the + same strong validator are selected. If none of the stored + responses contain the same strong validator, then the cache MUST + NOT use the new response to update any stored responses. + + + + + + +Fielding, et al. Standards Track [Page 18] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + o If the new response contains a weak validator and that validator + corresponds to one of the cache's stored responses, then the most + recent of those matching stored responses is selected for update. + + o If the new response does not include any form of validator (such + as in the case where a client generates an If-Modified-Since + request from a source other than the Last-Modified response header + field), and there is only one stored response, and that stored + response also lacks a validator, then that stored response is + selected for update. + + If a stored response is selected for update, the cache MUST: + + o delete any Warning header fields in the stored response with + warn-code 1xx (see Section 5.5); + + o retain any Warning header fields in the stored response with + warn-code 2xx; and, + + o use other header fields provided in the 304 (Not Modified) + response to replace all instances of the corresponding header + fields in the stored response. + +4.3.5. Freshening Responses via HEAD + + A response to the HEAD method is identical to what an equivalent + request made with a GET would have been, except it lacks a body. + This property of HEAD responses can be used to invalidate or update a + cached GET response if the more efficient conditional GET request + mechanism is not available (due to no validators being present in the + stored response) or if transmission of the representation body is not + desired even if it has changed. + + When a cache makes an inbound HEAD request for a given request target + and receives a 200 (OK) response, the cache SHOULD update or + invalidate each of its stored GET responses that could have been + selected for that request (see Section 4.1). + + For each of the stored responses that could have been selected, if + the stored response and HEAD response have matching values for any + received validator fields (ETag and Last-Modified) and, if the HEAD + response has a Content-Length header field, the value of + Content-Length matches that of the stored response, the cache SHOULD + update the stored response as described below; otherwise, the cache + SHOULD consider the stored response to be stale. + + + + + + +Fielding, et al. Standards Track [Page 19] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + If a cache updates a stored response with the metadata provided in a + HEAD response, the cache MUST: + + o delete any Warning header fields in the stored response with + warn-code 1xx (see Section 5.5); + + o retain any Warning header fields in the stored response with + warn-code 2xx; and, + + o use other header fields provided in the HEAD response to replace + all instances of the corresponding header fields in the stored + response and append new header fields to the stored response's + header section unless otherwise restricted by the Cache-Control + header field. + +4.4. Invalidation + + Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as + PUT, POST or DELETE have the potential for changing state on the + origin server, intervening caches can use them to keep their contents + up to date. + + A cache MUST invalidate the effective Request URI (Section 5.5 of + [RFC7230]) as well as the URI(s) in the Location and Content-Location + response header fields (if present) when a non-error status code is + received in response to an unsafe request method. + + However, a cache MUST NOT invalidate a URI from a Location or + Content-Location response header field if the host part of that URI + differs from the host part in the effective request URI (Section 5.5 + of [RFC7230]). This helps prevent denial-of-service attacks. + + A cache MUST invalidate the effective request URI (Section 5.5 of + [RFC7230]) when it receives a non-error response to a request with a + method whose safety is unknown. + + Here, a "non-error response" is one with a 2xx (Successful) or 3xx + (Redirection) status code. "Invalidate" means that the cache will + either remove all stored responses related to the effective request + URI or will mark these as "invalid" and in need of a mandatory + validation before they can be sent in response to a subsequent + request. + + Note that this does not guarantee that all appropriate responses are + invalidated. For example, a state-changing request might invalidate + responses in the caches it travels through, but relevant responses + still might be stored in other caches that it has not. + + + + +Fielding, et al. Standards Track [Page 20] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +5. Header Field Definitions + + This section defines the syntax and semantics of HTTP/1.1 header + fields related to caching. + +5.1. Age + + The "Age" header field conveys the sender's estimate of the amount of + time since the response was generated or successfully validated at + the origin server. Age values are calculated as specified in + Section 4.2.3. + + Age = delta-seconds + + The Age field-value is a non-negative integer, representing time in + seconds (see Section 1.2.1). + + The presence of an Age header field implies that the response was not + generated or validated by the origin server for this request. + However, lack of an Age header field does not imply the origin was + contacted, since the response might have been received from an + HTTP/1.0 cache that does not implement Age. + +5.2. Cache-Control + + The "Cache-Control" header field is used to specify directives for + caches along the request/response chain. Such 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. + + A cache MUST obey the requirements of the Cache-Control directives + defined in this section. See Section 5.2.3 for information about how + Cache-Control directives defined elsewhere are handled. + + Note: Some HTTP/1.0 caches might not implement Cache-Control. + + A proxy, whether or not it implements a cache, MUST pass cache + directives through in forwarded messages, 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 target a directive to a specific cache. + + Cache directives are identified by a token, to be compared + case-insensitively, and have an optional argument, that can use both + token and quoted-string syntax. For the directives defined below + that define arguments, recipients ought to accept both forms, even if + one is documented to be preferred. For any directive not defined by + this specification, a recipient MUST accept both forms. + + + +Fielding, et al. Standards Track [Page 21] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + Cache-Control = 1#cache-directive + + cache-directive = token [ "=" ( token / quoted-string ) ] + + For the cache directives defined below, no argument is defined (nor + allowed) unless stated otherwise. + +5.2.1. Request Cache-Control Directives + +5.2.1.1. max-age + + Argument syntax: + + delta-seconds (see Section 1.2.1) + + The "max-age" request directive indicates that the client is + unwilling to accept a response whose age is greater than the + specified number of seconds. Unless the max-stale request directive + is also present, the client is not willing to accept a stale + response. + + This directive uses the token form of the argument syntax: e.g., + 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the + quoted-string form. + +5.2.1.2. max-stale + + Argument syntax: + + delta-seconds (see Section 1.2.1) + + The "max-stale" request directive indicates that the client is + willing to accept a response that has exceeded its freshness + lifetime. If max-stale is assigned a value, then the client is + willing to accept a response that has exceeded its freshness lifetime + 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. + + This directive uses the token form of the argument syntax: e.g., + 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate + the quoted-string form. + +5.2.1.3. min-fresh + + Argument syntax: + + delta-seconds (see Section 1.2.1) + + + +Fielding, et al. Standards Track [Page 22] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + The "min-fresh" request directive 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. + + This directive uses the token form of the argument syntax: e.g., + 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate + the quoted-string form. + +5.2.1.4. no-cache + + The "no-cache" request directive indicates that a cache MUST NOT use + a stored response to satisfy the request without successful + validation on the origin server. + +5.2.1.5. no-store + + The "no-store" request directive indicates that a cache MUST NOT + store any part of either this request or any response to it. This + directive applies to both private 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. + + This directive is NOT 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. + + Note that if a request containing this directive is satisfied from a + cache, the no-store request directive does not apply to the already + stored response. + +5.2.1.6. no-transform + + The "no-transform" request directive indicates that an intermediary + (whether or not it implements a cache) MUST NOT transform the + payload, as defined in Section 5.7.2 of [RFC7230]. + +5.2.1.7. only-if-cached + + The "only-if-cached" request directive indicates that the client only + wishes to obtain a stored response. If it receives this directive, a + cache SHOULD either respond using a stored response that is + consistent with the other constraints of the request, or respond with + + + + +Fielding, et al. Standards Track [Page 23] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + a 504 (Gateway Timeout) status code. If a group of caches is being + operated as a unified system with good internal connectivity, a + member cache MAY forward such a request within that group of caches. + +5.2.2. Response Cache-Control Directives + +5.2.2.1. must-revalidate + + The "must-revalidate" response directive indicates that once it has + become stale, a cache MUST NOT use the response to satisfy subsequent + requests without successful validation on the origin server. + + The must-revalidate directive is necessary to support reliable + operation for certain protocol features. In all circumstances a + cache MUST obey the must-revalidate directive; in particular, if a + cache cannot reach the origin server for any reason, it MUST generate + a 504 (Gateway Timeout) response. + + The must-revalidate directive ought to be used by servers if and only + if failure to validate a request on the representation could result + in incorrect operation, such as a silently unexecuted financial + transaction. + +5.2.2.2. no-cache + + Argument syntax: + + #field-name + + The "no-cache" response directive indicates that the response MUST + NOT be used to satisfy a subsequent request without successful + validation on the origin server. This allows an origin server to + prevent a cache from using it to satisfy a request without contacting + it, even by caches that have been configured to send stale responses. + + If the no-cache response directive specifies 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, any header + fields in the response that have the field-name(s) listed 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. + + The field-names given are not limited to the set of header fields + defined by this specification. Field names are case-insensitive. + + + + + +Fielding, et al. Standards Track [Page 24] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + This directive uses the quoted-string form of the argument syntax. A + sender SHOULD NOT generate the token form (even if quoting appears + not to be needed for single-entry lists). + + Note: Although it has been back-ported to many implementations, some + HTTP/1.0 caches will not recognize or obey this directive. Also, + no-cache response directives with field-names are often handled by + caches as if an unqualified no-cache directive was received; i.e., + the special handling for the qualified form is not widely + implemented. + +5.2.2.3. no-store + + The "no-store" response directive indicates that a cache MUST NOT + store any part of either the immediate request or response. This + directive applies to both private 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. + + This directive is NOT 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. + +5.2.2.4. no-transform + + The "no-transform" response directive indicates that an intermediary + (regardless of whether it implements a cache) MUST NOT transform the + payload, as defined in Section 5.7.2 of [RFC7230]. + +5.2.2.5. public + + The "public" response directive indicates that any cache MAY store + the response, even if the response would normally be non-cacheable or + cacheable only within a private cache. (See Section 3.2 for + additional details related to the use of public in response to a + request containing Authorization, and Section 3 for details of how + public affects responses that would normally not be stored, due to + their status codes not being defined as cacheable by default; see + Section 4.2.2.) + +5.2.2.6. private + + Argument syntax: + + #field-name + + + +Fielding, et al. Standards Track [Page 25] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + The "private" response directive indicates that the response message + is intended for a single user and MUST NOT be stored by a shared + cache. A private cache MAY store the response and reuse it for later + requests, even if the response would normally be non-cacheable. + + If the private response directive specifies one or more field-names, + this requirement is limited to the field-values associated with the + listed response header fields. That is, a shared cache MUST NOT + store the specified field-names(s), whereas it MAY store the + remainder of the response message. + + The field-names given are not limited to the set of header fields + defined by this specification. Field names are case-insensitive. + + This directive uses the quoted-string form of the argument syntax. A + sender SHOULD NOT generate the token form (even if quoting appears + not to be needed for single-entry lists). + + Note: This usage of the word "private" only controls where the + response can be stored; it cannot ensure the privacy of the message + content. Also, private response directives with field-names are + often handled by caches as if an unqualified private directive was + received; i.e., the special handling for the qualified form is not + widely implemented. + +5.2.2.7. proxy-revalidate + + The "proxy-revalidate" response directive has the same meaning as the + must-revalidate response directive, except that it does not apply to + private caches. + +5.2.2.8. max-age + + Argument syntax: + + delta-seconds (see Section 1.2.1) + + The "max-age" response directive indicates that the response is to be + considered stale after its age is greater than the specified number + of seconds. + + This directive uses the token form of the argument syntax: e.g., + 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the + quoted-string form. + + + + + + + +Fielding, et al. Standards Track [Page 26] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +5.2.2.9. s-maxage + + Argument syntax: + + delta-seconds (see Section 1.2.1) + + The "s-maxage" response directive indicates that, in shared caches, + the maximum age specified by this directive overrides the maximum age + specified by either the max-age directive or the Expires header + field. The s-maxage directive also implies the semantics of the + proxy-revalidate response directive. + + This directive uses the token form of the argument syntax: e.g., + 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the + quoted-string form. + +5.2.3. 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 value. A cache + MUST ignore unrecognized cache directives. + + Informational extensions (those that do not require a change in cache + behavior) can 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 old directive are supplied, such that applications that do not + understand the new directive will default to the behavior specified + by the old directive, and those that understand the new directive + will recognize it as modifying the requirements associated with the + old directive. In this way, extensions to the existing cache-control + directives can be made without breaking deployed caches. + + For example, consider a hypothetical new response directive called + "community" that acts as a modifier to the private directive: in + addition to private caches, any cache that is shared only by members + of the named community is allowed to 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 that recognizes such a community cache-extension could + broaden its behavior in accordance with that extension. A cache that + does not recognize the community cache-extension would ignore it and + adhere to the private directive. + + + +Fielding, et al. Standards Track [Page 27] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +5.3. Expires + + The "Expires" header field gives the date/time after which the + response is considered stale. See Section 4.2 for further discussion + of the freshness 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 Expires value is an HTTP-date timestamp, as defined in Section + 7.1.1.1 of [RFC7231]. + + Expires = HTTP-date + + For example + + Expires: Thu, 01 Dec 1994 16:00:00 GMT + + A cache recipient MUST interpret invalid date formats, especially the + value "0", as representing a time in the past (i.e., "already + expired"). + + If a response includes a Cache-Control field with the max-age + directive (Section 5.2.2.8), a recipient MUST ignore the Expires + field. Likewise, if a response includes the s-maxage directive + (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires + field. In both these cases, the value in Expires is only intended + for recipients that have not yet implemented the Cache-Control field. + + An origin server without a clock MUST NOT generate an Expires field + unless its value represents a fixed time in the past (always expired) + or its value has been associated with the resource by a system or + user with a reliable clock. + + Historically, HTTP required the Expires field-value to be no more + than a year in the future. While longer freshness lifetimes are no + longer prohibited, extremely large values have been demonstrated to + cause problems (e.g., clock overflows due to use of 32-bit integers + for time values), and many caches will evict a response far sooner + than that. + + + + + + + + + + +Fielding, et al. Standards Track [Page 28] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +5.4. Pragma + + The "Pragma" header field allows backwards compatibility with + HTTP/1.0 caches, so that clients can specify a "no-cache" request + that they will understand (as Cache-Control was not defined until + HTTP/1.1). When the Cache-Control header field is also present and + understood in a request, Pragma is ignored. + + In HTTP/1.0, Pragma was defined as an extensible field for + implementation-specified directives for recipients. This + specification deprecates such extensions to improve interoperability. + + Pragma = 1#pragma-directive + pragma-directive = "no-cache" / extension-pragma + extension-pragma = token [ "=" ( token / quoted-string ) ] + + When the Cache-Control header field is not present in a request, + caches MUST consider the no-cache request pragma-directive as having + the same effect as if "Cache-Control: no-cache" were present (see + Section 5.2.1). + + When sending a no-cache request, a client ought to include both the + pragma and cache-control directives, unless Cache-Control: no-cache + is purposefully omitted to target other Cache-Control response + directives at HTTP/1.1 caches. For example: + + GET / HTTP/1.1 + Host: www.example.com + Cache-Control: max-age=30 + Pragma: no-cache + + will constrain HTTP/1.1 caches to serve a response no older than 30 + seconds, while precluding implementations that do not understand + Cache-Control from serving a cached response. + + Note: Because the meaning of "Pragma: no-cache" in responses is + not specified, it does not provide a reliable replacement for + "Cache-Control: no-cache" in them. + +5.5. Warning + + The "Warning" header field is used to carry additional information + about the status or transformation of a message that might not be + reflected in the status code. This information is typically used to + warn about possible incorrectness introduced by caching operations or + transformations applied to the payload of the message. + + + + + +Fielding, et al. Standards Track [Page 29] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + Warnings can be used for other purposes, both cache-related and + otherwise. The use of a warning, rather than an error status code, + distinguishes these responses from true failures. + + Warning header fields can in general be applied to any message, + however some warn-codes are specific to caches and can only be + applied to response messages. + + Warning = 1#warning-value + + warning-value = warn-code SP warn-agent SP warn-text + [ SP warn-date ] + + warn-code = 3DIGIT + warn-agent = ( uri-host [ ":" port ] ) / pseudonym + ; the name or pseudonym of the server adding + ; the Warning header field, for use in debugging + ; a single "-" is recommended when agent unknown + warn-text = quoted-string + warn-date = DQUOTE HTTP-date DQUOTE + + Multiple warnings can be generated in a response (either by the + origin server or by a cache), including multiple warnings with the + same warn-code number that only differ in warn-text. + + A user agent that receives one or more Warning header fields SHOULD + inform the user of as many of them as possible, in the order that + they appear in the response. Senders that generate multiple Warning + header fields are encouraged to order them with this user agent + behavior in mind. A sender that generates new Warning header fields + MUST append them after any existing Warning header fields. + + Warnings are assigned three digit warn-codes. The first digit + indicates whether the Warning is required to be deleted from a stored + response after validation: + + o 1xx warn-codes describe the freshness or validation status of the + response, and so they MUST be deleted by a cache after validation. + They can only be generated by a cache when validating a cached + entry, and MUST NOT be generated in any other situation. + + o 2xx warn-codes describe some aspect of the representation that is + not rectified by a validation (for example, a lossy compression of + the representation) and they MUST NOT be deleted by a cache after + validation, unless a full response is sent, in which case they + MUST be. + + + + + +Fielding, et al. Standards Track [Page 30] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + If a sender generates one or more 1xx warn-codes in a message to be + sent to a recipient known to implement only HTTP/1.0, the sender MUST + include in each corresponding warning-value a warn-date that matches + the Date header field in the message. For example: + + HTTP/1.1 200 OK + Date: Sat, 25 Aug 2012 23:34:45 GMT + Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" + + + Warnings have accompanying warn-text that describes the error, e.g., + for logging. It is advisory only, and its content does not affect + interpretation of the warn-code. + + If a recipient that uses, evaluates, or displays Warning header + fields receives a warn-date that is different from the Date value in + the same message, the recipient MUST exclude the warning-value + containing that warn-date before storing, forwarding, or using the + message. This allows recipients to exclude warning-values that were + improperly retained after a cache validation. If all of the + warning-values are excluded, the recipient MUST exclude the Warning + header field as well. + + The following warn-codes are defined by this specification, each with + a recommended warn-text in English, and a description of its meaning. + The procedure for defining additional warn codes is described in + Section 7.2.1. + +5.5.1. Warning: 110 - "Response is Stale" + + A cache SHOULD generate this whenever the sent response is stale. + +5.5.2. Warning: 111 - "Revalidation Failed" + + A cache SHOULD generate this when sending a stale response because an + attempt to validate the response failed, due to an inability to reach + the server. + +5.5.3. Warning: 112 - "Disconnected Operation" + + A cache SHOULD generate this if it is intentionally disconnected from + the rest of the network for a period of time. + +5.5.4. Warning: 113 - "Heuristic Expiration" + + A cache SHOULD generate this if it 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 31] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +5.5.5. Warning: 199 - "Miscellaneous Warning" + + The warning text can 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. + +5.5.6. Warning: 214 - "Transformation Applied" + + This Warning code MUST be added by a proxy if it applies any + transformation to the representation, such as changing the + content-coding, media-type, or modifying the representation data, + unless this Warning code already appears in the response. + +5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" + + The warning text can include arbitrary information to be presented to + a human user or logged. A system receiving this warning MUST NOT + take any automated action. + +6. History Lists + + User agents often have history mechanisms, such as "Back" buttons and + history lists, that can be used to redisplay a representation + retrieved earlier in a session. + + The freshness model (Section 4.2) does not necessarily apply to + history mechanisms. That is, a history mechanism can display a + previous representation even if it has expired. + + This does not prohibit the history mechanism from telling the user + that a view might be stale or from honoring cache directives (e.g., + Cache-Control: no-store). + +7. IANA Considerations + +7.1. Cache Directive Registry + + The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" + defines the namespace for the cache directives. It has been created + and is now maintained at + . + +7.1.1. Procedure + + A registration MUST include the following fields: + + o Cache Directive Name + + + +Fielding, et al. Standards Track [Page 32] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + o Pointer to specification text + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + +7.1.2. Considerations for New Cache Control Directives + + New extension directives ought to consider defining: + + o What it means for a directive to be specified multiple times, + + o When the directive does not take an argument, what it means when + an argument is present, + + o When the directive requires an argument, what it means when it is + missing, + + o Whether the directive is specific to requests, responses, or able + to be used in either. + + See also Section 5.2.3. + +7.1.3. Registrations + + The registry has been populated with the registrations below: + + +------------------------+----------------------------------+ + | Cache Directive | Reference | + +------------------------+----------------------------------+ + | max-age | Section 5.2.1.1, Section 5.2.2.8 | + | max-stale | Section 5.2.1.2 | + | min-fresh | Section 5.2.1.3 | + | must-revalidate | Section 5.2.2.1 | + | no-cache | Section 5.2.1.4, Section 5.2.2.2 | + | no-store | Section 5.2.1.5, Section 5.2.2.3 | + | no-transform | Section 5.2.1.6, Section 5.2.2.4 | + | only-if-cached | Section 5.2.1.7 | + | private | Section 5.2.2.6 | + | proxy-revalidate | Section 5.2.2.7 | + | public | Section 5.2.2.5 | + | s-maxage | Section 5.2.2.9 | + | stale-if-error | [RFC5861], Section 4 | + | stale-while-revalidate | [RFC5861], Section 3 | + +------------------------+----------------------------------+ + + + + + + + +Fielding, et al. Standards Track [Page 33] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +7.2. Warn Code Registry + + The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines + the namespace for warn codes. It has been created and is now + maintained at . + +7.2.1. Procedure + + A registration MUST include the following fields: + + o Warn Code (3 digits) + + o Short Description + + o Pointer to specification text + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + +7.2.2. Registrations + + The registry has been populated with the registrations below: + + +-----------+----------------------------------+---------------+ + | Warn Code | Short Description | Reference | + +-----------+----------------------------------+---------------+ + | 110 | Response is Stale | Section 5.5.1 | + | 111 | Revalidation Failed | Section 5.5.2 | + | 112 | Disconnected Operation | Section 5.5.3 | + | 113 | Heuristic Expiration | Section 5.5.4 | + | 199 | Miscellaneous Warning | Section 5.5.5 | + | 214 | Transformation Applied | Section 5.5.6 | + | 299 | Miscellaneous Persistent Warning | Section 5.5.7 | + +-----------+----------------------------------+---------------+ + +7.3. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + + + + + + + + + + +Fielding, et al. Standards Track [Page 34] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + This document defines the following HTTP header fields, so the + "Permanent Message Header Field Names" registry has been updated + accordingly (see [BCP90]). + + +-------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +-------------------+----------+----------+-------------+ + | Age | http | standard | Section 5.1 | + | Cache-Control | http | standard | Section 5.2 | + | Expires | http | standard | Section 5.3 | + | Pragma | http | standard | Section 5.4 | + | Warning | http | standard | Section 5.5 | + +-------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + +8. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns specific to HTTP caching. More + general security considerations are addressed in HTTP messaging + [RFC7230] and semantics [RFC7231]. + + Caches expose 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 need to be protected as sensitive + information. + + In particular, various attacks might be amplified by being stored in + a shared cache; such "cache poisoning" attacks use the cache to + distribute a malicious payload to many clients, and are especially + effective when an attacker can use implementation flaws, elevated + privileges, or other techniques to insert such a response into a + cache. One common attack vector for cache poisoning is to exploit + differences in message parsing on proxies and in user agents; see + Section 3.3.3 of [RFC7230] for the relevant requirements. + + Likewise, implementation flaws (as well as misunderstanding of cache + operation) might lead to caching of sensitive information (e.g., + authentication credentials) that is thought to be private, exposing + it to unauthorized parties. + + + + + + +Fielding, et al. Standards Track [Page 35] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + Furthermore, the very use of a cache can bring about privacy + concerns. For example, if two users share a cache, and the first one + browses to a site, the second may be able to detect that the other + has been to that site, because the resources from it load more + quickly, thanks to the cache. + + Note that the Set-Cookie response header field [RFC6265] does not + inhibit caching; a cacheable response with a Set-Cookie header field + can be (and often is) used to satisfy subsequent requests to caches. + Servers who wish to control caching of these responses are encouraged + to emit appropriate Cache-Control response header fields. + +9. Acknowledgments + + See Section 10 of [RFC7230]. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + + [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., + "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", + RFC 7233, June 2014. + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. + + + + + + + +Fielding, et al. Standards Track [Page 36] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +10.2. Informative References + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale + Content", RFC 5861, April 2010. + + [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and Algorithms + Specification", RFC 5905, June 2010. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 37] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +Appendix A. Changes from RFC 2616 + + The specification has been substantially rewritten for clarity. + + The conditions under which an authenticated response can be cached + have been clarified. (Section 3.2) + + New status codes can now define that caches are allowed to use + heuristic freshness with them. Caches are now allowed to calculate + heuristic freshness for URIs with query components. (Section 4.2.2) + + The algorithm for calculating age is now less conservative. Caches + are now required to handle dates with time zones as if they're + invalid, because it's not possible to accurately guess. + (Section 4.2.3) + + The Content-Location response header field is no longer used to + determine the appropriate response to use when validating. + (Section 4.3) + + The algorithm for selecting a cached negotiated response to use has + been clarified in several ways. In particular, it now explicitly + allows header-specific canonicalization when processing selecting + header fields. (Section 4.1) + + Requirements regarding denial-of-service attack avoidance when + performing invalidation have been clarified. (Section 4.4) + + Cache invalidation only occurs when a successful response is + received. (Section 4.4) + + Cache directives are explicitly defined to be case-insensitive. + Handling of multiple instances of cache directives when only one is + expected is now defined. (Section 5.2) + + The "no-store" request directive doesn't apply to responses; i.e., a + cache can satisfy a request with no-store on it and does not + invalidate it. (Section 5.2.1.5) + + The qualified forms of the private and no-cache cache directives are + noted to not be widely implemented; for example, "private=foo" is + interpreted by many caches as simply "private". Additionally, the + meaning of the qualified form of no-cache has been clarified. + (Section 5.2.2) + + The "no-cache" response directive's meaning has been clarified. + (Section 5.2.2.2) + + + + +Fielding, et al. Standards Track [Page 38] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + The one-year limit on Expires header field values has been removed; + instead, the reasoning for using a sensible value is given. + (Section 5.3) + + The Pragma header field is now only defined for backwards + compatibility; future pragmas are deprecated. (Section 5.4) + + Some requirements regarding production and processing of the Warning + header fields have been relaxed, as it is not widely implemented. + Furthermore, the Warning header field no longer uses RFC 2047 + encoding, nor does it allow multiple languages, as these aspects were + not implemented. (Section 5.5) + + This specification introduces the Cache Directive and Warn Code + Registries, and defines considerations for new cache directives. + (Section 7.1 and Section 7.2) + +Appendix B. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: 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), LF (line feed), OCTET (any + 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII + character). + + The rules below are defined in [RFC7230]: + + OWS = + field-name = + quoted-string = + token = + + port = + pseudonym = + uri-host = + + The rules below are defined in other parts: + + HTTP-date = + + + + + + + + + + + +Fielding, et al. Standards Track [Page 39] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +Appendix C. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + Age = delta-seconds + + Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS + cache-directive ] ) + + Expires = HTTP-date + + HTTP-date = + + OWS = + + Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS + pragma-directive ] ) + + Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] + ) + + cache-directive = token [ "=" ( token / quoted-string ) ] + + delta-seconds = 1*DIGIT + + extension-pragma = token [ "=" ( token / quoted-string ) ] + + field-name = + + port = + pragma-directive = "no-cache" / extension-pragma + pseudonym = + + quoted-string = + + token = + + uri-host = + + warn-agent = ( uri-host [ ":" port ] ) / pseudonym + warn-code = 3DIGIT + warn-date = DQUOTE HTTP-date DQUOTE + warn-text = quoted-string + warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date + ] + + + + + +Fielding, et al. Standards Track [Page 40] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +Index + + 1 + 110 (warn-code) 31 + 111 (warn-code) 31 + 112 (warn-code) 31 + 113 (warn-code) 31 + 199 (warn-code) 32 + + 2 + 214 (warn-code) 32 + 299 (warn-code) 32 + + A + age 11 + Age header field 21 + + C + cache 4 + cache entry 5 + cache key 5-6 + Cache-Control header field 21 + + D + Disconnected Operation (warn-text) 31 + + E + Expires header field 28 + explicit expiration time 11 + + F + fresh 11 + freshness lifetime 11 + + G + Grammar + Age 21 + Cache-Control 22 + cache-directive 22 + delta-seconds 5 + Expires 28 + extension-pragma 29 + Pragma 29 + pragma-directive 29 + warn-agent 29 + warn-code 29 + warn-date 29 + warn-text 29 + + + +Fielding, et al. Standards Track [Page 41] + +RFC 7234 HTTP/1.1 Caching June 2014 + + + Warning 29 + warning-value 29 + + H + Heuristic Expiration (warn-text) 31 + heuristic expiration time 11 + M + max-age (cache directive) 22, 26 + max-stale (cache directive) 22 + min-fresh (cache directive) 22 + Miscellaneous Persistent Warning (warn-text) 32 + Miscellaneous Warning (warn-text) 32 + must-revalidate (cache directive) 24 + + N + no-cache (cache directive) 23, 25 + no-store (cache directive) 23, 24 + no-transform (cache directive) 23, 25 + + O + only-if-cached (cache directive) 23 + + P + Pragma header field 29 + private (cache directive) 25 + private cache 4 + proxy-revalidate (cache directive) 26 + public (cache directive) 25 + + R + Response is Stale (warn-text) 30 + Revalidation Failed (warn-text) 31 + + S + s-maxage (cache directive) 27 + shared cache 4 + stale 11 + strong validator 18 + + T + Transformation Applied (warn-text) 32 + + V + validator 16 + + W + Warning header field 29 + + + + +Fielding, et al. Standards Track [Page 42] + +RFC 7234 HTTP/1.1 Caching June 2014 + + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Mark Nottingham (editor) + Akamai + + EMail: mnot@mnot.net + URI: http://www.mnot.net/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + +Fielding, et al. Standards Track [Page 43] + === added file 'doc/rfc/rfc7235.txt' --- doc/rfc/rfc7235.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7235.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 7235 Adobe +Obsoletes: 2616 J. Reschke, Ed. +Updates: 2617 greenbytes +Category: Standards Track June 2014 +ISSN: 2070-1721 + + + Hypertext Transfer Protocol (HTTP/1.1): Authentication + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypermedia information + systems. This document defines the HTTP Authentication framework. + +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/rfc7235. + +Copyright Notice + + Copyright (c) 2014 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. + + 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 + + + +Fielding & Reschke Standards Track [Page 1] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + 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 ....................................................3 + 1.1. Conformance and Error Handling .............................3 + 1.2. Syntax Notation ............................................3 + 2. Access Authentication Framework .................................3 + 2.1. Challenge and Response .....................................3 + 2.2. Protection Space (Realm) ...................................5 + 3. Status Code Definitions .........................................6 + 3.1. 401 Unauthorized ...........................................6 + 3.2. 407 Proxy Authentication Required ..........................6 + 4. Header Field Definitions ........................................7 + 4.1. WWW-Authenticate ...........................................7 + 4.2. Authorization ..............................................8 + 4.3. Proxy-Authenticate .........................................8 + 4.4. Proxy-Authorization ........................................9 + 5. IANA Considerations .............................................9 + 5.1. Authentication Scheme Registry .............................9 + 5.1.1. Procedure ...........................................9 + 5.1.2. Considerations for New Authentication Schemes ......10 + 5.2. Status Code Registration ..................................11 + 5.3. Header Field Registration .................................11 + 6. Security Considerations ........................................12 + 6.1. Confidentiality of Credentials ............................12 + 6.2. Authentication Credentials and Idle Clients ...............12 + 6.3. Protection Spaces .........................................13 + 7. Acknowledgments ................................................14 + 8. References .....................................................14 + 8.1. Normative References ......................................14 + 8.2. Informative References ....................................14 + Appendix A. Changes from RFCs 2616 and 2617 .......................16 + Appendix B. Imported ABNF .........................................16 + Appendix C. Collected ABNF ........................................17 + Index .............................................................18 + + + + + + + + +Fielding & Reschke Standards Track [Page 2] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +1. Introduction + + HTTP provides a general framework for access control and + authentication, via an extensible set of challenge-response + authentication schemes, which can be used by a server to challenge a + client request and by a client to provide authentication information. + This document defines HTTP/1.1 authentication in terms of the + architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): + Message Syntax and Routing" [RFC7230], including the general + framework previously described in "HTTP Authentication: Basic and + Digest Access Authentication" [RFC2617] and the related fields and + status codes previously defined in "Hypertext Transfer Protocol -- + HTTP/1.1" [RFC2616]. + + The IANA Authentication Scheme Registry (Section 5.1) lists + registered authentication schemes and their corresponding + specifications, including the "basic" and "digest" authentication + schemes previously defined by RFC 2617. + +1.1. Conformance and Error Handling + + 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 [RFC2119]. + + Conformance criteria and considerations regarding error handling are + defined in Section 2.5 of [RFC7230]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with a list extension, defined in Section 7 of + [RFC7230], that allows for compact definition of comma-separated + lists using a '#' operator (similar to how the '*' operator indicates + repetition). Appendix B describes rules imported from other + documents. Appendix C shows the collected grammar with all list + operators expanded to standard ABNF notation. + +2. Access Authentication Framework + +2.1. Challenge and Response + + HTTP provides a simple challenge-response authentication framework + that can be used by a server to challenge a client request and by a + client to provide authentication information. It uses a case- + insensitive token as a means to identify the authentication scheme, + followed by additional information necessary for achieving + + + + +Fielding & Reschke Standards Track [Page 3] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + authentication via that scheme. The latter can be either a comma- + separated list of parameters or a single sequence of characters + capable of holding base64-encoded information. + + Authentication parameters are name=value pairs, where the name token + is matched case-insensitively, and each parameter name MUST only + occur once per challenge. + + auth-scheme = token + + auth-param = token BWS "=" BWS ( token / quoted-string ) + + token68 = 1*( ALPHA / DIGIT / + "-" / "." / "_" / "~" / "+" / "/" ) *"=" + + The token68 syntax allows the 66 unreserved URI characters + ([RFC3986]), plus a few others, so that it can hold a base64, + base64url (URL and filename safe alphabet), base32, or base16 (hex) + encoding, with or without padding, but excluding whitespace + ([RFC4648]). + + A 401 (Unauthorized) response message is used by an origin server to + challenge the authorization of a user agent, including a + WWW-Authenticate header field containing at least one challenge + applicable to the requested resource. + + A 407 (Proxy Authentication Required) response message is used by a + proxy to challenge the authorization of a client, including a + Proxy-Authenticate header field containing at least one challenge + applicable to the proxy for the requested resource. + + challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] + + Note: Many clients fail to parse a challenge that contains an + unknown scheme. A workaround for this problem is to list well- + supported schemes (such as "basic") first. + + A user agent that wishes to authenticate itself with an origin server + -- usually, but not necessarily, after receiving a 401 (Unauthorized) + -- can do so by including an Authorization header field with the + request. + + A client that wishes to authenticate itself with a proxy -- usually, + but not necessarily, after receiving a 407 (Proxy Authentication + Required) -- can do so by including a Proxy-Authorization header + field with the request. + + + + + +Fielding & Reschke Standards Track [Page 4] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + Both the Authorization field value and the Proxy-Authorization field + value contain the client's credentials for the realm of the resource + being requested, based upon a challenge received in a response + (possibly at some point in the past). When creating their values, + the user agent ought to do so by selecting the challenge with what it + considers to be the most secure auth-scheme that it understands, + obtaining credentials from the user as appropriate. Transmission of + credentials within header field values implies significant security + considerations regarding the confidentiality of the underlying + connection, as described in Section 6.1. + + credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ] + + Upon receipt of a request for a protected resource that omits + credentials, contains invalid credentials (e.g., a bad password) or + partial credentials (e.g., when the authentication scheme requires + more than one round trip), an origin server SHOULD send a 401 + (Unauthorized) response that contains a WWW-Authenticate header field + with at least one (possibly new) challenge applicable to the + requested resource. + + Likewise, upon receipt of a request that omits proxy credentials or + contains invalid or partial proxy credentials, a proxy that requires + authentication SHOULD generate a 407 (Proxy Authentication Required) + response that contains a Proxy-Authenticate header field with at + least one (possibly new) challenge applicable to the proxy. + + A server that receives valid credentials that are not adequate to + gain access ought to respond with the 403 (Forbidden) status code + (Section 6.5.3 of [RFC7231]). + + HTTP does not restrict applications to this simple challenge-response + framework for access authentication. Additional mechanisms can be + used, such as authentication at the transport level or via message + encapsulation, and with additional header fields specifying + authentication information. However, such additional mechanisms are + not defined by this specification. + +2.2. Protection Space (Realm) + + The "realm" authentication parameter is reserved for use by + authentication schemes that wish to indicate a scope of protection. + + A protection space is defined by the canonical root URI (the scheme + and authority components of the effective request URI; see Section + 5.5 of [RFC7230]) of the server being accessed, in combination with + the realm value if present. These realms allow the protected + resources on a server to be partitioned into a set of protection + + + +Fielding & Reschke Standards Track [Page 5] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + spaces, each with its own authentication scheme and/or authorization + database. The realm value is a string, generally assigned by the + origin server, that can have additional semantics specific to the + authentication scheme. Note that a response can have multiple + challenges with the same auth-scheme but with different realms. + + The protection space determines the domain over which credentials can + be automatically applied. If a prior request has been authorized, + the user agent MAY reuse the same credentials for all other requests + within that protection space for a period of time determined by the + authentication scheme, parameters, and/or user preferences (such as a + configurable inactivity timeout). Unless specifically allowed by the + authentication scheme, a single protection space cannot extend + outside the scope of its server. + + For historical reasons, a sender MUST only generate the quoted-string + syntax. Recipients might have to support both token and + quoted-string syntax for maximum interoperability with existing + clients that have been accepting both notations for a long time. + +3. Status Code Definitions + +3.1. 401 Unauthorized + + The 401 (Unauthorized) status code indicates that the request has not + been applied because it lacks valid authentication credentials for + the target resource. The server generating a 401 response MUST send + a WWW-Authenticate header field (Section 4.1) containing at least one + challenge applicable to the target resource. + + If the request included authentication credentials, then the 401 + response indicates that authorization has been refused for those + credentials. The user agent MAY repeat the request with a new or + replaced Authorization header field (Section 4.2). 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 agent SHOULD present the enclosed representation to the + user, since it usually contains relevant diagnostic information. + +3.2. 407 Proxy Authentication Required + + The 407 (Proxy Authentication Required) status code is similar to 401 + (Unauthorized), but it indicates that the client needs to + authenticate itself in order to use a proxy. The proxy MUST send a + Proxy-Authenticate header field (Section 4.3) containing a challenge + applicable to that proxy for the target resource. The client MAY + repeat the request with a new or replaced Proxy-Authorization header + field (Section 4.4). + + + +Fielding & Reschke Standards Track [Page 6] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +4. Header Field Definitions + + This section defines the syntax and semantics of header fields + related to the HTTP authentication framework. + +4.1. WWW-Authenticate + + The "WWW-Authenticate" header field indicates the authentication + scheme(s) and parameters applicable to the target resource. + + WWW-Authenticate = 1#challenge + + A server generating a 401 (Unauthorized) response MUST send a + WWW-Authenticate header field containing at least one challenge. A + server MAY generate a WWW-Authenticate header field in other response + messages to indicate that supplying credentials (or different + credentials) might affect the response. + + A proxy forwarding a response MUST NOT modify any WWW-Authenticate + fields in that response. + + User agents are advised to take special care in parsing the field + value, as it might contain more than one challenge, and each + challenge can contain a comma-separated list of authentication + parameters. Furthermore, the header field itself can occur multiple + times. + + For instance: + + WWW-Authenticate: Newauth realm="apps", type=1, + title="Login to \"apps\"", Basic realm="simple" + + This header field contains two challenges; one for the "Newauth" + scheme with a realm value of "apps", and two additional parameters + "type" and "title", and another one for the "Basic" scheme with a + realm value of "simple". + + Note: The challenge grammar production uses the list syntax as + well. Therefore, a sequence of comma, whitespace, and comma can + be considered either as applying to the preceding challenge, or to + be an empty entry in the list of challenges. In practice, this + ambiguity does not affect the semantics of the header field value + and thus is harmless. + + + + + + + + +Fielding & Reschke Standards Track [Page 7] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +4.2. Authorization + + The "Authorization" header field allows a user agent to authenticate + itself with an origin server -- usually, but not necessarily, after + receiving a 401 (Unauthorized) response. Its value consists of + credentials containing the authentication information of the user + agent for the realm of the resource being requested. + + Authorization = credentials + + If a request is authenticated and a realm specified, the same + credentials are presumed to 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). + + A proxy forwarding a request MUST NOT modify any Authorization fields + in that request. See Section 3.2 of [RFC7234] for details of and + requirements pertaining to handling of the Authorization field by + HTTP caches. + +4.3. Proxy-Authenticate + + The "Proxy-Authenticate" header field consists of at least one + challenge that indicates the authentication scheme(s) and parameters + applicable to the proxy for this effective request URI (Section 5.5 + of [RFC7230]). A proxy MUST send at least one Proxy-Authenticate + header field in each 407 (Proxy Authentication Required) response + that it generates. + + Proxy-Authenticate = 1#challenge + + Unlike WWW-Authenticate, the Proxy-Authenticate header field applies + only to the next outbound client on the response chain. This is + because only the client that chose a given proxy is likely to have + the credentials necessary for authentication. However, when multiple + proxies are used within the same administrative domain, such as + office and regional caching proxies within a large corporate network, + it is common for credentials to be generated by the user agent and + passed through the hierarchy until consumed. Hence, in such a + configuration, it will appear as if Proxy-Authenticate is being + forwarded because each proxy will send the same challenge set. + + Note that the parsing considerations for WWW-Authenticate apply to + this header field as well; see Section 4.1 for details. + + + + + + +Fielding & Reschke Standards Track [Page 8] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +4.4. Proxy-Authorization + + The "Proxy-Authorization" header field allows the client to identify + itself (or its user) to a proxy that requires authentication. Its + value consists of credentials containing the authentication + information of the client for the proxy and/or realm of the resource + being requested. + + Proxy-Authorization = credentials + + Unlike Authorization, the Proxy-Authorization header field applies + only to the next inbound 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 inbound + 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. + +5. IANA Considerations + +5.1. Authentication Scheme Registry + + The "Hypertext Transfer Protocol (HTTP) Authentication Scheme + Registry" defines the namespace for the authentication schemes in + challenges and credentials. It has been created and is now + maintained at . + +5.1.1. Procedure + + Registrations MUST include the following fields: + + o Authentication Scheme Name + + o Pointer to specification text + + o Notes (optional) + + Values to be added to this namespace require IETF Review (see + [RFC5226], Section 4.1). + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 9] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +5.1.2. Considerations for New Authentication Schemes + + There are certain aspects of the HTTP Authentication Framework that + put constraints on how new authentication schemes can work: + + o HTTP authentication is presumed to be stateless: all of the + information necessary to authenticate a request MUST be provided + in the request, rather than be dependent on the server remembering + prior requests. Authentication based on, or bound to, the + underlying connection is outside the scope of this specification + and inherently flawed unless steps are taken to ensure that the + connection cannot be used by any party other than the + authenticated user (see Section 2.3 of [RFC7230]). + + o The authentication parameter "realm" is reserved for defining + protection spaces as described in Section 2.2. New schemes MUST + NOT use it in a way incompatible with that definition. + + o The "token68" notation was introduced for compatibility with + existing authentication schemes and can only be used once per + challenge or credential. Thus, new schemes ought to use the + auth-param syntax instead, because otherwise future extensions + will be impossible. + + o The parsing of challenges and credentials is defined by this + specification and cannot be modified by new authentication + schemes. When the auth-param syntax is used, all parameters ought + to support both token and quoted-string syntax, and syntactical + constraints ought to be defined on the field value after parsing + (i.e., quoted-string processing). This is necessary so that + recipients can use a generic parser that applies to all + authentication schemes. + + Note: The fact that the value syntax for the "realm" parameter is + restricted to quoted-string was a bad design choice not to be + repeated for new parameters. + + o Definitions of new schemes ought to define the treatment of + unknown extension parameters. In general, a "must-ignore" rule is + preferable to a "must-understand" rule, because otherwise it will + be hard to introduce new parameters in the presence of legacy + recipients. Furthermore, it's good to describe the policy for + defining new parameters (such as "update the specification" or + "use this registry"). + + o Authentication schemes need to document whether they are usable in + origin-server authentication (i.e., using WWW-Authenticate), + and/or proxy authentication (i.e., using Proxy-Authenticate). + + + +Fielding & Reschke Standards Track [Page 10] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + o The credentials carried in an Authorization header field are + specific to the user agent and, therefore, have the same effect on + HTTP caches as the "private" Cache-Control response directive + (Section 5.2.2.6 of [RFC7234]), within the scope of the request in + which they appear. + + Therefore, new authentication schemes that choose not to carry + credentials in the Authorization header field (e.g., using a newly + defined header field) will need to explicitly disallow caching, by + mandating the use of either Cache-Control request directives + (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response + directives (e.g., "private"). + +5.2. Status Code Registration + + The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located + at has been + updated with the registrations below: + + +-------+-------------------------------+-------------+ + | Value | Description | Reference | + +-------+-------------------------------+-------------+ + | 401 | Unauthorized | Section 3.1 | + | 407 | Proxy Authentication Required | Section 3.2 | + +-------+-------------------------------+-------------+ + +5.3. Header Field Registration + + HTTP header fields are registered within the "Message Headers" + registry maintained at + . + + This document defines the following HTTP header fields, so the + "Permanent Message Header Field Names" registry has been updated + accordingly (see [BCP90]). + + +---------------------+----------+----------+-------------+ + | Header Field Name | Protocol | Status | Reference | + +---------------------+----------+----------+-------------+ + | Authorization | http | standard | Section 4.2 | + | Proxy-Authenticate | http | standard | Section 4.3 | + | Proxy-Authorization | http | standard | Section 4.4 | + | WWW-Authenticate | http | standard | Section 4.1 | + +---------------------+----------+----------+-------------+ + + The change controller is: "IETF (iesg@ietf.org) - Internet + Engineering Task Force". + + + + +Fielding & Reschke Standards Track [Page 11] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +6. Security Considerations + + This section is meant to inform developers, information providers, + and users of known security concerns specific to HTTP authentication. + More general security considerations are addressed in HTTP messaging + [RFC7230] and semantics [RFC7231]. + + Everything about the topic of HTTP authentication is a security + consideration, so the list of considerations below is not exhaustive. + Furthermore, it is limited to security considerations regarding the + authentication framework, in general, rather than discussing all of + the potential considerations for specific authentication schemes + (which ought to be documented in the specifications that define those + schemes). Various organizations maintain topical information and + links to current research on Web application security (e.g., + [OWASP]), including common pitfalls for implementing and using the + authentication schemes found in practice. + +6.1. Confidentiality of Credentials + + The HTTP authentication framework does not define a single mechanism + for maintaining the confidentiality of credentials; instead, each + authentication scheme defines how the credentials are encoded prior + to transmission. While this provides flexibility for the development + of future authentication schemes, it is inadequate for the protection + of existing schemes that provide no confidentiality on their own, or + that do not sufficiently protect against replay attacks. + Furthermore, if the server expects credentials that are specific to + each individual user, the exchange of those credentials will have the + effect of identifying that user even if the content within + credentials remains confidential. + + HTTP depends on the security properties of the underlying transport- + or session-level connection to provide confidential transmission of + header fields. In other words, if a server limits access to + authenticated users using this framework, the server needs to ensure + that the connection is properly secured in accordance with the nature + of the authentication scheme used. For example, services that depend + on individual user authentication often require a connection to be + secured with TLS ("Transport Layer Security", [RFC5246]) prior to + exchanging any credentials. + +6.2. Authentication Credentials and Idle Clients + + Existing HTTP clients and user agents typically retain authentication + information indefinitely. HTTP does not provide a mechanism for the + origin server to direct clients to discard these cached credentials, + since the protocol has no awareness of how credentials are obtained + + + +Fielding & Reschke Standards Track [Page 12] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + or managed by the user agent. The mechanisms for expiring or + revoking credentials can be specified as part of an authentication + scheme definition. + + Circumstances under which credential caching can interfere with the + application's security model include but are not limited to: + + o Clients that have been idle for an extended period, following + which the server might wish to cause the client to re-prompt the + user for credentials. + + o Applications that 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. + + User agents that cache credentials are encouraged to provide a + readily accessible mechanism for discarding cached credentials under + user control. + +6.3. Protection Spaces + + Authentication schemes that solely rely on the "realm" mechanism for + establishing a protection space will expose credentials to all + resources on an origin server. Clients that have successfully made + authenticated requests with a resource can use the same + authentication credentials for other resources on the same origin + server. This makes it possible for a different resource to harvest + authentication credentials for other resources. + + This is of particular concern when an origin server hosts resources + for multiple parties under the same canonical root URI (Section 2.2). + Possible mitigation strategies include restricting direct access to + authentication credentials (i.e., not making the content of the + Authorization request header field available), and separating + protection spaces by using a different host name (or port number) for + each party. + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 13] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +7. Acknowledgments + + This specification takes over the definition of the HTTP + Authentication Framework, previously defined in RFC 2617. We thank + John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. + Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for + their work on that specification. See Section 6 of [RFC2617] for + further acknowledgements. + + See Section 10 of [RFC7230] for the Acknowledgments related to this + document revision. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + +8.2. Informative References + + [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web + Applications and Web Services", The Open Web Application + Security Project (OWASP) 2.0.1, July 2005, + . + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + + +Fielding & Reschke Standards Track [Page 14] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + + [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., + Leach, P., Luotonen, A., and L. Stewart, "HTTP + Authentication: Basic and Digest Access Authentication", + RFC 2617, June 1999. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 15] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +Appendix A. Changes from RFCs 2616 and 2617 + + The framework for HTTP Authentication is now defined by this + document, rather than RFC 2617. + + The "realm" parameter is no longer always required on challenges; + consequently, the ABNF allows challenges without any auth parameters. + (Section 2) + + The "token68" alternative to auth-param lists has been added for + consistency with legacy authentication schemes such as "Basic". + (Section 2) + + This specification introduces the Authentication Scheme Registry, + along with considerations for new authentication schemes. + (Section 5.1) + +Appendix B. Imported ABNF + + The following core rules are included by reference, as defined in + Appendix B.1 of [RFC5234]: 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), LF (line feed), OCTET (any + 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII + character). + + The rules below are defined in [RFC7230]: + + BWS = + OWS = + quoted-string = + token = + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 16] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +Appendix C. Collected ABNF + + In the collected ABNF below, list rules are expanded as per Section + 1.2 of [RFC7230]. + + Authorization = credentials + + BWS = + + OWS = + + Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS + challenge ] ) + Proxy-Authorization = credentials + + WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge + ] ) + + auth-param = token BWS "=" BWS ( token / quoted-string ) + auth-scheme = token + + challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *( + OWS "," [ OWS auth-param ] ) ] ) ] + credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) + *( OWS "," [ OWS auth-param ] ) ] ) ] + + quoted-string = + + token = + token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) + *"=" + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 17] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +Index + + 4 + 401 Unauthorized (status code) 6 + 407 Proxy Authentication Required (status code) 6 + + A + Authorization header field 8 + + C + Canonical Root URI 5 + + G + Grammar + auth-param 4 + auth-scheme 4 + Authorization 8 + challenge 4 + credentials 5 + Proxy-Authenticate 8 + Proxy-Authorization 9 + token68 4 + WWW-Authenticate 7 + + P + Protection Space 5 + Proxy-Authenticate header field 8 + Proxy-Authorization header field 9 + + R + Realm 5 + + W + WWW-Authenticate header field 7 + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 18] + +RFC 7235 HTTP/1.1 Authentication June 2014 + + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe Systems Incorporated + 345 Park Ave + San Jose, CA 95110 + USA + + EMail: fielding@gbiv.com + URI: http://roy.gbiv.com/ + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fielding & Reschke Standards Track [Page 19] + === added file 'doc/rfc/rfc7238.txt' --- doc/rfc/rfc7238.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7238.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Reschke +Request for Comments: 7238 greenbytes +Category: Experimental June 2014 +ISSN: 2070-1721 + + + The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) + +Abstract + + This document specifies the additional Hypertext Transfer Protocol + (HTTP) status code 308 (Permanent Redirect). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. 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). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see 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/rfc7238. + +Copyright Notice + + Copyright (c) 2014 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. + + + + + + +Reschke Experimental [Page 1] + +RFC 7238 HTTP Status Code 308 June 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 2 + 3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . . 2 + 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 3 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 + +1. Introduction + + HTTP defines a set of status codes for the purpose of redirecting a + request to a different URI ([RFC3986]). The history of these status + codes is summarized in Section 6.4 of [RFC7231], which also + classifies the existing status codes into four categories. + + The first of these categories contains the status codes 301 (Moved + Permanently), 302 (Found), and 307 (Temporary Redirect), which can be + classified as below: + + +-------------------------------------------+-----------+-----------+ + | | Permanent | Temporary | + +-------------------------------------------+-----------+-----------+ + | Allows changing the request method from | 301 | 302 | + | POST to GET | | | + | Does not allow changing the request | - | 307 | + | method from POST to GET | | | + +-------------------------------------------+-----------+-----------+ + + Section 6.4.7 of [RFC7231] states that HTTP does not define a + permanent variant of status code 307; this specification adds the + status code 308, defining this missing variant (Section 3). + +2. Notational Conventions + + 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 [RFC2119]. + +3. 308 Permanent Redirect + + The 308 (Permanent Redirect) status code indicates that the target + resource has been assigned a new permanent URI and any future + references to this resource ought to use one of the enclosed URIs. + + + +Reschke Experimental [Page 2] + +RFC 7238 HTTP Status Code 308 June 2014 + + + Clients with link editing capabilities ought to automatically re-link + references to the effective request URI (Section 5.5 of [RFC7230]) to + one or more of the new references sent by the server, where possible. + + The server SHOULD generate a Location header field ([RFC7231], + Section 7.1.2) in the response containing a preferred URI reference + for the new permanent URI. The user agent MAY use the Location field + value for automatic redirection. The server's response payload + usually contains a short hypertext note with a hyperlink to the new + URI(s). + + A 308 response is cacheable by default; i.e., unless otherwise + indicated by the method definition or explicit cache controls (see + [RFC7234], Section 4.2.2). + + Note: This status code is similar to 301 (Moved Permanently) + ([RFC7231], Section 6.4.2), except that it does not allow changing + the request method from POST to GET. + +4. Deployment Considerations + + Section 6 of [RFC7231] requires recipients to treat unknown 3xx + status codes the same way as status code 300 Multiple Choices + ([RFC7231], Section 6.4.1). Thus, servers will not be able to rely + on automatic redirection happening similar to status codes 301, 302, + or 307. + + Therefore, initial use of status code 308 will be restricted to cases + where the server has sufficient confidence in the client's + understanding the new code or when a fallback to the semantics of + status code 300 is not problematic. Server implementers are advised + not to vary the status code based on characteristics of the request, + such as the User-Agent header field ("User-Agent Sniffing") -- doing + so usually results in code that is both hard to maintain and hard to + debug and would also require special attention to caching (i.e., + setting a "Vary" response header field, as defined in Section 7.1.4 + of [RFC7231]). + + Note that many existing HTML-based user agents will emulate a refresh + when encountering an HTML refresh directive ([HTML]). This + can be used as another fallback. For example: + + Client request: + + GET / HTTP/1.1 + Host: example.com + + + + + +Reschke Experimental [Page 3] + +RFC 7238 HTTP Status Code 308 June 2014 + + + Server response: + + HTTP/1.1 308 Permanent Redirect + Content-Type: text/html; charset=UTF-8 + Location: http://example.com/new + Content-Length: 454 + + + + + Permanent Redirect + + + +

+ The document has been moved to + http://example.com/new. +

+ + + +5. Security Considerations + + All security considerations that apply to HTTP redirects apply to the + 308 status code as well (see Section 9 of [RFC7231]). + +6. IANA Considerations + + The registration below has been added to the "Hypertext Transfer + Protocol (HTTP) Status Code Registry" (defined in Section 8.2 of + [RFC7231] and located at + ): + + +-------+--------------------+---------------------------------+ + | Value | Description | Reference | + +-------+--------------------+---------------------------------+ + | 308 | Permanent Redirect | Section 3 of this specification | + +-------+--------------------+---------------------------------+ + + + + + + + + + + +Reschke Experimental [Page 4] + +RFC 7238 HTTP Status Code 308 June 2014 + + +7. Acknowledgements + + The definition for the new status code 308 reuses text from the + HTTP/1.1 definitions of status codes 301 and 307. + + Furthermore, thanks to Ben Campbell, Cyrus Daboo, Eran Hammer-Lahav, + Bjoern Hoehrmann, Subramanian Moonesamy, Peter Saint-Andre, and + Robert Sparks for feedback on this document. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + June 2014. + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, June 2014. + +8.2. Informative References + + [HTML] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 + Specification", W3C Recommendation REC-html401-19991224, + December 1999, + . + + Latest version available at + . + + + + + + + + + + +Reschke Experimental [Page 5] + +RFC 7238 HTTP Status Code 308 June 2014 + + +Author's Address + + Julian F. Reschke + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Reschke Experimental [Page 6] + === added file 'doc/rfc/rfc7239.txt' --- doc/rfc/rfc7239.txt 1970-01-01 00:00:00 +0000 +++ doc/rfc/rfc7239.txt 2014-06-09 01:38:06 +0000 @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Petersson +Request for Comments: 7239 M. Nilsson +Category: Standards Track Opera Software +ISSN: 2070-1721 June 2014 + + + Forwarded HTTP Extension + +Abstract + + This document defines an HTTP extension header field that allows + proxy components to disclose information lost in the proxying + process, for example, the originating IP address of a request or IP + address of the proxy on the user-agent-facing interface. In a path + of proxying components, this makes it possible to arrange it so that + each subsequent component will have access to, for example, all IP + addresses used in the chain of proxied HTTP requests. + + This document also specifies guidelines for a proxy administrator to + anonymize the origin of a request. + +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/rfc7239. + + + + + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 1] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +Copyright Notice + + Copyright (c) 2014 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 ....................................................3 + 2. Notational Conventions ..........................................4 + 3. Syntax Notations ................................................4 + 4. Forwarded HTTP Header Field .....................................4 + 5. Parameters ......................................................6 + 5.1. Forwarded By ...............................................6 + 5.2. Forwarded For ..............................................6 + 5.3. Forwarded Host .............................................7 + 5.4. Forwarded Proto ............................................7 + 5.5. Extensions .................................................7 + 6. Node Identifiers ................................................8 + 6.1. IPv4 and IPv6 Identifiers ..................................9 + 6.2. The "unknown" Identifier ...................................9 + 6.3. Obfuscated Identifier ......................................9 + 7. Implementation Considerations ..................................10 + 7.1. HTTP Lists ................................................10 + 7.2. Header Field Preservation .................................10 + 7.3. Relation to Via ...........................................10 + 7.4. Transition ................................................11 + 7.5. Example Usage .............................................11 + 8. Security Considerations ........................................12 + 8.1. Header Validity and Integrity .............................12 + 8.2. Information Leak ..........................................12 + 8.3. Privacy Considerations ....................................12 + 9. IANA Considerations ............................................14 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + Appendix A. Acknowledgments .......................................16 + + + + + +Petersson & Nilsson Standards Track [Page 2] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +1. Introduction + + In today's HTTP landscape, there are a multitude of different + applications that act as proxies for the user agents. In many cases, + these proxies exists without the action or knowledge of the end-user. + These cases occur, for example, when the proxy exists as a part of + the infrastructure within the organization running the web server. + Such proxies may be used for features such as load balancing or + crypto offload. Another example is when the proxy is used within the + same organization as the user, and the proxy is used to cache + resources. However, these proxies make the requests appear as if + they originated from the proxy's IP address, and they may change + other information in the original request. This represents a loss of + information from the original request. + + This loss of information can cause problems for a web server that has + a specific use for the clients' IP addresses that will not be met by + using the address of the proxy or other information changed by the + proxy. The main uses of this information are for diagnostics, access + control, and abuse management. Diagnostic functions can include + event logging, troubleshooting, and statistics gathering, and the + information collected is usually only stored for short periods of + time and only gathered in response to a particular problem or a + complaint from the client. Access control can be operated by + configuring a list of client IP addresses from which access is + permitted, but this approach will not work if a proxy is used, unless + the proxy is trusted and is, itself, configured with a list of + allowed client addresses for the server. Cases of abuse require + identification of the abuser and this uses many of the same features + identified for diagnostics. + + Most of the time that a proxy is used, this loss of information is + not the primary purpose, or even a desired effect, of using the + proxy. Thus, to restore the desired functionality when a proxy is in + use, a way of disclosing the original information at the HTTP level + is needed. Clearly, however, when the purpose of using a proxy is to + provide client anonymity, the proxy will not use the feature defined + in this document. + + It should be noted that the use of a reverse proxy also hides + information. Again, where the loss of information is not a + deliberate function of the use of the reverse proxy, it can be + desirable to find a way to encode the information within the HTTP + messages so that the consumer can see it. + + A common way to disclose this information is by using the non- + standard header fields such as X-Forwarded-For, X-Forwarded-By, and + X-Forwarded-Proto. There are many benefits to using a standardized + + + +Petersson & Nilsson Standards Track [Page 3] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + approach to commonly desired protocol function: not least is + interoperability between implementations. This document standardizes + a header field called "Forwarded" and provides the syntax and + semantics for disclosing such information. "Forwarded" also combines + all the information within one single header field, making it + possible to correlate that information. With the header field format + described in this document, it is possible to know what information + belongs together, as long as the proxies are trusted. Such + conclusions are not possible to make with the X-Forwarded class of + header fields. The header field defined in this document is optional + such that implementations of proxies that are intended to provide + privacy are not required to operate or implement the header field. + + Note that similar issues to those described for proxies also arise + with use of NATs. This is discussed further in [RFC6269]. + +2. Notational Conventions + + 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 [RFC2119]. + +3. Syntax Notations + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234] with the list rule extension defined in Section + 7 of [RFC7230]. + +4. Forwarded HTTP Header Field + + The "Forwarded" HTTP header field is an OPTIONAL header field that, + when used, contains a list of parameter-identifier pairs that + disclose information that is altered or lost when a proxy is involved + in the path of the request. Due to the sensitive nature of the data + passed in this header field (see Sections 8.2 and 8.3), this header + field should be turned off by default. Further, each parameter + should be configured individually. "Forwarded" is only for use in + HTTP requests and is not to be used in HTTP responses. This applies + to forwarding proxies, as well as reverse proxies. Information + passed in this header field can be, for example, the source IP + address of the request, the IP address of the incoming interface on + the proxy, or whether HTTP or HTTPS was used. If the request is + passing through several proxies, each proxy can add a set of + parameters; it can also remove previously added "Forwarded" header + fields. + + + + + + +Petersson & Nilsson Standards Track [Page 4] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + The top-level list is represented as a list of HTTP header + field-values as defined in Section 3.2 of [RFC7230]. The first + element in this list holds information added by the first proxy that + implements and uses this header field, and each subsequent element + holds information added by each subsequent proxy. Because this + header field is optional, any proxy in the chain may choose not to + update this header field. Each field-value is a semicolon-separated + list; this sublist consists of parameter-identifier pairs. + Parameter-identifier pairs are grouped together by an equals sign. + Each parameter MUST NOT occur more than once per field-value. The + parameter names are case-insensitive. The header field value can be + defined in ABNF syntax as: + + Forwarded = 1#forwarded-element + + forwarded-element = + [ forwarded-pair ] *( ";" [ forwarded-pair ] ) + + forwarded-pair = token "=" value + value = token / quoted-string + + token = + quoted-string = + + Examples: + + Forwarded: for="_gazonk" + Forwarded: For="[2001:db8:cafe::17]:4711" + Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 + Forwarded: for=192.0.2.43, for=198.51.100.17 + + Note that as ":" and "[]" are not valid characters in "token", IPv6 + addresses are written as "quoted-string". + + A proxy server that wants to add a new "Forwarded" header field value + can either append it to the last existing "Forwarded" header field + after a comma separator or add a new field at the end of the header + block. A proxy MAY remove all "Forwarded" header fields from a + request. It MUST, however, ensure that the correct header field is + updated in case of multiple "Forwarded" header fields. + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 5] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +5. Parameters + + This document specifies a number of parameters and valid values for + each of them: + + o "by" identifies the user-agent facing interface of the proxy. + + o "for" identifies the node making the request to the proxy. + + o "host" is the host request header field as received by the proxy. + + o "proto" indicates what protocol was used to make the request. + +5.1. Forwarded By + + The "by" parameter is used to disclose the interface where the + request came in to the proxy server. When proxies choose to use the + "by" parameter, its default configuration SHOULD contain an + obfuscated identifier as described in Section 6.3. If the server + receiving proxied requests requires some address-based functionality, + this parameter MAY instead contain an IP address (and, potentially, a + port number). A third option is the "unknown" identifier described + in Section 6.2. + + The syntax of a "by" value, after potential quoted-string unescaping, + conforms to the "node" ABNF described in Section 6. + + This is primarily added by reverse proxies that wish to forward this + information to the backend server. It can also be interesting in a + multihomed environment to signal to backend servers from which the + request came. + +5.2. Forwarded For + + The "for" parameter is used to disclose information about the client + that initiated the request and subsequent proxies in a chain of + proxies. When proxies choose to use the "for" parameter, its default + configuration SHOULD contain an obfuscated identifier as described in + Section 6.3. If the server receiving proxied requests requires some + address-based functionality, this parameter MAY instead contain an IP + address (and, potentially, a port number). A third option is the + "unknown" identifier described in Section 6.2. + + The syntax of a "for" value, after potential quoted-string + unescaping, conforms to the "node" ABNF described in Section 6. + + + + + + +Petersson & Nilsson Standards Track [Page 6] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + In a chain of proxy servers where this is fully utilized, the first + "for" parameter will disclose the client where the request was first + made, followed by any subsequent proxy identifiers. The last proxy + in the chain is not part of the list of "for" parameters. The last + proxy's IP address, and optionally a port number, are, however, + readily available as the remote IP address at the transport layer. + It can, however, be more relevant to read information about the last + proxy from preceding "Forwarded" header field's "by" parameter, if + present. + +5.3. Forwarded Host + + The "host" parameter is used to forward the original value of the + "Host" header field. This can be used, for example, by the origin + server if a reverse proxy is rewriting the "Host" header field to + some internal host name. + + The syntax for a "host" value, after potential quoted-string + unescaping, MUST conform to the Host ABNF described in Section 5.4 of + [RFC7230]. + +5.4. Forwarded Proto + + The "proto" parameter has the value of the used protocol type. The + syntax of a "proto" value, after potential quoted-string unescaping, + MUST conform to the URI scheme name as defined in Section 3.1 in + [RFC3986] and registered with IANA according to [RFC4395]. Typical + values are "http" or "https". + + For example, in an environment where a reverse proxy is also used as + a crypto offloader, this allows the origin server to rewrite URLs in + a document to match the type of connection as the user agent + requested, even though all connections to the origin server are + unencrypted HTTP. + +5.5. Extensions + + Extensions allow for additional parameters and values. Extensions + can be particularly useful in reverse proxy environments. All + extension parameters SHOULD be registered in the "HTTP Forwarded + Parameter" registry. If certain extensions are expected to have + widespread deployment, they SHOULD also be standardized. This is + further discussed in Section 9. + + + + + + + + +Petersson & Nilsson Standards Track [Page 7] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +6. Node Identifiers + + The node identifier is one of the following: + + o The client's IP address, with an optional port number + + o A token indicating that the IP address of the client is not known + to the proxy server + + o A generated token, allowing for tracing and debugging, while + allowing the internal structure or sensitive information to be + hidden + + The node identifier is defined by the ABNF syntax as: + + node = nodename [ ":" node-port ] + nodename = IPv4address / "[" IPv6address "]" / + "unknown" / obfnode + + IPv4address = + IPv6address = + obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-") + + node-port = port / obfport + port = 1*5DIGIT + obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-") + + DIGIT = + ALPHA = + + Each of the identifiers may optionally have the port identifier, for + example, allowing the identification of the endpoint in a NATed + environment. The "node-port" can be identified either by its port + number or by a generated token obfuscating the real port number. An + obfuscated port may be used in situations where the possessor of the + proxy wants the ability to trace requests -- for example, in debug + purposes -- but does not want to reveal internal information. + + Note that the ABNF above also allows port numbers to be appended to + the "unknown" identifier. Interpretation of such notation is, + however, left to the possessor of a proxy adding such a value to the + header field. To distinguish an "obfport" from a port, the "obfport" + MUST have a leading underscore. Further, it MUST also consist of + only "ALPHA", "DIGIT", and the characters ".", "_", and "-". + + It is important to note that an IPv6 address and any nodename with + node-port specified MUST be quoted, since ":" is not an allowed + character in "token". + + + +Petersson & Nilsson Standards Track [Page 8] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Examples: + + "192.0.2.43:47011" + "[2001:db8:cafe::17]:47011" + +6.1. IPv4 and IPv6 Identifiers + + The ABNF rules for "IPv6address" and "IPv4address" are defined in + [RFC3986]. The "IPv6address" SHOULD comply with textual + representation recommendations [RFC5952] (for example, lowercase, + compression of zeros). + + Note that the IP address may be one from the internal nets, as + defined in [RFC1918] and [RFC4193]. Also, note that an IPv6 address + is always enclosed in square brackets. + +6.2. The "unknown" Identifier + + The "unknown" identifier is used when the identity of the preceding + entity is not known, but the proxy server still wants to signal that + a forwarding of the request was made. One example would be a proxy + server process generating an outgoing request without direct access + to the incoming request TCP socket. + +6.3. Obfuscated Identifier + + A generated identifier may be used where there is a wish to keep the + internal IP addresses secret, while still allowing the "Forwarded" + header field to be used for tracing and debugging. This can also be + useful if the proxy uses some sort of interface labels and there is a + desire to pass them rather than an IP address. Unless static + assignment of identifiers is necessary for the server's use of the + identifiers, obfuscated identifiers SHOULD be randomly generated for + each request. If the server requires that identifiers persist across + requests, they SHOULD NOT persist longer than client IP addresses. + To distinguish the obfuscated identifier from other identifiers, it + MUST have a leading underscore "_". Furthermore, it MUST also + consist of only "ALPHA", "DIGIT", and the characters ".", "_", and + "-". + Example: + + Forwarded: for=_hidden, for=_SEVKISEK + + + + + + + + + +Petersson & Nilsson Standards Track [Page 9] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +7. Implementation Considerations + +7.1. HTTP Lists + + Note that an HTTP list allows white spaces to occur between the + identifiers, and the list may be split over multiple header fields. + As an example, the header field + + Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown + + is equivalent to the header field + + Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown + + which is equivalent to the header fields + + Forwarded: for=192.0.2.43 + Forwarded: for="[2001:db8:cafe::17]", for=unknown + +7.2. Header Field Preservation + + There are some cases when this header field should be kept and some + cases where it should not be kept. A directly forwarded request + should preserve and possibly extend it. If a single incoming request + causes the proxy to make multiple outbound requests, special care + must be taken to decide whether or not the header field should be + preserved. In many cases, the header field should be preserved, but + if the outbound request is not a direct consequence of the incoming + request, the header field should not be preserved. Consider also the + case when a proxy has detected a content mismatch in a 304 response + and is following the instructions in [RFC7232], Section 4.1 to repeat + the request unconditionally, in which case the new request is still + basically a direct consequence of the origin request, and the header + field should probably be kept. + +7.3. Relation to Via + + The "Via" header field (see [RFC7230], Section 5.7.1) is a header + field with a similar use case as this header field. The "Via" header + field, however, only provides information about the proxy itself, and + thereby leaves out the information about the client connecting to the + proxy server. The "Forwarded" header field, on the other hand, has + relaying information from the client-facing side of the proxy server + as its main purpose. As "Via" is already widely deployed, its format + cannot be changed to address the problems that "Forwarded" addresses. + + + + + + +Petersson & Nilsson Standards Track [Page 10] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Note that it is not possible to combine information from this header + field with the information from the Via header field. Some proxies + will not update the "Forwarded" header field, some proxies will not + update the Via header field, and some proxies will update both. + +7.4. Transition + + If a proxy gets incoming requests with X-Forwarded-* header fields + present, it is encouraged to convert these into the header field + described in this document, if it can be done in a sensible way. If + the request only contains one type -- for example, X-Forwarded-For -- + this can be translated to "Forwarded", by prepending each element + with "for=". Note that IPv6 addresses may not be quoted in + X-Forwarded-For and may not be enclosed by square brackets, but they + are quoted and enclosed in square brackets in "Forwarded". + + X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17 + + becomes: + + Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]" + + However, special care must be taken if, for example, both + X-Forwarded-For and X-Forwarded-By exist. In such cases, it may not + be possible to do a conversion, since it is not possible to know in + which order the already existing fields were added. Also, note that + removing the X-Forwarded-For header field may cause issues for + parties that have not yet implemented support for this new header + field. + +7.5. Example Usage + + A request from a client with IP address 192.0.2.43 passes through a + proxy with IP address 198.51.100.17, then through another proxy with + IP address 203.0.113.60 before reaching an origin server. This + could, for example, be an office client behind a corporate malware + filter talking to a origin server through a reverse proxy. + + o The HTTP request between the client and the first proxy has no + "Forwarded" header field. + + o The HTTP request between the first and second proxy has a + "Forwarded: for=192.0.2.43" header field. + + o The HTTP request between the second proxy and the origin server + has a "Forwarded: for=192.0.2.43, + for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com" + header field. + + + +Petersson & Nilsson Standards Track [Page 11] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + Note that, at some points in a connection chain, the information + might not be updated in the "Forwarded" header field, either because + of lack of support of this HTTP extension or because of a policy + decision not to disclose information about this network component. + +8. Security Considerations + +8.1. Header Validity and Integrity + + The "Forwarded" HTTP header field cannot be relied upon to be + correct, as it may be modified, whether mistakenly or for malicious + reasons, by every node on the way to the server, including the client + making the request. + + One approach to ensure that the "Forwarded" HTTP header field is + correct is to verify the correctness of proxies and to whitelist them + as trusted. This approach has at least two weaknesses. First, the + chain of IP addresses listed before the request came to the proxy + cannot be trusted. Second, unless the communication between proxies + and the endpoint is secured, the data can be modified by an attacker + with access to the network. + +8.2. Information Leak + + The "Forwarded" HTTP header field can reveal internal structures of + the network setup behind the NAT or proxy setup, which may be + undesired. This can be addressed either by using obfuscated + elements, by preventing the internal nodes from updating the HTTP + header field, or by having an egress proxy remove entries that reveal + internal network information. + + This header field should never be copied into response messages by + origin servers or intermediaries, as it can reveal the whole proxy + chain to the client. As a side effect, special care must be taken in + hosting environments not to allow the TRACE request where the + "Forwarded" field is used, as it would appear in the body of the + response message. + +8.3. Privacy Considerations + + In recent years, there have been growing concerns about privacy. + There is a trade-off between ensuring privacy for users versus + disclosing information that is useful, for example, for debugging, + statistics, and generating location-dependent content. The + "Forwarded" HTTP header field, by design, exposes information that + some users consider privacy sensitive, in order to allow for such + uses. For any proxy, if the HTTP request contains header fields that + + + + +Petersson & Nilsson Standards Track [Page 12] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + specifically request privacy semantics, the proxy SHOULD NOT use the + "Forwarded" header field, nor in any other manner pass private + information, such as IP addresses, on to the next hop. + + The client's IP address, that may be forwarded in the "for" parameter + of this header field, is considered to be privacy sensitive by many + people, as the IP address may be able to uniquely identify a client, + what operator the user is using, and possibly a rough estimation of + where the user is geographically located. + + Proxies using this extension will preserve the information of a + direct connection. This has an end-user privacy impact regardless of + whether the end-user or deployer knows or expects that this is the + case. + + Implementers and deployers of such proxies need to consider whether, + and how, deploying this extension affects user privacy. + + The default configuration for both the "by" and "for" parameters + SHOULD contain obfuscated identifiers. These identifiers SHOULD be + randomly generated per request. If identifiers that persist across + requests are required, their lifetimes SHOULD be limited and they + SHOULD NOT persist longer than client IP addresses. When generating + obfuscated identifiers, care must be taken not to include potentially + sensitive information in them. + + Note that users' IP addresses may already be forwarded by proxies + using the header field X-Forwarded-For, which is widely used. It + should also be noted that if the user were doing the connection + directly without passing the proxy, the client's IP address would be + sent to the web server. Users that do not actively choose an + anonymizing proxy cannot rely on having their IP address shielded. + These users who want to minimize the risk of being tracked must also + note that there are other ways information may leak, for example, by + browser header field fingerprinting. The Forwarded header field + itself, even when used without a uniquely identifying client + identifier, may make fingerprinting more feasible by revealing the + chain of proxies traversed by the client's request. + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 13] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +9. IANA Considerations + + This document specifies the HTTP header field listed below, which has + been added to the "Permanent Message Header Field Names" registry + defined in [RFC3864]. + + Header field: Forwarded + Applicable protocol: http + Status: standard + Author/Change controller: + IETF (iesg@ietf.org) + Internet Engineering Task Force + Specification document(s): this specification (Section 4) + Related information: None + + The "Forwarded" header field contains parameters for which IANA has + created and now maintains a new registry entitled "HTTP Forwarded + Parameters". Initial registrations are given below. For future + assignments, the registration procedure is IETF Review [RFC5226]. + The security and privacy implications of all new parameters should be + thoroughly documented. New parameters and their values MUST conform + with the forwarded-pair as defined in ABNF in Section 4. Further, a + short description should be provided in the registration. + + +-------------+---------------------------------------+-------------+ + | Parameter | Description | Reference | + | name | | | + +-------------+---------------------------------------+-------------+ + | by | IP address of incoming interface of a | Section 5.1 | + | | proxy | | + | for | IP address of client making a request | Section 5.2 | + | | through a proxy | | + | host | Host header field of the incoming | Section 5.3 | + | | request | | + | proto | Application protocol used for | Section 5.4 | + | | incoming request | | + +-------------+---------------------------------------+-------------+ + + Table 1: Initial Assignments + +10. References + +10.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + + + +Petersson & Nilsson Standards Track [Page 14] + +RFC 7239 Forwarded HTTP Extension June 2014 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and + Registration Procedures for New URI Schemes", BCP 35, + RFC 4395, February 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, August 2010. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, June 2014. + + [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Conditional Requests", RFC 7232, + June 2014. + +10.2. Informative References + + [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. + Roberts, "Issues with IP Address Sharing", RFC 6269, + June 2011. + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 15] + +RFC 7239 Forwarded HTTP Extension June 2014 + + +Appendix A. Acknowledgments + + Thanks to Per Cederqvist, Alissa Cooper, Adrian Farrel, Stephen + Farrell, Ned Freed, Per Hedbor, Amos Jeffries, Poul-Henning Kamp, + Murray S. Kucherawy, Barry Leiba, Salvatore Loreto, Alexey Melnikov, + S. Moonesamy, Susan Nichols, Mark Nottingham, Julian Reschke, John + Sullivan, Willy Tarreau, and Dan Wing for their feedback. + +Authors' Addresses + + Andreas Petersson + Opera Software + + EMail: andreas@sbin.se + + + Martin Nilsson + Opera Software + S:t Larsgatan 12 + Linkoping SE-582 24 + + EMail: nilsson@opera.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Petersson & Nilsson Standards Track [Page 16] +