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.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for systems. It is a generic, stateless, protocol which can be used for
skipping to change at page 5, line 31 skipping to change at page 5, line 31
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 28 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 28
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 28
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 29 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 29
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 29 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 29
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 30 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 30
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 31 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 31
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 32 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 32
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 33 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 33
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 34 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 35 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 35
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 35 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 36
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 36 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 36
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 37 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 37
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 37 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 37
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 38 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 38
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 38 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 38
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 40 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 40 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 40
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 40 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 40
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 41 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 41
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 42 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 42
skipping to change at page 6, line 51 skipping to change at page 6, line 51
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 70 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 70
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 70 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 70
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 71 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 71
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 71 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 71
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 72 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 72
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 72 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 72
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 73 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 73
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 73 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 73
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 74 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 75
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 75 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 75
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 75 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 75
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 76 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 76
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 76 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 76
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 76 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 76
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 76 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 76
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 76 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 77
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 77 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 77
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 77 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 77
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 77 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 78
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 78 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 78
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 78 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 78
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 78 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 78
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 79 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 79
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 79 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 79
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 79 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 79
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 79 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 79
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 79 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 80
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 79 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 80
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 80 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 80
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 80 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 80
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 80 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 80
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 80 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 81
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 81 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 81
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 81 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 81
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 81 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 81
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 82 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 82
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 83 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 83
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 83 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 83
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 84 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 84
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 85 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 85
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 86 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 86
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 86
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 87 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 87
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 88 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 88
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 89 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 89
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 89 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 89
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 90 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 90
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 90 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 90
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 91 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 91
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 91 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 91
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 91 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 91
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 92 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 92
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 94 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 94
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 95 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 95
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 96 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 96
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 96 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 96
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 97 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 97
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 97 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 97
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 98 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 98
13.3.4. Rules for When to Use Entity Tags and 13.3.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 100 Last-Modified Dates . . . . . . . . . . . . . . . . 101
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 102 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 102
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 102 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 103
13.5. Constructing Responses From Caches . . . . . . . . . . . 103 13.5. Constructing Responses From Caches . . . . . . . . . . . 103
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 103 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 104
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 104 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 104
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 105 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 106
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 106 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 107
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 107 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 107
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 108 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 108
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 108 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 109
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 109 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 109
13.10. Invalidation After Updates or Deletions . . . . . . . . 109 13.10. Invalidation After Updates or Deletions . . . . . . . . 109
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 110 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 110
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 110 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 111
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 111 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 111
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 112 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 112
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 114 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 114
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 116 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 116
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 117 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 117
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 117 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 117
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 118 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 118
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 119 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 119
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 121 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 121
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 122 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 122
14.9.3. Modifications of the Basic Expiration Mechanism . . 123 14.9.3. Modifications of the Basic Expiration Mechanism . . 123
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 125 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 125
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 127 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 127
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 128 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 128
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 129 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 129
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 130 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 130
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 130 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 131
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 131 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 131
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 132 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 132
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 133 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 133
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 134 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 134
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 136 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 136
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 136 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 137
14.18.1. Clockless Origin Server Operation . . . . . . . . . 137 14.18.1. Clockless Origin Server Operation . . . . . . . . . 138
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 138 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 138 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 139 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 139
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 140 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 140
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 140 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 141
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 141 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 141
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 142 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 142
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 145 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 145
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 146 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 146
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 146 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 146
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 147 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 147
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 148 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 148
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 148 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 148
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 149 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 149
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 149 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 150 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 150 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 150
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 151 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 152
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 152 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 153
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 153 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 153
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 153 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 155 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 155
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 155 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 156
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 156 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 156
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 157 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 157
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 158 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 158
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 160 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 160
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 162 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 163
15. Security Considerations . . . . . . . . . . . . . . . . . . . 163 15. Security Considerations . . . . . . . . . . . . . . . . . . . 164
15.1. Personal Information . . . . . . . . . . . . . . . . . . 163 15.1. Personal Information . . . . . . . . . . . . . . . . . . 164
15.1.1. Abuse of Server Log Information . . . . . . . . . . 163 15.1.1. Abuse of Server Log Information . . . . . . . . . . 164
15.1.2. Transfer of Sensitive Information . . . . . . . . . 163 15.1.2. Transfer of Sensitive Information . . . . . . . . . 164
15.1.3. Encoding Sensitive Information in URI's . . . . . . 164 15.1.3. Encoding Sensitive Information in URI's . . . . . . 165
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 165 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 166
15.2. Attacks Based On File and Path Names . . . . . . . . . . 165 15.2. Attacks Based On File and Path Names . . . . . . . . . . 166
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 166 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 167
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 166 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 167
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 167 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 168
15.6. Authentication Credentials and Idle Clients . . . . . . 167 15.6. Authentication Credentials and Idle Clients . . . . . . 168
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 167 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 168
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 168 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 169
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 169 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 170
16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 169 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 170
16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 170 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 171
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 172
17.1. References (to be classified) . . . . . . . . . . . . . 171 17.1. Normative References . . . . . . . . . . . . . . . . . . 172
17.2. Normative References . . . . . . . . . . . . . . . . . . 171 17.2. Informative References . . . . . . . . . . . . . . . . . 173
17.3. Informative References . . . . . . . . . . . . . . . . . 172
Appendix A. Internet Media Type message/http and Appendix A. Internet Media Type message/http and
application/http . . . . . . . . . . . . . . . . . . 177 application/http . . . . . . . . . . . . . . . . . . 178
Appendix B. Internet Media Type multipart/byteranges . . . . . . 179 Appendix B. Internet Media Type multipart/byteranges . . . . . . 181
Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 181 Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 183
Appendix D. Differences Between HTTP Entities and RFC 2045 Appendix D. Differences Between HTTP Entities and RFC 2045
Entities . . . . . . . . . . . . . . . . . . . . . . 182 Entities . . . . . . . . . . . . . . . . . . . . . . 184
D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 182 D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 184
D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 182 D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 184
D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 183 D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 185
D.4. Introduction of Content-Encoding . . . . . . . . . . . . 183 D.4. Introduction of Content-Encoding . . . . . . . . . . . . 185
D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 183 D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 185
D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 184 D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 186
D.7. MHTML and Line Length Limitations . . . . . . . . . . . 184 D.7. MHTML and Line Length Limitations . . . . . . . . . . . 186
Appendix E. Additional Features . . . . . . . . . . . . . . . . 185 Appendix E. Additional Features . . . . . . . . . . . . . . . . 187
E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 185 E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 187
Appendix F. Compatibility with Previous Versions . . . . . . . . 186 Appendix F. Compatibility with Previous Versions . . . . . . . . 188
F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 186 F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 188
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 . . . . . . . . . . . . . . . 186 Conserve IP Addresses . . . . . . . . . . . . . . . 188
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 187 F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 189
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 188 F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 190
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 190 F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 192
Appendix G. Change Log (to be removed by RFC Editor before Appendix G. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 192 publication) . . . . . . . . . . . . . . . . . . . . 194
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 192 G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 194
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 192 G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 194
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 192 G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 194
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 192 G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 194
G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 193 G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 195
G.6. Since draft-lafon-rfc2616bis-04 . . . . . . . . . . . . 196
Appendix H. Resolved issues (to be removed by RFC Editor Appendix H. Resolved issues (to be removed by RFC Editor
before publication) . . . . . . . . . . . . . . . . 195 before publication) . . . . . . . . . . . . . . . . 197
H.1. unneeded_references . . . . . . . . . . . . . . . . . . 195 H.1. abnf-dquote . . . . . . . . . . . . . . . . . . . . . . 197
H.2. consistent-reason-phrases . . . . . . . . . . . . . . . 195 H.2. abnf-rule-names . . . . . . . . . . . . . . . . . . . . 197
H.3. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 195 H.3. abnf-prose-cr . . . . . . . . . . . . . . . . . . . . . 197
H.4. abnf-edit . . . . . . . . . . . . . . . . . . . . . . . 196 H.4. abnf-case-insensitive . . . . . . . . . . . . . . . . . 197
H.5. rfc1766_normative . . . . . . . . . . . . . . . . . . . 196 H.5. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 198
H.6. i86-normative-up-to-date-references . . . . . . . . . . 196 H.6. abnf-chunk-data . . . . . . . . . . . . . . . . . . . . 199
H.7. i68-encoding-references-normative . . . . . . . . . . . 197 H.7. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 199
H.8. rfc2396_normative . . . . . . . . . . . . . . . . . . . 197
H.9. usascii_normative . . . . . . . . . . . . . . . . . . . 197
H.10. i65-informative-references . . . . . . . . . . . . . . . 197
H.11. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 198
H.12. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 199
H.13. i26-import-query-bnf . . . . . . . . . . . . . . . . . . 199
H.14. i47-inconsistency-in-date-format-explanation . . . . . . 200
H.15. media-reg . . . . . . . . . . . . . . . . . . . . . . . 200
H.16. i84-redundant-cross-references . . . . . . . . . . . . . 201
H.17. i87-typo-in-13.2.2 . . . . . . . . . . . . . . . . . . . 201
H.18. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 202
H.19. remove-CTE-abbrev . . . . . . . . . . . . . . . . . . . 203
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) . . . . . . . . . . . . . . . . . . . . 204 publication) . . . . . . . . . . . . . . . . . . . . 202
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 204 I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 202
I.2. i35-split-normative-and-informative-references . . . . . 204 I.2. i35-split-normative-and-informative-references . . . . . 202
I.3. i40-header-registration . . . . . . . . . . . . . . . . 204 I.3. i40-header-registration . . . . . . . . . . . . . . . . 202
I.4. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 204 I.4. need_iana_considerations . . . . . . . . . . . . . . . . 202
I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 204 I.5. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 203
I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 205 I.6. abnf-avoid-prose . . . . . . . . . . . . . . . . . . . . 203
I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 205 I.7. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 203
I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 205 I.8. rfc2822_normative . . . . . . . . . . . . . . . . . . . 203
I.9. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 206 I.9. rfc1737_informative_and_obsolete . . . . . . . . . . . . 204
I.10. i63-header-length-limit-with-encoded-words . . . . . . . 206 I.10. rfc2048_informative_and_obsolete . . . . . . . . . . . . 204
I.11. i74-character-encodings-for-headers . . . . . . . . . . 207 I.11. i34-updated-reference-for-uris . . . . . . . . . . . . . 204
I.12. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 207 I.12. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 204
I.13. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 208 I.13. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 205
I.14. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 208 I.14. i63-header-length-limit-with-encoded-words . . . . . . . 205
I.15. i58-what-identifies-an-http-resource . . . . . . . . . . 209 I.15. i74-character-encodings-for-headers . . . . . . . . . . 206
I.16. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 209 I.16. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 206
I.17. i73-clarification-of-the-term-deflate . . . . . . . . . 210 I.17. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 207
I.18. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 210 I.18. i58-what-identifies-an-http-resource . . . . . . . . . . 207
I.19. i20-default-charsets-for-text-media-types . . . . . . . 210 I.19. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 207
I.20. languagetag . . . . . . . . . . . . . . . . . . . . . . 212 I.20. i73-clarification-of-the-term-deflate . . . . . . . . . 208
I.21. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 212 I.21. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 208
I.22. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 213 I.22. i20-default-charsets-for-text-media-types . . . . . . . 209
I.23. i77-line-folding . . . . . . . . . . . . . . . . . . . . 213 I.23. i90-delimiting-messages-with-multipart-byteranges . . . 210
I.24. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 214 I.24. languagetag . . . . . . . . . . . . . . . . . . . . . . 211
I.25. i28-connection-closing . . . . . . . . . . . . . . . . . 214 I.25. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 211
I.26. i32-options-asterisk . . . . . . . . . . . . . . . . . . 214 I.26. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 212
I.27. i83-options-asterisk-and-proxies . . . . . . . . . . . . 215 I.27. i77-line-folding . . . . . . . . . . . . . . . . . . . . 212
I.28. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 216 I.28. i93-repeating-single-value-headers . . . . . . . . . . . 213
I.29. i57-status-code-and-reason-phrase . . . . . . . . . . . 216 I.29. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 213
I.30. i59-status-code-registry . . . . . . . . . . . . . . . . 217 I.30. i88-205-bodies . . . . . . . . . . . . . . . . . . . . . 214
I.31. i72-request-method-registry . . . . . . . . . . . . . . 217 I.31. i28-connection-closing . . . . . . . . . . . . . . . . . 214
I.32. i21-put-side-effects . . . . . . . . . . . . . . . . . . 217 I.32. uri_vs_request_uri . . . . . . . . . . . . . . . . . . . 214
I.33. i27-put-idempotency . . . . . . . . . . . . . . . . . . 218 I.33. i32-options-asterisk . . . . . . . . . . . . . . . . . . 214
I.34. i79-content-headers-vs-put . . . . . . . . . . . . . . . 219 I.34. i83-options-asterisk-and-proxies . . . . . . . . . . . . 215
I.35. i33-trace-security-considerations . . . . . . . . . . . 219 I.35. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 216
I.36. i69-clarify-requested-variant . . . . . . . . . . . . . 220 I.36. i57-status-code-and-reason-phrase . . . . . . . . . . . 216
I.37. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 221 I.37. i59-status-code-registry . . . . . . . . . . . . . . . . 217
I.38. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 223 I.38. i94-reason-phrase-bnf . . . . . . . . . . . . . . . . . 217
I.39. i78-relationship-between-401-authorization-and-www-authe 223 I.39. i91-duplicate-host-header-requirements . . . . . . . . . 217
I.40. i24-requiring-allow-in-405-responses . . . . . . . . . . 224 I.40. i72-request-method-registry . . . . . . . . . . . . . . 218
I.41. i81-content-negotiation-for-media-types . . . . . . . . 224 I.41. i21-put-side-effects . . . . . . . . . . . . . . . . . . 218
I.42. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 226 I.42. i27-put-idempotency . . . . . . . . . . . . . . . . . . 219
I.43. i29-age-calculation . . . . . . . . . . . . . . . . . . 226 I.43. i79-content-headers-vs-put . . . . . . . . . . . . . . . 220
I.44. i71-examples-for-etag-matching . . . . . . . . . . . . . 227 I.44. i33-trace-security-considerations . . . . . . . . . . . 220
I.45. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 228 I.45. i69-clarify-requested-variant . . . . . . . . . . . . . 221
I.46. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 228 I.46. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 221
I.47. i37-vary-and-non-existant-headers . . . . . . . . . . . 228 I.47. i78-relationship-between-401-authorization-and-www-authe 222
I.48. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 229 I.48. i24-requiring-allow-in-405-responses . . . . . . . . . . 222
I.49. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 229 I.49. i81-content-negotiation-for-media-types . . . . . . . . 223
I.50. i23-no-store-invalidation . . . . . . . . . . . . . . . 229 I.50. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 224
I.51. i80-content-location-is-not-special . . . . . . . . . . 230 I.51. i29-age-calculation . . . . . . . . . . . . . . . . . . 224
I.52. i22-etag-and-other-metadata-in-status-messages . . . . . 231 I.52. i71-examples-for-etag-matching . . . . . . . . . . . . . 226
I.53. i61-redirection-vs-location . . . . . . . . . . . . . . 231 I.53. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 226
I.54. fragment-combination . . . . . . . . . . . . . . . . . . 231 I.54. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 226
I.55. i41-security-considerations . . . . . . . . . . . . . . 232 I.55. i37-vary-and-non-existant-headers . . . . . . . . . . . 227
I.56. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 232 I.56. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 227
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 I.57. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 228
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245 I.58. i23-no-store-invalidation . . . . . . . . . . . . . . . 228
Intellectual Property and Copyright Statements . . . . . . . . . 248 I.59. 14.11-content-encoding_response_vs_message . . . . . . . 229
I.60. i80-content-location-is-not-special . . . . . . . . . . 230
I.61. i22-etag-and-other-metadata-in-status-messages . . . . . 230
I.62. i92-empty-host-headers . . . . . . . . . . . . . . . . . 230
I.63. i89-if-dash-and-entities . . . . . . . . . . . . . . . . 231
I.64. i61-redirection-vs-location . . . . . . . . . . . . . . 232
I.65. fragment-combination . . . . . . . . . . . . . . . . . . 232
I.66. i41-security-considerations . . . . . . . . . . . . . . 232
I.67. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 233
I.68. link-header . . . . . . . . . . . . . . . . . . . . . . 233
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 246
Intellectual Property and Copyright Statements . . . . . . . . . 249
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 23, line 19 skipping to change at page 23, 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 23, line 48 skipping to change at page 23, 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 25, line 24 skipping to change at page 25, 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 26, line 34 skipping to change at page 26, 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 29, line 5 skipping to change at page 29, 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 33, line 29 skipping to change at page 33, 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 34, line 36 skipping to change at page 34, 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 35, line 13 skipping to change at page 35, 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 37, line 37 skipping to change at page 37, 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
examples of tags which could be registered in future.) examples of tags which could be registered in future.)
3.11. Entity Tags 3.11. Entity Tags
Entity tags are used for comparing two or more entities from the same Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag requested resource. HTTP/1.1 uses entity tags in the ETag
(Section 14.19), If-Match (Section 14.24), If-None-Match (Section 14.19), If-Match (Section 14.24), If-None-Match
skipping to change at page 41, line 8 skipping to change at page 41, 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 46, line 14 skipping to change at page 46, 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 46, line 45 skipping to change at page 46, 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 51, line 49 skipping to change at page 51, 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 73, line 39 skipping to change at page 73, 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 86, line 7 skipping to change at page 86, 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 87, line 13 skipping to change at page 87, 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 99, line 23 skipping to change at page 99, 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 109, line 20 skipping to change at page 109, 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 116, line 28 skipping to change at page 116, 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 120, line 32 skipping to change at page 120, 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 131, line 6 skipping to change at page 131, 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 141, line 7 skipping to change at page 141, 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 158, line 45 skipping to change at page 159, line 12
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 160, line 25 skipping to change at page 160, 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 171, line 7 skipping to change at page 172, 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 172, line 36 skipping to change at page 173, 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 173, line 32 skipping to change at page 174, 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 177, line 14 skipping to change at page 178, 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 191, line 14 skipping to change at page 193, 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 195, line 5 skipping to change at page 196, 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 204, line 42 skipping to change at page 202, 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 206, line 39 skipping to change at page 205, 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 208, line 5 skipping to change at page 207, 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 210, line 37 skipping to change at page 208, 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 212, line 5 skipping to change at page 210, 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 213, line 5 skipping to change at page 212, 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 214, line 5 skipping to change at page 213, 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 215, line 13 skipping to change at page 215, 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 216, line 9 skipping to change at page 216, line 22
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 217, line 5 skipping to change at page 217, 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 218, line 32 skipping to change at page 219, line 24
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 219, line 11 skipping to change at page 220, 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 220, line 16 skipping to change at page 221, 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 221, line 5 skipping to change at page 221, 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 223, line 44 skipping to change at page 222, 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 224, line 39 skipping to change at page 223, 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 226, line 5 skipping to change at page 224, 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 227, line 29 skipping to change at page 226, 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 228, line 48 skipping to change at page 227, 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 230, line 31 skipping to change at page 229, 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 231, line 12 skipping to change at page 230, 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 232, line 4 skipping to change at page 232, 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) 68 100 Continue (status code) 68
101 Switching Protocols (status code) 68 101 Switching Protocols (status code) 68
110 Response is stale (warn code) 161 110 Response is stale (warn code) 161
111 Revalidation failed (warn code) 161 111 Revalidation failed (warn code) 161
112 Disconnected operation (warn code) 161 112 Disconnected operation (warn code) 162
113 Heuristic expiration (warn code) 161 113 Heuristic expiration (warn code) 162
199 Miscellaneous warning (warn code) 161 199 Miscellaneous warning (warn code) 162
2 2
200 OK (status code) 69 200 OK (status code) 69
201 Created (status code) 69 201 Created (status code) 69
202 Accepted (status code) 69 202 Accepted (status code) 69
203 Non-Authoritative Information (status code) 70 203 Non-Authoritative Information (status code) 70
204 No Content (status code) 70 204 No Content (status code) 70
205 Reset Content (status code) 70 205 Reset Content (status code) 70
206 Partial Content (status code) 71 206 Partial Content (status code) 71
214 Transformation applied (warn code) 162 214 Transformation applied (warn code) 162
299 Miscellaneous persistent warning (warn code) 162 299 Miscellaneous persistent warning (warn code) 162
3 3
300 Multiple Choices (status code) 72 300 Multiple Choices (status code) 72
301 Moved Permanently (status code) 72 301 Moved Permanently (status code) 72
302 Found (status code) 73 302 Found (status code) 73
303 See Other (status code) 73 303 See Other (status code) 73
304 Not Modified (status code) 74 304 Not Modified (status code) 74
305 Use Proxy (status code) 74 305 Use Proxy (status code) 75
306 (Unused) (status code) 75 306 (Unused) (status code) 75
307 Temporary Redirect (status code) 75 307 Temporary Redirect (status code) 75
4 4
400 Bad Request (status code) 76 400 Bad Request (status code) 76
401 Unauthorized (status code) 76 401 Unauthorized (status code) 76
402 Payment Required (status code) 76 402 Payment Required (status code) 76
403 Forbidden (status code) 76 403 Forbidden (status code) 76
404 Not Found (status code) 76 404 Not Found (status code) 77
405 Method Not Allowed (status code) 77 405 Method Not Allowed (status code) 77
406 Not Acceptable (status code) 77 406 Not Acceptable (status code) 77
407 Proxy Authentication Required (status code) 77 407 Proxy Authentication Required (status code) 78
408 Request Timeout (status code) 78 408 Request Timeout (status code) 78
409 Conflict (status code) 78 409 Conflict (status code) 78
410 Gone (status code) 78 410 Gone (status code) 78
411 Length Required (status code) 79 411 Length Required (status code) 79
412 Precondition Failed (status code) 79 412 Precondition Failed (status code) 79
413 Request Entity Too Large (status code) 79 413 Request Entity Too Large (status code) 79
414 Request-URI Too Long (status code) 79 414 Request-URI Too Long (status code) 79
415 Unsupported Media Type (status code) 79 415 Unsupported Media Type (status code) 80
416 Requested Range Not Satisfiable (status code) 79 416 Requested Range Not Satisfiable (status code) 80
417 Expectation Failed (status code) 80 417 Expectation Failed (status code) 80
5 5
500 Internal Server Error (status code) 80 500 Internal Server Error (status code) 80
501 Not Implemented (status code) 80 501 Not Implemented (status code) 80
502 Bad Gateway (status code) 80 502 Bad Gateway (status code) 81
503 Service Unavailable (status code) 81 503 Service Unavailable (status code) 81
504 Gateway Timeout (status code) 81 504 Gateway Timeout (status code) 81
505 HTTP Version Not Supported (status code) 81 505 HTTP Version Not Supported (status code) 81
A A
Accept header 112 Accept header 112
Accept-Charset header 114 Accept-Charset header 114
Accept-Encoding header 114 Accept-Encoding header 114
Accept-Language header 116 Accept-Language header 116
Accept-Ranges header 117 Accept-Ranges header 117
Age header 117 Age header 117
age 17 age 17
Allow header 118 Allow header 118
Alternates header 190 Alternates header 192
application/http Media Type 177 application/http Media Type 178
Authorization header 118 Authorization header 118
C C
Cache Directives Cache Directives
max-age 124, 126 max-age 124, 126
max-stale 124 max-stale 124
min-fresh 124 min-fresh 124
must-revalidate 126 must-revalidate 126
no-cache 122 no-cache 122
no-store 122 no-store 122
skipping to change at page 235, line 9 skipping to change at page 236, line 9
compress (content coding) 31 compress (content coding) 31
CONNECT method 67 CONNECT method 67
Connection header 129 Connection header 129
connection 14 connection 14
Content Codings 31 Content Codings 31
compress 31 compress 31
deflate 31 deflate 31
gzip 31 gzip 31
identity 31 identity 31
content negotiation 15 content negotiation 15
Content-Base header 190 Content-Base header 192
Content-Disposition header 185 Content-Disposition header 187
Content-Encoding header 130 Content-Encoding header 130
Content-Language header 130 Content-Language header 131
Content-Length header 131 Content-Length header 131
Content-Location header 132 Content-Location header 132
Content-MD5 header 133 Content-MD5 header 133
Content-Range header 134 Content-Range header 134
Content-Type header 136 Content-Type header 136
Content-Version header 190 Content-Version header 192
D D
Date header 136 Date header 137
deflate (content coding) 31 deflate (content coding) 31
DELETE method 67 DELETE method 67
Derived-From header 190 Derived-From header 192
downstream 18 downstream 18
E E
entity 14 entity 14
ETag header 138 ETag header 138
Expect header 138 Expect header 138
Expires header 139 Expires header 139
explicit expiration time 17 explicit expiration time 17
F F
first-hand 16 first-hand 16
fresh 17 fresh 17
freshness lifetime 17 freshness lifetime 17
From header 140 From header 140
G G
gateway 16 gateway 16
GET method 64 GET method 64
Grammar Grammar
absoluteURI 26
Accept 112 Accept 112
Accept-Charset 114 Accept-Charset 114
Accept-Encoding 114 Accept-Encoding 114
accept-extension 112 accept-extension 112
Accept-Language 116 Accept-Language 116
accept-params 112 accept-params 112
Accept-Ranges 117 Accept-Ranges 117
acceptable-ranges 117 acceptable-ranges 117
Age 118 Age 118
age-value 118 age-value 118
Allow 118 Allow 118
ALPHA 23 ALPHA 23
asctime-date 29 asctime-date 29
attribute 32 attribute 32
authority 26
Authorization 119 Authorization 119
byte-content-range-spec 134 byte-content-range-spec 134
byte-range-resp-spec 134 byte-range-resp-spec 134
byte-range-set 150 byte-range-set 150
byte-range-spec 150 byte-range-spec 150
byte-ranges-specifier 150 byte-ranges-specifier 150
bytes-unit 38 bytes-unit 38
Cache-Control 120 Cache-Control 120
cache-directive 120 cache-directive 120
cache-extension 120 cache-extension 120
skipping to change at page 236, line 36 skipping to change at page 237, line 38
chunk-ext-name 33 chunk-ext-name 33
chunk-ext-val 33 chunk-ext-val 33
chunk-extension 33 chunk-extension 33
chunk-size 33 chunk-size 33
Chunked-Body 33 Chunked-Body 33
codings 114 codings 114
comment 24 comment 24
Connection 129 Connection 129
connection-token 129 connection-token 129
content-coding 31 content-coding 31
content-disposition 185 content-disposition 187
Content-Encoding 130 Content-Encoding 130
Content-Language 131 Content-Language 131
Content-Length 131 Content-Length 131
Content-Location 132 Content-Location 132
Content-MD5 133 Content-MD5 133
Content-Range 134 Content-Range 134
content-range-spec 134 content-range-spec 134
Content-Type 136 Content-Type 136
CR 23 CR 23
CRLF 23 CRLF 23
ctext 24 ctext 24
CTL 23 CTL 23
Date 136 Date 137
date1 29 date1 29
date2 29 date2 29
date3 29 date3 29
delta-seconds 29 delta-seconds 29
DIGIT 23 DIGIT 23
disp-extension-parm 185 disp-extension-parm 187
disp-extension-token 185 disp-extension-token 187
disposition-parm 185 disposition-parm 187
disposition-type 185 disposition-type 187
DQUOTE 23
entity-body 53 entity-body 53
entity-header 53 entity-header 53
entity-tag 38 entity-tag 38
ETag 138 ETag 138
Expect 138 Expect 138
expect-params 138 expect-params 138
expectation 138 expectation 138
expectation-extension 138 expectation-extension 138
Expires 139 Expires 139
extension-code 51 extension-code 51
extension-header 53 extension-header 53
extension-method 45 extension-method 45
extension-pragma 148 extension-pragma 149
field-content 41 field-content 41
field-name 41 field-name 41
field-value 41 field-value 41
filename-parm 185 filename-parm 187
first-byte-pos 150 first-byte-pos 150
From 140 From 140
general-header 44 general-header 44
generic-message 40 generic-message 40
HEX 24 HEX 24
Host 141 Host 141
HT 23 HT 23
HTTP-date 29 HTTP-date 29
HTTP-message 40 HTTP-message 40
http-URL 27
HTTP-Version 25 HTTP-Version 25
http_URL 27 http_URL 27
If-Match 141 If-Match 141
If-Modified-Since 142 If-Modified-Since 143
If-None-Match 144 If-None-Match 144
If-Range 145 If-Range 145
If-Unmodified-Since 146 If-Unmodified-Since 146
instance-length 134 instance-length 134
language-range 116 language-range 116
language-tag 37 Language-Tag 37
last-byte-pos 150 last-byte-pos 150
last-chunk 33 last-chunk 33
Last-Modified 146 Last-Modified 146
LF 23 LF 23
LOALPHA 23 LOALPHA 23
Location 147 Location 147
LWS 23 LWS 23
Max-Forwards 148 Max-Forwards 148
md5-digest 133 md5-digest 133
media-range 112 media-range 112
media-type 34 media-type 34
message-body 41 message-body 41
message-header 41 message-header 41
Method 45 Method 45
MIME-Version 182 MIME-Version 184
month 29 month 29
OCTET 23 OCTET 23
opaque-tag 38 opaque-tag 38
other-range-unit 38 other-range-unit 38
parameter 32 parameter 32
Pragma 148 path-absolute 26
pragma-directive 148 port 26
primary-tag 37 Pragma 149
pragma-directive 149
product 36 product 36
product-version 36 product-version 36
protocol-name 158 protocol-name 159
protocol-version 158 protocol-version 159
Proxy-Authenticate 149 Proxy-Authenticate 149
Proxy-Authorization 149 Proxy-Authorization 150
pseudonym 158 pseudonym 159
qdtext 24 qdtext 24
query 26
quoted-pair 24 quoted-pair 24
quoted-string 24 quoted-string 24
qvalue 37 qvalue 37
Range 152 Range 152
range-unit 38 range-unit 38
ranges-specifier 150 ranges-specifier 150
Reason-Phrase 51 Reason-Phrase 51
received-by 158 received-by 159
received-protocol 158 received-protocol 159
Referer 152 Referer 153
relativeURI 26
Request 45 Request 45
request-header 48 request-header 48
Request-Line 45 Request-Line 45
Request-URI 46 Request-URI 46
Response 49 Response 49
response-header 52 response-header 52
Retry-After 153 Retry-After 153
rfc850-date 29 rfc850-date 29
rfc1123-date 29 rfc1123-date 29
separators 24 separators 24
Server 153 Server 154
SP 23 SP 23
start-line 40 start-line 40
Status-Code 51 Status-Code 51
Status-Line 49 Status-Line 49
subtag 37
subtype 34 subtype 34
suffix-byte-range-spec 151 suffix-byte-range-spec 151
suffix-length 151 suffix-length 151
t-codings 154 t-codings 154
tchar 24
TE 154 TE 154
TEXT 23 TEXT 23
time 29 time 29
token 24 token 24
Trailer 155 Trailer 155
trailer 33 trailer 33
trailer-part 33
transfer-coding 32 transfer-coding 32
Transfer-Encoding 155 Transfer-Encoding 156
transfer-extension 32 transfer-extension 32
type 34 type 34
UPALPHA 23 UPALPHA 23
Upgrade 156 Upgrade 156
uri-host 26
User-Agent 157 User-Agent 157
value 32 value 32
Vary 157 Vary 158
Via 158 Via 159
warn-agent 160 warn-agent 160
warn-code 160 warn-code 160
warn-date 160 warn-date 160
warn-text 160 warn-text 160
Warning 160 Warning 160
warning-value 160 warning-value 160
weak 38 weak 38
weekday 29 weekday 29
wkday 29 wkday 29
WWW-Authenticate 162 WWW-Authenticate 163
gzip (content coding) 31 gzip (content coding) 31
H H
HEAD method 64 HEAD method 64
Headers Headers
Accept 112 Accept 112
Accept-Charset 114 Accept-Charset 114
Accept-Encoding 114 Accept-Encoding 114
Accept-Language 116 Accept-Language 116
Accept-Ranges 117 Accept-Ranges 117
Age 117 Age 117
Allow 118 Allow 118
Alternate 190 Alternate 192
Authorization 118 Authorization 118
Cache-Control 119 Cache-Control 119
Connection 129 Connection 129
Content-Base 190 Content-Base 192
Content-Disposition 185 Content-Disposition 187
Content-Encoding 130 Content-Encoding 130
Content-Language 130 Content-Language 131
Content-Length 131 Content-Length 131
Content-Location 132 Content-Location 132
Content-MD5 133 Content-MD5 133
Content-Range 134 Content-Range 134
Content-Type 136 Content-Type 136
Content-Version 190 Content-Version 192
Date 136 Date 137
Derived-From 190 Derived-From 192
ETag 138 ETag 138
Expect 138 Expect 138
Expires 139 Expires 139
From 140 From 140
Host 140 Host 141
If-Match 141 If-Match 141
If-Modified-Since 142 If-Modified-Since 142
If-None-Match 144 If-None-Match 144
If-Range 145 If-Range 145
If-Unmodified-Since 146 If-Unmodified-Since 146
Last-Modified 146 Last-Modified 146
Link 190 Link 192
Location 147 Location 147
Max-Forwards 148 Max-Forwards 148
Pragma 148 Pragma 148
Proxy-Authenticate 149 Proxy-Authenticate 149
Proxy-Authorization 149 Proxy-Authorization 150
Public 190 Public 192
Range 150 Range 150
Referer 152 Referer 153
Retry-After 153 Retry-After 153
Server 153 Server 153
TE 154 TE 154
Trailer 155 Trailer 155
Transfer-Encoding 155 Transfer-Encoding 156
Upgrade 156 Upgrade 156
URI 190 URI 192
User-Agent 157 User-Agent 157
Vary 157 Vary 158
Via 158 Via 158
Warning 160 Warning 160
WWW-Authenticate 162 WWW-Authenticate 163
heuristic expiration time 17 heuristic expiration time 17
Host header 140 Host header 141
I I
identity (content coding) 31 identity (content coding) 31
If-Match header 141 If-Match header 141
If-Modified-Since header 142 If-Modified-Since header 142
If-None-Match header 144 If-None-Match header 144
If-Range header 145 If-Range header 145
If-Unmodified-Since header 146 If-Unmodified-Since header 146
inbound 18 inbound 18
L L
Last-Modified header 146 Last-Modified header 146
Link header 190 Link header 192
LINK method 190 LINK method 192
Location header 147 Location header 147
M M
max-age max-age
Cache Directive 124, 126 Cache Directive 124, 126
Max-Forwards header 148 Max-Forwards header 148
max-stale max-stale
Cache Directive 124 Cache Directive 124
Media Type Media Type
application/http 177 application/http 178
message/http 177 message/http 178
multipart/byteranges 179 multipart/byteranges 181
multipart/x-byteranges 180 multipart/x-byteranges 182
message 14 message 14
message/http Media Type 177 message/http Media Type 178
Methods Methods
CONNECT 67 CONNECT 67
DELETE 67 DELETE 67
GET 64 GET 64
HEAD 64 HEAD 64
LINK 190 LINK 192
OPTIONS 63 OPTIONS 63
PATCH 190 PATCH 192
POST 65 POST 65
PUT 65 PUT 65
TRACE 67 TRACE 67
UNLINK 190 UNLINK 192
min-fresh min-fresh
Cache Directive 124 Cache Directive 124
multipart/byteranges Media Type 179 multipart/byteranges Media Type 181
multipart/x-byteranges Media Type 180 multipart/x-byteranges Media Type 182
must-revalidate must-revalidate
Cache Directive 126 Cache Directive 126
N N
no-cache no-cache
Cache Directive 122 Cache Directive 122
no-store no-store
Cache Directive 122 Cache Directive 122
no-transform no-transform
Cache Directive 127 Cache Directive 127
O O
only-if-cached only-if-cached
Cache Directive 126 Cache Directive 126
OPTIONS method 63 OPTIONS method 63
origin server 15 origin server 15
outbound 18 outbound 18
P P
PATCH method 190 PATCH method 192
POST method 65 POST method 65
Pragma header 148 Pragma header 148
private private
Cache Directive 121 Cache Directive 121
proxy 15 proxy 15
Proxy-Authenticate header 149 Proxy-Authenticate header 149
Proxy-Authorization header 149 Proxy-Authorization header 150
proxy-revalidate proxy-revalidate
Cache Directive 127 Cache Directive 127
Public header 190 Public header 192
public public
Cache Directive 121 Cache Directive 121
PUT method 65 PUT method 65
R R
Range header 150 Range header 150
Referer header 152 Referer header 153
representation 14 representation 14
request 14 request 14
resource 14 resource 14
response 14 response 14
Retry-After header 153 Retry-After header 153
S S
s-maxage s-maxage
Cache Directive 123 Cache Directive 123
semantically transparent 17 semantically transparent 17
Server header 153 Server header 153
server 15 server 15
stale 17 stale 17
Status Codes Status Codes
100 Continue 68 100 Continue 68
101 Switching Protocols 68 101 Switching Protocols 68
skipping to change at page 243, line 17 skipping to change at page 244, line 26
202 Accepted 69 202 Accepted 69
203 Non-Authoritative Information 70 203 Non-Authoritative Information 70
204 No Content 70 204 No Content 70
205 Reset Content 70 205 Reset Content 70
206 Partial Content 71 206 Partial Content 71
300 Multiple Choices 72 300 Multiple Choices 72
301 Moved Permanently 72 301 Moved Permanently 72
302 Found 73 302 Found 73
303 See Other 73 303 See Other 73
304 Not Modified 74 304 Not Modified 74
305 Use Proxy 74 305 Use Proxy 75
306 (Unused) 75 306 (Unused) 75
307 Temporary Redirect 75 307 Temporary Redirect 75
400 Bad Request 76 400 Bad Request 76
401 Unauthorized 76 401 Unauthorized 76
402 Payment Required 76 402 Payment Required 76
403 Forbidden 76 403 Forbidden 76
404 Not Found 76 404 Not Found 77
405 Method Not Allowed 77 405 Method Not Allowed 77
406 Not Acceptable 77 406 Not Acceptable 77
407 Proxy Authentication Required 77 407 Proxy Authentication Required 78
408 Request Timeout 78 408 Request Timeout 78
409 Conflict 78 409 Conflict 78
410 Gone 78 410 Gone 78
411 Length Required 79 411 Length Required 79
412 Precondition Failed 79 412 Precondition Failed 79
413 Request Entity Too Large 79 413 Request Entity Too Large 79
414 Request-URI Too Long 79 414 Request-URI Too Long 79
415 Unsupported Media Type 79 415 Unsupported Media Type 80
416 Requested Range Not Satisfiable 79 416 Requested Range Not Satisfiable 80
417 Expectation Failed 80 417 Expectation Failed 80
500 Internal Server Error 80 500 Internal Server Error 80
501 Not Implemented 80 501 Not Implemented 80
502 Bad Gateway 80 502 Bad Gateway 81
503 Service Unavailable 81 503 Service Unavailable 81
504 Gateway Timeout 81 504 Gateway Timeout 81
505 HTTP Version Not Supported 81 505 HTTP Version Not Supported 81
T T
TE header 154 TE header 154
TRACE method 67 TRACE method 67
Trailer header 155 Trailer header 155
Transfer-Encoding header 155 Transfer-Encoding header 156
tunnel 16 tunnel 16
U U
UNLINK method 190 UNLINK method 192
Upgrade header 156 Upgrade header 156
upstream 18 upstream 18
URI header 190 URI header 192
user agent 15 user agent 15
User-Agent header 157 User-Agent header 157
V V
validator 17 validator 17
variant 15 variant 15
Vary header 157 Vary header 158
Via header 158 Via header 158
W W
Warn Codes Warn Codes
110 Response is stale 161 110 Response is stale 161
111 Revalidation failed 161 111 Revalidation failed 161
112 Disconnected operation 161 112 Disconnected operation 162
113 Heuristic expiration 161 113 Heuristic expiration 162
199 Miscellaneous warning 161 199 Miscellaneous warning 162
214 Transformation applied 162 214 Transformation applied 162
299 Miscellaneous persistent warning 162 299 Miscellaneous persistent warning 162
Warning header 160 Warning header 160
WWW-Authenticate header 162 WWW-Authenticate header 163
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. 290 change blocks. 
868 lines changed or deleted 989 lines changed or added

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