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