Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. Fielding, et al. Standards Track [Page 1] RFC 2616 HTTP/1.1 June 1999 Table of Contents 1 Introduction ...................................................7 1.1 Purpose......................................................7 1.2 Requirements .................................................8 1.3 Terminology ..................................................8 1.4 Overall Operation ...........................................12 2 Notational Conventions and Generic Grammar ....................14 2.1 Augmented BNF ...............................................14 2.2 Basic Rules .................................................15 3 Protocol Parameters ...........................................17 3.1 HTTP Version ................................................17 3.2 Uniform Resource Identifiers ................................18 3.2.1 General Syntax ...........................................19 3.2.2 http URL .................................................19 3.2.3 URI Comparison ...........................................20 3.3 Date/Time Formats ...........................................20 3.3.1 Full Date ................................................20 3.3.2 Delta Seconds ............................................21 3.4 Character Sets ..............................................21 3.4.1 Missing Charset ..........................................22 3.5 Content Codings .............................................23 3.6 Transfer Codings ............................................24 3.6.1 Chunked Transfer Coding ..................................25 3.7 Media Types .................................................26 3.7.1 Canonicalization and Text Defaults .......................27 3.7.2 Multipart Types ..........................................27 3.8 Product Tokens ..............................................28 3.9 Quality Values ..............................................29 3.10 Language Tags ...............................................29 3.11 Entity Tags .................................................30 3.12 Range Units .................................................30 4 HTTP Message ..................................................31 4.1 Message Types ...............................................31 4.2 Message Headers .............................................31 4.3 Message Body ................................................32 4.4 Message Length ..............................................33 4.5 General Header Fields .......................................34 5 Request .......................................................35 5.1 Request-Line ................................................35 5.1.1 Method ...................................................36 5.1.2 Request-URI ..............................................36 5.2 The Resource Identified by a Request ........................38 5.3 Request Header Fields .......................................38 6 Response ......................................................39 6.1 Status-Line .................................................39 6.1.1 Status Code and Reason Phrase ............................39 6.2 Response Header Fields ......................................41 Fielding, et al. Standards Track [Page 2] RFC 2616 HTTP/1.1 June 1999 7 Entity ........................................................42 7.1 Entity Header Fields ........................................42 7.2 Entity Body .................................................43 7.2.1 Type .....................................................43 7.2.2 Entity Length ............................................43 8 Connections ...................................................44 8.1 Persistent Connections ......................................44 8.1.1 Purpose ..................................................44 8.1.2 Overall Operation ........................................45 8.1.3 Proxy Servers ............................................46 8.1.4 Practical Considerations .................................46 8.2 Message Transmission Requirements ...........................47 8.2.1 Persistent Connections and Flow Control ..................47 8.2.2 Monitoring Connections for Error Status Messages .........48 8.2.3 Use of the 100 (Continue) Status .........................48 8.2.4 Client Behavior if Server Prematurely Closes Connection ..50 9 Method Definitions ............................................51 9.1 Safe and Idempotent Methods .................................51 9.1.1 Safe Methods .............................................51 9.1.2 Idempotent Methods .......................................51 9.2 OPTIONS .....................................................52 9.3 GET .........................................................53 9.4 HEAD ........................................................54 9.5 POST ........................................................54 9.6 PUT .........................................................55 9.7 DELETE ......................................................56 9.8 TRACE .......................................................56 9.9 CONNECT .....................................................57 10 Status Code Definitions ......................................57 10.1 Informational 1xx ...........................................57 10.1.1 100 Continue .............................................58 10.1.2 101 Switching Protocols ..................................58 10.2 Successful 2xx ..............................................58 10.2.1 200 OK ...................................................58 10.2.2 201 Created ..............................................59 10.2.3 202 Accepted .............................................59 10.2.4 203 Non-Authoritative Information ........................59 10.2.5 204 No Content ...........................................60 10.2.6 205 Reset Content ........................................60 10.2.7 206 Partial Content ......................................60 10.3 Redirection 3xx .............................................61 10.3.1 300 Multiple Choices .....................................61 10.3.2 301 Moved Permanently ....................................62 10.3.3 302 Found ................................................62 10.3.4 303 See Other ............................................63 10.3.5 304 Not Modified .........................................63 10.3.6 305 Use Proxy ............................................64 10.3.7 306 (Unused) .............................................64 Fielding, et al. Standards Track [Page 3] RFC 2616 HTTP/1.1 June 1999 10.3.8 307 Temporary Redirect ...................................65 10.4 Client Error 4xx ............................................65 10.4.1 400 Bad Request .........................................65 10.4.2 401 Unauthorized ........................................66 10.4.3 402 Payment Required ....................................66 10.4.4 403 Forbidden ...........................................66 10.4.5 404 Not Found ...........................................66 10.4.6 405 Method Not Allowed ..................................66 10.4.7 406 Not Acceptable ......................................67 10.4.8 407 Proxy Authentication Required .......................67 10.4.9 408 Request Timeout .....................................67 10.4.10 409 Conflict ............................................67 10.4.11 410 Gone ................................................68 10.4.12 411 Length Required .....................................68 10.4.13 412 Precondition Failed .................................68 10.4.14 413 Request Entity Too Large ............................69 10.4.15 414 Request-URI Too Long ................................69 10.4.16 415 Unsupported Media Type ..............................69 10.4.17 416 Requested Range Not Satisfiable .....................69 10.4.18 417 Expectation Failed ..................................70 10.5 Server Error 5xx ............................................70 10.5.1 500 Internal Server Error ................................70 10.5.2 501 Not Implemented ......................................70 10.5.3 502 Bad Gateway ..........................................70 10.5.4 503 Service Unavailable ..................................70 10.5.5 504 Gateway Timeout ......................................71 10.5.6 505 HTTP Version Not Supported ...........................71 11 Access Authentication ........................................71 12 Content Negotiation ..........................................71 12.1 Server-driven Negotiation ...................................72 12.2 Agent-driven Negotiation ....................................73 12.3 Transparent Negotiation .....................................74 13 Caching in HTTP ..............................................74 13.1.1 Cache Correctness ........................................75 13.1.2 Warnings .................................................76 13.1.3 Cache-control Mechanisms .................................77 13.1.4 Explicit User Agent Warnings .............................78 13.1.5 Exceptions to the Rules and Warnings .....................78 13.1.6 Client-controlled Behavior ...............................79 13.2 Expiration Model ............................................79 13.2.1 Server-Specified Expiration ..............................79 13.2.2 Heuristic Expiration .....................................80 13.2.3 Age Calculations .........................................80 13.2.4 Expiration Calculations ..................................83 13.2.5 Disambiguating Expiration Values .........................84 13.2.6 Disambiguating Multiple Responses ........................84 13.3 Validation Model ............................................85 13.3.1 Last-Modified Dates ......................................86 Fielding, et al. Standards Track [Page 4] RFC 2616 HTTP/1.1 June 1999 13.3.2 Entity Tag Cache Validators ..............................86 13.3.3 Weak and Strong Validators ...............................86 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89 13.3.5 Non-validating Conditionals ..............................90 13.4 Response Cacheability .......................................91 13.5 Constructing Responses From Caches ..........................92 13.5.1 End-to-end and Hop-by-hop Headers ........................92 13.5.2 Non-modifiable Headers ...................................92 13.5.3 Combining Headers ........................................94 13.5.4 Combining Byte Ranges ....................................95 13.6 Caching Negotiated Responses ................................95 13.7 Shared and Non-Shared Caches ................................96 13.8 Errors or Incomplete Response Cache Behavior ................97 13.9 Side Effects of GET and HEAD ................................97 13.10 Invalidation After Updates or Deletions ...................97 13.11 Write-Through Mandatory ...................................98 13.12 Cache Replacement .........................................99 13.13 History Lists .............................................99 14 Header Field Definitions ....................................100 14.1 Accept .....................................................100 14.2 Accept-Charset .............................................102 14.3 Accept-Encoding ............................................102 14.4 Accept-Language ............................................104 14.5 Accept-Ranges ..............................................105 14.6 Age ........................................................106 14.7 Allow ......................................................106 14.8 Authorization ..............................................107 14.9 Cache-Control ..............................................108 14.9.1 What is Cacheable .......................................109 14.9.2 What May be Stored by Caches ............................110 14.9.3 Modifications of the Basic Expiration Mechanism .........111 14.9.4 Cache Revalidation and Reload Controls ..................113 14.9.5 No-Transform Directive ..................................115 14.9.6 Cache Control Extensions ................................116 14.10 Connection ...............................................117 14.11 Content-Encoding .........................................118 14.12 Content-Language .........................................118 14.13 Content-Length ...........................................119 14.14 Content-Location .........................................120 14.15 Content-MD5 ..............................................121 14.16 Content-Range ............................................122 14.17 Content-Type .............................................124 14.18 Date .....................................................124 14.18.1 Clockless Origin Server Operation ......................125 14.19 ETag .....................................................126 14.20 Expect ...................................................126 14.21 Expires ..................................................127 14.22 From .....................................................128 Fielding, et al. Standards Track [Page 5] RFC 2616 HTTP/1.1 June 1999 14.23 Host .....................................................128 14.24 If-Match .................................................129 14.25 If-Modified-Since ........................................130 14.26 If-None-Match ............................................132 14.27 If-Range .................................................133 14.28 If-Unmodified-Since ......................................134 14.29 Last-Modified ............................................134 14.30 Location .................................................135 14.31 Max-Forwards .............................................136 14.32 Pragma ...................................................136 14.33 Proxy-Authenticate .......................................137 14.34 Proxy-Authorization ......................................137 14.35 Range ....................................................138 14.35.1 Byte Ranges ...........................................138 14.35.2 Range Retrieval Requests ..............................139 14.36 Referer ..................................................140 14.37 Retry-After ..............................................141 14.38 Server ...................................................141 14.39 TE .......................................................142 14.40 Trailer ..................................................143 14.41 Transfer-Encoding..........................................143 14.42 Upgrade ..................................................144 14.43 User-Agent ...............................................145 14.44 Vary .....................................................145 14.45 Via ......................................................146 14.46 Warning ..................................................148 14.47 WWW-Authenticate .........................................150 15 Security Considerations .......................................150 15.1 Personal Information....................................151 15.1.1 Abuse of Server Log Information .........................151 15.1.2 Transfer of Sensitive Information .......................151 15.1.3 Encoding Sensitive Information in URI's .................152 15.1.4 Privacy Issues Connected to Accept Headers ..............152 15.2 Attacks Based On File and Path Names .......................153 15.3 DNS Spoofing ...............................................154 15.4 Location Headers and Spoofing ..............................154 15.5 Content-Disposition Issues .................................154 15.6 Authentication Credentials and Idle Clients ................155 15.7 Proxies and Caching ........................................155 15.7.1 Denial of Service Attacks on Proxies....................156 16 Acknowledgments .............................................156 17 References ..................................................158 18 Authors' Addresses ..........................................162 19 Appendices ..................................................164 19.1 Internet Media Type message/http and application/http ......164 19.2 Internet Media Type multipart/byteranges ...................165 19.3 Tolerant Applications ......................................166 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167 Fielding, et al. Standards Track [Page 6] RFC 2616 HTTP/1.1 June 1999 19.4.1 MIME-Version ............................................167 19.4.2 Conversion to Canonical Form ............................167 19.4.3 Conversion of Date Formats ..............................168 19.4.4 Introduction of Content-Encoding ........................168 19.4.5 No Content-Transfer-Encoding ............................168 19.4.6 Introduction of Transfer-Encoding .......................169 19.4.7 MHTML and Line Length Limitations .......................169 19.5 Additional Features ........................................169 19.5.1 Content-Disposition .....................................170 19.6 Compatibility with Previous Versions .......................170 19.6.1 Changes from HTTP/1.0 ...................................171 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172 19.6.3 Changes from RFC 2068 ...................................172 20 Index .......................................................175 21 Full Copyright Statement ....................................176 1 Introduction 1.1 Purpose The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities. This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its features. Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request [47]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name (URN) [20], for indicating the resource to which a Fielding, et al. Standards Track [Page 7] RFC 2616 HTTP/1.1 June 1999 method is to be applied. Messages are passed in a format similar to that used by Internet mail [9] as defined by the Multipurpose Internet Mail Extensions (MIME) [7]. HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, including those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications. 1.2 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [34]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." 1.3 Terminology This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication. connection A transport layer virtual circuit established between two programs for the purpose of communication. message The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 and transmitted via the connection. request An HTTP request message, as defined in section 5. response An HTTP response message, as defined in section 6. Fielding, et al. Standards Track [Page 8] RFC 2616 HTTP/1.1 June 1999 resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways. entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7. representation An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status. content negotiation The mechanism for selecting the appropriate representation when servicing a request, as described in section 12. The representation of entities in any response can be negotiated (including error responses). variant A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. client A program that establishes connections for the purpose of sending requests. user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. server An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. Fielding, et al. Standards Track [Page 9] RFC 2616 HTTP/1.1 June 1999 origin server The server on which a given resource resides or is to be created. proxy An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. gateway A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway. tunnel An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. cacheable A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request. Fielding, et al. Standards Track [Page 10] RFC 2616 HTTP/1.1 June 1999 first-hand A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more proxies. A response is also first-hand if its validity has just been checked directly with the origin server. explicit expiration time The time at which the origin server intends that an entity should no longer be returned by a cache without further validation. heuristic expiration time An expiration time assigned by a cache when no explicit expiration time is available. age The age of a response is the time since it was sent by, or successfully validated with, the origin server. freshness lifetime The length of time between the generation of a response and its expiration time. fresh A response is fresh if its age has not yet exceeded its freshness lifetime. stale A response is stale if its age has passed its freshness lifetime. semantically transparent A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been handled directly by the origin server. validator A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent copy of an entity. upstream/downstream Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream. Fielding, et al. Standards Track [Page 11] RFC 2616 HTTP/1.1 June 1999 inbound/outbound Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent" 1.4 Overall Operation The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content. The relationship between HTTP and MIME is described in appendix 19.4. Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O). request chain ------------------------> UA -------------------v------------------- O <----------------------- response chain A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages. request chain --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- response chain The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. This distinction is important because some HTTP communication options Fielding, et al. Standards Track [Page 12] RFC 2616 HTTP/1.1 June 1999 may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple, simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request. Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request which has not been cached by UA or A. request chain ----------> UA -----v----- A -----v----- B - - - - - - C - - - - - - O <--------- response chain Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cacheable responses are defined in section 13. In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so on. HTTP systems are used in corporate intranets over high-bandwidth links, and for access via PDAs with low-power radio links and intermittent connectivity. The goal of HTTP/1.1 is to support the wide diversity of configurations already deployed while introducing protocol constructs that meet the needs of those who build web applications that require high reliability and, failing that, at least reliable indications of failure. HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification. Fielding, et al. Standards Track [Page 13] RFC 2616 HTTP/1.1 June 1999 In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see section 8.1). 2 Notational Conventions and Generic Grammar 2.1 Augmented BNF All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [9]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs: name = definition The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names. "literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive. rule1 | rule2 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no. (rule1 rule2) Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem". *rule The character "*" preceding an element indicates repetition. The full form is "*element" indicating at least and at most occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two. [rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)". Fielding, et al. Standards Track [Page 14] RFC 2616 HTTP/1.1 June 1999 N rule Specific repetition: "(element)" is equivalent to "*(element)"; that is, exactly occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. #rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "#element" indicating at least and at most elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as ( *LWS element *( *LWS "," *LWS element )) can be shown as 1#element Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two. ; comment A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications. implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token. 2.2 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [21]. Fielding, et al. Standards Track [Page 15] RFC 2616 HTTP/1.1 June 1999 OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7. CRLF = CR LF HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. LWS = [CRLF] 1*( SP | HT ) The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT = A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value. Hexadecimal numeric characters are used in several protocol elements. HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT Fielding, et al. Standards Track [Page 16] RFC 2616 HTTP/1.1 June 1999 Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value (as defined in section 3.6). token = 1* separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value. comment = "(" *( ctext | quoted-pair | comment ) ")" ctext = A string of text is parsed as a single word if it is quoted using double-quote marks. quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = > The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. quoted-pair = "\" CHAR 3 Protocol Parameters 3.1 HTTP Version HTTP uses a "." numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The number is incremented when the format of a message within the protocol is changed. See RFC 2145 [36] for a fuller explanation. Fielding, et al. Standards Track [Page 17] RFC 2616 HTTP/1.1 June 1999 The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 [36]. The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant. Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST NOT send a message with a version indicator which is greater than its actual version. If a higher version request is received, the proxy/gateway MUST either downgrade the request version, or respond with an error, or switch to tunnel behavior. Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MU