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
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
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Fielding
-Request for Comments: 2616 UC Irvine
-Obsoletes: 2068 J. Gettys
-Category: Standards Track Compaq/W3C
- J. Mogul
- Compaq
- H. Frystyk
- W3C/MIT
- L. Masinter
- Xerox
- P. Leach
- Microsoft
- T. Berners-Lee
- W3C/MIT
- June 1999
-
-
- Hypertext Transfer Protocol -- HTTP/1.1
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-Abstract
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. It is a generic, stateless, protocol which can be used for
- many tasks beyond its use for hypertext, such as name servers and
- distributed object management systems, through extension of its
- request methods, error codes and headers [47]. A feature of HTTP is
- the typing and negotiation of data representation, allowing systems
- to be built independently of the data being transferred.
-
- HTTP has been in use by the World-Wide Web global information
- initiative since 1990. This specification defines the protocol
- referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 1]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-Table of Contents
-
- 1 Introduction ...................................................7
- 1.1 Purpose......................................................7
- 1.2 Requirements .................................................8
- 1.3 Terminology ..................................................8
- 1.4 Overall Operation ...........................................12
- 2 Notational Conventions and Generic Grammar ....................14
- 2.1 Augmented BNF ...............................................14
- 2.2 Basic Rules .................................................15
- 3 Protocol Parameters ...........................................17
- 3.1 HTTP Version ................................................17
- 3.2 Uniform Resource Identifiers ................................18
- 3.2.1 General Syntax ...........................................19
- 3.2.2 http URL .................................................19
- 3.2.3 URI Comparison ...........................................20
- 3.3 Date/Time Formats ...........................................20
- 3.3.1 Full Date ................................................20
- 3.3.2 Delta Seconds ............................................21
- 3.4 Character Sets ..............................................21
- 3.4.1 Missing Charset ..........................................22
- 3.5 Content Codings .............................................23
- 3.6 Transfer Codings ............................................24
- 3.6.1 Chunked Transfer Coding ..................................25
- 3.7 Media Types .................................................26
- 3.7.1 Canonicalization and Text Defaults .......................27
- 3.7.2 Multipart Types ..........................................27
- 3.8 Product Tokens ..............................................28
- 3.9 Quality Values ..............................................29
- 3.10 Language Tags ...............................................29
- 3.11 Entity Tags .................................................30
- 3.12 Range Units .................................................30
- 4 HTTP Message ..................................................31
- 4.1 Message Types ...............................................31
- 4.2 Message Headers .............................................31
- 4.3 Message Body ................................................32
- 4.4 Message Length ..............................................33
- 4.5 General Header Fields .......................................34
- 5 Request .......................................................35
- 5.1 Request-Line ................................................35
- 5.1.1 Method ...................................................36
- 5.1.2 Request-URI ..............................................36
- 5.2 The Resource Identified by a Request ........................38
- 5.3 Request Header Fields .......................................38
- 6 Response ......................................................39
- 6.1 Status-Line .................................................39
- 6.1.1 Status Code and Reason Phrase ............................39
- 6.2 Response Header Fields ......................................41
-
-
-
-Fielding, et al. Standards Track [Page 2]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 7 Entity ........................................................42
- 7.1 Entity Header Fields ........................................42
- 7.2 Entity Body .................................................43
- 7.2.1 Type .....................................................43
- 7.2.2 Entity Length ............................................43
- 8 Connections ...................................................44
- 8.1 Persistent Connections ......................................44
- 8.1.1 Purpose ..................................................44
- 8.1.2 Overall Operation ........................................45
- 8.1.3 Proxy Servers ............................................46
- 8.1.4 Practical Considerations .................................46
- 8.2 Message Transmission Requirements ...........................47
- 8.2.1 Persistent Connections and Flow Control ..................47
- 8.2.2 Monitoring Connections for Error Status Messages .........48
- 8.2.3 Use of the 100 (Continue) Status .........................48
- 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
- 9 Method Definitions ............................................51
- 9.1 Safe and Idempotent Methods .................................51
- 9.1.1 Safe Methods .............................................51
- 9.1.2 Idempotent Methods .......................................51
- 9.2 OPTIONS .....................................................52
- 9.3 GET .........................................................53
- 9.4 HEAD ........................................................54
- 9.5 POST ........................................................54
- 9.6 PUT .........................................................55
- 9.7 DELETE ......................................................56
- 9.8 TRACE .......................................................56
- 9.9 CONNECT .....................................................57
- 10 Status Code Definitions ......................................57
- 10.1 Informational 1xx ...........................................57
- 10.1.1 100 Continue .............................................58
- 10.1.2 101 Switching Protocols ..................................58
- 10.2 Successful 2xx ..............................................58
- 10.2.1 200 OK ...................................................58
- 10.2.2 201 Created ..............................................59
- 10.2.3 202 Accepted .............................................59
- 10.2.4 203 Non-Authoritative Information ........................59
- 10.2.5 204 No Content ...........................................60
- 10.2.6 205 Reset Content ........................................60
- 10.2.7 206 Partial Content ......................................60
- 10.3 Redirection 3xx .............................................61
- 10.3.1 300 Multiple Choices .....................................61
- 10.3.2 301 Moved Permanently ....................................62
- 10.3.3 302 Found ................................................62
- 10.3.4 303 See Other ............................................63
- 10.3.5 304 Not Modified .........................................63
- 10.3.6 305 Use Proxy ............................................64
- 10.3.7 306 (Unused) .............................................64
-
-
-
-Fielding, et al. Standards Track [Page 3]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 10.3.8 307 Temporary Redirect ...................................65
- 10.4 Client Error 4xx ............................................65
- 10.4.1 400 Bad Request .........................................65
- 10.4.2 401 Unauthorized ........................................66
- 10.4.3 402 Payment Required ....................................66
- 10.4.4 403 Forbidden ...........................................66
- 10.4.5 404 Not Found ...........................................66
- 10.4.6 405 Method Not Allowed ..................................66
- 10.4.7 406 Not Acceptable ......................................67
- 10.4.8 407 Proxy Authentication Required .......................67
- 10.4.9 408 Request Timeout .....................................67
- 10.4.10 409 Conflict ............................................67
- 10.4.11 410 Gone ................................................68
- 10.4.12 411 Length Required .....................................68
- 10.4.13 412 Precondition Failed .................................68
- 10.4.14 413 Request Entity Too Large ............................69
- 10.4.15 414 Request-URI Too Long ................................69
- 10.4.16 415 Unsupported Media Type ..............................69
- 10.4.17 416 Requested Range Not Satisfiable .....................69
- 10.4.18 417 Expectation Failed ..................................70
- 10.5 Server Error 5xx ............................................70
- 10.5.1 500 Internal Server Error ................................70
- 10.5.2 501 Not Implemented ......................................70
- 10.5.3 502 Bad Gateway ..........................................70
- 10.5.4 503 Service Unavailable ..................................70
- 10.5.5 504 Gateway Timeout ......................................71
- 10.5.6 505 HTTP Version Not Supported ...........................71
- 11 Access Authentication ........................................71
- 12 Content Negotiation ..........................................71
- 12.1 Server-driven Negotiation ...................................72
- 12.2 Agent-driven Negotiation ....................................73
- 12.3 Transparent Negotiation .....................................74
- 13 Caching in HTTP ..............................................74
- 13.1.1 Cache Correctness ........................................75
- 13.1.2 Warnings .................................................76
- 13.1.3 Cache-control Mechanisms .................................77
- 13.1.4 Explicit User Agent Warnings .............................78
- 13.1.5 Exceptions to the Rules and Warnings .....................78
- 13.1.6 Client-controlled Behavior ...............................79
- 13.2 Expiration Model ............................................79
- 13.2.1 Server-Specified Expiration ..............................79
- 13.2.2 Heuristic Expiration .....................................80
- 13.2.3 Age Calculations .........................................80
- 13.2.4 Expiration Calculations ..................................83
- 13.2.5 Disambiguating Expiration Values .........................84
- 13.2.6 Disambiguating Multiple Responses ........................84
- 13.3 Validation Model ............................................85
- 13.3.1 Last-Modified Dates ......................................86
-
-
-
-Fielding, et al. Standards Track [Page 4]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 13.3.2 Entity Tag Cache Validators ..............................86
- 13.3.3 Weak and Strong Validators ...............................86
- 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
- 13.3.5 Non-validating Conditionals ..............................90
- 13.4 Response Cacheability .......................................91
- 13.5 Constructing Responses From Caches ..........................92
- 13.5.1 End-to-end and Hop-by-hop Headers ........................92
- 13.5.2 Non-modifiable Headers ...................................92
- 13.5.3 Combining Headers ........................................94
- 13.5.4 Combining Byte Ranges ....................................95
- 13.6 Caching Negotiated Responses ................................95
- 13.7 Shared and Non-Shared Caches ................................96
- 13.8 Errors or Incomplete Response Cache Behavior ................97
- 13.9 Side Effects of GET and HEAD ................................97
- 13.10 Invalidation After Updates or Deletions ...................97
- 13.11 Write-Through Mandatory ...................................98
- 13.12 Cache Replacement .........................................99
- 13.13 History Lists .............................................99
- 14 Header Field Definitions ....................................100
- 14.1 Accept .....................................................100
- 14.2 Accept-Charset .............................................102
- 14.3 Accept-Encoding ............................................102
- 14.4 Accept-Language ............................................104
- 14.5 Accept-Ranges ..............................................105
- 14.6 Age ........................................................106
- 14.7 Allow ......................................................106
- 14.8 Authorization ..............................................107
- 14.9 Cache-Control ..............................................108
- 14.9.1 What is Cacheable .......................................109
- 14.9.2 What May be Stored by Caches ............................110
- 14.9.3 Modifications of the Basic Expiration Mechanism .........111
- 14.9.4 Cache Revalidation and Reload Controls ..................113
- 14.9.5 No-Transform Directive ..................................115
- 14.9.6 Cache Control Extensions ................................116
- 14.10 Connection ...............................................117
- 14.11 Content-Encoding .........................................118
- 14.12 Content-Language .........................................118
- 14.13 Content-Length ...........................................119
- 14.14 Content-Location .........................................120
- 14.15 Content-MD5 ..............................................121
- 14.16 Content-Range ............................................122
- 14.17 Content-Type .............................................124
- 14.18 Date .....................................................124
- 14.18.1 Clockless Origin Server Operation ......................125
- 14.19 ETag .....................................................126
- 14.20 Expect ...................................................126
- 14.21 Expires ..................................................127
- 14.22 From .....................................................128
-
-
-
-Fielding, et al. Standards Track [Page 5]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 14.23 Host .....................................................128
- 14.24 If-Match .................................................129
- 14.25 If-Modified-Since ........................................130
- 14.26 If-None-Match ............................................132
- 14.27 If-Range .................................................133
- 14.28 If-Unmodified-Since ......................................134
- 14.29 Last-Modified ............................................134
- 14.30 Location .................................................135
- 14.31 Max-Forwards .............................................136
- 14.32 Pragma ...................................................136
- 14.33 Proxy-Authenticate .......................................137
- 14.34 Proxy-Authorization ......................................137
- 14.35 Range ....................................................138
- 14.35.1 Byte Ranges ...........................................138
- 14.35.2 Range Retrieval Requests ..............................139
- 14.36 Referer ..................................................140
- 14.37 Retry-After ..............................................141
- 14.38 Server ...................................................141
- 14.39 TE .......................................................142
- 14.40 Trailer ..................................................143
- 14.41 Transfer-Encoding..........................................143
- 14.42 Upgrade ..................................................144
- 14.43 User-Agent ...............................................145
- 14.44 Vary .....................................................145
- 14.45 Via ......................................................146
- 14.46 Warning ..................................................148
- 14.47 WWW-Authenticate .........................................150
- 15 Security Considerations .......................................150
- 15.1 Personal Information....................................151
- 15.1.1 Abuse of Server Log Information .........................151
- 15.1.2 Transfer of Sensitive Information .......................151
- 15.1.3 Encoding Sensitive Information in URI's .................152
- 15.1.4 Privacy Issues Connected to Accept Headers ..............152
- 15.2 Attacks Based On File and Path Names .......................153
- 15.3 DNS Spoofing ...............................................154
- 15.4 Location Headers and Spoofing ..............................154
- 15.5 Content-Disposition Issues .................................154
- 15.6 Authentication Credentials and Idle Clients ................155
- 15.7 Proxies and Caching ........................................155
- 15.7.1 Denial of Service Attacks on Proxies....................156
- 16 Acknowledgments .............................................156
- 17 References ..................................................158
- 18 Authors' Addresses ..........................................162
- 19 Appendices ..................................................164
- 19.1 Internet Media Type message/http and application/http ......164
- 19.2 Internet Media Type multipart/byteranges ...................165
- 19.3 Tolerant Applications ......................................166
- 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
-
-
-
-Fielding, et al. Standards Track [Page 6]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 19.4.1 MIME-Version ............................................167
- 19.4.2 Conversion to Canonical Form ............................167
- 19.4.3 Conversion of Date Formats ..............................168
- 19.4.4 Introduction of Content-Encoding ........................168
- 19.4.5 No Content-Transfer-Encoding ............................168
- 19.4.6 Introduction of Transfer-Encoding .......................169
- 19.4.7 MHTML and Line Length Limitations .......................169
- 19.5 Additional Features ........................................169
- 19.5.1 Content-Disposition .....................................170
- 19.6 Compatibility with Previous Versions .......................170
- 19.6.1 Changes from HTTP/1.0 ...................................171
- 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
- 19.6.3 Changes from RFC 2068 ...................................172
- 20 Index .......................................................175
- 21 Full Copyright Statement ....................................176
-
-1 Introduction
-
-1.1 Purpose
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. HTTP has been in use by the World-Wide Web global
- information initiative since 1990. The first version of HTTP,
- referred to as HTTP/0.9, was a simple protocol for raw data transfer
- across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
- the protocol by allowing messages to be in the format of MIME-like
- messages, containing metainformation about the data transferred and
- modifiers on the request/response semantics. However, HTTP/1.0 does
- not sufficiently take into consideration the effects of hierarchical
- proxies, caching, the need for persistent connections, or virtual
- hosts. In addition, the proliferation of incompletely-implemented
- applications calling themselves "HTTP/1.0" has necessitated a
- protocol version change in order for two communicating applications
- to determine each other's true capabilities.
-
- This specification defines the protocol referred to as "HTTP/1.1".
- This protocol includes more stringent requirements than HTTP/1.0 in
- order to ensure reliable implementation of its features.
-
- Practical information systems require more functionality than simple
- retrieval, including search, front-end update, and annotation. HTTP
- allows an open-ended set of methods and headers that indicate the
- purpose of a request [47]. It builds on the discipline of reference
- provided by the Uniform Resource Identifier (URI) [3], as a location
- (URL) [4] or name (URN) [20], for indicating the resource to which a
-
-
-
-
-
-Fielding, et al. Standards Track [Page 7]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- method is to be applied. Messages are passed in a format similar to
- that used by Internet mail [9] as defined by the Multipurpose
- Internet Mail Extensions (MIME) [7].
-
- HTTP is also used as a generic protocol for communication between
- user agents and proxies/gateways to other Internet systems, including
- those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
- and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
- access to resources available from diverse applications.
-
-1.2 Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [34].
-
- An implementation is not compliant if it fails to satisfy one or more
- of the MUST or REQUIRED level requirements for the protocols it
- implements. An implementation that satisfies all the MUST or REQUIRED
- level and all the SHOULD level requirements for its protocols is said
- to be "unconditionally compliant"; one that satisfies all the MUST
- level requirements but not all the SHOULD level requirements for its
- protocols is said to be "conditionally compliant."
-
-1.3 Terminology
-
- This specification uses a number of terms to refer to the roles
- played by participants in, and objects of, the HTTP communication.
-
- connection
- A transport layer virtual circuit established between two programs
- for the purpose of communication.
-
- message
- The basic unit of HTTP communication, consisting of a structured
- sequence of octets matching the syntax defined in section 4 and
- transmitted via the connection.
-
- request
- An HTTP request message, as defined in section 5.
-
- response
- An HTTP response message, as defined in section 6.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 8]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- resource
- A network data object or service that can be identified by a URI,
- as defined in section 3.2. Resources may be available in multiple
- representations (e.g. multiple languages, data formats, size, and
- resolutions) or vary in other ways.
-
- entity
- The information transferred as the payload of a request or
- response. An entity consists of metainformation in the form of
- entity-header fields and content in the form of an entity-body, as
- described in section 7.
-
- representation
- An entity included with a response that is subject to content
- negotiation, as described in section 12. There may exist multiple
- representations associated with a particular response status.
-
- content negotiation
- The mechanism for selecting the appropriate representation when
- servicing a request, as described in section 12. The
- representation of entities in any response can be negotiated
- (including error responses).
-
- variant
- A resource may have one, or more than one, representation(s)
- associated with it at any given instant. Each of these
- representations is termed a `varriant'. Use of the term `variant'
- does not necessarily imply that the resource is subject to content
- negotiation.
-
- client
- A program that establishes connections for the purpose of sending
- requests.
-
- user agent
- The client which initiates a request. These are often browsers,
- editors, spiders (web-traversing robots), or other end user tools.
-
- server
- An application program that accepts connections in order to
- service requests by sending back responses. Any given program may
- be capable of being both a client and a server; our use of these
- terms refers only to the role being performed by the program for a
- particular connection, rather than to the program's capabilities
- in general. Likewise, any server may act as an origin server,
- proxy, gateway, or tunnel, switching behavior based on the nature
- of each request.
-
-
-
-
-Fielding, et al. Standards Track [Page 9]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- origin server
- The server on which a given resource resides or is to be created.
-
- proxy
- An intermediary program which acts as both a server and a client
- for the purpose of making requests on behalf of other clients.
- Requests are serviced internally or by passing them on, with
- possible translation, to other servers. A proxy MUST implement
- both the client and server requirements of this specification. A
- "transparent proxy" is a proxy that does not modify the request or
- response beyond what is required for proxy authentication and
- identification. A "non-transparent proxy" is a proxy that modifies
- the request or response in order to provide some added service to
- the user agent, such as group annotation services, media type
- transformation, protocol reduction, or anonymity filtering. Except
- where either transparent or non-transparent behavior is explicitly
- stated, the HTTP proxy requirements apply to both types of
- proxies.
-
- gateway
- A server which acts as an intermediary for some other server.
- Unlike a proxy, a gateway receives requests as if it were the
- origin server for the requested resource; the requesting client
- may not be aware that it is communicating with a gateway.
-
- tunnel
- An intermediary program which is acting as a blind relay between
- two connections. Once active, a tunnel is not considered a party
- to the HTTP communication, though the tunnel may have been
- initiated by an HTTP request. The tunnel ceases to exist when both
- ends of the relayed connections are closed.
-
- cache
- A program's local store of response messages and the subsystem
- that controls its message storage, retrieval, and deletion. A
- cache stores cacheable responses in order to reduce the response
- time and network bandwidth consumption on future, equivalent
- requests. Any client or server may include a cache, though a cache
- cannot be used by a server that is acting as a tunnel.
-
- cacheable
- A response is cacheable if a cache is allowed to store a copy of
- the response message for use in answering subsequent requests. The
- rules for determining the cacheability of HTTP responses are
- defined in section 13. Even if a resource is cacheable, there may
- be additional constraints on whether a cache can use the cached
- copy for a particular request.
-
-
-
-
-Fielding, et al. Standards Track [Page 10]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- first-hand
- A response is first-hand if it comes directly and without
- unnecessary delay from the origin server, perhaps via one or more
- proxies. A response is also first-hand if its validity has just
- been checked directly with the origin server.
-
- explicit expiration time
- The time at which the origin server intends that an entity should
- no longer be returned by a cache without further validation.
-
- heuristic expiration time
- An expiration time assigned by a cache when no explicit expiration
- time is available.
-
- age
- The age of a response is the time since it was sent by, or
- successfully validated with, the origin server.
-
- freshness lifetime
- The length of time between the generation of a response and its
- expiration time.
-
- fresh
- A response is fresh if its age has not yet exceeded its freshness
- lifetime.
-
- stale
- A response is stale if its age has passed its freshness lifetime.
-
- semantically transparent
- A cache behaves in a "semantically transparent" manner, with
- respect to a particular response, when its use affects neither the
- requesting client nor the origin server, except to improve
- performance. When a cache is semantically transparent, the client
- receives exactly the same response (except for hop-by-hop headers)
- that it would have received had its request been handled directly
- by the origin server.
-
- validator
- A protocol element (e.g., an entity tag or a Last-Modified time)
- that is used to find out whether a cache entry is an equivalent
- copy of an entity.
-
- upstream/downstream
- Upstream and downstream describe the flow of a message: all
- messages flow from upstream to downstream.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 11]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- inbound/outbound
- Inbound and outbound refer to the request and response paths for
- messages: "inbound" means "traveling toward the origin server",
- and "outbound" means "traveling toward the user agent"
-
-1.4 Overall Operation
-
- The HTTP protocol is a request/response protocol. A client sends a
- request to the server in the form of a request method, URI, and
- protocol version, followed by a MIME-like message containing request
- modifiers, client information, and possible body content over a
- connection with a server. The server responds with a status line,
- including the message's protocol version and a success or error code,
- followed by a MIME-like message containing server information, entity
- metainformation, and possible entity-body content. The relationship
- between HTTP and MIME is described in appendix 19.4.
-
- Most HTTP communication is initiated by a user agent and consists of
- a request to be applied to a resource on some origin server. In the
- simplest case, this may be accomplished via a single connection (v)
- between the user agent (UA) and the origin server (O).
-
- request chain ------------------------>
- UA -------------------v------------------- O
- <----------------------- response chain
-
- A more complicated situation occurs when one or more intermediaries
- are present in the request/response chain. There are three common
- forms of intermediary: proxy, gateway, and tunnel. A proxy is a
- forwarding agent, receiving requests for a URI in its absolute form,
- rewriting all or part of the message, and forwarding the reformatted
- request toward the server identified by the URI. A gateway is a
- receiving agent, acting as a layer above some other server(s) and, if
- necessary, translating the requests to the underlying server's
- protocol. A tunnel acts as a relay point between two connections
- without changing the messages; tunnels are used when the
- communication needs to pass through an intermediary (such as a
- firewall) even when the intermediary cannot understand the contents
- of the messages.
-
- request chain -------------------------------------->
- UA -----v----- A -----v----- B -----v----- C -----v----- O
- <------------------------------------- response chain
-
- The figure above shows three intermediaries (A, B, and C) between the
- user agent and origin server. A request or response message that
- travels the whole chain will pass through four separate connections.
- This distinction is important because some HTTP communication options
-
-
-
-Fielding, et al. Standards Track [Page 12]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- may apply only to the connection with the nearest, non-tunnel
- neighbor, only to the end-points of the chain, or to all connections
- along the chain. Although the diagram is linear, each participant may
- be engaged in multiple, simultaneous communications. For example, B
- may be receiving requests from many clients other than A, and/or
- forwarding requests to servers other than C, at the same time that it
- is handling A's request.
-
- Any party to the communication which is not acting as a tunnel may
- employ an internal cache for handling requests. The effect of a cache
- is that the request/response chain is shortened if one of the
- participants along the chain has a cached response applicable to that
- request. The following illustrates the resulting chain if B has a
- cached copy of an earlier response from O (via C) for a request which
- has not been cached by UA or A.
-
- request chain ---------->
- UA -----v----- A -----v----- B - - - - - - C - - - - - - O
- <--------- response chain
-
- Not all responses are usefully cacheable, and some requests may
- contain modifiers which place special requirements on cache behavior.
- HTTP requirements for cache behavior and cacheable responses are
- defined in section 13.
-
- In fact, there are a wide variety of architectures and configurations
- of caches and proxies currently being experimented with or deployed
- across the World Wide Web. These systems include national hierarchies
- of proxy caches to save transoceanic bandwidth, systems that
- broadcast or multicast cache entries, organizations that distribute
- subsets of cached data via CD-ROM, and so on. HTTP systems are used
- in corporate intranets over high-bandwidth links, and for access via
- PDAs with low-power radio links and intermittent connectivity. The
- goal of HTTP/1.1 is to support the wide diversity of configurations
- already deployed while introducing protocol constructs that meet the
- needs of those who build web applications that require high
- reliability and, failing that, at least reliable indications of
- failure.
-
- HTTP communication usually takes place over TCP/IP connections. The
- default port is TCP 80 [19], but other ports can be used. This does
- not preclude HTTP from being implemented on top of any other protocol
- on the Internet, or on other networks. HTTP only presumes a reliable
- transport; any protocol that provides such guarantees can be used;
- the mapping of the HTTP/1.1 request and response structures onto the
- transport data units of the protocol in question is outside the scope
- of this specification.
-
-
-
-
-Fielding, et al. Standards Track [Page 13]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- In HTTP/1.0, most implementations used a new connection for each
- request/response exchange. In HTTP/1.1, a connection may be used for
- one or more request/response exchanges, although connections may be
- closed for a variety of reasons (see section 8.1).
-
-2 Notational Conventions and Generic Grammar
-
-2.1 Augmented BNF
-
- All of the mechanisms specified in this document are described in
- both prose and an augmented Backus-Naur Form (BNF) similar to that
- used by RFC 822 [9]. Implementors will need to be familiar with the
- notation in order to understand this specification. The augmented BNF
- includes the following constructs:
-
- name = definition
- The name of a rule is simply the name itself (without any
- enclosing "<" and ">") and is separated from its definition by the
- equal "=" character. White space is only significant in that
- indentation of continuation lines is used to indicate a rule
- definition that spans more than one line. Certain basic rules are
- in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
- brackets are used within definitions whenever their presence will
- facilitate discerning the use of rule names.
-
- "literal"
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
-
- rule1 | rule2
- Elements separated by a bar ("|") are alternatives, e.g., "yes |
- no" will accept yes or no.
-
- (rule1 rule2)
- Elements enclosed in parentheses are treated as a single element.
- Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
- foo elem" and "elem bar elem".
-
- *rule
- The character "*" preceding an element indicates repetition. The
- full form is "<n>*<m>element" indicating at least <n> and at most
- <m> occurrences of element. Default values are 0 and infinity so
- that "*(element)" allows any number, including zero; "1*element"
- requires at least one; and "1*2element" allows one or two.
-
- [rule]
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
-
-
-
-Fielding, et al. Standards Track [Page 14]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- N rule
- Specific repetition: "<n>(element)" is equivalent to
- "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
- Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
- alphabetic characters.
-
- #rule
- A construct "#" is defined, similar to "*", for defining lists of
- elements. The full form is "<n>#<m>element" indicating at least
- <n> and at most <m> elements, each separated by one or more commas
- (",") and OPTIONAL linear white space (LWS). This makes the usual
- form of lists very easy; a rule such as
- ( *LWS element *( *LWS "," *LWS element ))
- can be shown as
- 1#element
- Wherever this construct is used, null elements are allowed, but do
- not contribute to the count of elements present. That is,
- "(element), , (element) " is permitted, but counts as only two
- elements. Therefore, where at least one element is required, at
- least one non-null element MUST be present. Default values are 0
- and infinity so that "#element" allows any number, including zero;
- "1#element" requires at least one; and "1#2element" allows one or
- two.
-
- ; comment
- A semi-colon, set off some distance to the right of rule text,
- starts a comment that continues to the end of line. This is a
- simple way of including useful notes in parallel with the
- specifications.
-
- implied *LWS
- The grammar described by this specification is word-based. Except
- where noted otherwise, linear white space (LWS) can be included
- between any two adjacent words (token or quoted-string), and
- between adjacent words and separators, without changing the
- interpretation of a field. At least one delimiter (LWS and/or
-
- separators) MUST exist between any two tokens (for the definition
- of "token" below), since they would otherwise be interpreted as a
- single token.
-
-2.2 Basic Rules
-
- The following rules are used throughout this specification to
- describe basic parsing constructs. The US-ASCII coded character set
- is defined by ANSI X3.4-1986 [21].
-
-
-
-
-
-Fielding, et al. Standards Track [Page 15]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
- CTL = <any US-ASCII control character
- (octets 0 - 31) and DEL (127)>
- CR = <US-ASCII CR, carriage return (13)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, space (32)>
- HT = <US-ASCII HT, horizontal-tab (9)>
- <"> = <US-ASCII double-quote mark (34)>
-
- HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
- protocol elements except the entity-body (see appendix 19.3 for
- tolerant applications). The end-of-line marker within an entity-body
- is defined by its associated media type, as described in section 3.7.
-
- CRLF = CR LF
-
- HTTP/1.1 header field values can be folded onto multiple lines if the
- continuation line begins with a space or horizontal tab. All linear
- white space, including folding, has the same semantics as SP. A
- recipient MAY replace any linear white space with a single SP before
- interpreting the field value or forwarding the message downstream.
-
- LWS = [CRLF] 1*( SP | HT )
-
- The TEXT rule is only used for descriptive field contents and values
- that are not intended to be interpreted by the message parser. Words
- of *TEXT MAY contain characters from character sets other than ISO-
- 8859-1 [22] only when encoded according to the rules of RFC 2047
- [14].
-
- TEXT = <any OCTET except CTLs,
- but including LWS>
-
- A CRLF is allowed in the definition of TEXT only as part of a header
- field continuation. It is expected that the folding LWS will be
- replaced with a single SP before interpretation of the TEXT value.
-
- Hexadecimal numeric characters are used in several protocol elements.
-
- HEX = "A" | "B" | "C" | "D" | "E" | "F"
- | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
-
-
-
-
-
-Fielding, et al. Standards Track [Page 16]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Many HTTP/1.1 header field values consist of words separated by LWS
- or special characters. These special characters MUST be in a quoted
- string to be used within a parameter value (as defined in section
- 3.6).
-
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@"
- | "," | ";" | ":" | "\" | <">
- | "/" | "[" | "]" | "?" | "="
- | "{" | "}" | SP | HT
-
- Comments can be included in some HTTP header fields by surrounding
- the comment text with parentheses. Comments are only allowed in
- fields containing "comment" as part of their field value definition.
- In all other fields, parentheses are considered part of the field
- value.
-
- comment = "(" *( ctext | quoted-pair | comment ) ")"
- ctext = <any TEXT excluding "(" and ")">
-
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
-
- quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
- qdtext = <any TEXT except <">>
-
- The backslash character ("\") MAY be used as a single-character
- quoting mechanism only within quoted-string and comment constructs.
-
- quoted-pair = "\" CHAR
-
-3 Protocol Parameters
-
-3.1 HTTP Version
-
- HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
- of the protocol. The protocol versioning policy is intended to allow
- the sender to indicate the format of a message and its capacity for
- understanding further HTTP communication, rather than the features
- obtained via that communication. No change is made to the version
- number for the addition of message components which do not affect
- communication behavior or which only add to extensible field values.
- The <minor> number is incremented when the changes made to the
- protocol add features which do not change the general message parsing
- algorithm, but which may add to the message semantics and imply
- additional capabilities of the sender. The <major> number is
- incremented when the format of a message within the protocol is
- changed. See RFC 2145 [36] for a fuller explanation.
-
-
-
-Fielding, et al. Standards Track [Page 17]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The version of an HTTP message is indicated by an HTTP-Version field
- in the first line of the message.
-
- HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
-
- Note that the major and minor numbers MUST be treated as separate
- integers and that each MAY be incremented higher than a single digit.
- Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
- lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
- MUST NOT be sent.
-
- An application that sends a request or response message that includes
- HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
- with this specification. Applications that are at least conditionally
- compliant with this specification SHOULD use an HTTP-Version of
- "HTTP/1.1" in their messages, and MUST do so for any message that is
- not compatible with HTTP/1.0. For more details on when to send
- specific HTTP-Version values, see RFC 2145 [36].
-
- The HTTP version of an application is the highest HTTP version for
- which the application is at least conditionally compliant.
-
- Proxy and gateway applications need to be careful when forwarding
- messages in protocol versions different from that of the application.
- Since the protocol version indicates the protocol capability of the
- sender, a proxy/gateway MUST NOT send a message with a version
- indicator which is greater than its actual version. If a higher
- version request is received, the proxy/gateway MUST either downgrade
- the request version, or respond with an error, or switch to tunnel
- behavior.
-
- Due to interoperability problems with HTTP/1.0 proxies discovered
- since the publication of RFC 2068[33], caching proxies MUST, gateways
- MAY, and tunnels MUST NOT upgrade the request to the highest version
- they support. The proxy/gateway's response to that request MUST be in
- the same major version as the request.
-
- Note: Converting between versions of HTTP may involve modification
- of header fields required or forbidden by the versions involved.
-
-3.2 Uniform Resource Identifiers
-
- URIs have been known by many names: WWW addresses, Universal Document
- Identifiers, Universal Resource Identifiers [3], and finally the
- combination of Uniform Resource Locators (URL) [4] and Names (URN)
- [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
- simply formatted strings which identify--via name, location, or any
- other characteristic--a resource.
-
-
-
-Fielding, et al. Standards Track [Page 18]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-3.2.1 General Syntax
-
- URIs in HTTP can be represented in absolute form or relative to some
- known base URI [11], depending upon the context of their use. The two
- forms are differentiated by the fact that absolute URIs always begin
- with a scheme name followed by a colon. For definitive information on
- URL syntax and semantics, see "Uniform Resource Identifiers (URI):
- Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
- 1738 [4] and RFC 1808 [11]). This specification adopts the
- definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
- "host","abs_path", "rel_path", and "authority" from that
- specification.
-
- The HTTP protocol does not place any a priori limit on the length of
- a URI. Servers MUST be able to handle the URI of any resource they
- serve, and SHOULD be able to handle URIs of unbounded length if they
- provide GET-based forms that could generate such URIs. A server
- SHOULD return 414 (Request-URI Too Long) status if a URI is longer
- than the server can handle (see section 10.4.15).
-
- Note: Servers ought to be cautious about depending on URI lengths
- above 255 bytes, because some older client or proxy
- implementations might not properly support these lengths.
-
-3.2.2 http URL
-
- The "http" scheme is used to locate network resources via the HTTP
- protocol. This section defines the scheme-specific syntax and
- semantics for http URLs.
-
- http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
-
- If the port is empty or not given, port 80 is assumed. The semantics
- are that the identified resource is located at the server listening
- for TCP connections on that port of that host, and the Request-URI
- for the resource is abs_path (section 5.1.2). The use of IP addresses
- in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
- the abs_path is not present in the URL, it MUST be given as "/" when
- used as a Request-URI for a resource (section 5.1.2). If a proxy
- receives a host name which is not a fully qualified domain name, it
- MAY add its domain to the host name it received. If a proxy receives
- a fully qualified domain name, the proxy MUST NOT change the host
- name.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 19]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-3.2.3 URI Comparison
-
- When comparing two URIs to decide if they match or not, a client
- SHOULD use a case-sensitive octet-by-octet comparison of the entire
- URIs, with these exceptions:
-
- - A port that is empty or not given is equivalent to the default
- port for that URI-reference;
-
- - Comparisons of host names MUST be case-insensitive;
-
- - Comparisons of scheme names MUST be case-insensitive;
-
- - An empty abs_path is equivalent to an abs_path of "/".
-
- Characters other than those in the "reserved" and "unsafe" sets (see
- RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
-
- For example, the following three URIs are equivalent:
-
- http://abc.com:80/~smith/home.html
- http://ABC.com/%7Esmith/home.html
- http://ABC.com:/%7esmith/home.html
-
-3.3 Date/Time Formats
-
-3.3.1 Full Date
-
- HTTP applications have historically allowed three different formats
- for the representation of date/time stamps:
-
- Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
- Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
- Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
-
- The first format is preferred as an Internet standard and represents
- a fixed-length subset of that defined by RFC 1123 [8] (an update to
- RFC 822 [9]). The second format is in common use, but is based on the
- obsolete RFC 850 [12] date format and lacks a four-digit year.
- HTTP/1.1 clients and servers that parse the date value MUST accept
- all three formats (for compatibility with HTTP/1.0), though they MUST
- only generate the RFC 1123 format for representing HTTP-date values
- in header fields. See section 19.3 for further information.
-
- Note: Recipients of date values are encouraged to be robust in
- accepting date values that may have been sent by non-HTTP
- applications, as is sometimes the case when retrieving or posting
- messages via proxies/gateways to SMTP or NNTP.
-
-
-
-Fielding, et al. Standards Track [Page 20]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- All HTTP date/time stamps MUST be represented in Greenwich Mean Time
- (GMT), without exception. For the purposes of HTTP, GMT is exactly
- equal to UTC (Coordinated Universal Time). This is indicated in the
- first two formats by the inclusion of "GMT" as the three-letter
- abbreviation for time zone, and MUST be assumed when reading the
- asctime format. HTTP-date is case sensitive and MUST NOT include
- additional LWS beyond that specifically included as SP in the
- grammar.
-
- HTTP-date = rfc1123-date | rfc850-date | asctime-date
- rfc1123-date = wkday "," SP date1 SP time SP "GMT"
- rfc850-date = weekday "," SP date2 SP time SP "GMT"
- asctime-date = wkday SP date3 SP time SP 4DIGIT
- date1 = 2DIGIT SP month SP 4DIGIT
- ; day month year (e.g., 02 Jun 1982)
- date2 = 2DIGIT "-" month "-" 2DIGIT
- ; day-month-year (e.g., 02-Jun-82)
- date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
- ; month day (e.g., Jun 2)
- time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; 00:00:00 - 23:59:59
- wkday = "Mon" | "Tue" | "Wed"
- | "Thu" | "Fri" | "Sat" | "Sun"
- weekday = "Monday" | "Tuesday" | "Wednesday"
- | "Thursday" | "Friday" | "Saturday" | "Sunday"
- month = "Jan" | "Feb" | "Mar" | "Apr"
- | "May" | "Jun" | "Jul" | "Aug"
- | "Sep" | "Oct" | "Nov" | "Dec"
-
- Note: HTTP requirements for the date/time stamp format apply only
- to their usage within the protocol stream. Clients and servers are
- not required to use these formats for user presentation, request
- logging, etc.
-
-3.3.2 Delta Seconds
-
- Some HTTP header fields allow a time value to be specified as an
- integer number of seconds, represented in decimal, after the time
- that the message was received.
-
- delta-seconds = 1*DIGIT
-
-3.4 Character Sets
-
- HTTP uses the same definition of the term "character set" as that
- described for MIME:
-
-
-
-
-
-Fielding, et al. Standards Track [Page 21]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The term "character set" is used in this document to refer to a
- method used with one or more tables to convert a sequence of octets
- into a sequence of characters. Note that unconditional conversion in
- the other direction is not required, in that not all characters may
- be available in a given character set and a character set may provide
- more than one sequence of octets to represent a particular character.
- This definition is intended to allow various kinds of character
- encoding, from simple single-table mappings such as US-ASCII to
- complex table switching methods such as those that use ISO-2022's
- techniques. However, the definition associated with a MIME character
- set name MUST fully specify the mapping to be performed from octets
- to characters. In particular, use of external profiling information
- to determine the exact mapping is not permitted.
-
- Note: This use of the term "character set" is more commonly
- referred to as a "character encoding." However, since HTTP and
- MIME share the same registry, it is important that the terminology
- also be shared.
-
- HTTP character sets are identified by case-insensitive tokens. The
- complete set of tokens is defined by the IANA Character Set registry
- [19].
-
- charset = token
-
- Although HTTP allows an arbitrary token to be used as a charset
- value, any token that has a predefined value within the IANA
- Character Set registry [19] MUST represent the character set defined
- by that registry. Applications SHOULD limit their use of character
- sets to those defined by the IANA registry.
-
- Implementors should be aware of IETF character set requirements [38]
- [41].
-
-3.4.1 Missing Charset
-
- Some HTTP/1.0 software has interpreted a Content-Type header without
- charset parameter incorrectly to mean "recipient should guess."
- Senders wishing to defeat this behavior MAY include a charset
- parameter even when the charset is ISO-8859-1 and SHOULD do so when
- it is known that it will not confuse the recipient.
-
- Unfortunately, some older HTTP/1.0 clients did not deal properly with
- an explicit charset parameter. HTTP/1.1 recipients MUST respect the
- charset label provided by the sender; and those user agents that have
- a provision to "guess" a charset MUST use the charset from the
-
-
-
-
-
-Fielding, et al. Standards Track [Page 22]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- content-type field if they support that charset, rather than the
- recipient's preference, when initially displaying a document. See
- section 3.7.1.
-
-3.5 Content Codings
-
- Content coding values indicate an encoding transformation that has
- been or can be applied to an entity. Content codings are primarily
- used to allow a document to be compressed or otherwise usefully
- transformed without losing the identity of its underlying media type
- and without loss of information. Frequently, the entity is stored in
- coded form, transmitted directly, and only decoded by the recipient.
-
- content-coding = token
-
- All content-coding values are case-insensitive. HTTP/1.1 uses
- content-coding values in the Accept-Encoding (section 14.3) and
- Content-Encoding (section 14.11) header fields. Although the value
- describes the content-coding, what is more important is that it
- indicates what decoding mechanism will be required to remove the
- encoding.
-
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- content-coding value tokens. Initially, the registry contains the
- following tokens:
-
- gzip An encoding format produced by the file compression program
- "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
- Lempel-Ziv coding (LZ77) with a 32 bit CRC.
-
- compress
- The encoding format produced by the common UNIX file compression
- program "compress". This format is an adaptive Lempel-Ziv-Welch
- coding (LZW).
-
- Use of program names for the identification of encoding formats
- is not desirable and is discouraged for future encodings. Their
- use here is representative of historical practice, not good
- design. For compatibility with previous implementations of HTTP,
- applications SHOULD consider "x-gzip" and "x-compress" to be
- equivalent to "gzip" and "compress" respectively.
-
- deflate
- The "zlib" format defined in RFC 1950 [31] in combination with
- the "deflate" compression mechanism described in RFC 1951 [29].
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 23]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- identity
- The default (identity) encoding; the use of no transformation
- whatsoever. This content-coding is used only in the Accept-
- Encoding header, and SHOULD NOT be used in the Content-Encoding
- header.
-
- New content-coding value tokens SHOULD be registered; to allow
- interoperability between clients and servers, specifications of the
- content coding algorithms needed to implement a new value SHOULD be
- publicly available and adequate for independent implementation, and
- conform to the purpose of content coding defined in this section.
-
-3.6 Transfer Codings
-
- Transfer-coding values are used to indicate an encoding
- transformation that has been, can be, or may need to be applied to an
- entity-body in order to ensure "safe transport" through the network.
- This differs from a content coding in that the transfer-coding is a
- property of the message, not of the original entity.
-
- transfer-coding = "chunked" | transfer-extension
- transfer-extension = token *( ";" parameter )
-
- Parameters are in the form of attribute/value pairs.
-
- parameter = attribute "=" value
- attribute = token
- value = token | quoted-string
-
- All transfer-coding values are case-insensitive. HTTP/1.1 uses
- transfer-coding values in the TE header field (section 14.39) and in
- the Transfer-Encoding header field (section 14.41).
-
- Whenever a transfer-coding is applied to a message-body, the set of
- transfer-codings MUST include "chunked", unless the message is
- terminated by closing the connection. When the "chunked" transfer-
- coding is used, it MUST be the last transfer-coding applied to the
- message-body. The "chunked" transfer-coding MUST NOT be applied more
- than once to a message-body. These rules allow the recipient to
- determine the transfer-length of the message (section 4.4).
-
- Transfer-codings are analogous to the Content-Transfer-Encoding
- values of MIME [7], which were designed to enable safe transport of
- binary data over a 7-bit transport service. However, safe transport
- has a different focus for an 8bit-clean transfer protocol. In HTTP,
- the only unsafe characteristic of message-bodies is the difficulty in
- determining the exact body length (section 7.2.2), or the desire to
- encrypt data over a shared transport.
-
-
-
-Fielding, et al. Standards Track [Page 24]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- transfer-coding value tokens. Initially, the registry contains the
- following tokens: "chunked" (section 3.6.1), "identity" (section
- 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
- (section 3.5).
-
- New transfer-coding value tokens SHOULD be registered in the same way
- as new content-coding value tokens (section 3.5).
-
- A server which receives an entity-body with a transfer-coding it does
- not understand SHOULD return 501 (Unimplemented), and close the
- connection. A server MUST NOT send transfer-codings to an HTTP/1.0
- client.
-
-3.6.1 Chunked Transfer Coding
-
- The chunked encoding modifies the body of a message in order to
- transfer it as a series of chunks, each with its own size indicator,
- followed by an OPTIONAL trailer containing entity-header fields. This
- allows dynamically produced content to be transferred along with the
- information necessary for the recipient to verify that it has
- received the full message.
-
- Chunked-Body = *chunk
- last-chunk
- trailer
- CRLF
-
- chunk = chunk-size [ chunk-extension ] CRLF
- chunk-data CRLF
- chunk-size = 1*HEX
- last-chunk = 1*("0") [ chunk-extension ] CRLF
-
- chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
- chunk-ext-name = token
- chunk-ext-val = token | quoted-string
- chunk-data = chunk-size(OCTET)
- trailer = *(entity-header CRLF)
-
- The chunk-size field is a string of hex digits indicating the size of
- the chunk. The chunked encoding is ended by any chunk whose size is
- zero, followed by the trailer, which is terminated by an empty line.
-
- The trailer allows the sender to include additional HTTP header
- fields at the end of the message. The Trailer header field can be
- used to indicate which header fields are included in a trailer (see
- section 14.40).
-
-
-
-
-Fielding, et al. Standards Track [Page 25]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- A server using chunked transfer-coding in a response MUST NOT use the
- trailer for any header fields unless at least one of the following is
- true:
-
- a)the request included a TE header field that indicates "trailers" is
- acceptable in the transfer-coding of the response, as described in
- section 14.39; or,
-
- b)the server is the origin server for the response, the trailer
- fields consist entirely of optional metadata, and the recipient
- could use the message (in a manner acceptable to the origin server)
- without receiving this metadata. In other words, the origin server
- is willing to accept the possibility that the trailer fields might
- be silently discarded along the path to the client.
-
- This requirement prevents an interoperability failure when the
- message is being received by an HTTP/1.1 (or later) proxy and
- forwarded to an HTTP/1.0 recipient. It avoids a situation where
- compliance with the protocol would have necessitated a possibly
- infinite buffer on the proxy.
-
- An example process for decoding a Chunked-Body is presented in
- appendix 19.4.6.
-
- All HTTP/1.1 applications MUST be able to receive and decode the
- "chunked" transfer-coding, and MUST ignore chunk-extension extensions
- they do not understand.
-
-3.7 Media Types
-
- HTTP uses Internet Media Types [17] in the Content-Type (section
- 14.17) and Accept (section 14.1) header fields in order to provide
- open and extensible data typing and type negotiation.
-
- media-type = type "/" subtype *( ";" parameter )
- type = token
- subtype = token
-
- Parameters MAY follow the type/subtype in the form of attribute/value
- pairs (as defined in section 3.6).
-
- The type, subtype, and parameter attribute names are case-
- insensitive. Parameter values might or might not be case-sensitive,
- depending on the semantics of the parameter name. Linear white space
- (LWS) MUST NOT be used between the type and subtype, nor between an
- attribute and its value. The presence or absence of a parameter might
- be significant to the processing of a media-type, depending on its
- definition within the media type registry.
-
-
-
-Fielding, et al. Standards Track [Page 26]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Note that some older HTTP applications do not recognize media type
- parameters. When sending data to older HTTP applications,
- implementations SHOULD only use media type parameters when they are
- required by that type/subtype definition.
-
- Media-type values are registered with the Internet Assigned Number
- Authority (IANA [19]). The media type registration process is
- outlined in RFC 1590 [17]. Use of non-registered media types is
- discouraged.
-
-3.7.1 Canonicalization and Text Defaults
-
- Internet media types are registered with a canonical form. An
- entity-body transferred via HTTP messages MUST be represented in the
- appropriate canonical form prior to its transmission except for
- "text" types, as defined in the next paragraph.
-
- When in canonical form, media subtypes of the "text" type use CRLF as
- the text line break. HTTP relaxes this requirement and allows the
- transport of text media with plain CR or LF alone representing a line
- break when it is done consistently for an entire entity-body. HTTP
- applications MUST accept CRLF, bare CR, and bare LF as being
- representative of a line break in text media received via HTTP. In
- addition, if the text is represented in a character set that does not
- use octets 13 and 10 for CR and LF respectively, as is the case for
- some multi-byte character sets, HTTP allows the use of whatever octet
- sequences are defined by that character set to represent the
- equivalent of CR and LF for line breaks. This flexibility regarding
- line breaks applies only to text media in the entity-body; a bare CR
- or LF MUST NOT be substituted for CRLF within any of the HTTP control
- structures (such as header fields and multipart boundaries).
-
- If an entity-body is encoded with a content-coding, the underlying
- data MUST be in a form defined above prior to being encoded.
-
- The "charset" parameter is used with some media types to define the
- character set (section 3.4) of the data. When no explicit charset
- parameter is provided by the sender, media subtypes of the "text"
- type are defined to have a default charset value of "ISO-8859-1" when
- received via HTTP. Data in character sets other than "ISO-8859-1" or
- its subsets MUST be labeled with an appropriate charset value. See
- section 3.4.1 for compatibility problems.
-
-3.7.2 Multipart Types
-
- MIME provides for a number of "multipart" types -- encapsulations of
- one or more entities within a single message-body. All multipart
- types share a common syntax, as defined in section 5.1.1 of RFC 2046
-
-
-
-Fielding, et al. Standards Track [Page 27]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- [40], and MUST include a boundary parameter as part of the media type
- value. The message body is itself a protocol element and MUST
- therefore use only CRLF to represent line breaks between body-parts.
- Unlike in RFC 2046, the epilogue of any multipart message MUST be
- empty; HTTP applications MUST NOT transmit the epilogue (even if the
- original multipart contains an epilogue). These restrictions exist in
- order to preserve the self-delimiting nature of a multipart message-
- body, wherein the "end" of the message-body is indicated by the
- ending multipart boundary.
-
- In general, HTTP treats a multipart message-body no differently than
- any other media type: strictly as payload. The one exception is the
- "multipart/byteranges" type (appendix 19.2) when it appears in a 206
- (Partial Content) response, which will be interpreted by some HTTP
- caching mechanisms as described in sections 13.5.4 and 14.16. In all
- other cases, an HTTP user agent SHOULD follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- The MIME header fields within each body-part of a multipart message-
- body do not have any significance to HTTP beyond that defined by
- their MIME semantics.
-
- In general, an HTTP user agent SHOULD follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- If an application receives an unrecognized multipart subtype, the
- application MUST treat it as being equivalent to "multipart/mixed".
-
- Note: The "multipart/form-data" type has been specifically defined
- for carrying form data suitable for processing via the POST
- request method, as described in RFC 1867 [15].
-
-3.8 Product Tokens
-
- Product tokens are used to allow communicating applications to
- identify themselves by software name and version. Most fields using
- product tokens also allow sub-products which form a significant part
- of the application to be listed, separated by white space. By
- convention, the products are listed in order of their significance
- for identifying the application.
-
- product = token ["/" product-version]
- product-version = token
-
- Examples:
-
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
- Server: Apache/0.8.4
-
-
-
-
-
-Fielding, et al. Standards Track [Page 28]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Product tokens SHOULD be short and to the point. They MUST NOT be
- used for advertising or other non-essential information. Although any
- token character MAY appear in a product-version, this token SHOULD
- only be used for a version identifier (i.e., successive versions of
- the same product SHOULD only differ in the product-version portion of
- the product value).
-
-3.9 Quality Values
-
- HTTP content negotiation (section 12) uses short "floating point"
- numbers to indicate the relative importance ("weight") of various
- negotiable parameters. A weight is normalized to a real number in
- the range 0 through 1, where 0 is the minimum and 1 the maximum
- value. If a parameter has a quality value of 0, then content with
- this parameter is `not acceptable' for the client. HTTP/1.1
- applications MUST NOT generate more than three digits after the
- decimal point. User configuration of these values SHOULD also be
- limited in this fashion.
-
- qvalue = ( "0" [ "." 0*3DIGIT ] )
- | ( "1" [ "." 0*3("0") ] )
-
- "Quality values" is a misnomer, since these values merely represent
- relative degradation in desired quality.
-
-3.10 Language Tags
-
- A language tag identifies a natural language spoken, written, or
- otherwise conveyed by human beings for communication of information
- to other human beings. Computer languages are explicitly excluded.
- HTTP uses language tags within the Accept-Language and Content-
- Language fields.
-
- The syntax and registry of HTTP language tags is the same as that
- defined by RFC 1766 [1]. In summary, a language tag is composed of 1
- or more parts: A primary language tag and a possibly empty series of
- subtags:
-
- language-tag = primary-tag *( "-" subtag )
- primary-tag = 1*8ALPHA
- subtag = 1*8ALPHA
-
- White space is not allowed within the tag and all tags are case-
- insensitive. The name space of language tags is administered by the
- IANA. Example tags include:
-
- en, en-US, en-cockney, i-cherokee, x-pig-latin
-
-
-
-
-Fielding, et al. Standards Track [Page 29]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- where any two-letter primary-tag is an ISO-639 language abbreviation
- and any two-letter initial subtag is an ISO-3166 country code. (The
- last three tags above are not registered tags; all but the last are
- examples of tags which could be registered in future.)
-
-3.11 Entity Tags
-
- Entity tags are used for comparing two or more entities from the same
- requested resource. HTTP/1.1 uses entity tags in the ETag (section
- 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
- If-Range (section 14.27) header fields. The definition of how they
- are used and compared as cache validators is in section 13.3.3. An
- entity tag consists of an opaque quoted string, possibly prefixed by
- a weakness indicator.
-
- entity-tag = [ weak ] opaque-tag
- weak = "W/"
- opaque-tag = quoted-string
-
- A "strong entity tag" MAY be shared by two entities of a resource
- only if they are equivalent by octet equality.
-
- A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
- two entities of a resource only if the entities are equivalent and
- could be substituted for each other with no significant change in
- semantics. A weak entity tag can only be used for weak comparison.
-
- An entity tag MUST be unique across all versions of all entities
- associated with a particular resource. A given entity tag value MAY
- be used for entities obtained by requests on different URIs. The use
- of the same entity tag value in conjunction with entities obtained by
- requests on different URIs does not imply the equivalence of those
- entities.
-
-3.12 Range Units
-
- HTTP/1.1 allows a client to request that only part (a range of) the
- response entity be included within the response. HTTP/1.1 uses range
- units in the Range (section 14.35) and Content-Range (section 14.16)
- header fields. An entity can be broken down into subranges according
- to various structural units.
-
- range-unit = bytes-unit | other-range-unit
- bytes-unit = "bytes"
- other-range-unit = token
-
- The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
- implementations MAY ignore ranges specified using other units.
-
-
-
-Fielding, et al. Standards Track [Page 30]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- HTTP/1.1 has been designed to allow implementations of applications
- that do not depend on knowledge of ranges.
-
-4 HTTP Message
-
-4.1 Message Types
-
- HTTP messages consist of requests from client to server and responses
- from server to client.
-
- HTTP-message = Request | Response ; HTTP/1.1 messages
-
- Request (section 5) and Response (section 6) messages use the generic
- message format of RFC 822 [9] for transferring entities (the payload
- of the message). Both types of message consist of a start-line, zero
- or more header fields (also known as "headers"), an empty line (i.e.,
- a line with nothing preceding the CRLF) indicating the end of the
- header fields, and possibly a message-body.
-
- generic-message = start-line
- *(message-header CRLF)
- CRLF
- [ message-body ]
- start-line = Request-Line | Status-Line
-
- In the interest of robustness, servers SHOULD ignore any empty
- line(s) received where a Request-Line is expected. In other words, if
- the server is reading the protocol stream at the beginning of a
- message and receives a CRLF first, it should ignore the CRLF.
-
- Certain buggy HTTP/1.0 client implementations generate extra CRLF's
- after a POST request. To restate what is explicitly forbidden by the
- BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
- extra CRLF.
-
-4.2 Message Headers
-
- HTTP header fields, which include general-header (section 4.5),
- request-header (section 5.3), response-header (section 6.2), and
- entity-header (section 7.1) fields, follow the same generic format as
- that given in Section 3.1 of RFC 822 [9]. Each header field consists
- of a name followed by a colon (":") and the field value. Field names
- are case-insensitive. The field value MAY be preceded by any amount
- of LWS, though a single SP is preferred. Header fields can be
- extended over multiple lines by preceding each extra line with at
- least one SP or HT. Applications ought to follow "common form", where
- one is known or indicated, when generating HTTP constructs, since
- there might exist some implementations that fail to accept anything
-
-
-
-Fielding, et al. Standards Track [Page 31]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- beyond the common forms.
-
- message-header = field-name ":" [ field-value ]
- field-name = token
- field-value = *( field-content | LWS )
- field-content = <the OCTETs making up the field-value
- and consisting of either *TEXT or combinations
- of token, separators, and quoted-string>
-
- The field-content does not include any leading or trailing LWS:
- linear white space occurring before the first non-whitespace
- character of the field-value or after the last non-whitespace
- character of the field-value. Such leading or trailing LWS MAY be
- removed without changing the semantics of the field value. Any LWS
- that occurs between field-content MAY be replaced with a single SP
- before interpreting the field value or forwarding the message
- downstream.
-
- The order in which header fields with differing field names are
- received is not significant. However, it is "good practice" to send
- general-header fields first, followed by request-header or response-
- header fields, and ending with the entity-header fields.
-
- Multiple message-header fields with the same field-name MAY be
- present in a message if and only if the entire field-value for that
- header field is defined as a comma-separated list [i.e., #(values)].
- It MUST be possible to combine the multiple header fields into one
- "field-name: field-value" pair, without changing the semantics of the
- message, by appending each subsequent field-value to the first, each
- separated by a comma. The order in which header fields with the same
- field-name are received is therefore significant to the
- interpretation of the combined field value, and thus a proxy MUST NOT
- change the order of these field values when a message is forwarded.
-
-4.3 Message Body
-
- The message-body (if any) of an HTTP message is used to carry the
- entity-body associated with the request or response. The message-body
- differs from the entity-body only when a transfer-coding has been
- applied, as indicated by the Transfer-Encoding header field (section
- 14.41).
-
- message-body = entity-body
- | <entity-body encoded as per Transfer-Encoding>
-
- Transfer-Encoding MUST be used to indicate any transfer-codings
- applied by an application to ensure safe and proper transfer of the
- message. Transfer-Encoding is a property of the message, not of the
-
-
-
-Fielding, et al. Standards Track [Page 32]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- entity, and thus MAY be added or removed by any application along the
- request/response chain. (However, section 3.6 places restrictions on
- when certain transfer-codings may be used.)
-
- The rules for when a message-body is allowed in a message differ for
- requests and responses.
-
- The presence of a message-body in a request is signaled by the
- inclusion of a Content-Length or Transfer-Encoding header field in
- the request's message-headers. A message-body MUST NOT be included in
- a request if the specification of the request method (section 5.1.1)
- does not allow sending an entity-body in requests. A server SHOULD
- read and forward a message-body on any request; if the request method
- does not include defined semantics for an entity-body, then the
- message-body SHOULD be ignored when handling the request.
-
- For response messages, whether or not a message-body is included with
- a message is dependent on both the request method and the response
- status code (section 6.1.1). All responses to the HEAD request method
- MUST NOT include a message-body, even though the presence of entity-
- header fields might lead one to believe they do. All 1xx
- (informational), 204 (no content), and 304 (not modified) responses
- MUST NOT include a message-body. All other responses do include a
- message-body, although it MAY be of zero length.
-
-4.4 Message Length
-
- The transfer-length of a message is the length of the message-body as
- it appears in the message; that is, after any transfer-codings have
- been applied. When a message-body is included with a message, the
- transfer-length of that body is determined by one of the following
- (in order of precedence):
-
- 1.Any response message which "MUST NOT" include a message-body (such
- as the 1xx, 204, and 304 responses and any response to a HEAD
- request) is always terminated by the first empty line after the
- header fields, regardless of the entity-header fields present in
- the message.
-
- 2.If a Transfer-Encoding header field (section 14.41) is present and
- has any value other than "identity", then the transfer-length is
- defined by use of the "chunked" transfer-coding (section 3.6),
- unless the message is terminated by closing the connection.
-
- 3.If a Content-Length header field (section 14.13) is present, its
- decimal value in OCTETs represents both the entity-length and the
- transfer-length. The Content-Length header field MUST NOT be sent
- if these two lengths are different (i.e., if a Transfer-Encoding
-
-
-
-Fielding, et al. Standards Track [Page 33]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- header field is present). If a message is received with both a
- Transfer-Encoding header field and a Content-Length header field,
- the latter MUST be ignored.
-
- 4.If the message uses the media type "multipart/byteranges", and the
- ransfer-length is not otherwise specified, then this self-
- elimiting media type defines the transfer-length. This media type
- UST NOT be used unless the sender knows that the recipient can arse
- it; the presence in a request of a Range header with ultiple byte-
- range specifiers from a 1.1 client implies that the lient can parse
- multipart/byteranges responses.
-
- A range header might be forwarded by a 1.0 proxy that does not
- understand multipart/byteranges; in this case the server MUST
- delimit the message using methods defined in items 1,3 or 5 of
- this section.
-
- 5.By the server closing the connection. (Closing the connection
- cannot be used to indicate the end of a request body, since that
- would leave no possibility for the server to send back a response.)
-
- For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
- containing a message-body MUST include a valid Content-Length header
- field unless the server is known to be HTTP/1.1 compliant. If a
- request contains a message-body and a Content-Length is not given,
- the server SHOULD respond with 400 (bad request) if it cannot
- determine the length of the message, or with 411 (length required) if
- it wishes to insist on receiving a valid Content-Length.
-
- All HTTP/1.1 applications that receive entities MUST accept the
- "chunked" transfer-coding (section 3.6), thus allowing this mechanism
- to be used for messages when the message length cannot be determined
- in advance.
-
- Messages MUST NOT include both a Content-Length header field and a
- non-identity transfer-coding. If the message does include a non-
- identity transfer-coding, the Content-Length MUST be ignored.
-
- When a Content-Length is given in a message where a message-body is
- allowed, its field value MUST exactly match the number of OCTETs in
- the message-body. HTTP/1.1 user agents MUST notify the user when an
- invalid length is received and detected.
-
-4.5 General Header Fields
-
- There are a few header fields which have general applicability for
- both request and response messages, but which do not apply to the
- entity being transferred. These header fields apply only to the
-
-
-
-Fielding, et al. Standards Track [Page 34]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- message being transmitted.
-
- general-header = Cache-Control ; Section 14.9
- | Connection ; Section 14.10
- | Date ; Section 14.18
- | Pragma ; Section 14.32
- | Trailer ; Section 14.40
- | Transfer-Encoding ; Section 14.41
- | Upgrade ; Section 14.42
- | Via ; Section 14.45
- | Warning ; Section 14.46
-
- General-header field names can be extended reliably only in
- combination with a change in the protocol version. However, new or
- experimental header fields may be given the semantics of general
- header fields if all parties in the communication recognize them to
- be general-header fields. Unrecognized header fields are treated as
- entity-header fields.
-
-5 Request
-
- A request message from a client to a server includes, within the
- first line of that message, the method to be applied to the resource,
- the identifier of the resource, and the protocol version in use.
-
- Request = Request-Line ; Section 5.1
- *(( general-header ; Section 4.5
- | request-header ; Section 5.3
- | entity-header ) CRLF) ; Section 7.1
- CRLF
- [ message-body ] ; Section 4.3
-
-5.1 Request-Line
-
- The Request-Line begins with a method token, followed by the
- Request-URI and the protocol version, and ending with CRLF. The
- elements are separated by SP characters. No CR or LF is allowed
- except in the final CRLF sequence.
-
- Request-Line = Method SP Request-URI SP HTTP-Version CRLF
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 35]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-5.1.1 Method
-
- The Method token indicates the method to be performed on the
- resource identified by the Request-URI. The method is case-sensitive.
-
- Method = "OPTIONS" ; Section 9.2
- | "GET" ; Section 9.3
- | "HEAD" ; Section 9.4
- | "POST" ; Section 9.5
- | "PUT" ; Section 9.6
- | "DELETE" ; Section 9.7
- | "TRACE" ; Section 9.8
- | "CONNECT" ; Section 9.9
- | extension-method
- extension-method = token
-
- The list of methods allowed by a resource can be specified in an
- Allow header field (section 14.7). The return code of the response
- always notifies the client whether a method is currently allowed on a
- resource, since the set of allowed methods can change dynamically. An
- origin server SHOULD return the status code 405 (Method Not Allowed)
- if the method is known by the origin server but not allowed for the
- requested resource, and 501 (Not Implemented) if the method is
- unrecognized or not implemented by the origin server. The methods GET
- and HEAD MUST be supported by all general-purpose servers. All other
- methods are OPTIONAL; however, if the above methods are implemented,
- they MUST be implemented with the same semantics as those specified
- in section 9.
-
-5.1.2 Request-URI
-
- The Request-URI is a Uniform Resource Identifier (section 3.2) and
- identifies the resource upon which to apply the request.
-
- Request-URI = "*" | absoluteURI | abs_path | authority
-
- The four options for Request-URI are dependent on the nature of the
- request. The asterisk "*" means that the request does not apply to a
- particular resource, but to the server itself, and is only allowed
- when the method used does not necessarily apply to a resource. One
- example would be
-
- OPTIONS * HTTP/1.1
-
- The absoluteURI form is REQUIRED when the request is being made to a
- proxy. The proxy is requested to forward the request or service it
- from a valid cache, and return the response. Note that the proxy MAY
- forward the request on to another proxy or directly to the server
-
-
-
-Fielding, et al. Standards Track [Page 36]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- specified by the absoluteURI. In order to avoid request loops, a
- proxy MUST be able to recognize all of its server names, including
- any aliases, local variations, and the numeric IP address. An example
- Request-Line would be:
-
- GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
-
- To allow for transition to absoluteURIs in all requests in future
- versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
- form in requests, even though HTTP/1.1 clients will only generate
- them in requests to proxies.
-
- The authority form is only used by the CONNECT method (section 9.9).
-
- The most common form of Request-URI is that used to identify a
- resource on an origin server or gateway. In this case the absolute
- path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
- the Request-URI, and the network location of the URI (authority) MUST
- be transmitted in a Host header field. For example, a client wishing
- to retrieve the resource above directly from the origin server would
- create a TCP connection to port 80 of the host "www.w3.org" and send
- the lines:
-
- GET /pub/WWW/TheProject.html HTTP/1.1
- Host: www.w3.org
-
- followed by the remainder of the Request. Note that the absolute path
- cannot be empty; if none is present in the original URI, it MUST be
- given as "/" (the server root).
-
- The Request-URI is transmitted in the format specified in section
- 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
- [42], the origin server MUST decode the Request-URI in order to
- properly interpret the request. Servers SHOULD respond to invalid
- Request-URIs with an appropriate status code.
-
- A transparent proxy MUST NOT rewrite the "abs_path" part of the
- received Request-URI when forwarding it to the next inbound server,
- except as noted above to replace a null abs_path with "/".
-
- Note: The "no rewrite" rule prevents the proxy from changing the
- meaning of the request when the origin server is improperly using
- a non-reserved URI character for a reserved purpose. Implementors
- should be aware that some pre-HTTP/1.1 proxies have been known to
- rewrite the Request-URI.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 37]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-5.2 The Resource Identified by a Request
-
- The exact resource identified by an Internet request is determined by
- examining both the Request-URI and the Host header field.
-
- An origin server that does not allow resources to differ by the
- requested host MAY ignore the Host header field value when
- determining the resource identified by an HTTP/1.1 request. (But see
- section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
-
- An origin server that does differentiate resources based on the host
- requested (sometimes referred to as virtual hosts or vanity host
- names) MUST use the following rules for determining the requested
- resource on an HTTP/1.1 request:
-
- 1. If Request-URI is an absoluteURI, the host is part of the
- Request-URI. Any Host header field value in the request MUST be
- ignored.
-
- 2. If the Request-URI is not an absoluteURI, and the request includes
- a Host header field, the host is determined by the Host header
- field value.
-
- 3. If the host as determined by rule 1 or 2 is not a valid host on
- the server, the response MUST be a 400 (Bad Request) error message.
-
- Recipients of an HTTP/1.0 request that lacks a Host header field MAY
- attempt to use heuristics (e.g., examination of the URI path for
- something unique to a particular host) in order to determine what
- exact resource is being requested.
-
-5.3 Request Header Fields
-
- The request-header fields allow the client to pass additional
- information about the request, and about the client itself, to the
- server. These fields act as request modifiers, with semantics
- equivalent to the parameters on a programming language method
- invocation.
-
- request-header = Accept ; Section 14.1
- | Accept-Charset ; Section 14.2
- | Accept-Encoding ; Section 14.3
- | Accept-Language ; Section 14.4
- | Authorization ; Section 14.8
- | Expect ; Section 14.20
- | From ; Section 14.22
- | Host ; Section 14.23
- | If-Match ; Section 14.24
-
-
-
-Fielding, et al. Standards Track [Page 38]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- | If-Modified-Since ; Section 14.25
- | If-None-Match ; Section 14.26
- | If-Range ; Section 14.27
- | If-Unmodified-Since ; Section 14.28
- | Max-Forwards ; Section 14.31
- | Proxy-Authorization ; Section 14.34
- | Range ; Section 14.35
- | Referer ; Section 14.36
- | TE ; Section 14.39
- | User-Agent ; Section 14.43
-
- Request-header field names can be extended reliably only in
- combination with a change in the protocol version. However, new or
- experimental header fields MAY be given the semantics of request-
- header fields if all parties in the communication recognize them to
- be request-header fields. Unrecognized header fields are treated as
- entity-header fields.
-
-6 Response
-
- After receiving and interpreting a request message, a server responds
- with an HTTP response message.
-
- Response = Status-Line ; Section 6.1
- *(( general-header ; Section 4.5
- | response-header ; Section 6.2
- | entity-header ) CRLF) ; Section 7.1
- CRLF
- [ message-body ] ; Section 7.2
-
-6.1 Status-Line
-
- The first line of a Response message is the Status-Line, consisting
- of the protocol version followed by a numeric status code and its
- associated textual phrase, with each element separated by SP
- characters. No CR or LF is allowed except in the final CRLF sequence.
-
- Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-
-6.1.1 Status Code and Reason Phrase
-
- The Status-Code element is a 3-digit integer result code of the
- attempt to understand and satisfy the request. These codes are fully
- defined in section 10. The Reason-Phrase is intended to give a short
- textual description of the Status-Code. The Status-Code is intended
- for use by automata and the Reason-Phrase is intended for the human
- user. The client is not required to examine or display the Reason-
- Phrase.
-
-
-
-Fielding, et al. Standards Track [Page 39]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The first digit of the Status-Code defines the class of response. The
- last two digits do not have any categorization role. There are 5
- values for the first digit:
-
- - 1xx: Informational - Request received, continuing process
-
- - 2xx: Success - The action was successfully received,
- understood, and accepted
-
- - 3xx: Redirection - Further action must be taken in order to
- complete the request
-
- - 4xx: Client Error - The request contains bad syntax or cannot
- be fulfilled
-
- - 5xx: Server Error - The server failed to fulfill an apparently
- valid request
-
- The individual values of the numeric status codes defined for
- HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
- presented below. The reason phrases listed here are only
- recommendations -- they MAY be replaced by local equivalents without
- affecting the protocol.
-
- Status-Code =
- "100" ; Section 10.1.1: Continue
- | "101" ; Section 10.1.2: Switching Protocols
- | "200" ; Section 10.2.1: OK
- | "201" ; Section 10.2.2: Created
- | "202" ; Section 10.2.3: Accepted
- | "203" ; Section 10.2.4: Non-Authoritative Information
- | "204" ; Section 10.2.5: No Content
- | "205" ; Section 10.2.6: Reset Content
- | "206" ; Section 10.2.7: Partial Content
- | "300" ; Section 10.3.1: Multiple Choices
- | "301" ; Section 10.3.2: Moved Permanently
- | "302" ; Section 10.3.3: Found
- | "303" ; Section 10.3.4: See Other
- | "304" ; Section 10.3.5: Not Modified
- | "305" ; Section 10.3.6: Use Proxy
- | "307" ; Section 10.3.8: Temporary Redirect
- | "400" ; Section 10.4.1: Bad Request
- | "401" ; Section 10.4.2: Unauthorized
- | "402" ; Section 10.4.3: Payment Required
- | "403" ; Section 10.4.4: Forbidden
- | "404" ; Section 10.4.5: Not Found
- | "405" ; Section 10.4.6: Method Not Allowed
- | "406" ; Section 10.4.7: Not Acceptable
-
-
-
-Fielding, et al. Standards Track [Page 40]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- | "407" ; Section 10.4.8: Proxy Authentication Required
- | "408" ; Section 10.4.9: Request Time-out
- | "409" ; Section 10.4.10: Conflict
- | "410" ; Section 10.4.11: Gone
- | "411" ; Section 10.4.12: Length Required
- | "412" ; Section 10.4.13: Precondition Failed
- | "413" ; Section 10.4.14: Request Entity Too Large
- | "414" ; Section 10.4.15: Request-URI Too Large
- | "415" ; Section 10.4.16: Unsupported Media Type
- | "416" ; Section 10.4.17: Requested range not satisfiable
- | "417" ; Section 10.4.18: Expectation Failed
- | "500" ; Section 10.5.1: Internal Server Error
- | "501" ; Section 10.5.2: Not Implemented
- | "502" ; Section 10.5.3: Bad Gateway
- | "503" ; Section 10.5.4: Service Unavailable
- | "504" ; Section 10.5.5: Gateway Time-out
- | "505" ; Section 10.5.6: HTTP Version not supported
- | extension-code
-
- extension-code = 3DIGIT
- Reason-Phrase = *<TEXT, excluding CR, LF>
-
- HTTP status codes are extensible. HTTP applications are not required
- to understand the meaning of all registered status codes, though such
- understanding is obviously desirable. However, applications MUST
- understand the class of any status code, as indicated by the first
- digit, and treat any unrecognized response as being equivalent to the
- x00 status code of that class, with the exception that an
- unrecognized response MUST NOT be cached. For example, if an
- unrecognized status code of 431 is received by the client, it can
- safely assume that there was something wrong with its request and
- treat the response as if it had received a 400 status code. In such
- cases, user agents SHOULD present to the user the entity returned
- with the response, since that entity is likely to include human-
- readable information which will explain the unusual status.
-
-6.2 Response Header Fields
-
- The response-header fields allow the server to pass additional
- information about the response which cannot be placed in the Status-
- Line. These header fields give information about the server and about
- further access to the resource identified by the Request-URI.
-
- response-header = Accept-Ranges ; Section 14.5
- | Age ; Section 14.6
- | ETag ; Section 14.19
- | Location ; Section 14.30
- | Proxy-Authenticate ; Section 14.33
-
-
-
-Fielding, et al. Standards Track [Page 41]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- | Retry-After ; Section 14.37
- | Server ; Section 14.38
- | Vary ; Section 14.44
- | WWW-Authenticate ; Section 14.47
-
- Response-header field names can be extended reliably only in
- combination with a change in the protocol version. However, new or
- experimental header fields MAY be given the semantics of response-
- header fields if all parties in the communication recognize them to
- be response-header fields. Unrecognized header fields are treated as
- entity-header fields.
-
-7 Entity
-
- Request and Response messages MAY transfer an entity if not otherwise
- restricted by the request method or response status code. An entity
- consists of entity-header fields and an entity-body, although some
- responses will only include the entity-headers.
-
- In this section, both sender and recipient refer to either the client
- or the server, depending on who sends and who receives the entity.
-
-7.1 Entity Header Fields
-
- Entity-header fields define metainformation about the entity-body or,
- if no body is present, about the resource identified by the request.
- Some of this metainformation is OPTIONAL; some might be REQUIRED by
- portions of this specification.
-
- entity-header = Allow ; Section 14.7
- | Content-Encoding ; Section 14.11
- | Content-Language ; Section 14.12
- | Content-Length ; Section 14.13
- | Content-Location ; Section 14.14
- | Content-MD5 ; Section 14.15
- | Content-Range ; Section 14.16
- | Content-Type ; Section 14.17
- | Expires ; Section 14.21
- | Last-Modified ; Section 14.29
- | extension-header
-
- extension-header = message-header
-
- The extension-header mechanism allows additional entity-header fields
- to be defined without changing the protocol, but these fields cannot
- be assumed to be recognizable by the recipient. Unrecognized header
- fields SHOULD be ignored by the recipient and MUST be forwarded by
- transparent proxies.
-
-
-
-Fielding, et al. Standards Track [Page 42]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-7.2 Entity Body
-
- The entity-body (if any) sent with an HTTP request or response is in
- a format and encoding defined by the entity-header fields.
-
- entity-body = *OCTET
-
- An entity-body is only present in a message when a message-body is
- present, as described in section 4.3. The entity-body is obtained
- from the message-body by decoding any Transfer-Encoding that might
- have been applied to ensure safe and proper transfer of the message.
-
-7.2.1 Type
-
- When an entity-body is included with a message, the data type of that
- body is determined via the header fields Content-Type and Content-
- Encoding. These define a two-layer, ordered encoding model:
-
- entity-body := Content-Encoding( Content-Type( data ) )
-
- Content-Type specifies the media type of the underlying data.
- Content-Encoding may be used to indicate any additional content
- codings applied to the data, usually for the purpose of data
- compression, that are a property of the requested resource. There is
- no default encoding.
-
- Any HTTP/1.1 message containing an entity-body SHOULD include a
- Content-Type header field defining the media type of that body. If
- and only if the media type is not given by a Content-Type field, the
- recipient MAY attempt to guess the media type via inspection of its
- content and/or the name extension(s) of the URI used to identify the
- resource. If the media type remains unknown, the recipient SHOULD
- treat it as type "application/octet-stream".
-
-7.2.2 Entity Length
-
- The entity-length of a message is the length of the message-body
- before any transfer-codings have been applied. Section 4.4 defines
- how the transfer-length of a message-body is determined.
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 43]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-8 Connections
-
-8.1 Persistent Connections
-
-8.1.1 Purpose
-
- Prior to persistent connections, a separate TCP connection was
- established to fetch each URL, increasing the load on HTTP servers
- and causing congestion on the Internet. The use of inline images and
- other associated data often require a client to make multiple
- requests of the same server in a short amount of time. Analysis of
- these performance problems and results from a prototype
- implementation are available [26] [30]. Implementation experience and
- measurements of actual HTTP/1.1 (RFC 2068) implementations show good
- results [39]. Alternatives have also been explored, for example,
- T/TCP [27].
-
- Persistent HTTP connections have a number of advantages:
-
- - By opening and closing fewer TCP connections, CPU time is saved
- in routers and hosts (clients, servers, proxies, gateways,
- tunnels, or caches), and memory used for TCP protocol control
- blocks can be saved in hosts.
-
- - HTTP requests and responses can be pipelined on a connection.
- Pipelining allows a client to make multiple requests without
- waiting for each response, allowing a single TCP connection to
- be used much more efficiently, with much lower elapsed time.
-
- - Network congestion is reduced by reducing the number of packets
- caused by TCP opens, and by allowing TCP sufficient time to
- determine the congestion state of the network.
-
- - Latency on subsequent requests is reduced since there is no time
- spent in TCP's connection opening handshake.
-
- - HTTP can evolve more gracefully, since errors can be reported
- without the penalty of closing the TCP connection. Clients using
- future versions of HTTP might optimistically try a new feature,
- but if communicating with an older server, retry with old
- semantics after an error is reported.
-
- HTTP implementations SHOULD implement persistent connections.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 44]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-8.1.2 Overall Operation
-
- A significant difference between HTTP/1.1 and earlier versions of
- HTTP is that persistent connections are the default behavior of any
- HTTP connection. That is, unless otherwise indicated, the client
- SHOULD assume that the server will maintain a persistent connection,
- even after error responses from the server.
-
- Persistent connections provide a mechanism by which a client and a
- server can signal the close of a TCP connection. This signaling takes
- place using the Connection header field (section 14.10). Once a close
- has been signaled, the client MUST NOT send any more requests on that
- connection.
-
-8.1.2.1 Negotiation
-
- An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
- maintain a persistent connection unless a Connection header including
- the connection-token "close" was sent in the request. If the server
- chooses to close the connection immediately after sending the
- response, it SHOULD send a Connection header including the
- connection-token close.
-
- An HTTP/1.1 client MAY expect a connection to remain open, but would
- decide to keep it open based on whether the response from a server
- contains a Connection header with the connection-token close. In case
- the client does not want to maintain a connection for more than that
- request, it SHOULD send a Connection header including the
- connection-token close.
-
- If either the client or the server sends the close token in the
- Connection header, that request becomes the last one for the
- connection.
-
- Clients and servers SHOULD NOT assume that a persistent connection is
- maintained for HTTP versions less than 1.1 unless it is explicitly
- signaled. See section 19.6.2 for more information on backward
- compatibility with HTTP/1.0 clients.
-
- In order to remain persistent, all messages on the connection MUST
- have a self-defined message length (i.e., one not defined by closure
- of the connection), as described in section 4.4.
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 45]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-8.1.2.2 Pipelining
-
- A client that supports persistent connections MAY "pipeline" its
- requests (i.e., send multiple requests without waiting for each
- response). A server MUST send its responses to those requests in the
- same order that the requests were received.
-
- Clients which assume persistent connections and pipeline immediately
- after connection establishment SHOULD be prepared to retry their
- connection if the first pipelined attempt fails. If a client does
- such a retry, it MUST NOT pipeline before it knows the connection is
- persistent. Clients MUST also be prepared to resend their requests if
- the server closes the connection before sending all of the
- corresponding responses.
-
- Clients SHOULD NOT pipeline requests using non-idempotent methods or
- non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
- premature termination of the transport connection could lead to
- indeterminate results. A client wishing to send a non-idempotent
- request SHOULD wait to send that request until it has received the
- response status for the previous request.
-
-8.1.3 Proxy Servers
-
- It is especially important that proxies correctly implement the
- properties of the Connection header field as specified in section
- 14.10.
-
- The proxy server MUST signal persistent connections separately with
- its clients and the origin servers (or other proxy servers) that it
- connects to. Each persistent connection applies to only one transport
- link.
-
- A proxy server MUST NOT establish a HTTP/1.1 persistent connection
- with an HTTP/1.0 client (but see RFC 2068 [33] for information and
- discussion of the problems with the Keep-Alive header implemented by
- many HTTP/1.0 clients).
-
-8.1.4 Practical Considerations
-
- Servers will usually have some time-out value beyond which they will
- no longer maintain an inactive connection. Proxy servers might make
- this a higher value since it is likely that the client will be making
- more connections through the same server. The use of persistent
- connections places no requirements on the length (or existence) of
- this time-out for either the client or the server.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 46]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- When a client or server wishes to time-out it SHOULD issue a graceful
- close on the transport connection. Clients and servers SHOULD both
- constantly watch for the other side of the transport close, and
- respond to it as appropriate. If a client or server does not detect
- the other side's close promptly it could cause unnecessary resource
- drain on the network.
-
- A client, server, or proxy MAY close the transport connection at any
- time. For example, a client might have started to send a new request
- at the same time that the server has decided to close the "idle"
- connection. From the server's point of view, the connection is being
- closed while it was idle, but from the client's point of view, a
- request is in progress.
-
- This means that clients, servers, and proxies MUST be able to recover
- from asynchronous close events. Client software SHOULD reopen the
- transport connection and retransmit the aborted sequence of requests
- without user interaction so long as the request sequence is
- idempotent (see section 9.1.2). Non-idempotent methods or sequences
- MUST NOT be automatically retried, although user agents MAY offer a
- human operator the choice of retrying the request(s). Confirmation by
- user-agent software with semantic understanding of the application
- MAY substitute for user confirmation. The automatic retry SHOULD NOT
- be repeated if the second sequence of requests fails.
-
- Servers SHOULD always respond to at least one request per connection,
- if at all possible. Servers SHOULD NOT close a connection in the
- middle of transmitting a response, unless a network or client failure
- is suspected.
-
- Clients that use persistent connections SHOULD limit the number of
- simultaneous connections that they maintain to a given server. A
- single-user client SHOULD NOT maintain more than 2 connections with
- any server or proxy. A proxy SHOULD use up to 2*N connections to
- another server or proxy, where N is the number of simultaneously
- active users. These guidelines are intended to improve HTTP response
- times and avoid congestion.
-
-8.2 Message Transmission Requirements
-
-8.2.1 Persistent Connections and Flow Control
-
- HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
- flow control mechanisms to resolve temporary overloads, rather than
- terminating connections with the expectation that clients will retry.
- The latter technique can exacerbate network congestion.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 47]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-8.2.2 Monitoring Connections for Error Status Messages
-
- An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
- the network connection for an error status while it is transmitting
- the request. If the client sees an error status, it SHOULD
- immediately cease transmitting the body. If the body is being sent
- using a "chunked" encoding (section 3.6), a zero length chunk and
- empty trailer MAY be used to prematurely mark the end of the message.
- If the body was preceded by a Content-Length header, the client MUST
- close the connection.
-
-8.2.3 Use of the 100 (Continue) Status
-
- The purpose of the 100 (Continue) status (see section 10.1.1) is to
- allow a client that is sending a request message with a request body
- to determine if the origin server is willing to accept the request
- (based on the request headers) before the client sends the request
- body. In some cases, it might either be inappropriate or highly
- inefficient for the client to send the body if the server will reject
- the message without looking at the body.
-
- Requirements for HTTP/1.1 clients:
-
- - If a client will wait for a 100 (Continue) response before
- sending the request body, it MUST send an Expect request-header
- field (section 14.20) with the "100-continue" expectation.
-
- - A client MUST NOT send an Expect request-header field (section
- 14.20) with the "100-continue" expectation if it does not intend
- to send a request body.
-
- Because of the presence of older implementations, the protocol allows
- ambiguous situations in which a client may send "Expect: 100-
- continue" without receiving either a 417 (Expectation Failed) status
- or a 100 (Continue) status. Therefore, when a client sends this
- header field to an origin server (possibly via a proxy) from which it
- has never seen a 100 (Continue) status, the client SHOULD NOT wait
- for an indefinite period before sending the request body.
-
- Requirements for HTTP/1.1 origin servers:
-
- - Upon receiving a request which includes an Expect request-header
- field with the "100-continue" expectation, an origin server MUST
- either respond with 100 (Continue) status and continue to read
- from the input stream, or respond with a final status code. The
- origin server MUST NOT wait for the request body before sending
- the 100 (Continue) response. If it responds with a final status
- code, it MAY close the transport connection or it MAY continue
-
-
-
-Fielding, et al. Standards Track [Page 48]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- to read and discard the rest of the request. It MUST NOT
- perform the requested method if it returns a final status code.
-
- - An origin server SHOULD NOT send a 100 (Continue) response if
- the request message does not include an Expect request-header
- field with the "100-continue" expectation, and MUST NOT send a
- 100 (Continue) response if such a request comes from an HTTP/1.0
- (or earlier) client. There is an exception to this rule: for
- compatibility with RFC 2068, a server MAY send a 100 (Continue)
- status in response to an HTTP/1.1 PUT or POST request that does
- not include an Expect request-header field with the "100-
- continue" expectation. This exception, the purpose of which is
- to minimize any client processing delays associated with an
- undeclared wait for 100 (Continue) status, applies only to
- HTTP/1.1 requests, and not to requests with any other HTTP-
- version value.
-
- - An origin server MAY omit a 100 (Continue) response if it has
- already received some or all of the request body for the
- corresponding request.
-
- - An origin server that sends a 100 (Continue) response MUST
- ultimately send a final status code, once the request body is
- received and processed, unless it terminates the transport
- connection prematurely.
-
- - If an origin server receives a request that does not include an
- Expect request-header field with the "100-continue" expectation,
- the request includes a request body, and the server responds
- with a final status code before reading the entire request body
- from the transport connection, then the server SHOULD NOT close
- the transport connection until it has read the entire request,
- or until the client closes the connection. Otherwise, the client
- might not reliably receive the response message. However, this
- requirement is not be construed as preventing a server from
- defending itself against denial-of-service attacks, or from
- badly broken client implementations.
-
- Requirements for HTTP/1.1 proxies:
-
- - If a proxy receives a request that includes an Expect request-
- header field with the "100-continue" expectation, and the proxy
- either knows that the next-hop server complies with HTTP/1.1 or
- higher, or does not know the HTTP version of the next-hop
- server, it MUST forward the request, including the Expect header
- field.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 49]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - If the proxy knows that the version of the next-hop server is
- HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
- respond with a 417 (Expectation Failed) status.
-
- - Proxies SHOULD maintain a cache recording the HTTP version
- numbers received from recently-referenced next-hop servers.
-
- - A proxy MUST NOT forward a 100 (Continue) response if the
- request message was received from an HTTP/1.0 (or earlier)
- client and did not include an Expect request-header field with
- the "100-continue" expectation. This requirement overrides the
- general rule for forwarding of 1xx responses (see section 10.1).
-
-8.2.4 Client Behavior if Server Prematurely Closes Connection
-
- If an HTTP/1.1 client sends a request which includes a request body,
- but which does not include an Expect request-header field with the
- "100-continue" expectation, and if the client is not directly
- connected to an HTTP/1.1 origin server, and if the client sees the
- connection close before receiving any status from the server, the
- client SHOULD retry the request. If the client does retry this
- request, it MAY use the following "binary exponential backoff"
- algorithm to be assured of obtaining a reliable response:
-
- 1. Initiate a new connection to the server
-
- 2. Transmit the request-headers
-
- 3. Initialize a variable R to the estimated round-trip time to the
- server (e.g., based on the time it took to establish the
- connection), or to a constant value of 5 seconds if the round-
- trip time is not available.
-
- 4. Compute T = R * (2**N), where N is the number of previous
- retries of this request.
-
- 5. Wait either for an error response from the server, or for T
- seconds (whichever comes first)
-
- 6. If no error response is received, after T seconds transmit the
- body of the request.
-
- 7. If client sees that the connection is closed prematurely,
- repeat from step 1 until the request is accepted, an error
- response is received, or the user becomes impatient and
- terminates the retry process.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 50]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If at any point an error status is received, the client
-
- - SHOULD NOT continue and
-
- - SHOULD close the connection if it has not completed sending the
- request message.
-
-9 Method Definitions
-
- The set of common methods for HTTP/1.1 is defined below. Although
- this set can be expanded, additional methods cannot be assumed to
- share the same semantics for separately extended clients and servers.
-
- The Host request-header field (section 14.23) MUST accompany all
- HTTP/1.1 requests.
-
-9.1 Safe and Idempotent Methods
-
-9.1.1 Safe Methods
-
- Implementors should be aware that the software represents the user in
- their interactions over the Internet, and should be careful to allow
- the user to be aware of any actions they might take which may have an
- unexpected significance to themselves or others.
-
- In particular, the convention has been established that the GET and
- HEAD methods SHOULD NOT have the significance of taking an action
- other than retrieval. These methods ought to be considered "safe".
- This allows user agents to represent other methods, such as POST, PUT
- and DELETE, in a special way, so that the user is made aware of the
- fact that a possibly unsafe action is being requested.
-
- Naturally, it is not possible to ensure that the server does not
- generate side-effects as a result of performing a GET request; in
- fact, some dynamic resources consider that a feature. The important
- distinction here is that the user did not request the side-effects,
- so therefore cannot be held accountable for them.
-
-9.1.2 Idempotent Methods
-
- Methods can also have the property of "idempotence" in that (aside
- from error or expiration issues) the side-effects of N > 0 identical
- requests is the same as for a single request. The methods GET, HEAD,
- PUT and DELETE share this property. Also, the methods OPTIONS and
- TRACE SHOULD NOT have side effects, and so are inherently idempotent.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 51]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- However, it is possible that a sequence of several requests is non-
- idempotent, even if all of the methods executed in that sequence are
- idempotent. (A sequence is idempotent if a single execution of the
- entire sequence always yields a result that is not changed by a
- reexecution of all, or part, of that sequence.) For example, a
- sequence is non-idempotent if its result depends on a value that is
- later modified in the same sequence.
-
- A sequence that never has side effects is idempotent, by definition
- (provided that no concurrent operations are being executed on the
- same set of resources).
-
-9.2 OPTIONS
-
- The OPTIONS method represents a request for information about the
- communication options available on the request/response chain
- identified by the Request-URI. This method allows the client to
- determine the options and/or requirements associated with a resource,
- or the capabilities of a server, without implying a resource action
- or initiating a resource retrieval.
-
- Responses to this method are not cacheable.
-
- If the OPTIONS request includes an entity-body (as indicated by the
- presence of Content-Length or Transfer-Encoding), then the media type
- MUST be indicated by a Content-Type field. Although this
- specification does not define any use for such a body, future
- extensions to HTTP might use the OPTIONS body to make more detailed
- queries on the server. A server that does not support such an
- extension MAY discard the request body.
-
- If the Request-URI is an asterisk ("*"), the OPTIONS request is
- intended to apply to the server in general rather than to a specific
- resource. Since a server's communication options typically depend on
- the resource, the "*" request is only useful as a "ping" or "no-op"
- type of method; it does nothing beyond allowing the client to test
- the capabilities of the server. For example, this can be used to test
- a proxy for HTTP/1.1 compliance (or lack thereof).
-
- If the Request-URI is not an asterisk, the OPTIONS request applies
- only to the options that are available when communicating with that
- resource.
-
- A 200 response SHOULD include any header fields that indicate
- optional features implemented by the server and applicable to that
- resource (e.g., Allow), possibly including extensions not defined by
- this specification. The response body, if any, SHOULD also include
- information about the communication options. The format for such a
-
-
-
-Fielding, et al. Standards Track [Page 52]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- body is not defined by this specification, but might be defined by
- future extensions to HTTP. Content negotiation MAY be used to select
- the appropriate response format. If no response body is included, the
- response MUST include a Content-Length field with a field-value of
- "0".
-
- The Max-Forwards request-header field MAY be used to target a
- specific proxy in the request chain. When a proxy receives an OPTIONS
- request on an absoluteURI for which request forwarding is permitted,
- the proxy MUST check for a Max-Forwards field. If the Max-Forwards
- field-value is zero ("0"), the proxy MUST NOT forward the message;
- instead, the proxy SHOULD respond with its own communication options.
- If the Max-Forwards field-value is an integer greater than zero, the
- proxy MUST decrement the field-value when it forwards the request. If
- no Max-Forwards field is present in the request, then the forwarded
- request MUST NOT include a Max-Forwards field.
-
-9.3 GET
-
- The GET method means retrieve whatever information (in the form of an
- entity) is identified by the Request-URI. If the Request-URI refers
- to a data-producing process, it is the produced data which shall be
- returned as the entity in the response and not the source text of the
- process, unless that text happens to be the output of the process.
-
- The semantics of the GET method change to a "conditional GET" if the
- request message includes an If-Modified-Since, If-Unmodified-Since,
- If-Match, If-None-Match, or If-Range header field. A conditional GET
- method requests that the entity be transferred only under the
- circumstances described by the conditional header field(s). The
- conditional GET method is intended to reduce unnecessary network
- usage by allowing cached entities to be refreshed without requiring
- multiple requests or transferring data already held by the client.
-
- The semantics of the GET method change to a "partial GET" if the
- request message includes a Range header field. A partial GET requests
- that only part of the entity be transferred, as described in section
- 14.35. The partial GET method is intended to reduce unnecessary
- network usage by allowing partially-retrieved entities to be
- completed without transferring data already held by the client.
-
- The response to a GET request is cacheable if and only if it meets
- the requirements for HTTP caching described in section 13.
-
- See section 15.1.3 for security considerations when used for forms.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 53]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-9.4 HEAD
-
- The HEAD method is identical to GET except that the server MUST NOT
- return a message-body in the response. The metainformation contained
- in the HTTP headers in response to a HEAD request SHOULD be identical
- to the information sent in response to a GET request. This method can
- be used for obtaining metainformation about the entity implied by the
- request without transferring the entity-body itself. This method is
- often used for testing hypertext links for validity, accessibility,
- and recent modification.
-
- The response to a HEAD request MAY be cacheable in the sense that the
- information contained in the response MAY be used to update a
- previously cached entity from that resource. If the new field values
- indicate that the cached entity differs from the current entity (as
- would be indicated by a change in Content-Length, Content-MD5, ETag
- or Last-Modified), then the cache MUST treat the cache entry as
- stale.
-
-9.5 POST
-
- The POST method is used to request that the origin server accept the
- entity enclosed in the request as a new subordinate of the resource
- identified by the Request-URI in the Request-Line. POST is designed
- to allow a uniform method to cover the following functions:
-
- - Annotation of existing resources;
-
- - Posting a message to a bulletin board, newsgroup, mailing list,
- or similar group of articles;
-
- - Providing a block of data, such as the result of submitting a
- form, to a data-handling process;
-
- - Extending a database through an append operation.
-
- The actual function performed by the POST method is determined by the
- server and is usually dependent on the Request-URI. The posted entity
- is subordinate to that URI in the same way that a file is subordinate
- to a directory containing it, a news article is subordinate to a
- newsgroup to which it is posted, or a record is subordinate to a
- database.
-
- The action performed by the POST method might not result in a
- resource that can be identified by a URI. In this case, either 200
- (OK) or 204 (No Content) is the appropriate response status,
- depending on whether or not the response includes an entity that
- describes the result.
-
-
-
-Fielding, et al. Standards Track [Page 54]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If a resource has been created on the origin server, the response
- SHOULD be 201 (Created) and contain an entity which describes the
- status of the request and refers to the new resource, and a Location
- header (see section 14.30).
-
- Responses to this method are not cacheable, unless the response
- includes appropriate Cache-Control or Expires header fields. However,
- the 303 (See Other) response can be used to direct the user agent to
- retrieve a cacheable resource.
-
- POST requests MUST obey the message transmission requirements set out
- in section 8.2.
-
- See section 15.1.3 for security considerations.
-
-9.6 PUT
-
- The PUT method requests that the enclosed entity be stored under the
- supplied Request-URI. If the Request-URI refers to an already
- existing resource, the enclosed entity SHOULD be considered as a
- modified version of the one residing on the origin server. If the
- Request-URI does not point to an existing resource, and that URI is
- capable of being defined as a new resource by the requesting user
- agent, the origin server can create the resource with that URI. If a
- new resource is created, the origin server MUST inform the user agent
- via the 201 (Created) response. If an existing resource is modified,
- either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
- to indicate successful completion of the request. If the resource
- could not be created or modified with the Request-URI, an appropriate
- error response SHOULD be given that reflects the nature of the
- problem. The recipient of the entity MUST NOT ignore any Content-*
- (e.g. Content-Range) headers that it does not understand or implement
- and MUST return a 501 (Not Implemented) response in such cases.
-
- If the request passes through a cache and the Request-URI identifies
- one or more currently cached entities, those entries SHOULD be
- treated as stale. Responses to this method are not cacheable.
-
- The fundamental difference between the POST and PUT requests is
- reflected in the different meaning of the Request-URI. The URI in a
- POST request identifies the resource that will handle the enclosed
- entity. That resource might be a data-accepting process, a gateway to
- some other protocol, or a separate entity that accepts annotations.
- In contrast, the URI in a PUT request identifies the entity enclosed
- with the request -- the user agent knows what URI is intended and the
- server MUST NOT attempt to apply the request to some other resource.
- If the server desires that the request be applied to a different URI,
-
-
-
-
-Fielding, et al. Standards Track [Page 55]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- it MUST send a 301 (Moved Permanently) response; the user agent MAY
- then make its own decision regarding whether or not to redirect the
- request.
-
- A single resource MAY be identified by many different URIs. For
- example, an article might have a URI for identifying "the current
- version" which is separate from the URI identifying each particular
- version. In this case, a PUT request on a general URI might result in
- several other URIs being defined by the origin server.
-
- HTTP/1.1 does not define how a PUT method affects the state of an
- origin server.
-
- PUT requests MUST obey the message transmission requirements set out
- in section 8.2.
-
- Unless otherwise specified for a particular entity-header, the
- entity-headers in the PUT request SHOULD be applied to the resource
- created or modified by the PUT.
-
-9.7 DELETE
-
- The DELETE method requests that the origin server delete the resource
- identified by the Request-URI. This method MAY be overridden by human
- intervention (or other means) on the origin server. The client cannot
- be guaranteed that the operation has been carried out, even if the
- status code returned from the origin server indicates that the action
- has been completed successfully. However, the server SHOULD NOT
- indicate success unless, at the time the response is given, it
- intends to delete the resource or move it to an inaccessible
- location.
-
- A successful response SHOULD be 200 (OK) if the response includes an
- entity describing the status, 202 (Accepted) if the action has not
- yet been enacted, or 204 (No Content) if the action has been enacted
- but the response does not include an entity.
-
- If the request passes through a cache and the Request-URI identifies
- one or more currently cached entities, those entries SHOULD be
- treated as stale. Responses to this method are not cacheable.
-
-9.8 TRACE
-
- The TRACE method is used to invoke a remote, application-layer loop-
- back of the request message. The final recipient of the request
- SHOULD reflect the message received back to the client as the
- entity-body of a 200 (OK) response. The final recipient is either the
-
-
-
-
-Fielding, et al. Standards Track [Page 56]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- origin server or the first proxy or gateway to receive a Max-Forwards
- value of zero (0) in the request (see section 14.31). A TRACE request
- MUST NOT include an entity.
-
- TRACE allows the client to see what is being received at the other
- end of the request chain and use that data for testing or diagnostic
- information. The value of the Via header field (section 14.45) is of
- particular interest, since it acts as a trace of the request chain.
- Use of the Max-Forwards header field allows the client to limit the
- length of the request chain, which is useful for testing a chain of
- proxies forwarding messages in an infinite loop.
-
- If the request is valid, the response SHOULD contain the entire
- request message in the entity-body, with a Content-Type of
- "message/http". Responses to this method MUST NOT be cached.
-
-9.9 CONNECT
-
- This specification reserves the method name CONNECT for use with a
- proxy that can dynamically switch to being a tunnel (e.g. SSL
- tunneling [44]).
-
-10 Status Code Definitions
-
- Each Status-Code is described below, including a description of which
- method(s) it can follow and any metainformation required in the
- response.
-
-10.1 Informational 1xx
-
- This class of status code indicates a provisional response,
- consisting only of the Status-Line and optional headers, and is
- terminated by an empty line. There are no required headers for this
- class of status code. Since HTTP/1.0 did not define any 1xx status
- codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
- except under experimental conditions.
-
- A client MUST be prepared to accept one or more 1xx status responses
- prior to a regular response, even if the client does not expect a 100
- (Continue) status message. Unexpected 1xx status responses MAY be
- ignored by a user agent.
-
- Proxies MUST forward 1xx responses, unless the connection between the
- proxy and its client has been closed, or unless the proxy itself
- requested the generation of the 1xx response. (For example, if a
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 57]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- proxy adds a "Expect: 100-continue" field when it forwards a request,
- then it need not forward the corresponding 100 (Continue)
- response(s).)
-
-10.1.1 100 Continue
-
- The client SHOULD continue with its request. This interim response is
- used to inform the client that the initial part of the request has
- been received and has not yet been rejected by the server. The client
- SHOULD continue by sending the remainder of the request or, if the
- request has already been completed, ignore this response. The server
- MUST send a final response after the request has been completed. See
- section 8.2.3 for detailed discussion of the use and handling of this
- status code.
-
-10.1.2 101 Switching Protocols
-
- The server understands and is willing to comply with the client's
- request, via the Upgrade message header field (section 14.42), for a
- change in the application protocol being used on this connection. The
- server will switch protocols to those defined by the response's
- Upgrade header field immediately after the empty line which
- terminates the 101 response.
-
- The protocol SHOULD be switched only when it is advantageous to do
- so. For example, switching to a newer version of HTTP is advantageous
- over older versions, and switching to a real-time, synchronous
- protocol might be advantageous when delivering resources that use
- such features.
-
-10.2 Successful 2xx
-
- This class of status code indicates that the client's request was
- successfully received, understood, and accepted.
-
-10.2.1 200 OK
-
- The request has succeeded. The information returned with the response
- is dependent on the method used in the request, for example:
-
- GET an entity corresponding to the requested resource is sent in
- the response;
-
- HEAD the entity-header fields corresponding to the requested
- resource are sent in the response without any message-body;
-
- POST an entity describing or containing the result of the action;
-
-
-
-
-Fielding, et al. Standards Track [Page 58]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- TRACE an entity containing the request message as received by the
- end server.
-
-10.2.2 201 Created
-
- The request has been fulfilled and resulted in a new resource being
- created. The newly created resource can be referenced by the URI(s)
- returned in the entity of the response, with the most specific URI
- for the resource given by a Location header field. The response
- SHOULD include an entity containing a list of resource
- characteristics and location(s) from which the user or user agent can
- choose the one most appropriate. The entity format is specified by
- the media type given in the Content-Type header field. The origin
- server MUST create the resource before returning the 201 status code.
- If the action cannot be carried out immediately, the server SHOULD
- respond with 202 (Accepted) response instead.
-
- A 201 response MAY contain an ETag response header field indicating
- the current value of the entity tag for the requested variant just
- created, see section 14.19.
-
-10.2.3 202 Accepted
-
- The request has been accepted for processing, but the processing has
- not been completed. The request might or might not eventually be
- acted upon, as it might be disallowed when processing actually takes
- place. There is no facility for re-sending a status code from an
- asynchronous operation such as this.
-
- The 202 response is intentionally non-committal. Its purpose is to
- allow a server to accept a request for some other process (perhaps a
- batch-oriented process that is only run once per day) without
- requiring that the user agent's connection to the server persist
- until the process is completed. The entity returned with this
- response SHOULD include an indication of the request's current status
- and either a pointer to a status monitor or some estimate of when the
- user can expect the request to be fulfilled.
-
-10.2.4 203 Non-Authoritative Information
-
- The returned metainformation in the entity-header is not the
- definitive set as available from the origin server, but is gathered
- from a local or a third-party copy. The set presented MAY be a subset
- or superset of the original version. For example, including local
- annotation information about the resource might result in a superset
- of the metainformation known by the origin server. Use of this
- response code is not required and is only appropriate when the
- response would otherwise be 200 (OK).
-
-
-
-Fielding, et al. Standards Track [Page 59]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.2.5 204 No Content
-
- The server has fulfilled the request but does not need to return an
- entity-body, and might want to return updated metainformation. The
- response MAY include new or updated metainformation in the form of
- entity-headers, which if present SHOULD be associated with the
- requested variant.
-
- If the client is a user agent, it SHOULD NOT change its document view
- from that which caused the request to be sent. This response is
- primarily intended to allow input for actions to take place without
- causing a change to the user agent's active document view, although
- any new or updated metainformation SHOULD be applied to the document
- currently in the user agent's active view.
-
- The 204 response MUST NOT include a message-body, and thus is always
- terminated by the first empty line after the header fields.
-
-10.2.6 205 Reset Content
-
- The server has fulfilled the request and the user agent SHOULD reset
- the document view which caused the request to be sent. This response
- is primarily intended to allow input for actions to take place via
- user input, followed by a clearing of the form in which the input is
- given so that the user can easily initiate another input action. The
- response MUST NOT include an entity.
-
-10.2.7 206 Partial Content
-
- The server has fulfilled the partial GET request for the resource.
- The request MUST have included a Range header field (section 14.35)
- indicating the desired range, and MAY have included an If-Range
- header field (section 14.27) to make the request conditional.
-
- The response MUST include the following header fields:
-
- - Either a Content-Range header field (section 14.16) indicating
- the range included with this response, or a multipart/byteranges
- Content-Type including Content-Range fields for each part. If a
- Content-Length header field is present in the response, its
- value MUST match the actual number of OCTETs transmitted in the
- message-body.
-
- - Date
-
- - ETag and/or Content-Location, if the header would have been sent
- in a 200 response to the same request
-
-
-
-
-Fielding, et al. Standards Track [Page 60]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - Expires, Cache-Control, and/or Vary, if the field-value might
- differ from that sent in any previous response for the same
- variant
-
- If the 206 response is the result of an If-Range request that used a
- strong cache validator (see section 13.3.3), the response SHOULD NOT
- include other entity-headers. If the response is the result of an
- If-Range request that used a weak validator, the response MUST NOT
- include other entity-headers; this prevents inconsistencies between
- cached entity-bodies and updated headers. Otherwise, the response
- MUST include all of the entity-headers that would have been returned
- with a 200 (OK) response to the same request.
-
- A cache MUST NOT combine a 206 response with other previously cached
- content if the ETag or Last-Modified headers do not match exactly,
- see 13.5.4.
-
- A cache that does not support the Range and Content-Range headers
- MUST NOT cache 206 (Partial) responses.
-
-10.3 Redirection 3xx
-
- This class of status code indicates that further action needs to be
- taken by the user agent in order to fulfill the request. The action
- required MAY be carried out by the user agent without interaction
- with the user if and only if the method used in the second request is
- GET or HEAD. A client SHOULD detect infinite redirection loops, since
- such loops generate network traffic for each redirection.
-
- Note: previous versions of this specification recommended a
- maximum of five redirections. Content developers should be aware
- that there might be clients that implement such a fixed
- limitation.
-
-10.3.1 300 Multiple Choices
-
- The requested resource corresponds to any one of a set of
- representations, each with its own specific location, and agent-
- driven negotiation information (section 12) is being provided so that
- the user (or user agent) can select a preferred representation and
- redirect its request to that location.
-
- Unless it was a HEAD request, the response SHOULD include an entity
- containing a list of resource characteristics and location(s) from
- which the user or user agent can choose the one most appropriate. The
- entity format is specified by the media type given in the Content-
- Type header field. Depending upon the format and the capabilities of
-
-
-
-
-Fielding, et al. Standards Track [Page 61]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- the user agent, selection of the most appropriate choice MAY be
- performed automatically. However, this specification does not define
- any standard for such automatic selection.
-
- If the server has a preferred choice of representation, it SHOULD
- include the specific URI for that representation in the Location
- field; user agents MAY use the Location field value for automatic
- redirection. This response is cacheable unless indicated otherwise.
-
-10.3.2 301 Moved Permanently
-
- The requested resource has been assigned a new permanent URI and any
- future references to this resource SHOULD use one of the returned
- URIs. Clients with link editing capabilities ought to automatically
- re-link references to the Request-URI to one or more of the new
- references returned by the server, where possible. This response is
- cacheable unless indicated otherwise.
-
- The new permanent URI SHOULD be given by the Location field in the
- response. Unless the request method was HEAD, the entity of the
- response SHOULD contain a short hypertext note with a hyperlink to
- the new URI(s).
-
- If the 301 status code is received in response to a request other
- than GET or HEAD, the user agent MUST NOT automatically redirect the
- request unless it can be confirmed by the user, since this might
- change the conditions under which the request was issued.
-
- Note: When automatically redirecting a POST request after
- receiving a 301 status code, some existing HTTP/1.0 user agents
- will erroneously change it into a GET request.
-
-10.3.3 302 Found
-
- The requested resource resides temporarily under a different URI.
- Since the redirection might be altered on occasion, the client SHOULD
- continue to use the Request-URI for future requests. This response
- is only cacheable if indicated by a Cache-Control or Expires header
- field.
-
- The temporary URI SHOULD be given by the Location field in the
- response. Unless the request method was HEAD, the entity of the
- response SHOULD contain a short hypertext note with a hyperlink to
- the new URI(s).
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 62]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If the 302 status code is received in response to a request other
- than GET or HEAD, the user agent MUST NOT automatically redirect the
- request unless it can be confirmed by the user, since this might
- change the conditions under which the request was issued.
-
- Note: RFC 1945 and RFC 2068 specify that the client is not allowed
- to change the method on the redirected request. However, most
- existing user agent implementations treat 302 as if it were a 303
- response, performing a GET on the Location field-value regardless
- of the original request method. The status codes 303 and 307 have
- been added for servers that wish to make unambiguously clear which
- kind of reaction is expected of the client.
-
-10.3.4 303 See Other
-
- The response to the request can be found under a different URI and
- SHOULD be retrieved using a GET method on that resource. This method
- exists primarily to allow the output of a POST-activated script to
- redirect the user agent to a selected resource. The new URI is not a
- substitute reference for the originally requested resource. The 303
- response MUST NOT be cached, but the response to the second
- (redirected) request might be cacheable.
-
- The different URI SHOULD be given by the Location field in the
- response. Unless the request method was HEAD, the entity of the
- response SHOULD contain a short hypertext note with a hyperlink to
- the new URI(s).
-
- Note: Many pre-HTTP/1.1 user agents do not understand the 303
- status. When interoperability with such clients is a concern, the
- 302 status code may be used instead, since most user agents react
- to a 302 response as described here for 303.
-
-10.3.5 304 Not Modified
-
- If the client has performed a conditional GET request and access is
- allowed, but the document has not been modified, the server SHOULD
- respond with this status code. The 304 response MUST NOT contain a
- message-body, and thus is always terminated by the first empty line
- after the header fields.
-
- The response MUST include the following header fields:
-
- - Date, unless its omission is required by section 14.18.1
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 63]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If a clockless origin server obeys these rules, and proxies and
- clients add their own Date to any response received without one (as
- already specified by [RFC 2068], section 14.19), caches will operate
- correctly.
-
- - ETag and/or Content-Location, if the header would have been sent
- in a 200 response to the same request
-
- - Expires, Cache-Control, and/or Vary, if the field-value might
- differ from that sent in any previous response for the same
- variant
-
- If the conditional GET used a strong cache validator (see section
- 13.3.3), the response SHOULD NOT include other entity-headers.
- Otherwise (i.e., the conditional GET used a weak validator), the
- response MUST NOT include other entity-headers; this prevents
- inconsistencies between cached entity-bodies and updated headers.
-
- If a 304 response indicates an entity not currently cached, then the
- cache MUST disregard the response and repeat the request without the
- conditional.
-
- If a cache uses a received 304 response to update a cache entry, the
- cache MUST update the entry to reflect any new field values given in
- the response.
-
-10.3.6 305 Use Proxy
-
- The requested resource MUST be accessed through the proxy given by
- the Location field. The Location field gives the URI of the proxy.
- The recipient is expected to repeat this single request via the
- proxy. 305 responses MUST only be generated by origin servers.
-
- Note: RFC 2068 was not clear that 305 was intended to redirect a
- single request, and to be generated by origin servers only. Not
- observing these limitations has significant security consequences.
-
-10.3.7 306 (Unused)
-
- The 306 status code was used in a previous version of the
- specification, is no longer used, and the code is reserved.
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 64]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.3.8 307 Temporary Redirect
-
- The requested resource resides temporarily under a different URI.
- Since the redirection MAY be altered on occasion, the client SHOULD
- continue to use the Request-URI for future requests. This response
- is only cacheable if indicated by a Cache-Control or Expires header
- field.
-
- The temporary URI SHOULD be given by the Location field in the
- response. Unless the request method was HEAD, the entity of the
- response SHOULD contain a short hypertext note with a hyperlink to
- the new URI(s) , since many pre-HTTP/1.1 user agents do not
- understand the 307 status. Therefore, the note SHOULD contain the
- information necessary for a user to repeat the original request on
- the new URI.
-
- If the 307 status code is received in response to a request other
- than GET or HEAD, the user agent MUST NOT automatically redirect the
- request unless it can be confirmed by the user, since this might
- change the conditions under which the request was issued.
-
-10.4 Client Error 4xx
-
- The 4xx class of status code is intended for cases in which the
- client seems to have erred. Except when responding to a HEAD request,
- the server SHOULD include an entity containing an explanation of the
- error situation, and whether it is a temporary or permanent
- condition. These status codes are applicable to any request method.
- User agents SHOULD display any included entity to the user.
-
- If the client is sending data, a server implementation using TCP
- SHOULD be careful to ensure that the client acknowledges receipt of
- the packet(s) containing the response, before the server closes the
- input connection. If the client continues sending data to the server
- after the close, the server's TCP stack will send a reset packet to
- the client, which may erase the client's unacknowledged input buffers
- before they can be read and interpreted by the HTTP application.
-
-10.4.1 400 Bad Request
-
- The request could not be understood by the server due to malformed
- syntax. The client SHOULD NOT repeat the request without
- modifications.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 65]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.4.2 401 Unauthorized
-
- The request requires user authentication. The response MUST include a
- WWW-Authenticate header field (section 14.47) containing a challenge
- applicable to the requested resource. The client MAY repeat the
- request with a suitable Authorization header field (section 14.8). If
- the request already included Authorization credentials, then the 401
- response indicates that authorization has been refused for those
- credentials. If the 401 response contains the same challenge as the
- prior response, and the user agent has already attempted
- authentication at least once, then the user SHOULD be presented the
- entity that was given in the response, since that entity might
- include relevant diagnostic information. HTTP access authentication
- is explained in "HTTP Authentication: Basic and Digest Access
- Authentication" [43].
-
-10.4.3 402 Payment Required
-
- This code is reserved for future use.
-
-10.4.4 403 Forbidden
-
- The server understood the request, but is refusing to fulfill it.
- Authorization will not help and the request SHOULD NOT be repeated.
- If the request method was not HEAD and the server wishes to make
- public why the request has not been fulfilled, it SHOULD describe the
- reason for the refusal in the entity. If the server does not wish to
- make this information available to the client, the status code 404
- (Not Found) can be used instead.
-
-10.4.5 404 Not Found
-
- The server has not found anything matching the Request-URI. No
- indication is given of whether the condition is temporary or
- permanent. The 410 (Gone) status code SHOULD be used if the server
- knows, through some internally configurable mechanism, that an old
- resource is permanently unavailable and has no forwarding address.
- This status code is commonly used when the server does not wish to
- reveal exactly why the request has been refused, or when no other
- response is applicable.
-
-10.4.6 405 Method Not Allowed
-
- The method specified in the Request-Line is not allowed for the
- resource identified by the Request-URI. The response MUST include an
- Allow header containing a list of valid methods for the requested
- resource.
-
-
-
-
-Fielding, et al. Standards Track [Page 66]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.4.7 406 Not Acceptable
-
- The resource identified by the request is only capable of generating
- response entities which have content characteristics not acceptable
- according to the accept headers sent in the request.
-
- Unless it was a HEAD request, the response SHOULD include an entity
- containing a list of available entity characteristics and location(s)
- from which the user or user agent can choose the one most
- appropriate. The entity format is specified by the media type given
- in the Content-Type header field. Depending upon the format and the
- capabilities of the user agent, selection of the most appropriate
- choice MAY be performed automatically. However, this specification
- does not define any standard for such automatic selection.
-
- Note: HTTP/1.1 servers are allowed to return responses which are
- not acceptable according to the accept headers sent in the
- request. In some cases, this may even be preferable to sending a
- 406 response. User agents are encouraged to inspect the headers of
- an incoming response to determine if it is acceptable.
-
- If the response could be unacceptable, a user agent SHOULD
- temporarily stop receipt of more data and query the user for a
- decision on further actions.
-
-10.4.8 407 Proxy Authentication Required
-
- This code is similar to 401 (Unauthorized), but indicates that the
- client must first authenticate itself with the proxy. The proxy MUST
- return a Proxy-Authenticate header field (section 14.33) containing a
- challenge applicable to the proxy for the requested resource. The
- client MAY repeat the request with a suitable Proxy-Authorization
- header field (section 14.34). HTTP access authentication is explained
- in "HTTP Authentication: Basic and Digest Access Authentication"
- [43].
-
-10.4.9 408 Request Timeout
-
- The client did not produce a request within the time that the server
- was prepared to wait. The client MAY repeat the request without
- modifications at any later time.
-
-10.4.10 409 Conflict
-
- The request could not be completed due to a conflict with the current
- state of the resource. This code is only allowed in situations where
- it is expected that the user might be able to resolve the conflict
- and resubmit the request. The response body SHOULD include enough
-
-
-
-Fielding, et al. Standards Track [Page 67]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- information for the user to recognize the source of the conflict.
- Ideally, the response entity would include enough information for the
- user or user agent to fix the problem; however, that might not be
- possible and is not required.
-
- Conflicts are most likely to occur in response to a PUT request. For
- example, if versioning were being used and the entity being PUT
- included changes to a resource which conflict with those made by an
- earlier (third-party) request, the server might use the 409 response
- to indicate that it can't complete the request. In this case, the
- response entity would likely contain a list of the differences
- between the two versions in a format defined by the response
- Content-Type.
-
-10.4.11 410 Gone
-
- The requested resource is no longer available at the server and no
- forwarding address is known. This condition is expected to be
- considered permanent. Clients with link editing capabilities SHOULD
- delete references to the Request-URI after user approval. If the
- server does not know, or has no facility to determine, whether or not
- the condition is permanent, the status code 404 (Not Found) SHOULD be
- used instead. This response is cacheable unless indicated otherwise.
-
- The 410 response is primarily intended to assist the task of web
- maintenance by notifying the recipient that the resource is
- intentionally unavailable and that the server owners desire that
- remote links to that resource be removed. Such an event is common for
- limited-time, promotional services and for resources belonging to
- individuals no longer working at the server's site. It is not
- necessary to mark all permanently unavailable resources as "gone" or
- to keep the mark for any length of time -- that is left to the
- discretion of the server owner.
-
-10.4.12 411 Length Required
-
- The server refuses to accept the request without a defined Content-
- Length. The client MAY repeat the request if it adds a valid
- Content-Length header field containing the length of the message-body
- in the request message.
-
-10.4.13 412 Precondition Failed
-
- The precondition given in one or more of the request-header fields
- evaluated to false when it was tested on the server. This response
- code allows the client to place preconditions on the current resource
- metainformation (header field data) and thus prevent the requested
- method from being applied to a resource other than the one intended.
-
-
-
-Fielding, et al. Standards Track [Page 68]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.4.14 413 Request Entity Too Large
-
- The server is refusing to process a request because the request
- entity is larger than the server is willing or able to process. The
- server MAY close the connection to prevent the client from continuing
- the request.
-
- If the condition is temporary, the server SHOULD include a Retry-
- After header field to indicate that it is temporary and after what
- time the client MAY try again.
-
-10.4.15 414 Request-URI Too Long
-
- The server is refusing to service the request because the Request-URI
- is longer than the server is willing to interpret. This rare
- condition is only likely to occur when a client has improperly
- converted a POST request to a GET request with long query
- information, when the client has descended into a URI "black hole" of
- redirection (e.g., a redirected URI prefix that points to a suffix of
- itself), or when the server is under attack by a client attempting to
- exploit security holes present in some servers using fixed-length
- buffers for reading or manipulating the Request-URI.
-
-10.4.16 415 Unsupported Media Type
-
- The server is refusing to service the request because the entity of
- the request is in a format not supported by the requested resource
- for the requested method.
-
-10.4.17 416 Requested Range Not Satisfiable
-
- A server SHOULD return a response with this status code if a request
- included a Range request-header field (section 14.35), and none of
- the range-specifier values in this field overlap the current extent
- of the selected resource, and the request did not include an If-Range
- request-header field. (For byte-ranges, this means that the first-
- byte-pos of all of the byte-range-spec values were greater than the
- current length of the selected resource.)
-
- When this status code is returned for a byte-range request, the
- response SHOULD include a Content-Range entity-header field
- specifying the current length of the selected resource (see section
- 14.16). This response MUST NOT use the multipart/byteranges content-
- type.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 69]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.4.18 417 Expectation Failed
-
- The expectation given in an Expect request-header field (see section
- 14.20) could not be met by this server, or, if the server is a proxy,
- the server has unambiguous evidence that the request could not be met
- by the next-hop server.
-
-10.5 Server Error 5xx
-
- Response status codes beginning with the digit "5" indicate cases in
- which the server is aware that it has erred or is incapable of
- performing the request. Except when responding to a HEAD request, the
- server SHOULD include an entity containing an explanation of the
- error situation, and whether it is a temporary or permanent
- condition. User agents SHOULD display any included entity to the
- user. These response codes are applicable to any request method.
-
-10.5.1 500 Internal Server Error
-
- The server encountered an unexpected condition which prevented it
- from fulfilling the request.
-
-10.5.2 501 Not Implemented
-
- The server does not support the functionality required to fulfill the
- request. This is the appropriate response when the server does not
- recognize the request method and is not capable of supporting it for
- any resource.
-
-10.5.3 502 Bad Gateway
-
- The server, while acting as a gateway or proxy, received an invalid
- response from the upstream server it accessed in attempting to
- fulfill the request.
-
-10.5.4 503 Service Unavailable
-
- The server is currently unable to handle the request due to a
- temporary overloading or maintenance of the server. The implication
- is that this is a temporary condition which will be alleviated after
- some delay. If known, the length of the delay MAY be indicated in a
- Retry-After header. If no Retry-After is given, the client SHOULD
- handle the response as it would for a 500 response.
-
- Note: The existence of the 503 status code does not imply that a
- server must use it when becoming overloaded. Some servers may wish
- to simply refuse the connection.
-
-
-
-
-Fielding, et al. Standards Track [Page 70]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-10.5.5 504 Gateway Timeout
-
- The server, while acting as a gateway or proxy, did not receive a
- timely response from the upstream server specified by the URI (e.g.
- HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
- to access in attempting to complete the request.
-
- Note: Note to implementors: some deployed proxies are known to
- return 400 or 500 when DNS lookups time out.
-
-10.5.6 505 HTTP Version Not Supported
-
- The server does not support, or refuses to support, the HTTP protocol
- version that was used in the request message. The server is
- indicating that it is unable or unwilling to complete the request
- using the same major version as the client, as described in section
- 3.1, other than with this error message. The response SHOULD contain
- an entity describing why that version is not supported and what other
- protocols are supported by that server.
-
-11 Access Authentication
-
- HTTP provides several OPTIONAL challenge-response authentication
- mechanisms which can be used by a server to challenge a client
- request and by a client to provide authentication information. The
- general framework for access authentication, and the specification of
- "basic" and "digest" authentication, are specified in "HTTP
- Authentication: Basic and Digest Access Authentication" [43]. This
- specification adopts the definitions of "challenge" and "credentials"
- from that specification.
-
-12 Content Negotiation
-
- Most HTTP responses include an entity which contains information for
- interpretation by a human user. Naturally, it is desirable to supply
- the user with the "best available" entity corresponding to the
- request. Unfortunately for servers and caches, not all users have the
- same preferences for what is "best," and not all user agents are
- equally capable of rendering all entity types. For that reason, HTTP
- has provisions for several mechanisms for "content negotiation" --
- the process of selecting the best representation for a given response
- when there are multiple representations available.
-
- Note: This is not called "format negotiation" because the
- alternate representations may be of the same media type, but use
- different capabilities of that type, be in different languages,
- etc.
-
-
-
-
-Fielding, et al. Standards Track [Page 71]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Any response containing an entity-body MAY be subject to negotiation,
- including error responses.
-
- There are two kinds of content negotiation which are possible in
- HTTP: server-driven and agent-driven negotiation. These two kinds of
- negotiation are orthogonal and thus may be used separately or in
- combination. One method of combination, referred to as transparent
- negotiation, occurs when a cache uses the agent-driven negotiation
- information provided by the origin server in order to provide
- server-driven negotiation for subsequent requests.
-
-12.1 Server-driven Negotiation
-
- If the selection of the best representation for a response is made by
- an algorithm located at the server, it is called server-driven
- negotiation. Selection is based on the available representations of
- the response (the dimensions over which it can vary; e.g. language,
- content-coding, etc.) and the contents of particular header fields in
- the request message or on other information pertaining to the request
- (such as the network address of the client).
-
- Server-driven negotiation is advantageous when the algorithm for
- selecting from among the available representations is difficult to
- describe to the user agent, or when the server desires to send its
- "best guess" to the client along with the first response (hoping to
- avoid the round-trip delay of a subsequent request if the "best
- guess" is good enough for the user). In order to improve the server's
- guess, the user agent MAY include request header fields (Accept,
- Accept-Language, Accept-Encoding, etc.) which describe its
- preferences for such a response.
-
- Server-driven negotiation has disadvantages:
-
- 1. It is impossible for the server to accurately determine what
- might be "best" for any given user, since that would require
- complete knowledge of both the capabilities of the user agent
- and the intended use for the response (e.g., does the user want
- to view it on screen or print it on paper?).
-
- 2. Having the user agent describe its capabilities in every
- request can be both very inefficient (given that only a small
- percentage of responses have multiple representations) and a
- potential violation of the user's privacy.
-
- 3. It complicates the implementation of an origin server and the
- algorithms for generating responses to a request.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 72]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 4. It may limit a public cache's ability to use the same response
- for multiple user's requests.
-
- HTTP/1.1 includes the following request-header fields for enabling
- server-driven negotiation through description of user agent
- capabilities and user preferences: Accept (section 14.1), Accept-
- Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
- Language (section 14.4), and User-Agent (section 14.43). However, an
- origin server is not limited to these dimensions and MAY vary the
- response based on any aspect of the request, including information
- outside the request-header fields or within extension header fields
- not defined by this specification.
-
- The Vary header field can be used to express the parameters the
- server uses to select a representation that is subject to server-
- driven negotiation. See section 13.6 for use of the Vary header field
- by caches and section 14.44 for use of the Vary header field by
- servers.
-
-12.2 Agent-driven Negotiation
-
- With agent-driven negotiation, selection of the best representation
- for a response is performed by the user agent after receiving an
- initial response from the origin server. Selection is based on a list
- of the available representations of the response included within the
- header fields or entity-body of the initial response, with each
- representation identified by its own URI. Selection from among the
- representations may be performed automatically (if the user agent is
- capable of doing so) or manually by the user selecting from a
- generated (possibly hypertext) menu.
-
- Agent-driven negotiation is advantageous when the response would vary
- over commonly-used dimensions (such as type, language, or encoding),
- when the origin server is unable to determine a user agent's
- capabilities from examining the request, and generally when public
- caches are used to distribute server load and reduce network usage.
-
- Agent-driven negotiation suffers from the disadvantage of needing a
- second request to obtain the best alternate representation. This
- second request is only efficient when caching is used. In addition,
- this specification does not define any mechanism for supporting
- automatic selection, though it also does not prevent any such
- mechanism from being developed as an extension and used within
- HTTP/1.1.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 73]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
- status codes for enabling agent-driven negotiation when the server is
- unwilling or unable to provide a varying response using server-driven
- negotiation.
-
-12.3 Transparent Negotiation
-
- Transparent negotiation is a combination of both server-driven and
- agent-driven negotiation. When a cache is supplied with a form of the
- list of available representations of the response (as in agent-driven
- negotiation) and the dimensions of variance are completely understood
- by the cache, then the cache becomes capable of performing server-
- driven negotiation on behalf of the origin server for subsequent
- requests on that resource.
-
- Transparent negotiation has the advantage of distributing the
- negotiation work that would otherwise be required of the origin
- server and also removing the second request delay of agent-driven
- negotiation when the cache is able to correctly guess the right
- response.
-
- This specification does not define any mechanism for transparent
- negotiation, though it also does not prevent any such mechanism from
- being developed as an extension that could be used within HTTP/1.1.
-
-13 Caching in HTTP
-
- HTTP is typically used for distributed information systems, where
- performance can be improved by the use of response caches. The
- HTTP/1.1 protocol includes a number of elements intended to make
- caching work as well as possible. Because these elements are
- inextricable from other aspects of the protocol, and because they
- interact with each other, it is useful to describe the basic caching
- design of HTTP separately from the detailed descriptions of methods,
- headers, response codes, etc.
-
- Caching would be useless if it did not significantly improve
- performance. The goal of caching in HTTP/1.1 is to eliminate the need
- to send requests in many cases, and to eliminate the need to send
- full responses in many other cases. The former reduces the number of
- network round-trips required for many operations; we use an
- "expiration" mechanism for this purpose (see section 13.2). The
- latter reduces network bandwidth requirements; we use a "validation"
- mechanism for this purpose (see section 13.3).
-
- Requirements for performance, availability, and disconnected
- operation require us to be able to relax the goal of semantic
- transparency. The HTTP/1.1 protocol allows origin servers, caches,
-
-
-
-Fielding, et al. Standards Track [Page 74]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- and clients to explicitly reduce transparency when necessary.
- However, because non-transparent operation may confuse non-expert
- users, and might be incompatible with certain server applications
- (such as those for ordering merchandise), the protocol requires that
- transparency be relaxed
-
- - only by an explicit protocol-level request when relaxed by
- client or origin server
-
- - only with an explicit warning to the end user when relaxed by
- cache or client
-
- Therefore, the HTTP/1.1 protocol provides these important elements:
-
- 1. Protocol features that provide full semantic transparency when
- this is required by all parties.
-
- 2. Protocol features that allow an origin server or user agent to
- explicitly request and control non-transparent operation.
-
- 3. Protocol features that allow a cache to attach warnings to
- responses that do not preserve the requested approximation of
- semantic transparency.
-
- A basic principle is that it must be possible for the clients to
- detect any potential relaxation of semantic transparency.
-
- Note: The server, cache, or client implementor might be faced with
- design decisions not explicitly discussed in this specification.
- If a decision might affect semantic transparency, the implementor
- ought to err on the side of maintaining transparency unless a
- careful and complete analysis shows significant benefits in
- breaking transparency.
-
-13.1.1 Cache Correctness
-
- A correct cache MUST respond to a request with the most up-to-date
- response held by the cache that is appropriate to the request (see
- sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
- conditions:
-
- 1. It has been checked for equivalence with what the origin server
- would have returned by revalidating the response with the
- origin server (section 13.3);
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 75]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 2. It is "fresh enough" (see section 13.2). In the default case,
- this means it meets the least restrictive freshness requirement
- of the client, origin server, and cache (see section 14.9); if
- the origin server so specifies, it is the freshness requirement
- of the origin server alone.
-
- If a stored response is not "fresh enough" by the most
- restrictive freshness requirement of both the client and the
- origin server, in carefully considered circumstances the cache
- MAY still return the response with the appropriate Warning
- header (see section 13.1.5 and 14.46), unless such a response
- is prohibited (e.g., by a "no-store" cache-directive, or by a
- "no-cache" cache-request-directive; see section 14.9).
-
- 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
- or error (4xx or 5xx) response message.
-
- If the cache can not communicate with the origin server, then a
- correct cache SHOULD respond as above if the response can be
- correctly served from the cache; if not it MUST return an error or
- warning indicating that there was a communication failure.
-
- If a cache receives a response (either an entire response, or a 304
- (Not Modified) response) that it would normally forward to the
- requesting client, and the received response is no longer fresh, the
- cache SHOULD forward it to the requesting client without adding a new
- Warning (but without removing any existing Warning headers). A cache
- SHOULD NOT attempt to revalidate a response simply because that
- response became stale in transit; this might lead to an infinite
- loop. A user agent that receives a stale response without a Warning
- MAY display a warning indication to the user.
-
-13.1.2 Warnings
-
- Whenever a cache returns a response that is neither first-hand nor
- "fresh enough" (in the sense of condition 2 in section 13.1.1), it
- MUST attach a warning to that effect, using a Warning general-header.
- The Warning header and the currently defined warnings are described
- in section 14.46. The warning allows clients to take appropriate
- action.
-
- Warnings MAY be used for other purposes, both cache-related and
- otherwise. The use of a warning, rather than an error status code,
- distinguish these responses from true failures.
-
- Warnings are assigned three digit warn-codes. The first digit
- indicates whether the Warning MUST or MUST NOT be deleted from a
- stored cache entry after a successful revalidation:
-
-
-
-Fielding, et al. Standards Track [Page 76]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 1xx Warnings that describe the freshness or revalidation status of
- the response, and so MUST be deleted after a successful
- revalidation. 1XX warn-codes MAY be generated by a cache only when
- validating a cached entry. It MUST NOT be generated by clients.
-
- 2xx Warnings that describe some aspect of the entity body or entity
- headers that is not rectified by a revalidation (for example, a
- lossy compression of the entity bodies) and which MUST NOT be
- deleted after a successful revalidation.
-
- See section 14.46 for the definitions of the codes themselves.
-
- HTTP/1.0 caches will cache all Warnings in responses, without
- deleting the ones in the first category. Warnings in responses that
- are passed to HTTP/1.0 caches carry an extra warning-date field,
- which prevents a future HTTP/1.1 recipient from believing an
- erroneously cached Warning.
-
- Warnings also carry a warning text. The text MAY be in any
- appropriate natural language (perhaps based on the client's Accept
- headers), and include an OPTIONAL indication of what character set is
- used.
-
- Multiple warnings MAY be attached to a response (either by the origin
- server or by a cache), including multiple warnings with the same code
- number. For example, a server might provide the same warning with
- texts in both English and Basque.
-
- When multiple warnings are attached to a response, it might not be
- practical or reasonable to display all of them to the user. This
- version of HTTP does not specify strict priority rules for deciding
- which warnings to display and in what order, but does suggest some
- heuristics.
-
-13.1.3 Cache-control Mechanisms
-
- The basic cache mechanisms in HTTP/1.1 (server-specified expiration
- times and validators) are implicit directives to caches. In some
- cases, a server or client might need to provide explicit directives
- to the HTTP caches. We use the Cache-Control header for this purpose.
-
- The Cache-Control header allows a client or server to transmit a
- variety of directives in either requests or responses. These
- directives typically override the default caching algorithms. As a
- general rule, if there is any apparent conflict between header
- values, the most restrictive interpretation is applied (that is, the
- one that is most likely to preserve semantic transparency). However,
-
-
-
-
-Fielding, et al. Standards Track [Page 77]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- in some cases, cache-control directives are explicitly specified as
- weakening the approximation of semantic transparency (for example,
- "max-stale" or "public").
-
- The cache-control directives are described in detail in section 14.9.
-
-13.1.4 Explicit User Agent Warnings
-
- Many user agents make it possible for users to override the basic
- caching mechanisms. For example, the user agent might allow the user
- to specify that cached entities (even explicitly stale ones) are
- never validated. Or the user agent might habitually add "Cache-
- Control: max-stale=3600" to every request. The user agent SHOULD NOT
- default to either non-transparent behavior, or behavior that results
- in abnormally ineffective caching, but MAY be explicitly configured
- to do so by an explicit action of the user.
-
- If the user has overridden the basic caching mechanisms, the user
- agent SHOULD explicitly indicate to the user whenever this results in
- the display of information that might not meet the server's
- transparency requirements (in particular, if the displayed entity is
- known to be stale). Since the protocol normally allows the user agent
- to determine if responses are stale or not, this indication need only
- be displayed when this actually happens. The indication need not be a
- dialog box; it could be an icon (for example, a picture of a rotting
- fish) or some other indicator.
-
- If the user has overridden the caching mechanisms in a way that would
- abnormally reduce the effectiveness of caches, the user agent SHOULD
- continually indicate this state to the user (for example, by a
- display of a picture of currency in flames) so that the user does not
- inadvertently consume excess resources or suffer from excessive
- latency.
-
-13.1.5 Exceptions to the Rules and Warnings
-
- In some cases, the operator of a cache MAY choose to configure it to
- return stale responses even when not requested by clients. This
- decision ought not be made lightly, but may be necessary for reasons
- of availability or performance, especially when the cache is poorly
- connected to the origin server. Whenever a cache returns a stale
- response, it MUST mark it as such (using a Warning header) enabling
- the client software to alert the user that there might be a potential
- problem.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 78]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- It also allows the user agent to take steps to obtain a first-hand or
- fresh response. For this reason, a cache SHOULD NOT return a stale
- response if the client explicitly requests a first-hand or fresh one,
- unless it is impossible to comply for technical or policy reasons.
-
-13.1.6 Client-controlled Behavior
-
- While the origin server (and to a lesser extent, intermediate caches,
- by their contribution to the age of a response) are the primary
- source of expiration information, in some cases the client might need
- to control a cache's decision about whether to return a cached
- response without validating it. Clients do this using several
- directives of the Cache-Control header.
-
- A client's request MAY specify the maximum age it is willing to
- accept of an unvalidated response; specifying a value of zero forces
- the cache(s) to revalidate all responses. A client MAY also specify
- the minimum time remaining before a response expires. Both of these
- options increase constraints on the behavior of caches, and so cannot
- further relax the cache's approximation of semantic transparency.
-
- A client MAY also specify that it will accept stale responses, up to
- some maximum amount of staleness. This loosens the constraints on the
- caches, and so might violate the origin server's specified
- constraints on semantic transparency, but might be necessary to
- support disconnected operation, or high availability in the face of
- poor connectivity.
-
-13.2 Expiration Model
-
-13.2.1 Server-Specified Expiration
-
- HTTP caching works best when caches can entirely avoid making
- requests to the origin server. The primary mechanism for avoiding
- requests is for an origin server to provide an explicit expiration
- time in the future, indicating that a response MAY be used to satisfy
- subsequent requests. In other words, a cache can return a fresh
- response without first contacting the server.
-
- Our expectation is that servers will assign future explicit
- expiration times to responses in the belief that the entity is not
- likely to change, in a semantically significant way, before the
- expiration time is reached. This normally preserves semantic
- transparency, as long as the server's expiration times are carefully
- chosen.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 79]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The expiration mechanism applies only to responses taken from a cache
- and not to first-hand responses forwarded immediately to the
- requesting client.
-
- If an origin server wishes to force a semantically transparent cache
- to validate every request, it MAY assign an explicit expiration time
- in the past. This means that the response is always stale, and so the
- cache SHOULD validate it before using it for subsequent requests. See
- section 14.9.4 for a more restrictive way to force revalidation.
-
- If an origin server wishes to force any HTTP/1.1 cache, no matter how
- it is configured, to validate every request, it SHOULD use the "must-
- revalidate" cache-control directive (see section 14.9).
-
- Servers specify explicit expiration times using either the Expires
- header, or the max-age directive of the Cache-Control header.
-
- An expiration time cannot be used to force a user agent to refresh
- its display or reload a resource; its semantics apply only to caching
- mechanisms, and such mechanisms need only check a resource's
- expiration status when a new request for that resource is initiated.
- See section 13.13 for an explanation of the difference between caches
- and history mechanisms.
-
-13.2.2 Heuristic Expiration
-
- Since origin servers do not always provide explicit expiration times,
- HTTP caches typically assign heuristic expiration times, employing
- algorithms that use other header values (such as the Last-Modified
- time) to estimate a plausible expiration time. The HTTP/1.1
- specification does not provide specific algorithms, but does impose
- worst-case constraints on their results. Since heuristic expiration
- times might compromise semantic transparency, they ought to used
- cautiously, and we encourage origin servers to provide explicit
- expiration times as much as possible.
-
-13.2.3 Age Calculations
-
- In order to know if a cached entry is fresh, a cache needs to know if
- its age exceeds its freshness lifetime. We discuss how to calculate
- the latter in section 13.2.4; this section describes how to calculate
- the age of a response or cache entry.
-
- In this discussion, we use the term "now" to mean "the current value
- of the clock at the host performing the calculation." Hosts that use
- HTTP, but especially hosts running origin servers and caches, SHOULD
- use NTP [28] or some similar protocol to synchronize their clocks to
- a globally accurate time standard.
-
-
-
-Fielding, et al. Standards Track [Page 80]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- HTTP/1.1 requires origin servers to send a Date header, if possible,
- with every response, giving the time at which the response was
- generated (see section 14.18). We use the term "date_value" to denote
- the value of the Date header, in a form appropriate for arithmetic
- operations.
-
- HTTP/1.1 uses the Age response-header to convey the estimated age of
- the response message when obtained from a cache. The Age field value
- is the cache's estimate of the amount of time since the response was
- generated or revalidated by the origin server.
-
- In essence, the Age value is the sum of the time that the response
- has been resident in each of the caches along the path from the
- origin server, plus the amount of time it has been in transit along
- network paths.
-
- We use the term "age_value" to denote the value of the Age header, in
- a form appropriate for arithmetic operations.
-
- A response's age can be calculated in two entirely independent ways:
-
- 1. now minus date_value, if the local clock is reasonably well
- synchronized to the origin server's clock. If the result is
- negative, the result is replaced by zero.
-
- 2. age_value, if all of the caches along the response path
- implement HTTP/1.1.
-
- Given that we have two independent ways to compute the age of a
- response when it is received, we can combine these as
-
- corrected_received_age = max(now - date_value, age_value)
-
- and as long as we have either nearly synchronized clocks or all-
- HTTP/1.1 paths, one gets a reliable (conservative) result.
-
- Because of network-imposed delays, some significant interval might
- pass between the time that a server generates a response and the time
- it is received at the next outbound cache or client. If uncorrected,
- this delay could result in improperly low ages.
-
- Because the request that resulted in the returned Age value must have
- been initiated prior to that Age value's generation, we can correct
- for delays imposed by the network by recording the time at which the
- request was initiated. Then, when an Age value is received, it MUST
- be interpreted relative to the time the request was initiated, not
-
-
-
-
-
-Fielding, et al. Standards Track [Page 81]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- the time that the response was received. This algorithm results in
- conservative behavior no matter how much delay is experienced. So, we
- compute:
-
- corrected_initial_age = corrected_received_age
- + (now - request_time)
-
- where "request_time" is the time (according to the local clock) when
- the request that elicited this response was sent.
-
- Summary of age calculation algorithm, when a cache receives a
- response:
-
- /*
- * age_value
- * is the value of Age: header received by the cache with
- * this response.
- * date_value
- * is the value of the origin server's Date: header
- * request_time
- * is the (local) time when the cache made the request
- * that resulted in this cached response
- * response_time
- * is the (local) time when the cache received the
- * response
- * now
- * is the current (local) time
- */
-
- apparent_age = max(0, response_time - date_value);
- corrected_received_age = max(apparent_age, age_value);
- response_delay = response_time - request_time;
- corrected_initial_age = corrected_received_age + response_delay;
- resident_time = now - response_time;
- current_age = corrected_initial_age + resident_time;
-
- The current_age of a cache entry is calculated by adding the amount
- of time (in seconds) since the cache entry was last validated by the
- origin server to the corrected_initial_age. When a response is
- generated from a cache entry, the cache MUST include a single Age
- header field in the response with a value equal to the cache entry's
- current_age.
-
- The presence of an Age header field in a response implies that a
- response is not first-hand. However, the converse is not true, since
- the lack of an Age header field in a response does not imply that the
-
-
-
-
-
-Fielding, et al. Standards Track [Page 82]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- response is first-hand unless all caches along the request path are
- compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
- the Age header field).
-
-13.2.4 Expiration Calculations
-
- In order to decide whether a response is fresh or stale, we need to
- compare its freshness lifetime to its age. The age is calculated as
- described in section 13.2.3; this section describes how to calculate
- the freshness lifetime, and to determine if a response has expired.
- In the discussion below, the values can be represented in any form
- appropriate for arithmetic operations.
-
- We use the term "expires_value" to denote the value of the Expires
- header. We use the term "max_age_value" to denote an appropriate
- value of the number of seconds carried by the "max-age" directive of
- the Cache-Control header in a response (see section 14.9.3).
-
- The max-age directive takes priority over Expires, so if max-age is
- present in a response, the calculation is simply:
-
- freshness_lifetime = max_age_value
-
- Otherwise, if Expires is present in the response, the calculation is:
-
- freshness_lifetime = expires_value - date_value
-
- Note that neither of these calculations is vulnerable to clock skew,
- since all of the information comes from the origin server.
-
- If none of Expires, Cache-Control: max-age, or Cache-Control: s-
- maxage (see section 14.9.3) appears in the response, and the response
- does not include other restrictions on caching, the cache MAY compute
- a freshness lifetime using a heuristic. The cache MUST attach Warning
- 113 to any response whose age is more than 24 hours if such warning
- has not already been added.
-
- Also, if the response does have a Last-Modified time, the heuristic
- expiration value SHOULD be no more than some fraction of the interval
- since that time. A typical setting of this fraction might be 10%.
-
- The calculation to determine if a response has expired is quite
- simple:
-
- response_is_fresh = (freshness_lifetime > current_age)
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 83]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.2.5 Disambiguating Expiration Values
-
- Because expiration values are assigned optimistically, it is possible
- for two caches to contain fresh values for the same resource that are
- different.
-
- If a client performing a retrieval receives a non-first-hand response
- for a request that was already fresh in its own cache, and the Date
- header in its existing cache entry is newer than the Date on the new
- response, then the client MAY ignore the response. If so, it MAY
- retry the request with a "Cache-Control: max-age=0" directive (see
- section 14.9), to force a check with the origin server.
-
- If a cache has two fresh responses for the same representation with
- different validators, it MUST use the one with the more recent Date
- header. This situation might arise because the cache is pooling
- responses from other caches, or because a client has asked for a
- reload or a revalidation of an apparently fresh cache entry.
-
-13.2.6 Disambiguating Multiple Responses
-
- Because a client might be receiving responses via multiple paths, so
- that some responses flow through one set of caches and other
- responses flow through a different set of caches, a client might
- receive responses in an order different from that in which the origin
- server sent them. We would like the client to use the most recently
- generated response, even if older responses are still apparently
- fresh.
-
- Neither the entity tag nor the expiration value can impose an
- ordering on responses, since it is possible that a later response
- intentionally carries an earlier expiration time. The Date values are
- ordered to a granularity of one second.
-
- When a client tries to revalidate a cache entry, and the response it
- receives contains a Date header that appears to be older than the one
- for the existing entry, then the client SHOULD repeat the request
- unconditionally, and include
-
- Cache-Control: max-age=0
-
- to force any intermediate caches to validate their copies directly
- with the origin server, or
-
- Cache-Control: no-cache
-
- to force any intermediate caches to obtain a new copy from the origin
- server.
-
-
-
-Fielding, et al. Standards Track [Page 84]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If the Date values are equal, then the client MAY use either response
- (or MAY, if it is being extremely prudent, request a new response).
- Servers MUST NOT depend on clients being able to choose
- deterministically between responses generated during the same second,
- if their expiration times overlap.
-
-13.3 Validation Model
-
- When a cache has a stale entry that it would like to use as a
- response to a client's request, it first has to check with the origin
- server (or possibly an intermediate cache with a fresh response) to
- see if its cached entry is still usable. We call this "validating"
- the cache entry. Since we do not want to have to pay the overhead of
- retransmitting the full response if the cached entry is good, and we
- do not want to pay the overhead of an extra round trip if the cached
- entry is invalid, the HTTP/1.1 protocol supports the use of
- conditional methods.
-
- The key protocol features for supporting conditional methods are
- those concerned with "cache validators." When an origin server
- generates a full response, it attaches some sort of validator to it,
- which is kept with the cache entry. When a client (user agent or
- proxy cache) makes a conditional request for a resource for which it
- has a cache entry, it includes the associated validator in the
- request.
-
- The server then checks that validator against the current validator
- for the entity, and, if they match (see section 13.3.3), it responds
- with a special status code (usually, 304 (Not Modified)) and no
- entity-body. Otherwise, it returns a full response (including
- entity-body). Thus, we avoid transmitting the full response if the
- validator matches, and we avoid an extra round trip if it does not
- match.
-
- In HTTP/1.1, a conditional request looks exactly the same as a normal
- request for the same resource, except that it carries a special
- header (which includes the validator) that implicitly turns the
- method (usually, GET) into a conditional.
-
- The protocol includes both positive and negative senses of cache-
- validating conditions. That is, it is possible to request either that
- a method be performed if and only if a validator matches or if and
- only if no validators match.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 85]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Note: a response that lacks a validator may still be cached, and
- served from cache until it expires, unless this is explicitly
- prohibited by a cache-control directive. However, a cache cannot
- do a conditional retrieval if it does not have a validator for the
- entity, which means it will not be refreshable after it expires.
-
-13.3.1 Last-Modified Dates
-
- The Last-Modified entity-header field value is often used as a cache
- validator. In simple terms, a cache entry is considered to be valid
- if the entity has not been modified since the Last-Modified value.
-
-13.3.2 Entity Tag Cache Validators
-
- The ETag response-header field value, an entity tag, provides for an
- "opaque" cache validator. This might allow more reliable validation
- in situations where it is inconvenient to store modification dates,
- where the one-second resolution of HTTP date values is not
- sufficient, or where the origin server wishes to avoid certain
- paradoxes that might arise from the use of modification dates.
-
- Entity Tags are described in section 3.11. The headers used with
- entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
-
-13.3.3 Weak and Strong Validators
-
- Since both origin servers and caches will compare two validators to
- decide if they represent the same or different entities, one normally
- would expect that if the entity (the entity-body or any entity-
- headers) changes in any way, then the associated validator would
- change as well. If this is true, then we call this validator a
- "strong validator."
-
- However, there might be cases when a server prefers to change the
- validator only on semantically significant changes, and not when
- insignificant aspects of the entity change. A validator that does not
- always change when the resource changes is a "weak validator."
-
- Entity tags are normally "strong validators," but the protocol
- provides a mechanism to tag an entity tag as "weak." One can think of
- a strong validator as one that changes whenever the bits of an entity
- changes, while a weak value changes whenever the meaning of an entity
- changes. Alternatively, one can think of a strong validator as part
- of an identifier for a specific entity, while a weak validator is
- part of an identifier for a set of semantically equivalent entities.
-
- Note: One example of a strong validator is an integer that is
- incremented in stable storage every time an entity is changed.
-
-
-
-Fielding, et al. Standards Track [Page 86]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- An entity's modification time, if represented with one-second
- resolution, could be a weak validator, since it is possible that
- the resource might be modified twice during a single second.
-
- Support for weak validators is optional. However, weak validators
- allow for more efficient caching of equivalent objects; for
- example, a hit counter on a site is probably good enough if it is
- updated every few days or weeks, and any value during that period
- is likely "good enough" to be equivalent.
-
- A "use" of a validator is either when a client generates a request
- and includes the validator in a validating header field, or when a
- server compares two validators.
-
- Strong validators are usable in any context. Weak validators are only
- usable in contexts that do not depend on exact equality of an entity.
- For example, either kind is usable for a conditional GET of a full
- entity. However, only a strong validator is usable for a sub-range
- retrieval, since otherwise the client might end up with an internally
- inconsistent entity.
-
- Clients MAY issue simple (non-subrange) GET requests with either weak
- validators or strong validators. Clients MUST NOT use weak validators
- in other forms of request.
-
- The only function that the HTTP/1.1 protocol defines on validators is
- comparison. There are two validator comparison functions, depending
- on whether the comparison context allows the use of weak validators
- or not:
-
- - The strong comparison function: in order to be considered equal,
- both validators MUST be identical in every way, and both MUST
- NOT be weak.
-
- - The weak comparison function: in order to be considered equal,
- both validators MUST be identical in every way, but either or
- both of them MAY be tagged as "weak" without affecting the
- result.
-
- An entity tag is strong unless it is explicitly tagged as weak.
- Section 3.11 gives the syntax for entity tags.
-
- A Last-Modified time, when used as a validator in a request, is
- implicitly weak unless it is possible to deduce that it is strong,
- using the following rules:
-
- - The validator is being compared by an origin server to the
- actual current validator for the entity and,
-
-
-
-Fielding, et al. Standards Track [Page 87]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - That origin server reliably knows that the associated entity did
- not change twice during the second covered by the presented
- validator.
-
- or
-
- - The validator is about to be used by a client in an If-
- Modified-Since or If-Unmodified-Since header, because the client
- has a cache entry for the associated entity, and
-
- - That cache entry includes a Date value, which gives the time
- when the origin server sent the original response, and
-
- - The presented Last-Modified time is at least 60 seconds before
- the Date value.
-
- or
-
- - The validator is being compared by an intermediate cache to the
- validator stored in its cache entry for the entity, and
-
- - That cache entry includes a Date value, which gives the time
- when the origin server sent the original response, and
-
- - The presented Last-Modified time is at least 60 seconds before
- the Date value.
-
- This method relies on the fact that if two different responses were
- sent by the origin server during the same second, but both had the
- same Last-Modified time, then at least one of those responses would
- have a Date value equal to its Last-Modified time. The arbitrary 60-
- second limit guards against the possibility that the Date and Last-
- Modified values are generated from different clocks, or at somewhat
- different times during the preparation of the response. An
- implementation MAY use a value larger than 60 seconds, if it is
- believed that 60 seconds is too short.
-
- If a client wishes to perform a sub-range retrieval on a value for
- which it has only a Last-Modified time and no opaque validator, it
- MAY do this only if the Last-Modified time is strong in the sense
- described here.
-
- A cache or origin server receiving a conditional request, other than
- a full-body GET request, MUST use the strong comparison function to
- evaluate the condition.
-
- These rules allow HTTP/1.1 caches and clients to safely perform sub-
- range retrievals on values that have been obtained from HTTP/1.0
-
-
-
-Fielding, et al. Standards Track [Page 88]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- servers.
-
-13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
-
- We adopt a set of rules and recommendations for origin servers,
- clients, and caches regarding when various validator types ought to
- be used, and for what purposes.
-
- HTTP/1.1 origin servers:
-
- - SHOULD send an entity tag validator unless it is not feasible to
- generate one.
-
- - MAY send a weak entity tag instead of a strong entity tag, if
- performance considerations support the use of weak entity tags,
- or if it is unfeasible to send a strong entity tag.
-
- - SHOULD send a Last-Modified value if it is feasible to send one,
- unless the risk of a breakdown in semantic transparency that
- could result from using this date in an If-Modified-Since header
- would lead to serious problems.
-
- In other words, the preferred behavior for an HTTP/1.1 origin server
- is to send both a strong entity tag and a Last-Modified value.
-
- In order to be legal, a strong entity tag MUST change whenever the
- associated entity value changes in any way. A weak entity tag SHOULD
- change whenever the associated entity changes in a semantically
- significant way.
-
- Note: in order to provide semantically transparent caching, an
- origin server must avoid reusing a specific strong entity tag
- value for two different entities, or reusing a specific weak
- entity tag value for two semantically different entities. Cache
- entries might persist for arbitrarily long periods, regardless of
- expiration times, so it might be inappropriate to expect that a
- cache will never again attempt to validate an entry using a
- validator that it obtained at some point in the past.
-
- HTTP/1.1 clients:
-
- - If an entity tag has been provided by the origin server, MUST
- use that entity tag in any cache-conditional request (using If-
- Match or If-None-Match).
-
- - If only a Last-Modified value has been provided by the origin
- server, SHOULD use that value in non-subrange cache-conditional
- requests (using If-Modified-Since).
-
-
-
-Fielding, et al. Standards Track [Page 89]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - If only a Last-Modified value has been provided by an HTTP/1.0
- origin server, MAY use that value in subrange cache-conditional
- requests (using If-Unmodified-Since:). The user agent SHOULD
- provide a way to disable this, in case of difficulty.
-
- - If both an entity tag and a Last-Modified value have been
- provided by the origin server, SHOULD use both validators in
- cache-conditional requests. This allows both HTTP/1.0 and
- HTTP/1.1 caches to respond appropriately.
-
- An HTTP/1.1 origin server, upon receiving a conditional request that
- includes both a Last-Modified date (e.g., in an If-Modified-Since or
- If-Unmodified-Since header field) and one or more entity tags (e.g.,
- in an If-Match, If-None-Match, or If-Range header field) as cache
- validators, MUST NOT return a response status of 304 (Not Modified)
- unless doing so is consistent with all of the conditional header
- fields in the request.
-
- An HTTP/1.1 caching proxy, upon receiving a conditional request that
- includes both a Last-Modified date and one or more entity tags as
- cache validators, MUST NOT return a locally cached response to the
- client unless that cached response is consistent with all of the
- conditional header fields in the request.
-
- Note: The general principle behind these rules is that HTTP/1.1
- servers and clients should transmit as much non-redundant
- information as is available in their responses and requests.
- HTTP/1.1 systems receiving this information will make the most
- conservative assumptions about the validators they receive.
-
- HTTP/1.0 clients and caches will ignore entity tags. Generally,
- last-modified values received or used by these systems will
- support transparent and efficient caching, and so HTTP/1.1 origin
- servers should provide Last-Modified values. In those rare cases
- where the use of a Last-Modified value as a validator by an
- HTTP/1.0 system could result in a serious problem, then HTTP/1.1
- origin servers should not provide one.
-
-13.3.5 Non-validating Conditionals
-
- The principle behind entity tags is that only the service author
- knows the semantics of a resource well enough to select an
- appropriate cache validation mechanism, and the specification of any
- validator comparison function more complex than byte-equality would
- open up a can of worms. Thus, comparisons of any other headers
- (except Last-Modified, for compatibility with HTTP/1.0) are never
- used for purposes of validating a cache entry.
-
-
-
-
-Fielding, et al. Standards Track [Page 90]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.4 Response Cacheability
-
- Unless specifically constrained by a cache-control (section 14.9)
- directive, a caching system MAY always store a successful response
- (see section 13.8) as a cache entry, MAY return it without validation
- if it is fresh, and MAY return it after successful validation. If
- there is neither a cache validator nor an explicit expiration time
- associated with a response, we do not expect it to be cached, but
- certain caches MAY violate this expectation (for example, when little
- or no network connectivity is available). A client can usually detect
- that such a response was taken from a cache by comparing the Date
- header to the current time.
-
- Note: some HTTP/1.0 caches are known to violate this expectation
- without providing any Warning.
-
- However, in some cases it might be inappropriate for a cache to
- retain an entity, or to return it in response to a subsequent
- request. This might be because absolute semantic transparency is
- deemed necessary by the service author, or because of security or
- privacy considerations. Certain cache-control directives are
- therefore provided so that the server can indicate that certain
- resource entities, or portions thereof, are not to be cached
- regardless of other considerations.
-
- Note that section 14.8 normally prevents a shared cache from saving
- and returning a response to a previous request if that request
- included an Authorization header.
-
- A response received with a status code of 200, 203, 206, 300, 301 or
- 410 MAY be stored by a cache and used in reply to a subsequent
- request, subject to the expiration mechanism, unless a cache-control
- directive prohibits caching. However, a cache that does not support
- the Range and Content-Range headers MUST NOT cache 206 (Partial
- Content) responses.
-
- A response received with any other status code (e.g. status codes 302
- and 307) MUST NOT be returned in a reply to a subsequent request
- unless there are cache-control directives or another header(s) that
- explicitly allow it. For example, these include the following: an
- Expires header (section 14.21); a "max-age", "s-maxage", "must-
- revalidate", "proxy-revalidate", "public" or "private" cache-control
- directive (section 14.9).
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 91]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.5 Constructing Responses From Caches
-
- The purpose of an HTTP cache is to store information received in
- response to requests for use in responding to future requests. In
- many cases, a cache simply returns the appropriate parts of a
- response to the requester. However, if the cache holds a cache entry
- based on a previous response, it might have to combine parts of a new
- response with what is held in the cache entry.
-
-13.5.1 End-to-end and Hop-by-hop Headers
-
- For the purpose of defining the behavior of caches and non-caching
- proxies, we divide HTTP headers into two categories:
-
- - End-to-end headers, which are transmitted to the ultimate
- recipient of a request or response. End-to-end headers in
- responses MUST be stored as part of a cache entry and MUST be
- transmitted in any response formed from a cache entry.
-
- - Hop-by-hop headers, which are meaningful only for a single
- transport-level connection, and are not stored by caches or
- forwarded by proxies.
-
- The following HTTP/1.1 headers are hop-by-hop headers:
-
- - Connection
- - Keep-Alive
- - Proxy-Authenticate
- - Proxy-Authorization
- - TE
- - Trailers
- - Transfer-Encoding
- - Upgrade
-
- All other headers defined by HTTP/1.1 are end-to-end headers.
-
- Other hop-by-hop headers MUST be listed in a Connection header,
- (section 14.10) to be introduced into HTTP/1.1 (or later).
-
-13.5.2 Non-modifiable Headers
-
- Some features of the HTTP/1.1 protocol, such as Digest
- Authentication, depend on the value of certain end-to-end headers. A
- transparent proxy SHOULD NOT modify an end-to-end header unless the
- definition of that header requires or specifically allows that.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 92]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- A transparent proxy MUST NOT modify any of the following fields in a
- request or response, and it MUST NOT add any of these fields if not
- already present:
-
- - Content-Location
-
- - Content-MD5
-
- - ETag
-
- - Last-Modified
-
- A transparent proxy MUST NOT modify any of the following fields in a
- response:
-
- - Expires
-
- but it MAY add any of these fields if not already present. If an
- Expires header is added, it MUST be given a field-value identical to
- that of the Date header in that response.
-
- A proxy MUST NOT modify or add any of the following fields in a
- message that contains the no-transform cache-control directive, or in
- any request:
-
- - Content-Encoding
-
- - Content-Range
-
- - Content-Type
-
- A non-transparent proxy MAY modify or add these fields to a message
- that does not include no-transform, but if it does so, it MUST add a
- Warning 214 (Transformation applied) if one does not already appear
- in the message (see section 14.46).
-
- Warning: unnecessary modification of end-to-end headers might
- cause authentication failures if stronger authentication
- mechanisms are introduced in later versions of HTTP. Such
- authentication mechanisms MAY rely on the values of header fields
- not listed here.
-
- The Content-Length field of a request or response is added or deleted
- according to the rules in section 4.4. A transparent proxy MUST
- preserve the entity-length (section 7.2.2) of the entity-body,
- although it MAY change the transfer-length (section 4.4).
-
-
-
-
-
-Fielding, et al. Standards Track [Page 93]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.5.3 Combining Headers
-
- When a cache makes a validating request to a server, and the server
- provides a 304 (Not Modified) response or a 206 (Partial Content)
- response, the cache then constructs a response to send to the
- requesting client.
-
- If the status code is 304 (Not Modified), the cache uses the entity-
- body stored in the cache entry as the entity-body of this outgoing
- response. If the status code is 206 (Partial Content) and the ETag or
- Last-Modified headers match exactly, the cache MAY combine the
- contents stored in the cache entry with the new contents received in
- the response and use the result as the entity-body of this outgoing
- response, (see 13.5.4).
-
- The end-to-end headers stored in the cache entry are used for the
- constructed response, except that
-
- - any stored Warning headers with warn-code 1xx (see section
- 14.46) MUST be deleted from the cache entry and the forwarded
- response.
-
- - any stored Warning headers with warn-code 2xx MUST be retained
- in the cache entry and the forwarded response.
-
- - any end-to-end headers provided in the 304 or 206 response MUST
- replace the corresponding headers from the cache entry.
-
- Unless the cache decides to remove the cache entry, it MUST also
- replace the end-to-end headers stored with the cache entry with
- corresponding headers received in the incoming response, except for
- Warning headers as described immediately above. If a header field-
- name in the incoming response matches more than one header in the
- cache entry, all such old headers MUST be replaced.
-
- In other words, the set of end-to-end headers received in the
- incoming response overrides all corresponding end-to-end headers
- stored with the cache entry (except for stored Warning headers with
- warn-code 1xx, which are deleted even if not overridden).
-
- Note: this rule allows an origin server to use a 304 (Not
- Modified) or a 206 (Partial Content) response to update any header
- associated with a previous response for the same entity or sub-
- ranges thereof, although it might not always be meaningful or
- correct to do so. This rule does not allow an origin server to use
- a 304 (Not Modified) or a 206 (Partial Content) response to
- entirely delete a header that it had provided with a previous
- response.
-
-
-
-Fielding, et al. Standards Track [Page 94]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.5.4 Combining Byte Ranges
-
- A response might transfer only a subrange of the bytes of an entity-
- body, either because the request included one or more Range
- specifications, or because a connection was broken prematurely. After
- several such transfers, a cache might have received several ranges of
- the same entity-body.
-
- If a cache has a stored non-empty set of subranges for an entity, and
- an incoming response transfers another subrange, the cache MAY
- combine the new subrange with the existing set if both the following
- conditions are met:
-
- - Both the incoming response and the cache entry have a cache
- validator.
-
- - The two cache validators match using the strong comparison
- function (see section 13.3.3).
-
- If either requirement is not met, the cache MUST use only the most
- recent partial response (based on the Date values transmitted with
- every response, and using the incoming response if these values are
- equal or missing), and MUST discard the other partial information.
-
-13.6 Caching Negotiated Responses
-
- Use of server-driven content negotiation (section 12.1), as indicated
- by the presence of a Vary header field in a response, alters the
- conditions and procedure by which a cache can use the response for
- subsequent requests. See section 14.44 for use of the Vary header
- field by servers.
-
- A server SHOULD use the Vary header field to inform a cache of what
- request-header fields were used to select among multiple
- representations of a cacheable response subject to server-driven
- negotiation. The set of header fields named by the Vary field value
- is known as the "selecting" request-headers.
-
- When the cache receives a subsequent request whose Request-URI
- specifies one or more cache entries including a Vary header field,
- the cache MUST NOT use such a cache entry to construct a response to
- the new request unless all of the selecting request-headers present
- in the new request match the corresponding stored request-headers in
- the original request.
-
- The selecting request-headers from two requests are defined to match
- if and only if the selecting request-headers in the first request can
- be transformed to the selecting request-headers in the second request
-
-
-
-Fielding, et al. Standards Track [Page 95]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- by adding or removing linear white space (LWS) at places where this
- is allowed by the corresponding BNF, and/or combining multiple
- message-header fields with the same field name following the rules
- about message headers in section 4.2.
-
- A Vary header field-value of "*" always fails to match and subsequent
- requests on that resource can only be properly interpreted by the
- origin server.
-
- If the selecting request header fields for the cached entry do not
- match the selecting request header fields of the new request, then
- the cache MUST NOT use a cached entry to satisfy the request unless
- it first relays the new request to the origin server in a conditional
- request and the server responds with 304 (Not Modified), including an
- entity tag or Content-Location that indicates the entity to be used.
-
- If an entity tag was assigned to a cached representation, the
- forwarded request SHOULD be conditional and include the entity tags
- in an If-None-Match header field from all its cache entries for the
- resource. This conveys to the server the set of entities currently
- held by the cache, so that if any one of these entities matches the
- requested entity, the server can use the ETag header field in its 304
- (Not Modified) response to tell the cache which entry is appropriate.
- If the entity-tag of the new response matches that of an existing
- entry, the new response SHOULD be used to update the header fields of
- the existing entry, and the result MUST be returned to the client.
-
- If any of the existing cache entries contains only partial content
- for the associated entity, its entity-tag SHOULD NOT be included in
- the If-None-Match header field unless the request is for a range that
- would be fully satisfied by that entry.
-
- If a cache receives a successful response whose Content-Location
- field matches that of an existing cache entry for the same Request-
- ]URI, whose entity-tag differs from that of the existing entry, and
- whose Date is more recent than that of the existing entry, the
- existing entry SHOULD NOT be returned in response to future requests
- and SHOULD be deleted from the cache.
-
-13.7 Shared and Non-Shared Caches
-
- For reasons of security and privacy, it is necessary to make a
- distinction between "shared" and "non-shared" caches. A non-shared
- cache is one that is accessible only to a single user. Accessibility
- in this case SHOULD be enforced by appropriate security mechanisms.
- All other caches are considered to be "shared." Other sections of
-
-
-
-
-
-Fielding, et al. Standards Track [Page 96]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- this specification place certain constraints on the operation of
- shared caches in order to prevent loss of privacy or failure of
- access controls.
-
-13.8 Errors or Incomplete Response Cache Behavior
-
- A cache that receives an incomplete response (for example, with fewer
- bytes of data than specified in a Content-Length header) MAY store
- the response. However, the cache MUST treat this as a partial
- response. Partial responses MAY be combined as described in section
- 13.5.4; the result might be a full response or might still be
- partial. A cache MUST NOT return a partial response to a client
- without explicitly marking it as such, using the 206 (Partial
- Content) status code. A cache MUST NOT return a partial response
- using a status code of 200 (OK).
-
- If a cache receives a 5xx response while attempting to revalidate an
- entry, it MAY either forward this response to the requesting client,
- or act as if the server failed to respond. In the latter case, it MAY
- return a previously received response unless the cached entry
- includes the "must-revalidate" cache-control directive (see section
- 14.9).
-
-13.9 Side Effects of GET and HEAD
-
- Unless the origin server explicitly prohibits the caching of their
- responses, the application of GET and HEAD methods to any resources
- SHOULD NOT have side effects that would lead to erroneous behavior if
- these responses are taken from a cache. They MAY still have side
- effects, but a cache is not required to consider such side effects in
- its caching decisions. Caches are always expected to observe an
- origin server's explicit restrictions on caching.
-
- We note one exception to this rule: since some applications have
- traditionally used GETs and HEADs with query URLs (those containing a
- "?" in the rel_path part) to perform operations with significant side
- effects, caches MUST NOT treat responses to such URIs as fresh unless
- the server provides an explicit expiration time. This specifically
- means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
- be taken from a cache. See section 9.1.1 for related information.
-
-13.10 Invalidation After Updates or Deletions
-
- The effect of certain methods performed on a resource at the origin
- server might cause one or more existing cache entries to become non-
- transparently invalid. That is, although they might continue to be
- "fresh," they do not accurately reflect what the origin server would
- return for a new request on that resource.
-
-
-
-Fielding, et al. Standards Track [Page 97]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- There is no way for the HTTP protocol to guarantee that all such
- cache entries are marked invalid. For example, the request that
- caused the change at the origin server might not have gone through
- the proxy where a cache entry is stored. However, several rules help
- reduce the likelihood of erroneous behavior.
-
- In this section, the phrase "invalidate an entity" means that the
- cache will either remove all instances of that entity from its
- storage, or will mark these as "invalid" and in need of a mandatory
- revalidation before they can be returned in response to a subsequent
- request.
-
- Some HTTP methods MUST cause a cache to invalidate an entity. This is
- either the entity referred to by the Request-URI, or by the Location
- or Content-Location headers (if present). These methods are:
-
- - PUT
-
- - DELETE
-
- - POST
-
- In order to prevent denial of service attacks, an invalidation based
- on the URI in a Location or Content-Location header MUST only be
- performed if the host part is the same as in the Request-URI.
-
- A cache that passes through requests for methods it does not
- understand SHOULD invalidate any entities referred to by the
- Request-URI.
-
-13.11 Write-Through Mandatory
-
- All methods that might be expected to cause modifications to the
- origin server's resources MUST be written through to the origin
- server. This currently includes all methods except for GET and HEAD.
- A cache MUST NOT reply to such a request from a client before having
- transmitted the request to the inbound server, and having received a
- corresponding response from the inbound server. This does not prevent
- a proxy cache from sending a 100 (Continue) response before the
- inbound server has sent its final reply.
-
- The alternative (known as "write-back" or "copy-back" caching) is not
- allowed in HTTP/1.1, due to the difficulty of providing consistent
- updates and the problems arising from server, cache, or network
- failure prior to write-back.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 98]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-13.12 Cache Replacement
-
- If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
- response is received from a resource while any existing responses for
- the same resource are cached, the cache SHOULD use the new response
- to reply to the current request. It MAY insert it into cache storage
- and MAY, if it meets all other requirements, use it to respond to any
- future requests that would previously have caused the old response to
- be returned. If it inserts the new response into cache storage the
- rules in section 13.5.3 apply.
-
- Note: a new response that has an older Date header value than
- existing cached responses is not cacheable.
-
-13.13 History Lists
-
- User agents often have history mechanisms, such as "Back" buttons and
- history lists, which can be used to redisplay an entity retrieved
- earlier in a session.
-
- History mechanisms and caches are different. In particular history
- mechanisms SHOULD NOT try to show a semantically transparent view of
- the current state of a resource. Rather, a history mechanism is meant
- to show exactly what the user saw at the time when the resource was
- retrieved.
-
- By default, an expiration time does not apply to history mechanisms.
- If the entity is still in storage, a history mechanism SHOULD display
- it even if the entity has expired, unless the user has specifically
- configured the agent to refresh expired history documents.
-
- This is not to be construed to prohibit the history mechanism from
- telling the user that a view might be stale.
-
- Note: if history list mechanisms unnecessarily prevent users from
- viewing stale resources, this will tend to force service authors
- to avoid using HTTP expiration controls and cache controls when
- they would otherwise like to. Service authors may consider it
- important that users not be presented with error messages or
- warning messages when they use navigation controls (such as BACK)
- to view previously fetched resources. Even though sometimes such
- resources ought not to cached, or ought to expire quickly, user
- interface considerations may force service authors to resort to
- other means of preventing caching (e.g. "once-only" URLs) in order
- not to suffer the effects of improperly functioning history
- mechanisms.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 99]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14 Header Field Definitions
-
- This section defines the syntax and semantics of all standard
- HTTP/1.1 header fields. For entity-header fields, both sender and
- recipient refer to either the client or the server, depending on who
- sends and who receives the entity.
-
-14.1 Accept
-
- The Accept request-header field can be used to specify certain media
- types which are acceptable for the response. Accept headers can be
- used to indicate that the request is specifically limited to a small
- set of desired types, as in the case of a request for an in-line
- image.
-
- Accept = "Accept" ":"
- #( media-range [ accept-params ] )
-
- media-range = ( "*/*"
- | ( type "/" "*" )
- | ( type "/" subtype )
- ) *( ";" parameter )
- accept-params = ";" "q" "=" qvalue *( accept-extension )
- accept-extension = ";" token [ "=" ( token | quoted-string ) ]
-
- The asterisk "*" character is used to group media types into ranges,
- with "*/*" indicating all media types and "type/*" indicating all
- subtypes of that type. The media-range MAY include media type
- parameters that are applicable to that range.
-
- Each media-range MAY be followed by one or more accept-params,
- beginning with the "q" parameter for indicating a relative quality
- factor. The first "q" parameter (if any) separates the media-range
- parameter(s) from the accept-params. Quality factors allow the user
- or user agent to indicate the relative degree of preference for that
- media-range, using the qvalue scale from 0 to 1 (section 3.9). The
- default value is q=1.
-
- Note: Use of the "q" parameter name to separate media type
- parameters from Accept extension parameters is due to historical
- practice. Although this prevents any media type parameter named
- "q" from being used with a media range, such an event is believed
- to be unlikely given the lack of any "q" parameters in the IANA
- media type registry and the rare usage of any media type
- parameters in Accept. Future media types are discouraged from
- registering any parameter named "q".
-
-
-
-
-
-Fielding, et al. Standards Track [Page 100]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The example
-
- Accept: audio/*; q=0.2, audio/basic
-
- SHOULD be interpreted as "I prefer audio/basic, but send me any audio
- type if it is the best available after an 80% mark-down in quality."
-
- If no Accept header field is present, then it is assumed that the
- client accepts all media types. If an Accept header field is present,
- and if the server cannot send a response which is acceptable
- according to the combined Accept field value, then the server SHOULD
- send a 406 (not acceptable) response.
-
- A more elaborate example is
-
- Accept: text/plain; q=0.5, text/html,
- text/x-dvi; q=0.8, text/x-c
-
- Verbally, this would be interpreted as "text/html and text/x-c are
- the preferred media types, but if they do not exist, then send the
- text/x-dvi entity, and if that does not exist, send the text/plain
- entity."
-
- Media ranges can be overridden by more specific media ranges or
- specific media types. If more than one media range applies to a given
- type, the most specific reference has precedence. For example,
-
- Accept: text/*, text/html, text/html;level=1, */*
-
- have the following precedence:
-
- 1) text/html;level=1
- 2) text/html
- 3) text/*
- 4) */*
-
- The media type quality factor associated with a given type is
- determined by finding the media range with the highest precedence
- which matches that type. For example,
-
- Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
- text/html;level=2;q=0.4, */*;q=0.5
-
- would cause the following values to be associated:
-
- text/html;level=1 = 1
- text/html = 0.7
- text/plain = 0.3
-
-
-
-Fielding, et al. Standards Track [Page 101]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- image/jpeg = 0.5
- text/html;level=2 = 0.4
- text/html;level=3 = 0.7
-
- Note: A user agent might be provided with a default set of quality
- values for certain media ranges. However, unless the user agent is
- a closed system which cannot interact with other rendering agents,
- this default set ought to be configurable by the user.
-
-14.2 Accept-Charset
-
- The Accept-Charset request-header field can be used to indicate what
- character sets are acceptable for the response. This field allows
- clients capable of understanding more comprehensive or special-
- purpose character sets to signal that capability to a server which is
- capable of representing documents in those character sets.
-
- Accept-Charset = "Accept-Charset" ":"
- 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
-
-
- Character set values are described in section 3.4. Each charset MAY
- be given an associated quality value which represents the user's
- preference for that charset. The default value is q=1. An example is
-
- Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
-
- The special value "*", if present in the Accept-Charset field,
- matches every character set (including ISO-8859-1) which is not
- mentioned elsewhere in the Accept-Charset field. If no "*" is present
- in an Accept-Charset field, then all character sets not explicitly
- mentioned get a quality value of 0, except for ISO-8859-1, which gets
- a quality value of 1 if not explicitly mentioned.
-
- If no Accept-Charset header is present, the default is that any
- character set is acceptable. If an Accept-Charset header is present,
- and if the server cannot send a response which is acceptable
- according to the Accept-Charset header, then the server SHOULD send
- an error response with the 406 (not acceptable) status code, though
- the sending of an unacceptable response is also allowed.
-
-14.3 Accept-Encoding
-
- The Accept-Encoding request-header field is similar to Accept, but
- restricts the content-codings (section 3.5) that are acceptable in
- the response.
-
- Accept-Encoding = "Accept-Encoding" ":"
-
-
-
-Fielding, et al. Standards Track [Page 102]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 1#( codings [ ";" "q" "=" qvalue ] )
- codings = ( content-coding | "*" )
-
- Examples of its use are:
-
- Accept-Encoding: compress, gzip
- Accept-Encoding:
- Accept-Encoding: *
- Accept-Encoding: compress;q=0.5, gzip;q=1.0
- Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
-
- A server tests whether a content-coding is acceptable, according to
- an Accept-Encoding field, using these rules:
-
- 1. If the content-coding is one of the content-codings listed in
- the Accept-Encoding field, then it is acceptable, unless it is
- accompanied by a qvalue of 0. (As defined in section 3.9, a
- qvalue of 0 means "not acceptable.")
-
- 2. The special "*" symbol in an Accept-Encoding field matches any
- available content-coding not explicitly listed in the header
- field.
-
- 3. If multiple content-codings are acceptable, then the acceptable
- content-coding with the highest non-zero qvalue is preferred.
-
- 4. The "identity" content-coding is always acceptable, unless
- specifically refused because the Accept-Encoding field includes
- "identity;q=0", or because the field includes "*;q=0" and does
- not explicitly include the "identity" content-coding. If the
- Accept-Encoding field-value is empty, then only the "identity"
- encoding is acceptable.
-
- If an Accept-Encoding field is present in a request, and if the
- server cannot send a response which is acceptable according to the
- Accept-Encoding header, then the server SHOULD send an error response
- with the 406 (Not Acceptable) status code.
-
- If no Accept-Encoding field is present in a request, the server MAY
- assume that the client will accept any content coding. In this case,
- if "identity" is one of the available content-codings, then the
- server SHOULD use the "identity" content-coding, unless it has
- additional information that a different content-coding is meaningful
- to the client.
-
- Note: If the request does not include an Accept-Encoding field,
- and if the "identity" content-coding is unavailable, then
- content-codings commonly understood by HTTP/1.0 clients (i.e.,
-
-
-
-Fielding, et al. Standards Track [Page 103]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- "gzip" and "compress") are preferred; some older clients
- improperly display messages sent with other content-codings. The
- server might also make this decision based on information about
- the particular user-agent or client.
-
- Note: Most HTTP/1.0 applications do not recognize or obey qvalues
- associated with content-codings. This means that qvalues will not
- work and are not permitted with x-gzip or x-compress.
-
-14.4 Accept-Language
-
- The Accept-Language request-header field is similar to Accept, but
- restricts the set of natural languages that are preferred as a
- response to the request. Language tags are defined in section 3.10.
-
- Accept-Language = "Accept-Language" ":"
- 1#( language-range [ ";" "q" "=" qvalue ] )
- language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
-
- Each language-range MAY be given an associated quality value which
- represents an estimate of the user's preference for the languages
- specified by that range. The quality value defaults to "q=1". For
- example,
-
- Accept-Language: da, en-gb;q=0.8, en;q=0.7
-
- would mean: "I prefer Danish, but will accept British English and
- other types of English." A language-range matches a language-tag if
- it exactly equals the tag, or if it exactly equals a prefix of the
- tag such that the first tag character following the prefix is "-".
- The special range "*", if present in the Accept-Language field,
- matches every tag not matched by any other range present in the
- Accept-Language field.
-
- Note: This use of a prefix matching rule does not imply that
- language tags are assigned to languages in such a way that it is
- always true that if a user understands a language with a certain
- tag, then this user will also understand all languages with tags
- for which this tag is a prefix. The prefix rule simply allows the
- use of prefix tags if this is the case.
-
- The language quality factor assigned to a language-tag by the
- Accept-Language field is the quality value of the longest language-
- range in the field that matches the language-tag. If no language-
- range in the field matches the tag, the language quality factor
- assigned is 0. If no Accept-Language header is present in the
- request, the server
-
-
-
-
-Fielding, et al. Standards Track [Page 104]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- SHOULD assume that all languages are equally acceptable. If an
- Accept-Language header is present, then all languages which are
- assigned a quality factor greater than 0 are acceptable.
-
- It might be contrary to the privacy expectations of the user to send
- an Accept-Language header with the complete linguistic preferences of
- the user in every request. For a discussion of this issue, see
- section 15.1.4.
-
- As intelligibility is highly dependent on the individual user, it is
- recommended that client applications make the choice of linguistic
- preference available to the user. If the choice is not made
- available, then the Accept-Language header field MUST NOT be given in
- the request.
-
- Note: When making the choice of linguistic preference available to
- the user, we remind implementors of the fact that users are not
- familiar with the details of language matching as described above,
- and should provide appropriate guidance. As an example, users
- might assume that on selecting "en-gb", they will be served any
- kind of English document if British English is not available. A
- user agent might suggest in such a case to add "en" to get the
- best matching behavior.
-
-14.5 Accept-Ranges
-
- The Accept-Ranges response-header field allows the server to
- indicate its acceptance of range requests for a resource:
-
- Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
- acceptable-ranges = 1#range-unit | "none"
-
- Origin servers that accept byte-range requests MAY send
-
- Accept-Ranges: bytes
-
- but are not required to do so. Clients MAY generate byte-range
- requests without having received this header for the resource
- involved. Range units are defined in section 3.12.
-
- Servers that do not accept any kind of range request for a
- resource MAY send
-
- Accept-Ranges: none
-
- to advise the client not to attempt a range request.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 105]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.6 Age
-
- The Age response-header field conveys the sender's estimate of the
- amount of time since the response (or its revalidation) was
- generated at the origin server. A cached response is "fresh" if
- its age does not exceed its freshness lifetime. Age values are
- calculated as specified in section 13.2.3.
-
- Age = "Age" ":" age-value
- age-value = delta-seconds
-
- Age values are non-negative decimal integers, representing time in
- seconds.
-
- If a cache receives a value larger than the largest positive
- integer it can represent, or if any of its age calculations
- overflows, it MUST transmit an Age header with a value of
- 2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
- include an Age header field in every response generated from its
- own cache. Caches SHOULD use an arithmetic type of at least 31
- bits of range.
-
-14.7 Allow
-
- The Allow entity-header field lists the set of methods supported
- by the resource identified by the Request-URI. The purpose of this
- field is strictly to inform the recipient of valid methods
- associated with the resource. An Allow header field MUST be
- present in a 405 (Method Not Allowed) response.
-
- Allow = "Allow" ":" #Method
-
- Example of use:
-
- Allow: GET, HEAD, PUT
-
- This field cannot prevent a client from trying other methods.
- However, the indications given by the Allow header field value
- SHOULD be followed. The actual set of allowed methods is defined
- by the origin server at the time of each request.
-
- The Allow header field MAY be provided with a PUT request to
- recommend the methods to be supported by the new or modified
- resource. The server is not required to support these methods and
- SHOULD include an Allow header in the response giving the actual
- supported methods.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 106]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- A proxy MUST NOT modify the Allow header field even if it does not
- understand all the methods specified, since the user agent might
- have other means of communicating with the origin server.
-
-14.8 Authorization
-
- A user agent that wishes to authenticate itself with a server--
- usually, but not necessarily, after receiving a 401 response--does
- so by including an Authorization request-header field with the
- request. The Authorization field value consists of credentials
- containing the authentication information of the user agent for
- the realm of the resource being requested.
-
- Authorization = "Authorization" ":" credentials
-
- HTTP access authentication is described in "HTTP Authentication:
- Basic and Digest Access Authentication" [43]. If a request is
- authenticated and a realm specified, the same credentials SHOULD
- be valid for all other requests within this realm (assuming that
- the authentication scheme itself does not require otherwise, such
- as credentials that vary according to a challenge value or using
- synchronized clocks).
-
- When a shared cache (see section 13.7) receives a request
- containing an Authorization field, it MUST NOT return the
- corresponding response as a reply to any other request, unless one
- of the following specific exceptions holds:
-
- 1. If the response includes the "s-maxage" cache-control
- directive, the cache MAY use that response in replying to a
- subsequent request. But (if the specified maximum age has
- passed) a proxy cache MUST first revalidate it with the origin
- server, using the request-headers from the new request to allow
- the origin server to authenticate the new request. (This is the
- defined behavior for s-maxage.) If the response includes "s-
- maxage=0", the proxy MUST always revalidate it before re-using
- it.
-
- 2. If the response includes the "must-revalidate" cache-control
- directive, the cache MAY use that response in replying to a
- subsequent request. But if the response is stale, all caches
- MUST first revalidate it with the origin server, using the
- request-headers from the new request to allow the origin server
- to authenticate the new request.
-
- 3. If the response includes the "public" cache-control directive,
- it MAY be returned in reply to any subsequent request.
-
-
-
-
-Fielding, et al. Standards Track [Page 107]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.9 Cache-Control
-
- The Cache-Control general-header field is used to specify directives
- that MUST be obeyed by all caching mechanisms along the
- request/response chain. The directives specify behavior intended to
- prevent caches from adversely interfering with the request or
- response. These directives typically override the default caching
- algorithms. Cache directives are unidirectional in that the presence
- of a directive in a request does not imply that the same directive is
- to be given in the response.
-
- Note that HTTP/1.0 caches might not implement Cache-Control and
- might only implement Pragma: no-cache (see section 14.32).
-
- Cache directives MUST be passed through by a proxy or gateway
- application, regardless of their significance to that application,
- since the directives might be applicable to all recipients along the
- request/response chain. It is not possible to specify a cache-
- directive for a specific cache.
-
- Cache-Control = "Cache-Control" ":" 1#cache-directive
-
- cache-directive = cache-request-directive
- | cache-response-directive
-
- cache-request-directive =
- "no-cache" ; Section 14.9.1
- | "no-store" ; Section 14.9.2
- | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
- | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
- | "min-fresh" "=" delta-seconds ; Section 14.9.3
- | "no-transform" ; Section 14.9.5
- | "only-if-cached" ; Section 14.9.4
- | cache-extension ; Section 14.9.6
-
- cache-response-directive =
- "public" ; Section 14.9.1
- | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
- | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
- | "no-store" ; Section 14.9.2
- | "no-transform" ; Section 14.9.5
- | "must-revalidate" ; Section 14.9.4
- | "proxy-revalidate" ; Section 14.9.4
- | "max-age" "=" delta-seconds ; Section 14.9.3
- | "s-maxage" "=" delta-seconds ; Section 14.9.3
- | cache-extension ; Section 14.9.6
-
- cache-extension = token [ "=" ( token | quoted-string ) ]
-
-
-
-Fielding, et al. Standards Track [Page 108]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- When a directive appears without any 1#field-name parameter, the
- directive applies to the entire request or response. When such a
- directive appears with a 1#field-name parameter, it applies only to
- the named field or fields, and not to the rest of the request or
- response. This mechanism supports extensibility; implementations of
- future versions of the HTTP protocol might apply these directives to
- header fields not defined in HTTP/1.1.
-
- The cache-control directives can be broken down into these general
- categories:
-
- - Restrictions on what are cacheable; these may only be imposed by
- the origin server.
-
- - Restrictions on what may be stored by a cache; these may be
- imposed by either the origin server or the user agent.
-
- - Modifications of the basic expiration mechanism; these may be
- imposed by either the origin server or the user agent.
-
- - Controls over cache revalidation and reload; these may only be
- imposed by a user agent.
-
- - Control over transformation of entities.
-
- - Extensions to the caching system.
-
-14.9.1 What is Cacheable
-
- By default, a response is cacheable if the requirements of the
- request method, request header fields, and the response status
- indicate that it is cacheable. Section 13.4 summarizes these defaults
- for cacheability. The following Cache-Control response directives
- allow an origin server to override the default cacheability of a
- response:
-
- public
- Indicates that the response MAY be cached by any cache, even if it
- would normally be non-cacheable or cacheable only within a non-
- shared cache. (See also Authorization, section 14.8, for
- additional details.)
-
- private
- Indicates that all or part of the response message is intended for
- a single user and MUST NOT be cached by a shared cache. This
- allows an origin server to state that the specified parts of the
-
-
-
-
-
-Fielding, et al. Standards Track [Page 109]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- response are intended for only one user and are not a valid
- response for requests by other users. A private (non-shared) cache
- MAY cache the response.
-
- Note: This usage of the word private only controls where the
- response may be cached, and cannot ensure the privacy of the
- message content.
-
- no-cache
- If the no-cache directive does not specify a field-name, then a
- cache MUST NOT use the response to satisfy a subsequent request
- without successful revalidation with the origin server. This
- allows an origin server to prevent caching even by caches that
- have been configured to return stale responses to client requests.
-
- If the no-cache directive does specify one or more field-names,
- then a cache MAY use the response to satisfy a subsequent request,
- subject to any other restrictions on caching. However, the
- specified field-name(s) MUST NOT be sent in the response to a
- subsequent request without successful revalidation with the origin
- server. This allows an origin server to prevent the re-use of
- certain header fields in a response, while still allowing caching
- of the rest of the response.
-
- Note: Most HTTP/1.0 caches will not recognize or obey this
- directive.
-
-14.9.2 What May be Stored by Caches
-
- no-store
- The purpose of the no-store directive is to prevent the
- inadvertent release or retention of sensitive information (for
- example, on backup tapes). The no-store directive applies to the
- entire message, and MAY be sent either in a response or in a
- request. If sent in a request, a cache MUST NOT store any part of
- either this request or any response to it. If sent in a response,
- a cache MUST NOT store any part of either this response or the
- request that elicited it. This directive applies to both non-
- shared and shared caches. "MUST NOT store" in this context means
- that the cache MUST NOT intentionally store the information in
- non-volatile storage, and MUST make a best-effort attempt to
- remove the information from volatile storage as promptly as
- possible after forwarding it.
-
- Even when this directive is associated with a response, users
- might explicitly store such a response outside of the caching
- system (e.g., with a "Save As" dialog). History buffers MAY store
- such responses as part of their normal operation.
-
-
-
-Fielding, et al. Standards Track [Page 110]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The purpose of this directive is to meet the stated requirements
- of certain users and service authors who are concerned about
- accidental releases of information via unanticipated accesses to
- cache data structures. While the use of this directive might
- improve privacy in some cases, we caution that it is NOT in any
- way a reliable or sufficient mechanism for ensuring privacy. In
- particular, malicious or compromised caches might not recognize or
- obey this directive, and communications networks might be
- vulnerable to eavesdropping.
-
-14.9.3 Modifications of the Basic Expiration Mechanism
-
- The expiration time of an entity MAY be specified by the origin
- server using the Expires header (see section 14.21). Alternatively,
- it MAY be specified using the max-age directive in a response. When
- the max-age cache-control directive is present in a cached response,
- the response is stale if its current age is greater than the age
- value given (in seconds) at the time of a new request for that
- resource. The max-age directive on a response implies that the
- response is cacheable (i.e., "public") unless some other, more
- restrictive cache directive is also present.
-
- If a response includes both an Expires header and a max-age
- directive, the max-age directive overrides the Expires header, even
- if the Expires header is more restrictive. This rule allows an origin
- server to provide, for a given response, a longer expiration time to
- an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
- useful if certain HTTP/1.0 caches improperly calculate ages or
- expiration times, perhaps due to desynchronized clocks.
-
- Many HTTP/1.0 cache implementations will treat an Expires value that
- is less than or equal to the response Date value as being equivalent
- to the Cache-Control response directive "no-cache". If an HTTP/1.1
- cache receives such a response, and the response does not include a
- Cache-Control header field, it SHOULD consider the response to be
- non-cacheable in order to retain compatibility with HTTP/1.0 servers.
-
- Note: An origin server might wish to use a relatively new HTTP
- cache control feature, such as the "private" directive, on a
- network including older caches that do not understand that
- feature. The origin server will need to combine the new feature
- with an Expires field whose value is less than or equal to the
- Date value. This will prevent older caches from improperly
- caching the response.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 111]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- s-maxage
- If a response includes an s-maxage directive, then for a shared
- cache (but not for a private cache), the maximum age specified by
- this directive overrides the maximum age specified by either the
- max-age directive or the Expires header. The s-maxage directive
- also implies the semantics of the proxy-revalidate directive (see
- section 14.9.4), i.e., that the shared cache must not use the
- entry after it becomes stale to respond to a subsequent request
- without first revalidating it with the origin server. The s-
- maxage directive is always ignored by a private cache.
-
- Note that most older caches, not compliant with this specification,
- do not implement any cache-control directives. An origin server
- wishing to use a cache-control directive that restricts, but does not
- prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
- requirement that the max-age directive overrides the Expires header,
- and the fact that pre-HTTP/1.1-compliant caches do not observe the
- max-age directive.
-
- Other directives allow a user agent to modify the basic expiration
- mechanism. These directives MAY be specified on a request:
-
- max-age
- Indicates that the client is willing to accept a response whose
- age is no greater than the specified time in seconds. Unless max-
- stale directive is also included, the client is not willing to
- accept a stale response.
-
- min-fresh
- Indicates that the client is willing to accept a response whose
- freshness lifetime is no less than its current age plus the
- specified time in seconds. That is, the client wants a response
- that will still be fresh for at least the specified number of
- seconds.
-
- max-stale
- Indicates that the client is willing to accept a response that has
- exceeded its expiration time. If max-stale is assigned a value,
- then the client is willing to accept a response that has exceeded
- its expiration time by no more than the specified number of
- seconds. If no value is assigned to max-stale, then the client is
- willing to accept a stale response of any age.
-
- If a cache returns a stale response, either because of a max-stale
- directive on a request, or because the cache is configured to
- override the expiration time of a response, the cache MUST attach a
- Warning header to the stale response, using Warning 110 (Response is
- stale).
-
-
-
-Fielding, et al. Standards Track [Page 112]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- A cache MAY be configured to return stale responses without
- validation, but only if this does not conflict with any "MUST"-level
- requirements concerning cache validation (e.g., a "must-revalidate"
- cache-control directive).
-
- If both the new request and the cached entry include "max-age"
- directives, then the lesser of the two values is used for determining
- the freshness of the cached entry for that request.
-
-14.9.4 Cache Revalidation and Reload Controls
-
- Sometimes a user agent might want or need to insist that a cache
- revalidate its cache entry with the origin server (and not just with
- the next cache along the path to the origin server), or to reload its
- cache entry from the origin server. End-to-end revalidation might be
- necessary if either the cache or the origin server has overestimated
- the expiration time of the cached response. End-to-end reload may be
- necessary if the cache entry has become corrupted for some reason.
-
- End-to-end revalidation may be requested either when the client does
- not have its own local cached copy, in which case we call it
- "unspecified end-to-end revalidation", or when the client does have a
- local cached copy, in which case we call it "specific end-to-end
- revalidation."
-
- The client can specify these three kinds of action using Cache-
- Control request directives:
-
- End-to-end reload
- The request includes a "no-cache" cache-control directive or, for
- compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
- names MUST NOT be included with the no-cache directive in a
- request. The server MUST NOT use a cached copy when responding to
- such a request.
-
- Specific end-to-end revalidation
- The request includes a "max-age=0" cache-control directive, which
- forces each cache along the path to the origin server to
- revalidate its own entry, if any, with the next cache or server.
- The initial request includes a cache-validating conditional with
- the client's current validator.
-
- Unspecified end-to-end revalidation
- The request includes "max-age=0" cache-control directive, which
- forces each cache along the path to the origin server to
- revalidate its own entry, if any, with the next cache or server.
- The initial request does not include a cache-validating
-
-
-
-
-Fielding, et al. Standards Track [Page 113]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- conditional; the first cache along the path (if any) that holds a
- cache entry for this resource includes a cache-validating
- conditional with its current validator.
-
- max-age
- When an intermediate cache is forced, by means of a max-age=0
- directive, to revalidate its own cache entry, and the client has
- supplied its own validator in the request, the supplied validator
- might differ from the validator currently stored with the cache
- entry. In this case, the cache MAY use either validator in making
- its own request without affecting semantic transparency.
-
- However, the choice of validator might affect performance. The
- best approach is for the intermediate cache to use its own
- validator when making its request. If the server replies with 304
- (Not Modified), then the cache can return its now validated copy
- to the client with a 200 (OK) response. If the server replies with
- a new entity and cache validator, however, the intermediate cache
- can compare the returned validator with the one provided in the
- client's request, using the strong comparison function. If the
- client's validator is equal to the origin server's, then the
- intermediate cache simply returns 304 (Not Modified). Otherwise,
- it returns the new entity with a 200 (OK) response.
-
- If a request includes the no-cache directive, it SHOULD NOT
- include min-fresh, max-stale, or max-age.
-
- only-if-cached
- In some cases, such as times of extremely poor network
- connectivity, a client may want a cache to return only those
- responses that it currently has stored, and not to reload or
- revalidate with the origin server. To do this, the client may
- include the only-if-cached directive in a request. If it receives
- this directive, a cache SHOULD either respond using a cached entry
- that is consistent with the other constraints of the request, or
- respond with a 504 (Gateway Timeout) status. However, if a group
- of caches is being operated as a unified system with good internal
- connectivity, such a request MAY be forwarded within that group of
- caches.
-
- must-revalidate
- Because a cache MAY be configured to ignore a server's specified
- expiration time, and because a client request MAY include a max-
- stale directive (which has a similar effect), the protocol also
- includes a mechanism for the origin server to require revalidation
- of a cache entry on any subsequent use. When the must-revalidate
- directive is present in a response received by a cache, that cache
- MUST NOT use the entry after it becomes stale to respond to a
-
-
-
-Fielding, et al. Standards Track [Page 114]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- subsequent request without first revalidating it with the origin
- server. (I.e., the cache MUST do an end-to-end revalidation every
- time, if, based solely on the origin server's Expires or max-age
- value, the cached response is stale.)
-
- The must-revalidate directive is necessary to support reliable
- operation for certain protocol features. In all circumstances an
- HTTP/1.1 cache MUST obey the must-revalidate directive; in
- particular, if the cache cannot reach the origin server for any
- reason, it MUST generate a 504 (Gateway Timeout) response.
-
- Servers SHOULD send the must-revalidate directive if and only if
- failure to revalidate a request on the entity could result in
- incorrect operation, such as a silently unexecuted financial
- transaction. Recipients MUST NOT take any automated action that
- violates this directive, and MUST NOT automatically provide an
- unvalidated copy of the entity if revalidation fails.
-
- Although this is not recommended, user agents operating under
- severe connectivity constraints MAY violate this directive but, if
- so, MUST explicitly warn the user that an unvalidated response has
- been provided. The warning MUST be provided on each unvalidated
- access, and SHOULD require explicit user confirmation.
-
- proxy-revalidate
- The proxy-revalidate directive has the same meaning as the must-
- revalidate directive, except that it does not apply to non-shared
- user agent caches. It can be used on a response to an
- authenticated request to permit the user's cache to store and
- later return the response without needing to revalidate it (since
- it has already been authenticated once by that user), while still
- requiring proxies that service many users to revalidate each time
- (in order to make sure that each user has been authenticated).
- Note that such authenticated responses also need the public cache
- control directive in order to allow them to be cached at all.
-
-14.9.5 No-Transform Directive
-
- no-transform
- Implementors of intermediate caches (proxies) have found it useful
- to convert the media type of certain entity bodies. A non-
- transparent proxy might, for example, convert between image
- formats in order to save cache space or to reduce the amount of
- traffic on a slow link.
-
- Serious operational problems occur, however, when these
- transformations are applied to entity bodies intended for certain
- kinds of applications. For example, applications for medical
-
-
-
-Fielding, et al. Standards Track [Page 115]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- imaging, scientific data analysis and those using end-to-end
- authentication, all depend on receiving an entity body that is bit
- for bit identical to the original entity-body.
-
- Therefore, if a message includes the no-transform directive, an
- intermediate cache or proxy MUST NOT change those headers that are
- listed in section 13.5.2 as being subject to the no-transform
- directive. This implies that the cache or proxy MUST NOT change
- any aspect of the entity-body that is specified by these headers,
- including the value of the entity-body itself.
-
-14.9.6 Cache Control Extensions
-
- The Cache-Control header field can be extended through the use of one
- or more cache-extension tokens, each with an optional assigned value.
- Informational extensions (those which do not require a change in
- cache behavior) MAY be added without changing the semantics of other
- directives. Behavioral extensions are designed to work by acting as
- modifiers to the existing base of cache directives. Both the new
- directive and the standard directive are supplied, such that
- applications which do not understand the new directive will default
- to the behavior specified by the standard directive, and those that
- understand the new directive will recognize it as modifying the
- requirements associated with the standard directive. In this way,
- extensions to the cache-control directives can be made without
- requiring changes to the base protocol.
-
- This extension mechanism depends on an HTTP cache obeying all of the
- cache-control directives defined for its native HTTP-version, obeying
- certain extensions, and ignoring all directives that it does not
- understand.
-
- For example, consider a hypothetical new response directive called
- community which acts as a modifier to the private directive. We
- define this new directive to mean that, in addition to any non-shared
- cache, any cache which is shared only by members of the community
- named within its value may cache the response. An origin server
- wishing to allow the UCI community to use an otherwise private
- response in their shared cache(s) could do so by including
-
- Cache-Control: private, community="UCI"
-
- A cache seeing this header field will act correctly even if the cache
- does not understand the community cache-extension, since it will also
- see and understand the private directive and thus default to the safe
- behavior.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 116]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Unrecognized cache-directives MUST be ignored; it is assumed that any
- cache-directive likely to be unrecognized by an HTTP/1.1 cache will
- be combined with standard directives (or the response's default
- cacheability) such that the cache behavior will remain minimally
- correct even if the cache does not understand the extension(s).
-
-14.10 Connection
-
- The Connection general-header field allows the sender to specify
- options that are desired for that particular connection and MUST NOT
- be communicated by proxies over further connections.
-
- The Connection header has the following grammar:
-
- Connection = "Connection" ":" 1#(connection-token)
- connection-token = token
-
- HTTP/1.1 proxies MUST parse the Connection header field before a
- message is forwarded and, for each connection-token in this field,
- remove any header field(s) from the message with the same name as the
- connection-token. Connection options are signaled by the presence of
- a connection-token in the Connection header field, not by any
- corresponding additional header field(s), since the additional header
- field may not be sent if there are no parameters associated with that
- connection option.
-
- Message headers listed in the Connection header MUST NOT include
- end-to-end headers, such as Cache-Control.
-
- HTTP/1.1 defines the "close" connection option for the sender to
- signal that the connection will be closed after completion of the
- response. For example,
-
- Connection: close
-
- in either the request or the response header fields indicates that
- the connection SHOULD NOT be considered `persistent' (section 8.1)
- after the current request/response is complete.
-
- HTTP/1.1 applications that do not support persistent connections MUST
- include the "close" connection option in every message.
-
- A system receiving an HTTP/1.0 (or lower-version) message that
- includes a Connection header MUST, for each connection-token in this
- field, remove and ignore any header field(s) from the message with
- the same name as the connection-token. This protects against mistaken
- forwarding of such header fields by pre-HTTP/1.1 proxies. See section
- 19.6.2.
-
-
-
-Fielding, et al. Standards Track [Page 117]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.11 Content-Encoding
-
- The Content-Encoding entity-header field is used as a modifier to the
- media-type. When present, its value indicates what additional content
- codings have been applied to the entity-body, and thus what decoding
- mechanisms must be applied in order to obtain the media-type
- referenced by the Content-Type header field. Content-Encoding is
- primarily used to allow a document to be compressed without losing
- the identity of its underlying media type.
-
- Content-Encoding = "Content-Encoding" ":" 1#content-coding
-
- Content codings are defined in section 3.5. An example of its use is
-
- Content-Encoding: gzip
-
- The content-coding is a characteristic of the entity identified by
- the Request-URI. Typically, the entity-body is stored with this
- encoding and is only decoded before rendering or analogous usage.
- However, a non-transparent proxy MAY modify the content-coding if the
- new coding is known to be acceptable to the recipient, unless the
- "no-transform" cache-control directive is present in the message.
-
- If the content-coding of an entity is not "identity", then the
- response MUST include a Content-Encoding entity-header (section
- 14.11) that lists the non-identity content-coding(s) used.
-
- If the content-coding of an entity in a request message is not
- acceptable to the origin server, the server SHOULD respond with a
- status code of 415 (Unsupported Media Type).
-
- If multiple encodings have been applied to an entity, the content
- codings MUST be listed in the order in which they were applied.
- Additional information about the encoding parameters MAY be provided
- by other entity-header fields not defined by this specification.
-
-14.12 Content-Language
-
- The Content-Language entity-header field describes the natural
- language(s) of the intended audience for the enclosed entity. Note
- that this might not be equivalent to all the languages used within
- the entity-body.
-
- Content-Language = "Content-Language" ":" 1#language-tag
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 118]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Language tags are defined in section 3.10. The primary purpose of
- Content-Language is to allow a user to identify and differentiate
- entities according to the user's own preferred language. Thus, if the
- body content is intended only for a Danish-literate audience, the
- appropriate field is
-
- Content-Language: da
-
- If no Content-Language is specified, the default is that the content
- is intended for all language audiences. This might mean that the
- sender does not consider it to be specific to any natural language,
- or that the sender does not know for which language it is intended.
-
- Multiple languages MAY be listed for content that is intended for
- multiple audiences. For example, a rendition of the "Treaty of
- Waitangi," presented simultaneously in the original Maori and English
- versions, would call for
-
- Content-Language: mi, en
-
- However, just because multiple languages are present within an entity
- does not mean that it is intended for multiple linguistic audiences.
- An example would be a beginner's language primer, such as "A First
- Lesson in Latin," which is clearly intended to be used by an
- English-literate audience. In this case, the Content-Language would
- properly only include "en".
-
- Content-Language MAY be applied to any media type -- it is not
- limited to textual documents.
-
-14.13 Content-Length
-
- The Content-Length entity-header field indicates the size of the
- entity-body, in decimal number of OCTETs, sent to the recipient or,
- in the case of the HEAD method, the size of the entity-body that
- would have been sent had the request been a GET.
-
- Content-Length = "Content-Length" ":" 1*DIGIT
-
- An example is
-
- Content-Length: 3495
-
- Applications SHOULD use this field to indicate the transfer-length of
- the message-body, unless this is prohibited by the rules in section
- 4.4.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 119]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Any Content-Length greater than or equal to zero is a valid value.
- Section 4.4 describes how to determine the length of a message-body
- if a Content-Length is not given.
-
- Note that the meaning of this field is significantly different from
- the corresponding definition in MIME, where it is an optional field
- used within the "message/external-body" content-type. In HTTP, it
- SHOULD be sent whenever the message's length can be determined prior
- to being transferred, unless this is prohibited by the rules in
- section 4.4.
-
-14.14 Content-Location
-
- The Content-Location entity-header field MAY be used to supply the
- resource location for the entity enclosed in the message when that
- entity is accessible from a location separate from the requested
- resource's URI. A server SHOULD provide a Content-Location for the
- variant corresponding to the response entity; especially in the case
- where a resource has multiple entities associated with it, and those
- entities actually have separate locations by which they might be
- individually accessed, the server SHOULD provide a Content-Location
- for the particular variant which is returned.
-
- Content-Location = "Content-Location" ":"
- ( absoluteURI | relativeURI )
-
- The value of Content-Location also defines the base URI for the
- entity.
-
- The Content-Location value is not a replacement for the original
- requested URI; it is only a statement of the location of the resource
- corresponding to this particular entity at the time of the request.
- Future requests MAY specify the Content-Location URI as the request-
- URI if the desire is to identify the source of that particular
- entity.
-
- A cache cannot assume that an entity with a Content-Location
- different from the URI used to retrieve it can be used to respond to
- later requests on that Content-Location URI. However, the Content-
- Location can be used to differentiate between multiple entities
- retrieved from a single requested resource, as described in section
- 13.6.
-
- If the Content-Location is a relative URI, the relative URI is
- interpreted relative to the Request-URI.
-
- The meaning of the Content-Location header in PUT or POST requests is
- undefined; servers are free to ignore it in those cases.
-
-
-
-Fielding, et al. Standards Track [Page 120]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.15 Content-MD5
-
- The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
- an MD5 digest of the entity-body for the purpose of providing an
- end-to-end message integrity check (MIC) of the entity-body. (Note: a
- MIC is good for detecting accidental modification of the entity-body
- in transit, but is not proof against malicious attacks.)
-
- Content-MD5 = "Content-MD5" ":" md5-digest
- md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
-
- The Content-MD5 header field MAY be generated by an origin server or
- client to function as an integrity check of the entity-body. Only
- origin servers or clients MAY generate the Content-MD5 header field;
- proxies and gateways MUST NOT generate it, as this would defeat its
- value as an end-to-end integrity check. Any recipient of the entity-
- body, including gateways and proxies, MAY check that the digest value
- in this header field matches that of the entity-body as received.
-
- The MD5 digest is computed based on the content of the entity-body,
- including any content-coding that has been applied, but not including
- any transfer-encoding applied to the message-body. If the message is
- received with a transfer-encoding, that encoding MUST be removed
- prior to checking the Content-MD5 value against the received entity.
-
- This has the result that the digest is computed on the octets of the
- entity-body exactly as, and in the order that, they would be sent if
- no transfer-encoding were being applied.
-
- HTTP extends RFC 1864 to permit the digest to be computed for MIME
- composite media-types (e.g., multipart/* and message/rfc822), but
- this does not change how the digest is computed as defined in the
- preceding paragraph.
-
- There are several consequences of this. The entity-body for composite
- types MAY contain many body-parts, each with its own MIME and HTTP
- headers (including Content-MD5, Content-Transfer-Encoding, and
- Content-Encoding headers). If a body-part has a Content-Transfer-
- Encoding or Content-Encoding header, it is assumed that the content
- of the body-part has had the encoding applied, and the body-part is
- included in the Content-MD5 digest as is -- i.e., after the
- application. The Transfer-Encoding header field is not allowed within
- body-parts.
-
- Conversion of all line breaks to CRLF MUST NOT be done before
- computing or checking the digest: the line break convention used in
- the text actually transmitted MUST be left unaltered when computing
- the digest.
-
-
-
-Fielding, et al. Standards Track [Page 121]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Note: while the definition of Content-MD5 is exactly the same for
- HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
- in which the application of Content-MD5 to HTTP entity-bodies
- differs from its application to MIME entity-bodies. One is that
- HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
- does use Transfer-Encoding and Content-Encoding. Another is that
- HTTP more frequently uses binary content types than MIME, so it is
- worth noting that, in such cases, the byte order used to compute
- the digest is the transmission byte order defined for the type.
- Lastly, HTTP allows transmission of text types with any of several
- line break conventions and not just the canonical form using CRLF.
-
-14.16 Content-Range
-
- The Content-Range entity-header is sent with a partial entity-body to
- specify where in the full entity-body the partial body should be
- applied. Range units are defined in section 3.12.
-
- Content-Range = "Content-Range" ":" content-range-spec
-
- content-range-spec = byte-content-range-spec
- byte-content-range-spec = bytes-unit SP
- byte-range-resp-spec "/"
- ( instance-length | "*" )
-
- byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
- | "*"
- instance-length = 1*DIGIT
-
- The header SHOULD indicate the total length of the full entity-body,
- unless this length is unknown or difficult to determine. The asterisk
- "*" character means that the instance-length is unknown at the time
- when the response was generated.
-
- Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
- range-resp-spec MUST only specify one range, and MUST contain
- absolute byte positions for both the first and last byte of the
- range.
-
- A byte-content-range-spec with a byte-range-resp-spec whose last-
- byte-pos value is less than its first-byte-pos value, or whose
- instance-length value is less than or equal to its last-byte-pos
- value, is invalid. The recipient of an invalid byte-content-range-
- spec MUST ignore it and any content transferred along with it.
-
- A server sending a response with status code 416 (Requested range not
- satisfiable) SHOULD include a Content-Range field with a byte-range-
- resp-spec of "*". The instance-length specifies the current length of
-
-
-
-Fielding, et al. Standards Track [Page 122]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- the selected resource. A response with status code 206 (Partial
- Content) MUST NOT include a Content-Range field with a byte-range-
- resp-spec of "*".
-
- Examples of byte-content-range-spec values, assuming that the entity
- contains a total of 1234 bytes:
-
- . The first 500 bytes:
- bytes 0-499/1234
-
- . The second 500 bytes:
- bytes 500-999/1234
-
- . All except for the first 500 bytes:
- bytes 500-1233/1234
-
- . The last 500 bytes:
- bytes 734-1233/1234
-
- When an HTTP message includes the content of a single range (for
- example, a response to a request for a single range, or to a request
- for a set of ranges that overlap without any holes), this content is
- transmitted with a Content-Range header, and a Content-Length header
- showing the number of bytes actually transferred. For example,
-
- HTTP/1.1 206 Partial content
- Date: Wed, 15 Nov 1995 06:25:24 GMT
- Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
- Content-Range: bytes 21010-47021/47022
- Content-Length: 26012
- Content-Type: image/gif
-
- When an HTTP message includes the content of multiple ranges (for
- example, a response to a request for multiple non-overlapping
- ranges), these are transmitted as a multipart message. The multipart
- media type used for this purpose is "multipart/byteranges" as defined
- in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
-
- A response to a request for a single range MUST NOT be sent using the
- multipart/byteranges media type. A response to a request for
- multiple ranges, whose result is a single range, MAY be sent as a
- multipart/byteranges media type with one part. A client that cannot
- decode a multipart/byteranges message MUST NOT ask for multiple
- byte-ranges in a single request.
-
- When a client requests multiple byte-ranges in one request, the
- server SHOULD return them in the order that they appeared in the
- request.
-
-
-
-Fielding, et al. Standards Track [Page 123]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If the server ignores a byte-range-spec because it is syntactically
- invalid, the server SHOULD treat the request as if the invalid Range
- header field did not exist. (Normally, this means return a 200
- response containing the full entity).
-
- If the server receives a request (other than one including an If-
- Range request-header field) with an unsatisfiable Range request-
- header field (that is, all of whose byte-range-spec values have a
- first-byte-pos value greater than the current length of the selected
- resource), it SHOULD return a response code of 416 (Requested range
- not satisfiable) (section 10.4.17).
-
- Note: clients cannot depend on servers to send a 416 (Requested
- range not satisfiable) response instead of a 200 (OK) response for
- an unsatisfiable Range request-header, since not all servers
- implement this request-header.
-
-14.17 Content-Type
-
- The Content-Type entity-header field indicates the media type of the
- entity-body sent to the recipient or, in the case of the HEAD method,
- the media type that would have been sent had the request been a GET.
-
- Content-Type = "Content-Type" ":" media-type
-
- Media types are defined in section 3.7. An example of the field is
-
- Content-Type: text/html; charset=ISO-8859-4
-
- Further discussion of methods for identifying the media type of an
- entity is provided in section 7.2.1.
-
-14.18 Date
-
- The Date general-header field represents the date and time at which
- the message was originated, having the same semantics as orig-date in
- RFC 822. The field value is an HTTP-date, as described in section
- 3.3.1; it MUST be sent in RFC 1123 [8]-date format.
-
- Date = "Date" ":" HTTP-date
-
- An example is
-
- Date: Tue, 15 Nov 1994 08:12:31 GMT
-
- Origin servers MUST include a Date header field in all responses,
- except in these cases:
-
-
-
-
-Fielding, et al. Standards Track [Page 124]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 1. If the response status code is 100 (Continue) or 101 (Switching
- Protocols), the response MAY include a Date header field, at
- the server's option.
-
- 2. If the response status code conveys a server error, e.g. 500
- (Internal Server Error) or 503 (Service Unavailable), and it is
- inconvenient or impossible to generate a valid Date.
-
- 3. If the server does not have a clock that can provide a
- reasonable approximation of the current time, its responses
- MUST NOT include a Date header field. In this case, the rules
- in section 14.18.1 MUST be followed.
-
- A received message that does not have a Date header field MUST be
- assigned one by the recipient if the message will be cached by that
- recipient or gatewayed via a protocol which requires a Date. An HTTP
- implementation without a clock MUST NOT cache responses without
- revalidating them on every use. An HTTP cache, especially a shared
- cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
- clock with a reliable external standard.
-
- Clients SHOULD only send a Date header field in messages that include
- an entity-body, as in the case of the PUT and POST requests, and even
- then it is optional. A client without a clock MUST NOT send a Date
- header field in a request.
-
- The HTTP-date sent in a Date header SHOULD NOT represent a date and
- time subsequent to the generation of the message. It SHOULD represent
- the best available approximation of the date and time of message
- generation, unless the implementation has no means of generating a
- reasonably accurate date and time. In theory, the date ought to
- represent the moment just before the entity is generated. In
- practice, the date can be generated at any time during the message
- origination without affecting its semantic value.
-
-14.18.1 Clockless Origin Server Operation
-
- Some origin server implementations might not have a clock available.
- An origin server without a clock MUST NOT assign Expires or Last-
- Modified values to a response, unless these values were associated
- with the resource by a system or user with a reliable clock. It MAY
- assign an Expires value that is known, at or before server
- configuration time, to be in the past (this allows "pre-expiration"
- of responses without storing separate Expires values for each
- resource).
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 125]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.19 ETag
-
- The ETag response-header field provides the current value of the
- entity tag for the requested variant. The headers used with entity
- tags are described in sections 14.24, 14.26 and 14.44. The entity tag
- MAY be used for comparison with other entities from the same resource
- (see section 13.3.3).
-
- ETag = "ETag" ":" entity-tag
-
- Examples:
-
- ETag: "xyzzy"
- ETag: W/"xyzzy"
- ETag: ""
-
-14.20 Expect
-
- The Expect request-header field is used to indicate that particular
- server behaviors are required by the client.
-
- Expect = "Expect" ":" 1#expectation
-
- expectation = "100-continue" | expectation-extension
- expectation-extension = token [ "=" ( token | quoted-string )
- *expect-params ]
- expect-params = ";" token [ "=" ( token | quoted-string ) ]
-
-
- A server that does not understand or is unable to comply with any of
- the expectation values in the Expect field of a request MUST respond
- with appropriate error status. The server MUST respond with a 417
- (Expectation Failed) status if any of the expectations cannot be met
- or, if there are other problems with the request, some other 4xx
- status.
-
- This header field is defined with extensible syntax to allow for
- future extensions. If a server receives a request containing an
- Expect field that includes an expectation-extension that it does not
- support, it MUST respond with a 417 (Expectation Failed) status.
-
- Comparison of expectation values is case-insensitive for unquoted
- tokens (including the 100-continue token), and is case-sensitive for
- quoted-string expectation-extensions.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 126]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
- return a 417 (Expectation Failed) status if it receives a request
- with an expectation that it cannot meet. However, the Expect
- request-header itself is end-to-end; it MUST be forwarded if the
- request is forwarded.
-
- Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
- Expect header.
-
- See section 8.2.3 for the use of the 100 (continue) status.
-
-14.21 Expires
-
- The Expires entity-header field gives the date/time after which the
- response is considered stale. A stale cache entry may not normally be
- returned by a cache (either a proxy cache or a user agent cache)
- unless it is first validated with the origin server (or with an
- intermediate cache that has a fresh copy of the entity). See section
- 13.2 for further discussion of the expiration model.
-
- The presence of an Expires field does not imply that the original
- resource will change or cease to exist at, before, or after that
- time.
-
- The format is an absolute date and time as defined by HTTP-date in
- section 3.3.1; it MUST be in RFC 1123 date format:
-
- Expires = "Expires" ":" HTTP-date
-
- An example of its use is
-
- Expires: Thu, 01 Dec 1994 16:00:00 GMT
-
- Note: if a response includes a Cache-Control field with the max-
- age directive (see section 14.9.3), that directive overrides the
- Expires field.
-
- HTTP/1.1 clients and caches MUST treat other invalid date formats,
- especially including the value "0", as in the past (i.e., "already
- expired").
-
- To mark a response as "already expired," an origin server sends an
- Expires date that is equal to the Date header value. (See the rules
- for expiration calculations in section 13.2.4.)
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 127]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- To mark a response as "never expires," an origin server sends an
- Expires date approximately one year from the time the response is
- sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
- year in the future.
-
- The presence of an Expires header field with a date value of some
- time in the future on a response that otherwise would by default be
- non-cacheable indicates that the response is cacheable, unless
- indicated otherwise by a Cache-Control header field (section 14.9).
-
-14.22 From
-
- The From request-header field, if given, SHOULD contain an Internet
- e-mail address for the human user who controls the requesting user
- agent. The address SHOULD be machine-usable, as defined by "mailbox"
- in RFC 822 [9] as updated by RFC 1123 [8]:
-
- From = "From" ":" mailbox
-
- An example is:
-
- From: webmaster@w3.org
-
- This header field MAY be used for logging purposes and as a means for
- identifying the source of invalid or unwanted requests. It SHOULD NOT
- be used as an insecure form of access protection. The interpretation
- of this field is that the request is being performed on behalf of the
- person given, who accepts responsibility for the method performed. In
- particular, robot agents SHOULD include this header so that the
- person responsible for running the robot can be contacted if problems
- occur on the receiving end.
-
- The Internet e-mail address in this field MAY be separate from the
- Internet host which issued the request. For example, when a request
- is passed through a proxy the original issuer's address SHOULD be
- used.
-
- The client SHOULD NOT send the From header field without the user's
- approval, as it might conflict with the user's privacy interests or
- their site's security policy. It is strongly recommended that the
- user be able to disable, enable, and modify the value of this field
- at any time prior to a request.
-
-14.23 Host
-
- The Host request-header field specifies the Internet host and port
- number of the resource being requested, as obtained from the original
- URI given by the user or referring resource (generally an HTTP URL,
-
-
-
-Fielding, et al. Standards Track [Page 128]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- as described in section 3.2.2). The Host field value MUST represent
- the naming authority of the origin server or gateway given by the
- original URL. This allows the origin server or gateway to
- differentiate between internally-ambiguous URLs, such as the root "/"
- URL of a server for multiple host names on a single IP address.
-
- Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
-
- A "host" without any trailing port information implies the default
- port for the service requested (e.g., "80" for an HTTP URL). For
- example, a request on the origin server for
- <http://www.w3.org/pub/WWW/> would properly include:
-
- GET /pub/WWW/ HTTP/1.1
- Host: www.w3.org
-
- A client MUST include a Host header field in all HTTP/1.1 request
- messages . If the requested URI does not include an Internet host
- name for the service being requested, then the Host header field MUST
- be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
- request message it forwards does contain an appropriate Host header
- field that identifies the service being requested by the proxy. All
- Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
- status code to any HTTP/1.1 request message which lacks a Host header
- field.
-
- See sections 5.2 and 19.6.1.1 for other requirements relating to
- Host.
-
-14.24 If-Match
-
- The If-Match request-header field is used with a method to make it
- conditional. A client that has one or more entities previously
- obtained from the resource can verify that one of those entities is
- current by including a list of their associated entity tags in the
- If-Match header field. Entity tags are defined in section 3.11. The
- purpose of this feature is to allow efficient updates of cached
- information with a minimum amount of transaction overhead. It is also
- used, on updating requests, to prevent inadvertent modification of
- the wrong version of a resource. As a special case, the value "*"
- matches any current entity of the resource.
-
- If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
-
- If any of the entity tags match the entity tag of the entity that
- would have been returned in the response to a similar GET request
- (without the If-Match header) on that resource, or if "*" is given
-
-
-
-
-Fielding, et al. Standards Track [Page 129]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- and any current entity exists for that resource, then the server MAY
- perform the requested method as if the If-Match header field did not
- exist.
-
- A server MUST use the strong comparison function (see section 13.3.3)
- to compare the entity tags in If-Match.
-
- If none of the entity tags match, or if "*" is given and no current
- entity exists, the server MUST NOT perform the requested method, and
- MUST return a 412 (Precondition Failed) response. This behavior is
- most useful when the client wants to prevent an updating method, such
- as PUT, from modifying a resource that has changed since the client
- last retrieved it.
-
- If the request would, without the If-Match header field, result in
- anything other than a 2xx or 412 status, then the If-Match header
- MUST be ignored.
-
- The meaning of "If-Match: *" is that the method SHOULD be performed
- if the representation selected by the origin server (or by a cache,
- possibly using the Vary mechanism, see section 14.44) exists, and
- MUST NOT be performed if the representation does not exist.
-
- A request intended to update a resource (e.g., a PUT) MAY include an
- If-Match header field to signal that the request method MUST NOT be
- applied if the entity corresponding to the If-Match value (a single
- entity tag) is no longer a representation of that resource. This
- allows the user to indicate that they do not wish the request to be
- successful if the resource has been changed without their knowledge.
- Examples:
-
- If-Match: "xyzzy"
- If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
- If-Match: *
-
- The result of a request having both an If-Match header field and
- either an If-None-Match or an If-Modified-Since header fields is
- undefined by this specification.
-
-14.25 If-Modified-Since
-
- The If-Modified-Since request-header field is used with a method to
- make it conditional: if the requested variant has not been modified
- since the time specified in this field, an entity will not be
- returned from the server; instead, a 304 (not modified) response will
- be returned without any message-body.
-
- If-Modified-Since = "If-Modified-Since" ":" HTTP-date
-
-
-
-Fielding, et al. Standards Track [Page 130]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- An example of the field is:
-
- If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-
- A GET method with an If-Modified-Since header and no Range header
- requests that the identified entity be transferred only if it has
- been modified since the date given by the If-Modified-Since header.
- The algorithm for determining this includes the following cases:
-
- a) If the request would normally result in anything other than a
- 200 (OK) status, or if the passed If-Modified-Since date is
- invalid, the response is exactly the same as for a normal GET.
- A date which is later than the server's current time is
- invalid.
-
- b) If the variant has been modified since the If-Modified-Since
- date, the response is exactly the same as for a normal GET.
-
- c) If the variant has not been modified since a valid If-
- Modified-Since date, the server SHOULD return a 304 (Not
- Modified) response.
-
- The purpose of this feature is to allow efficient updates of cached
- information with a minimum amount of transaction overhead.
-
- Note: The Range request-header field modifies the meaning of If-
- Modified-Since; see section 14.35 for full details.
-
- Note: If-Modified-Since times are interpreted by the server, whose
- clock might not be synchronized with the client.
-
- Note: When handling an If-Modified-Since header field, some
- servers will use an exact date comparison function, rather than a
- less-than function, for deciding whether to send a 304 (Not
- Modified) response. To get best results when sending an If-
- Modified-Since header field for cache validation, clients are
- advised to use the exact date string received in a previous Last-
- Modified header field whenever possible.
-
- Note: If a client uses an arbitrary date in the If-Modified-Since
- header instead of a date taken from the Last-Modified header for
- the same request, the client should be aware of the fact that this
- date is interpreted in the server's understanding of time. The
- client should consider unsynchronized clocks and rounding problems
- due to the different encodings of time between the client and
- server. This includes the possibility of race conditions if the
- document has changed between the time it was first requested and
- the If-Modified-Since date of a subsequent request, and the
-
-
-
-Fielding, et al. Standards Track [Page 131]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- possibility of clock-skew-related problems if the If-Modified-
- Since date is derived from the client's clock without correction
- to the server's clock. Corrections for different time bases
- between client and server are at best approximate due to network
- latency.
-
- The result of a request having both an If-Modified-Since header field
- and either an If-Match or an If-Unmodified-Since header fields is
- undefined by this specification.
-
-14.26 If-None-Match
-
- The If-None-Match request-header field is used with a method to make
- it conditional. A client that has one or more entities previously
- obtained from the resource can verify that none of those entities is
- current by including a list of their associated entity tags in the
- If-None-Match header field. The purpose of this feature is to allow
- efficient updates of cached information with a minimum amount of
- transaction overhead. It is also used to prevent a method (e.g. PUT)
- from inadvertently modifying an existing resource when the client
- believes that the resource does not exist.
-
- As a special case, the value "*" matches any current entity of the
- resource.
-
- If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
-
- If any of the entity tags match the entity tag of the entity that
- would have been returned in the response to a similar GET request
- (without the If-None-Match header) on that resource, or if "*" is
- given and any current entity exists for that resource, then the
- server MUST NOT perform the requested method, unless required to do
- so because the resource's modification date fails to match that
- supplied in an If-Modified-Since header field in the request.
- Instead, if the request method was GET or HEAD, the server SHOULD
- respond with a 304 (Not Modified) response, including the cache-
- related header fields (particularly ETag) of one of the entities that
- matched. For all other request methods, the server MUST respond with
- a status of 412 (Precondition Failed).
-
- See section 13.3.3 for rules on how to determine if two entities tags
- match. The weak comparison function can only be used with GET or HEAD
- requests.
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 132]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If none of the entity tags match, then the server MAY perform the
- requested method as if the If-None-Match header field did not exist,
- but MUST also ignore any If-Modified-Since header field(s) in the
- request. That is, if no entity tags match, then the server MUST NOT
- return a 304 (Not Modified) response.
-
- If the request would, without the If-None-Match header field, result
- in anything other than a 2xx or 304 status, then the If-None-Match
- header MUST be ignored. (See section 13.3.4 for a discussion of
- server behavior when both If-Modified-Since and If-None-Match appear
- in the same request.)
-
- The meaning of "If-None-Match: *" is that the method MUST NOT be
- performed if the representation selected by the origin server (or by
- a cache, possibly using the Vary mechanism, see section 14.44)
- exists, and SHOULD be performed if the representation does not exist.
- This feature is intended to be useful in preventing races between PUT
- operations.
-
- Examples:
-
- If-None-Match: "xyzzy"
- If-None-Match: W/"xyzzy"
- If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
- If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
- If-None-Match: *
-
- The result of a request having both an If-None-Match header field and
- either an If-Match or an If-Unmodified-Since header fields is
- undefined by this specification.
-
-14.27 If-Range
-
- If a client has a partial copy of an entity in its cache, and wishes
- to have an up-to-date copy of the entire entity in its cache, it
- could use the Range request-header with a conditional GET (using
- either or both of If-Unmodified-Since and If-Match.) However, if the
- condition fails because the entity has been modified, the client
- would then have to make a second request to obtain the entire current
- entity-body.
-
- The If-Range header allows a client to "short-circuit" the second
- request. Informally, its meaning is `if the entity is unchanged, send
- me the part(s) that I am missing; otherwise, send me the entire new
- entity'.
-
- If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
-
-
-
-
-Fielding, et al. Standards Track [Page 133]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If the client has no entity tag for an entity, but does have a Last-
- Modified date, it MAY use that date in an If-Range header. (The
- server can distinguish between a valid HTTP-date and any form of
- entity-tag by examining no more than two characters.) The If-Range
- header SHOULD only be used together with a Range header, and MUST be
- ignored if the request does not include a Range header, or if the
- server does not support the sub-range operation.
-
- If the entity tag given in the If-Range header matches the current
- entity tag for the entity, then the server SHOULD provide the
- specified sub-range of the entity using a 206 (Partial content)
- response. If the entity tag does not match, then the server SHOULD
- return the entire entity using a 200 (OK) response.
-
-14.28 If-Unmodified-Since
-
- The If-Unmodified-Since request-header field is used with a method to
- make it conditional. If the requested resource has not been modified
- since the time specified in this field, the server SHOULD perform the
- requested operation as if the If-Unmodified-Since header were not
- present.
-
- If the requested variant has been modified since the specified time,
- the server MUST NOT perform the requested operation, and MUST return
- a 412 (Precondition Failed).
-
- If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
-
- An example of the field is:
-
- If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-
- If the request normally (i.e., without the If-Unmodified-Since
- header) would result in anything other than a 2xx or 412 status, the
- If-Unmodified-Since header SHOULD be ignored.
-
- If the specified date is invalid, the header is ignored.
-
- The result of a request having both an If-Unmodified-Since header
- field and either an If-None-Match or an If-Modified-Since header
- fields is undefined by this specification.
-
-14.29 Last-Modified
-
- The Last-Modified entity-header field indicates the date and time at
- which the origin server believes the variant was last modified.
-
- Last-Modified = "Last-Modified" ":" HTTP-date
-
-
-
-Fielding, et al. Standards Track [Page 134]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- An example of its use is
-
- Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
-
- The exact meaning of this header field depends on the implementation
- of the origin server and the nature of the original resource. For
- files, it may be just the file system last-modified time. For
- entities with dynamically included parts, it may be the most recent
- of the set of last-modify times for its component parts. For database
- gateways, it may be the last-update time stamp of the record. For
- virtual objects, it may be the last time the internal state changed.
-
- An origin server MUST NOT send a Last-Modified date which is later
- than the server's time of message origination. In such cases, where
- the resource's last modification would indicate some time in the
- future, the server MUST replace that date with the message
- origination date.
-
- An origin server SHOULD obtain the Last-Modified value of the entity
- as close as possible to the time that it generates the Date value of
- its response. This allows a recipient to make an accurate assessment
- of the entity's modification time, especially if the entity changes
- near the time that the response is generated.
-
- HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
-
-14.30 Location
-
- The Location response-header field is used to redirect the recipient
- to a location other than the Request-URI for completion of the
- request or identification of a new resource. For 201 (Created)
- responses, the Location is that of the new resource which was created
- by the request. For 3xx responses, the location SHOULD indicate the
- server's preferred URI for automatic redirection to the resource. The
- field value consists of a single absolute URI.
-
- Location = "Location" ":" absoluteURI
-
- An example is:
-
- Location: http://www.w3.org/pub/WWW/People.html
-
- Note: The Content-Location header field (section 14.14) differs
- from Location in that the Content-Location identifies the original
- location of the entity enclosed in the request. It is therefore
- possible for a response to contain header fields for both Location
- and Content-Location. Also see section 13.10 for cache
- requirements of some methods.
-
-
-
-Fielding, et al. Standards Track [Page 135]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.31 Max-Forwards
-
- The Max-Forwards request-header field provides a mechanism with the
- TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
- number of proxies or gateways that can forward the request to the
- next inbound server. This can be useful when the client is attempting
- to trace a request chain which appears to be failing or looping in
- mid-chain.
-
- Max-Forwards = "Max-Forwards" ":" 1*DIGIT
-
- The Max-Forwards value is a decimal integer indicating the remaining
- number of times this request message may be forwarded.
-
- Each proxy or gateway recipient of a TRACE or OPTIONS request
- containing a Max-Forwards header field MUST check and update its
- value prior to forwarding the request. If the received value is zero
- (0), the recipient MUST NOT forward the request; instead, it MUST
- respond as the final recipient. If the received Max-Forwards value is
- greater than zero, then the forwarded message MUST contain an updated
- Max-Forwards field with a value decremented by one (1).
-
- The Max-Forwards header field MAY be ignored for all other methods
- defined by this specification and for any extension methods for which
- it is not explicitly referred to as part of that method definition.
-
-14.32 Pragma
-
- The Pragma general-header field is used to include implementation-
- specific directives that might apply to any recipient along the
- request/response chain. All pragma directives specify optional
- behavior from the viewpoint of the protocol; however, some systems
- MAY require that behavior be consistent with the directives.
-
- Pragma = "Pragma" ":" 1#pragma-directive
- pragma-directive = "no-cache" | extension-pragma
- extension-pragma = token [ "=" ( token | quoted-string ) ]
-
- When the no-cache directive is present in a request message, an
- application SHOULD forward the request toward the origin server even
- if it has a cached copy of what is being requested. This pragma
- directive has the same semantics as the no-cache cache-directive (see
- section 14.9) and is defined here for backward compatibility with
- HTTP/1.0. Clients SHOULD include both header fields when a no-cache
- request is sent to a server not known to be HTTP/1.1 compliant.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 136]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Pragma directives MUST be passed through by a proxy or gateway
- application, regardless of their significance to that application,
- since the directives might be applicable to all recipients along the
- request/response chain. It is not possible to specify a pragma for a
- specific recipient; however, any pragma directive not relevant to a
- recipient SHOULD be ignored by that recipient.
-
- HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
- sent "Cache-Control: no-cache". No new Pragma directives will be
- defined in HTTP.
-
- Note: because the meaning of "Pragma: no-cache as a response
- header field is not actually specified, it does not provide a
- reliable replacement for "Cache-Control: no-cache" in a response
-
-14.33 Proxy-Authenticate
-
- The Proxy-Authenticate response-header field MUST be included as part
- of a 407 (Proxy Authentication Required) response. The field value
- consists of a challenge that indicates the authentication scheme and
- parameters applicable to the proxy for this Request-URI.
-
- Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
-
- The HTTP access authentication process is described in "HTTP
- Authentication: Basic and Digest Access Authentication" [43]. Unlike
- WWW-Authenticate, the Proxy-Authenticate header field applies only to
- the current connection and SHOULD NOT be passed on to downstream
- clients. However, an intermediate proxy might need to obtain its own
- credentials by requesting them from the downstream client, which in
- some circumstances will appear as if the proxy is forwarding the
- Proxy-Authenticate header field.
-
-14.34 Proxy-Authorization
-
- The Proxy-Authorization request-header field allows the client to
- identify itself (or its user) to a proxy which requires
- authentication. The Proxy-Authorization field value consists of
- credentials containing the authentication information of the user
- agent for the proxy and/or realm of the resource being requested.
-
- Proxy-Authorization = "Proxy-Authorization" ":" credentials
-
- The HTTP access authentication process is described in "HTTP
- Authentication: Basic and Digest Access Authentication" [43] . Unlike
- Authorization, the Proxy-Authorization header field applies only to
- the next outbound proxy that demanded authentication using the Proxy-
- Authenticate field. When multiple proxies are used in a chain, the
-
-
-
-Fielding, et al. Standards Track [Page 137]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Proxy-Authorization header field is consumed by the first outbound
- proxy that was expecting to receive credentials. A proxy MAY relay
- the credentials from the client request to the next proxy if that is
- the mechanism by which the proxies cooperatively authenticate a given
- request.
-
-14.35 Range
-
-14.35.1 Byte Ranges
-
- Since all HTTP entities are represented in HTTP messages as sequences
- of bytes, the concept of a byte range is meaningful for any HTTP
- entity. (However, not all clients and servers need to support byte-
- range operations.)
-
- Byte range specifications in HTTP apply to the sequence of bytes in
- the entity-body (not necessarily the same as the message-body).
-
- A byte range operation MAY specify a single range of bytes, or a set
- of ranges within a single entity.
-
- ranges-specifier = byte-ranges-specifier
- byte-ranges-specifier = bytes-unit "=" byte-range-set
- byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
- byte-range-spec = first-byte-pos "-" [last-byte-pos]
- first-byte-pos = 1*DIGIT
- last-byte-pos = 1*DIGIT
-
- The first-byte-pos value in a byte-range-spec gives the byte-offset
- of the first byte in a range. The last-byte-pos value gives the
- byte-offset of the last byte in the range; that is, the byte
- positions specified are inclusive. Byte offsets start at zero.
-
- If the last-byte-pos value is present, it MUST be greater than or
- equal to the first-byte-pos in that byte-range-spec, or the byte-
- range-spec is syntactically invalid. The recipient of a byte-range-
- set that includes one or more syntactically invalid byte-range-spec
- values MUST ignore the header field that includes that byte-range-
- set.
-
- If the last-byte-pos value is absent, or if the value is greater than
- or equal to the current length of the entity-body, last-byte-pos is
- taken to be equal to one less than the current length of the entity-
- body in bytes.
-
- By its choice of last-byte-pos, a client can limit the number of
- bytes retrieved without knowing the size of the entity.
-
-
-
-
-Fielding, et al. Standards Track [Page 138]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- suffix-byte-range-spec = "-" suffix-length
- suffix-length = 1*DIGIT
-
- A suffix-byte-range-spec is used to specify the suffix of the
- entity-body, of a length given by the suffix-length value. (That is,
- this form specifies the last N bytes of an entity-body.) If the
- entity is shorter than the specified suffix-length, the entire
- entity-body is used.
-
- If a syntactically valid byte-range-set includes at least one byte-
- range-spec whose first-byte-pos is less than the current length of
- the entity-body, or at least one suffix-byte-range-spec with a non-
- zero suffix-length, then the byte-range-set is satisfiable.
- Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
- is unsatisfiable, the server SHOULD return a response with a status
- of 416 (Requested range not satisfiable). Otherwise, the server
- SHOULD return a response with a status of 206 (Partial Content)
- containing the satisfiable ranges of the entity-body.
-
- Examples of byte-ranges-specifier values (assuming an entity-body of
- length 10000):
-
- - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
- 499
-
- - The second 500 bytes (byte offsets 500-999, inclusive):
- bytes=500-999
-
- - The final 500 bytes (byte offsets 9500-9999, inclusive):
- bytes=-500
-
- - Or bytes=9500-
-
- - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
-
- - Several legal but not canonical specifications of the second 500
- bytes (byte offsets 500-999, inclusive):
- bytes=500-600,601-999
- bytes=500-700,601-999
-
-14.35.2 Range Retrieval Requests
-
- HTTP retrieval requests using conditional or unconditional GET
- methods MAY request one or more sub-ranges of the entity, instead of
- the entire entity, using the Range request header, which applies to
- the entity returned as the result of the request:
-
- Range = "Range" ":" ranges-specifier
-
-
-
-Fielding, et al. Standards Track [Page 139]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- A server MAY ignore the Range header. However, HTTP/1.1 origin
- servers and intermediate caches ought to support byte ranges when
- possible, since Range supports efficient recovery from partially
- failed transfers, and supports efficient partial retrieval of large
- entities.
-
- If the server supports the Range header and the specified range or
- ranges are appropriate for the entity:
-
- - The presence of a Range header in an unconditional GET modifies
- what is returned if the GET is otherwise successful. In other
- words, the response carries a status code of 206 (Partial
- Content) instead of 200 (OK).
-
- - The presence of a Range header in a conditional GET (a request
- using one or both of If-Modified-Since and If-None-Match, or
- one or both of If-Unmodified-Since and If-Match) modifies what
- is returned if the GET is otherwise successful and the
- condition is true. It does not affect the 304 (Not Modified)
- response returned if the conditional is false.
-
- In some cases, it might be more appropriate to use the If-Range
- header (see section 14.27) in addition to the Range header.
-
- If a proxy that supports ranges receives a Range request, forwards
- the request to an inbound server, and receives an entire entity in
- reply, it SHOULD only return the requested range to its client. It
- SHOULD store the entire received response in its cache if that is
- consistent with its cache allocation policies.
-
-14.36 Referer
-
- The Referer[sic] request-header field allows the client to specify,
- for the server's benefit, the address (URI) of the resource from
- which the Request-URI was obtained (the "referrer", although the
- header field is misspelled.) The Referer request-header allows a
- server to generate lists of back-links to resources for interest,
- logging, optimized caching, etc. It also allows obsolete or mistyped
- links to be traced for maintenance. The Referer field MUST NOT be
- sent if the Request-URI was obtained from a source that does not have
- its own URI, such as input from the user keyboard.
-
- Referer = "Referer" ":" ( absoluteURI | relativeURI )
-
- Example:
-
- Referer: http://www.w3.org/hypertext/DataSources/Overview.html
-
-
-
-
-Fielding, et al. Standards Track [Page 140]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If the field value is a relative URI, it SHOULD be interpreted
- relative to the Request-URI. The URI MUST NOT include a fragment. See
- section 15.1.3 for security considerations.
-
-14.37 Retry-After
-
- The Retry-After response-header field can be used with a 503 (Service
- Unavailable) response to indicate how long the service is expected to
- be unavailable to the requesting client. This field MAY also be used
- with any 3xx (Redirection) response to indicate the minimum time the
- user-agent is asked wait before issuing the redirected request. The
- value of this field can be either an HTTP-date or an integer number
- of seconds (in decimal) after the time of the response.
-
- Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
-
- Two examples of its use are
-
- Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
- Retry-After: 120
-
- In the latter example, the delay is 2 minutes.
-
-14.38 Server
-
- The Server response-header field contains information about the
- software used by the origin server to handle the request. The field
- can contain multiple product tokens (section 3.8) and comments
- identifying the server and any significant subproducts. The product
- tokens are listed in order of their significance for identifying the
- application.
-
- Server = "Server" ":" 1*( product | comment )
-
- Example:
-
- Server: CERN/3.0 libwww/2.17
-
- If the response is being forwarded through a proxy, the proxy
- application MUST NOT modify the Server response-header. Instead, it
- SHOULD include a Via field (as described in section 14.45).
-
- Note: Revealing the specific software version of the server might
- allow the server machine to become more vulnerable to attacks
- against software that is known to contain security holes. Server
- implementors are encouraged to make this field a configurable
- option.
-
-
-
-
-Fielding, et al. Standards Track [Page 141]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-14.39 TE
-
- The TE request-header field indicates what extension transfer-codings
- it is willing to accept in the response and whether or not it is
- willing to accept trailer fields in a chunked transfer-coding. Its
- value may consist of the keyword "trailers" and/or a comma-separated
- list of extension transfer-coding names with optional accept
- parameters (as described in section 3.6).
-
- TE = "TE" ":" #( t-codings )
- t-codings = "trailers" | ( transfer-extension [ accept-params ] )
-
- The presence of the keyword "trailers" indicates that the client is
- willing to accept trailer fields in a chunked transfer-coding, as
- defined in section 3.6.1. This keyword is reserved for use with
- transfer-coding values even though it does not itself represent a
- transfer-coding.
-
- Examples of its use are:
-
- TE: deflate
- TE:
- TE: trailers, deflate;q=0.5
-
- The TE header field only applies to the immediate connection.
- Therefore, the keyword MUST be supplied within a Connection header
- field (section 14.10) whenever TE is present in an HTTP/1.1 message.
-
- A server tests whether a transfer-coding is acceptable, according to
- a TE field, using these rules:
-
- 1. The "chunked" transfer-coding is always acceptable. If the
- keyword "trailers" is listed, the client indicates that it is
- willing to accept trailer fields in the chunked response on
- behalf of itself and any downstream clients. The implication is
- that, if given, the client is stating that either all
- downstream clients are willing to accept trailer fields in the
- forwarded response, or that it will attempt to buffer the
- response on behalf of downstream recipients.
-
- Note: HTTP/1.1 does not define any means to limit the size of a
- chunked response such that a client can be assured of buffering
- the entire response.
-
- 2. If the transfer-coding being tested is one of the transfer-
- codings listed in the TE field, then it is acceptable unless it
- is accompanied by a qvalue of 0. (As defined in section 3.9, a
- qvalue of 0 means "not acceptable.")
-
-
-
-Fielding, et al. Standards Track [Page 142]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 3. If multiple transfer-codings are acceptable, then the
- acceptable transfer-coding with the highest non-zero qvalue is
- preferred. The "chunked" transfer-coding always has a qvalue
- of 1.
-
- If the TE field-value is empty or if no TE field is present, the only
- transfer-coding is "chunked". A message with no transfer-coding is
- always acceptable.
-
-14.40 Trailer
-
- The Trailer general field value indicates that the given set of
- header fields is present in the trailer of a message encoded with
- chunked transfer-coding.
-
- Trailer = "Trailer" ":" 1#field-name
-
- An HTTP/1.1 message SHOULD include a Trailer header field in a
- message using chunked transfer-coding with a non-empty trailer. Doing
- so allows the recipient to know which header fields to expect in the
- trailer.
-
- If no Trailer header field is present, the trailer SHOULD NOT include
- any header fields. See section 3.6.1 for restrictions on the use of
- trailer fields in a "chunked" transfer-coding.
-
- Message header fields listed in the Trailer header field MUST NOT
- include the following header fields:
-
- . Transfer-Encoding
-
- . Content-Length
-
- . Trailer
-
-14.41 Transfer-Encoding
-
- The Transfer-Encoding general-header field indicates what (if any)
- type of transformation has been applied to the message body in order
- to safely transfer it between the sender and the recipient. This
- differs from the content-coding in that the transfer-coding is a
- property of the message, not of the entity.
-
- Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
-
- Transfer-codings are defined in section 3.6. An example is:
-
- Transfer-Encoding: chunked
-
-
-
-Fielding, et al. Standards Track [Page 143]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- If multiple encodings have been applied to an entity, the transfer-
- codings MUST be listed in the order in which they were applied.
- Additional information about the encoding parameters MAY be provided
- by other entity-header fields not defined by this specification.
-
- Many older HTTP/1.0 applications do not understand the Transfer-
- Encoding header.
-
-14.42 Upgrade
-
- The Upgrade general-header allows the client to specify what
- additional communication protocols it supports and would like to use
- if the server finds it appropriate to switch protocols. The server
- MUST use the Upgrade header field within a 101 (Switching Protocols)
- response to indicate which protocol(s) are being switched.
-
- Upgrade = "Upgrade" ":" 1#product
-
- For example,
-
- Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
-
- The Upgrade header field is intended to provide a simple mechanism
- for transition from HTTP/1.1 to some other, incompatible protocol. It
- does so by allowing the client to advertise its desire to use another
- protocol, such as a later version of HTTP with a higher major version
- number, even though the current request has been made using HTTP/1.1.
- This eases the difficult transition between incompatible protocols by
- allowing the client to initiate a request in the more commonly
- supported protocol while indicating to the server that it would like
- to use a "better" protocol if available (where "better" is determined
- by the server, possibly according to the nature of the method and/or
- resource being requested).
-
- The Upgrade header field only applies to switching application-layer
- protocols upon the existing transport-layer connection. Upgrade
- cannot be used to insist on a protocol change; its acceptance and use
- by the server is optional. The capabilities and nature of the
- application-layer communication after the protocol change is entirely
- dependent upon the new protocol chosen, although the first action
- after changing the protocol MUST be a response to the initial HTTP
- request containing the Upgrade header field.
-
- The Upgrade header field only applies to the immediate connection.
- Therefore, the upgrade keyword MUST be supplied within a Connection
- header field (section 14.10) whenever Upgrade is present in an
- HTTP/1.1 message.
-
-
-
-
-Fielding, et al. Standards Track [Page 144]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The Upgrade header field cannot be used to indicate a switch to a
- protocol on a different connection. For that purpose, it is more
- appropriate to use a 301, 302, 303, or 305 redirection response.
-
- This specification only defines the protocol name "HTTP" for use by
- the family of Hypertext Transfer Protocols, as defined by the HTTP
- version rules of section 3.1 and future updates to this
- specification. Any token can be used as a protocol name; however, it
- will only be useful if both the client and server associate the name
- with the same protocol.
-
-14.43 User-Agent
-
- The User-Agent request-header field contains information about the
- user agent originating the request. This is for statistical purposes,
- the tracing of protocol violations, and automated recognition of user
- agents for the sake of tailoring responses to avoid particular user
- agent limitations. User agents SHOULD include this field with
- requests. The field can contain multiple product tokens (section 3.8)
- and comments identifying the agent and any subproducts which form a
- significant part of the user agent. By convention, the product tokens
- are listed in order of their significance for identifying the
- application.
-
- User-Agent = "User-Agent" ":" 1*( product | comment )
-
- Example:
-
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
-
-14.44 Vary
-
- The Vary field value indicates the set of request-header fields that
- fully determines, while the response is fresh, whether a cache is
- permitted to use the response to reply to a subsequent request
- without revalidation. For uncacheable or stale responses, the Vary
- field value advises the user agent about the criteria that were used
- to select the representation. A Vary field value of "*" implies that
- a cache cannot determine from the request headers of a subsequent
- request whether this response is the appropriate representation. See
- section 13.6 for use of the Vary header field by caches.
-
- Vary = "Vary" ":" ( "*" | 1#field-name )
-
- An HTTP/1.1 server SHOULD include a Vary header field with any
- cacheable response that is subject to server-driven negotiation.
- Doing so allows a cache to properly interpret future requests on that
- resource and informs the user agent about the presence of negotiation
-
-
-
-Fielding, et al. Standards Track [Page 145]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- on that resource. A server MAY include a Vary header field with a
- non-cacheable response that is subject to server-driven negotiation,
- since this might provide the user agent with useful information about
- the dimensions over which the response varies at the time of the
- response.
-
- A Vary field value consisting of a list of field-names signals that
- the representation selected for the response is based on a selection
- algorithm which considers ONLY the listed request-header field values
- in selecting the most appropriate representation. A cache MAY assume
- that the same selection will be made for future requests with the
- same values for the listed field names, for the duration of time for
- which the response is fresh.
-
- The field-names given are not limited to the set of standard
- request-header fields defined by this specification. Field names are
- case-insensitive.
-
- A Vary field value of "*" signals that unspecified parameters not
- limited to the request-headers (e.g., the network address of the
- client), play a role in the selection of the response representation.
- The "*" value MUST NOT be generated by a proxy server; it may only be
- generated by an origin server.
-
-14.45 Via
-
- The Via general-header field MUST be used by gateways and proxies to
- indicate the intermediate protocols and recipients between the user
- agent and the server on requests, and between the origin server and
- the client on responses. It is analogous to the "Received" field of
- RFC 822 [9] and is intended to be used for tracking message forwards,
- avoiding request loops, and identifying the protocol capabilities of
- all senders along the request/response chain.
-
- Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
- received-protocol = [ protocol-name "/" ] protocol-version
- protocol-name = token
- protocol-version = token
- received-by = ( host [ ":" port ] ) | pseudonym
- pseudonym = token
-
- The received-protocol indicates the protocol version of the message
- received by the server or client along each segment of the
- request/response chain. The received-protocol version is appended to
- the Via field value when the message is forwarded so that information
- about the protocol capabilities of upstream applications remains
- visible to all recipients.
-
-
-
-
-Fielding, et al. Standards Track [Page 146]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The protocol-name is optional if and only if it would be "HTTP". The
- received-by field is normally the host and optional port number of a
- recipient server or client that subsequently forwarded the message.
- However, if the real host is considered to be sensitive information,
- it MAY be replaced by a pseudonym. If the port is not given, it MAY
- be assumed to be the default port of the received-protocol.
-
- Multiple Via field values represents each proxy or gateway that has
- forwarded the message. Each recipient MUST append its information
- such that the end result is ordered according to the sequence of
- forwarding applications.
-
- Comments MAY be used in the Via header field to identify the software
- of the recipient proxy or gateway, analogous to the User-Agent and
- Server header fields. However, all comments in the Via field are
- optional and MAY be removed by any recipient prior to forwarding the
- message.
-
- For example, a request message could be sent from an HTTP/1.0 user
- agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
- forward the request to a public proxy at nowhere.com, which completes
- the request by forwarding it to the origin server at www.ics.uci.edu.
- The request received by www.ics.uci.edu would then have the following
- Via header field:
-
- Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
-
- Proxies and gateways used as a portal through a network firewall
- SHOULD NOT, by default, forward the names and ports of hosts within
- the firewall region. This information SHOULD only be propagated if
- explicitly enabled. If not enabled, the received-by host of any host
- behind the firewall SHOULD be replaced by an appropriate pseudonym
- for that host.
-
- For organizations that have strong privacy requirements for hiding
- internal structures, a proxy MAY combine an ordered subsequence of
- Via header field entries with identical received-protocol values into
- a single such entry. For example,
-
- Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
-
- could be collapsed to
-
- Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 147]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Applications SHOULD NOT combine multiple entries unless they are all
- under the same organizational control and the hosts have already been
- replaced by pseudonyms. Applications MUST NOT combine entries which
- have different received-protocol values.
-
-14.46 Warning
-
- The Warning general-header field is used to carry additional
- information about the status or transformation of a message which
- might not be reflected in the message. This information is typically
- used to warn about a possible lack of semantic transparency from
- caching operations or transformations applied to the entity body of
- the message.
-
- Warning headers are sent with responses using:
-
- Warning = "Warning" ":" 1#warning-value
-
- warning-value = warn-code SP warn-agent SP warn-text
- [SP warn-date]
-
- warn-code = 3DIGIT
- warn-agent = ( host [ ":" port ] ) | pseudonym
- ; the name or pseudonym of the server adding
- ; the Warning header, for use in debugging
- warn-text = quoted-string
- warn-date = <"> HTTP-date <">
-
- A response MAY carry more than one Warning header.
-
- The warn-text SHOULD be in a natural language and character set that
- is most likely to be intelligible to the human user receiving the
- response. This decision MAY be based on any available knowledge, such
- as the location of the cache or user, the Accept-Language field in a
- request, the Content-Language field in a response, etc. The default
- language is English and the default character set is ISO-8859-1.
-
- If a character set other than ISO-8859-1 is used, it MUST be encoded
- in the warn-text using the method described in RFC 2047 [14].
-
- Warning headers can in general be applied to any message, however
- some specific warn-codes are specific to caches and can only be
- applied to response messages. New Warning headers SHOULD be added
- after any existing Warning headers. A cache MUST NOT delete any
- Warning header that it received with a message. However, if a cache
- successfully validates a cache entry, it SHOULD remove any Warning
- headers previously attached to that entry except as specified for
-
-
-
-
-Fielding, et al. Standards Track [Page 148]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- specific Warning codes. It MUST then add any Warning headers received
- in the validating response. In other words, Warning headers are those
- that would be attached to the most recent relevant response.
-
- When multiple Warning headers are attached to a response, the user
- agent ought to inform the user of as many of them as possible, in the
- order that they appear in the response. If it is not possible to
- inform the user of all of the warnings, the user agent SHOULD follow
- these heuristics:
-
- - Warnings that appear early in the response take priority over
- those appearing later in the response.
-
- - Warnings in the user's preferred character set take priority
- over warnings in other character sets but with identical warn-
- codes and warn-agents.
-
- Systems that generate multiple Warning headers SHOULD order them with
- this user agent behavior in mind.
-
- Requirements for the behavior of caches with respect to Warnings are
- stated in section 13.1.2.
-
- This is a list of the currently-defined warn-codes, each with a
- recommended warn-text in English, and a description of its meaning.
-
- 110 Response is stale
- MUST be included whenever the returned response is stale.
-
- 111 Revalidation failed
- MUST be included if a cache returns a stale response because an
- attempt to revalidate the response failed, due to an inability to
- reach the server.
-
- 112 Disconnected operation
- SHOULD be included if the cache is intentionally disconnected from
- the rest of the network for a period of time.
-
- 113 Heuristic expiration
- MUST be included if the cache heuristically chose a freshness
- lifetime greater than 24 hours and the response's age is greater
- than 24 hours.
-
- 199 Miscellaneous warning
- The warning text MAY include arbitrary information to be presented
- to a human user, or logged. A system receiving this warning MUST
- NOT take any automated action, besides presenting the warning to
- the user.
-
-
-
-Fielding, et al. Standards Track [Page 149]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 214 Transformation applied
- MUST be added by an intermediate cache or proxy if it applies any
- transformation changing the content-coding (as specified in the
- Content-Encoding header) or media-type (as specified in the
- Content-Type header) of the response, or the entity-body of the
- response, unless this Warning code already appears in the response.
-
- 299 Miscellaneous persistent warning
- The warning text MAY include arbitrary information to be presented
- to a human user, or logged. A system receiving this warning MUST
- NOT take any automated action.
-
- If an implementation sends a message with one or more Warning headers
- whose version is HTTP/1.0 or lower, then the sender MUST include in
- each warning-value a warn-date that matches the date in the response.
-
- If an implementation receives a message with a warning-value that
- includes a warn-date, and that warn-date is different from the Date
- value in the response, then that warning-value MUST be deleted from
- the message before storing, forwarding, or using it. (This prevents
- bad consequences of naive caching of Warning header fields.) If all
- of the warning-values are deleted for this reason, the Warning header
- MUST be deleted as well.
-
-14.47 WWW-Authenticate
-
- The WWW-Authenticate response-header field MUST be included in 401
- (Unauthorized) response messages. The field value consists of at
- least one challenge that indicates the authentication scheme(s) and
- parameters applicable to the Request-URI.
-
- WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
-
- The HTTP access authentication process is described in "HTTP
- Authentication: Basic and Digest Access Authentication" [43]. User
- agents are advised to take special care in parsing the WWW-
- Authenticate field value as it might contain more than one challenge,
- or if more than one WWW-Authenticate header field is provided, the
- contents of a challenge itself can contain a comma-separated list of
- authentication parameters.
-
-15 Security Considerations
-
- This section is meant to inform application developers, information
- providers, and users of the security limitations in HTTP/1.1 as
- described by this document. The discussion does not include
- definitive solutions to the problems revealed, though it does make
- some suggestions for reducing security risks.
-
-
-
-Fielding, et al. Standards Track [Page 150]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-15.1 Personal Information
-
- HTTP clients are often privy to large amounts of personal information
- (e.g. the user's name, location, mail address, passwords, encryption
- keys, etc.), and SHOULD be very careful to prevent unintentional
- leakage of this information via the HTTP protocol to other sources.
- We very strongly recommend that a convenient interface be provided
- for the user to control dissemination of such information, and that
- designers and implementors be particularly careful in this area.
- History shows that errors in this area often create serious security
- and/or privacy problems and generate highly adverse publicity for the
- implementor's company.
-
-15.1.1 Abuse of Server Log Information
-
- A server is in the position to save personal data about a user's
- requests which might identify their reading patterns or subjects of
- interest. This information is clearly confidential in nature and its
- handling can be constrained by law in certain countries. People using
- the HTTP protocol to provide data are responsible for ensuring that
- such material is not distributed without the permission of any
- individuals that are identifiable by the published results.
-
-15.1.2 Transfer of Sensitive Information
-
- Like any generic data transfer protocol, HTTP cannot regulate the
- content of the data that is transferred, nor is there any a priori
- method of determining the sensitivity of any particular piece of
- information within the context of any given request. Therefore,
- applications SHOULD supply as much control over this information as
- possible to the provider of that information. Four header fields are
- worth special mention in this context: Server, Via, Referer and From.
-
- Revealing the specific software version of the server might allow the
- server machine to become more vulnerable to attacks against software
- that is known to contain security holes. Implementors SHOULD make the
- Server header field a configurable option.
-
- Proxies which serve as a portal through a network firewall SHOULD
- take special precautions regarding the transfer of header information
- that identifies the hosts behind the firewall. In particular, they
- SHOULD remove, or replace with sanitized versions, any Via fields
- generated behind the firewall.
-
- The Referer header allows reading patterns to be studied and reverse
- links drawn. Although it can be very useful, its power can be abused
- if user details are not separated from the information contained in
-
-
-
-
-Fielding, et al. Standards Track [Page 151]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- the Referer. Even when the personal information has been removed, the
- Referer header might indicate a private document's URI whose
- publication would be inappropriate.
-
- The information sent in the From field might conflict with the user's
- privacy interests or their site's security policy, and hence it
- SHOULD NOT be transmitted without the user being able to disable,
- enable, and modify the contents of the field. The user MUST be able
- to set the contents of this field within a user preference or
- application defaults configuration.
-
- We suggest, though do not require, that a convenient toggle interface
- be provided for the user to enable or disable the sending of From and
- Referer information.
-
- The User-Agent (section 14.43) or Server (section 14.38) header
- fields can sometimes be used to determine that a specific client or
- server have a particular security hole which might be exploited.
- Unfortunately, this same information is often used for other valuable
- purposes for which HTTP currently has no better mechanism.
-
-15.1.3 Encoding Sensitive Information in URI's
-
- Because the source of a link might be private information or might
- reveal an otherwise private information source, it is strongly
- recommended that the user be able to select whether or not the
- Referer field is sent. For example, a browser client could have a
- toggle switch for browsing openly/anonymously, which would
- respectively enable/disable the sending of Referer and From
- information.
-
- Clients SHOULD NOT include a Referer header field in a (non-secure)
- HTTP request if the referring page was transferred with a secure
- protocol.
-
- Authors of services which use the HTTP protocol SHOULD NOT use GET
- based forms for the submission of sensitive data, because this will
- cause this data to be encoded in the Request-URI. Many existing
- servers, proxies, and user agents will log the request URI in some
- place where it might be visible to third parties. Servers can use
- POST-based form submission instead
-
-15.1.4 Privacy Issues Connected to Accept Headers
-
- Accept request-headers can reveal information about the user to all
- servers which are accessed. The Accept-Language header in particular
- can reveal information the user would consider to be of a private
- nature, because the understanding of particular languages is often
-
-
-
-Fielding, et al. Standards Track [Page 152]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- strongly correlated to the membership of a particular ethnic group.
- User agents which offer the option to configure the contents of an
- Accept-Language header to be sent in every request are strongly
- encouraged to let the configuration process include a message which
- makes the user aware of the loss of privacy involved.
-
- An approach that limits the loss of privacy would be for a user agent
- to omit the sending of Accept-Language headers by default, and to ask
- the user whether or not to start sending Accept-Language headers to a
- server if it detects, by looking for any Vary response-header fields
- generated by the server, that such sending could improve the quality
- of service.
-
- Elaborate user-customized accept header fields sent in every request,
- in particular if these include quality values, can be used by servers
- as relatively reliable and long-lived user identifiers. Such user
- identifiers would allow content providers to do click-trail tracking,
- and would allow collaborating content providers to match cross-server
- click-trails or form submissions of individual users. Note that for
- many users not behind a proxy, the network address of the host
- running the user agent will also serve as a long-lived user
- identifier. In environments where proxies are used to enhance
- privacy, user agents ought to be conservative in offering accept
- header configuration options to end users. As an extreme privacy
- measure, proxies could filter the accept headers in relayed requests.
- General purpose user agents which provide a high degree of header
- configurability SHOULD warn users about the loss of privacy which can
- be involved.
-
-15.2 Attacks Based On File and Path Names
-
- Implementations of HTTP origin servers SHOULD be careful to restrict
- the documents returned by HTTP requests to be only those that were
- intended by the server administrators. If an HTTP server translates
- HTTP URIs directly into file system calls, the server MUST take
- special care not to serve files that were not intended to be
- delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
- other operating systems use ".." as a path component to indicate a
- directory level above the current one. On such a system, an HTTP
- server MUST disallow any such construct in the Request-URI if it
- would otherwise allow access to a resource outside those intended to
- be accessible via the HTTP server. Similarly, files intended for
- reference only internally to the server (such as access control
- files, configuration files, and script code) MUST be protected from
- inappropriate retrieval, since they might contain sensitive
- information. Experience has shown that minor bugs in such HTTP server
- implementations have turned into security risks.
-
-
-
-
-Fielding, et al. Standards Track [Page 153]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-15.3 DNS Spoofing
-
- Clients using HTTP rely heavily on the Domain Name Service, and are
- thus generally prone to security attacks based on the deliberate
- mis-association of IP addresses and DNS names. Clients need to be
- cautious in assuming the continuing validity of an IP number/DNS name
- association.
-
- In particular, HTTP clients SHOULD rely on their name resolver for
- confirmation of an IP number/DNS name association, rather than
- caching the result of previous host name lookups. Many platforms
- already can cache host name lookups locally when appropriate, and
- they SHOULD be configured to do so. It is proper for these lookups to
- be cached, however, only when the TTL (Time To Live) information
- reported by the name server makes it likely that the cached
- information will remain useful.
-
- If HTTP clients cache the results of host name lookups in order to
- achieve a performance improvement, they MUST observe the TTL
- information reported by DNS.
-
- If HTTP clients do not observe this rule, they could be spoofed when
- a previously-accessed server's IP address changes. As network
- renumbering is expected to become increasingly common [24], the
- possibility of this form of attack will grow. Observing this
- requirement thus reduces this potential security vulnerability.
-
- This requirement also improves the load-balancing behavior of clients
- for replicated servers using the same DNS name and reduces the
- likelihood of a user's experiencing failure in accessing sites which
- use that strategy.
-
-15.4 Location Headers and Spoofing
-
- If a single server supports multiple organizations that do not trust
- one another, then it MUST check the values of Location and Content-
- Location headers in responses that are generated under control of
- said organizations to make sure that they do not attempt to
- invalidate resources over which they have no authority.
-
-15.5 Content-Disposition Issues
-
- RFC 1806 [35], from which the often implemented Content-Disposition
- (see section 19.5.1) header in HTTP is derived, has a number of very
- serious security considerations. Content-Disposition is not part of
- the HTTP standard, but since it is widely implemented, we are
- documenting its use and risks for implementors. See RFC 2183 [49]
- (which updates RFC 1806) for details.
-
-
-
-Fielding, et al. Standards Track [Page 154]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-15.6 Authentication Credentials and Idle Clients
-
- Existing HTTP clients and user agents typically retain authentication
- information indefinitely. HTTP/1.1. does not provide a method for a
- server to direct clients to discard these cached credentials. This is
- a significant defect that requires further extensions to HTTP.
- Circumstances under which credential caching can interfere with the
- application's security model include but are not limited to:
-
- - Clients which have been idle for an extended period following
- which the server might wish to cause the client to reprompt the
- user for credentials.
-
- - Applications which include a session termination indication
- (such as a `logout' or `commit' button on a page) after which
- the server side of the application `knows' that there is no
- further reason for the client to retain the credentials.
-
- This is currently under separate study. There are a number of work-
- arounds to parts of this problem, and we encourage the use of
- password protection in screen savers, idle time-outs, and other
- methods which mitigate the security problems inherent in this
- problem. In particular, user agents which cache credentials are
- encouraged to provide a readily accessible mechanism for discarding
- cached credentials under user control.
-
-15.7 Proxies and Caching
-
- By their very nature, HTTP proxies are men-in-the-middle, and
- represent an opportunity for man-in-the-middle attacks. Compromise of
- the systems on which the proxies run can result in serious security
- and privacy problems. Proxies have access to security-related
- information, personal information about individual users and
- organizations, and proprietary information belonging to users and
- content providers. A compromised proxy, or a proxy implemented or
- configured without regard to security and privacy considerations,
- might be used in the commission of a wide range of potential attacks.
-
- Proxy operators should protect the systems on which proxies run as
- they would protect any system that contains or transports sensitive
- information. In particular, log information gathered at proxies often
- contains highly sensitive personal information, and/or information
- about organizations. Log information should be carefully guarded, and
- appropriate guidelines for use developed and followed. (Section
- 15.1.1).
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 155]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Caching proxies provide additional potential vulnerabilities, since
- the contents of the cache represent an attractive target for
- malicious exploitation. Because cache contents persist after an HTTP
- request is complete, an attack on the cache can reveal information
- long after a user believes that the information has been removed from
- the network. Therefore, cache contents should be protected as
- sensitive information.
-
- Proxy implementors should consider the privacy and security
- implications of their design and coding decisions, and of the
- configuration options they provide to proxy operators (especially the
- default configuration).
-
- Users of a proxy need to be aware that they are no trustworthier than
- the people who run the proxy; HTTP itself cannot solve this problem.
-
- The judicious use of cryptography, when appropriate, may suffice to
- protect against a broad range of security and privacy attacks. Such
- cryptography is beyond the scope of the HTTP/1.1 specification.
-
-15.7.1 Denial of Service Attacks on Proxies
-
- They exist. They are hard to defend against. Research continues.
- Beware.
-
-16 Acknowledgments
-
- This specification makes heavy use of the augmented BNF and generic
- constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
- reuses many of the definitions provided by Nathaniel Borenstein and
- Ned Freed for MIME [7]. We hope that their inclusion in this
- specification will help reduce past confusion over the relationship
- between HTTP and Internet mail message formats.
-
- The HTTP protocol has evolved considerably over the years. It has
- benefited from a large and active developer community--the many
- people who have participated on the www-talk mailing list--and it is
- that community which has been most responsible for the success of
- HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
- Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
- Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
- McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
- VanHeyningen deserve special recognition for their efforts in
- defining early aspects of the protocol.
-
- This document has benefited greatly from the comments of all those
- participating in the HTTP-WG. In addition to those already mentioned,
- the following individuals have contributed to this specification:
-
-
-
-Fielding, et al. Standards Track [Page 156]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Gary Adams Ross Patterson
- Harald Tveit Alvestrand Albert Lunde
- Keith Ball John C. Mallery
- Brian Behlendorf Jean-Philippe Martin-Flatin
- Paul Burchard Mitra
- Maurizio Codogno David Morris
- Mike Cowlishaw Gavin Nicol
- Roman Czyborra Bill Perry
- Michael A. Dolan Jeffrey Perry
- David J. Fiander Scott Powers
- Alan Freier Owen Rees
- Marc Hedlund Luigi Rizzo
- Greg Herlihy David Robinson
- Koen Holtman Marc Salomon
- Alex Hopmann Rich Salz
- Bob Jernigan Allan M. Schiffman
- Shel Kaphan Jim Seidman
- Rohit Khare Chuck Shotton
- John Klensin Eric W. Sink
- Martijn Koster Simon E. Spero
- Alexei Kosut Richard N. Taylor
- David M. Kristol Robert S. Thau
- Daniel LaLiberte Bill (BearHeart) Weinman
- Ben Laurie Francois Yergeau
- Paul J. Leach Mary Ellen Zurko
- Daniel DuBois Josh Cohen
-
-
- Much of the content and presentation of the caching design is due to
- suggestions and comments from individuals including: Shel Kaphan,
- Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
-
- Most of the specification of ranges is based on work originally done
- by Ari Luotonen and John Franks, with additional input from Steve
- Zilles.
-
- Thanks to the "cave men" of Palo Alto. You know who you are.
-
- Jim Gettys (the current editor of this document) wishes particularly
- to thank Roy Fielding, the previous editor of this document, along
- with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
- Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
- Larry Masinter for their help. And thanks go particularly to Jeff
- Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 157]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
- Frystyk implemented RFC 2068 early, and we wish to thank them for the
- discovery of many of the problems that this document attempts to
- rectify.
-
-17 References
-
- [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
- 1766, March 1995.
-
- [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
- D. and B. Alberti, "The Internet Gopher Protocol (a distributed
- document search and retrieval protocol)", RFC 1436, March 1993.
-
- [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
- 1630, June 1994.
-
- [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
- Locators (URL)", RFC 1738, December 1994.
-
- [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
- 2.0", RFC 1866, November 1995.
-
- [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
- Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
- [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC 2045, November 1996.
-
- [8] Braden, R., "Requirements for Internet Hosts -- Communication
- Layers", STD 3, RFC 1123, October 1989.
-
- [9] Crocker, D., "Standard for The Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
- Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
- Functional Specification," (v1.5), Thinking Machines
- Corporation, April 1990.
-
- [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
- June 1995.
-
- [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
- Messages", RFC 1036, December 1987.
-
-
-
-
-
-Fielding, et al. Standards Track [Page 158]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
- 977, February 1986.
-
- [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
- Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
- November 1996.
-
- [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
- 1867, November 1995.
-
- [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
- August 1982.
-
- [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
- November 1996.
-
- [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
- 959, October 1985.
-
- [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
- October 1994.
-
- [20] Sollins, K. and L. Masinter, "Functional Requirements for
- Uniform Resource Names", RFC 1737, December 1994.
-
- [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
- Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
-
- [22] ISO-8859. International Standard -- Information Processing --
- 8-bit Single-Byte Coded Graphic Character Sets --
- Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
- Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
- Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
- Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
- Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
- Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
- Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
- Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
- Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
-
- [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
- 1864, October 1995.
-
- [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
- 1900, February 1996.
-
- [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
- 1952, May 1996.
-
-
-
-Fielding, et al. Standards Track [Page 159]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
- Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
- Dec. 1995. Slightly revised version of paper in Proc. 2nd
- International WWW Conference '94: Mosaic and the Web, Oct. 1994,
- which is available at
- http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
- ency.html.
-
- [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
- Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
- ISI Research Report ISI/RR-98-463, (original report dated Aug.
- 1996), USC/Information Sciences Institute, August 1998.
-
- [28] Mills, D., "Network Time Protocol (Version 3) Specification,
- Implementation and Analysis", RFC 1305, March 1992.
-
- [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
- version 1.3", RFC 1951, May 1996.
-
- [30] S. Spero, "Analysis of HTTP Performance Problems,"
- http://sunsite.unc.edu/mdma-release/http-prob.html.
-
- [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
- Specification version 3.3", RFC 1950, May 1996.
-
- [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
- Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
- Digest Access Authentication", RFC 2069, January 1997.
-
- [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
- Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
- 2068, January 1997.
-
- [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [35] Troost, R. and Dorner, S., "Communicating Presentation
- Information in Internet Messages: The Content-Disposition
- Header", RFC 1806, June 1995.
-
- [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
- Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
- [jg639]
-
- [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
- 1997. [jg640]
-
-
-
-
-
-Fielding, et al. Standards Track [Page 160]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
- ISO-10646", RFC 2279, January 1998. [jg641]
-
- [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
- Lie, H., and C. Lilley. "Network Performance Effects of
- HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
- France, September 1997.[jg642]
-
- [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046, November
- 1996. [jg643]
-
- [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
- BCP 18, RFC 2277, January 1998. [jg644]
-
- [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
- August 1998. [jg645]
-
- [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
- Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
- Authentication: Basic and Digest Access Authentication", RFC
- 2617, June 1999. [jg646]
-
- [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
- servers," Work in Progress. [jg647]
-
- [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
- Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
- 1997.
-
- [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
-
- [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
- (HTCPCP/1.0)", RFC 2324, 1 April 1998.
-
- [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Five: Conformance Criteria and Examples",
- RFC 2049, November 1996.
-
- [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
- Information in Internet Messages: The Content-Disposition Header
- Field", RFC 2183, August 1997.
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 161]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-18 Authors' Addresses
-
- Roy T. Fielding
- Information and Computer Science
- University of California, Irvine
- Irvine, CA 92697-3425, USA
-
- Fax: +1 (949) 824-1715
- EMail: fielding@ics.uci.edu
-
-
- James Gettys
- World Wide Web Consortium
- MIT Laboratory for Computer Science
- 545 Technology Square
- Cambridge, MA 02139, USA
-
- Fax: +1 (617) 258 8682
- EMail: jg@w3.org
-
-
- Jeffrey C. Mogul
- Western Research Laboratory
- Compaq Computer Corporation
- 250 University Avenue
- Palo Alto, California, 94305, USA
-
- EMail: mogul@wrl.dec.com
-
-
- Henrik Frystyk Nielsen
- World Wide Web Consortium
- MIT Laboratory for Computer Science
- 545 Technology Square
- Cambridge, MA 02139, USA
-
- Fax: +1 (617) 258 8682
- EMail: frystyk@w3.org
-
-
- Larry Masinter
- Xerox Corporation
- 3333 Coyote Hill Road
- Palo Alto, CA 94034, USA
-
- EMail: masinter@parc.xerox.com
-
-
-
-
-
-Fielding, et al. Standards Track [Page 162]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Paul J. Leach
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052, USA
-
- EMail: paulle@microsoft.com
-
-
- Tim Berners-Lee
- Director, World Wide Web Consortium
- MIT Laboratory for Computer Science
- 545 Technology Square
- Cambridge, MA 02139, USA
-
- Fax: +1 (617) 258 8682
- EMail: timbl@w3.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 163]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-19 Appendices
-
-19.1 Internet Media Type message/http and application/http
-
- In addition to defining the HTTP/1.1 protocol, this document serves
- as the specification for the Internet media type "message/http" and
- "application/http". The message/http type can be used to enclose a
- single HTTP request or response message, provided that it obeys the
- MIME restrictions for all "message" types regarding line length and
- encodings. The application/http type can be used to enclose a
- pipeline of one or more HTTP request or response messages (not
- intermixed). The following is to be registered with IANA [17].
-
- Media Type name: message
- Media subtype name: http
- Required parameters: none
- Optional parameters: version, msgtype
- version: The HTTP-Version number of the enclosed message
- (e.g., "1.1"). If not present, the version can be
- determined from the first line of the body.
- msgtype: The message type -- "request" or "response". If not
- present, the type can be determined from the first
- line of the body.
- Encoding considerations: only "7bit", "8bit", or "binary" are
- permitted
- Security considerations: none
-
- Media Type name: application
- Media subtype name: http
- Required parameters: none
- Optional parameters: version, msgtype
- version: The HTTP-Version number of the enclosed messages
- (e.g., "1.1"). If not present, the version can be
- determined from the first line of the body.
- msgtype: The message type -- "request" or "response". If not
- present, the type can be determined from the first
- line of the body.
- Encoding considerations: HTTP messages enclosed by this type
- are in "binary" format; use of an appropriate
- Content-Transfer-Encoding is required when
- transmitted via E-mail.
- Security considerations: none
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 164]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-19.2 Internet Media Type multipart/byteranges
-
- When an HTTP 206 (Partial Content) response message includes the
- content of multiple ranges (a response to a request for multiple
- non-overlapping ranges), these are transmitted as a multipart
- message-body. The media type for this purpose is called
- "multipart/byteranges".
-
- The multipart/byteranges media type includes two or more parts, each
- with its own Content-Type and Content-Range fields. The required
- boundary parameter specifies the boundary string used to separate
- each body-part.
-
- Media Type name: multipart
- Media subtype name: byteranges
- Required parameters: boundary
- Optional parameters: none
- Encoding considerations: only "7bit", "8bit", or "binary" are
- permitted
- Security considerations: none
-
-
- For example:
-
- HTTP/1.1 206 Partial Content
- Date: Wed, 15 Nov 1995 06:25:24 GMT
- Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
- Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
-
- --THIS_STRING_SEPARATES
- Content-type: application/pdf
- Content-range: bytes 500-999/8000
-
- ...the first range...
- --THIS_STRING_SEPARATES
- Content-type: application/pdf
- Content-range: bytes 7000-7999/8000
-
- ...the second range
- --THIS_STRING_SEPARATES--
-
- Notes:
-
- 1) Additional CRLFs may precede the first boundary string in the
- entity.
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 165]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- 2) Although RFC 2046 [40] permits the boundary string to be
- quoted, some existing implementations handle a quoted boundary
- string incorrectly.
-
- 3) A number of browsers and servers were coded to an early draft
- of the byteranges specification to use a media type of
- multipart/x-byteranges, which is almost, but not quite
- compatible with the version documented in HTTP/1.1.
-
-19.3 Tolerant Applications
-
- Although this document specifies the requirements for the generation
- of HTTP/1.1 messages, not all applications will be correct in their
- implementation. We therefore recommend that operational applications
- be tolerant of deviations whenever those deviations can be
- interpreted unambiguously.
-
- Clients SHOULD be tolerant in parsing the Status-Line and servers
- tolerant when parsing the Request-Line. In particular, they SHOULD
- accept any amount of SP or HT characters between fields, even though
- only a single SP is required.
-
- The line terminator for message-header fields is the sequence CRLF.
- However, we recommend that applications, when parsing such headers,
- recognize a single LF as a line terminator and ignore the leading CR.
-
- The character set of an entity-body SHOULD be labeled as the lowest
- common denominator of the character codes used within that body, with
- the exception that not labeling the entity is preferred over labeling
- the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
- and 3.4.1.
-
- Additional rules for requirements on parsing and encoding of dates
- and other potential problems with date encodings include:
-
- - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
- which appears to be more than 50 years in the future is in fact
- in the past (this helps solve the "year 2000" problem).
-
- - An HTTP/1.1 implementation MAY internally represent a parsed
- Expires date as earlier than the proper value, but MUST NOT
- internally represent a parsed Expires date as later than the
- proper value.
-
- - All expiration-related calculations MUST be done in GMT. The
- local time zone MUST NOT influence the calculation or comparison
- of an age or expiration time.
-
-
-
-
-Fielding, et al. Standards Track [Page 166]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - If an HTTP header incorrectly carries a date value with a time
- zone other than GMT, it MUST be converted into GMT using the
- most conservative possible conversion.
-
-19.4 Differences Between HTTP Entities and RFC 2045 Entities
-
- HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
- 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
- allow entities to be transmitted in an open variety of
- representations and with extensible mechanisms. However, RFC 2045
- discusses mail, and HTTP has a few features that are different from
- those described in RFC 2045. These differences were carefully chosen
- to optimize performance over binary connections, to allow greater
- freedom in the use of new media types, to make date comparisons
- easier, and to acknowledge the practice of some early HTTP servers
- and clients.
-
- This appendix describes specific areas where HTTP differs from RFC
- 2045. Proxies and gateways to strict MIME environments SHOULD be
- aware of these differences and provide the appropriate conversions
- where necessary. Proxies and gateways from MIME environments to HTTP
- also need to be aware of the differences because some conversions
- might be required.
-
-19.4.1 MIME-Version
-
- HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
- include a single MIME-Version general-header field to indicate what
- version of the MIME protocol was used to construct the message. Use
- of the MIME-Version header field indicates that the message is in
- full compliance with the MIME protocol (as defined in RFC 2045[7]).
- Proxies/gateways are responsible for ensuring full compliance (where
- possible) when exporting HTTP messages to strict MIME environments.
-
- MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
-
- MIME version "1.0" is the default for use in HTTP/1.1. However,
- HTTP/1.1 message parsing and semantics are defined by this document
- and not the MIME specification.
-
-19.4.2 Conversion to Canonical Form
-
- RFC 2045 [7] requires that an Internet mail entity be converted to
- canonical form prior to being transferred, as described in section 4
- of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
- allowed for subtypes of the "text" media type when transmitted over
- HTTP. RFC 2046 requires that content with a type of "text" represent
- line breaks as CRLF and forbids the use of CR or LF outside of line
-
-
-
-Fielding, et al. Standards Track [Page 167]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
- line break within text content when a message is transmitted over
- HTTP.
-
- Where it is possible, a proxy or gateway from HTTP to a strict MIME
- environment SHOULD translate all line breaks within the text media
- types described in section 3.7.1 of this document to the RFC 2049
- canonical form of CRLF. Note, however, that this might be complicated
- by the presence of a Content-Encoding and by the fact that HTTP
- allows the use of some character sets which do not use octets 13 and
- 10 to represent CR and LF, as is the case for some multi-byte
- character sets.
-
- Implementors should note that conversion will break any cryptographic
- checksums applied to the original content unless the original content
- is already in canonical form. Therefore, the canonical form is
- recommended for any content that uses such checksums in HTTP.
-
-19.4.3 Conversion of Date Formats
-
- HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
- simplify the process of date comparison. Proxies and gateways from
- other protocols SHOULD ensure that any Date header field present in a
- message conforms to one of the HTTP/1.1 formats and rewrite the date
- if necessary.
-
-19.4.4 Introduction of Content-Encoding
-
- RFC 2045 does not include any concept equivalent to HTTP/1.1's
- Content-Encoding header field. Since this acts as a modifier on the
- media type, proxies and gateways from HTTP to MIME-compliant
- protocols MUST either change the value of the Content-Type header
- field or decode the entity-body before forwarding the message. (Some
- experimental applications of Content-Type for Internet mail have used
- a media-type parameter of ";conversions=<content-coding>" to perform
- a function equivalent to Content-Encoding. However, this parameter is
- not part of RFC 2045.)
-
-19.4.5 No Content-Transfer-Encoding
-
- HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
- 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
- remove any non-identity CTE ("quoted-printable" or "base64") encoding
- prior to delivering the response message to an HTTP client.
-
- Proxies and gateways from HTTP to MIME-compliant protocols are
- responsible for ensuring that the message is in the correct format
- and encoding for safe transport on that protocol, where "safe
-
-
-
-Fielding, et al. Standards Track [Page 168]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- transport" is defined by the limitations of the protocol being used.
- Such a proxy or gateway SHOULD label the data with an appropriate
- Content-Transfer-Encoding if doing so will improve the likelihood of
- safe transport over the destination protocol.
-
-19.4.6 Introduction of Transfer-Encoding
-
- HTTP/1.1 introduces the Transfer-Encoding header field (section
- 14.41). Proxies/gateways MUST remove any transfer-coding prior to
- forwarding a message via a MIME-compliant protocol.
-
- A process for decoding the "chunked" transfer-coding (section 3.6)
- can be represented in pseudo-code as:
-
- length := 0
- read chunk-size, chunk-extension (if any) and CRLF
- while (chunk-size > 0) {
- read chunk-data and CRLF
- append chunk-data to entity-body
- length := length + chunk-size
- read chunk-size and CRLF
- }
- read entity-header
- while (entity-header not empty) {
- append entity-header to existing header fields
- read entity-header
- }
- Content-Length := length
- Remove "chunked" from Transfer-Encoding
-
-19.4.7 MHTML and Line Length Limitations
-
- HTTP implementations which share code with MHTML [45] implementations
- need to be aware of MIME line length limitations. Since HTTP does not
- have this limitation, HTTP does not fold long lines. MHTML messages
- being transported by HTTP follow all conventions of MHTML, including
- line length limitations and folding, canonicalization, etc., since
- HTTP transports all message-bodies as payload (see section 3.7.2) and
- does not interpret the content or any MIME header lines that might be
- contained therein.
-
-19.5 Additional Features
-
- RFC 1945 and RFC 2068 document protocol elements used by some
- existing HTTP implementations, but not consistently and correctly
- across most HTTP/1.1 applications. Implementors are advised to be
- aware of these features, but cannot rely upon their presence in, or
- interoperability with, other HTTP/1.1 applications. Some of these
-
-
-
-Fielding, et al. Standards Track [Page 169]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- describe proposed experimental features, and some describe features
- that experimental deployment found lacking that are now addressed in
- the base HTTP/1.1 specification.
-
- A number of other headers, such as Content-Disposition and Title,
- from SMTP and MIME are also often implemented (see RFC 2076 [37]).
-
-19.5.1 Content-Disposition
-
- The Content-Disposition response-header field has been proposed as a
- means for the origin server to suggest a default filename if the user
- requests that the content is saved to a file. This usage is derived
- from the definition of Content-Disposition in RFC 1806 [35].
-
- content-disposition = "Content-Disposition" ":"
- disposition-type *( ";" disposition-parm )
- disposition-type = "attachment" | disp-extension-token
- disposition-parm = filename-parm | disp-extension-parm
- filename-parm = "filename" "=" quoted-string
- disp-extension-token = token
- disp-extension-parm = token "=" ( token | quoted-string )
-
- An example is
-
- Content-Disposition: attachment; filename="fname.ext"
-
- The receiving user agent SHOULD NOT respect any directory path
- information present in the filename-parm parameter, which is the only
- parameter believed to apply to HTTP implementations at this time. The
- filename SHOULD be treated as a terminal component only.
-
- If this header is used in a response with the application/octet-
- stream content-type, the implied suggestion is that the user agent
- should not display the response, but directly enter a `save response
- as...' dialog.
-
- See section 15.5 for Content-Disposition security issues.
-
-19.6 Compatibility with Previous Versions
-
- It is beyond the scope of a protocol specification to mandate
- compliance with previous versions. HTTP/1.1 was deliberately
- designed, however, to make supporting previous versions easy. It is
- worth noting that, at the time of composing this specification
- (1996), we would expect commercial HTTP/1.1 servers to:
-
- - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
- 1.1 requests;
-
-
-
-Fielding, et al. Standards Track [Page 170]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- - understand any valid request in the format of HTTP/0.9, 1.0, or
- 1.1;
-
- - respond appropriately with a message in the same major version
- used by the client.
-
- And we would expect HTTP/1.1 clients to:
-
- - recognize the format of the Status-Line for HTTP/1.0 and 1.1
- responses;
-
- - understand any valid response in the format of HTTP/0.9, 1.0, or
- 1.1.
-
- For most implementations of HTTP/1.0, each connection is established
- by the client prior to the request and closed by the server after
- sending the response. Some implementations implement the Keep-Alive
- version of persistent connections described in section 19.7.1 of RFC
- 2068 [33].
-
-19.6.1 Changes from HTTP/1.0
-
- This section summarizes major differences between versions HTTP/1.0
- and HTTP/1.1.
-
-19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
- Addresses
-
- The requirements that clients and servers support the Host request-
- header, report an error if the Host request-header (section 14.23) is
- missing from an HTTP/1.1 request, and accept absolute URIs (section
- 5.1.2) are among the most important changes defined by this
- specification.
-
- Older HTTP/1.0 clients assumed a one-to-one relationship of IP
- addresses and servers; there was no other established mechanism for
- distinguishing the intended server of a request than the IP address
- to which that request was directed. The changes outlined above will
- allow the Internet, once older HTTP clients are no longer common, to
- support multiple Web sites from a single IP address, greatly
- simplifying large operational Web servers, where allocation of many
- IP addresses to a single host has created serious problems. The
- Internet will also be able to recover the IP addresses that have been
- allocated for the sole purpose of allowing special-purpose domain
- names to be used in root-level HTTP URLs. Given the rate of growth of
- the Web, and the number of servers already deployed, it is extremely
-
-
-
-
-
-Fielding, et al. Standards Track [Page 171]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- important that all implementations of HTTP (including updates to
- existing HTTP/1.0 applications) correctly implement these
- requirements:
-
- - Both clients and servers MUST support the Host request-header.
-
- - A client that sends an HTTP/1.1 request MUST send a Host header.
-
- - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
- request does not include a Host request-header.
-
- - Servers MUST accept absolute URIs.
-
-19.6.2 Compatibility with HTTP/1.0 Persistent Connections
-
- Some clients and servers might wish to be compatible with some
- previous implementations of persistent connections in HTTP/1.0
- clients and servers. Persistent connections in HTTP/1.0 are
- explicitly negotiated as they are not the default behavior. HTTP/1.0
- experimental implementations of persistent connections are faulty,
- and the new facilities in HTTP/1.1 are designed to rectify these
- problems. The problem was that some existing 1.0 clients may be
- sending Keep-Alive to a proxy server that doesn't understand
- Connection, which would then erroneously forward it to the next
- inbound server, which would establish the Keep-Alive connection and
- result in a hung HTTP/1.0 proxy waiting for the close on the
- response. The result is that HTTP/1.0 clients must be prevented from
- using Keep-Alive when talking to proxies.
-
- However, talking to proxies is the most important use of persistent
- connections, so that prohibition is clearly unacceptable. Therefore,
- we need some other mechanism for indicating a persistent connection
- is desired, which is safe to use even when talking to an old proxy
- that ignores Connection. Persistent connections are the default for
- HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
- declaring non-persistence. See section 14.10.
-
- The original HTTP/1.0 form of persistent connections (the Connection:
- Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
-
-19.6.3 Changes from RFC 2068
-
- This specification has been carefully audited to correct and
- disambiguate key word usage; RFC 2068 had many problems in respect to
- the conventions laid out in RFC 2119 [34].
-
- Clarified which error code should be used for inbound server failures
- (e.g. DNS failures). (Section 10.5.5).
-
-
-
-Fielding, et al. Standards Track [Page 172]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- CREATE had a race that required an Etag be sent when a resource is
- first created. (Section 10.2.2).
-
- Content-Base was deleted from the specification: it was not
- implemented widely, and there is no simple, safe way to introduce it
- without a robust extension mechanism. In addition, it is used in a
- similar, but not identical fashion in MHTML [45].
-
- Transfer-coding and message lengths all interact in ways that
- required fixing exactly when chunked encoding is used (to allow for
- transfer encoding that may not be self delimiting); it was important
- to straighten out exactly how message lengths are computed. (Sections
- 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
-
- A content-coding of "identity" was introduced, to solve problems
- discovered in caching. (section 3.5)
-
- Quality Values of zero should indicate that "I don't want something"
- to allow clients to refuse a representation. (Section 3.9)
-
- The use and interpretation of HTTP version numbers has been clarified
- by RFC 2145. Require proxies to upgrade requests to highest protocol
- version they support to deal with problems discovered in HTTP/1.0
- implementations (Section 3.1)
-
- Charset wildcarding is introduced to avoid explosion of character set
- names in accept headers. (Section 14.2)
-
- A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
- was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
- 14.9.3)
-
- The Cache-Control: max-age directive was not properly defined for
- responses. (Section 14.9.3)
-
- There are situations where a server (especially a proxy) does not
- know the full length of a response but is capable of serving a
- byterange request. We therefore need a mechanism to allow byteranges
- with a content-range not indicating the full length of the message.
- (Section 14.16)
-
- Range request responses would become very verbose if all meta-data
- were always returned; by allowing the server to only send needed
- headers in a 206 response, this problem can be avoided. (Section
- 10.2.7, 13.5.3, and 14.27)
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 173]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Fix problem with unsatisfiable range requests; there are two cases:
- syntactic problems, and range doesn't exist in the document. The 416
- status code was needed to resolve this ambiguity needed to indicate
- an error for a byte range request that falls outside of the actual
- contents of a document. (Section 10.4.17, 14.16)
-
- Rewrite of message transmission requirements to make it much harder
- for implementors to get it wrong, as the consequences of errors here
- can have significant impact on the Internet, and to deal with the
- following problems:
-
- 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
- this was incorrectly placing a requirement on the behavior of
- an implementation of a future version of HTTP/1.x
-
- 2. Made it clear that user-agents should retry requests, not
- "clients" in general.
-
- 3. Converted requirements for clients to ignore unexpected 100
- (Continue) responses, and for proxies to forward 100 responses,
- into a general requirement for 1xx responses.
-
- 4. Modified some TCP-specific language, to make it clearer that
- non-TCP transports are possible for HTTP.
-
- 5. Require that the origin server MUST NOT wait for the request
- body before it sends a required 100 (Continue) response.
-
- 6. Allow, rather than require, a server to omit 100 (Continue) if
- it has already seen some of the request body.
-
- 7. Allow servers to defend against denial-of-service attacks and
- broken clients.
-
- This change adds the Expect header and 417 status code. The message
- transmission requirements fixes are in sections 8.2, 10.4.18,
- 8.1.2.2, 13.11, and 14.20.
-
- Proxies should be able to add Content-Length when appropriate.
- (Section 13.5.2)
-
- Clean up confusion between 403 and 404 responses. (Section 10.4.4,
- 10.4.5, and 10.4.11)
-
- Warnings could be cached incorrectly, or not updated appropriately.
- (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
- also needed to be a general header, as PUT or other methods may have
- need for it in requests.
-
-
-
-Fielding, et al. Standards Track [Page 174]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
- Transfer-coding had significant problems, particularly with
- interactions with chunked encoding. The solution is that transfer-
- codings become as full fledged as content-codings. This involves
- adding an IANA registry for transfer-codings (separate from content
- codings), a new header field (TE) and enabling trailer headers in the
- future. Transfer encoding is a major performance benefit, so it was
- worth fixing [39]. TE also solves another, obscure, downward
- interoperability problem that could have occurred due to interactions
- between authentication trailers, chunked encoding and HTTP/1.0
- clients.(Section 3.6, 3.6.1, and 14.39)
-
- The PATCH, LINK, UNLINK methods were defined but not commonly
- implemented in previous versions of this specification. See RFC 2068
- [33].
-
- The Alternates, Content-Version, Derived-From, Link, URI, Public and
- Content-Base header fields were defined in previous versions of this
- specification, but not commonly implemented. See RFC 2068 [33].
-
-20 Index
-
- Please see the PostScript version of this RFC for the INDEX.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 175]
-\f
-RFC 2616 HTTP/1.1 June 1999
-
-
-21. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Standards Track [Page 176]
-\f
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 "<major>.<minor>" 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]
+\f
+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]
+\f
+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]
+\f
+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 = <URI-reference, see [RFC3986], Section 4.1>
+ absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
+ relative-part = <relative-part, see [RFC3986], Section 4.2>
+ scheme = <scheme, see [RFC3986], Section 3.1>
+ authority = <authority, see [RFC3986], Section 3.2>
+ uri-host = <host, see [RFC3986], Section 3.2.2>
+ port = <port, see [RFC3986], Section 3.2.3>
+ path-abempty = <path-abempty, see [RFC3986], Section 3.3>
+ segment = <segment, see [RFC3986], Section 3.3>
+ query = <query, see [RFC3986], Section 3.4>
+ fragment = <fragment, see [RFC3986], Section 3.5>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ <http://www.example.org/pub/WWW/> 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 "<n>#<m>element"
+ indicating at least <n> and at most <m> elements, each separated by a
+ single comma (",") and optional whitespace (OWS).
+
+
+
+
+Fielding & Reschke Standards Track [Page 59]
+\f
+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:
+
+ <n>#<m>element => element <n-1>*<m-1>( 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]
+\f
+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
+ <http://www.iana.org/assignments/message-headers/>.
+
+ 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]
+\f
+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
+ <http://www.iana.org/assignments/uri-schemes/>.
+
+ 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
+ <http://www.iana.org/assignments/media-types>.
+
+ 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]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/http-parameters>.
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 64]
+\f
+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]
+\f
+RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
+
+
+8.5. Content Coding Registration
+
+ IANA maintains the "HTTP Content Coding Registry" at
+ <http://www.iana.org/assignments/http-parameters>.
+
+ 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
+ <http://www.iana.org/assignments/http-upgrade-tokens>.
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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,
+ <http://doi.acm.org/10.1145/2382196.2382204>.
+
+ [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, <http://packetstormsecurity.com/
+ papers/general/whitepaper_httpresponse.pdf>.
+
+ [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
+ Politics", ACM Transactions on Internet
+ Technology 1(2), November 2001,
+ <http://arxiv.org/abs/cs.SE/0105018>.
+
+ [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
+ Request Smuggling", June 2005,
+ <http://www.watchfire.com/news/whitepapers.aspx>.
+
+
+
+
+Fielding & Reschke Standards Track [Page 75]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 = <URI-reference, see [RFC3986], Section 4.1>
+ 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-URI, see [RFC3986], Section 4.3>
+ absolute-form = absolute-URI
+ absolute-path = 1*( "/" segment )
+ asterisk-form = "*"
+ authority = <authority, see [RFC3986], Section 3.2>
+ authority-form = authority
+
+
+
+
+Fielding & Reschke Standards Track [Page 82]
+\f
+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 = <fragment, see [RFC3986], Section 3.5>
+
+ 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 = <path-abempty, see [RFC3986], Section 3.3>
+ port = <port, see [RFC3986], Section 3.2.3>
+ protocol = protocol-name [ "/" protocol-version ]
+ protocol-name = token
+ protocol-version = token
+ pseudonym = token
+
+ qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
+ / %x5D-7E ; ']'-'~'
+ / obs-text
+ query = <query, see [RFC3986], Section 3.4>
+ quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
+
+
+
+Fielding & Reschke Standards Track [Page 83]
+\f
+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 = <relative-part, see [RFC3986], Section 4.2>
+ request-line = method SP request-target SP HTTP-version CRLF
+ request-target = origin-form / absolute-form / authority-form /
+ asterisk-form
+
+ scheme = <scheme, see [RFC3986], Section 3.1>
+ segment = <segment, see [RFC3986], Section 3.3>
+ 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 = <host, see [RFC3986], Section 3.2.2>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 84]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 (<http://www.iana.org/assignments/character-sets>) 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 = <Language-Tag, see [RFC5646], Section 2.1>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 =
+ <language-range, see [RFC4647], Section 2.1>
+
+ 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]
+\f
+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]
+\f
+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 = <mailbox, see [RFC5322], Section 3.4>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/http-methods>.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 73]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/http-status-codes>.
+
+ 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]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/message-headers>, as defined by
+ [BCP90].
+
+
+
+
+Fielding & Reschke Standards Track [Page 77]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <http://www.iana.org/assignments/http-parameters>.
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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,
+ <https://www.owasp.org/>.
+
+ [REST] Fielding, R., "Architectural Styles and the Design of
+ Network-based Software Architectures",
+ Doctoral Dissertation, University of California, Irvine,
+ September 2000,
+ <http://roy.gbiv.com/pubs/dissertation/top.htm>.
+
+ [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]
+\f
+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]
+\f
+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]
+\f
+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=<content-coding>"
+ 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]
+\f
+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]
+\f
+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]
+\f
+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 = <BWS, see [RFC7230], Section 3.2.3>
+ OWS = <OWS, see [RFC7230], Section 3.2.3>
+ RWS = <RWS, see [RFC7230], Section 3.2.3>
+ URI-reference = <URI-reference, see [RFC7230], Section 2.7>
+ absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
+ comment = <comment, see [RFC7230], Section 3.2.6>
+ field-name = <comment, see [RFC7230], Section 3.2>
+ partial-URI = <partial-URI, see [RFC7230], Section 2.7>
+
+
+
+Fielding & Reschke Standards Track [Page 93]
+\f
+RFC 7231 HTTP/1.1 Semantics and Content June 2014
+
+
+ quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
+ token = <token, see [RFC7230], Section 3.2.6>
+
+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 = <BWS, see [RFC7230], Section 3.2.3>
+
+ 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 = <OWS, see [RFC7230], Section 3.2.3>
+
+ RWS = <RWS, see [RFC7230], Section 3.2.3>
+ Referer = absolute-URI / partial-URI
+ Retry-After = HTTP-date / delay-seconds
+
+
+
+Fielding & Reschke Standards Track [Page 94]
+\f
+RFC 7231 HTTP/1.1 Semantics and Content June 2014
+
+
+ Server = product *( RWS ( product / comment ) )
+
+ URI-reference = <URI-reference, see [RFC7230], Section 2.7>
+ User-Agent = product *( RWS ( product / comment ) )
+
+ Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
+ ) )
+
+ absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
+ 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 = <comment, see [RFC7230], Section 3.2.6>
+ 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 = <comment, see [RFC7230], Section 3.2>
+
+ hour = 2DIGIT
+
+ language-range = <language-range, see [RFC4647], Section 2.1>
+ language-tag = <Language-Tag, see [RFC5646], Section 2.1>
+
+ mailbox = <mailbox, see [RFC5322], Section 3.4>
+ media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
+ ";" OWS parameter )
+
+
+
+Fielding & Reschke Standards Track [Page 95]
+\f
+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 = <partial-URI, see [RFC7230], Section 2.7>
+ product = token [ "/" product-version ]
+ product-version = token
+ quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
+ 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 = <token, see [RFC7230], Section 3.2.6>
+ type = token
+
+ weight = OWS ";" OWS "q=" qvalue
+
+ year = 4DIGIT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 96]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <http://www.iana.org/assignments/http-status-codes> 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
+ <http://www.iana.org/assignments/message-headers/>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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 = <OWS, see [RFC7230], Section 3.2.3>
+ obs-text = <obs-text, see [RFC7230], Section 3.2.6>
+
+ The rules below are defined in other parts:
+
+ HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 25]
+\f
+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 = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+
+ 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 = <OWS, see [RFC7230], Section 3.2.3>
+
+ entity-tag = [ weak ] opaque-tag
+ etagc = "!" / %x23-7E ; '#'-'~'
+ / obs-text
+
+ obs-text = <obs-text, see [RFC7230], Section 3.2.6>
+ opaque-tag = DQUOTE *etagc DQUOTE
+
+ weak = %x57.2F ; W/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 26]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/http-parameters>.
+
+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]
+\f
+RFC 7233 HTTP/1.1 Range Requests June 2014
+
+
+5.2. Status Code Registration
+
+ The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
+ at <http://www.iana.org/assignments/http-status-codes> 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
+ <http://www.iana.org/assignments/message-headers/>.
+
+ 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
+ <http://www.iana.org/assignments/media-types>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 = <OWS, see [RFC7230], Section 3.2.3>
+ token = <token, see [RFC7230], Section 3.2.6>
+
+ The rules below are defined in other parts:
+
+ HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+ entity-tag = <entity-tag, see [RFC7232], Section 2.3>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 22]
+\f
+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 = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+
+ If-Range = entity-tag / HTTP-date
+
+ OWS = <OWS, see [RFC7230], Section 3.2.3>
+
+ 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 = <entity-tag, see [RFC7232], Section 2.3>
+
+ 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]
+\f
+RFC 7233 HTTP/1.1 Range Requests June 2014
+
+
+ suffix-length = 1*DIGIT
+
+ token = <token, see [RFC7230], Section 3.2.6>
+
+ 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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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
+ <http://www.iana.org/assignments/http-cache-directives>.
+
+7.1.1. Procedure
+
+ A registration MUST include the following fields:
+
+ o Cache Directive Name
+
+
+
+Fielding, et al. Standards Track [Page 32]
+\f
+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]
+\f
+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 <http://www.iana.org/assignments/http-warn-codes>.
+
+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
+ <http://www.iana.org/assignments/message-headers/>.
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 34]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 = <OWS, see [RFC7230], Section 3.2.3>
+ field-name = <field-name, see [RFC7230], Section 3.2>
+ quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
+ token = <token, see [RFC7230], Section 3.2.6>
+
+ port = <port, see [RFC7230], Section 2.7>
+ pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
+ uri-host = <uri-host, see [RFC7230], Section 2.7>
+
+ The rules below are defined in other parts:
+
+ HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Standards Track [Page 39]
+\f
+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 = <HTTP-date, see [RFC7231], Section 7.1.1.1>
+
+ OWS = <OWS, see [RFC7230], Section 3.2.3>
+
+ 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 = <field-name, see [RFC7230], Section 3.2>
+
+ port = <port, see [RFC7230], Section 2.7>
+ pragma-directive = "no-cache" / extension-pragma
+ pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
+
+ quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
+
+ token = <token, see [RFC7230], Section 3.2.6>
+
+ uri-host = <uri-host, see [RFC7230], Section 2.7>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 <http://www.iana.org/assignments/http-authschemes>.
+
+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]
+\f
+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]
+\f
+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 <http://www.iana.org/assignments/http-status-codes> 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
+ <http://www.iana.org/assignments/message-headers/>.
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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,
+ <https://www.owasp.org/>.
+
+ [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]
+\f
+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]
+\f
+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 = <BWS, see [RFC7230], Section 3.2.3>
+ OWS = <OWS, see [RFC7230], Section 3.2.3>
+ quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
+ token = <token, see [RFC7230], Section 3.2.6>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 16]
+\f
+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 = <BWS, see [RFC7230], Section 3.2.3>
+
+ OWS = <OWS, see [RFC7230], Section 3.2.3>
+
+ 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 = <quoted-string, see [RFC7230], Section 3.2.6>
+
+ token = <token, see [RFC7230], Section 3.2.6>
+ token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
+ *"="
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding & Reschke Standards Track [Page 17]
+\f
+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]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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 <meta> 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]
+\f
+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
+
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Permanent Redirect</title>
+ <meta http-equiv="refresh"
+ content="0; url=http://example.com/new">
+ </head>
+ <body>
+ <p>
+ The document has been moved to
+ <a href="http://example.com/new"
+ >http://example.com/new</a>.
+ </p>
+ </body>
+ </html>
+
+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
+ <http://www.iana.org/assignments/http-status-codes>):
+
+ +-------+--------------------+---------------------------------+
+ | Value | Description | Reference |
+ +-------+--------------------+---------------------------------+
+ | 308 | Permanent Redirect | Section 3 of this specification |
+ +-------+--------------------+---------------------------------+
+
+
+
+
+
+
+
+
+
+
+Reschke Experimental [Page 4]
+\f
+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,
+ <http://www.w3.org/TR/1999/REC-html401-19991224>.
+
+ Latest version available at
+ <http://www.w3.org/TR/html401>.
+
+
+
+
+
+
+
+
+
+
+Reschke Experimental [Page 5]
+\f
+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]
+\f
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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 = <Defined in [RFC7230], Section 3.2.6>
+ quoted-string = <Defined in [RFC7230], Section 3.2.6>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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 = <Defined in [RFC3986], Section 3.2.2>
+ IPv6address = <Defined in [RFC3986], Section 3.2.2>
+ obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-")
+
+ node-port = port / obfport
+ port = 1*5DIGIT
+ obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-")
+
+ DIGIT = <Defined in [RFC5234], Section 3.4>
+ ALPHA = <Defined in [RFC5234], Section B.1>
+
+ 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / squid.git / commitdiff
