rfc2616.txt   draft-lafon-rfc2616bis-00.txt 
Network Working Group R. Fielding Network Working Group Y. Lafon
Request for Comments: 2616 UC Irvine Internet-Draft W3C
Obsoletes: 2068 J. Gettys Obsoletes: 2616 (if approved) J. Reschke
Category: Standards Track Compaq/W3C Intended status: Standards Track greenbytes
J. Mogul Expires: April 16, 2007 October 13, 2006
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Hypertext Transfer Protocol -- HTTP/1.1 Hypertext Transfer Protocol -- HTTP/1.1
draft-lafon-rfc2616bis-00
Status of this Memo Status of this Memo
This document specifies an Internet standards track protocol for the By submitting this Internet-Draft, each author represents that any
Internet community, and requests discussion and suggestions for applicable patent or other IPR claims of which he or she is aware
improvements. Please refer to the current edition of the "Internet have been or will be disclosed, and any of which he or she becomes
Official Protocol Standards" (STD 1) for the standardization state aware will be disclosed, in accordance with Section 6 of BCP 79.
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). Copyright (C) The IETF Trust (2006).
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its distributed object management systems, through extension of its
request methods, error codes and headers [47]. A feature of HTTP is request methods, error codes and headers [47]. A feature of HTTP is
the typing and negotiation of data representation, allowing systems the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred. to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. referred to as "HTTP/1.1", and is an update to RFC2616.
Editorial Note (To be removed by RFC Editor before publication)
Distribution of this document is unlimited. Please send comments to
the Hypertext Transfer Protocol (HTTP) mailing list at
ietf-http-wg@w3.org [51], which may be joined by sending a message
with subject "subscribe" to ietf-http-wg-request@w3.org [52].
Discussions of the HTTP working group are archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. XML versions,
latest edits and the issues list for this document are available from
<http://www.w3.org/Protocols/HTTP/1.1/>.
The purpose of this document is to revise RFC2616 ([50]), doing only
minimal corrections. For now, it is not planned to advance the
standards level of HTTP, thus - if published - the specification will
still be a "Proposed Standard" (see [46]).
The current plan is to incorporate known errata, and to update the
specification text according to the current IETF publication
guidelines. In particular:
o Incorporate the corrections collected in the RFC2616 errata
document (<http://skrb.org/ietf/http_errata.html>) and potentially
newly discovered and agreed-upon errata.
o Update references, and re-classify them into "Normative" and
"Informative", based on the prior work done by Jim Gettys in
<http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00>.
This document is based on a variant of the original RFC2616
specification formatted using Marshall T. Rose's "xml2rfc" tool (see
<http://xml.resource.org>) and therefore deviates from the original
text in word wrapping, page breaks, list formatting, reference
formatting, whitespace usage and appendix numbering. Otherwise, it
is supposed to contain an accurate copy of the original specification
text. See <http://www.w3.org/Protocols/HTTP/1.1/
rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both
documents, as generated by "rfcdiff"
(<http://tools.ietf.org/tools/rfcdiff/>).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 10
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 13 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 15
2. Notational Conventions and Generic Grammar . . . . . . . . . 16 2. Notational Conventions and Generic Grammar . . . . . . . . . 18
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 16 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 18
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 20
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 22
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 20 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 23
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 21 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 23
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 22 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 24
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 22 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 24
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 22 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 24
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 24 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 26
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 24 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 26
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 25 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 27
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 25 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 27
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 26 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 28
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 27 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 29
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 29 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 31
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 29 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 31
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 30 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 32
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 31 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 33
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 31 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 33
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 32 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 34
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 34
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 33 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 35
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38
4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 4.5. General Header Fields . . . . . . . . . . . . . . . . . 39
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 39 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 41
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 39 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 40 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 42
5.2. The Resource Identified by a Request . . . . . . . . . . 41 5.2. The Resource Identified by a Request . . . . . . . . . . 43
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 42 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 44
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 46 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 48
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 47 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 49
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 49
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 48 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 50
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 49 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 51
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 49 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 51
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 49 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 51
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 51 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 53
8.1.4. Practical Considerations . . . . . . . . . . . . . . 51 8.1.4. Practical Considerations . . . . . . . . . . . . . . 53
8.2. Message Transmission Requirements . . . . . . . . . . . 52 8.2. Message Transmission Requirements . . . . . . . . . . . 54
8.2.1. Persistent Connections and Flow Control . . . . . . 52 8.2.1. Persistent Connections and Flow Control . . . . . . 54
8.2.2. Monitoring Connections for Error Status Messages . . 52 8.2.2. Monitoring Connections for Error Status Messages . . 54
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 53 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 55
8.2.4. Client Behavior if Server Prematurely Closes 8.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . 55 Connection . . . . . . . . . . . . . . . . . . . . . 57
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 58
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 56 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 58
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 56 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 58
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 56 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 58
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 59
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 62 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 64
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 63 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 65
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 63 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 65
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 63 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 65
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 63 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 65
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 64 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 66
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 64 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 66
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 64 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 66
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 64 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 66
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 65 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 67
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 65 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 67
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 65 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 67
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 66 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 68
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 66 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 68
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 67 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 69
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 67 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 69
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 68 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 70
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 68 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 70
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 69 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 71
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 69 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 71
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 70 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 72
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 70 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 72
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 70 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 72
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 71 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 73
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 71 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 73
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 71 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 73
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 71 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 73
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 71 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 73
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 72 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 74
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 72 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 74
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 72 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 74
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 73 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 75
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 73 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 75
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 73 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 75
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 74 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 76
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 74 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 76
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 74 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 76
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 74 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 76
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 74 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 76
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 74 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 76
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 75 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 77
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 75 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 77
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 75 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 77
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 75 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 77
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 75 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 77
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 76 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 78
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 76 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 78
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 76 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 78
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 77 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 79
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 78 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 80
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 78 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 80
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 79 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 81
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 80 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 82
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 81 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 83
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 82 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 84
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 83 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 85
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 84 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 86
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 84 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 86
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 85 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 87
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 85 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 87
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 86 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 88
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 86 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 88
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 86 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 88
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 87 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 89
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 89 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 91
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 90 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 92
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 91 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 93
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 91 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 93
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 92 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 94
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 92 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 94
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 93 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 95
13.3.4. Rules for When to Use Entity Tags and 13.3.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 95 Last-Modified Dates . . . . . . . . . . . . . . . . 97
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 97 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 99
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 97 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 99
13.5. Constructing Responses From Caches . . . . . . . . . . . 98 13.5. Constructing Responses From Caches . . . . . . . . . . . 100
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 98 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 100
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 99 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 101
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 100 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 102
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 101 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 103
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 102 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 104
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 103 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 105
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 103 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 105
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 104 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 106
13.10. Invalidation After Updates or Deletions . . . . . . . . 104 13.10. Invalidation After Updates or Deletions . . . . . . . . 106
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 105 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 107
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 105 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 107
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 106 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 108
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 107 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 109
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 107 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 109
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 109 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 111
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 109 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 111
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 111 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 113
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 112 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 114
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 112 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 114
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 113 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 115
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 113 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 116
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 114 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 116
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 116 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 118
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 117 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 119
14.9.3. Modifications of the Basic Expiration Mechanism . . 118 14.9.3. Modifications of the Basic Expiration Mechanism . . 120
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 120 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 122
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 122 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 125
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 123 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 125
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 124 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 126
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 127
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 125 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 128
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 126 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 128
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 127 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 129
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 128 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 130
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 129 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 131
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 131 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 133
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 131 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 133
14.18.1. Clockless Origin Server Operation . . . . . . . . . 132 14.18.1. Clockless Origin Server Operation . . . . . . . . . 134
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 133 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 133 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 135
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 134 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 136
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 136 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 138
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 139
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 139 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 141
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 140 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 142
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 141 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 143
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 141 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 143
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 142 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 144
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 142 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 144
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 143 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 145
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 144 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 146
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 146
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 144 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 147
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 144 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 147
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 146 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 148
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 147 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 149
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 147 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 150
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 149 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 152
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 150 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 152
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 150 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 153
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 152 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 152 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 153 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 155
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 154 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 157
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 159
15. Security Considerations . . . . . . . . . . . . . . . . . . . 158 15. Security Considerations . . . . . . . . . . . . . . . . . . . 160
15.1. Personal Information . . . . . . . . . . . . . . . . . . 158 15.1. Personal Information . . . . . . . . . . . . . . . . . . 160
15.1.1. Abuse of Server Log Information . . . . . . . . . . 158 15.1.1. Abuse of Server Log Information . . . . . . . . . . 160
15.1.2. Transfer of Sensitive Information . . . . . . . . . 158 15.1.2. Transfer of Sensitive Information . . . . . . . . . 160
15.1.3. Encoding Sensitive Information in URI's . . . . . . 159 15.1.3. Encoding Sensitive Information in URI's . . . . . . 161
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 160 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 162
15.2. Attacks Based On File and Path Names . . . . . . . . . . 160 15.2. Attacks Based On File and Path Names . . . . . . . . . . 162
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 161 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 163
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 161 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 163
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 162 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 164
15.6. Authentication Credentials and Idle Clients . . . . . . 162 15.6. Authentication Credentials and Idle Clients . . . . . . 164
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 162 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 164
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 163 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 165
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 166
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 166
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 170 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 168
A.1. Internet Media Type message/http and application/http . 170 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.2. Internet Media Type multipart/byteranges . . . . . . . . 171 17.1. References . . . . . . . . . . . . . . . . . . . . . . . 169
A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 172 17.2. Normative References . . . . . . . . . . . . . . . . . . 172
A.4. Differences Between HTTP Entities and RFC 2045 Appendix A. Internet Media Type message/http and
Entities . . . . . . . . . . . . . . . . . . . . . . . . 173 application/http . . . . . . . . . . . . . . . . . . 174
A.4.1. MIME-Version . . . . . . . . . . . . . . . . . . . . 174 Appendix B. Internet Media Type multipart/byteranges . . . . . . 176
A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 174 Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 178
A.4.3. Conversion of Date Formats . . . . . . . . . . . . . 174 Appendix D. Differences Between HTTP Entities and RFC 2045
A.4.4. Introduction of Content-Encoding . . . . . . . . . . 175 Entities . . . . . . . . . . . . . . . . . . . . . . 179
A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 175 D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 179
A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 175 D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 179
A.4.7. MHTML and Line Length Limitations . . . . . . . . . 176 D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 180
A.5. Additional Features . . . . . . . . . . . . . . . . . . 176 D.4. Introduction of Content-Encoding . . . . . . . . . . . . 180
A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 176 D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 180
A.6. Compatibility with Previous Versions . . . . . . . . . . 177 D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 181
A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 178 D.7. MHTML and Line Length Limitations . . . . . . . . . . . 181
A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 179 Appendix E. Additional Features . . . . . . . . . . . . . . . . 182
A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 179 E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 182
Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 183 Appendix F. Compatibility with Previous Versions . . . . . . . . 183
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 183
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 196 F.1.1. Changes to Simplify Multi-homed Web Servers and
Intellectual Property and Copyright Statements . . . . . . . . . 198 Conserve IP Addresses . . . . . . . . . . . . . . . 183
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 184
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 185
Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 188
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 188
Appendix H. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 189
H.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 189
H.2. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201
Intellectual Property and Copyright Statements . . . . . . . . . 202
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World-Wide Web global systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP, information initiative since 1990. The first version of HTTP,
referred to as HTTP/0.9, was a simple protocol for raw data transfer referred to as HTTP/0.9, was a simple protocol for raw data transfer
skipping to change at page 13, line 27 skipping to change at page 15, line 27
1.4. Overall Operation 1.4. Overall Operation
The HTTP protocol is a request/response protocol. A client sends a 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 request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request protocol version, followed by a MIME-like message containing request
modifiers, client information, and possible body content over a modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line, connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code, including the message's protocol version and a success or error code,
followed by a MIME-like message containing server information, entity followed by a MIME-like message containing server information, entity
metainformation, and possible entity-body content. The relationship metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in Appendix A.4. between HTTP and MIME is described in Appendix D.
Most HTTP communication is initiated by a user agent and consists of 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 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) simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O). between the user agent (UA) and the origin server (O).
request chain ------------------------> request chain ------------------------>
UA -------------------v------------------- O UA -------------------v------------------- O
<----------------------- response chain <----------------------- response chain
skipping to change at page 18, line 28 skipping to change at page 20, line 28
DIGIT = <any US-ASCII digit "0".."9"> DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)> (octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)> CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)> LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)> SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)> HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)> <"> = <US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see Appendix A.3 for protocol elements except the entity-body (see Appendix C for tolerant
tolerant applications). The end-of-line marker within an entity-body applications). The end-of-line marker within an entity-body is
is defined by its associated media type, as described in Section 3.7. defined by its associated media type, as described in Section 3.7.
CRLF = CR LF CRLF = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the 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 continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT ) LWS = [CRLF] 1*( SP | HT )
skipping to change at page 22, line 10 skipping to change at page 24, line 10
The "http" scheme is used to locate network resources via the HTTP The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and protocol. This section defines the scheme-specific syntax and
semantics for http URLs. semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics 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 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 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 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 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 [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 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 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 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 receives a fully qualified domain name, the proxy MUST NOT change the
host name. host name.
3.2.3. URI Comparison 3.2.3. URI Comparison
When comparing two URIs to decide if they match or not, a client 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 SHOULD use a case-sensitive octet-by-octet comparison of the entire
URIs, with these exceptions: URIs, with these exceptions:
skipping to change at page 23, line 11 skipping to change at page 25, line 11
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 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 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 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents 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 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 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. 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 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 all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123 format for representing HTTP-date values only generate the RFC 1123 format for representing HTTP-date values
in header fields. See Appendix A.3 for further information. in header fields. See Appendix C for further information.
Note: Recipients of date values are encouraged to be robust in Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP. messages via proxies/gateways to SMTP or NNTP.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
skipping to change at page 29, line 4 skipping to change at page 31, line 4
trailer fields might be silently discarded along the path to the trailer fields might be silently discarded along the path to the
client. client.
This requirement prevents an interoperability failure when the This requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and 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 forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly compliance with the protocol would have necessitated a possibly
infinite buffer on the proxy. infinite buffer on the proxy.
An example process for decoding a Chunked-Body is presented in An example process for decoding a Chunked-Body is presented in
Appendix A.4.6. Appendix D.6.
All HTTP/1.1 applications MUST be able to receive and decode the All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions "chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand. they do not understand.
3.7. Media Types 3.7. Media Types
HTTP uses Internet Media Types [17] in the Content-Type HTTP uses Internet Media Types [17] in the Content-Type
(Section 14.17) and Accept (Section 14.1) header fields in order to (Section 14.17) and Accept (Section 14.1) header fields in order to
provide open and extensible data typing and type negotiation. provide open and extensible data typing and type negotiation.
skipping to change at page 30, line 43 skipping to change at page 32, line 43
therefore use only CRLF to represent line breaks between body-parts. therefore use only CRLF to represent line breaks between body-parts.
Unlike in RFC 2046, the epilogue of any multipart message MUST be Unlike in RFC 2046, the epilogue of any multipart message MUST be
empty; HTTP applications MUST NOT transmit the epilogue (even if the empty; HTTP applications MUST NOT transmit the epilogue (even if the
original multipart contains an epilogue). These restrictions exist original multipart contains an epilogue). These restrictions exist
in order to preserve the self-delimiting nature of a multipart in order to preserve the self-delimiting nature of a multipart
message-body, wherein the "end" of the message-body is indicated by message-body, wherein the "end" of the message-body is indicated by
the ending multipart boundary. the ending multipart boundary.
In general, HTTP treats a multipart message-body no differently than In general, HTTP treats a multipart message-body no differently than
any other media type: strictly as payload. The one exception is the any other media type: strictly as payload. The one exception is the
"multipart/byteranges" type (Appendix A.2) when it appears in a 206 "multipart/byteranges" type (Appendix B) when it appears in a 206
(Partial Content) response, which will be interpreted by some HTTP (Partial Content) response, which will be interpreted by some HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all 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 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. 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- The MIME header fields within each body-part of a multipart message-
body do not have any significance to HTTP beyond that defined by body do not have any significance to HTTP beyond that defined by
their MIME semantics. their MIME semantics.
In general, an HTTP user agent SHOULD follow the same or similar 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. behavior as a MIME user agent would upon receipt of a multipart type.
skipping to change at page 41, line 8 skipping to change at page 43, line 8
to retrieve the resource above directly from the origin server would 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 create a TCP connection to port 80 of the host "www.w3.org" and send
the lines: the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org Host: www.w3.org
followed by the remainder of the Request. Note that the absolute 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 path cannot be empty; if none is present in the original URI, it MUST
be given as "/" (the server root). be given as "/" (the server root).
The Request-URI is transmitted in the format specified in The Request-URI is transmitted in the format specified in section
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
encoding [42], the origin server MUST decode the Request-URI in order [42], the origin server MUST decode the Request-URI in order to
to properly interpret the request. Servers SHOULD respond to invalid properly interpret the request. Servers SHOULD respond to invalid
Request-URIs with an appropriate status code. Request-URIs with an appropriate status code.
A transparent proxy MUST NOT rewrite the "abs_path" part of the A transparent proxy MUST NOT rewrite the "abs_path" part of the
received Request-URI when forwarding it to the next inbound server, received Request-URI when forwarding it to the next inbound server,
except as noted above to replace a null abs_path with "/". except as noted above to replace a null abs_path with "/".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI. rewrite the Request-URI.
5.2. The Resource Identified by a Request 5.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
examining both the Request-URI and the Host header field. examining both the Request-URI and the Host header field.
An origin server that does not allow resources to differ by the An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see determining the resource identified by an HTTP/1.1 request. (But see
Appendix A.6.1.1 for other requirements on Host support in HTTP/1.1.) Appendix F.1.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity host requested (sometimes referred to as virtual hosts or vanity host
names) MUST use the following rules for determining the requested names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request: resource on an HTTP/1.1 request:
1. If Request-URI is an absoluteURI, the host is part of the 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 Request-URI. Any Host header field value in the request MUST be
ignored. ignored.
skipping to change at page 45, line 14 skipping to change at page 47, line 14
Status-Code = Status-Code =
"100" ; Section 10.1.1: Continue "100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols | "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK | "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created | "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted | "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information | "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content | "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content | "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content | "206" ; Section 10.2.7 Partial Content
| "300" ; Section 10.3.1: Multiple Choices | "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently | "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found | "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other | "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified | "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy | "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect | "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request | "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized | "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required | "402" ; Section 10.4.3: Payment Required
skipping to change at page 50, line 36 skipping to change at page 52, line 36
case the client does not want to maintain a connection for more than case the client does not want to maintain a connection for more than
that request, it SHOULD send a Connection header including the that request, it SHOULD send a Connection header including the
connection-token close. connection-token close.
If either the client or the server sends the close token in the If either the client or the server sends the close token in the
Connection header, that request becomes the last one for the Connection header, that request becomes the last one for the
connection. connection.
Clients and servers SHOULD NOT assume that a persistent connection is Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See Appendix A.6.2 for more information on backward signaled. See Appendix F.2 for more information on backward
compatibility with HTTP/1.0 clients. compatibility with HTTP/1.0 clients.
In order to remain persistent, all messages on the connection MUST In order to remain persistent, all messages on the connection MUST
have a self-defined message length (i.e., one not defined by closure have a self-defined message length (i.e., one not defined by closure
of the connection), as described in Section 4.4. of the connection), as described in Section 4.4.
8.1.2.2. Pipelining 8.1.2.2. Pipelining
A client that supports persistent connections MAY "pipeline" its A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each requests (i.e., send multiple requests without waiting for each
skipping to change at page 100, line 35 skipping to change at page 102, line 35
Warning: unnecessary modification of end-to-end headers might Warning: unnecessary modification of end-to-end headers might
cause authentication failures if stronger authentication cause authentication failures if stronger authentication
mechanisms are introduced in later versions of HTTP. Such mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields authentication mechanisms MAY rely on the values of header fields
not listed here. not listed here.
The Content-Length field of a request or response is added or deleted 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 according to the rules in Section 4.4. A transparent proxy MUST
preserve the entity-length (Section 7.2.2) of the entity-body, preserve the entity-length (Section 7.2.2) of the entity-body,
although it MAY change the transfer-length (Section 4.4). although it MAY change the transfer-length (section Section 4.4).
13.5.3. Combining Headers 13.5.3. Combining Headers
When a cache makes a validating request to a server, and the server When a cache makes a validating request to a server, and the server
provides a 304 (Not Modified) response or a 206 (Partial Content) provides a 304 (Not Modified) response or a 206 (Partial Content)
response, the cache then constructs a response to send to the response, the cache then constructs a response to send to the
requesting client. requesting client.
If the status code is 304 (Not Modified), the cache uses the entity- 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 body stored in the cache entry as the entity-body of this outgoing
skipping to change at page 111, line 14 skipping to change at page 113, line 14
agent or client. agent or client.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues will not associated with content-codings. This means that qvalues will not
work and are not permitted with x-gzip or x-compress. work and are not permitted with x-gzip or x-compress.
14.4. Accept-Language 14.4. Accept-Language
The Accept-Language request-header field is similar to Accept, but The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a restricts the set of natural languages that are preferred as a
response to the request. Language tags are defined in Section 3.10. response to the request. Language tags are defined in section
Section 3.10.
Accept-Language = "Accept-Language" ":" Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] ) 1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Each language-range MAY be given an associated quality value which Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For specified by that range. The quality value defaults to "q=1". For
example, example,
skipping to change at page 125, line 5 skipping to change at page 127, line 15
after the current request/response is complete. after the current request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message. include the "close" connection option in every message.
A system receiving an HTTP/1.0 (or lower-version) message that A system receiving an HTTP/1.0 (or lower-version) message that
includes a Connection header MUST, for each connection-token in this includes a Connection header MUST, for each connection-token in this
field, remove and ignore any header field(s) from the message with field, remove and ignore any header field(s) from the message with
the same name as the connection-token. This protects against the same name as the connection-token. This protects against
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
See Appendix A.6.2. See Appendix F.2.
14.11. Content-Encoding 14.11. Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional media-type. When present, its value indicates what additional
content codings have been applied to the entity-body, and thus what content codings have been applied to the entity-body, and thus what
decoding mechanisms must be applied in order to obtain the media-type decoding mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing primarily used to allow a document to be compressed without losing
the identity of its underlying media type. the identity of its underlying media type.
skipping to change at page 130, line 11 skipping to change at page 132, line 21
A server sending a response with status code 416 (Requested range not A server sending a response with status code 416 (Requested range not
satisfiable) SHOULD include a Content-Range field with a byte-range- satisfiable) SHOULD include a Content-Range field with a byte-range-
resp-spec of "*". The instance-length specifies the current length resp-spec of "*". The instance-length specifies the current length
of the selected resource. A response with status code 206 (Partial of the selected resource. A response with status code 206 (Partial
Content) MUST NOT include a Content-Range field with a byte-range- Content) MUST NOT include a Content-Range field with a byte-range-
resp-spec of "*". resp-spec of "*".
Examples of byte-content-range-spec values, assuming that the entity Examples of byte-content-range-spec values, assuming that the entity
contains a total of 1234 bytes: contains a total of 1234 bytes:
o The first 500 bytes: . The first 500 bytes:
bytes 0-499/1234 bytes 0-499/1234
o The second 500 bytes: . The second 500 bytes:
bytes 500-999/1234 bytes 500-999/1234
o All except for the first 500 bytes: . All except for the first 500 bytes:
bytes 500-1233/1234 bytes 500-1233/1234
o The last 500 bytes: . The last 500 bytes:
bytes 734-1233/1234 bytes 734-1233/1234
When an HTTP message includes the content of a single range (for 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 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 for a set of ranges that overlap without any holes), this content is
transmitted with a Content-Range header, and a Content-Length header transmitted with a Content-Range header, and a Content-Length header
showing the number of bytes actually transferred. For example, showing the number of bytes actually transferred. For example,
HTTP/1.1 206 Partial content HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022 Content-Range: bytes 21010-47021/47022
Content-Length: 26012 Content-Length: 26012
Content-Type: image/gif Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart message. The multipart ranges), these are transmitted as a multipart message. The multipart
media type used for this purpose is "multipart/byteranges" as defined media type used for this purpose is "multipart/byteranges" as defined
in Appendix A.2. See Appendix A.6.3 for a compatibility issue. in Appendix B. See Appendix F.3 for a compatibility issue.
A response to a request for a single range MUST NOT be sent using the 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 multipart/byteranges media type. A response to a request for
multiple ranges, whose result is a single range, MAY be sent as a multiple ranges, whose result is a single range, MAY be sent as a
multipart/byteranges media type with one part. A client that cannot multipart/byteranges media type with one part. A client that cannot
decode a multipart/byteranges message MUST NOT ask for multiple byte- decode a multipart/byteranges message MUST NOT ask for multiple byte-
ranges in a single request. ranges in a single request.
When a client requests multiple byte-ranges in one request, the When a client requests multiple byte-ranges in one request, the
server SHOULD return them in the order that they appeared in the server SHOULD return them in the order that they appeared in the
skipping to change at page 136, line 22 skipping to change at page 138, line 30
A client MUST include a Host header field in all HTTP/1.1 request 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 messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field MUST 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 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 request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 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 status code to any HTTP/1.1 request message which lacks a Host header
field. field.
See sections 5.2 and A.6.1.1 for other requirements relating to Host. See sections 5.2 and F.1.1 for other requirements relating to Host.
14.24. If-Match 14.24. If-Match
The If-Match request-header field is used with a method to make it The If-Match request-header field is used with a method to make it
conditional. A client that has one or more entities previously conditional. A client that has one or more entities previously
obtained from the resource can verify that one of those entities is obtained from the resource can verify that one of those entities is
current by including a list of their associated entity tags in the 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 If-Match header field. Entity tags are defined in Section 3.11. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. It is information with a minimum amount of transaction overhead. It is
skipping to change at page 162, line 8 skipping to change at page 164, line 8
If a single server supports multiple organizations that do not trust If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content- one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
15.5. Content-Disposition Issues 15.5. Content-Disposition Issues
RFC 1806 [35], from which the often implemented Content-Disposition RFC 1806 [35], from which the often implemented Content-Disposition
(see Appendix A.5.1) header in HTTP is derived, has a number of very (see Appendix E.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 [49] documenting its use and risks for implementors. See RFC 2183 [49]
(which updates RFC 1806) for details. (which updates RFC 1806) for details.
15.6. Authentication Credentials and Idle Clients 15.6. Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a information indefinitely. HTTP/1.1. does not provide a method for a
server to direct clients to discard these cached credentials. This server to direct clients to discard these cached credentials. This
skipping to change at page 164, line 7 skipping to change at page 166, line 7
protect against a broad range of security and privacy attacks. Such protect against a broad range of security and privacy attacks. Such
cryptography is beyond the scope of the HTTP/1.1 specification. cryptography is beyond the scope of the HTTP/1.1 specification.
15.7.1. Denial of Service Attacks on Proxies 15.7.1. Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues. They exist. They are hard to defend against. Research continues.
Beware. Beware.
16. Acknowledgments 16. Acknowledgments
16.1. (RFC2616)
This specification makes heavy use of the augmented BNF and generic This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for RFC 822 [9]. Similarly, constructs defined by David H. Crocker for RFC 822 [9]. Similarly,
it reuses many of the definitions provided by Nathaniel Borenstein it reuses many of the definitions provided by Nathaniel Borenstein
and Ned Freed for MIME [7]. We hope that their inclusion in this and Ned Freed for MIME [7]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats. between HTTP and Internet mail message formats.
The HTTP protocol has evolved considerably over the years. It has The HTTP protocol has evolved considerably over the years. It has
benefited from a large and active developer community--the many benefited from a large and active developer community--the many
people who have participated on the www-talk mailing list--and it is people who have participated on the www-talk mailing list--and it is
skipping to change at page 166, line 5 skipping to change at page 168, line 5
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
Larry Masinter for their help. And thanks go particularly to Jeff Larry Masinter for their help. And thanks go particularly to Jeff
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
Frystyk implemented RFC 2068 early, and we wish to thank them for the Frystyk implemented RFC 2068 early, and we wish to thank them for the
discovery of many of the problems that this document attempts to discovery of many of the problems that this document attempts to
rectify. rectify.
16.2. (This Document)
This document is based on [50], which was authored by Roy T.
Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen,
Larry Masinter, Paul J. Leach and Tim Berners-Lee.
17. References 17. References
17.1. References
[1] Alvestrand, H., "Tags for the Identification of Languages", [1] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995. RFC 1766, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
D., and B. Alberti, "The Internet Gopher Protocol (a D., and B. Alberti, "The Internet Gopher Protocol (a
distributed document search and retrieval protocol)", RFC 1436, distributed document search and retrieval protocol)", RFC 1436,
March 1993. March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of Unifying Syntax for the Expression of Names and Addresses of
skipping to change at page 167, line 16 skipping to change at page 170, line 17
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
[15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", [15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML",
RFC 1867, November 1995. RFC 1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982. August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
November 1996. March 1994.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985. RFC 959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. RFC 1700, October 1994.
[20] Masinter, L. and K. Sollins, "Functional Requirements for [20] Masinter, L. and K. Sollins, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994. Uniform Resource Names", RFC 1737, December 1994.
skipping to change at page 169, line 32 skipping to change at page 172, line 35
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
servers", Work in Progress. servers", Work in Progress.
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2110, Aggregate Documents, such as HTML (MHTML)", RFC 2110,
March 1997. March 1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", [46] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, April 1998. (HTCPCP/1.0)", RFC 2324, April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996. Examples", RFC 2049, November 1996.
[49] Troost, R., Dorner, S., and K. Moore, "Communicating [49] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997. Disposition Header Field", RFC 2183, August 1997.
Appendix A. Appendices 17.2. Normative References
A.1. Internet Media Type message/http and application/http [50] 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.
URIs
[51] <mailto:ietf-http-wg@w3.org>
[52] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
Appendix A. Internet Media Type message/http and application/http
In addition to defining the HTTP/1.1 protocol, this document serves In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type "message/http" and as the specification for the Internet media type "message/http" and
"application/http". The message/http type can be used to enclose a "application/http". The message/http type can be used to enclose a
single HTTP request or response message, provided that it obeys the single HTTP request or response message, provided that it obeys the
MIME restrictions for all "message" types regarding line length and MIME restrictions for all "message" types regarding line length and
encodings. The application/http type can be used to enclose a encodings. The application/http type can be used to enclose a
pipeline of one or more HTTP request or response messages (not pipeline of one or more HTTP request or response messages (not
intermixed). The following is to be registered with IANA [17]. intermixed). The following is to be registered with IANA [17].
skipping to change at page 171, line 15 skipping to change at page 176, line 5
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via E-mail.
Security considerations: none Security considerations: none
A.2. Internet Media Type multipart/byteranges Appendix B. Internet Media Type multipart/byteranges
When an HTTP 206 (Partial Content) response message includes the When an HTTP 206 (Partial Content) response message includes the
content of multiple ranges (a response to a request for multiple non- content of multiple ranges (a response to a request for multiple non-
overlapping ranges), these are transmitted as a multipart message- overlapping ranges), these are transmitted as a multipart message-
body. The media type for this purpose is called "multipart/ body. The media type for this purpose is called "multipart/
byteranges". byteranges".
The multipart/byteranges media type includes two or more parts, each The multipart/byteranges media type includes two or more parts, each
with its own Content-Type and Content-Range fields. The required with its own Content-Type and Content-Range fields. The required
boundary parameter specifies the boundary string used to separate boundary parameter specifies the boundary string used to separate
skipping to change at page 172, line 37 skipping to change at page 178, line 5
2. Although RFC 2046 [40] permits the boundary string to be quoted, 2. Although RFC 2046 [40] permits the boundary string to be quoted,
some existing implementations handle a quoted boundary string some existing implementations handle a quoted boundary string
incorrectly. incorrectly.
3. A number of browsers and servers were coded to an early draft of 3. A number of browsers and servers were coded to an early draft of
the byteranges specification to use a media type of multipart/ the byteranges specification to use a media type of multipart/
x-byteranges, which is almost, but not quite compatible with the x-byteranges, which is almost, but not quite compatible with the
version documented in HTTP/1.1. version documented in HTTP/1.1.
A.3. Tolerant Applications Appendix C. Tolerant Applications
Although this document specifies the requirements for the generation Although this document specifies the requirements for the generation
of HTTP/1.1 messages, not all applications will be correct in their of HTTP/1.1 messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be be tolerant of deviations whenever those deviations can be
interpreted unambiguously. interpreted unambiguously.
Clients SHOULD be tolerant in parsing the Status-Line and servers Clients SHOULD be tolerant in parsing the Status-Line and servers
tolerant when parsing the Request-Line. In particular, they SHOULD tolerant when parsing the Request-Line. In particular, they SHOULD
accept any amount of SP or HT characters between fields, even though accept any amount of SP or HT characters between fields, even though
skipping to change at page 173, line 32 skipping to change at page 179, line 5
proper value. proper value.
o All expiration-related calculations MUST be done in GMT. The o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison local time zone MUST NOT influence the calculation or comparison
of an age or expiration time. of an age or expiration time.
o If an HTTP header incorrectly carries a date value with a time o If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it MUST be converted into GMT using the most zone other than GMT, it MUST be converted into GMT using the most
conservative possible conversion. conservative possible conversion.
A.4. Differences Between HTTP Entities and RFC 2045 Entities Appendix D. Differences Between HTTP Entities and RFC 2045 Entities
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
allow entities to be transmitted in an open variety of allow entities to be transmitted in an open variety of
representations and with extensible mechanisms. However, RFC 2045 representations and with extensible mechanisms. However, RFC 2045
discusses mail, and HTTP has a few features that are different from discusses mail, and HTTP has a few features that are different from
those described in RFC 2045. These differences were carefully chosen those described in RFC 2045. These differences were carefully chosen
to optimize performance over binary connections, to allow greater to optimize performance over binary connections, to allow greater
freedom in the use of new media types, to make date comparisons freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers easier, and to acknowledge the practice of some early HTTP servers
and clients. and clients.
This appendix describes specific areas where HTTP differs from RFC This appendix describes specific areas where HTTP differs from RFC
2045. Proxies and gateways to strict MIME environments SHOULD be 2045. Proxies and gateways to strict MIME environments SHOULD be
aware of these differences and provide the appropriate conversions aware of these differences and provide the appropriate conversions
where necessary. Proxies and gateways from MIME environments to HTTP where necessary. Proxies and gateways from MIME environments to HTTP
also need to be aware of the differences because some conversions also need to be aware of the differences because some conversions
might be required. might be required.
A.4.1. MIME-Version D.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
MAY include a single MIME-Version general-header field to indicate MAY include a single MIME-Version general-header field to indicate
what version of the MIME protocol was used to construct the message. 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 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]). full compliance with the MIME protocol (as defined in RFC 2045[7]).
Proxies/gateways are responsible for ensuring full compliance (where Proxies/gateways are responsible for ensuring full compliance (where
possible) when exporting HTTP messages to strict MIME environments. possible) when exporting HTTP messages to strict MIME environments.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME version "1.0" is the default for use in HTTP/1.1. However, 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 HTTP/1.1 message parsing and semantics are defined by this document
and not the MIME specification. and not the MIME specification.
A.4.2. Conversion to Canonical Form D.2. Conversion to Canonical Form
RFC 2045 [7] requires that an Internet mail entity be converted to RFC 2045 [7] requires that an Internet mail entity be converted to
canonical form prior to being transferred, as described in section 4 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 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 allowed for subtypes of the "text" media type when transmitted over
HTTP. RFC 2046 requires that content with a type of "text" represent 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 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 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate
a line break within text content when a message is transmitted over a line break within text content when a message is transmitted over
HTTP. HTTP.
skipping to change at page 174, line 47 skipping to change at page 180, line 19
complicated by the presence of a Content-Encoding and by the fact 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 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 octets 13 and 10 to represent CR and LF, as is the case for some
multi-byte character sets. multi-byte character sets.
Implementors should note that conversion will break any cryptographic Implementors should note that conversion will break any cryptographic
checksums applied to the original content unless the original content checksums applied to the original content unless the original content
is already in canonical form. Therefore, the canonical form is is already in canonical form. Therefore, the canonical form is
recommended for any content that uses such checksums in HTTP. recommended for any content that uses such checksums in HTTP.
A.4.3. Conversion of Date Formats D.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to 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 simplify the process of date comparison. Proxies and gateways from
other protocols SHOULD ensure that any Date header field present in a 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 message conforms to one of the HTTP/1.1 formats and rewrite the date
if necessary. if necessary.
A.4.4. Introduction of Content-Encoding D.4. Introduction of Content-Encoding
RFC 2045 does not include any concept equivalent to HTTP/1.1's 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 Content-Encoding header field. Since this acts as a modifier on the
media type, proxies and gateways from HTTP to MIME-compliant media type, proxies and gateways from HTTP to MIME-compliant
protocols MUST either change the value of the Content-Type header protocols MUST either change the value of the Content-Type header
field or decode the entity-body before forwarding the message. (Some field or decode the entity-body before forwarding the message. (Some
experimental applications of Content-Type for Internet mail have used experimental applications of Content-Type for Internet mail have used
a media-type parameter of ";conversions=<content-coding>" to perform a media-type parameter of ";conversions=<content-coding>" to perform
a function equivalent to Content-Encoding. However, this parameter a function equivalent to Content-Encoding. However, this parameter
is not part of RFC 2045). is not part of RFC 2045).
A.4.5. No Content-Transfer-Encoding D.5. No Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP 2045. Proxies and gateways from MIME-compliant protocols to HTTP
MUST remove any non-identity CTE ("quoted-printable" or "base64") MUST remove any non-identity CTE ("quoted-printable" or "base64")
encoding prior to delivering the response message to an HTTP client. encoding prior to delivering the response message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used. transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway SHOULD label the data with an appropriate Such a proxy or gateway SHOULD label the data with an appropriate
Content-Transfer-Encoding if doing so will improve the likelihood of Content-Transfer-Encoding if doing so will improve the likelihood of
safe transport over the destination protocol. safe transport over the destination protocol.
A.4.6. Introduction of Transfer-Encoding D.6. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 14.41). Proxies/gateways MUST remove any transfer-coding (Section 14.41). Proxies/gateways MUST remove any transfer-coding
prior to forwarding a message via a MIME-compliant protocol. prior to forwarding a message via a MIME-compliant protocol.
A process for decoding the "chunked" transfer-coding (Section 3.6) A process for decoding the "chunked" transfer-coding (Section 3.6)
can be represented in pseudo-code as: can be represented in pseudo-code as:
length := 0 length := 0
read chunk-size, chunk-extension (if any) and CRLF read chunk-size, chunk-extension (if any) and CRLF
skipping to change at page 176, line 21 skipping to change at page 181, line 30
read chunk-size and CRLF read chunk-size and CRLF
} }
read entity-header read entity-header
while (entity-header not empty) { while (entity-header not empty) {
append entity-header to existing header fields append entity-header to existing header fields
read entity-header read entity-header
} }
Content-Length := length Content-Length := length
Remove "chunked" from Transfer-Encoding Remove "chunked" from Transfer-Encoding
A.4.7. MHTML and Line Length Limitations D.7. MHTML and Line Length Limitations
HTTP implementations which share code with MHTML [45] implementations HTTP implementations which share code with MHTML [45] implementations
need to be aware of MIME line length limitations. Since HTTP does need to be aware of MIME line length limitations. Since HTTP does
not have this limitation, HTTP does not fold long lines. MHTML not have this limitation, HTTP does not fold long lines. MHTML
messages being transported by HTTP follow all conventions of MHTML, messages being transported by HTTP follow all conventions of MHTML,
including line length limitations and folding, canonicalization, including line length limitations and folding, canonicalization,
etc., since HTTP transports all message-bodies as payload (see etc., since HTTP transports all message-bodies as payload (see
Section 3.7.2) and does not interpret the content or any MIME header Section 3.7.2) and does not interpret the content or any MIME header
lines that might be contained therein. lines that might be contained therein.
A.5. Additional Features Appendix E. Additional Features
RFC 1945 and RFC 2068 document protocol elements used by some RFC 1945 and RFC 2068 document protocol elements used by some
existing HTTP implementations, but not consistently and correctly existing HTTP implementations, but not consistently and correctly
across most HTTP/1.1 applications. Implementors are advised to be across most HTTP/1.1 applications. Implementors are advised to be
aware of these features, but cannot rely upon their presence in, or aware of these features, but cannot rely upon their presence in, or
interoperability with, other HTTP/1.1 applications. Some of these interoperability with, other HTTP/1.1 applications. Some of these
describe proposed experimental features, and some describe features describe proposed experimental features, and some describe features
that experimental deployment found lacking that are now addressed in that experimental deployment found lacking that are now addressed in
the base HTTP/1.1 specification. the base HTTP/1.1 specification.
A number of other headers, such as Content-Disposition and Title, A number of other headers, such as Content-Disposition and Title,
from SMTP and MIME are also often implemented (see RFC 2076 [37]). from SMTP and MIME are also often implemented (see RFC 2076 [37]).
A.5.1. Content-Disposition E.1. Content-Disposition
The Content-Disposition response-header field has been proposed as a The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user 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 requests that the content is saved to a file. This usage is derived
from the definition of Content-Disposition in RFC 1806 [35]. from the definition of Content-Disposition in RFC 1806 [35].
content-disposition = "Content-Disposition" ":" content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm ) disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm disposition-parm = filename-parm | disp-extension-parm
skipping to change at page 177, line 29 skipping to change at page 183, line 5
parameter believed to apply to HTTP implementations at this time. parameter believed to apply to HTTP implementations at this time.
The filename SHOULD be treated as a terminal component only. The filename SHOULD be treated as a terminal component only.
If this header is used in a response with the application/ If this header is used in a response with the application/
octet-stream content-type, the implied suggestion is that the user octet-stream content-type, the implied suggestion is that the user
agent should not display the response, but directly enter a `save agent should not display the response, but directly enter a `save
response as...' dialog. response as...' dialog.
See Section 15.5 for Content-Disposition security issues. See Section 15.5 for Content-Disposition security issues.
A.6. Compatibility with Previous Versions Appendix F. Compatibility with Previous Versions
It is beyond the scope of a protocol specification to mandate It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately compliance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. It is designed, however, to make supporting previous versions easy. It is
worth noting that, at the time of composing this specification worth noting that, at the time of composing this specification
(1996), we would expect commercial HTTP/1.1 servers to: (1996), we would expect commercial HTTP/1.1 servers to:
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and o recognize the format of the Request-Line for HTTP/0.9, 1.0, and
1.1 requests; 1.1 requests;
skipping to change at page 178, line 8 skipping to change at page 183, line 33
o recognize the format of the Status-Line for HTTP/1.0 and 1.1 o recognize the format of the Status-Line for HTTP/1.0 and 1.1
responses; responses;
o understand any valid response in the format of HTTP/0.9, 1.0, or o understand any valid response in the format of HTTP/0.9, 1.0, or
1.1. 1.1.
For most implementations of HTTP/1.0, each connection is established For most implementations of HTTP/1.0, each connection is established
by the client prior to the request and closed by the server after by the client prior to the request and closed by the server after
sending the response. Some implementations implement the Keep-Alive sending the response. Some implementations implement the Keep-Alive
version of persistent connections described in Section 19.7.1 of RFC version of persistent connections described in section 19.7.1 of RFC
2068 [33]. 2068 [33].
A.6.1. Changes from HTTP/1.0 F.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.6.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP F.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses Addresses
The requirements that clients and servers support the Host request- The requirements that clients and servers support the Host request-
header, report an error if the Host request-header (Section 14.23) is header, report an error if the Host request-header (Section 14.23) is
missing from an HTTP/1.1 request, and accept absolute URIs missing from an HTTP/1.1 request, and accept absolute URIs (section
(Section 5.1.2) are among the most important changes defined by this 5.1.2) are among the most important changes defined by this
specification. specification.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The changes outlined above will to which that request was directed. The changes outlined above will
allow the Internet, once older HTTP clients are no longer common, to allow the Internet, once older HTTP clients are no longer common, to
support multiple Web sites from a single IP address, greatly support multiple Web sites from a single IP address, greatly
simplifying large operational Web servers, where allocation of many simplifying large operational Web servers, where allocation of many
IP addresses to a single host has created serious problems. The IP addresses to a single host has created serious problems. The
skipping to change at page 179, line 5 skipping to change at page 184, line 26
o Both clients and servers MUST support the Host request-header. o Both clients and servers MUST support the Host request-header.
o A client that sends an HTTP/1.1 request MUST send a Host header. o A client that sends an HTTP/1.1 request MUST send a Host header.
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header. request does not include a Host request-header.
o Servers MUST accept absolute URIs. o Servers MUST accept absolute URIs.
A.6.2. Compatibility with HTTP/1.0 Persistent Connections F.2. Compatibility with HTTP/1.0 Persistent Connections
Some clients and servers might wish to be compatible with some Some clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0 previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections in HTTP/1.0 are clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0 explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections are faulty, experimental implementations of persistent connections are faulty,
and the new facilities in HTTP/1.1 are designed to rectify these 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 problems. The problem was that some existing 1.0 clients may be
sending Keep-Alive to a proxy server that doesn't understand sending Keep-Alive to a proxy server that doesn't understand
Connection, which would then erroneously forward it to the next Connection, which would then erroneously forward it to the next
skipping to change at page 179, line 32 skipping to change at page 185, line 5
connections, so that prohibition is clearly unacceptable. Therefore, connections, so that prohibition is clearly unacceptable. Therefore,
we need some other mechanism for indicating a persistent connection we need some other mechanism for indicating a persistent connection
is desired, which is safe to use even when talking to an old proxy is desired, which is safe to use even when talking to an old proxy
that ignores Connection. Persistent connections are the default for that ignores Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence. See Section 14.10. declaring non-persistence. See Section 14.10.
The original HTTP/1.0 form of persistent connections (the Connection: The original HTTP/1.0 form of persistent connections (the Connection:
Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
A.6.3. Changes from RFC 2068 F.3. Changes from RFC 2068
This specification has been carefully audited to correct and This specification has been carefully audited to correct and
disambiguate key word usage; RFC 2068 had many problems in respect to disambiguate key word usage; RFC 2068 had many problems in respect to
the conventions laid out in RFC 2119 [34]. the conventions laid out in RFC 2119 [34].
Clarified which error code should be used for inbound server failures Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 10.5.5). (e.g. DNS failures). (Section 10.5.5).
CREATE had a race that required an Etag be sent when a resource is CREATE had a race that required an Etag be sent when a resource is
first created. (Section 10.2.2). first created. (Section 10.2.2).
skipping to change at page 183, line 5 skipping to change at page 188, line 5
clients.(Section 3.6, 3.6.1, and 14.39) clients.(Section 3.6, 3.6.1, and 14.39)
The PATCH, LINK, UNLINK methods were defined but not commonly The PATCH, LINK, UNLINK methods were defined but not commonly
implemented in previous versions of this specification. See RFC 2068 implemented in previous versions of this specification. See RFC 2068
[33]. [33].
The Alternates, Content-Version, Derived-From, Link, URI, Public and The Alternates, Content-Version, Derived-From, Link, URI, Public and
Content-Base header fields were defined in previous versions of this Content-Base header fields were defined in previous versions of this
specification, but not commonly implemented. See RFC 2068 [33]. specification, but not commonly implemented. See RFC 2068 [33].
Appendix B. Index Appendix G. Change Log (to be removed by RFC Editor before publication)
Please see the PostScript version of this RFC for the INDEX. G.1. Since RFC2616
Update Authors. Add Editorial Note and Acknowledgements (containing
the original RFC2616 authors). Add "Normative References",
containing just RFC2616 for now.
Appendix H. Open issues (to be removed by RFC Editor prior to
publication)
H.1. rfc2616bis
Type: edit
julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes
with respect to the revision process itself.
H.2. edit
Type: edit
julian.reschke@greenbytes.de (2006-08-10): Umbrella issue for
editorial fixes/enhancements.
Index Index
1 1
100 Continue (status code) 63 100 Continue (status code) 65
101 Switching Protocols (status code) 63 101 Switching Protocols (status code) 65
110 Response is stale (warn code) 156
111 Revalidation failed (warn code) 156
112 Disconnected operation (warn code) 156
113 Heuristic expiration (warn code) 156
199 Miscellaneous warning (warn code) 156
2 2
200 OK (status code) 64 200 OK (status code) 66
201 Created (status code) 64 201 Created (status code) 66
202 Accepted (status code) 64 202 Accepted (status code) 66
203 Non-Authoritative Information (status code) 65 203 Non-Authoritative Information (status code) 67
204 No Content (status code) 65 204 No Content (status code) 67
205 Reset Content (status code) 65 205 Reset Content (status code) 67
206 Partial Content (status code) 66 206 Partial Content (status code) 68
214 Transformation applied (warn code) 156
299 Miscellaneous persistent warning (warn code) 157
3 3
300 Multiple Choices (status code) 67 300 Multiple Choices (status code) 69
301 Moved Permanently (status code) 67 301 Moved Permanently (status code) 69
302 Found (status code) 68 302 Found (status code) 70
303 See Other (status code) 68 303 See Other (status code) 70
304 Not Modified (status code) 69 304 Not Modified (status code) 71
305 Use Proxy (status code) 69 305 Use Proxy (status code) 71
306 (Unused) (status code) 70 306 (Unused) (status code) 72
307 Temporary Redirect (status code) 70 307 Temporary Redirect (status code) 72
4 4
400 Bad Request (status code) 71 400 Bad Request (status code) 73
401 Unauthorized (status code) 71 401 Unauthorized (status code) 73
402 Payment Required (status code) 71 402 Payment Required (status code) 73
403 Forbidden (status code) 71 403 Forbidden (status code) 73
404 Not Found (status code) 71 404 Not Found (status code) 73
405 Method Not Allowed (status code) 72 405 Method Not Allowed (status code) 74
406 Not Acceptable (status code) 72 406 Not Acceptable (status code) 74
407 Proxy Authentication Required (status code) 72 407 Proxy Authentication Required (status code) 74
408 Request Timeout (status code) 73 408 Request Timeout (status code) 75
409 Conflict (status code) 73 409 Conflict (status code) 75
410 Gone (status code) 73 410 Gone (status code) 75
411 Length Required (status code) 74 411 Length Required (status code) 76
412 Precondition Failed (status code) 74 412 Precondition Failed (status code) 76
413 Request Entity Too Large (status code) 74 413 Request Entity Too Large (status code) 76
414 Request-URI Too Long (status code) 74 414 Request-URI Too Long (status code) 76
415 Unsupported Media Type (status code) 74 415 Unsupported Media Type (status code) 76
416 Requested Range Not Satisfiable (status code) 74 416 Requested Range Not Satisfiable (status code) 76
417 Expectation Failed (status code) 75 417 Expectation Failed (status code) 77
5 5
500 Internal Server Error (status code) 75 500 Internal Server Error (status code) 77
501 Not Implemented (status code) 75 501 Not Implemented (status code) 77
502 Bad Gateway (status code) 75 502 Bad Gateway (status code) 77
503 Service Unavailable (status code) 76 503 Service Unavailable (status code) 78
504 Gateway Timeout (status code) 76 504 Gateway Timeout (status code) 78
505 HTTP Version Not Supported (status code) 76 505 HTTP Version Not Supported (status code) 78
A A
Accept header 107 Accept header 109
Accept-Charset header 109 Accept-Charset header 111
Accept-Encoding header 109 Accept-Encoding header 111
Accept-Language header 111 Accept-Language header 113
Accept-Ranges header 112 Accept-Ranges header 114
Age header 112 Age header 114
age 12 age 14
Allow header 113 Allow header 115
Alternates header 182 Authorization header 116
application/http Media Type 170
Authorization header 113
C C
Cache Directives Cache Directives
max-age 119, 121 max-age 121, 123
max-stale 119 max-stale 121
min-fresh 119 min-fresh 121
must-revalidate 121 must-revalidate 123
no-cache 117 no-cache 119
no-store 117 no-store 119
no-transform 122 no-transform 125
only-if-cached 121 only-if-cached 123
private 116 private 118
proxy-revalidate 122 proxy-revalidate 124
public 116 public 118
s-maxage 118 s-maxage 120
cache 11 cache 13
Cache-Control header 114 Cache-Control header 116
cacheable 11 cacheable 13
client 10 client 12
compress (content coding) 25 compress 27
CONNECT method 62 CONNECT method 64
Connection header 124 Connection header 126
connection 9 connection 11
Content Codings 25 content negotiation 12
compress 25 Content-Encoding header 127
deflate 26 Content-Language header 128
gzip 25 Content-Length header 128
identity 26 Content-Location header 129
content negotiation 10 Content-MD5 header 130
Content-Base header 182 Content-Range header 131
Content-Disposition header 176 Content-Type header 133
Content-Encoding header 125
Content-Language header 125
Content-Length header 126
Content-Location header 127
Content-MD5 header 128
Content-Range header 129
Content-Type header 131
Content-Version header 182
D D
Date header 131 Date header 133
deflate (content coding) 26 deflate 28
DELETE method 61 DELETE method 63
Derived-From header 182 downstream 15
downstream 13
E E
entity 9 entity 11
ETag header 133 ETag header 135
Expect header 133 Expect header 135
Expires header 134 Expires header 136
explicit expiration time 12 explicit expiration time 14
F F
first-hand 11 first-hand 13
fresh 12 fresh 14
freshness lifetime 12 freshness lifetime 14
From header 135 From header 137
G G
gateway 11 gateway 13
GET method 58 GET method 60
Grammar Grammar
Accept 107 Accept 109
Accept-Charset 109 Accept-Charset 111
Accept-Encoding 109 Accept-Encoding 111
accept-extension 107 accept-extension 109
Accept-Language 111 Accept-Language 113
accept-params 107 accept-params 109
Accept-Ranges 112 Accept-Ranges 114
acceptable-ranges 112 acceptable-ranges 114
Age 113 Age 115
age-value 113 age-value 115
Allow 113 Allow 115
ALPHA 18 ALPHA 20
asctime-date 23 asctime-date 25
attribute 26 attribute 28
Authorization 114 Authorization 116
byte-content-range-spec 129 byte-content-range-spec 131
byte-range-resp-spec 129 byte-range-resp-spec 131
byte-range-set 145 byte-range-set 147
byte-range-spec 145 byte-range-spec 147
byte-ranges-specifier 145 byte-ranges-specifier 147
bytes-unit 33 bytes-unit 35
Cache-Control 115 Cache-Control 117
cache-directive 115 cache-directive 117
cache-extension 115 cache-extension 117
cache-request-directive 115 cache-request-directive 117
cache-response-directive 115 cache-response-directive 117
CHAR 18 CHAR 20
charset 24 charset 26
chunk 28 chunk 30
chunk-data 28 chunk-data 30
chunk-ext-name 28 chunk-ext-name 30
chunk-ext-val 28 chunk-ext-val 30
chunk-extension 28 chunk-extension 30
chunk-size 28 chunk-size 30
Chunked-Body 28 Chunked-Body 30
codings 109 codings 111
comment 19 comment 21
Connection 124 Connection 126
connection-token 124 connection-token 126
content-coding 25 content-coding 27
content-disposition 177 content-disposition 182
Content-Encoding 125 Content-Encoding 127
Content-Language 125 Content-Language 128
Content-Length 126 Content-Length 128
Content-Location 127 Content-Location 129
Content-MD5 128 Content-MD5 130
Content-Range 129 Content-Range 131
content-range-spec 129 content-range-spec 131
Content-Type 131 Content-Type 133
CR 18 CR 20
CRLF 18 CRLF 20
ctext 19 ctext 21
CTL 18 CTL 20
Date 131 Date 134
date1 23 date1 25
date2 23 date2 25
date3 23 date3 25
delta-seconds 24 delta-seconds 26
DIGIT 18 DIGIT 20
disp-extension-parm 177 disp-extension-parm 182
disp-extension-token 177 disp-extension-token 182
disposition-parm 177 disposition-parm 182
disposition-type 177 disposition-type 182
entity-body 47 entity-body 49
entity-header 47 entity-header 49
entity-tag 32 entity-tag 34
ETag 133 ETag 135
Expect 133 Expect 135
expect-params 133 expect-params 135
expectation 133 expectation 135
expectation-extension 133 expectation-extension 135
Expires 134 Expires 136
extension-code 45 extension-code 47
extension-header 47 extension-header 49
extension-method 39 extension-method 41
extension-pragma 143 extension-pragma 145
field-content 35 field-content 37
field-name 35 field-name 37
field-value 35 field-value 37
filename-parm 177 filename-parm 182
first-byte-pos 145 first-byte-pos 147
From 135 From 137
general-header 38 general-header 40
generic-message 34 generic-message 36
HEX 19 HEX 21
Host 135 Host 138
HT 18 HT 20
HTTP-date 23 HTTP-date 25
HTTP-message 34 HTTP-message 36
HTTP-Version 20 HTTP-Version 22
http_URL 21 http_URL 23
If-Match 136 If-Match 138
If-Modified-Since 137 If-Modified-Since 139
If-None-Match 139 If-None-Match 141
If-Range 140 If-Range 142
If-Unmodified-Since 141 If-Unmodified-Since 143
instance-length 129 instance-length 131
language-range 111 language-range 113
language-tag 32 language-tag 34
last-byte-pos 145 last-byte-pos 147
last-chunk 28 last-chunk 30
Last-Modified 141 Last-Modified 143
LF 18 LF 20
LOALPHA 18 LOALPHA 20
Location 142 Location 144
LWS 18 LWS 20
Max-Forwards 142 Max-Forwards 145
md5-digest 128 md5-digest 130
media-range 107 media-range 109
media-type 29 media-type 31
message-body 35 message-body 37
message-header 35 message-header 37
Method 39 Method 41
MIME-Version 174 MIME-Version 179
month 23 month 25
OCTET 18 OCTET 20
opaque-tag 32 opaque-tag 34
other-range-unit 33 other-range-unit 35
parameter 26 parameter 28
Pragma 143 Pragma 145
pragma-directive 143 pragma-directive 145
primary-tag 32 primary-tag 34
product 31 product 33
product-version 31 product-version 33
protocol-name 153 protocol-name 155
protocol-version 153 protocol-version 155
Proxy-Authenticate 144 Proxy-Authenticate 146
Proxy-Authorization 144 Proxy-Authorization 146
pseudonym 153 pseudonym 155
qdtext 19 qdtext 21
quoted-pair 19 quoted-pair 21
quoted-string 19 quoted-string 21
qvalue 31 qvalue 33
Range 146 Range 148
range-unit 33 range-unit 35
ranges-specifier 145 ranges-specifier 147
Reason-Phrase 45 Reason-Phrase 47
received-by 153 received-by 155
received-protocol 153 received-protocol 155
Referer 147 Referer 149
Request 39 Request 41
request-header 42 request-header 44
Request-Line 39 Request-Line 41
Request-URI 40 Request-URI 42
Response 43 Response 45
response-header 46 response-header 48
Retry-After 147 Retry-After 150
rfc850-date 23 rfc850-date 25
rfc1123-date 23 rfc1123-date 25
separators 19 separators 21
Server 148 Server 150
SP 18 SP 20
start-line 34 start-line 36
Status-Code 45 Status-Code 47
Status-Line 43 Status-Line 45
subtag 32 subtag 34
subtype 29 subtype 31
suffix-byte-range-spec 145 suffix-byte-range-spec 147
suffix-length 145 suffix-length 147
t-codings 148 t-codings 151
TE 148 TE 151
TEXT 18 TEXT 20
time 23 time 25
token 19 token 21
Trailer 150 Trailer 152
trailer 28 trailer 30
transfer-coding 26 transfer-coding 28
Transfer-Encoding 150 Transfer-Encoding 152
transfer-extension 26 transfer-extension 28
type 29 type 31
UPALPHA 18 UPALPHA 20
Upgrade 151 Upgrade 153
User-Agent 152 User-Agent 154
value 26 value 28
Vary 152 Vary 154
Via 153 Via 155
warn-agent 155 warn-agent 157
warn-code 155 warn-code 157
warn-date 155 warn-date 157
warn-text 155 warn-text 157
Warning 155 Warning 157
warning-value 155 warning-value 157
weak 32 weak 34
weekday 23 weekday 25
wkday 23 wkday 25
WWW-Authenticate 157 WWW-Authenticate 159
gzip (content coding) 25 gzip 27
H H
HEAD method 58 HEAD method 60
Headers Headers
Accept 107 Accept 109
Accept-Charset 109 Accept-Charset 111
Accept-Encoding 109 Accept-Encoding 111
Accept-Language 111 Accept-Language 113
Accept-Ranges 112 Accept-Ranges 114
Age 112 Age 114
Allow 113 Allow 115
Alternate 182 Authorization 116
Authorization 113 Cache-Control 116
Cache-Control 114 Connection 126
Connection 124 Content-Encoding 127
Content-Base 182 Content-Language 128
Content-Disposition 176 Content-Length 128
Content-Encoding 125 Content-Location 129
Content-Language 125 Content-MD5 130
Content-Length 126 Content-Range 131
Content-Location 127 Content-Type 133
Content-MD5 128 Date 133
Content-Range 129 ETag 135
Content-Type 131 Expect 135
Content-Version 182 Expires 136
Date 131 From 137
Derived-From 182 Host 137
ETag 133 If-Match 138
Expect 133 If-Modified-Since 139
Expires 134 If-None-Match 141
From 135 If-Range 142
Host 135 If-Unmodified-Since 143
If-Match 136 Last-Modified 143
If-Modified-Since 137 Location 144
If-None-Match 139 Max-Forwards 144
If-Range 140 Pragma 145
If-Unmodified-Since 141 Proxy-Authenticate 146
Last-Modified 141 Proxy-Authorization 146
Link 182 Range 147
Location 142 Referer 149
Max-Forwards 142 Retry-After 150
Pragma 143 Server 150
Proxy-Authenticate 144 TE 151
Proxy-Authorization 144 Trailer 152
Public 182 Transfer-Encoding 152
Range 144 Upgrade 153
Referer 147 User-Agent 154
Retry-After 147 Vary 154
Server 148 Via 155
TE 148 Warning 157
Trailer 149 WWW-Authenticate 159
Transfer-Encoding 150 heuristic expiration time 14
Upgrade 150 Host header 137
URI 182
User-Agent 152
Vary 152
Via 153
Warning 154
WWW-Authenticate 157
heuristic expiration time 12
Host header 135
I I
identity (content coding) 26 identity 28
If-Match header 136 If-Match header 138
If-Modified-Since header 137 If-Modified-Since header 139
If-None-Match header 139 If-None-Match header 141
If-Range header 140 If-Range header 142
If-Unmodified-Since header 141 If-Unmodified-Since header 143
inbound 13 inbound 15
L L
Last-Modified header 141 Last-Modified header 143
Link header 182 Location header 144
LINK method 181
Location header 142
M M
max-age max-age
Cache Directive 119, 121 Cache Directive 121, 123
Max-Forwards header 142 Max-Forwards header 144
max-stale max-stale
Cache Directive 119 Cache Directive 121
Media Type message 11
application/http 170
message/http 170
multipart/byteranges 171
multipart/x-byteranges 172
message 9
message/http Media Type 170
Methods Methods
CONNECT 62 CONNECT 64
DELETE 61 DELETE 63
GET 58 GET 60
HEAD 58 HEAD 60
LINK 181 OPTIONS 59
OPTIONS 57 POST 61
PATCH 181 PUT 62
POST 59 TRACE 63
PUT 60
TRACE 61
UNLINK 181
min-fresh min-fresh
Cache Directive 119
multipart/byteranges Media Type 171
multipart/x-byteranges Media Type 172
must-revalidate
Cache Directive 121 Cache Directive 121
must-revalidate
Cache Directive 123
N N
no-cache no-cache
Cache Directive 117 Cache Directive 119
no-store no-store
Cache Directive 117 Cache Directive 119
no-transform no-transform
Cache Directive 122 Cache Directive 125
O O
only-if-cached only-if-cached
Cache Directive 121 Cache Directive 123
OPTIONS method 57 OPTIONS method 59
origin server 10 origin server 12
outbound 13 outbound 15
P P
PATCH method 181 POST method 61
POST method 59 Pragma header 145
Pragma header 143
private private
Cache Directive 116 Cache Directive 118
proxy 10 proxy 12
Proxy-Authenticate header 144 Proxy-Authenticate header 146
Proxy-Authorization header 144 Proxy-Authorization header 146
proxy-revalidate proxy-revalidate
Cache Directive 122 Cache Directive 124
Public header 182
public public
Cache Directive 116 Cache Directive 118
PUT method 60 PUT method 62
R R
Range header 144 Range header 147
Referer header 147 Referer header 149
representation 9 representation 11
request 9 request 11
resource 9 resource 11
response 9 response 11
Retry-After header 147 Retry-After header 150
S S
s-maxage s-maxage
Cache Directive 118 Cache Directive 120
semantically transparent 12 semantically transparent 14
Server header 148 Server header 150
server 10 server 12
stale 12 stale 14
Status Codes Status Codes
100 Continue 63 100 Continue 65
101 Switching Protocols 63 101 Switching Protocols 65
200 OK 64 200 OK 66
201 Created 64 201 Created 66
202 Accepted 64 202 Accepted 66
203 Non-Authoritative Information 65 203 Non-Authoritative Information 67
204 No Content 65 204 No Content 67
205 Reset Content 65 205 Reset Content 67
206 Partial Content 66 206 Partial Content 68
300 Multiple Choices 67 300 Multiple Choices 69
301 Moved Permanently 67 301 Moved Permanently 69
302 Found 68 302 Found 70
303 See Other 68 303 See Other 70
304 Not Modified 69 304 Not Modified 71
305 Use Proxy 69 305 Use Proxy 71
306 (Unused) 70 306 (Unused) 72
307 Temporary Redirect 70 307 Temporary Redirect 72
400 Bad Request 71 400 Bad Request 73
401 Unauthorized 71 401 Unauthorized 73
402 Payment Required 71 402 Payment Required 73
403 Forbidden 71 403 Forbidden 73
404 Not Found 71 404 Not Found 73
405 Method Not Allowed 72 405 Method Not Allowed 74
406 Not Acceptable 72 406 Not Acceptable 74
407 Proxy Authentication Required 72 407 Proxy Authentication Required 74
408 Request Timeout 73 408 Request Timeout 75
409 Conflict 73 409 Conflict 75
410 Gone 73 410 Gone 75
411 Length Required 74 411 Length Required 76
412 Precondition Failed 74 412 Precondition Failed 76
413 Request Entity Too Large 74 413 Request Entity Too Large 76
414 Request-URI Too Long 74 414 Request-URI Too Long 76
415 Unsupported Media Type 74 415 Unsupported Media Type 76
416 Requested Range Not Satisfiable 74 416 Requested Range Not Satisfiable 76
417 Expectation Failed 75 417 Expectation Failed 77
500 Internal Server Error 75 500 Internal Server Error 77
501 Not Implemented 75 501 Not Implemented 77
502 Bad Gateway 75 502 Bad Gateway 77
503 Service Unavailable 76 503 Service Unavailable 78
504 Gateway Timeout 76 504 Gateway Timeout 78
505 HTTP Version Not Supported 76 505 HTTP Version Not Supported 78
T T
TE header 148 TE header 151
TRACE method 61 TRACE method 63
Trailer header 149 Trailer header 152
Transfer-Encoding header 150 Transfer-Encoding header 152
tunnel 11 tunnel 13
U U
UNLINK method 181 Upgrade header 153
Upgrade header 150 upstream 15
upstream 13 user agent 12
URI header 182 User-Agent header 154
user agent 10
User-Agent header 152
V V
validator 12 validator 14
variant 10 variant 12
Vary header 152 Vary header 154
Via header 153 Via header 155
W W
Warn Codes Warning header 157
110 Response is stale 156 WWW-Authenticate header 159
111 Revalidation failed 156
112 Disconnected operation 156
113 Heuristic expiration 156
199 Miscellaneous warning 156
214 Transformation applied 156
299 Miscellaneous persistent warning 157
Warning header 154
WWW-Authenticate header 157
Authors' Addresses Authors' Addresses
Roy T. Fielding Yves Lafon
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Fax: +1(949)824-1715
Email: fielding@ics.uci.edu
James Gettys
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge, MA 02139
Fax: +1(617)258-8682
Email: jg@w3.org
Jeffrey C. Mogul
Compaq Computer Corporation
Western Research Laboratory
250 University Avenue
Palo Alto, CA 94305
Email: mogul@wrl.dec.com
Henrik Frystyk Nielsen
World Wide Web Consortium World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356 2004, Route des Lucioles
545 Technology Square Sophia Antipolis 06902
Cambridge, MA 02139 France
Fax: +1(617)258-8682
Email: frystyk@w3.org
Larry Masinter
Xerox Corporation
MIT Laboratory for Computer Science, NE43-356
3333 Coyote Hill Road
Palo Alto, CA 94034
Email: masinter@parc.xerox.com
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
Email: paulle@microsoft.com Phone: +33 492387943
Fax: +33 492387822
Email: ylafon@w3.org
URI: http://www.w3.org/
Tim Berners-Lee Julian F. Reschke
World Wide Web Consortium greenbytes GmbH
MIT Laboratory for Computer Science, NE43-356 Hafenweg 16
545 Technology Square Muenster, NW 48155
Cambridge, MA 02139 Germany
Fax: +1(617)258-8682 Phone: +49 251 2807760
Email: timbl@w3.org Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 100 change blocks. 
879 lines changed or deleted 893 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/