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