draft-lafon-rfc2616bis-00.txt   draft-lafon-rfc2616bis-01.txt 
Network Working Group Y. Lafon Network Working Group R. Fielding
Internet-Draft W3C Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Reschke Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track greenbytes Intended status: Standards Track J. Mogul
Expires: April 16, 2007 October 13, 2006 Expires: April 25, 2007 HP
H. Frystyk
Microsoft
L. Masinter
Adobe Systems
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Y. Lafon, Ed.
W3C
J. Reschke, Ed.
greenbytes
October 22, 2006
Hypertext Transfer Protocol -- HTTP/1.1 Hypertext Transfer Protocol -- HTTP/1.1
draft-lafon-rfc2616bis-00 draft-lafon-rfc2616bis-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 48
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 16, 2007. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). 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
skipping to change at page 3, line 26 skipping to change at page 4, line 26
The purpose of this document is to revise RFC2616 ([50]), doing only The purpose of this document is to revise RFC2616 ([50]), doing only
minimal corrections. For now, it is not planned to advance the minimal corrections. For now, it is not planned to advance the
standards level of HTTP, thus - if published - the specification will standards level of HTTP, thus - if published - the specification will
still be a "Proposed Standard" (see [46]). still be a "Proposed Standard" (see [46]).
The current plan is to incorporate known errata, and to update the The current plan is to incorporate known errata, and to update the
specification text according to the current IETF publication specification text according to the current IETF publication
guidelines. In particular: guidelines. In particular:
o Incorporate the corrections collected in the RFC2616 errata o Incorporate the corrections collected in the RFC2616 errata
document (<http://skrb.org/ietf/http_errata.html>) and potentially document (<http://purl.org/NET/http-errata>) (most of the
newly discovered and agreed-upon errata. suggested fixes have been applied to draft 01).
o Incorporate corrections for newly discovered and agreed-upon
problems, using the HTTP WG mailing list as forum.
o Update references, and re-classify them into "Normative" and o Update references, and re-classify them into "Normative" and
"Informative", based on the prior work done by Jim Gettys in "Informative", based on the prior work done by Jim Gettys in
<http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00>. <http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00>.
This document is based on a variant of the original RFC2616 This document is based on a variant of the original RFC2616
specification formatted using Marshall T. Rose's "xml2rfc" tool (see specification formatted using Marshall T. Rose's "xml2rfc" tool (see
<http://xml.resource.org>) and therefore deviates from the original <http://xml.resource.org>) and therefore deviates from the original
text in word wrapping, page breaks, list formatting, reference text in word wrapping, page breaks, list formatting, reference
formatting, whitespace usage and appendix numbering. Otherwise, it formatting, whitespace usage and appendix numbering. Otherwise, it
is supposed to contain an accurate copy of the original specification is supposed to contain an accurate copy of the original specification
text. See <http://www.w3.org/Protocols/HTTP/1.1/ text. See <http://www.w3.org/Protocols/HTTP/1.1/
rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both
documents, as generated by "rfcdiff" documents, as generated by "rfcdiff"
(<http://tools.ietf.org/tools/rfcdiff/>). (<http://tools.ietf.org/tools/rfcdiff/>).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 10 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 12
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 13
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 15 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17
2. Notational Conventions and Generic Grammar . . . . . . . . . 18 2. Notational Conventions and Generic Grammar . . . . . . . . . 20
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 18 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 20
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 20 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 22
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 22 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 22 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 24
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 23 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 25
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 23 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 25
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 23 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 24 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 26
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 24 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 24 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 26 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 26 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 27 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 27 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 28 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 29 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 31 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 31 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 32 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 35
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 33 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 33 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 34 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 34 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 35 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41
4.5. General Header Fields . . . . . . . . . . . . . . . . . 39 4.5. General Header Fields . . . . . . . . . . . . . . . . . 42
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 41 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 42 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 45
5.2. The Resource Identified by a Request . . . . . . . . . . 43 5.2. The Resource Identified by a Request . . . . . . . . . . 46
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 44 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 47
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 48
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 48
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 48 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 51
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 49 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 52
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 49 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 52
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 50 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 50 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 53
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 51 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 54
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 51 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 54
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 51 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 54
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 53 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 56
8.1.4. Practical Considerations . . . . . . . . . . . . . . 53 8.1.4. Practical Considerations . . . . . . . . . . . . . . 56
8.2. Message Transmission Requirements . . . . . . . . . . . 54 8.2. Message Transmission Requirements . . . . . . . . . . . 57
8.2.1. Persistent Connections and Flow Control . . . . . . 54 8.2.1. Persistent Connections and Flow Control . . . . . . 57
8.2.2. Monitoring Connections for Error Status Messages . . 54 8.2.2. Monitoring Connections for Error Status Messages . . 57
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 55 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 58
8.2.4. Client Behavior if Server Prematurely Closes 8.2.4. Client Behavior if Server Prematurely Closes
Connection . . . . . . . . . . . . . . . . . . . . . 57 Connection . . . . . . . . . . . . . . . . . . . . . 60
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 58 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 58 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 61
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 58 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 61
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 58 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 61
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 59 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 61 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 62 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 66
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 64 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 67
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 65 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 68
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 65 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 68
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 65 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 68
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 65 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 68
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 66 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 69
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 66 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 69
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 66 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 69
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 66 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 69
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 67 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 67 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 70
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 67 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 70
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 68 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 71
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 68 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 71
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 69 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 72
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 69 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 72
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 70 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 73
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 70 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 73
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 71 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 71 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 74
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 72 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 75
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 72 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 75
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 72 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 73 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 76
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 73 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 76
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 73 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 76
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 73 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 76
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 73 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 76
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 74 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 77
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 74 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 77
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 74 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 77
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 75 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 78
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 75 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 78
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 75 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 78
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 76 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 79
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 76 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 79
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 76 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 79
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 76 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 79
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 76 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 79
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 76 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 79
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 77 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 80
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 77 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 77 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 80
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 77 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 80
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 77 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 80
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 78 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 81
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 78 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 81
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 78 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 81
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 79 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 82
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 80 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 83
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 80 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 83
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 81 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 84
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 82 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 85
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 83 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 86
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 84 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 87
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 85 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 88
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 86 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 89
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 86 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 89
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 87 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 90
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 87 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 90
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 88 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 91
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 88 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 91
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 88 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 91
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 89 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 92
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 91 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 94
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 92 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 95
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 93 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 96
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 93 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 96
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 94 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 97
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 94 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 97
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 95 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 98
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 . . . . . . . . . . . . . . . . 97 Last-Modified Dates . . . . . . . . . . . . . . . . 100
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 99 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 102
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 99 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 102
13.5. Constructing Responses From Caches . . . . . . . . . . . 100 13.5. Constructing Responses From Caches . . . . . . . . . . . 103
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 100 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 103
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 101 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 104
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 102 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 105
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 103 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 106
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 104 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 107
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 105 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 108
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 105 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 108
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 106 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 109
13.10. Invalidation After Updates or Deletions . . . . . . . . 106 13.10. Invalidation After Updates or Deletions . . . . . . . . 109
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 107 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 110
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 107 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 110
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 108 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 111
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 109 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 112
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 109 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 111 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 114
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 111 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 113 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 116
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 114 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 117
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 114 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 117
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 115 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 116 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 119
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 116 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 119
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 118 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 121
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 119 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 122
14.9.3. Modifications of the Basic Expiration Mechanism . . 120 14.9.3. Modifications of the Basic Expiration Mechanism . . 123
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 122 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 125
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 125 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 128
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 125 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 128
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 126 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 129
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 127 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 130
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 128 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 131
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 128 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 131
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 129 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 132
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 130 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 133
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 131 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 134
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 133 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 136
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 133 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.18.1. Clockless Origin Server Operation . . . . . . . . . 134 14.18.1. Clockless Origin Server Operation . . . . . . . . . 138
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 136 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 139
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 137 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 140
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 137 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 141
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 138 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 141
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 139 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 142
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 141 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 142 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 145
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 143 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 146
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 143 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 146
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 144 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 147
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 144 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 148
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 145 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 148
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 146 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 149
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 146 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 147 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 147 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 150
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 148 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 152
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 149 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 153
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 150 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 153
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 150 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 152 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 155
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 152 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 156
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 153 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 156
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 157
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 154 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 155 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 157 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 160
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 159 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 163
15. Security Considerations . . . . . . . . . . . . . . . . . . . 160 15. Security Considerations . . . . . . . . . . . . . . . . . . . 164
15.1. Personal Information . . . . . . . . . . . . . . . . . . 160 15.1. Personal Information . . . . . . . . . . . . . . . . . . 164
15.1.1. Abuse of Server Log Information . . . . . . . . . . 160 15.1.1. Abuse of Server Log Information . . . . . . . . . . 164
15.1.2. Transfer of Sensitive Information . . . . . . . . . 160 15.1.2. Transfer of Sensitive Information . . . . . . . . . 164
15.1.3. Encoding Sensitive Information in URI's . . . . . . 161 15.1.3. Encoding Sensitive Information in URI's . . . . . . 165
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 162 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 166
15.2. Attacks Based On File and Path Names . . . . . . . . . . 162 15.2. Attacks Based On File and Path Names . . . . . . . . . . 166
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 163 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 167
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 163 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 167
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 164 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 168
15.6. Authentication Credentials and Idle Clients . . . . . . 164 15.6. Authentication Credentials and Idle Clients . . . . . . 168
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 164 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 168
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 165 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 169
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 166 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 170
16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 166 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 170
16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 168 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 171
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 172
17.1. References . . . . . . . . . . . . . . . . . . . . . . . 169 17.1. References . . . . . . . . . . . . . . . . . . . . . . . 172
17.2. Normative References . . . . . . . . . . . . . . . . . . 172 17.2. Informative References . . . . . . . . . . . . . . . . . 175
Appendix A. Internet Media Type message/http and Appendix A. Internet Media Type message/http and
application/http . . . . . . . . . . . . . . . . . . 174 application/http . . . . . . . . . . . . . . . . . . 177
Appendix B. Internet Media Type multipart/byteranges . . . . . . 176 Appendix B. Internet Media Type multipart/byteranges . . . . . . 179
Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 178 Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 181
Appendix D. Differences Between HTTP Entities and RFC 2045 Appendix D. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 179 Entities . . . . . . . . . . . . . . . . . . . . . . 182
D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 179 D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 182
D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 179 D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 182
D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 180 D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 183
D.4. Introduction of Content-Encoding . . . . . . . . . . . . 180 D.4. Introduction of Content-Encoding . . . . . . . . . . . . 183
D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 180 D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 183
D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 181 D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 184
D.7. MHTML and Line Length Limitations . . . . . . . . . . . 181 D.7. MHTML and Line Length Limitations . . . . . . . . . . . 184
Appendix E. Additional Features . . . . . . . . . . . . . . . . 182 Appendix E. Additional Features . . . . . . . . . . . . . . . . 185
E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 182 E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 185
Appendix F. Compatibility with Previous Versions . . . . . . . . 183 Appendix F. Compatibility with Previous Versions . . . . . . . . 186
F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 183 F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 186
F.1.1. Changes to Simplify Multi-homed Web Servers and F.1.1. Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses . . . . . . . . . . . . . . . 183 Conserve IP Addresses . . . . . . . . . . . . . . . 186
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 184 F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 187
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 185 F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 188
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 190
Appendix G. Change Log (to be removed by RFC Editor before Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 188 publication) . . . . . . . . . . . . . . . . . . . . 192
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 188 G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 192
Appendix H. Open issues (to be removed by RFC Editor prior to G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 192
publication) . . . . . . . . . . . . . . . . . . . . 189 Appendix H. Resolved issues (to be removed by RFC Editor
H.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 189 before publication) . . . . . . . . . . . . . . . . 193
H.2. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 189 H.1. rfc2606-compliance . . . . . . . . . . . . . . . . . . . 193
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 H.2. editor-notes . . . . . . . . . . . . . . . . . . . . . . 193
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201 H.3. verscase . . . . . . . . . . . . . . . . . . . . . . . . 193
Intellectual Property and Copyright Statements . . . . . . . . . 202 H.4. unsafe-uri . . . . . . . . . . . . . . . . . . . . . . . 193
H.5. charactersets . . . . . . . . . . . . . . . . . . . . . 194
H.6. identity . . . . . . . . . . . . . . . . . . . . . . . . 194
H.7. chunk-size . . . . . . . . . . . . . . . . . . . . . . . 194
H.8. msg-len-chars . . . . . . . . . . . . . . . . . . . . . 195
H.9. uriquery . . . . . . . . . . . . . . . . . . . . . . . . 195
H.10. post . . . . . . . . . . . . . . . . . . . . . . . . . . 195
H.11. ifrange206 . . . . . . . . . . . . . . . . . . . . . . . 195
H.12. saferedirect . . . . . . . . . . . . . . . . . . . . . . 196
H.13. trailer-hop . . . . . . . . . . . . . . . . . . . . . . 196
H.14. invalidupd . . . . . . . . . . . . . . . . . . . . . . . 196
H.15. noclose1xx . . . . . . . . . . . . . . . . . . . . . . . 197
H.16. via-must . . . . . . . . . . . . . . . . . . . . . . . . 197
Appendix I. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 198
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 198
I.2. unneeded_references . . . . . . . . . . . . . . . . . . 198
I.3. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 198
I.4. media-reg . . . . . . . . . . . . . . . . . . . . . . . 198
I.5. languagetag . . . . . . . . . . . . . . . . . . . . . . 198
I.6. location-fragments . . . . . . . . . . . . . . . . . . . 199
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 211
Intellectual Property and Copyright Statements . . . . . . . . . 214
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 12, line 19 skipping to change at page 14, line 19
The mechanism for selecting the appropriate representation when The mechanism for selecting the appropriate representation when
servicing a request, as described in Section 12. The servicing a request, as described in Section 12. The
representation of entities in any response can be negotiated representation of entities in any response can be negotiated
(including error responses). (including error responses).
variant variant
A resource may have one, or more than one, representation(s) A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these associated with it at any given instant. Each of these
representations is termed a `varriant'. Use of the term `variant' representations is termed a `variant'. Use of the term `variant'
does not necessarily imply that the resource is subject to content does not necessarily imply that the resource is subject to content
negotiation. negotiation.
client client
A program that establishes connections for the purpose of sending A program that establishes connections for the purpose of sending
requests. requests.
user agent user agent
skipping to change at page 22, line 43 skipping to change at page 24, line 43
An application that sends a request or response message that includes An application that sends a request or response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least with this specification. Applications that are at least
conditionally compliant with this specification SHOULD use an HTTP- conditionally compliant with this specification SHOULD use an HTTP-
Version of "HTTP/1.1" in their messages, and MUST do so for any Version of "HTTP/1.1" in their messages, and MUST do so for any
message that is not compatible with HTTP/1.0. For more details on message that is not compatible with HTTP/1.0. For more details on
when to send specific HTTP-Version values, see RFC 2145 [36]. when to send specific HTTP-Version values, see RFC 2145 [36].
The HTTP version of an application is the highest HTTP version for The HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant. which the application is at least conditionally compliant. HTTP-
Version is case-sensitive.
Proxy and gateway applications need to be careful when forwarding Proxy and gateway applications need to be careful when forwarding
messages in protocol versions different from that of the application. messages in protocol versions different from that of the application.
Since the protocol version indicates the protocol capability of the Since the protocol version indicates the protocol capability of the
sender, a proxy/gateway MUST NOT send a message with a version sender, a proxy/gateway MUST NOT send a message with a version
indicator which is greater than its actual version. If a higher indicator which is greater than its actual version. If a higher
version request is received, the proxy/gateway MUST either downgrade version request is received, the proxy/gateway MUST either downgrade
the request version, or respond with an error, or switch to tunnel the request version, or respond with an error, or switch to tunnel
behavior. behavior.
skipping to change at page 24, line 10 skipping to change at page 26, line 16
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:
o A port that is empty or not given is equivalent to the default o A port that is empty or not given is equivalent to the default
port for that URI-reference; port for that URI-reference;
o Comparisons of host names MUST be case-insensitive; o Comparisons of host names MUST be case-insensitive;
o Comparisons of scheme names MUST be case-insensitive; o Comparisons of scheme names MUST be case-insensitive;
o An empty abs_path is equivalent to an abs_path of "/". o An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see Characters other than those in the "reserved" set (see RFC 2396 [42])
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html http://ABC.com:/%7esmith/home.html
3.3. Date/Time Formats 3.3. Date/Time Formats
3.3.1. Full Date 3.3.1. Full Date
skipping to change at page 26, line 49 skipping to change at page 29, line 25
[19]. [19].
charset = token charset = token
Although HTTP allows an arbitrary token to be used as a charset Although HTTP allows an arbitrary token to be used as a charset
value, any token that has a predefined value within the IANA value, any token that has a predefined value within the IANA
Character Set registry [19] MUST represent the character set defined Character Set registry [19] MUST represent the character set defined
by that registry. Applications SHOULD limit their use of character by that registry. Applications SHOULD limit their use of character
sets to those defined by the IANA registry. sets to those defined by the IANA registry.
HTTP uses charset in two contexts: within an Accept-Charset request
header (in which the charset value is an unquoted token) and as the
value of a parameter in a Content-Type header (within a request or
response), in which case the parameter value of the charset parameter
may be quoted.
Implementors should be aware of IETF character set requirements [38] Implementors should be aware of IETF character set requirements [38]
[41]. [41].
3.4.1. Missing Charset 3.4.1. Missing Charset
Some HTTP/1.0 software has interpreted a Content-Type header without Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess." charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient. it is known that it will not confuse the recipient.
skipping to change at page 29, line 23 skipping to change at page 32, line 7
Transfer-codings are analogous to the Content-Transfer-Encoding Transfer-codings are analogous to the Content-Transfer-Encoding
values of MIME [7], which were designed to enable safe transport of values of MIME [7], which were designed to enable safe transport of
binary data over a 7-bit transport service. However, safe transport binary data over a 7-bit transport service. However, safe transport
has a different focus for an 8bit-clean transfer protocol. In HTTP, has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (Section 7.2.2), or the desire to determining the exact body length (Section 7.2.2), or the desire to
encrypt data over a shared transport. encrypt data over a shared transport.
The Internet Assigned Numbers Authority (IANA) acts as a registry for The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (Section 3.6.1), "identity" (section following tokens: "chunked" (Section 3.6.1), "gzip" (Section 3.5),
3.6.2), "gzip" (Section 3.5), "compress" (Section 3.5), and "deflate" "compress" (Section 3.5), and "deflate" (Section 3.5).
(Section 3.5).
New transfer-coding value tokens SHOULD be registered in the same way New transfer-coding value tokens SHOULD be registered in the same way
as new content-coding value tokens (Section 3.5). as new content-coding value tokens (Section 3.5).
A server which receives an entity-body with a transfer-coding it does A server which receives an entity-body with a transfer-coding it does
not understand SHOULD return 501 (Unimplemented), and close the not understand SHOULD return 501 (Unimplemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client. client.
3.6.1. Chunked Transfer Coding 3.6.1. Chunked Transfer Coding
skipping to change at page 30, line 22 skipping to change at page 32, line 44
chunk-size = 1*HEX chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token chunk-ext-name = token
chunk-ext-val = token | quoted-string chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET) chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF) trailer = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of The chunk-size field is a string of hex digits indicating the size of
the chunk. The chunked encoding is ended by any chunk whose size is the chunk-data in octets. The chunked encoding is ended by any chunk
zero, followed by the trailer, which is terminated by an empty line. whose size is zero, followed by the trailer, which is terminated by
an empty line.
The trailer allows the sender to include additional HTTP header The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see used to indicate which header fields are included in a trailer (see
Section 14.40). Section 14.40).
A server using chunked transfer-coding in a response MUST NOT use the A server using chunked transfer-coding in a response MUST NOT use the
trailer for any header fields unless at least one of the following is trailer for any header fields unless at least one of the following is
true: true:
skipping to change at page 38, line 41 skipping to change at page 41, line 41
been applied. When a message-body is included with a message, the been applied. When a message-body is included with a message, the
transfer-length of that body is determined by one of the following transfer-length of that body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response message which "MUST NOT" include a message-body 1. Any response message which "MUST NOT" include a message-body
(such as the 1xx, 204, and 304 responses and any response to a (such as the 1xx, 204, and 304 responses and any response to a
HEAD request) is always terminated by the first empty line after HEAD request) is always terminated by the first empty line after
the header fields, regardless of the entity-header fields present the header fields, regardless of the entity-header fields present
in the message. in the message.
2. If a Transfer-Encoding header field (Section 14.41) is present 2. If a Transfer-Encoding header field (Section 14.41) is present,
and has any value other than "identity", then the transfer-length then the transfer-length is defined by use of the "chunked"
is defined by use of the "chunked" transfer-coding (Section 3.6), transfer-coding (Section 3.6), unless the message is terminated
unless the message is terminated by closing the connection. by closing the connection.
3. If a Content-Length header field (Section 14.13) is present, its 3. If a Content-Length header field (Section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be transfer-length. The Content-Length header field MUST NOT be
sent if these two lengths are different (i.e., if a Transfer- sent if these two lengths are different (i.e., if a Transfer-
Encoding header field is present). If a message is received with Encoding header field is present). If a message is received with
both a Transfer-Encoding header field and a Content-Length header both a Transfer-Encoding header field and a Content-Length header
field, the latter MUST be ignored. field, the latter MUST be ignored.
4. If the message uses the media type "multipart/byteranges", and 4. If the message uses the media type "multipart/byteranges", and
the ransfer-length is not otherwise specified, then this self- the transfer-length is not otherwise specified, then this self-
elimiting media type defines the transfer-length. This media delimiting media type defines the transfer-length. This media
type UST NOT be used unless the sender knows that the recipient type MUST NOT be used unless the sender knows that the recipient
can arse it; the presence in a request of a Range header with can parse it; the presence in a request of a Range header with
ultiple byte-range specifiers from a 1.1 client implies that the multiple byte-range specifiers from a 1.1 client implies that the
lient can parse multipart/byteranges responses. client can parse multipart/byteranges responses.
A range header might be forwarded by a 1.0 proxy that does not A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST understand multipart/byteranges; in this case the server MUST
delimit the message using methods defined in items 1, 3 or 5 delimit the message using methods defined in items 1, 3 or 5
of this section. of this section.
5. By the server closing the connection. (Closing the connection 5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a would leave no possibility for the server to send back a
response.) response.)
skipping to change at page 39, line 38 skipping to change at page 42, line 38
the server SHOULD respond with 400 (bad request) if it cannot the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length. it wishes to insist on receiving a valid Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer-coding (Section 3.6), thus allowing this mechanism "chunked" transfer-coding (Section 3.6), thus allowing this mechanism
to be used for messages when the message length cannot be determined to be used for messages when the message length cannot be determined
in advance. in advance.
Messages MUST NOT include both a Content-Length header field and a Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non- transfer-coding. If the message does include a transfer-coding, the
identity transfer-coding, the Content-Length MUST be ignored. Content-Length MUST be ignored.
When a Content-Length is given in a message where a message-body is When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected. invalid length is received and detected.
4.5. General Header Fields 4.5. General Header Fields
There are a few header fields which have general applicability for There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the both request and response messages, but which do not apply to the
skipping to change at page 42, line 12 skipping to change at page 45, line 12
GET and HEAD MUST be supported by all general-purpose servers. All GET and HEAD MUST be supported by all general-purpose servers. All
other methods are OPTIONAL; however, if the above methods are other methods are OPTIONAL; however, if the above methods are
implemented, they MUST be implemented with the same semantics as implemented, they MUST be implemented with the same semantics as
those specified in Section 9. those specified in Section 9.
5.1.2. Request-URI 5.1.2. Request-URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) and The Request-URI is a Uniform Resource Identifier (Section 3.2) and
identifies the resource upon which to apply the request. identifies the resource upon which to apply the request.
Request-URI = "*" | absoluteURI | abs_path | authority Request-URI = "*"
| absoluteURI
| abs_path [ "?" query ]
| authority
The four options for Request-URI are dependent on the nature of the The four options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One when the method used does not necessarily apply to a resource. One
example would be example would be
OPTIONS * HTTP/1.1 OPTIONS * HTTP/1.1
The absoluteURI form is REQUIRED when the request is being made to a The absoluteURI form is REQUIRED when the request is being made to a
proxy. The proxy is requested to forward the request or service it proxy. The proxy is requested to forward the request or service it
from a valid cache, and return the response. Note that the proxy MAY from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server forward the request on to another proxy or directly to the server
specified by the absoluteURI. In order to avoid request loops, a specified by the absoluteURI. In order to avoid request loops, a
proxy MUST be able to recognize all of its server names, including proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric IP address. An any aliases, local variations, and the numeric IP address. An
example Request-Line would be: example Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies. them in requests to proxies.
The authority form is only used by the CONNECT method (Section 9.9). The authority form is only used by the CONNECT method (Section 9.9).
The most common form of Request-URI is that used to identify a The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing be transmitted in a Host header field. For example, a client wishing
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.example.org" and
the lines: send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org Host: www.example.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 section The Request-URI is transmitted in the format specified in
3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX"
[42], the origin server MUST decode the Request-URI in order to encoding [42], the origin server MUST decode the Request-URI in order
properly interpret the request. Servers SHOULD respond to invalid to 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
skipping to change at page 47, line 14 skipping to change at page 50, 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 61, line 16 skipping to change at page 64, line 16
information contained in the response MAY be used to update a information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as or Last-Modified), then the cache MUST treat the cache entry as
stale. stale.
9.5. POST 9.5. POST
The POST method is used to request that the origin server accept the The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource entity enclosed in the request as data to be processed by the
identified by the Request-URI in the Request-Line. POST is designed resource identified by the Request-URI in the Request-Line. POST is
to allow a uniform method to cover the following functions: designed to allow a uniform method to cover the following functions:
o Annotation of existing resources; o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles; similar group of articles;
o Providing a block of data, such as the result of submitting a o Providing a block of data, such as the result of submitting a
form, to a data-handling process; form, to a data-handling process;
o Extending a database through an append operation. o Extending a database through an append operation.
The actual function performed by the POST method is determined by the The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted server and is usually dependent on the Request-URI.
entity is subordinate to that URI in the same way that a file is
subordinate to a directory containing it, a news article is
subordinate to a newsgroup to which it is posted, or a record is
subordinate to a database.
The action performed by the POST method might not result in a The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200 resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status, (OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that depending on whether or not the response includes an entity that
describes the result. describes the result.
If a resource has been created on the origin server, the response If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location status of the request and refers to the new resource, and a Location
skipping to change at page 68, line 32 skipping to change at page 71, line 32
o Date o Date
o ETag and/or Content-Location, if the header would have been sent o ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request in a 200 response to the same request
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant variant
If the 206 response is the result of an If-Range request that used a If the 206 response is the result of an If-Range request, the
strong cache validator (see Section 13.3.3), the response SHOULD NOT response SHOULD NOT include other entity-headers. Otherwise, the
include other entity-headers. If the response is the result of an response MUST include all of the entity-headers that would have been
If-Range request that used a weak validator, the response MUST NOT returned with a 200 (OK) response to the same request.
include other entity-headers; this prevents inconsistencies between
cached entity-bodies and updated headers. Otherwise, the response
MUST include all of the entity-headers that would have been returned
with a 200 (OK) response to the same request.
A cache MUST NOT combine a 206 response with other previously cached A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly, content if the ETag or Last-Modified headers do not match exactly,
see 13.5.4. see 13.5.4.
A cache that does not support the Range and Content-Range headers A cache that does not support the Range and Content-Range headers
MUST NOT cache 206 (Partial) responses. MUST NOT cache 206 (Partial) responses.
10.3. Redirection 3xx 10.3. Redirection 3xx
skipping to change at page 69, line 50 skipping to change at page 72, line 46
URIs. Clients with link editing capabilities ought to automatically URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is references returned by the server, where possible. This response is
cacheable unless indicated otherwise. cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 301 status code is received in response to a request other If the 301 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 9.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request. will erroneously change it into a GET request.
10.3.3. 302 Found 10.3.3. 302 Found
The requested resource resides temporarily under a different URI. The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header is only cacheable if indicated by a Cache-Control or Expires header
field. field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 302 status code is received in response to a request other If the 302 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 9.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303 existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client. kind of reaction is expected of the client.
10.3.4. 303 See Other 10.3.4. 303 See Other
skipping to change at page 72, line 33 skipping to change at page 75, line 33
field. field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the understand the 307 status. Therefore, the note SHOULD contain the
information necessary for a user to repeat the original request on information necessary for a user to repeat the original request on
the new URI. the new URI.
If the 307 status code is received in response to a request other If the 307 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 9.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
10.4. Client Error 4xx 10.4. Client Error 4xx
The 4xx class of status code is intended for cases in which the The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD client seems to have erred. Except when responding to a HEAD
request, the server SHOULD include an entity containing an request, the server SHOULD include an entity containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included entity to request method. User agents SHOULD display any included entity to
the user. the user.
skipping to change at page 101, line 21 skipping to change at page 104, line 21
o Connection o Connection
o Keep-Alive o Keep-Alive
o Proxy-Authenticate o Proxy-Authenticate
o Proxy-Authorization o Proxy-Authorization
o TE o TE
o Trailers o Trailer
o Transfer-Encoding o Transfer-Encoding
o Upgrade o Upgrade
All other headers defined by HTTP/1.1 are end-to-end headers. All other headers defined by HTTP/1.1 are end-to-end headers.
Other hop-by-hop headers MUST be listed in a Connection header, Other hop-by-hop headers MUST be listed in a Connection header,
(Section 14.10) to be introduced into HTTP/1.1 (or later). (Section 14.10) to be introduced into HTTP/1.1 (or later).
skipping to change at page 107, line 11 skipping to change at page 110, line 11
is either the entity referred to by the Request-URI, or by the is either the entity referred to by the Request-URI, or by the
Location or Content-Location headers (if present). These methods Location or Content-Location headers (if present). These methods
are: are:
o PUT o PUT
o DELETE o DELETE
o POST o POST
In order to prevent denial of service attacks, an invalidation based An invalidation based on the URI in a Location or Content-Location
on the URI in a Location or Content-Location header MUST only be header MUST NOT be performed if the host part of that URI differs
performed if the host part is the same as in the Request-URI. from the host part in the Request-URI. This helps prevent denial of
service attacks.
A cache that passes through requests for methods it does not A cache that passes through requests for methods it does not
understand SHOULD invalidate any entities referred to by the Request- understand SHOULD invalidate any entities referred to by the Request-
URI. URI.
13.11. Write-Through Mandatory 13.11. Write-Through Mandatory
All methods that might be expected to cause modifications to the All methods that might be expected to cause modifications to the
origin server's resources MUST be written through to the origin origin server's resources MUST be written through to the origin
server. This currently includes all methods except for GET and HEAD. server. This currently includes all methods except for GET and HEAD.
skipping to change at page 127, line 7 skipping to change at page 130, line 7
HTTP/1.1 defines the "close" connection option for the sender to HTTP/1.1 defines the "close" connection option for the sender to
signal that the connection will be closed after completion of the signal that the connection will be closed after completion of the
response. For example, response. For example,
Connection: close Connection: close
in either the request or the response header fields indicates that in either the request or the response header fields indicates that
the connection SHOULD NOT be considered `persistent' (Section 8.1) the connection SHOULD NOT be considered `persistent' (Section 8.1)
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 An HTTP/1.1 client that does not support persistent connections MUST
include the "close" connection option in every message. include the "close" connection option in every request message.
An HTTP/1.1 server that does not support persistent connections MUST
include the "close" connection option in every response message that
does not have a 1xx (informational) status code.
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 F.2. See Appendix F.2.
14.11. Content-Encoding 14.11. Content-Encoding
skipping to change at page 138, line 15 skipping to change at page 141, line 21
the naming authority of the origin server or gateway given by the the naming authority of the origin server or gateway given by the
original URL. This allows the origin server or gateway to original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/" differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address. URL of a server for multiple host names on a single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). For port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for example, a request on the origin server for
<http://www.w3.org/pub/WWW/> would properly include: <http://www.example.org/pub/WWW/> would properly include:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.w3.org Host: www.example.org
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.
skipping to change at page 144, line 34 skipping to change at page 147, line 41
14.30. Location 14.30. Location
The Location response-header field is used to redirect the recipient The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created) request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. server's preferred URI for automatic redirection to the resource.
The field value consists of a single absolute URI. The field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI Location = "Location" ":" absoluteURI [ "#" fragment ]
An example is: An example is:
Location: http://www.w3.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html
Note: The Content-Location header field (Section 14.14) differs Note: The Content-Location header field (Section 14.14) differs
from Location in that the Content-Location identifies the original from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location possible for a response to contain header fields for both Location
and Content-Location. Also see Section 13.10 for cache and Content-Location. Also see Section 13.10 for cache
requirements of some methods. requirements of some methods.
There are circumstances in which a fragment identifier in a Location
URL would not be appropriate:
o With a 201 Created response, because in this usage the Location
header specifies the URL for the entire created resource.
o With a 300 Multiple Choices, since the choice decision is intended
to be made on resource characteristics and not fragment
characteristics.
o With 305 Use Proxy.
14.31. Max-Forwards 14.31. Max-Forwards
The Max-Forwards request-header field provides a mechanism with the The Max-Forwards request-header field provides a mechanism with the
TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the
number of proxies or gateways that can forward the request to the number of proxies or gateways that can forward the request to the
next inbound server. This can be useful when the client is next inbound server. This can be useful when the client is
attempting to trace a request chain which appears to be failing or attempting to trace a request chain which appears to be failing or
looping in mid-chain. looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards = "Max-Forwards" ":" 1*DIGIT
skipping to change at page 149, line 45 skipping to change at page 153, line 21
server to generate lists of back-links to resources for interest, server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard. its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI ) Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example: Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. relative to the Request-URI. The URI MUST NOT include a fragment.
See Section 15.1.3 for security considerations. See Section 15.1.3 for security considerations.
14.37. Retry-After 14.37. Retry-After
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
skipping to change at page 150, line 41 skipping to change at page 154, line 14
application. application.
Server = "Server" ":" 1*( product | comment ) Server = "Server" ":" 1*( product | comment )
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in Section 14.45). MUST include a Via field (as described in Section 14.45).
Note: Revealing the specific software version of the server might Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable implementors are encouraged to make this field a configurable
option. option.
14.39. TE 14.39. TE
The TE request-header field indicates what extension transfer-codings The TE request-header field indicates what extension transfer-codings
skipping to change at page 167, line 5 skipping to change at page 170, line 32
Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
VanHeyningen deserve special recognition for their efforts in VanHeyningen deserve special recognition for their efforts in
defining early aspects of the protocol. defining early aspects of the protocol.
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already participating in the HTTP-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Gary Adams Ross Patterson Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
Harald Tveit Alvestrand Albert Lunde Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra,
Keith Ball John C. Mallery Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc
Brian Behlendorf Jean-Philippe Martin-Flatin Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel
Paul Burchard Mitra Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut,
Maurizio Codogno David Morris David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert
Mike Cowlishaw Gavin Nicol Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David
Roman Czyborra Bill Perry Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott
Michael A. Dolan Jeffrey Perry Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich
David J. Fiander Scott Powers Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink,
Alan Freier Owen Rees Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart)
Marc Hedlund Luigi Rizzo Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen.
Greg Herlihy David Robinson
Koen Holtman Marc Salomon
Alex Hopmann Rich Salz
Bob Jernigan Allan M. Schiffman
Shel Kaphan Jim Seidman
Rohit Khare Chuck Shotton
John Klensin Eric W. Sink
Martijn Koster Simon E. Spero
Alexei Kosut Richard N. Taylor
David M. Kristol Robert S. Thau
Daniel LaLiberte Bill (BearHeart) Weinman
Ben Laurie Francois Yergeau
Paul J. Leach Mary Ellen Zurko
Daniel DuBois Josh Cohen
Much of the content and presentation of the caching design is due to Much of the content and presentation of the caching design is due to
suggestions and comments from individuals including: Shel Kaphan, suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
Most of the specification of ranges is based on work originally done Most of the specification of ranges is based on work originally done
by Ari Luotonen and John Franks, with additional input from Steve by Ari Luotonen and John Franks, with additional input from Steve
Zilles. Zilles.
Thanks to the "cave men" of Palo Alto. You know who you are. Thanks to the "cave men" of Palo Alto. You know who you are.
Jim Gettys (the current editor of this document) wishes particularly Jim Gettys (the editor of [50]) wishes particularly to thank Roy
to thank Roy Fielding, the previous editor of this document, along Fielding, the editor of [33], along with John Klensin, Jeff Mogul,
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and Hopmann, Scott Lawrence, and Larry Masinter for their help. And
Larry Masinter for their help. And thanks go particularly to Jeff thanks go particularly to Jeff Mogul and Scott Lawrence for
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. 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) 16.2. (This Document)
This document is based on [50], which was authored by Roy T. This document has benefited greatly from the comments of all those
Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, participating in the HTTP-WG. In particular, we thank Scott Lawrence
Larry Masinter, Paul J. Leach and Tim Berners-Lee. for maintaining the RFC2616 Errata list, and Roy Fielding, Bjoern
Hoehrmann, Larry Masinter, Howard Melman, Jeff Mogul and Alex
Rousskov for contributions to it.
17. References 17. References
17.1. 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
skipping to change at page 172, line 35 skipping to change at page 175, 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",
October 1996. BCP 9, RFC 2026, 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.
17.2. Normative References 17.2. Informative References
[50] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [50] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
URIs URIs
[51] <mailto:ietf-http-wg@w3.org> [51] <mailto:ietf-http-wg@w3.org>
[52] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> [52] <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
skipping to change at page 180, line 43 skipping to change at page 183, line 43
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).
D.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 CTE encoding prior to delivering the response message
encoding prior to delivering the response message to an HTTP client. 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.
D.6. Introduction of Transfer-Encoding D.6. Introduction of Transfer-Encoding
skipping to change at page 183, line 33 skipping to change at page 186, 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].
F.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.
F.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 (section missing from an HTTP/1.1 request, and accept absolute URIs
5.1.2) are among the most important changes defined by this (Section 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 188, line 5 skipping to change at page 190, line 31
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].
F.4. Changes from RFC 2616
Clarify that HTTP-Version is case sensitive. (Section 3.1)
Eliminate overlooked reference to "unsafe" characters.
(Section 3.2.3)
Clarify contexts that charset is used in. (Section 3.4)
Remove reference to non-existant identity transfer-coding value
tokens. (Sections 3.6, 4.4 and D.5)
Clarification that the chunk length does not include the count of the
octets in the chunk header and trailer. (Section 3.6.1)
Fix BNF to add query, as the abs_path production in Section 3 of [42]
doesn't define it. (Section 5.1.2)
Clarify definition of POST. (Section 9.5)
Clarify that it's not ok to use a weak cache validator in a 206
response. (Section 10.2.7)
Failed to consider that there are many other request methods that are
safe to automatically redirect, and further that the user agent is
able to make that determination based on the request method
semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 )
Fix misspelled header. (Section 13.5.1)
Clarify denial of service attack avoidance requirement.
(Section 13.10)
Clarify exactly when close connection options must be sent.
(Section 14.10)
Correct syntax of Location header to allow fragment, as referred
symbol wasn't what was expected, and add some clarifications as to
when it would not be appropriate. (Section 14.30)
In the description of the Server header, the Via field was described
as a SHOULD. The requirement was and is stated correctly in the
description of the Via header, Section 14.45. (Section 14.38)
Appendix G. Change Log (to be removed by RFC Editor before publication) Appendix G. Change Log (to be removed by RFC Editor before publication)
G.1. Since RFC2616 G.1. Since RFC2616
Update Authors. Add Editorial Note and Acknowledgements (containing Update Authors. Add Editorial Note and Acknowledgements (containing
the original RFC2616 authors). Add "Normative References", the original RFC2616 authors). Add "Normative References",
containing just RFC2616 for now. containing just RFC2616 for now.
Appendix H. Open issues (to be removed by RFC Editor prior to G.2. Since draft-lafon-rfc2616bis-00
Add and resolve issues "charactersets", "chunk-size", "editor-notes",
"identity", "ifrange206", "invalidupd", "msg-len-chars",
"noclose1xx", "post", "saferedirect", "trailer-hop", "unsafe-uri",
"uriquery", "verscase" and "via-must" as proposed in
<http://purl.org/NET/http-errata>. Add and resolve issue "rfc2606-
compliance".
Add issues "languagetag", "media-reg" and "unneeded_references". Add
issue "location-fragments" and partly resolve it.
Reformat HTTP-WG contributors as a plain text paragraph.
Change [RFC2616] to be an informative reference. Fix RFC2026
reference (broken in draft 00). Outdent artwork to more closely
match RFC2616. (No change tracking for these changes).
Mark Yves Lafon and Julian Reschke as "Editor" in the front page and
the Authors section. Re-add all of the authors of RFC2616 for now.
(No change tracking for these changes).
Appendix H. Resolved issues (to be removed by RFC Editor before
publication) publication)
H.1. rfc2616bis Issues that were either rejected or resolved in this version of this
document.
H.1. rfc2606-compliance
Type: edit
julian.reschke@greenbytes.de (2006-10-19): Make sure that domain
names in examples use names reserved for that purpose (see RFC2606).
Resolution: Done.
H.2. editor-notes
Type: edit
<http://purl.org/NET/http-errata#editor-notes>
fielding@kiwi.ics.uci.edu (1999-08-03): See http://lists.w3.org/
Archives/Public/ietf-http-wg-old/1999MayAug/0102.html.
Resolution (2006-10-14): Not applicable. New References section is
generated by xml2rfc.
H.3. verscase
In Section 3.1:
Type: change
<http://purl.org/NET/http-errata#verscase>
fielding@apache.org (2002-09-16): See http://lists.w3.org/Archives/
Public/ietf-http-wg/2002JulSep/0066.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#verscase.
H.4. unsafe-uri
In Section 3.2.3:
Type: change
<http://purl.org/NET/http-errata#unsafe-uri>
fielding@kiwi.ICS.UCI.EDU (1999-09-10): See
http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1999/0273.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#unsafe-uri.
H.5. charactersets
In Section 3.4:
Type: change
<http://purl.org/NET/http-errata#charactersets>
Howard@silverstream.com (2001-02-08): See http://lists.w3.org/
Archives/Public/ietf-http-wg-old/2001JanApr/0022.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#charactersets.
H.6. identity
In Section 3.6:
Type: change
<http://purl.org/NET/http-errata#identity>
LMM@acm.org (2001-11-05): See http://lists.w3.org/Archives/Public/
ietf-http-wg-old/2001SepDec/0018.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#identity.
H.7. chunk-size
In Section 3.6.1:
Type: change
<http://purl.org/NET/http-errata#chunk-size>
wham_bang@yahoo.com (1999-06-02): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/1999MayAug/0018.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#chunk-size.
H.8. msg-len-chars
In Section 4.4:
Type: edit
<http://purl.org/NET/http-errata#msg-len-chars>
fielding@kiwi.ics.uci.edu (1999-08-03): See http://lists.w3.org/
Archives/Public/ietf-http-wg-old/1999MayAug/0102.html.
Resolution (2006-10-13): Resolved as per
http://purl.org/NET/http-errata#msg-len-chars.
H.9. uriquery
In Section 5.1:
Type: change
<http://purl.org/NET/http-errata#uriquery>
LMM@acm.org (2001-07-30): See http://lists.w3.org/Archives/Public/
ietf-http-wg-old/2001MayAug/0034.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#uriquery.
H.10. post
In Section 9.5:
Type: change
<http://purl.org/NET/http-errata#post>
mogul@pa.dec.com (2002-04-09): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/2002JanApr/0024.html.
Resolution (2006-10-16): Resolved as per
http://purl.org/NET/http-errata#post.
H.11. ifrange206
In Section 10.2.7:
Type: change
<http://purl.org/NET/http-errata#identity>
rousskov@measurement-factory.com (2003-04-15): See http://
lists.w3.org/Archives/Public/ietf-http-wg/2003AprJun/0003.html.
Resolution (2006-10-16): Resolved as per
http://purl.org/NET/http-errata#ifrange206.
H.12. saferedirect
In Section 10.3.2:
Type: change
<http://purl.org/NET/http-errata#saferedirect>
fielding@ebuilt.com (2001-03-03): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/2001JanApr/0031.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#saferedirect.
H.13. trailer-hop
In Section 13.5.1:
Type: edit
<http://purl.org/NET/http-errata#trailer-hop>
mogul@pa.dec.com (2000-12-04): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/2000SepDec/0127.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#trailer-hop.
H.14. invalidupd
In Section 13.10:
Type: change
<http://purl.org/NET/http-errata#invalidupd>
Jeff.Mogul@hp.com (2002-06-21): See http://lists.w3.org/Archives/
Public/ietf-http-wg/2002AprJun/0058.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#invalidupd.
H.15. noclose1xx
In Section 14.10:
Type: change
<http://purl.org/NET/http-errata#noclose1xx>
fielding@ebuilt.com (2001-11-08): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/2001SepDec/0022.html.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#noclose1xx.
H.16. via-must
In Section 14.38:
Type: change
<http://purl.org/NET/http-errata#via-must>
julian.reschke@greenbytes.de (2006-10-14): See
http://purl.org/NET/http-errata#via-must.
Resolution (2006-10-14): Resolved as per
http://purl.org/NET/http-errata#via-must.
Appendix I. Open issues (to be removed by RFC Editor prior to
publication)
I.1. rfc2616bis
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes
with respect to the revision process itself. with respect to the revision process itself.
H.2. edit I.2. unneeded_references
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-08-10): Umbrella issue for <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/
0054.html>
julian.reschke@greenbytes.de (2006-10-19): The reference entries for
RFC1866, RFC2069 and RFC2026 are unused. Remove them?
I.3. edit
Type: edit
julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for
editorial fixes/enhancements. editorial fixes/enhancements.
I.4. media-reg
In Section 3.7:
Type: change
<http://purl.org/NET/http-errata#media-reg>
derhoermi@gmx.net (2000-09-10): See http://lists.w3.org/Archives/
Public/ietf-http-wg-old/2000SepDec/0013.html.
julian.reschke@greenbytes.de (2006-10-14): Resolve as part of general
update and reclassification of references.
I.5. languagetag
In Section 3:
Type: change
<http://purl.org/NET/http-errata#languagetag>
julian.reschke@greenbytes.de (2006-10-14): See
http://purl.org/NET/http-errata#languagetag.
julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066
has been obsoleted by RFC4646. See also http://lists.w3.org/
Archives/Public/ietf-http-wg/2006OctDec/0001.html.
I.6. location-fragments
In Section 14.30:
Type: change
<http://purl.org/NET/http-errata#location-fragments>
fielding@kiwi.ics.uci.edu (1999-08-06): See http://lists.w3.org/
Archives/Public/ietf-http-wg-old/1999MayAug/0103.html.
julian.reschke@greenbytes.de (2006-10-16): Fix BNF and add note about
when it's appropriate to use fragments as suggested in
http://purl.org/NET/http-errata#location-fragments. This leaves us
with the open issue: _At present, the behavior in the case where
there was a fragment with the original URI, e.g.:
http://host1.example.com/resource1#fragment1 where /resource1
redirects to http://host2.example.com/resource2#fragment2 is
'fragment1' discarded? Do you find fragment2 and then find fragment1
within it? We don't have fragment combination rules._.
Index Index
1 1
100 Continue (status code) 65 100 Continue (status code) 68
101 Switching Protocols (status code) 65 101 Switching Protocols (status code) 68
2 2
200 OK (status code) 66 200 OK (status code) 69
201 Created (status code) 66 201 Created (status code) 69
202 Accepted (status code) 66 202 Accepted (status code) 69
203 Non-Authoritative Information (status code) 67 203 Non-Authoritative Information (status code) 70
204 No Content (status code) 67 204 No Content (status code) 70
205 Reset Content (status code) 67 205 Reset Content (status code) 70
206 Partial Content (status code) 68 206 Partial Content (status code) 71
3 3
300 Multiple Choices (status code) 69 300 Multiple Choices (status code) 72
301 Moved Permanently (status code) 69 301 Moved Permanently (status code) 72
302 Found (status code) 70 302 Found (status code) 73
303 See Other (status code) 70 303 See Other (status code) 73
304 Not Modified (status code) 71 304 Not Modified (status code) 74
305 Use Proxy (status code) 71 305 Use Proxy (status code) 74
306 (Unused) (status code) 72 306 (Unused) (status code) 75
307 Temporary Redirect (status code) 72 307 Temporary Redirect (status code) 75
4 4
400 Bad Request (status code) 73 400 Bad Request (status code) 76
401 Unauthorized (status code) 73 401 Unauthorized (status code) 76
402 Payment Required (status code) 73 402 Payment Required (status code) 76
403 Forbidden (status code) 73 403 Forbidden (status code) 76
404 Not Found (status code) 73 404 Not Found (status code) 76
405 Method Not Allowed (status code) 74 405 Method Not Allowed (status code) 77
406 Not Acceptable (status code) 74 406 Not Acceptable (status code) 77
407 Proxy Authentication Required (status code) 74 407 Proxy Authentication Required (status code) 77
408 Request Timeout (status code) 75 408 Request Timeout (status code) 78
409 Conflict (status code) 75 409 Conflict (status code) 78
410 Gone (status code) 75 410 Gone (status code) 78
411 Length Required (status code) 76 411 Length Required (status code) 79
412 Precondition Failed (status code) 76 412 Precondition Failed (status code) 79
413 Request Entity Too Large (status code) 76 413 Request Entity Too Large (status code) 79
414 Request-URI Too Long (status code) 76 414 Request-URI Too Long (status code) 79
415 Unsupported Media Type (status code) 76 415 Unsupported Media Type (status code) 79
416 Requested Range Not Satisfiable (status code) 76 416 Requested Range Not Satisfiable (status code) 79
417 Expectation Failed (status code) 77 417 Expectation Failed (status code) 80
5 5
500 Internal Server Error (status code) 77 500 Internal Server Error (status code) 80
501 Not Implemented (status code) 77 501 Not Implemented (status code) 80
502 Bad Gateway (status code) 77 502 Bad Gateway (status code) 80
503 Service Unavailable (status code) 78 503 Service Unavailable (status code) 81
504 Gateway Timeout (status code) 78 504 Gateway Timeout (status code) 81
505 HTTP Version Not Supported (status code) 78 505 HTTP Version Not Supported (status code) 81
A A
Accept header 109 Accept header 112
Accept-Charset header 111 Accept-Charset header 114
Accept-Encoding header 111 Accept-Encoding header 114
Accept-Language header 113 Accept-Language header 116
Accept-Ranges header 114 Accept-Ranges header 117
Age header 114 Age header 117
age 14 age 16
Allow header 115 Allow header 118
Authorization header 116 Authorization header 119
C C
Cache Directives Cache Directives
max-age 121, 123 max-age 124, 126
max-stale 121 max-stale 124
min-fresh 121 min-fresh 124
must-revalidate 123 must-revalidate 126
no-cache 119 no-cache 122
no-store 119 no-store 122
no-transform 125 no-transform 128
only-if-cached 123 only-if-cached 126
private 118 private 121
proxy-revalidate 124 proxy-revalidate 127
public 118 public 121
s-maxage 120 s-maxage 123
cache 13 cache 15
Cache-Control header 116 Cache-Control header 119
cacheable 13 cacheable 15
client 12 client 14
compress 27 compress 30
CONNECT method 64 CONNECT method 67
Connection header 126 Connection header 129
connection 11 connection 13
content negotiation 12 content negotiation 14
Content-Encoding header 127 Content-Encoding header 130
Content-Language header 128 Content-Language header 131
Content-Length header 128 Content-Length header 131
Content-Location header 129 Content-Location header 132
Content-MD5 header 130 Content-MD5 header 133
Content-Range header 131 Content-Range header 134
Content-Type header 133 Content-Type header 136
D D
Date header 133 Date header 137
deflate 28 deflate 30
DELETE method 63 DELETE method 66
downstream 15 downstream 17
E E
entity 11 entity 13
ETag header 135 ETag header 138
Expect header 135 Expect header 138
Expires header 136 Expires header 139
explicit expiration time 14 explicit expiration time 16
F F
first-hand 13 first-hand 15
fresh 14 fresh 16
freshness lifetime 14 freshness lifetime 16
From header 137 From header 140
G G
gateway 13 gateway 15
GET method 60 GET method 63
Grammar Grammar
Accept 109 Accept 112
Accept-Charset 111 Accept-Charset 114
Accept-Encoding 111 Accept-Encoding 114
accept-extension 109 accept-extension 112
Accept-Language 113 Accept-Language 116
accept-params 109 accept-params 112
Accept-Ranges 114 Accept-Ranges 117
acceptable-ranges 114 acceptable-ranges 117
Age 115 Age 118
age-value 115 age-value 118
Allow 115 Allow 118
ALPHA 20 ALPHA 22
asctime-date 25 asctime-date 28
attribute 28 attribute 31
Authorization 116 Authorization 119
byte-content-range-spec 131 byte-content-range-spec 134
byte-range-resp-spec 131 byte-range-resp-spec 134
byte-range-set 147 byte-range-set 150
byte-range-spec 147 byte-range-spec 150
byte-ranges-specifier 147 byte-ranges-specifier 150
bytes-unit 35 bytes-unit 37
Cache-Control 117 Cache-Control 120
cache-directive 117 cache-directive 120
cache-extension 117 cache-extension 120
cache-request-directive 117 cache-request-directive 120
cache-response-directive 117 cache-response-directive 120
CHAR 20 CHAR 22
charset 26 charset 29
chunk 30 chunk 32
chunk-data 30 chunk-data 32
chunk-ext-name 30 chunk-ext-name 32
chunk-ext-val 30 chunk-ext-val 32
chunk-extension 30 chunk-extension 32
chunk-size 30 chunk-size 32
Chunked-Body 30 Chunked-Body 32
codings 111 codings 114
comment 21 comment 23
Connection 126 Connection 129
connection-token 126 connection-token 129
content-coding 27 content-coding 30
content-disposition 182 content-disposition 185
Content-Encoding 127 Content-Encoding 130
Content-Language 128 Content-Language 131
Content-Length 128 Content-Length 132
Content-Location 129 Content-Location 132
Content-MD5 130 Content-MD5 133
Content-Range 131 Content-Range 134
content-range-spec 131 content-range-spec 134
Content-Type 133 Content-Type 136
CR 20 CR 22
CRLF 20 CRLF 22
ctext 21 ctext 23
CTL 20 CTL 22
Date 134 Date 137
date1 25 date1 28
date2 25 date2 28
date3 25 date3 28
delta-seconds 26 delta-seconds 28
DIGIT 20 DIGIT 22
disp-extension-parm 182 disp-extension-parm 185
disp-extension-token 182 disp-extension-token 185
disposition-parm 182 disposition-parm 185
disposition-type 182 disposition-type 185
entity-body 49 entity-body 52
entity-header 49 entity-header 52
entity-tag 34 entity-tag 37
ETag 135 ETag 138
Expect 135 Expect 138
expect-params 135 expect-params 138
expectation 135 expectation 138
expectation-extension 135 expectation-extension 138
Expires 136 Expires 139
extension-code 47 extension-code 50
extension-header 49 extension-header 52
extension-method 41 extension-method 44
extension-pragma 145 extension-pragma 149
field-content 37 field-content 40
field-name 37 field-name 40
field-value 37 field-value 40
filename-parm 182 filename-parm 185
first-byte-pos 147 first-byte-pos 150
From 137 From 140
general-header 40 general-header 43
generic-message 36 generic-message 39
HEX 21 HEX 23
Host 138 Host 141
HT 20 HT 22
HTTP-date 25 HTTP-date 28
HTTP-message 36 HTTP-message 39
HTTP-Version 22 HTTP-Version 24
http_URL 23 http_URL 26
If-Match 138 If-Match 141
If-Modified-Since 139 If-Modified-Since 143
If-None-Match 141 If-None-Match 144
If-Range 142 If-Range 145
If-Unmodified-Since 143 If-Unmodified-Since 146
instance-length 131 instance-length 134
language-range 113 language-range 116
language-tag 34 language-tag 36
last-byte-pos 147 last-byte-pos 150
last-chunk 30 last-chunk 32
Last-Modified 143 Last-Modified 146
LF 20 LF 22
LOALPHA 20 LOALPHA 22
Location 144 Location 147
LWS 20 LWS 22
Max-Forwards 145 Max-Forwards 148
md5-digest 130 md5-digest 133
media-range 109 media-range 112
media-type 31 media-type 33
message-body 37 message-body 40
message-header 37 message-header 40
Method 41 Method 44
MIME-Version 179 MIME-Version 182
month 25 month 28
OCTET 20 OCTET 22
opaque-tag 34 opaque-tag 37
other-range-unit 35 other-range-unit 37
parameter 28 parameter 31
Pragma 145 Pragma 149
pragma-directive 145 pragma-directive 149
primary-tag 34 primary-tag 36
product 33 product 35
product-version 33 product-version 35
protocol-name 155 protocol-name 159
protocol-version 155 protocol-version 159
Proxy-Authenticate 146 Proxy-Authenticate 149
Proxy-Authorization 146 Proxy-Authorization 150
pseudonym 155 pseudonym 159
qdtext 21 qdtext 23
quoted-pair 21 quoted-pair 23
quoted-string 21 quoted-string 23
qvalue 33 qvalue 36
Range 148 Range 152
range-unit 35 range-unit 37
ranges-specifier 147 ranges-specifier 150
Reason-Phrase 47 Reason-Phrase 50
received-by 155 received-by 159
received-protocol 155 received-protocol 159
Referer 149 Referer 153
Request 41 Request 44
request-header 44 request-header 47
Request-Line 41 Request-Line 44
Request-URI 42 Request-URI 45
Response 45 Response 48
response-header 48 response-header 51
Retry-After 150 Retry-After 153
rfc850-date 25 rfc850-date 28
rfc1123-date 25 rfc1123-date 28
separators 21 separators 23
Server 150 Server 154
SP 20 SP 22
start-line 36 start-line 39
Status-Code 47 Status-Code 50
Status-Line 45 Status-Line 48
subtag 34 subtag 36
subtype 31 subtype 33
suffix-byte-range-spec 147 suffix-byte-range-spec 151
suffix-length 147 suffix-length 151
t-codings 151 t-codings 154
TE 151 TE 154
TEXT 20 TEXT 22
time 25 time 28
token 21 token 23
Trailer 152 Trailer 155
trailer 30 trailer 32
transfer-coding 28 transfer-coding 31
Transfer-Encoding 152 Transfer-Encoding 156
transfer-extension 28 transfer-extension 31
type 31 type 33
UPALPHA 20 UPALPHA 22
Upgrade 153 Upgrade 156
User-Agent 154 User-Agent 157
value 28 value 31
Vary 154 Vary 158
Via 155 Via 159
warn-agent 157 warn-agent 160
warn-code 157 warn-code 160
warn-date 157 warn-date 160
warn-text 157 warn-text 160
Warning 157 Warning 160
warning-value 157 warning-value 160
weak 34 weak 37
weekday 25 weekday 28
wkday 25 wkday 28
WWW-Authenticate 159 WWW-Authenticate 163
gzip 27 gzip 30
H H
HEAD method 60 HEAD method 63
Headers Headers
Accept 109 Accept 112
Accept-Charset 111 Accept-Charset 114
Accept-Encoding 111 Accept-Encoding 114
Accept-Language 113 Accept-Language 116
Accept-Ranges 114 Accept-Ranges 117
Age 114 Age 117
Allow 115 Allow 118
Authorization 116 Authorization 119
Cache-Control 116 Cache-Control 119
Connection 126 Connection 129
Content-Encoding 127 Content-Encoding 130
Content-Language 128 Content-Language 131
Content-Length 128 Content-Length 131
Content-Location 129 Content-Location 132
Content-MD5 130 Content-MD5 133
Content-Range 131 Content-Range 134
Content-Type 133 Content-Type 136
Date 133 Date 137
ETag 135 ETag 138
Expect 135 Expect 138
Expires 136 Expires 139
From 137 From 140
Host 137 Host 141
If-Match 138 If-Match 141
If-Modified-Since 139 If-Modified-Since 142
If-None-Match 141 If-None-Match 144
If-Range 142 If-Range 145
If-Unmodified-Since 143 If-Unmodified-Since 146
Last-Modified 143 Last-Modified 146
Location 144 Location 147
Max-Forwards 144 Max-Forwards 148
Pragma 145 Pragma 148
Proxy-Authenticate 146 Proxy-Authenticate 149
Proxy-Authorization 146 Proxy-Authorization 150
Range 147 Range 150
Referer 149 Referer 153
Retry-After 150 Retry-After 153
Server 150 Server 153
TE 151 TE 154
Trailer 152 Trailer 155
Transfer-Encoding 152 Transfer-Encoding 156
Upgrade 153 Upgrade 156
User-Agent 154 User-Agent 157
Vary 154 Vary 158
Via 155 Via 158
Warning 157 Warning 160
WWW-Authenticate 159 WWW-Authenticate 163
heuristic expiration time 14 heuristic expiration time 16
Host header 137 Host header 141
I I
identity 28 identity 30
If-Match header 138 If-Match header 141
If-Modified-Since header 139 If-Modified-Since header 142
If-None-Match header 141 If-None-Match header 144
If-Range header 142 If-Range header 145
If-Unmodified-Since header 143 If-Unmodified-Since header 146
inbound 15 inbound 17
L L
Last-Modified header 143 Last-Modified header 146
Location header 144 Location header 147
M M
max-age max-age
Cache Directive 121, 123 Cache Directive 124, 126
Max-Forwards header 144 Max-Forwards header 148
max-stale max-stale
Cache Directive 121 Cache Directive 124
message 11 message 13
Methods Methods
CONNECT 64 CONNECT 67
DELETE 63 DELETE 66
GET 60 GET 63
HEAD 60 HEAD 63
OPTIONS 59 OPTIONS 62
POST 61 POST 64
PUT 62 PUT 65
TRACE 63 TRACE 66
min-fresh min-fresh
Cache Directive 121 Cache Directive 124
must-revalidate must-revalidate
Cache Directive 123 Cache Directive 126
N N
no-cache no-cache
Cache Directive 119 Cache Directive 122
no-store no-store
Cache Directive 119 Cache Directive 122
no-transform no-transform
Cache Directive 125 Cache Directive 128
O O
only-if-cached only-if-cached
Cache Directive 123 Cache Directive 126
OPTIONS method 59 OPTIONS method 62
origin server 12 origin server 14
outbound 15 outbound 17
P P
POST method 61 POST method 64
Pragma header 145 Pragma header 148
private private
Cache Directive 118 Cache Directive 121
proxy 12 proxy 14
Proxy-Authenticate header 146 Proxy-Authenticate header 149
Proxy-Authorization header 146 Proxy-Authorization header 150
proxy-revalidate proxy-revalidate
Cache Directive 124 Cache Directive 127
public public
Cache Directive 118 Cache Directive 121
PUT method 62 PUT method 65
R R
Range header 147 Range header 150
Referer header 149 Referer header 153
representation 11 representation 13
request 11 request 13
resource 11 resource 13
response 11 response 13
Retry-After header 150 Retry-After header 153
S S
s-maxage s-maxage
Cache Directive 120 Cache Directive 123
semantically transparent 14 semantically transparent 16
Server header 150 Server header 153
server 12 server 14
stale 14 stale 16