draft-lafon-rfc2616bis-04.txt   draft-lafon-rfc2616bis-latest.txt 
Network Working Group R. Fielding Network Working Group R. Fielding
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: May 21, 2008 J. Mogul Expires: June 3, 2008 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
November 18, 2007 December 2007
Hypertext Transfer Protocol -- HTTP/1.1 Hypertext Transfer Protocol -- HTTP/1.1
draft-lafon-rfc2616bis-04 draft-lafon-rfc2616bis-latest
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 49 skipping to change at page 1, line 49
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 May 21, 2008. This Internet-Draft will expire on June 3, 2008.
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its distributed object management systems, through extension of its
request methods, error codes and headers [RFC2324]. A feature of request methods, error codes and headers [RFC2324]. A feature of
HTTP is the typing and negotiation of data representation, allowing HTTP is the typing and negotiation of data representation, allowing
skipping to change at page 4, line 31 skipping to change at page 4, line 31
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 34 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 35
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41
skipping to change at page 5, line 52 skipping to change at page 5, line 52
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 69 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 69
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 69 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 69
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 69 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 69
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 70 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 70
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 70 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 70
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 71 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 71
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 71 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 71
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 72 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 72
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 72 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 72
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 73 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 73
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 73 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 74
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 74 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 74
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 74 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 74
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 74 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 74
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 75 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 75
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 75 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 75
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 75 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 75
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 75 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 76
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 76 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 76
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 76 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 76
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 76 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 77
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 77 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 77
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 77 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 77
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 77 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 77
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 78 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 78
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 78 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 78
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 78 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 78
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 78 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 78
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 78 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 79
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 78 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 79
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 79 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 79
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 79 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 79
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 79 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 79
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 79 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 79
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 79 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 80
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 80 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 80
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 80 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 80
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 80 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 80
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 81 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 81
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 82 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 82
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 82 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 82
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 83 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 83
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 84 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 84
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 85 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 85
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 85
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 86 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 86
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 87 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 87
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 88 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 88
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 88 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 88
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 89 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 89
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 89 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 89
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 90 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 90
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 90 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 90
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 90 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 90
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 91 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 91
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 93 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 93
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 94 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 94
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 95 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 95
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 95 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 95
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 96 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 96
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 96 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 96
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 97 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 97
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 . . . . . . . . . . . . . . . . 99 Last-Modified Dates . . . . . . . . . . . . . . . . 100
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 101 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 101
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 101 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 102
13.5. Constructing Responses From Caches . . . . . . . . . . . 102 13.5. Constructing Responses From Caches . . . . . . . . . . . 102
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 102 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 103
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 103 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 103
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 104 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 105
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 105 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 106
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 106 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 106
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 107 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 107
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 107 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 108
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 108 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 108
13.10. Invalidation After Updates or Deletions . . . . . . . . 108 13.10. Invalidation After Updates or Deletions . . . . . . . . 108
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 109 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 109
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 109 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 110
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 110 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 110
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 111 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 111
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 111 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 111
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 113 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 113
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 113 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 113
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 116 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 116
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 117 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 117
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 117 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 117
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 120 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 120
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 121 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 121
14.9.3. Modifications of the Basic Expiration Mechanism . . 122 14.9.3. Modifications of the Basic Expiration Mechanism . . 122
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 124 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 124
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 126 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 126
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 127 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 127
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 128 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 128
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 129 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 129
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 129 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 130
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 130 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 130
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 131 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 131
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 132 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 132
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 133 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 133
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 135 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 135
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 136
14.18.1. Clockless Origin Server Operation . . . . . . . . . 136 14.18.1. Clockless Origin Server Operation . . . . . . . . . 137
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 137 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 137 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 138 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 138
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 139 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 139
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 139 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 140
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 140 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 140
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 141 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 141
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 143 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 143
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 144 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 144
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 145 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 145
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 146 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 146
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 147 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 147
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 147 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 147
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 148 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 148
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 148 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 149
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 149 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 149
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 149 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 149
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 150 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 151
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 151 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 152
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 152 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 152
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 152 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 152
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 154 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 154
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 154 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 155
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 155 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 155
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 156 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 156
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 156 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 159 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 159
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 161 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 162
15. Security Considerations . . . . . . . . . . . . . . . . . . . 162 15. Security Considerations . . . . . . . . . . . . . . . . . . . 163
15.1. Personal Information . . . . . . . . . . . . . . . . . . 162 15.1. Personal Information . . . . . . . . . . . . . . . . . . 163
15.1.1. Abuse of Server Log Information . . . . . . . . . . 162 15.1.1. Abuse of Server Log Information . . . . . . . . . . 163
15.1.2. Transfer of Sensitive Information . . . . . . . . . 162 15.1.2. Transfer of Sensitive Information . . . . . . . . . 163
15.1.3. Encoding Sensitive Information in URI's . . . . . . 163 15.1.3. Encoding Sensitive Information in URI's . . . . . . 164
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 164 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 165
15.2. Attacks Based On File and Path Names . . . . . . . . . . 164 15.2. Attacks Based On File and Path Names . . . . . . . . . . 165
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 165 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 166
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 165 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 166
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 166 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 167
15.6. Authentication Credentials and Idle Clients . . . . . . 166 15.6. Authentication Credentials and Idle Clients . . . . . . 167
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 166 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 167
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 167 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 168
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 168 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 169
16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 168 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 169
16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 169 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 170
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 170 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 171
17.1. References (to be classified) . . . . . . . . . . . . . 170 17.1. Normative References . . . . . . . . . . . . . . . . . . 171
17.2. Normative References . . . . . . . . . . . . . . . . . . 170 17.2. Informative References . . . . . . . . . . . . . . . . . 172
17.3. Informative References . . . . . . . . . . . . . . . . . 171
Appendix A. Internet Media Type message/http and Appendix A. Internet Media Type message/http and
application/http . . . . . . . . . . . . . . . . . . 176 application/http . . . . . . . . . . . . . . . . . . 177
Appendix B. Internet Media Type multipart/byteranges . . . . . . 178 Appendix B. Internet Media Type multipart/byteranges . . . . . . 180
Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 180 Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 182
Appendix D. Differences Between HTTP Entities and RFC 2045 Appendix D. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 181 Entities . . . . . . . . . . . . . . . . . . . . . . 183
D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 181 D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 183
D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 181 D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 183
D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 182 D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 184
D.4. Introduction of Content-Encoding . . . . . . . . . . . . 182 D.4. Introduction of Content-Encoding . . . . . . . . . . . . 184
D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 182 D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 184
D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 183 D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 185
D.7. MHTML and Line Length Limitations . . . . . . . . . . . 183 D.7. MHTML and Line Length Limitations . . . . . . . . . . . 185
Appendix E. Additional Features . . . . . . . . . . . . . . . . 184 Appendix E. Additional Features . . . . . . . . . . . . . . . . 186
E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 184 E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 186
Appendix F. Compatibility with Previous Versions . . . . . . . . 185 Appendix F. Compatibility with Previous Versions . . . . . . . . 187
F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 185 F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 187
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 . . . . . . . . . . . . . . . 185 Conserve IP Addresses . . . . . . . . . . . . . . . 187
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 186 F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 188
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 187 F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 189
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 189 F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 191
Appendix G. Change Log (to be removed by RFC Editor before Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 191 publication) . . . . . . . . . . . . . . . . . . . . 193
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 191 G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 193
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 191 G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 193
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 191 G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 193
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 191 G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 193
G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 192 G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 194
G.6. Since draft-lafon-rfc2616bis-04 . . . . . . . . . . . . 195
Appendix H. Resolved issues (to be removed by RFC Editor Appendix H. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . 194 before publication) . . . . . . . . . . . . . . . . 196
H.1. unneeded_references . . . . . . . . . . . . . . . . . . 194 H.1. abnf-dquote . . . . . . . . . . . . . . . . . . . . . . 196
H.2. consistent-reason-phrases . . . . . . . . . . . . . . . 194 H.2. abnf-rule-names . . . . . . . . . . . . . . . . . . . . 196
H.3. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 194 H.3. abnf-prose-cr . . . . . . . . . . . . . . . . . . . . . 196
H.4. abnf-edit . . . . . . . . . . . . . . . . . . . . . . . 195 H.4. abnf-case-insensitive . . . . . . . . . . . . . . . . . 196
H.5. rfc1766_normative . . . . . . . . . . . . . . . . . . . 195 H.5. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 197
H.6. i86-normative-up-to-date-references . . . . . . . . . . 195 H.6. abnf-chunk-data . . . . . . . . . . . . . . . . . . . . 198
H.7. i68-encoding-references-normative . . . . . . . . . . . 196 H.7. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 198
H.8. rfc2396_normative . . . . . . . . . . . . . . . . . . . 196
H.9. usascii_normative . . . . . . . . . . . . . . . . . . . 196
H.10. i65-informative-references . . . . . . . . . . . . . . . 196
H.11. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 197
H.12. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 198
H.13. i26-import-query-bnf . . . . . . . . . . . . . . . . . . 198
H.14. i47-inconsistency-in-date-format-explanation . . . . . . 199
H.15. media-reg . . . . . . . . . . . . . . . . . . . . . . . 199
H.16. i84-redundant-cross-references . . . . . . . . . . . . . 200
H.17. i87-typo-in-13.2.2 . . . . . . . . . . . . . . . . . . . 200
H.18. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 201
H.19. remove-CTE-abbrev . . . . . . . . . . . . . . . . . . . 202
Appendix I. Open issues (to be removed by RFC Editor prior to Appendix I. Open issues (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 203 publication) . . . . . . . . . . . . . . . . . . . . 201
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 203 I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 201
I.2. i35-split-normative-and-informative-references . . . . . 203 I.2. i35-split-normative-and-informative-references . . . . . 201
I.3. i40-header-registration . . . . . . . . . . . . . . . . 203 I.3. i40-header-registration . . . . . . . . . . . . . . . . 201
I.4. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 203 I.4. need_iana_considerations . . . . . . . . . . . . . . . . 201
I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 203 I.5. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 202
I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 204 I.6. abnf-avoid-prose . . . . . . . . . . . . . . . . . . . . 202
I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 204 I.7. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 202
I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 204 I.8. rfc2822_normative . . . . . . . . . . . . . . . . . . . 202
I.9. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 205 I.9. rfc1737_informative_and_obsolete . . . . . . . . . . . . 203
I.10. i63-header-length-limit-with-encoded-words . . . . . . . 205 I.10. rfc2048_informative_and_obsolete . . . . . . . . . . . . 203
I.11. i74-character-encodings-for-headers . . . . . . . . . . 206 I.11. i34-updated-reference-for-uris . . . . . . . . . . . . . 203
I.12. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 206 I.12. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 203
I.13. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 207 I.13. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 204
I.14. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 207 I.14. i63-header-length-limit-with-encoded-words . . . . . . . 204
I.15. i58-what-identifies-an-http-resource . . . . . . . . . . 208 I.15. i74-character-encodings-for-headers . . . . . . . . . . 205
I.16. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 208 I.16. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 205
I.17. i73-clarification-of-the-term-deflate . . . . . . . . . 209 I.17. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 206
I.18. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 209 I.18. i58-what-identifies-an-http-resource . . . . . . . . . . 206
I.19. i20-default-charsets-for-text-media-types . . . . . . . 209 I.19. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 206
I.20. languagetag . . . . . . . . . . . . . . . . . . . . . . 211 I.20. i73-clarification-of-the-term-deflate . . . . . . . . . 207
I.21. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 211 I.21. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 207
I.22. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 212 I.22. i20-default-charsets-for-text-media-types . . . . . . . 208
I.23. i77-line-folding . . . . . . . . . . . . . . . . . . . . 212 I.23. i90-delimiting-messages-with-multipart-byteranges . . . 209
I.24. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 213 I.24. languagetag . . . . . . . . . . . . . . . . . . . . . . 210
I.25. i28-connection-closing . . . . . . . . . . . . . . . . . 213 I.25. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 210
I.26. i32-options-asterisk . . . . . . . . . . . . . . . . . . 213 I.26. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 211
I.27. i83-options-asterisk-and-proxies . . . . . . . . . . . . 214 I.27. i77-line-folding . . . . . . . . . . . . . . . . . . . . 211
I.28. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 215 I.28. i93-repeating-single-value-headers . . . . . . . . . . . 212
I.29. i57-status-code-and-reason-phrase . . . . . . . . . . . 215 I.29. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 212
I.30. i59-status-code-registry . . . . . . . . . . . . . . . . 216 I.30. i88-205-bodies . . . . . . . . . . . . . . . . . . . . . 213
I.31. i72-request-method-registry . . . . . . . . . . . . . . 216 I.31. i28-connection-closing . . . . . . . . . . . . . . . . . 213
I.32. i21-put-side-effects . . . . . . . . . . . . . . . . . . 216 I.32. uri_vs_request_uri . . . . . . . . . . . . . . . . . . . 213
I.33. i27-put-idempotency . . . . . . . . . . . . . . . . . . 217 I.33. i32-options-asterisk . . . . . . . . . . . . . . . . . . 213
I.34. i79-content-headers-vs-put . . . . . . . . . . . . . . . 218 I.34. i83-options-asterisk-and-proxies . . . . . . . . . . . . 214
I.35. i33-trace-security-considerations . . . . . . . . . . . 218 I.35. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 215
I.36. i69-clarify-requested-variant . . . . . . . . . . . . . 219 I.36. i57-status-code-and-reason-phrase . . . . . . . . . . . 215
I.37. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 220 I.37. i59-status-code-registry . . . . . . . . . . . . . . . . 216
I.38. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 222 I.38. i94-reason-phrase-bnf . . . . . . . . . . . . . . . . . 216
I.39. i78-relationship-between-401-authorization-and-www-authe 222 I.39. i91-duplicate-host-header-requirements . . . . . . . . . 216
I.40. i24-requiring-allow-in-405-responses . . . . . . . . . . 223 I.40. i72-request-method-registry . . . . . . . . . . . . . . 217
I.41. i81-content-negotiation-for-media-types . . . . . . . . 223 I.41. i21-put-side-effects . . . . . . . . . . . . . . . . . . 217
I.42. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 225 I.42. i27-put-idempotency . . . . . . . . . . . . . . . . . . 218
I.43. i29-age-calculation . . . . . . . . . . . . . . . . . . 225 I.43. i79-content-headers-vs-put . . . . . . . . . . . . . . . 219
I.44. i71-examples-for-etag-matching . . . . . . . . . . . . . 226 I.44. i33-trace-security-considerations . . . . . . . . . . . 219
I.45. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 227 I.45. i69-clarify-requested-variant . . . . . . . . . . . . . 220
I.46. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 227 I.46. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 220
I.47. i37-vary-and-non-existant-headers . . . . . . . . . . . 227 I.47. i78-relationship-between-401-authorization-and-www-authe 221
I.48. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 228 I.48. i24-requiring-allow-in-405-responses . . . . . . . . . . 221
I.49. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 228 I.49. i81-content-negotiation-for-media-types . . . . . . . . 222
I.50. i23-no-store-invalidation . . . . . . . . . . . . . . . 228 I.50. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 223
I.51. i80-content-location-is-not-special . . . . . . . . . . 229 I.51. i29-age-calculation . . . . . . . . . . . . . . . . . . 223
I.52. i22-etag-and-other-metadata-in-status-messages . . . . . 230 I.52. i71-examples-for-etag-matching . . . . . . . . . . . . . 225
I.53. i61-redirection-vs-location . . . . . . . . . . . . . . 230 I.53. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 225
I.54. fragment-combination . . . . . . . . . . . . . . . . . . 230 I.54. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 225
I.55. i41-security-considerations . . . . . . . . . . . . . . 231 I.55. i37-vary-and-non-existant-headers . . . . . . . . . . . 226
I.56. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 231 I.56. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 226
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 I.57. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 227
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 244 I.58. i23-no-store-invalidation . . . . . . . . . . . . . . . 227
Intellectual Property and Copyright Statements . . . . . . . . . 247 I.59. 14.11-content-encoding_response_vs_message . . . . . . . 228
I.60. i80-content-location-is-not-special . . . . . . . . . . 229
I.61. i22-etag-and-other-metadata-in-status-messages . . . . . 229
I.62. i92-empty-host-headers . . . . . . . . . . . . . . . . . 229
I.63. i89-if-dash-and-entities . . . . . . . . . . . . . . . . 230
I.64. i61-redirection-vs-location . . . . . . . . . . . . . . 231
I.65. fragment-combination . . . . . . . . . . . . . . . . . . 231
I.66. i41-security-considerations . . . . . . . . . . . . . . 231
I.67. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 232
I.68. link-header . . . . . . . . . . . . . . . . . . . . . . 232
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245
Intellectual Property and Copyright Statements . . . . . . . . . 248
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 22, line 19 skipping to change at page 22, line 19
The following rules are used throughout this specification to The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986 [USASCII]. is defined by ANSI X3.4-1986 [USASCII].
OCTET = <any 8-bit sequence of data> OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)> CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z"> LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9"> DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character CTL = %x00-1F | %x7F
(octets 0 - 31) and DEL (127)> ; (octets 0 - 31) and DEL (127)
CR = <US-ASCII CR, carriage return (13)> CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)> LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)> SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)> HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)> DQUOTE = <US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see Appendix C for tolerant protocol elements except the entity-body (see Appendix C for tolerant
applications). The end-of-line marker within an entity-body is applications). The end-of-line marker within an entity-body is
defined by its associated media type, as described in Section 3.7. defined by its associated media type, as described in Section 3.7.
CRLF = CR LF CRLF = CR LF
HTTP/1.1 header field values can be folded onto multiple lines if the HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
skipping to change at page 22, line 48 skipping to change at page 22, line 48
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT ) LWS = [CRLF] 1*( SP | HT )
The TEXT rule is only used for descriptive field contents and values The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO- of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [ISO-8859-1] only when encoded according to the rules of 8859-1 [ISO-8859-1] only when encoded according to the rules of
[RFC2047]. [RFC2047].
TEXT = <any OCTET except CTLs, TEXT = %x20-7E | %x80-FF | LWS
but including LWS> ; any OCTET except CTLs, but including LWS
A CRLF is allowed in the definition of TEXT only as part of a header A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value. replaced with a single SP before interpretation of the TEXT value.
Hexadecimal numeric characters are used in several protocol elements. Hexadecimal numeric characters are used in several protocol elements.
HEX = "A" | "B" | "C" | "D" | "E" | "F" HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted or special characters. These special characters MUST be in a quoted
string to be used within a parameter value (as defined in string to be used within a parameter value (as defined in
Section 3.6). Section 3.6).
token = 1*<any CHAR except CTLs or separators> separators = "(" | ")" | "<" | ">" | "@"
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | DQUOTE
| "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "="
| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
| "{" | "}" | SP | HT
tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*" | "+" | "-"
| "." | "^" | "_" | "`" | "|" | "~" | DIGIT | ALPHA
; any CHAR except CTLs or separators
token = 1*tchar
Comments can be included in some HTTP header fields by surrounding Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition. fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field In all other fields, parentheses are considered part of the field
value. value.
comment = "(" *( ctext | quoted-pair | comment ) ")" comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")"> ctext = %x20-27 | %x2A-7E | %x80-FF | LWS
; any TEXT excluding "(" and ")"
A string of text is parsed as a single word if it is quoted using A string of text is parsed as a single word if it is quoted using
double-quote marks. double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )
qdtext = <any TEXT excluding <"> and "\"> qdtext = %x20-21 | %x23-5B | %x5D-7E | %x80-FF | LWS
; any TEXT excluding DQUOTE and "\"
The backslash character ("\") MAY be used as a single-character The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs. quoting mechanism only within quoted-string and comment constructs.
quoted-pair = "\" CHAR quoted-pair = "\" CHAR
3. Protocol Parameters 3. Protocol Parameters
3.1. HTTP Version 3.1. HTTP Version
skipping to change at page 24, line 24 skipping to change at page 24, line 24
number for the addition of message components which do not affect number for the addition of message components which do not affect
communication behavior or which only add to extensible field values. communication behavior or which only add to extensible field values.
The <minor> number is incremented when the changes made to the The <minor> number is incremented when the changes made to the
protocol add features which do not change the general message parsing protocol add features which do not change the general message parsing
algorithm, but which may add to the message semantics and imply algorithm, but which may add to the message semantics and imply
additional capabilities of the sender. The <major> number is additional capabilities of the sender. The <major> number is
incremented when the format of a message within the protocol is incremented when the format of a message within the protocol is
changed. See [RFC2145] for a fuller explanation. changed. See [RFC2145] for a fuller explanation.
The version of an HTTP message is indicated by an HTTP-Version field The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message. in the first line of the message. HTTP-Version is case-sensitive.
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers MUST be treated as separate Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented higher than a single digit. integers and that each MAY be incremented higher than a single digit.
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
and MUST NOT be sent. and MUST NOT be sent.
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 [RFC2145]. when to send specific HTTP-Version values, see [RFC2145].
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. HTTP- which the application is at least conditionally compliant.
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 25, line 34 skipping to change at page 25, line 33
3.2.1. General Syntax 3.2.1. General Syntax
URIs in HTTP can be represented in absolute form or relative to some URIs in HTTP can be represented in absolute form or relative to some
known base URI [RFC1808], depending upon the context of their use. known base URI [RFC1808], depending upon the context of their use.
The two forms are differentiated by the fact that absolute URIs The two forms are differentiated by the fact that absolute URIs
always begin with a scheme name followed by a colon. For definitive always begin with a scheme name followed by a colon. For definitive
information on URL syntax and semantics, see "Uniform Resource information on URL syntax and semantics, see "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which
replaces [RFC1738] and [RFC1808]). This specification adopts the replaces [RFC1738] and [RFC1808]). This specification adopts the
definitions of "URI-reference", "absoluteURI", "relativeURI", "port", definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
"host", "abs_path", "rel_path", "query", and "authority" from that "host", "abs_path", "query", and "authority" from that specification.
specification.
absoluteURI = <absoluteURI, defined in [RFC2396], Section 3>
authority = <authority, defined in [RFC2396], Section 3.2>
path-absolute = <abs_path, defined in [RFC2396], Section 3>
port = <port, defined in [RFC2396], Section 3.2.2>
query = <query, defined in [RFC2396], Section 3.4>
relativeURI = <relativeURI, defined in [RFC2396], Section 5>
uri-host = <host, defined in [RFC2396], Section 3.2.2>
The HTTP protocol does not place any a priori limit on the length of The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see Section 10.4.15). than the server can handle (see Section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy above 255 bytes, because some older client or proxy
implementations might not properly support these lengths. implementations might not properly support these lengths.
3.2.2. http URL 3.2.2. http URL
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:" "//" uri-host [ ":" port ] [ path-absolute [ "?" 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 path-absolute (Section 5.1.2). The use of IP
addresses in URLs SHOULD be avoided whenever possible (see addresses in URLs SHOULD be avoided whenever possible (see
[RFC1900]). If the abs_path is not present in the URL, it MUST be [RFC1900]). If the path-absolute is not present in the URL, it MUST
given as "/" when used as a Request-URI for a resource be given as "/" when used as a Request-URI for a resource
(Section 5.1.2). If a proxy receives a host name which is not a (Section 5.1.2). If a proxy receives a host name which is not a
fully qualified domain name, it MAY add its domain to the host name fully qualified domain name, it MAY add its domain to the host name
it received. If a proxy receives a fully qualified domain name, the it received. If a proxy receives a fully qualified domain name, the
proxy MUST NOT change the host name. proxy MUST NOT change the 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 path-absolute is equivalent to an path-absolute of "/".
Characters other than those in the "reserved" set (see [RFC2396]) are Characters other than those in the "reserved" set (see [RFC2396]) are
equivalent to their ""%" HEX HEX" encoding. equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
skipping to change at page 28, line 5 skipping to change at page 28, line 5
All HTTP date/time stamps MUST be represented in Greenwich Mean Time All HTTP date/time stamps MUST be represented in Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly (GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC (Coordinated Universal Time). This is indicated in the equal to UTC (Coordinated Universal Time). This is indicated in the
first two formats by the inclusion of "GMT" as the three-letter first two formats by the inclusion of "GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include asctime format. HTTP-date is case sensitive and MUST NOT include
additional LWS beyond that specifically included as SP in the additional LWS beyond that specifically included as SP in the
grammar. grammar.
HTTP-date = rfc1123-date | rfc850-date | asctime-date HTTP-date = rfc1123-date ; for use in message producers
| obsolete-date ; only allowed in message parsing
obsolete-date = rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) ; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82) ; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2) ; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
skipping to change at page 32, line 29 skipping to change at page 32, line 29
The chunked encoding modifies the body of a message in order to The chunked encoding modifies the body of a message in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. followed by an OPTIONAL trailer containing entity-header fields.
This allows dynamically produced content to be transferred along with This allows dynamically produced content to be transferred along with
the information necessary for the recipient to verify that it has the information necessary for the recipient to verify that it has
received the full message. received the full message.
Chunked-Body = *chunk Chunked-Body = *chunk
last-chunk last-chunk
trailer trailer-part
CRLF CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF chunk-data CRLF
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)
trailer = *(entity-header CRLF) chunk-data = 1*OCTET ; a sequence of chunk-size octets
trailer-part = *(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-data in octets. The chunked encoding is ended by any chunk the chunk-data in octets. The chunked encoding is ended by any chunk
whose size is zero, followed by the trailer, which is terminated by whose size is zero, followed by the trailer, which is terminated by
an empty line. 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).
skipping to change at page 33, line 36 skipping to change at page 33, line 37
An example process for decoding a Chunked-Body is presented in An example process for decoding a Chunked-Body is presented in
Appendix D.6. Appendix D.6.
All HTTP/1.1 applications MUST be able to receive and decode the All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions "chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand. they do not understand.
3.7. Media Types 3.7. Media Types
HTTP uses Internet Media Types [RFC2048] in the Content-Type HTTP uses Internet Media Types [RFC2046] in the Content-Type
(Section 14.17) and Accept (Section 14.1) header fields in order to (Section 14.17) and Accept (Section 14.1) header fields in order to
provide open and extensible data typing and type negotiation. provide open and extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter ) media-type = type "/" subtype *( ";" parameter )
type = token type = token
subtype = token subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value Parameters MAY follow the type/subtype in the form of attribute/value
pairs (as defined in Section 3.6). pairs (as defined in Section 3.6).
skipping to change at page 34, line 13 skipping to change at page 34, line 15
might be significant to the processing of a media-type, depending on might be significant to the processing of a media-type, depending on
its definition within the media type registry. its definition within the media type registry.
Note that some older HTTP applications do not recognize media type Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications, parameters. When sending data to older HTTP applications,
implementations SHOULD only use media type parameters when they are implementations SHOULD only use media type parameters when they are
required by that type/subtype definition. required by that type/subtype definition.
Media-type values are registered with the Internet Assigned Number Media-type values are registered with the Internet Assigned Number
Authority (IANA). The media type registration process is outlined in Authority (IANA). The media type registration process is outlined in
[RFC2048]. Use of non-registered media types is discouraged. [RFC4288]. Use of non-registered media types is discouraged.
3.7.1. Canonicalization and Text Defaults 3.7.1. Canonicalization and Text Defaults
Internet media types are registered with a canonical form. An Internet media types are registered with a canonical form. An
entity-body transferred via HTTP messages MUST be represented in the entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission except for appropriate canonical form prior to its transmission except for
"text" types, as defined in the next paragraph. "text" types, as defined in the next paragraph.
When in canonical form, media subtypes of the "text" type use CRLF as When in canonical form, media subtypes of the "text" type use CRLF as
the text line break. HTTP relaxes this requirement and allows the the text line break. HTTP relaxes this requirement and allows the
skipping to change at page 36, line 38 skipping to change at page 36, line 41
relative degradation in desired quality. relative degradation in desired quality.
3.10. Language Tags 3.10. Language Tags
A language tag identifies a natural language spoken, written, or A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded. to other human beings. Computer languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
Language fields. Language fields.
The syntax and registry of HTTP language tags is the same as that The syntax and registry of HTTP language tags is defined by
defined by [RFC1766]. In summary, a language tag is composed of 1 or [RFC4646]:
more parts: A primary language tag and a possibly empty series of
subtags:
language-tag = primary-tag *( "-" subtag ) Language-Tag = <defined in [RFC4646], Section 2.1>
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
White space is not allowed within the tag and all tags are case- White space is not allowed within the tag and all tags are case-
insensitive. The name space of language tags is administered by the insensitive. The name space of language tags is administered by the
IANA. Example tags include: IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin en, en-US, en-cockney, i-cherokee, x-pig-latin
where any two-letter primary-tag is an ISO-639 language abbreviation where any two-letter primary-tag is an ISO-639 language abbreviation
and any two-letter initial subtag is an ISO-3166 country code. (The and any two-letter initial subtag is an ISO-3166 country code. (The
last three tags above are not registered tags; all but the last are last three tags above are not registered tags; all but the last are
skipping to change at page 40, line 8 skipping to change at page 40, line 8
of LWS, though a single SP is preferred. Header fields can be of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications ought to follow "common form", least one SP or HT. Applications ought to follow "common form",
where one is known or indicated, when generating HTTP constructs, where one is known or indicated, when generating HTTP constructs,
since there might exist some implementations that fail to accept since there might exist some implementations that fail to accept
anything beyond the common forms. anything beyond the common forms.
message-header = field-name ":" [ field-value ] message-header = field-name ":" [ field-value ]
field-name = token field-name = token
field-value = *( field-content | LWS ) field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value field-content = <field content>
and consisting of either *TEXT or combinations ; the OCTETs making up the field-value
of token, separators, and quoted-string> ; and consisting of either *TEXT or combinations
; of token, separators, and quoted-string
The field-content does not include any leading or trailing LWS: The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message before interpreting the field value or forwarding the message
downstream. downstream.
skipping to change at page 45, line 14 skipping to change at page 45, line 14
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 = "*" Request-URI = "*"
| absoluteURI | absoluteURI
| abs_path [ "?" query ] | path-absolute [ "?" query ]
| authority | 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
skipping to change at page 45, line 45 skipping to change at page 45, line 45
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, path-
the Request-URI, and the network location of the URI (authority) MUST absolute) as the Request-URI, and the network location of the URI
be transmitted in a Host header field. For example, a client wishing (authority) MUST be transmitted in a Host header field. For example,
to retrieve the resource above directly from the origin server would a client wishing to retrieve the resource above directly from the
create a TCP connection to port 80 of the host "www.example.org" and origin server would create a TCP connection to port 80 of the host
send the lines: "www.example.org" and send the lines:
GET /pub/WWW/TheProject.html HTTP/1.1 GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.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 The Request-URI is transmitted in the format specified in
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX"
encoding [RFC2396], the origin server MUST decode the Request-URI in encoding [RFC2396], the origin server MUST decode the Request-URI in
order to properly interpret the request. Servers SHOULD respond to order to properly interpret the request. Servers SHOULD respond to
invalid Request-URIs with an appropriate status code. invalid 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 "path-absolute" 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 path-absolute with "/".
Note: The "no rewrite" rule prevents the proxy from changing the Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using meaning of the request when the origin server is improperly using
a non-reserved URI character for a reserved purpose. Implementors a non-reserved URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI. rewrite the Request-URI.
5.2. The Resource Identified by a Request 5.2. The Resource Identified by a Request
The exact resource identified by an Internet request is determined by The exact resource identified by an Internet request is determined by
skipping to change at page 50, line 49 skipping to change at page 50, line 49
| "417" ; Section 10.4.18: Expectation Failed | "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error | "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented | "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway | "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable | "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out | "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported | "505" ; Section 10.5.6: HTTP Version not supported
| extension-code | extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *( HT | %x20-7E | %x80-FF )
HTTP status codes are extensible. HTTP applications are not required HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
skipping to change at page 72, line 39 skipping to change at page 72, line 39
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
The response to the request can be found under a different URI and The server directs the user agent to a different resource, indicated
SHOULD be retrieved using a GET method on that resource. This method by a URI in the Location header field, that provides an indirect
exists primarily to allow the output of a POST-activated script to response to the original request. The user agent MAY perform a GET
redirect the user agent to a selected resource. The new URI is not a request on the URI in the Location field in order to obtain a
substitute reference for the originally requested resource. The 303 representation corresponding to the response, be redirected again, or
response MUST NOT be cached, but the response to the second end with an error status. The Location URI is not a substitute
(redirected) request might be cacheable. reference for the originally requested resource.
The different URI SHOULD be given by the Location field in the The 303 status is generally applicable to any HTTP method. It is
response. Unless the request method was HEAD, the entity of the primarily used to allow the output of a POST action to redirect the
response SHOULD contain a short hypertext note with a hyperlink to user agent to a selected resource, since doing so provides the
the new URI(s). information corresponding to the POST response in a form that can be
separately identified, bookmarked, and cached independent of the
original request.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 A 303 response to a GET request indicates that the requested resource
status. When interoperability with such clients is a concern, the does not have a representation of its own that can be transferred by
302 status code may be used instead, since most user agents react the server over HTTP. The Location URI indicates a resource that is
to a 302 response as described here for 303. descriptive of the requested resource such that the follow-on
representation may be useful without implying that it adequately
represents the previously requested resource. Note that answers to
the questions of what can be represented, what representations are
adequate, and what might be a useful description are outside the
scope of HTTP and thus entirely determined by the resource owner(s).
A 303 response SHOULD NOT be cached unless it is indicated as
cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI.
10.3.5. 304 Not Modified 10.3.5. 304 Not Modified
If the client has performed a conditional GET request and access is If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line message-body, and thus is always terminated by the first empty line
after the header fields. after the header fields.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 85, line 7 skipping to change at page 85, line 7
server and also removing the second request delay of agent-driven server and also removing the second request delay of agent-driven
negotiation when the cache is able to correctly guess the right negotiation when the cache is able to correctly guess the right
response. response.
This specification does not define any mechanism for transparent This specification does not define any mechanism for transparent
negotiation, though it also does not prevent any such mechanism from negotiation, though it also does not prevent any such mechanism from
being developed as an extension that could be used within HTTP/1.1. being developed as an extension that could be used within HTTP/1.1.
13. Caching in HTTP 13. Caching in HTTP
13.1. Overview
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. The performance can be improved by the use of response caches. The
HTTP/1.1 protocol includes a number of elements intended to make HTTP/1.1 protocol includes a number of elements intended to make
caching work as well as possible. Because these elements are caching work as well as possible. Because these elements are
inextricable from other aspects of the protocol, and because they inextricable from other aspects of the protocol, and because they
interact with each other, it is useful to describe the basic caching interact with each other, it is useful to describe the basic caching
design of HTTP separately from the detailed descriptions of methods, design of HTTP separately from the detailed descriptions of methods,
headers, response codes, etc. headers, response codes, etc.
Caching would be useless if it did not significantly improve Caching would be useless if it did not significantly improve
skipping to change at page 86, line 13 skipping to change at page 86, line 15
A basic principle is that it must be possible for the clients to A basic principle is that it must be possible for the clients to
detect any potential relaxation of semantic transparency. detect any potential relaxation of semantic transparency.
Note: The server, cache, or client implementor might be faced with Note: The server, cache, or client implementor might be faced with
design decisions not explicitly discussed in this specification. design decisions not explicitly discussed in this specification.
If a decision might affect semantic transparency, the implementor If a decision might affect semantic transparency, the implementor
ought to err on the side of maintaining transparency unless a ought to err on the side of maintaining transparency unless a
careful and complete analysis shows significant benefits in careful and complete analysis shows significant benefits in
breaking transparency. breaking transparency.
13.1.
13.1.1. Cache Correctness 13.1.1. Cache Correctness
A correct cache MUST respond to a request with the most up-to-date A correct cache MUST respond to a request with the most up-to-date
response held by the cache that is appropriate to the request (see response held by the cache that is appropriate to the request (see
Sections 13.2.5, 13.2.6, and 13.12) which meets one of the following Sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
conditions: conditions:
1. It has been checked for equivalence with what the origin server 1. It has been checked for equivalence with what the origin server
would have returned by revalidating the response with the origin would have returned by revalidating the response with the origin
server (Section 13.3); server (Section 13.3);
skipping to change at page 98, line 23 skipping to change at page 98, line 23
or not: or not:
o The strong comparison function: in order to be considered equal, o The strong comparison function: in order to be considered equal,
both validators MUST be identical in every way, and both MUST NOT both validators MUST be identical in every way, and both MUST NOT
be weak. be weak.
o The weak comparison function: in order to be considered equal, o The weak comparison function: in order to be considered equal,
both validators MUST be identical in every way, but either or both both validators MUST be identical in every way, but either or both
of them MAY be tagged as "weak" without affecting the result. of them MAY be tagged as "weak" without affecting the result.
The example below shows the results for a set of entity tag pairs,
and both the weak and strong comparison function results:
+--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match |
| | | | |
| W/"1" | W/"2" | no match | no match |
| | | | |
| W/"1" | "1" | no match | match |
| | | | |
| "1" | "1" | match | match |
+--------+--------+-------------------+-----------------+
An entity tag is strong unless it is explicitly tagged as weak. An entity tag is strong unless it is explicitly tagged as weak.
Section 3.11 gives the syntax for entity tags. Section 3.11 gives the syntax for entity tags.
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the entity and, current validator for the entity and,
skipping to change at page 108, line 20 skipping to change at page 108, line 36
Unless the origin server explicitly prohibits the caching of their Unless the origin server explicitly prohibits the caching of their
responses, the application of GET and HEAD methods to any resources responses, the application of GET and HEAD methods to any resources
SHOULD NOT have side effects that would lead to erroneous behavior if SHOULD NOT have side effects that would lead to erroneous behavior if
these responses are taken from a cache. They MAY still have side these responses are taken from a cache. They MAY still have side
effects, but a cache is not required to consider such side effects in effects, but a cache is not required to consider such side effects in
its caching decisions. Caches are always expected to observe an its caching decisions. Caches are always expected to observe an
origin server's explicit restrictions on caching. origin server's explicit restrictions on caching.
We note one exception to this rule: since some applications have We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a traditionally used GETs and HEADs with URLs containing a query part
"?" in the rel_path part) to perform operations with significant side to perform operations with significant side effects, caches MUST NOT
effects, caches MUST NOT treat responses to such URIs as fresh unless treat responses to such URIs as fresh unless the server provides an
the server provides an explicit expiration time. This specifically explicit expiration time. This specifically means that responses
means that responses from HTTP/1.0 servers for such URIs SHOULD NOT from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache.
be taken from a cache. See Section 9.1.1 for related information. See Section 9.1.1 for related information.
13.10. Invalidation After Updates or Deletions 13.10. Invalidation After Updates or Deletions
The effect of certain methods performed on a resource at the origin The effect of certain methods performed on a resource at the origin
server might cause one or more existing cache entries to become non- server might cause one or more existing cache entries to become non-
transparently invalid. That is, although they might continue to be transparently invalid. That is, although they might continue to be
"fresh," they do not accurately reflect what the origin server would "fresh," they do not accurately reflect what the origin server would
return for a new request on that resource. return for a new request on that resource.
There is no way for the HTTP protocol to guarantee that all such There is no way for the HTTP protocol to guarantee that all such
skipping to change at page 115, line 28 skipping to change at page 115, line 28
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Each language-range MAY be given an associated quality value which Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For specified by that range. The quality value defaults to "q=1". For
example, example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if other types of English." A language-range matches a Language-Tag if
it exactly equals the tag, or if it exactly equals a prefix of the it exactly equals the tag, or if it exactly equals a prefix of the
tag such that the first tag character following the prefix is "-". tag such that the first tag character following the prefix is "-".
The special range "*", if present in the Accept-Language field, The special range "*", if present in the Accept-Language field,
matches every tag not matched by any other range present in the matches every tag not matched by any other range present in the
Accept-Language field. Accept-Language field.
Note: This use of a prefix matching rule does not imply that Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case. use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the Accept- The language quality factor assigned to a Language-Tag by the Accept-
Language field is the quality value of the longest language-range in Language field is the quality value of the longest language-range in
the field that matches the language-tag. If no language-range in the the field that matches the Language-Tag. If no language-range in the
field matches the tag, the language quality factor assigned is 0. If field matches the tag, the language quality factor assigned is 0. If
no Accept-Language header is present in the request, the server no Accept-Language header is present in the request, the server
SHOULD assume that all languages are equally acceptable. If an SHOULD assume that all languages are equally acceptable. If an
Accept-Language header is present, then all languages which are Accept-Language header is present, then all languages which are
assigned a quality factor greater than 0 are acceptable. assigned a quality factor greater than 0 are acceptable.
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header with the complete linguistic preferences of an Accept-Language header with the complete linguistic preferences of
the user in every request. For a discussion of this issue, see the user in every request. For a discussion of this issue, see
Section 15.1.4. Section 15.1.4.
skipping to change at page 119, line 32 skipping to change at page 119, line 32
| "no-store" ; Section 14.9.2 | "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3 | "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5 | "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4 | "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6 | cache-extension ; Section 14.9.6
cache-response-directive = cache-response-directive =
"public" ; Section 14.9.1 "public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | "private" [ "=" DQUOTE 1#field-name DQUOTE ]
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 ; Section 14.9.1
| "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
; Section 14.9.1
| "no-store" ; Section 14.9.2 | "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5 | "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4 | "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4 | "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3 | "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3 | "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6 | cache-extension ; Section 14.9.6
cache-extension = token [ "=" ( token | quoted-string ) ] cache-extension = token [ "=" ( token | quoted-string ) ]
skipping to change at page 130, line 6 skipping to change at page 130, line 12
Additional information about the encoding parameters MAY be provided Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification. by other entity-header fields not defined by this specification.
14.12. Content-Language 14.12. Content-Language
The Content-Language entity-header field describes the natural The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity. Note language(s) of the intended audience for the enclosed entity. Note
that this might not be equivalent to all the languages used within that this might not be equivalent to all the languages used within
the entity-body. the entity-body.
Content-Language = "Content-Language" ":" 1#language-tag Content-Language = "Content-Language" ":" 1#Language-Tag
Language tags are defined in Section 3.10. The primary purpose of Language tags are defined in Section 3.10. The primary purpose of
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if entities according to the user's own preferred language. Thus, if
the body content is intended only for a Danish-literate audience, the the body content is intended only for a Danish-literate audience, the
appropriate field is appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
skipping to change at page 140, line 7 skipping to change at page 140, line 16
The Host request-header field specifies the Internet host and port The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original number of the resource being requested, as obtained from the original
URI given by the user or referring resource (generally an HTTP URL, URI given by the user or referring resource (generally an HTTP URL,
as described in Section 3.2.2). The Host field value MUST represent as described in Section 3.2.2). The Host field value MUST represent
the naming authority of the origin server or gateway given by the 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" ":" uri-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.example.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.example.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
skipping to change at page 157, line 37 skipping to change at page 158, line 4
client), play a role in the selection of the response representation. client), play a role in the selection of the response representation.
The "*" value MUST NOT be generated by a proxy server; it may only be The "*" value MUST NOT be generated by a proxy server; it may only be
generated by an origin server. generated by an origin server.
14.45. Via 14.45. Via
The Via general-header field MUST be used by gateways and proxies to The Via general-header field MUST be used by gateways and proxies to
indicate the intermediate protocols and recipients between the user indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of the client on responses. It is analogous to the "Received" field of
[RFC2822] and is intended to be used for tracking message forwards, [RFC2822] and is intended to be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of avoiding request loops, and identifying the protocol capabilities of
all senders along the request/response chain. all senders along the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token protocol-name = token
protocol-version = token protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym received-by = ( uri-host [ ":" port ] ) | pseudonym
pseudonym = token pseudonym = token
The received-protocol indicates the protocol version of the message The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the request/ received by the server or client along each segment of the request/
response chain. The received-protocol version is appended to the Via response chain. The received-protocol version is appended to the Via
field value when the message is forwarded so that information about field value when the message is forwarded so that information about
the protocol capabilities of upstream applications remains visible to the protocol capabilities of upstream applications remains visible to
all recipients. all recipients.
The protocol-name is optional if and only if it would be "HTTP". The The protocol-name is optional if and only if it would be "HTTP". The
skipping to change at page 159, line 25 skipping to change at page 159, line 41
the message. the message.
Warning headers are sent with responses using: Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date] [SP warn-date]
warn-code = 3DIGIT warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym warn-agent = ( uri-host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding ; the name or pseudonym of the server adding
; the Warning header, for use in debugging ; the Warning header, for use in debugging
warn-text = quoted-string warn-text = quoted-string
warn-date = <"> HTTP-date <"> warn-date = DQUOTE HTTP-date DQUOTE
A response MAY carry more than one Warning header. A response MAY carry more than one Warning header.
The warn-text SHOULD be in a natural language and character set that The warn-text SHOULD be in a natural language and character set that
is most likely to be intelligible to the human user receiving the is most likely to be intelligible to the human user receiving the
response. This decision MAY be based on any available knowledge, response. This decision MAY be based on any available knowledge,
such as the location of the cache or user, the Accept-Language field such as the location of the cache or user, the Accept-Language field
in a request, the Content-Language field in a response, etc. The in a request, the Content-Language field in a response, etc. The
default language is English and the default character set is ISO- default language is English and the default character set is ISO-
8859-1. 8859-1.
skipping to change at page 170, line 7 skipping to change at page 171, line 7
participating in the HTTP-WG. In particular, we thank Scott Lawrence participating in the HTTP-WG. In particular, we thank Scott Lawrence
for maintaining the RFC2616 Errata list, and Mark Baker, David Booth, for maintaining the RFC2616 Errata list, and Mark Baker, David Booth,
Adrien de Croy, Martin Duerst, Roy Fielding, Hugo Haas, Bjoern Adrien de Croy, Martin Duerst, Roy Fielding, Hugo Haas, Bjoern
Hoehrmann, Brian Kell, Jamie Lokier, Paul Marquess, Larry Masinter, Hoehrmann, Brian Kell, Jamie Lokier, Paul Marquess, Larry Masinter,
Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Joe Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Joe
Orton, Alex Rousskov, Travis Snoozy and Dan Winship for further Orton, Alex Rousskov, Travis Snoozy and Dan Winship for further
contributions. contributions.
17. References 17. References
17.1. References (to be classified) 17.1. Normative References
[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
17.2. Normative References
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[RFC1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995. RFC 1864, October 1995.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996. Specification version 3.3", RFC 1950, May 1996.
RFC1950 is an Informational RFC, thus it may be less RFC1950 is an Informational RFC, thus it may be less
stable than this specification. On the other hand, this stable than this specification. On the other hand, this
downward reference was present since [RFC2068] (published downward reference was present since [RFC2068] (published
in 1997), therefore it is unlikely to cause problems in in 1997), therefore it is unlikely to cause problems in
skipping to change at page 171, line 36 skipping to change at page 172, line 24
August 1998. August 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 4646, September 2006.
[RFC822ABNF] [RFC822ABNF]
Crocker, D., "Standard for the format of ARPA Internet Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
17.3. Informative References 17.2. Informative References
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
proxy servers", draft-luotonen-web-proxy-tunneling-01 proxy servers", draft-luotonen-web-proxy-tunneling-01
(work in progress), August 1998. (work in progress), August 1998.
[Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and
C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1,
and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , and PNG", Proceedings of ACM SIGCOMM '97, Cannes France ,
Sep 1997. Sep 1997.
skipping to change at page 172, line 32 skipping to change at page 173, line 26
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol Torrey, D., and B. Alberti, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)", (a distributed document search and retrieval protocol)",
RFC 1436, March 1993. RFC 1436, March 1993.
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses Unifying Syntax for the Expression of Names and Addresses
of Objects on the Network as used in the World-Wide Web", of Objects on the Network as used in the World-Wide Web",
RFC 1630, June 1994. RFC 1630, June 1994.
[RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994. Resource Locators (URL)", RFC 1738, December 1994.
[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995. Header", RFC 1806, June 1995.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators", [RFC1808] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995. RFC 1808, June 1995.
skipping to change at page 176, line 14 skipping to change at page 177, line 14
Appendix A. Internet Media Type message/http and application/http Appendix A. Internet Media Type message/http and application/http
In addition to defining the HTTP/1.1 protocol, this document serves In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type "message/http" and as the specification for the Internet media type "message/http" and
"application/http". The message/http type can be used to enclose a "application/http". The message/http type can be used to enclose a
single HTTP request or response message, provided that it obeys the single HTTP request or response message, provided that it obeys the
MIME restrictions for all "message" types regarding line length and MIME restrictions for all "message" types regarding line length and
encodings. The application/http type can be used to enclose a encodings. The application/http type can be used to enclose a
pipeline of one or more HTTP request or response messages (not pipeline of one or more HTTP request or response messages (not
intermixed). The following is to be registered with IANA [RFC2048]. intermixed). The following is to be registered with IANA [RFC4288].
Media Type name: message Type name: message
Media subtype name: http Subtype name: http
Required parameters: none Required parameters: none
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed message (e.g., version: The HTTP-Version number of the enclosed message (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: none Security considerations: none
Media Type name: application Interoperability considerations: none
Media subtype name: http Published specification: This specification (see Appendix A).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
Type name: application
Subtype name: http
Required parameters: none Required parameters: none
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed messages (e.g., version: The HTTP-Version number of the enclosed messages (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via E-mail.
Security considerations: none Security considerations: none
Interoperability considerations: none
Published specification: This specification (see Appendix A).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
Appendix B. Internet Media Type multipart/byteranges Appendix B. Internet Media Type multipart/byteranges
When an HTTP 206 (Partial Content) response message includes the When an HTTP 206 (Partial Content) response message includes the
content of multiple ranges (a response to a request for multiple non- content of multiple ranges (a response to a request for multiple non-
overlapping ranges), these are transmitted as a multipart message- overlapping ranges), these are transmitted as a multipart message-
body. The media type for this purpose is called "multipart/ body. The media type for this purpose is called "multipart/
byteranges". byteranges".
The multipart/byteranges media type includes two or more parts, each The multipart/byteranges media type includes two or more parts, each
with its own Content-Type and Content-Range fields. The required with its own Content-Type and Content-Range fields. The required
boundary parameter specifies the boundary string used to separate boundary parameter specifies the boundary string used to separate
each body-part. each body-part.
Media Type name: multipart Type name: multipart
Media subtype name: byteranges Subtype name: byteranges
Required parameters: boundary Required parameters: boundary
Optional parameters: none Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are Encoding considerations: only "7bit", "8bit", or "binary" are
permitted permitted
Security considerations: none Security considerations: none
Interoperability considerations: none
Published specification: This specification (see Appendix B).
Applications that use this media type:
Additional information:
Magic number(s): none
File extension(s): none
Macintosh file type code(s): none
Person and email address to contact for further information: See
Authors Section.
Intended usage: COMMON
Restrictions on usage: none
Author/Change controller: IESG
For example: For example:
HTTP/1.1 206 Partial Content HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES --THIS_STRING_SEPARATES
Content-type: application/pdf Content-type: application/pdf
Content-range: bytes 500-999/8000 Content-range: bytes 500-999/8000
skipping to change at page 190, line 14 skipping to change at page 192, line 14
Clarify definition of POST. (Section 9.5) Clarify definition of POST. (Section 9.5)
Clarify that it's not ok to use a weak cache validator in a 206 Clarify that it's not ok to use a weak cache validator in a 206
response. (Section 10.2.7) response. (Section 10.2.7)
Failed to consider that there are many other request methods that are Failed to consider that there are many other request methods that are
safe to automatically redirect, and further that the user agent is safe to automatically redirect, and further that the user agent is
able to make that determination based on the request method able to make that determination based on the request method
semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 ) semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 )
Clarify that 303 responses can be cacheable. (Section 10.3.4)
Fix misspelled header and clarify requirements for hop-by-hop headers Fix misspelled header and clarify requirements for hop-by-hop headers
introduced in future specifications. (Section 13.5.1) introduced in future specifications. (Section 13.5.1)
Clarify denial of service attack avoidance requirement. Clarify denial of service attack avoidance requirement.
(Section 13.10) (Section 13.10)
Fix bug in BNF disallowing empty Accept-Encoding headers. Fix bug in BNF disallowing empty Accept-Encoding headers.
(Section 14.3) (Section 14.3)
Clarify exactly when close connection options must be sent. Clarify exactly when close connection options must be sent.
skipping to change at page 194, line 5 skipping to change at page 195, line 11
reg" (which wasn't resolved by drafts -02 and -03, after all), reg" (which wasn't resolved by drafts -02 and -03, after all),
"remove-CTE-abbrev", "rfc1766_normative", "rfc2396_normative" and "remove-CTE-abbrev", "rfc1766_normative", "rfc2396_normative" and
"usascii_normative". "usascii_normative".
Add new section "Normative References" (the old "References (to be Add new section "Normative References" (the old "References (to be
classified)" section will be removed once all references are re- classified)" section will be removed once all references are re-
classified). classified).
Update contact information for Jim Gettys. Update contact information for Jim Gettys.
Appendix H. Resolved issues (to be removed by RFC Editor before G.6. Since draft-lafon-rfc2616bis-04
publication)
Issues that were either rejected or resolved in this version of this
document.
H.1. unneeded_references
Type: edit
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0054>,
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i44>
julian.reschke@greenbytes.de (2006-10-19): The reference entries for
RFC1866, RFC2069 and RFC2026 are unused. Remove them?
julian.reschke@greenbytes.de (2006-11-02): See also
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0118>.
Resolution (2006-10-24): Remove references to RFC1866 and RFC2069 for
now. Keep RFC2026 for now; it's referenced from Editorial note.
H.2. consistent-reason-phrases
Type: edit
<http://www.w3.org/mid/472E16C5.8000703@gmx.de>
julian.reschke@greenbytes.de (2007-11-04): Use consistent status
reason phrases.
Resolution (2007-11-15): Done.
H.3. i66-iso8859-1-reference
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i66>
julian.reschke@greenbytes.de (2006-10-28): Classify ISO8859 as
normative, and simplify reference to only refer to ISO8859 Part 1
(because that's the only part needed here), and update to the 1998
version.
Resolution (2006-10-28): Done.
H.4. abnf-edit
Type: edit
<http://www.w3.org/mid/4739C417.2040203@gmx.de>
julian.reschke@greenbytes.de (2007-11-13): Fix minor editorial issues
with BNF causing problems with ABNF parsers, such as (1) inconsistent
indentation and (2) missing whitespace.
Resolution (2007-11-15): Done.
H.5. rfc1766_normative
Type: edit
julian.reschke@greenbytes.de (2006-11-15): Classify RFC1766 ("Tags
for the Identification of Languages") as normative (update to RFC4646
in a separate step, see issue languagetag).
Resolution (2006-11-15): Done.
H.6. i86-normative-up-to-date-references
Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i86> Add issues "14.11-content-encoding_response_vs_message", "abnf-avoid-
prose", "i88-205-bodies", "i89-if-dash-and-entities", "i90-
delimiting-messages-with-multipart-byteranges", "i91-duplicate-host-
header-requirements", "i92-empty-host-headers", "i93-repeating-
single-value-headers", "i94-reason-phrase-bnf", "link-header",
"need_iana_considerations".
julian.reschke@greenbytes.de (2006-11-12): Classify RFC1864 ("The Add and resolve issues "abnf-case-insensitive", "abnf-chunk-data",
Content-MD5 Header Field") as normative. Note that note this "abnf-dquote", "abnf-prose-cr" and "abnf-rule-names".
disagrees with draft-gettys-http-v11-spec-rev-00 which made it
informative.
julian.reschke@greenbytes.de (2006-11-14): Classify RFC2045 Resolve issues "i70-cacheability-of-303" and "i82-rel_path-not-used".
("Multipurpose Internet Mail Extensions (MIME) Part One: Format of
Internet Message Bodies") as normative.
julian.reschke@greenbytes.de (2006-11-12): Classify RFC2046 Add and partly resolve issues "rfc1737_informative_and_obsolete" and
("Multipurpose Internet Mail Extensions (MIME) Part Two: Media "rfc2048_informative_and_obsolete"
Types") as normative.
julian.reschke@greenbytes.de (2006-11-12): Classify RFC2047 ("MIME Update contact information for Jim Gettys.
(Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text") as normative.
julian.reschke@greenbytes.de (2006-10-27): Classify RFC2119 (Key Moved the introduction of Section 13 into previously empty, unnamed
words for use in RFCs to Indicate Requirement Levels) as normative. subsection 13.1.
julian.reschke@greenbytes.de (2006-10-27): Classify RFC2617 (HTTP Appendix H. Resolved issues (to be removed by RFC Editor before
Authentication) as normative. publication)
Resolution (2007-10-12): Done. Issues that were either rejected or resolved in this version of this
document.
H.7. i68-encoding-references-normative H.1. abnf-dquote
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i68> julian.reschke@greenbytes.de (2007-11-20): Use DQUOTE instead of <">
in BNF.
julian.reschke@greenbytes.de (2007-05-28): Classify RFC1950 (ZLIB),
RFC1951 (DEFLATE) and RFC1952 (GZIP) as normative (note this
disagrees with draft-gettys-http-v11-spec-rev-00 which made it
informative).
julian.reschke@greenbytes.de (2007-06-16): RFC4897 requires us to add
notes to the references explaining why the downref was made (see
<http://tools.ietf.org/html/rfc4897#section-3.1>).
Resolution (2007-06-18): Done. Resolution (2007-11-20): Done.
H.8. rfc2396_normative H.2. abnf-rule-names
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-11-13): Classify RFC2396 ("Uniform julian.reschke@greenbytes.de (2007-11-22): Fix invalid rule names:
Resource Identifiers (URI): Generic Syntax") as normative (update to "http_URL" and "abs_path".
RFC3986 in a separate step, see i34-updated-reference-for-uris).
Resolution (2006-11-13): Done. Resolution (2007-11-22): Replace "http_URL" by "http-URL" and "abs-
path" by "path-absolute" (which is the name used in RFC3986). Also
add BNF rules for the other rules imported from RFC2396.
H.9. usascii_normative H.3. abnf-prose-cr
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-10-27): Classify USASCII as julian.reschke@greenbytes.de (2007-11-20): Change BNF prose values to
normative. not contain line breaks.
Resolution (2006-10-27): Done. Resolution (2007-11-20): Done.
H.10. i65-informative-references H.4. abnf-case-insensitive
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i65> julian.reschke@greenbytes.de (2007-11-20): Rule names are case-
insensitive. Fix name collisions.
julian.reschke@greenbytes.de (2007-05-28): The following references
are informative: Luo1998 ("Tunneling TCP based protocols through Web
proxy servers", also update reference to quote the expired Internet
Draft properly). Nie1997 ("Network Performance Effects of HTTP/1.1,
CSS1, and PNG"). Pad1995 ("Improving HTTP Latency"). RFC821 (SMTP),
also update the reference to RFC2821. RFC822 ("STANDARD FOR THE
FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance
as RFC822ABNF for the cases where the reference if for the ABNF part
(these references will later be replaced by references to RFC4234
(see issue abnf)). RFC959 (FTP). RFC1036 ("Standard for Interchange
of USENET Messages"). RFC1123 ("Requirements for Internet Hosts --
Application and Support") -- it is only used as a background
reference for rfc1123-date, which this spec defines itself (note this
disagrees with draft-gettys-http-v11-spec-rev-00 which made it
normative). RFC1305 ("Network Time Protocol (Version 3)"). RFC1436
(Gopher). RFC1630 (URI Syntax) -- there'll be a normative reference
to a newer spec. RFC1738 (URL) -- there'll be a normative reference
to a newer spec. RFC1806 ("Communicating Presentation Information in
Internet Messages: The Content-Disposition Header"). RFC1808
(Relative Uniform Resource Locators). RFC1867 ("Form-based File
Upload in HTML"), also update the reference to RFC2388 ("Returning
Values from Forms: multipart/form-data"). RFC1900 ("Renumbering
Needs Work"). RFC1945 (HTTP/1.0). RFC2026 ("The Internet Standards
Process -- Revision 3"). RFC2049 ("Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples").
RFC2068 (HTTP/1.1). RFC2076 ("Common Internet Message Headers").
RFC2110 (MHTML), also update the reference to RFC2557. RFC2145 ("Use
and Interpretation of HTTP Version Numbers"). RFC2183
("Communicating Presentation Information in Internet Messages: The
Content-Disposition Header Field"). RFC2277 ("IETF Policy on
Character Sets and Languages"). RFC2279 (UTF8), also update the
reference to RFC3629. RFC2324 (HTCPCP/1.0). Spero ("Analysis of
HTTP Performance Problems"). Tou1998 ("Analysis of HTTP
Performance"). WAIS ("WAIS Interface Protocol Prototype Functional
Specification (v1.5)").
derhoermi@gmx.net (2007-05-28): _On RFC1950-1952:_ Understanding
these documents is required in order to understand the coding values
defined for the coding registry established and used by the document;
why would it be appropriate to cite them as informative?
Resolution (2007-06-12): Done (with the exceptions noted by Bjoern
Hoehrmann).
H.11. i31-qdtext-bnf
In Section 2.2:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i31>
jamie@shareable.org (2004-03-15): ...I wrote a regular expression julian.reschke@greenbytes.de (2007-11-22): Proposal: replace "host"
based on the RFC 2616 definition, and that allows "foo\" as a quoted- by "uri-host", "trailer" by "trailer-part".
string. That's not intended, is it?
Resolution (2007-06-18): Resolved as per Resolution (2007-11-22): Done.
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action13.
H.12. i62-whitespace-in-quoted-pair H.5. i82-rel_path-not-used
In Section 2.2: In Section 3.2.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i62> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i82>
dan.winship@gmail.com (2007-04-20): (...) RFC 2822 updates RFC 822's
quoted-pair rule to disallow CR, LF, and NUL. We should probably
make the same change.
Resolution (2007-10-07): Closed as duplicate of i64-ws-in-quoted-
pair.
H.13. i26-import-query-bnf
In Section 3.2.2:
Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i26>
abodeman@yahoo.com (2005-05-23):
In section 3.2.2, http_URL is defined as follows:
"http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query
]]" -- http://tools.ietf.org/html/rfc2616.html#section-3.2.2
However, RFC 2616 does not contain a rule called "query". I assume
this is meant to be the same "query" that is defined in RFC 2396,
since section 3.2.1 incorporates "URI-reference", "absoluteURI",
"relativeURI", "port", "host", "abs_path", "rel_path", and
"authority" from that specification (but "query" is missing from this
list).
Resolution (2007-10-06): Add "query" to the list of definitions
adopted from RCF2396 (note that RFC2396 has been obsoleted by
RFC3986, but this is a separate issue).
H.14. i47-inconsistency-in-date-format-explanation
In Section 3.3.1:
Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47>
julian.reschke@greenbytes.de (2006-11-20): Should say "...obsolete
RFC1036 date format [...]..." instead of "...obsolete RFC 850 [12]
date format...".
See also <http://lists.w3.org/Archives/Public/ietf-http-wg/
2006OctDec/0187.html>.
fielding@gbiv.com (2007-11-02):
The proposed resolution to this issue (in draft 03) is incorrect
because RFC1036 doesn't define the date format in question. This was
an error introduced in the 2616 editing cycle. It should be fixed by
removing reference to 1036, as described below:
<del>RFC 850, obsoleted by RFC 1036</del><ins>obsolete RFC 850
format</ins>
<del>The second format is in common use, but is based on the obsolete julian.reschke@gmx.de (2007-10-07):
RFC 850 [RFC1036] date format and lacks a four-digit year.</del><ins>
The other formats are described here only for compatibility with
obsolete implementations.</ins>
Resolution (2007-11-03): Resolved as proposed by Roy. RFC2616 changed the ABNF for http_URL so that it doesn't use rel_path
(as defined in RFC2396) anymore.
H.15. media-reg However, that definition is still "adopted" in:
In Section 3.7: "URIs in HTTP can be represented in absolute form or relative to
some known base URI [11], depending upon the context of their use.
The two forms are differentiated by the fact that absolute URIs
always begin with a scheme name followed by a colon. For
definitive information on URL syntax and semantics, see "Uniform
Resource Identifiers (URI): Generic Syntax and Semantics," RFC
2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This
specification adopts the definitions of "URI-reference",
"absoluteURI", "relativeURI", "port", "host","abs_path",
"rel_path", and "authority" from that specification." --
http://tools.ietf.org/html/rfc2616#section-3.2.1
Type: change ...and used in:
<http://purl.org/NET/http-errata#media-reg>, "We note one exception to this rule: since some applications have
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i8> traditionally used GETs and HEADs with query URLs (those
containing a "?" in the rel_path part) to perform operations with
significant side effects, caches MUST NOT treat responses to such
URIs as fresh unless the server provides an explicit expiration
time. This specifically means that responses from HTTP/1.0
servers for such URIs SHOULD NOT be taken from a cache. See
Section 9.1.1 for related information." --
http://tools.ietf.org/html/rfc2616#section-13.9
derhoermi@gmx.net (2000-09-10): See <http://lists.w3.org/Archives/ Proposal:
Public/ietf-http-wg-old/2000SepDec/0013>. 1) get rid of the mention in 3.2.1, and
2) in 13.9 paragraph 2, replace "...query URLs (those containing a
"?" in the rel_path part)..." by "...URLs containing a query part..."
Resolution (2006-11-14): Done (note that RFC2048 has been obsoleted Resolution (2007-11-25): Closed as proposed.
now as well; see separate issue rfc2048_informative_and_obsolete).
Note that the prosed resolution in
http://purl.org/NET/http-errata#media-reg contains typos both in the
original text ("4288" rather than "1590") and in the proposed
resolution ("Mulitpurpose").
H.16. i84-redundant-cross-references H.6. abnf-chunk-data
In Section 9.5: In Section 3.6.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i84> julian.reschke@greenbytes.de (2007-11-22):
fielding@gbiv.com (2007-09-28):
RFC 2616 sections 9.5 (POST) and 9.6 (PUT) have the following useless
waste of bits
"POST requests MUST obey the message transmission requirements set
out in section 8.2.
See section 15.1.3 for security considerations." --
http://tools.ietf.org/html/rfc2616#section-9.5
and
"PUT requests MUST obey the message transmission requirements set The grammar production:
out in section 8.2." --
http://tools.ietf.org/html/rfc2616#section-9.6
respectively. They can be safely deleted without changing HTTP. chunk-data = chunk-size(OCTET)
Section 8.2 is not specific to PUT and POST. Likewise, a content- doesn't work as intended; "chunk-size" can not appear in this place.
free forward pointer to just one of the many subsections on security Fix the production by moving "chunk-size" into a comment.
consideration is a total waste of brain cells.
Those are just two examples of what can only be described as a Resolution (2007-11-22): Say "chunk-data = 1*OCTET ; a sequence of
spaghetti style of content-free cross-references within the spec that chunk-size octets" instead.
make it very hard to read. They should be removed in general at the
editors' discretion.
Resolution (2007-09-29): Remove text as proposed. H.7. i70-cacheability-of-303
H.17. i87-typo-in-13.2.2 In Section 10.3.4:
In Section 13.2.2: Type: change
Type: edit <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70>
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i87> fielding@gbiv.com (2007-07-12):
fielding@gbiv.com (2007-09-07):
This typo is still in the current draft. On the cacheability requirement: ... I have no idea why the
specification says that. Cache-control can be used to override it.
s/ought to used/ought to be used/; "A response received with any other status code MUST NOT be
returned in a reply to a subsequent request unless there are
Cache-Control directives or another header(s) that explicitly
allow it. For example, these include the following: an Expires
header (section 14.21); a "max-age", "must-revalidate", "proxy-
revalidate", "public" or "private" Cache-Control directive
(section 14.9)." --
http://tools.ietf.org/html/rfc2616#section-13.4
Resolution (2007-09-08): Fixed. It looks like the contradiction was added to RFC 2616 when somebody
decided to convert the commentary on its use with POST into a fixed
requirement on all 303 responses. It is just a bug in the spec.
H.18. i25-accept-encoding-bnf fielding@gbiv.com (2007-07-13):
In Section 14.3: My suggestion is to change the entire section to:
Type: change 10.3.4. 303 See Other
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i25> The server directs the user agent to a different resource, indicated
by a URI in the Location header field, that provides an indirect
response to the original request. The user agent MAY perform a GET
request on the URI in the Location field in order to obtain a
representation corresponding to the response, be redirected again, or
end with an error status. The Location URI is not a substitute
reference for the originally requested resource.
abodeman@yahoo.com (2005-06-02): The 303 status is generally applicable to any HTTP method. It is
primarily used to allow the output of a POST action to redirect the
user agent to a selected resource, since doing so provides the
information corresponding to the POST response in a form that can be
separately identified, bookmarked, and cached independent of the
original request.
In section 14.3, the definition of Accept-Encoding is given as A 303 response to a GET request indicates that the requested resource
follows: does not have a representation of its own that can be transferred by
the server over HTTP. The Location URI indicates a resource that is
descriptive of the requested resource such that the follow-on
representation may be useful without implying that that it adequately
represents the previously requested resource. Note that answers to
the questions of what can be represented, what representations are
adequate, and what might be a useful description are outside the
scope of HTTP and thus entirely determined by the resource owner(s).
Accept-Encoding = "Accept-Encoding" ":" A 303 response SHOULD NOT be cached unless it is indicated as
1#( codings [ ";" "q" "=" qvalue ] ) cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI.
This definition implies that there must be at least one non-null dbooth@hp.com (2007-07-03): ... s/The Location URI indicates/The
codings. However, just below this definition, one of the examples Location URI SHOULD indicate/ ...
given has an empty Accept-Encoding field-value:
Accept-Encoding: compress, gzip dbooth@hp.com (2007-10-04):
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Furthermore, the fourth rule for testing whether a content-coding is ...My thinking was that the owner of the URI originally requested may
acceptable mentions the possibility that the field-value may be not be the same as the owner of the redirect URI, and hence the first
empty. owner might not have control over whether the resource at the
redirect URI really *is* "descriptive of the requested resource",
even though it is thought to be.
It seems, then, that the definition for Accept-Encoding should be BTW, I do notice one other thing. I suggest changing the following
revised: sentence:
Accept-Encoding = "Accept-Encoding" ":" "A 303 response to a GET request indicates that the requested
#( codings [ ";" "q" "=" qvalue ] ) resource does not have a representation of its own that can be
transferred by the server over HTTP."
Resolution (2007-03-18): Accepted during the Prague meeting, see to:
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action09.
H.19. remove-CTE-abbrev "A 303 response to a GET request indicates that the requested
resource does not have a representation of its own, available from
the request URI, that can be transferred by the server over HTTP."
In Section D.5: The reason is that if the same resource were requested via a
different URI, it might indeed provide a representation of its own
(if it were an information resource). The original text would have
prevented 303 URIs from identifying information resources, rather
than permitting them to identify any kind of resource.
Type: edit fielding@gbiv.com (2007-10-16):
<file:///C:/projects/w3c/WWW/Protocols/HTTP/1.1/rfc2616bis/issues/ ...
index.html#i16>
fielding@gbiv.com (2007-11-02): ...there is absolutely no reason to In which case it would be redirected via a 301, 302, or 307. 303 only
abbreviate the field name when it is only used twice in the entire redirects to different resources, which means the requested resource
document... for the 303 response is different from the target resource, even if
that difference can't be measured in bits. Even if they aren't, in
fact, different, the client is being told by the server that they
should be interpreted as different, and that makes it fact as far as
HTTP's interface is concerned.
Resolution (2007-11-15): Done. There is no information resource in HTTP, for the same reason that
there is no spoon in the Matrix.
Appendix I. Open issues (to be removed by RFC Editor prior to Appendix I. Open issues (to be removed by RFC Editor prior to
publication) publication)
I.1. rfc2616bis 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.
skipping to change at page 203, line 42 skipping to change at page 201, line 42
I.3. i40-header-registration I.3. i40-header-registration
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i40> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i40>
A revision of RFC2616 should mention BCP 90 (Registration Procedures A revision of RFC2616 should mention BCP 90 (Registration Procedures
for Message Header Fields) and should take over as the authoritative for Message Header Fields) and should take over as the authoritative
reference for the headers it contains. reference for the headers it contains.
I.4. edit I.4. need_iana_considerations
Type: change
julian.reschke@greenbytes.de (2006-10-24): We need an IANA
Considerations section. Include update to HTTP header registration
there? (Also: do we need a method name registry?)
I.5. edit
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for
editorial fixes/enhancements. editorial fixes/enhancements.
I.5. abnf I.6. abnf-avoid-prose
Type: change Type: change
julian.reschke@greenbytes.de (2007-11-23): Avoid prose when an exact
rule can be specified.
I.7. abnf
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36>
julian.reschke@greenbytes.de (2006-12-03): Update BNF to RFC4234 julian.reschke@greenbytes.de (2006-12-03): Update BNF to RFC4234
(plan to be added). (plan to be added).
julian.reschke@greenbytes.de (2007-07-24): See julian.reschke@greenbytes.de (2007-07-24): See
<http://www.w3.org/mid/45FBAB8C.6010809@gmx.de> for a to-do list. <http://www.w3.org/mid/45FBAB8C.6010809@gmx.de> for a to-do list.
julian.reschke@greenbytes.de (2007-11-13): See julian.reschke@greenbytes.de (2007-11-13): See
<http://www.w3.org/mid/4739C417.2040203@gmx.de> for a summary of <http://www.w3.org/mid/4739C417.2040203@gmx.de> for a summary of
issues with the current ABNF. issues with the current ABNF.
I.6. rfc2048_informative_and_obsolete I.8. rfc2822_normative
Type: change
julian.reschke@greenbytes.de (2006-12-03): RFC822 ("STANDARD FOR THE
FORMAT OF ARPA INTERNET TEXT MESSAGES") has been obsoleted by RFC2822
("Internet Message Format"). Some of the references from RFC822 can
be upgraded, some others are historical notes and should stay as they
are. Also, RFC822 is the base for RFC2616's ABNF; as long as it has
not been upgraded to RFC4234 format, we need to keep RFC822 as
normative reference. See issue abnf.
julian.reschke@greenbytes.de (2007-06-16): RFC4897 requires us to add
a note to the references explaining why the downref was made (see
<http://tools.ietf.org/html/rfc4897#section-3.1>).
I.9. rfc1737_informative_and_obsolete
Type: change
julian.reschke@greenbytes.de (2006-10-27): Classify RFC1737
("Functional Requirements for Uniform Resource Names") as informative
and update to RFC2141 ("URN Syntax") which seems to be a better
reference.
I.10. rfc2048_informative_and_obsolete
Type: edit Type: edit
julian.reschke@greenbytes.de (2006-11-15): Classify RFC2048 julian.reschke@greenbytes.de (2006-11-15): Classify RFC2048
("Multipurpose Internet Mail Extensions (MIME) Part Four: ("Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures") as informative, update to RFC4288, Registration Procedures") as informative, update to RFC4288,
potentially update the application/http and multipart/byteranges MIME potentially update the application/http and multipart/byteranges MIME
type registration. Also, in Section 3.7 fix first reference to refer type registration. Also, in Section 3.7 fix first reference to refer
to RFC2046 (it's about media types in general, not the registration to RFC2046 (it's about media types in general, not the registration
procedure). procedure).
julian.reschke@greenbytes.de (2007-04-20): Separate issue for julian.reschke@greenbytes.de (2007-04-20): Separate issue for
updating the registration template: i55-updating-to-rfc4288. updating the registration template: i55-updating-to-rfc4288.
I.7. i34-updated-reference-for-uris I.11. i34-updated-reference-for-uris
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i34> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i34>
julian.reschke@greenbytes.de (2006-11-14): Update RFC2396 ("Uniform julian.reschke@greenbytes.de (2006-11-14): Update RFC2396 ("Uniform
Resource Identifiers (URI): Generic Syntax") to RFC3986. Resource Identifiers (URI): Generic Syntax") to RFC3986.
I.8. i50-misc-typos I.12. i50-misc-typos
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50>
a-travis@microsoft.com (2006-12-18): (See <http://lists.w3.org/ a-travis@microsoft.com (2006-12-18): (See <http://lists.w3.org/
Archives/Public/ietf-http-wg/2006OctDec/0275.html>). Archives/Public/ietf-http-wg/2006OctDec/0275.html>).
julian.reschke@greenbytes.de (2007-06-29): Some of the strictly julian.reschke@greenbytes.de (2007-06-29): Some of the strictly
editorial issues have been resolves as part of issue "edit". editorial issues have been resolves as part of issue "edit".
I.9. i52-sort-1.3-terminology I.13. i52-sort-1.3-terminology
In Section 1.3: In Section 1.3:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52>
a-travis@microsoft.com (2006-12-21): It's irritating to try and look a-travis@microsoft.com (2006-12-21): It's irritating to try and look
up definitions in section 1.3. IMHO, the entries really should be up definitions in section 1.3. IMHO, the entries really should be
sorted alphabetically, despite the fact that the terms have sorted alphabetically, despite the fact that the terms have
skipping to change at page 205, line 39 skipping to change at page 204, line 39
shuffling to control whether it's correct (nothing lost, no change in shuffling to control whether it's correct (nothing lost, no change in
the definitions). the definitions).
(2) In the RFC2616 ordering, things that belong together (such as (2) In the RFC2616 ordering, things that belong together (such as
"client", "user agent", "server" ...) are close to each other. "client", "user agent", "server" ...) are close to each other.
(3) Contrary to RFC2616, the text version of new spec will contain an (3) Contrary to RFC2616, the text version of new spec will contain an
alphabetical index section anyway (unless it's removed upon alphabetical index section anyway (unless it's removed upon
publication :-). publication :-).
I.10. i63-header-length-limit-with-encoded-words I.14. i63-header-length-limit-with-encoded-words
In Section 2.2: In Section 2.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63>
derhoermi@gmx.net (2007-05-14): (See <http://lists.w3.org/Archives/ derhoermi@gmx.net (2007-05-14): (See <http://lists.w3.org/Archives/
Public/ietf-http-wg/2007AprJun/0050.html>). Public/ietf-http-wg/2007AprJun/0050.html>).
I.11. i74-character-encodings-for-headers I.15. i74-character-encodings-for-headers
In Section 2.2: In Section 2.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i74> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i74>
duerst@it.aoyama.ac.jp (2007-07-10): RFC 2616 prescribes that headers duerst@it.aoyama.ac.jp (2007-07-10): RFC 2616 prescribes that headers
containing non-ASCII have to use either iso-8859-1 or RFC 2047. This containing non-ASCII have to use either iso-8859-1 or RFC 2047. This
is unnecessarily complex and not necessarily followed. At the least, is unnecessarily complex and not necessarily followed. At the least,
new extensions should be allowed to specify that UTF-8 is used. new extensions should be allowed to specify that UTF-8 is used.
I.12. i64-ws-in-quoted-pair I.16. i64-ws-in-quoted-pair
In Section 2.2: In Section 2.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i64> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i64>
dan.winship@gmail.com (2007-04-20): dan.winship@gmail.com (2007-04-20):
I think quoted-pair is broken too. Merging your fix into RFC2616 I think quoted-pair is broken too. Merging your fix into RFC2616
skipping to change at page 207, line 5 skipping to change at page 206, line 5
Warning: "Don't misparse \ Warning: "Don't misparse \
this: it's really a single header!" this: it's really a single header!"
(if the receiving implementation follows the recommendations in 19.3 (if the receiving implementation follows the recommendations in 19.3
you need to escape the LF instead of the CR, but it's otherwise the you need to escape the LF instead of the CR, but it's otherwise the
same.) same.)
RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and RFC 2822 updates RFC 822's quoted-pair rule to disallow CR, LF, and
NUL. We should probably make the same change. NUL. We should probably make the same change.
I.13. i75-rfc2145-normative I.17. i75-rfc2145-normative
In Section 3.1: In Section 3.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i75> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i75>
Jeff.Mogul@hp.com (2007-06-07): http://www.ietf.org/rfc/rfc2145.txt: Jeff.Mogul@hp.com (2007-06-07): http://www.ietf.org/rfc/rfc2145.txt:
There are references from RFC2616, section 3.1, to this document. There are references from RFC2616, section 3.1, to this document.
Perhaps these should be marked as normative; certainly, a proxy Perhaps these should be marked as normative; certainly, a proxy
implemention that violates RFC2145 is non-compliant in any reasonable implemention that violates RFC2145 is non-compliant in any reasonable
sense of the word. sense of the word.
I.14. i82-rel_path-not-used I.18. i58-what-identifies-an-http-resource
In Section 3.2.1:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i82>
julian.reschke@gmx.de (2007-10-07):
RFC2616 changed the ABNF for http_URL so that it doesn't use rel_path
(as defined in RFC2396) anymore.
However, that definition is still "adopted" in:
"URIs in HTTP can be represented in absolute form or relative to
some known base URI [11], depending upon the context of their use.
The two forms are differentiated by the fact that absolute URIs
always begin with a scheme name followed by a colon. For
definitive information on URL syntax and semantics, see "Uniform
Resource Identifiers (URI): Generic Syntax and Semantics," RFC
2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This
specification adopts the definitions of "URI-reference",
"absoluteURI", "relativeURI", "port", "host","abs_path",
"rel_path", and "authority" from that specification." --
http://tools.ietf.org/html/rfc2616#section-3.2.1
...and used in:
"We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those
containing a "?" in the rel_path part) to perform operations with
significant side effects, caches MUST NOT treat responses to such
URIs as fresh unless the server provides an explicit expiration
time. This specifically means that responses from HTTP/1.0
servers for such URIs SHOULD NOT be taken from a cache. See
Section 9.1.1 for related information." --
http://tools.ietf.org/html/rfc2616#section-13.9
Proposal:
1) get rid of the mention in 3.2.1, and
2) in 13.9 paragraph 2, replace "...query URLs (those containing a
"?" in the rel_path part)..." by "...URLs containing a query part..."
I.15. i58-what-identifies-an-http-resource
In Section 3.2.2: In Section 3.2.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58>
julian.reschke@gmx.de (2007-01-23): julian.reschke@gmx.de (2007-01-23):
3.2.2 really doesn't say what identifies the resource: 3.2.2 really doesn't say what identifies the resource:
"If the port is empty or not given, port 80 is assumed. The "If the port is empty or not given, port 80 is assumed. The
semantics are that the identified resource is located at the semantics are that the identified resource is located at the
server listening for TCP connections on that port of that host, server listening for TCP connections on that port of that host,
and the Request-URI for the resource is abs_path (Section 5.1.2)." and the Request-URI for the resource is abs_path (Section 5.1.2)."
-- http://tools.ietf.org/html/rfc2616#section-3.2.2 -- http://tools.ietf.org/html/rfc2616#section-3.2.2
But it _does_ say what part of the HTTP URL becomes the Request-URI, But it _does_ say what part of the HTTP URL becomes the Request-URI,
and that definitively needs to be fixed. and that definitively needs to be fixed.
I.16. i51-http-date-vs-rfc1123-date I.19. i51-http-date-vs-rfc1123-date
In Section 3.3.1: In Section 3.3.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51>
a-travis@microsoft.com (2006-12-18): On closer inspection, shouldn't a-travis@microsoft.com (2006-12-18): On closer inspection, shouldn't
the BNF for that section (14.18) be "rfc1123-date" and not "HTTP- the BNF for that section (14.18) be "rfc1123-date" and not "HTTP-
date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is
allowed (conflicting with the definition of HTTP-date)*? Likewise, allowed (conflicting with the definition of HTTP-date)*? Likewise,
shouldn't we just use the rfc1123-date moniker throughout the shouldn't we just use the rfc1123-date moniker throughout the
document whenever explicitly referring to only dates in RFC 1123 document whenever explicitly referring to only dates in RFC 1123
format? format?
I.17. i73-clarification-of-the-term-deflate I.20. i73-clarification-of-the-term-deflate
In Section 3.5: In Section 3.5:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i73> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i73>
paul_marquess@yahoo.co.uk (2007-08-07): paul_marquess@yahoo.co.uk (2007-08-07):
There is ambiguity in that definition because of the inconsistent use There is ambiguity in that definition because of the inconsistent use
skipping to change at page 209, line 37 skipping to change at page 207, line 39
So I suggest there are two issues that need to be addressed So I suggest there are two issues that need to be addressed
1. The definition of "deflate" needs to be rewritten to remove the 1. The definition of "deflate" needs to be rewritten to remove the
ambiguity. ambiguity.
2. Document the reality that there are incorrect implementations, 2. Document the reality that there are incorrect implementations,
and recommend that anyone writing a "deflate" decoder should cope and recommend that anyone writing a "deflate" decoder should cope
with both forms. with both forms.
I.18. i67-quoting-charsets I.21. i67-quoting-charsets
In Section 3.7: In Section 3.7:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67>
maiera@de.ibm.com (2007-05-23): (See <http://lists.w3.org/Archives/ maiera@de.ibm.com (2007-05-23): (See <http://lists.w3.org/Archives/
Public/ietf-http-wg/2007AprJun/0065.html>). Public/ietf-http-wg/2007AprJun/0065.html>).
I.19. i20-default-charsets-for-text-media-types I.22. i20-default-charsets-for-text-media-types
In Section 3.7.1: In Section 3.7.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i20>
mnot@yahoo-inc.com (2006-05-01): mnot@yahoo-inc.com (2006-05-01):
2616 Section 3.7.1 states; 2616 Section 3.7.1 states;
"When no explicit charset parameter is provided by the sender, "When no explicit charset parameter is provided by the sender,
media subtypes of the "text" type are defined to have a default media subtypes of the "text" type are defined to have a default
charset value of "ISO-8859-1" when received via HTTP." -- charset value of "ISO-8859-1" when received via HTTP." --
http://tools.ietf.org/html/rfc2616#section-3.7.1 http://tools.ietf.org/html/rfc2616#section-3.7.1
skipping to change at page 211, line 5 skipping to change at page 209, line 6
8859-1. And browsers in these regions don't expect pages to be iso- 8859-1. And browsers in these regions don't expect pages to be iso-
8859-1. 8859-1.
... ...
So the text below should be changed to say that data in all character So the text below should be changed to say that data in all character
sets SHOULD be labeled, and move the default to historic. Some sets SHOULD be labeled, and move the default to historic. Some
adequate adjustments should also be made to Section 3.4.1. I'll adequate adjustments should also be made to Section 3.4.1. I'll
gladly help with word-smithing. gladly help with word-smithing.
I.20. languagetag I.23. i90-delimiting-messages-with-multipart-byteranges
In Section 3.7.2:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i90>
derhoermi@gmx.net (2007-11-18):
There appears to be some confusion as to when multipart/byteranges
bodies have to be inspected to determine the message length. It
seems that is widely considered optional and sometimes limited to ...
"In general, HTTP treats a multipart message-body no differently
than any other media type: strictly as payload. The one exception
is the "multipart/byteranges" type (appendix 19.2) when it appears
in a 206 (Partial Content) response ..."
... this particular case, even though the specification suggest the
opposite, I read it to say, all implementations have to support that
and support it in all messages, like requests and non-206 responses.
Apache 2.2.6 for example treats
POST / HTTP/1.1
Host: example
Content-type: multipart/byteranges;
boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
...
as two requests, a zero-length POST and a --THIS_STRING_SEPARATES to
the root which it does not support (which seems to be a bug in
itself).
Would it be possible, for example, to discourage implementations to
ever generate messages where the message length is determined by this
type, and limit having to read it to 206 responses, as the text above
suggests?
I.24. languagetag
In Section 3: In Section 3:
Type: change Type: change
<http://purl.org/NET/http-errata#languagetag>, <http://purl.org/NET/http-errata#languagetag>,
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13>
julian.reschke@greenbytes.de (2006-10-14): See julian.reschke@greenbytes.de (2006-10-14): See
<http://purl.org/NET/http-errata#languagetag>. <http://purl.org/NET/http-errata#languagetag>.
julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066 julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066
has been obsoleted by RFC4646. See also has been obsoleted by RFC4646. See also
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001>. <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001>.
I.21. i85-custom-ranges julian.reschke@greenbytes.de (2007-11-29): See feedback in <http://
lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/0293.html> and <
http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/
0296.html>, in particular the pointer to RFC4647 which defines
Language-Range.
I.25. i85-custom-ranges
In Section 3.12: In Section 3.12:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i85> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i85>
kornel@geekhood.net (2007-08-25): kornel@geekhood.net (2007-08-25):
The RFC 2616 seems to suggest such possibility in 3.12 Range Units: The RFC 2616 seems to suggest such possibility in 3.12 Range Units:
skipping to change at page 212, line 5 skipping to change at page 211, line 10
was a lot of push-back from people who thought it was too much was a lot of push-back from people who thought it was too much
complexity. complexity.
I think the idea 'sort of' got into the spec, but not fully fleshed I think the idea 'sort of' got into the spec, but not fully fleshed
out. out.
I agree that it belongs in the issue list, to either clarify how to I agree that it belongs in the issue list, to either clarify how to
use custom ranges (with a range unit registry, for example) or else use custom ranges (with a range unit registry, for example) or else
to remove the feature. to remove the feature.
I.22. i30-header-lws I.26. i30-header-lws
In Section 4.2: In Section 4.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i30>
jamie@shareable.org (2004-03-15): _See jamie@shareable.org (2004-03-15): _See
<http://www.w3.org/mid/20040315183116.GC9731@mail.shareable.org>_. <http://www.w3.org/mid/20040315183116.GC9731@mail.shareable.org>_.
I.23. i77-line-folding I.27. i77-line-folding
In Section 4.2: In Section 4.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i77> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i77>
fielding@gbiv.com (2007-01-19): fielding@gbiv.com (2007-01-19):
...I think the spec should reflect the standard, not be artificially ...I think the spec should reflect the standard, not be artificially
skipping to change at page 213, line 5 skipping to change at page 212, line 9
forwarded, but forbidding a server from processing such a message is forwarded, but forbidding a server from processing such a message is
not going to happen because it would make all implementations non- not going to happen because it would make all implementations non-
compliant. compliant.
Servers should be configurable in regards to robust or restricted Servers should be configurable in regards to robust or restricted
parsing behavior, and nothing we say can improve the "security" of parsing behavior, and nothing we say can improve the "security" of
broken software that was deployed years ago. Software that correctly broken software that was deployed years ago. Software that correctly
parses according to the RFC is not subject to those perceived parses according to the RFC is not subject to those perceived
security issues. security issues.
I.24. i19-bodies-on-GET I.28. i93-repeating-single-value-headers
In Section 4.2:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i93>
julian.reschke@gmx.de (2007-11-20):
follow-up to a discussion over at the HTML mailing list, see
<http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>).
We currently say in Section 4.2:
"Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for
that header field is defined as a comma-separated list [i.e.,
#(values)]." -- http://tools.ietf.org/html/rfc2616#section-4.2
Now this seems to be kind of backwards, wouldn't it be *much* clearer
if it said:
"Multiple message-header fields with the same field-name MUST NOT
be present in a message unless the entire field-value for that
header field is defined as a comma-separated list [i.e.,
#(values)]."
That being said, do we have a recommendation for recipients when that
requirement is violated? I would assume that servers SHOULD return a
400 (Bad Request), but what about clients?
I.29. i19-bodies-on-GET
In Section 4.3: In Section 4.3:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19>
Jeff.Mogul@hp.com (2006-06-22): (See <http://www.w3.org/mid/ Jeff.Mogul@hp.com (2006-06-22): (See <http://www.w3.org/mid/
200606221739.k5MHd3PA013395@pobox-pa.hpl.hp.com>). 200606221739.k5MHd3PA013395@pobox-pa.hpl.hp.com>).
I.25. i28-connection-closing I.30. i88-205-bodies
In Section 4.3:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i88>
julian.reschke@greenbytes.de (2007-11-29): (See
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i88>).
I.31. i28-connection-closing
In Section 4.4: In Section 4.4:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i28>
joe@manyfish.co.uk (2005-02-26): The phrase "unless the message is joe@manyfish.co.uk (2005-02-26): The phrase "unless the message is
terminated by closing the connection" in Section 4.4 is unnecessary. terminated by closing the connection" in Section 4.4 is unnecessary.
Section 3.6 uses the same phrase; it is a little confusing. In 4.4 Section 3.6 uses the same phrase; it is a little confusing. In 4.4
you could almost read it to mean that presence of "Connection: close" you could almost read it to mean that presence of "Connection: close"
would mean that a T-E header should be ignored, which is presumably would mean that a T-E header should be ignored, which is presumably
not the intent (and certainly not the practice). not the intent (and certainly not the practice).
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague julian.reschke@gmx.de (2007-10-06): Discussed during the Prague
meeting, see meeting, see
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action01>. <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action01>.
I.26. i32-options-asterisk I.32. uri_vs_request_uri
In Section 5.1.2: In Section 5.1.2:
Type: change Type: change
<http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/
0126.html>
julian.reschke@greenbytes.de (2007-01-24): The Request-URI generally
is not a URI (when taking any form other than absoluteURI).
I.33. i32-options-asterisk
In Section 5.1.2:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i32> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i32>
julian.reschke@gmx.de (2003-11-24): I'd like to see a clarification julian.reschke@gmx.de (2003-11-24): I'd like to see a clarification
about what clients can expect upon OPTIONS *. In particular, can about what clients can expect upon OPTIONS *. In particular, can
they expect to find out about *any* method name supported on that they expect to find out about *any* method name supported on that
server? I'm asking because this doesn't seem to be the case for at server? I'm asking because this doesn't seem to be the case for at
least two major server bases, being: least two major server bases, being:
- Apache (for instance, additional method names supported by mod_dav - Apache (for instance, additional method names supported by mod_dav
aren't listed) and aren't listed) and
- generic Java servlet engines (servlet API does not support - generic Java servlet engines (servlet API does not support
skipping to change at page 214, line 13 skipping to change at page 214, line 25
applications). applications).
julian.reschke@gmx.de (2007-10-08): julian.reschke@gmx.de (2007-10-08):
Quote Roy Fielding: Quote Roy Fielding:
"...Allow only applies to URIs, not *..." -- http:// "...Allow only applies to URIs, not *..." -- http://
mail-archives.apache.org/mod_mbox/httpd-dev/ mail-archives.apache.org/mod_mbox/httpd-dev/
200710.mbox/%3c24EE5E9D-9FBB-4530-9735-33BD768FC633@gbiv.com%3e 200710.mbox/%3c24EE5E9D-9FBB-4530-9735-33BD768FC633@gbiv.com%3e
I.27. i83-options-asterisk-and-proxies I.34. i83-options-asterisk-and-proxies
In Section 5.1.2: In Section 5.1.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i83>
hno@squid-cache.org (2007-10-01): _Text about proxying OPTIONS * hno@squid-cache.org (2007-10-01): _Text about proxying OPTIONS *
contained in RFC2068 was lost in RCF2616._ contained in RFC2068 was lost in RCF2616._
skipping to change at page 215, line 9 skipping to change at page 215, line 23
meets this criteria. meets this criteria.
Is there a possibility for other methods than OPTIONS which may make Is there a possibility for other methods than OPTIONS which may make
sense on a global resource-less context? I think not. If this is sense on a global resource-less context? I think not. If this is
complemented with a restriction that the special request-URI "*" may complemented with a restriction that the special request-URI "*" may
only be used in OPTIONS requests then it's fine. Interoperability of only be used in OPTIONS requests then it's fine. Interoperability of
extension methods using "*" will be tricky at best.. extension methods using "*" will be tricky at best..
... ...
I.28. i56-6.1.1-can-be-misread-as-a-complete-list I.35. i56-6.1.1-can-be-misread-as-a-complete-list
In Section 6.1.1: In Section 6.1.1:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56>
henrik@henriknordstrom.net (2007-01-11): The second sentence in the henrik@henriknordstrom.net (2007-01-11): The second sentence in the
first paragraph can on a quick reading be misread as section 10 first paragraph can on a quick reading be misread as section 10
contains a complete definiton of all possible status codes, where it contains a complete definiton of all possible status codes, where it
in reality only has the status codes defined by this RFC. in reality only has the status codes defined by this RFC.
I.29. i57-status-code-and-reason-phrase I.36. i57-status-code-and-reason-phrase
In Section 6.1.1: In Section 6.1.1:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57>
henrik@henriknordstrom.net (2007-01-11): henrik@henriknordstrom.net (2007-01-11):
6.1.1 is apparently a bit too vague about how applications should 6.1.1 is apparently a bit too vague about how applications should
skipping to change at page 216, line 5 skipping to change at page 216, line 13
use the status code to determine the status of the response and only use the status code to determine the status of the response and only
process the Reason Phrase as a comment intended for humans. process the Reason Phrase as a comment intended for humans.
It's true that later in the same section there is a reverse MAY It's true that later in the same section there is a reverse MAY
requirement implying this by saying that the phrases in the rfc is requirement implying this by saying that the phrases in the rfc is
just an example and may be replaced without affecting the protocol, just an example and may be replaced without affecting the protocol,
but apparently it's not sufficient for implementers to understand but apparently it's not sufficient for implementers to understand
that applications should not decide the outcome based on the reason that applications should not decide the outcome based on the reason
phrase. phrase.
I.30. i59-status-code-registry I.37. i59-status-code-registry
In Section 6.1.1: In Section 6.1.1:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59>
henrik@henriknordstrom.net (2007-02-18): The IANA status code henrik@henriknordstrom.net (2007-02-18): The IANA status code
registry should be referred to. registry should be referred to.
I.31. i72-request-method-registry I.38. i94-reason-phrase-bnf
In Section 6.1.1:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i94>
julian.reschke@gmx.de (2007-11-23):
Looking at...:
Reason-Phrase = *<TEXT, excluding CR, LF>
TEXT = <any OCTET except CTLs,
but including LWS>
LWS = [CRLF] 1*( SP | HT )
CRLF = CR LF
So was the real intent to say: any OCTET except CTLs?
I.39. i91-duplicate-host-header-requirements
In Section 9:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i91>
julian.reschke@gmx.de (2007-11-14): ...any reason why the Host header
requirement is listed here so prominently (duplicating text from
14.23)?
I.40. i72-request-method-registry
In Section 9: In Section 9:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i72> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i72>
henrik@henriknordstrom.net (2007-08-06): I see a need for an official henrik@henriknordstrom.net (2007-08-06): I see a need for an official
HTTP request method registry to be established, preferably maintained HTTP request method registry to be established, preferably maintained
by IANA. by IANA.
I.32. i21-put-side-effects I.41. i21-put-side-effects
In Section 9.6: In Section 9.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21>
mnot@yahoo-inc.com (2006-04-03): mnot@yahoo-inc.com (2006-04-03):
2616 specifically allows PUT to have side effects; 2616 specifically allows PUT to have side effects;
skipping to change at page 217, line 4 skipping to change at page 217, line 43
example, an article might have a URI for identifying "the current example, an article might have a URI for identifying "the current
version" which is separate from the URI identifying each version" which is separate from the URI identifying each
particular version. In this case, a PUT request on a general URI particular version. In this case, a PUT request on a general URI
might result in several other URIs being defined by the origin might result in several other URIs being defined by the origin
server. server.
HTTP/1.1 does not define how a PUT method affects the state of an HTTP/1.1 does not define how a PUT method affects the state of an
origin server." -- origin server." --
http://tools.ietf.org/html/rfc2616.html#section-9.6 http://tools.ietf.org/html/rfc2616.html#section-9.6
and it also says (in the context of PUT) and it also says (in the context of PUT)
"If a new resource is created, the origin server MUST inform the "If a new resource is created, the origin server MUST inform the
user agent via the 201 (Created) response." -- user agent via the 201 (Created) response." --
http://tools.ietf.org/html/rfc2616.html#section-9.6 http://tools.ietf.org/html/rfc2616.html#section-9.6
So, if I PUT something to /foo, and it has the side effect if So, if I PUT something to /foo, and it has the side effect if
creating /foo;2006-04-03, is the response required to be a 201 creating /foo;2006-04-03, is the response required to be a 201
Created? Created?
I.e., read literally, the above requirement requires a 201 Created I.e., read literally, the above requirement requires a 201 Created
when PUT results in *any* resource being created -- even as a side when PUT results in *any* resource being created -- even as a side
effect. effect.
This is IMO unnecessarily constraining, and should be relaxed; e.g., This is IMO unnecessarily constraining, and should be relaxed; e.g.,
changed to something like changed to something like
_"If a new resource is created at the Request-URI, the origin server _"If a new resource is created at the Request-URI, the origin server
MUST inform the user agent via the 201 (Created) response."_ MUST inform the user agent via the 201 (Created) response."_
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague julian.reschke@gmx.de (2007-10-06): Discussed during the Prague
meeting, see meeting, see
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action06>: <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action06>:
_Combine to make second sentence dependent upon the first: "If the _Combine to make second sentence dependent upon the first: "If the
Request-URI does not point to an existing resource, and that URI is Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response."_ via the 201 (Created) response."_
I.33. i27-put-idempotency I.42. i27-put-idempotency
In Section 9.6: In Section 9.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i27>
mnot@yahoo-inc.com (2005-03-16): It _appears_ that RFC3253 changes mnot@yahoo-inc.com (2005-03-16): It _appears_ that RFC3253 changes
the idempotency of PUT; is this allowed? RFC3253 doesn't update or the idempotency of PUT; is this allowed? RFC3253 doesn't update or
obsolete 2616... obsolete 2616...
skipping to change at page 218, line 11 skipping to change at page 219, line 5
meeting, see meeting, see
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>: <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action10>:
_"Loosen definition of Idempotency as per Roy."_ -- See _"Loosen definition of Idempotency as per Roy."_ -- See
<http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: _Just <http://tech.groups.yahoo.com/group/rest-discuss/message/7387>: _Just
ignore the definition of idempotent in RFC 2616. Anything specified ignore the definition of idempotent in RFC 2616. Anything specified
in HTTP that defines how the server shall implement the semantics of in HTTP that defines how the server shall implement the semantics of
an interface method is wrong, by definition. What matters is the an interface method is wrong, by definition. What matters is the
effect on the interface as expected by the client, not what actually effect on the interface as expected by the client, not what actually
happens on the server to implement that effect._ happens on the server to implement that effect._
I.34. i79-content-headers-vs-put I.43. i79-content-headers-vs-put
In Section 9.6: In Section 9.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i79> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i79>
julian.reschke@greenbytes.de (2007-07-25): It's not clear to me what julian.reschke@greenbytes.de (2007-07-25): It's not clear to me what
Content-* headers are? All headers starting with the character Content-* headers are? All headers starting with the character
sequence "Content-"? Just those defined in RFC2616? sequence "Content-"? Just those defined in RFC2616?
I.35. i33-trace-security-considerations I.44. i33-trace-security-considerations
In Section 9.8: In Section 9.8:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i33> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i33>
rousskov@measurement-factory.com (2003-02-14): rousskov@measurement-factory.com (2003-02-14):
There is an HTTP-related security violation approach found/researched There is an HTTP-related security violation approach found/researched
skipping to change at page 219, line 16 skipping to change at page 220, line 9
With numerous XSS (cross-site-scripting) vulnerabilities in user With numerous XSS (cross-site-scripting) vulnerabilities in user
agents, this seems like a real and nasty problem. TRACE method agents, this seems like a real and nasty problem. TRACE method
support is optional per RFC 2616, but many popular servers support support is optional per RFC 2616, but many popular servers support
it. White Hat Security advises server administrators to disable it. White Hat Security advises server administrators to disable
support for TRACE. support for TRACE.
What is your opinion? Should TRACE be supported by default? Is it a What is your opinion? Should TRACE be supported by default? Is it a
good idea to mention this "exposure" vulnerability in HTTP errata or good idea to mention this "exposure" vulnerability in HTTP errata or
elsewhere? elsewhere?
I.36. i69-clarify-requested-variant I.45. i69-clarify-requested-variant
In Section 10.2.2: In Section 10.2.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>
julian.reschke@gmx.de (2007-07-13): The spec uses the term "requested julian.reschke@gmx.de (2007-07-13): The spec uses the term "requested
variant" in several places (10.2.2 201 Created, 10.2.5 204 No variant" in several places (10.2.2 201 Created, 10.2.5 204 No
Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified- Content, 14.19 ETag, 14.25 If-Modified-Since, 14.28 If-Unmodified-
skipping to change at page 220, line 5 skipping to change at page 220, line 41
definition in general. definition in general.
_variant_ _variant_
_The ultimate target resource of a request after indirections caused _The ultimate target resource of a request after indirections caused
by content negotiation (varying by request fields) and method by content negotiation (varying by request fields) and method
association (e.g., PROPFIND) have been taken into account. Some association (e.g., PROPFIND) have been taken into account. Some
variant resources may also be identified directly by their own URI, variant resources may also be identified directly by their own URI,
which may be indicated by a Content-Location in the response._ which may be indicated by a Content-Location in the response._
I.37. i70-cacheability-of-303 I.46. i76-deprecate-305-use-proxy
In Section 10.3.4:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i70>
fielding@gbiv.com (2007-07-12):
On the cacheability requirement: ... I have no idea why the
specification says that. Cache-control can be used to override it.
"A response received with any other status code MUST NOT be
returned in a reply to a subsequent request unless there are
Cache-Control directives or another header(s) that explicitly
allow it. For example, these include the following: an Expires
header (section 14.21); a "max-age", "must-revalidate", "proxy-
revalidate", "public" or "private" Cache-Control directive
(section 14.9)." --
http://tools.ietf.org/html/rfc2616#section-13.4
It looks like the contradiction was added to RFC 2616 when somebody
decided to convert the commentary on its use with POST into a fixed
requirement on all 303 responses. It is just a bug in the spec.
fielding@gbiv.com (2007-07-13):
My suggestion is to change the entire section to:
10.3.4. 303 See Other
The server directs the user agent to a different resource, indicated
by a URI in the Location header field, that provides an indirect
response to the original request. The user agent MAY perform a GET
request on the URI in the Location field in order to obtain a
representation corresponding to the response, be redirected again, or
end with an error status. The Location URI is not a substitute
reference for the originally requested resource.
The 303 status is generally applicable to any HTTP method. It is
primarily used to allow the output of a POST action to redirect the
user agent to a selected resource, since doing so provides the
information corresponding to the POST response in a form that can be
separately identified, bookmarked, and cached independent of the
original request.
A 303 response to a GET request indicates that the requested resource
does not have a representation of its own that can be transferred by
the server over HTTP. The Location URI indicates a resource that is
descriptive of the requested resource such that the follow-on
representation may be useful without implying that that it adequately
represents the previously requested resource. Note that answers to
the questions of what can be represented, what representations are
adequate, and what might be a useful description are outside the
scope of HTTP and thus entirely determined by the resource owner(s).
A 303 response SHOULD NOT be cached unless it is indicated as
cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI.
dbooth@hp.com (2007-07-03): ... s/The Location URI indicates/The
Location URI SHOULD indicate/ ...
dbooth@hp.com (2007-10-04):
...My thinking was that the owner of the URI originally requested may
not be the same as the owner of the redirect URI, and hence the first
owner might not have control over whether the resource at the
redirect URI really *is* "descriptive of the requested resource",
even though it is thought to be.
BTW, I do notice one other thing. I suggest changing the following
sentence:
"A 303 response to a GET request indicates that the requested
resource does not have a representation of its own that can be
transferred by the server over HTTP."
to:
"A 303 response to a GET request indicates that the requested
resource does not have a representation of its own, available from
the request URI, that can be transferred by the server over HTTP."
The reason is that if the same resource were requested via a
different URI, it might indeed provide a representation of its own
(if it were an information resource). The original text would have
prevented 303 URIs from identifying information resources, rather
than permitting them to identify any kind of resource.
fielding@gbiv.com (2007-10-16):
...
In which case it would be redirected via a 301, 302, or 307. 303 only
redirects to different resources, which means the requested resource
for the 303 response is different from the target resource, even if
that difference can't be measured in bits. Even if they aren't, in
fact, different, the client is being told by the server that they
should be interpreted as different, and that makes it fact as far as
HTTP's interface is concerned.
There is no information resource in HTTP, for the same reason that
there is no spoon in the Matrix.
I.38. i76-deprecate-305-use-proxy
In Section 10.3.6: In Section 10.3.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i76> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i76>
adrien@qbik.com (2007-06-15): adrien@qbik.com (2007-06-15):
I can't find any browser that supports this. I can't find any browser that supports this.
skipping to change at page 222, line 44 skipping to change at page 221, line 21
* Opera displays message "The server tried to redirect Opera to the * Opera displays message "The server tried to redirect Opera to the
alternative proxy "http://xxxxxxxx". For security reasons this is no alternative proxy "http://xxxxxxxx". For security reasons this is no
longer supported." longer supported."
So looks like the main browsers (haven't tried Safari) have de facto So looks like the main browsers (haven't tried Safari) have de facto
deprecated it. deprecated it.
Is it an optional code to handle? RFC2616 is extremely sparse in its Is it an optional code to handle? RFC2616 is extremely sparse in its
description of the status code. description of the status code.
I.39. i78-relationship-between-401-authorization-and-www-authenticate I.47. i78-relationship-between-401-authorization-and-www-authenticate
In Section 10.4.2: In Section 10.4.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i78>
hugo@yahoo-inc.com (2007-07-25): Are these mechanisms exclusive? hugo@yahoo-inc.com (2007-07-25): Are these mechanisms exclusive?
I.e., can they only be used together, or can a cookie-based I.e., can they only be used together, or can a cookie-based
authentication scheme (for example) use 401? (full message at <http:/ authentication scheme (for example) use 401? (full message at <http:/
/www.w3.org/mid/5A4607FB-6F74-4C7F-BF60-37E0EFEC97DF@yahoo-inc.com>) /www.w3.org/mid/5A4607FB-6F74-4C7F-BF60-37E0EFEC97DF@yahoo-inc.com>)
I.40. i24-requiring-allow-in-405-responses I.48. i24-requiring-allow-in-405-responses
In Section 10.4.6: In Section 10.4.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i24> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i24>
fielding@gbiv.com (2005-06-23): fielding@gbiv.com (2005-06-23):
In RFC 2616, 10.4.6 405 Method Not Allowed: In RFC 2616, 10.4.6 405 Method Not Allowed:
skipping to change at page 223, line 39 skipping to change at page 222, line 16
other cases, it may not be prudent to tell an unauthenticated client other cases, it may not be prudent to tell an unauthenticated client
all of the methods that might be available to other clients. all of the methods that might be available to other clients.
I think the above should be modified to s/MUST/MAY/; does anyone here I think the above should be modified to s/MUST/MAY/; does anyone here
know of a reason not to make that change? know of a reason not to make that change?
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague julian.reschke@gmx.de (2007-10-06): Discussed during the Prague
meeting, see meeting, see
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action08>. <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action08>.
I.41. i81-content-negotiation-for-media-types I.49. i81-content-negotiation-for-media-types
In Section 12: In Section 12:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i81>
lmm@acm.org (2006-04-11): lmm@acm.org (2006-04-11):
HTTP content negotiation was one of those "nice in theory" protocol HTTP content negotiation was one of those "nice in theory" protocol
skipping to change at page 225, line 5 skipping to change at page 223, line 26
Clearly "deprecate" was hyperbole. (I can say that since I raised Clearly "deprecate" was hyperbole. (I can say that since I raised
the issue in the first place.) However, Accept headers have a the issue in the first place.) However, Accept headers have a
limited domain of applicability, e.g., when the client has a limited limited domain of applicability, e.g., when the client has a limited
repertoire of types that it is actually willing to accept, and this repertoire of types that it is actually willing to accept, and this
is generally not true on typical desktop web browsers (maybe some is generally not true on typical desktop web browsers (maybe some
phones might have such a limitation). phones might have such a limitation).
The point about changing the 406 requirement so that it matches The point about changing the 406 requirement so that it matches
reality should also be added to the issue. reality should also be added to the issue.
I.42. i54-definition-of-1xx-warn-codes I.50. i54-definition-of-1xx-warn-codes
In Section 13.1.2: In Section 13.1.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54>
a-travis@microsoft.com (2006-12-22): See a-travis@microsoft.com (2006-12-22): See
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54>. <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54>.
I.43. i29-age-calculation I.51. i29-age-calculation
In Section 13.2.3: In Section 13.2.3:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i29> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i29>
rousskov@measurement-factory.com (2002-08-30): rousskov@measurement-factory.com (2002-08-30):
RFC 2616 says: RFC 2616 says:
skipping to change at page 226, line 29 skipping to change at page 225, line 5
current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value) current_age = max(now - date_value, age_value + now - request_time) = = now - min(date_value, request_time - age_value)
It even has a clear physical meaning -- the min() part is the It even has a clear physical meaning -- the min() part is the
conservative estimate of object creation time. conservative estimate of object creation time.
julian.reschke@gmx.de (2007-10-06): Discussed during the Prague julian.reschke@gmx.de (2007-10-06): Discussed during the Prague
meeting, see meeting, see
<http://www.w3.org/2007/03/18-rfc2616-minutes.html#action11>. <http://www.w3.org/2007/03/18-rfc2616-minutes.html#action11>.
I.44. i71-examples-for-etag-matching I.52. i71-examples-for-etag-matching
In Section 13.3.3: In Section 13.3.3:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i71> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i71>
julian.reschke@greenbytes.de (2006-12-02): Add examples for weak and julian.reschke@greenbytes.de (2006-12-02): Add examples for weak and
strong matching. strong matching.
julian.reschke@greenbytes.de (2007-06-07): Backed out example, julian.reschke@greenbytes.de (2007-06-07): Backed out example,
because it's controversial. We need to answer the question: "Are because it's controversial. We need to answer the question: "Are
there circumstances where a server will weakly match the etags "1" there circumstances where a server will weakly match the etags "1"
and W/"1"? and W/"1"?
julian.reschke@greenbytes.de (2007-07-17): Re-added example table for julian.reschke@greenbytes.de (2007-07-17): Re-added example table for
further discussion. further discussion.
I.45. i60-13.5.1-and-13.5.2 I.53. i60-13.5.1-and-13.5.2
In Section 13.5: In Section 13.5:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60>
mnot@yahoo-inc.com (2007-03-30): 13.5.1 and 13.5.2 describe how mnot@yahoo-inc.com (2007-03-30): 13.5.1 and 13.5.2 describe how
proxies should handle headers, even though it's in a section entitled proxies should handle headers, even though it's in a section entitled
"Caching in HTTP." People have a hard time finding them. Would it "Caching in HTTP." People have a hard time finding them. Would it
be helpful to try to separate out the purely intermediary-related be helpful to try to separate out the purely intermediary-related
material from section 13 to a more appropriate place (e.g., section material from section 13 to a more appropriate place (e.g., section
8, or a new section)? 8, or a new section)?
I.46. i53-allow-is-not-in-13.5.2 I.54. i53-allow-is-not-in-13.5.2
In Section 13.5.2: In Section 13.5.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53>
a-travis@microsoft.com (2006-12-20): a-travis@microsoft.com (2006-12-20):
Section 14.7 states: Section 14.7 states:
skipping to change at page 227, line 48 skipping to change at page 226, line 18
fix should be -- remove 13.5.2 and push the (not-)modifiable fix should be -- remove 13.5.2 and push the (not-)modifiable
information in the definition of the respective headers, or to information in the definition of the respective headers, or to
maintain 13.5.2 in parallel with all of the header definitions, or to maintain 13.5.2 in parallel with all of the header definitions, or to
push all the information out of the header definitions into 13.5.2. push all the information out of the header definitions into 13.5.2.
The easy fix for now would be to just make a mention of Allow in The easy fix for now would be to just make a mention of Allow in
13.5.2. 13.5.2.
Additionally, Server should also be included. Additionally, Server should also be included.
I.47. i37-vary-and-non-existant-headers I.55. i37-vary-and-non-existant-headers
In Section 13.6: In Section 13.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i37> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i37>
jamie@shareable.org (2004-02-23): (See jamie@shareable.org (2004-02-23): (See
<http://www.w3.org/mid/20040223204041.GA32719@mail.shareable.org>). <http://www.w3.org/mid/20040223204041.GA32719@mail.shareable.org>).
I.48. i38-mismatched-vary I.56. i38-mismatched-vary
In Section 13.6: In Section 13.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i38> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i38>
hno@squid-cache.org (2006-10-20): hno@squid-cache.org (2006-10-20):
When one cached variant has one Vary header, and then another variant When one cached variant has one Vary header, and then another variant
is received with a different Vary header. Lets say the first has is received with a different Vary header. Lets say the first has
Vary: Accept-Language Vary: Accept-Language
and the second and the second
Vary: Accept-Encoding Vary: Accept-Encoding
what is the appropriate behaviour for a cache? what is the appropriate behaviour for a cache?
I.49. i39-etag-uniqueness I.57. i39-etag-uniqueness
In Section 13.6: In Section 13.6:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i39> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i39>
henrik@henriknordstrom.net (2006-10-19): From experience I think it's henrik@henriknordstrom.net (2006-10-19): From experience I think it's
also worthwhile to further stress the importance of ETag uniqueness also worthwhile to further stress the importance of ETag uniqueness
among variants of a URI. Very few implementations get this part among variants of a URI. Very few implementations get this part
correct. In fact most major web servers have issues here... correct. In fact most major web servers have issues here...
Some even strongly believe that entities with different Content- Some even strongly believe that entities with different Content-
Encoding is the same entity, arguing that since most encoding (at Encoding is the same entity, arguing that since most encoding (at
least the standardized ones) can be converted to the same identity least the standardized ones) can be converted to the same identity
encoding so they are in fact the same entity and should have the same encoding so they are in fact the same entity and should have the same
strong ETag. strong ETag.
I.50. i23-no-store-invalidation I.58. i23-no-store-invalidation
In Section 14.9.2: In Section 14.9.2:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i23> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i23>
rousskov@measurement-factory.com (2005-07-26): Responses to HTTP rousskov@measurement-factory.com (2005-07-26): Responses to HTTP
requests with "Cache-control: no-store" are not cachable. Recently, requests with "Cache-control: no-store" are not cachable. Recently,
we came across a cache that does not cache responses to no-store we came across a cache that does not cache responses to no-store
skipping to change at page 229, line 31 skipping to change at page 228, line 5
5. Client requests the same entity A again, without using no-store. 5. Client requests the same entity A again, without using no-store.
6. Cache serves the "old" entity A cached in step #2 above. 6. Cache serves the "old" entity A cached in step #2 above.
Does the cache violate the intent of RFC 2616 in step #6? If yes, Does the cache violate the intent of RFC 2616 in step #6? If yes,
should that intent be made explicit (I cannot find any explicit rules should that intent be made explicit (I cannot find any explicit rules
prohibiting the above behavior)? prohibiting the above behavior)?
If no, should the cache check that response in step #4 does not If no, should the cache check that response in step #4 does not
indicate that cached entity A is stale? I cannot find explicit rules indicate that cached entity A is stale? I cannot find explicit rules
requiring that, but we do have similar rules about 304 and HEAD requiring that, but we do have similar rules about 304 and HEAD
responses invalidating older cached entities. responses invalidating older cached entities.
I.51. i80-content-location-is-not-special I.59. 14.11-content-encoding_response_vs_message
In Section 14.11:
Type: change
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/
0269.html>
a-travis@microsoft.com (2006-12-14):
The third paragraph of section 14.11 (page 118) reads as follows:
"If the content-coding of an entity is not "identity", then the
response MUST include a Content-Encoding entity-header (section
14.11) that lists the non-identity content-coding(s) used."
Aside from being self-referential, the phrasing can be interpreted in
at least two ways, neither of which is probably the _intended_
meaning:
* If the content-coding of an entity [in the request] is not
"identity", then the response MUST include a Content-Encoding entity
header [...].
* If the content-coding of an entity [at the URI requested by the
client] is not "identity", then the response MUST include a Content-
Encoding entity header [...].
Because the requirement specifically applies to "the response", both
of these interpretations place a burden only on the server. The
client is not required to declare any Content-Encoding values on its
request message. However, the paragraph afterward (as well as the
BNF for Request; Section 5, P35) implies that clients are allowed to
send content-encoded messages to the server (because the server
SHOULD respond with a 415 status). Thus, unless it is truly the case
that clients are NOT required to explicitly identify content-
encodings, I would suggest the following modification:
"If the content-encoding of an entity is not "identity", then the
<del>response</del><ins>HTTP-message containing the entity</ins> MUST
include a Content-Encoding entity-header <del>(section 14.11)</del>
that lists the non-identity content-coding(s) used."
-- Travis
(See also <http://lists.w3.org/Archives/Public/ietf-http-wg/
2006OctDec/0269.html>)
I.60. i80-content-location-is-not-special
In Section 14.14: In Section 14.14:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80>
julian.reschke@greenbytes.de (2007-07-31): julian.reschke@greenbytes.de (2007-07-31):
The definition of Content-Location ends with: The definition of Content-Location ends with:
skipping to change at page 230, line 12 skipping to change at page 229, line 35
1) It seems that the meaning of Content-Location is universal for 1) It seems that the meaning of Content-Location is universal for
messages that carry an entity; I'm not sure what's the point in messages that carry an entity; I'm not sure what's the point in
claiming that meaning does not apply to PUT or POST. claiming that meaning does not apply to PUT or POST.
2) Also: every time a limited set of methods is mentioned somewhere 2) Also: every time a limited set of methods is mentioned somewhere
it feels like problematic spec writing. What makes PUT or POST so it feels like problematic spec writing. What makes PUT or POST so
special in comparison to other methods? Maybe that they are the only special in comparison to other methods? Maybe that they are the only
methods in RFC2616 that carry request entity bodies? In which case methods in RFC2616 that carry request entity bodies? In which case
the statement should be rephrased accordingly... the statement should be rephrased accordingly...
I.52. i22-etag-and-other-metadata-in-status-messages I.61. i22-etag-and-other-metadata-in-status-messages
In Section 14.19: In Section 14.19:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i22>
julian.reschke@gmx.de (2006-08-09): (See proposal at <http:// julian.reschke@gmx.de (2006-08-09): (See proposal at <http://
greenbytes.de/tech/webdav/#draft-reschke-http-etag-on-write>). greenbytes.de/tech/webdav/#draft-reschke-http-etag-on-write>).
I.53. i61-redirection-vs-location I.62. i92-empty-host-headers
In Section 14.23:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i92>
derhoermi@gmx.net (2007-11-21):
The specification states "If the requested URI does not include an
Internet host name for the service being requested, then the Host
header field MUST be given with an empty value" but the grammar does
not seem to allow this.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
should be changed into
Host = "Host" ":" [ host [ ":" port ] ] ; Section 3.2.2
I.63. i89-if-dash-and-entities
In Section 14.24:
Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i89>
henrik@henriknordstrom.net (2007-10-31):
The description of If(-None)-Match still refers to entity when it
talks about ETag, should refer to entity tag, variant and requested
variant.
Sections:
14.24 If-Match
14.26 If-None-Match
Problematic text (same in both sections):
"A client that has one or more entities previously obtained from
the resource can verify that one of those entities is current by
including a list of their associated entity tags in the"
and later
"or if "*" is given and any current entity exists for that
resource"
Problem:
ETag values is associated with variants, not entities. There is
other uses of these conditionals than just simple entity caching
which seems to be what the current text has in mind.
I.64. i61-redirection-vs-location
In Section 14.30: In Section 14.30:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61>
julian.reschke@gmx.de (2007-04-19): The first sentence could be julian.reschke@gmx.de (2007-04-19): The first sentence could be
understood as if the presence of the "Location" response header understood as if the presence of the "Location" response header
always implies some kind of redirection. See also <http:// always implies some kind of redirection. See also <http://
lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html>. lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html>.
I.54. fragment-combination I.65. fragment-combination
In Section 14.30: In Section 14.30:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43>
fielding@kiwi.ics.uci.edu (1999-08-06): See <http://lists.w3.org/ fielding@kiwi.ics.uci.edu (1999-08-06): See <http://lists.w3.org/
Archives/Public/ietf-http-wg-old/1999MayAug/0103>. Archives/Public/ietf-http-wg-old/1999MayAug/0103>.
skipping to change at page 231, line 4 skipping to change at page 231, line 34
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43>
fielding@kiwi.ics.uci.edu (1999-08-06): See <http://lists.w3.org/ fielding@kiwi.ics.uci.edu (1999-08-06): See <http://lists.w3.org/
Archives/Public/ietf-http-wg-old/1999MayAug/0103>. Archives/Public/ietf-http-wg-old/1999MayAug/0103>.
julian.reschke@greenbytes.de (2006-10-29): Part of this was fixed in julian.reschke@greenbytes.de (2006-10-29): Part of this was fixed in
draft 01 (see issue draft 01 (see issue
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i6>). This <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i6>). This
leaves us with the open issue: _At present, the behavior in the case leaves us with the open issue: _At present, the behavior in the case
where there was a fragment with the original URI, e.g.: where there was a fragment with the original URI, e.g.:
http://host1.example.com/resource1#fragment1 where /resource1 http://host1.example.com/resource1#fragment1 where /resource1
redirects to http://host2.example.com/resource2#fragment2 is redirects to http://host2.example.com/resource2#fragment2 is
'fragment1' discarded? Do you find fragment2 and then find fragment1 'fragment1' discarded? Do you find fragment2 and then find fragment1
within it? We don't have fragment combination rules._. within it? We don't have fragment combination rules._.
I.55. i41-security-considerations I.66. i41-security-considerations
In Section 15: In Section 15:
Type: change Type: change
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i41> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i41>
What work needs to be done to the Security Considerations section of What work needs to be done to the Security Considerations section of
RFC2616 to allow publication of a revision? E.g., does HTTP need to RFC2616 to allow publication of a revision? E.g., does HTTP need to
specify a Mandatory To Implement mechanism? specify a Mandatory To Implement mechanism?
I.56. i55-updating-to-rfc4288 I.67. i55-updating-to-rfc4288
In Section A: In Section A:
Type: edit Type: edit
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i55> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i55>
julian.reschke@gmx.de (2007-01-05): The update from RFC2048 to julian.reschke@gmx.de (2007-01-05): The update from RFC2048 to
RFC4288 requires minor modifications for the media type registrations RFC4288 requires minor modifications for the media type registrations
for "message/http", "application/http" and "multipart/byteranges". for "message/http", "application/http" and "multipart/byteranges".
I.68. link-header
In Section F.3:
Type: change
<http://www.w3.org/mid/46DB0738.7090500@gmx.de>
julian.reschke@gmx.de (2007-09-02):
The current editor's draft of HTML5 requires User-Agents to respect
the HTTP Link header (as specified in RFC2068, and dropped from
RFC2616) -- see <http://www.w3.org/html/wg/html5/#the-link>:
"Some versions of HTTP defined a Link: header, to be processed
like a series of link elements. When processing links, those must
be taken into consideration as well. For the purposes of
ordering, links defined by HTTP headers must be assumed to come
before any links in the document, in the order that they were
given in the HTTP entity header. Relative URIs in these headers
must be resolved according to the rules given in HTTP, not
relative to base URIs set by the document (e.g. using a base
element or xml:base attributes). [RFC2616] [RFC2068]" --
http://www.w3.org/html/wg/html5/#the-link
So either this is just wishful thinking, or implementation support
for the Link header has indeed improved lately (I'll guess in FF and
Opera). In the latter case, we may want to re-add it in RFC2616bis.
Index Index
1 1
100 Continue (status code) 67 100 Continue (status code) 67
101 Switching Protocols (status code) 67 101 Switching Protocols (status code) 67
110 Response is stale (warn code) 160 110 Response is stale (warn code) 160
111 Revalidation failed (warn code) 160 111 Revalidation failed (warn code) 160
112 Disconnected operation (warn code) 160 112 Disconnected operation (warn code) 161
113 Heuristic expiration (warn code) 160 113 Heuristic expiration (warn code) 161
199 Miscellaneous warning (warn code) 160 199 Miscellaneous warning (warn code) 161
2 2
200 OK (status code) 68 200 OK (status code) 68
201 Created (status code) 68 201 Created (status code) 68
202 Accepted (status code) 68 202 Accepted (status code) 68
203 Non-Authoritative Information (status code) 69 203 Non-Authoritative Information (status code) 69
204 No Content (status code) 69 204 No Content (status code) 69
205 Reset Content (status code) 69 205 Reset Content (status code) 69
206 Partial Content (status code) 70 206 Partial Content (status code) 70
214 Transformation applied (warn code) 161 214 Transformation applied (warn code) 161
299 Miscellaneous persistent warning (warn code) 161 299 Miscellaneous persistent warning (warn code) 161
3 3
300 Multiple Choices (status code) 71 300 Multiple Choices (status code) 71
301 Moved Permanently (status code) 71 301 Moved Permanently (status code) 71
302 Found (status code) 72 302 Found (status code) 72
303 See Other (status code) 72 303 See Other (status code) 72
304 Not Modified (status code) 73 304 Not Modified (status code) 73
305 Use Proxy (status code) 73 305 Use Proxy (status code) 74
306 (Unused) (status code) 74 306 (Unused) (status code) 74
307 Temporary Redirect (status code) 74 307 Temporary Redirect (status code) 74
4 4
400 Bad Request (status code) 75 400 Bad Request (status code) 75
401 Unauthorized (status code) 75 401 Unauthorized (status code) 75
402 Payment Required (status code) 75 402 Payment Required (status code) 75
403 Forbidden (status code) 75 403 Forbidden (status code) 75
404 Not Found (status code) 75 404 Not Found (status code) 76
405 Method Not Allowed (status code) 76 405 Method Not Allowed (status code) 76
406 Not Acceptable (status code) 76 406 Not Acceptable (status code) 76
407 Proxy Authentication Required (status code) 76 407 Proxy Authentication Required (status code) 77
408 Request Timeout (status code) 77 408 Request Timeout (status code) 77
409 Conflict (status code) 77 409 Conflict (status code) 77
410 Gone (status code) 77 410 Gone (status code) 77
411 Length Required (status code) 78 411 Length Required (status code) 78
412 Precondition Failed (status code) 78 412 Precondition Failed (status code) 78
413 Request Entity Too Large (status code) 78 413 Request Entity Too Large (status code) 78
414 Request-URI Too Long (status code) 78 414 Request-URI Too Long (status code) 78
415 Unsupported Media Type (status code) 78 415 Unsupported Media Type (status code) 79
416 Requested Range Not Satisfiable (status code) 78 416 Requested Range Not Satisfiable (status code) 79
417 Expectation Failed (status code) 79 417 Expectation Failed (status code) 79
5 5
500 Internal Server Error (status code) 79 500 Internal Server Error (status code) 79
501 Not Implemented (status code) 79 501 Not Implemented (status code) 79
502 Bad Gateway (status code) 79 502 Bad Gateway (status code) 80
503 Service Unavailable (status code) 80 503 Service Unavailable (status code) 80
504 Gateway Timeout (status code) 80 504 Gateway Timeout (status code) 80
505 HTTP Version Not Supported (status code) 80 505 HTTP Version Not Supported (status code) 80
A A
Accept header 111 Accept header 111
Accept-Charset header 113 Accept-Charset header 113
Accept-Encoding header 113 Accept-Encoding header 113
Accept-Language header 115 Accept-Language header 115
Accept-Ranges header 116 Accept-Ranges header 116
age 16 age 16
Age header 116 Age header 116
Allow header 117 Allow header 117
Alternates header 189 Alternates header 191
application/http Media Type 176 application/http Media Type 177
Authorization header 117 Authorization header 117
C C
cache 15 cache 15
Cache Directives Cache Directives
max-age 123, 125 max-age 123, 125
max-stale 123 max-stale 123
min-fresh 123 min-fresh 123
must-revalidate 125 must-revalidate 125
no-cache 121 no-cache 121
skipping to change at page 234, line 9 skipping to change at page 235, line 9
compress (content coding) 30 compress (content coding) 30
CONNECT method 66 CONNECT method 66
connection 13 connection 13
Connection header 128 Connection header 128
Content Codings 30 Content Codings 30
compress 30 compress 30
deflate 30 deflate 30
gzip 30 gzip 30
identity 30 identity 30
content negotiation 14 content negotiation 14
Content-Base header 189 Content-Base header 191
Content-Disposition header 184 Content-Disposition header 186
Content-Encoding header 129 Content-Encoding header 129
Content-Language header 129 Content-Language header 130
Content-Length header 130 Content-Length header 130
Content-Location header 131 Content-Location header 131
Content-MD5 header 132 Content-MD5 header 132
Content-Range header 133 Content-Range header 133
Content-Type header 135 Content-Type header 135
Content-Version header 189 Content-Version header 191
D D
Date header 135 Date header 136
deflate (content coding) 30 deflate (content coding) 30
DELETE method 66 DELETE method 66
Derived-From header 189 Derived-From header 191
downstream 17 downstream 17
E E
entity 13 entity 13
ETag header 137 ETag header 137
Expect header 137 Expect header 137
Expires header 138 Expires header 138
explicit expiration time 16 explicit expiration time 16
F F
first-hand 15 first-hand 15
fresh 16 fresh 16
freshness lifetime 16 freshness lifetime 16
From header 139 From header 139
G G
gateway 15 gateway 15
GET method 63 GET method 63
Grammar Grammar
absoluteURI 25
Accept 111 Accept 111
Accept-Charset 113 Accept-Charset 113
Accept-Encoding 113 Accept-Encoding 113
accept-extension 111 accept-extension 111
Accept-Language 115 Accept-Language 115
accept-params 111 accept-params 111
Accept-Ranges 116 Accept-Ranges 116
acceptable-ranges 116 acceptable-ranges 116
Age 117 Age 117
age-value 117 age-value 117
Allow 117 Allow 117
ALPHA 22 ALPHA 22
asctime-date 28 asctime-date 28
attribute 31 attribute 31
authority 25
Authorization 118 Authorization 118
byte-content-range-spec 133 byte-content-range-spec 133
byte-range-resp-spec 133 byte-range-resp-spec 133
byte-range-set 149 byte-range-set 149
byte-range-spec 149 byte-range-spec 149
byte-ranges-specifier 149 byte-ranges-specifier 149
bytes-unit 37 bytes-unit 37
Cache-Control 119 Cache-Control 119
cache-directive 119 cache-directive 119
cache-extension 119 cache-extension 119
skipping to change at page 235, line 36 skipping to change at page 236, line 38
chunk-ext-name 32 chunk-ext-name 32
chunk-ext-val 32 chunk-ext-val 32
chunk-extension 32 chunk-extension 32
chunk-size 32 chunk-size 32
Chunked-Body 32 Chunked-Body 32
codings 113 codings 113
comment 23 comment 23
Connection 128 Connection 128
connection-token 128 connection-token 128
content-coding 30 content-coding 30
content-disposition 184 content-disposition 186
Content-Encoding 129 Content-Encoding 129
Content-Language 130 Content-Language 130
Content-Length 130 Content-Length 130
Content-Location 131 Content-Location 131
Content-MD5 132 Content-MD5 132
Content-Range 133 Content-Range 133
content-range-spec 133 content-range-spec 133
Content-Type 135 Content-Type 135
CR 22 CR 22
CRLF 22 CRLF 22
ctext 23 ctext 23
CTL 22 CTL 22
Date 135 Date 136
date1 28 date1 28
date2 28 date2 28
date3 28 date3 28
delta-seconds 28 delta-seconds 28
DIGIT 22 DIGIT 22
disp-extension-parm 184 disp-extension-parm 186
disp-extension-token 184 disp-extension-token 186
disposition-parm 184 disposition-parm 186
disposition-type 184 disposition-type 186
DQUOTE 22
entity-body 52 entity-body 52
entity-header 52 entity-header 52
entity-tag 37 entity-tag 37
ETag 137 ETag 137
Expect 137 Expect 137
expect-params 137 expect-params 137
expectation 137 expectation 137
expectation-extension 137 expectation-extension 137
Expires 138 Expires 138
extension-code 50 extension-code 50
extension-header 52 extension-header 52
extension-method 44 extension-method 44
extension-pragma 147 extension-pragma 148
field-content 40 field-content 40
field-name 40 field-name 40
field-value 40 field-value 40
filename-parm 184 filename-parm 186
first-byte-pos 149 first-byte-pos 149
From 139 From 139
general-header 43 general-header 43
generic-message 39 generic-message 39
HEX 23 HEX 23
Host 140 Host 140
HT 22 HT 22
HTTP-date 28 HTTP-date 28
HTTP-message 39 HTTP-message 39
http-URL 26
HTTP-Version 24 HTTP-Version 24
http_URL 26 http_URL 26
If-Match 140 If-Match 140
If-Modified-Since 141 If-Modified-Since 142
If-None-Match 143 If-None-Match 143
If-Range 144 If-Range 144
If-Unmodified-Since 145 If-Unmodified-Since 145
instance-length 133 instance-length 133
language-range 115 language-range 115
language-tag 36 Language-Tag 36
last-byte-pos 149 last-byte-pos 149
last-chunk 32 last-chunk 32
Last-Modified 145 Last-Modified 145
LF 22 LF 22
LOALPHA 22 LOALPHA 22
Location 146 Location 146
LWS 22 LWS 22
Max-Forwards 147 Max-Forwards 147
md5-digest 132 md5-digest 132
media-range 111 media-range 111
media-type 33 media-type 33
message-body 40 message-body 40
message-header 40 message-header 40
Method 44 Method 44
MIME-Version 181 MIME-Version 183
month 28 month 28
OCTET 22 OCTET 22
opaque-tag 37 opaque-tag 37
other-range-unit 37 other-range-unit 37
parameter 31 parameter 31
Pragma 147 path-absolute 25
pragma-directive 147 port 25
primary-tag 36 Pragma 148
pragma-directive 148
product 35 product 35
product-version 35 product-version 35
protocol-name 157 protocol-name 158
protocol-version 157 protocol-version 158
Proxy-Authenticate 148 Proxy-Authenticate 148
Proxy-Authorization 148 Proxy-Authorization 149
pseudonym 157 pseudonym 158
qdtext 23 qdtext 23
query 25
quoted-pair 23 quoted-pair 23
quoted-string 23 quoted-string 23
qvalue 36 qvalue 36
Range 151 Range 151
range-unit 37 range-unit 37
ranges-specifier 149 ranges-specifier 149
Reason-Phrase 50 Reason-Phrase 50
received-by 157 received-by 158
received-protocol 157 received-protocol 158
Referer 151 Referer 152
relativeURI 25
Request 44 Request 44
request-header 47 request-header 47
Request-Line 44 Request-Line 44
Request-URI 45 Request-URI 45
Response 48 Response 48
response-header 51 response-header 51
Retry-After 152 Retry-After 152
rfc850-date 28 rfc850-date 28
rfc1123-date 28 rfc1123-date 28
separators 23 separators 23
Server 152 Server 153
SP 22 SP 22
start-line 39 start-line 39
Status-Code 50 Status-Code 50
Status-Line 48 Status-Line 48
subtag 36
subtype 33 subtype 33
suffix-byte-range-spec 150 suffix-byte-range-spec 150
suffix-length 150 suffix-length 150
t-codings 153 t-codings 153
tchar 23
TE 153 TE 153
TEXT 22 TEXT 22
time 28 time 28
token 23 token 23
Trailer 154 Trailer 154
trailer 32 trailer 32
trailer-part 32
transfer-coding 31 transfer-coding 31
Transfer-Encoding 154 Transfer-Encoding 155
transfer-extension 31 transfer-extension 31
type 33 type 33
UPALPHA 22 UPALPHA 22
Upgrade 155 Upgrade 155
uri-host 25
User-Agent 156 User-Agent 156
value 31 value 31
Vary 156 Vary 157
Via 157 Via 158
warn-agent 159 warn-agent 159
warn-code 159 warn-code 159
warn-date 159 warn-date 159
warn-text 159 warn-text 159
Warning 159 Warning 159
warning-value 159 warning-value 159
weak 37 weak 37
weekday 28 weekday 28
wkday 28 wkday 28
WWW-Authenticate 161 WWW-Authenticate 162
gzip (content coding) 30 gzip (content coding) 30
H H
HEAD method 63 HEAD method 63
Headers Headers
Accept 111 Accept 111
Accept-Charset 113 Accept-Charset 113
Accept-Encoding 113 Accept-Encoding 113
Accept-Language 115 Accept-Language 115
Accept-Ranges 116 Accept-Ranges 116
Age 116 Age 116
Allow 117 Allow 117
Alternate 189 Alternate 191
Authorization 117 Authorization 117
Cache-Control 118 Cache-Control 118
Connection 128 Connection 128
Content-Base 189 Content-Base 191
Content-Disposition 184 Content-Disposition 186
Content-Encoding 129 Content-Encoding 129
Content-Language 129 Content-Language 130
Content-Length 130 Content-Length 130
Content-Location 131 Content-Location 131
Content-MD5 132 Content-MD5 132
Content-Range 133 Content-Range 133
Content-Type 135 Content-Type 135
Content-Version 189 Content-Version 191
Date 135 Date 136
Derived-From 189 Derived-From 191
ETag 137 ETag 137
Expect 137 Expect 137
Expires 138 Expires 138
From 139 From 139
Host 139 Host 140
If-Match 140 If-Match 140
If-Modified-Since 141 If-Modified-Since 141
If-None-Match 143 If-None-Match 143
If-Range 144 If-Range 144
If-Unmodified-Since 145 If-Unmodified-Since 145
Last-Modified 145 Last-Modified 145
Link 189 Link 191
Location 146 Location 146
Max-Forwards 147 Max-Forwards 147
Pragma 147 Pragma 147
Proxy-Authenticate 148 Proxy-Authenticate 148
Proxy-Authorization 148 Proxy-Authorization 149
Public 189 Public 191
Range 149 Range 149
Referer 151 Referer 152
Retry-After 152 Retry-After 152
Server 152 Server 152
TE 153 TE 153
Trailer 154 Trailer 154
Transfer-Encoding 154 Transfer-Encoding 155
Upgrade 155 Upgrade 155
URI 189 URI 191
User-Agent 156 User-Agent 156
Vary 156 Vary 157
Via 157 Via 157
Warning 159 Warning 159
WWW-Authenticate 161 WWW-Authenticate 162
heuristic expiration time 16 heuristic expiration time 16
Host header 139 Host header 140
I I
identity (content coding) 30 identity (content coding) 30
If-Match header 140 If-Match header 140
If-Modified-Since header 141 If-Modified-Since header 141
If-None-Match header 143 If-None-Match header 143
If-Range header 144 If-Range header 144
If-Unmodified-Since header 145 If-Unmodified-Since header 145
inbound 17 inbound 17
L L
Last-Modified header 145 Last-Modified header 145
Link header 189 Link header 191
LINK method 189 LINK method 191
Location header 146 Location header 146
M M
max-age max-age
Cache Directive 123, 125 Cache Directive 123, 125
Max-Forwards header 147 Max-Forwards header 147
max-stale max-stale
Cache Directive 123 Cache Directive 123
Media Type Media Type
application/http 176 application/http 177
message/http 176 message/http 177
multipart/byteranges 178 multipart/byteranges 180
multipart/x-byteranges 179 multipart/x-byteranges 181
message 13 message 13
message/http Media Type 176 message/http Media Type 177
Methods Methods
CONNECT 66 CONNECT 66
DELETE 66 DELETE 66
GET 63 GET 63
HEAD 63 HEAD 63
LINK 189 LINK 191
OPTIONS 62 OPTIONS 62
PATCH 189 PATCH 191
POST 64 POST 64
PUT 64 PUT 64
TRACE 66 TRACE 66
UNLINK 189 UNLINK 191
min-fresh min-fresh
Cache Directive 123 Cache Directive 123
multipart/byteranges Media Type 178 multipart/byteranges Media Type 180
multipart/x-byteranges Media Type 179 multipart/x-byteranges Media Type 181
must-revalidate must-revalidate
Cache Directive 125 Cache Directive 125
N N
no-cache no-cache
Cache Directive 121 Cache Directive 121
no-store no-store
Cache Directive 121 Cache Directive 121
no-transform no-transform
Cache Directive 126 Cache Directive 126
O O
only-if-cached only-if-cached
Cache Directive 125 Cache Directive 125
OPTIONS method 62 OPTIONS method 62
origin server 14 origin server 14
outbound 17 outbound 17
P P
PATCH method 189 PATCH method 191
POST method 64 POST method 64
Pragma header 147 Pragma header 147
private private
Cache Directive 120 Cache Directive 120
proxy 14 proxy 14
Proxy-Authenticate header 148 Proxy-Authenticate header 148
Proxy-Authorization header 148 Proxy-Authorization header 149
proxy-revalidate proxy-revalidate
Cache Directive 126 Cache Directive 126
public public
Cache Directive 120 Cache Directive 120
Public header 189 Public header 191
PUT method 64 PUT method 64
R R
Range header 149 Range header 149
Referer header 151 Referer header 152
representation 13 representation 13
request 13 request 13
resource 13 resource 13
response 13 response 13
Retry-After header 152 Retry-After header 152
S S
s-maxage s-maxage
Cache Directive 122 Cache Directive 122
semantically transparent 16 semantically transparent 16
skipping to change at page 242, line 17 skipping to change at page 243, line 27
202 Accepted 68 202 Accepted 68
203 Non-Authoritative Information 69 203 Non-Authoritative Information 69
204 No Content 69 204 No Content 69
205 Reset Content 69 205 Reset Content 69
206 Partial Content 70 206 Partial Content 70
300 Multiple Choices 71 300 Multiple Choices 71
301 Moved Permanently 71 301 Moved Permanently 71
302 Found 72 302 Found 72
303 See Other 72 303 See Other 72
304 Not Modified 73 304 Not Modified 73
305 Use Proxy 73 305 Use Proxy 74
306 (Unused) 74 306 (Unused) 74
307 Temporary Redirect 74 307 Temporary Redirect 74
400 Bad Request 75 400 Bad Request 75
401 Unauthorized 75 401 Unauthorized 75
402 Payment Required 75 402 Payment Required 75
403 Forbidden 75 403 Forbidden 75
404 Not Found 75 404 Not Found 76
405 Method Not Allowed 76 405 Method Not Allowed 76
406 Not Acceptable 76 406 Not Acceptable 76
407 Proxy Authentication Required 76 407 Proxy Authentication Required 77
408 Request Timeout 77 408 Request Timeout 77
409 Conflict 77 409 Conflict 77
410 Gone 77 410 Gone 77
411 Length Required 78 411 Length Required 78
412 Precondition Failed 78 412 Precondition Failed 78
413 Request Entity Too Large 78 413 Request Entity Too Large 78
414 Request-URI Too Long 78 414 Request-URI Too Long 78
415 Unsupported Media Type 78 415 Unsupported Media Type 79
416 Requested Range Not Satisfiable 78 416 Requested Range Not Satisfiable 79
417 Expectation Failed 79 417 Expectation Failed 79
500 Internal Server Error 79 500 Internal Server Error 79
501 Not Implemented 79 501 Not Implemented 79
502 Bad Gateway 79 502 Bad Gateway 80
503 Service Unavailable 80 503 Service Unavailable 80
504 Gateway Timeout 80 504 Gateway Timeout 80
505 HTTP Version Not Supported 80 505 HTTP Version Not Supported 80
T T
TE header 153 TE header 153
TRACE method 66 TRACE method 66
Trailer header 154 Trailer header 154
Transfer-Encoding header 154 Transfer-Encoding header 155
tunnel 15 tunnel 15
U U
UNLINK method 189 UNLINK method 191
Upgrade header 155 Upgrade header 155
upstream 17 upstream 17
URI header 189 URI header 191
user agent 14 user agent 14
User-Agent header 156 User-Agent header 156
V V
validator 16 validator 16
variant 14 variant 14
Vary header 156 Vary header 157
Via header 157 Via header 157
W W
Warn Codes Warn Codes
110 Response is stale 160 110 Response is stale 160
111 Revalidation failed 160 111 Revalidation failed 160
112 Disconnected operation 160 112 Disconnected operation 161
113 Heuristic expiration 160 113 Heuristic expiration 161
199 Miscellaneous warning 160 199 Miscellaneous warning 161
214 Transformation applied 161 214 Transformation applied 161
299 Miscellaneous persistent warning 161 299 Miscellaneous persistent warning 161
Warning header 159 Warning header 159
WWW-Authenticate header 161 WWW-Authenticate header 162
Authors' Addresses Authors' Addresses
Roy T. Fielding Roy T. Fielding
Day Software Day Software
23 Corporate Plaza DR, Suite 215 23 Corporate Plaza DR, Suite 215
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com Email: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child One Laptop per Child
1 Cambridge Center, 10th floor 21 Oak Knoll Road
Cambridge, MA 02142 Carlisle, MA 01741
USA USA
Email: jg at laptop.org
URI: http://www.laptop.org/ URI: http://www.laptop.org/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org Email: JeffMogul@acm.org
 End of changes. 288 change blocks. 
871 lines changed or deleted 993 lines changed or added

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