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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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]
`
`NOAC Ex. 1011 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"