rfc2616.txt | draft-lafon-rfc2616bis-00.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding | Network Working Group Y. Lafon | |||
Request for Comments: 2616 UC Irvine | Internet-Draft W3C | |||
Obsoletes: 2068 J. Gettys | Obsoletes: 2616 (if approved) J. Reschke | |||
Category: Standards Track Compaq/W3C | Intended status: Standards Track greenbytes | |||
J. Mogul | Expires: April 16, 2007 October 13, 2006 | |||
Compaq | ||||
H. Frystyk | ||||
W3C/MIT | ||||
L. Masinter | ||||
Xerox | ||||
P. Leach | ||||
Microsoft | ||||
T. Berners-Lee | ||||
W3C/MIT | ||||
Hypertext Transfer Protocol -- HTTP/1.1 | Hypertext Transfer Protocol -- HTTP/1.1 | |||
draft-lafon-rfc2616bis-00 | ||||
Status of this Memo | Status of this Memo | |||
This document specifies an Internet standards track protocol for the | By submitting this Internet-Draft, each author represents that any | |||
Internet community, and requests discussion and suggestions for | applicable patent or other IPR claims of which he or she is aware | |||
improvements. Please refer to the current edition of the "Internet | have been or will be disclosed, and any of which he or she becomes | |||
Official Protocol Standards" (STD 1) for the standardization state | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on April 16, 2007. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (1999). | 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 | |||
many tasks beyond its use for hypertext, such as name servers and | many tasks beyond its use for hypertext, such as name servers and | |||
distributed object management systems, through extension of its | distributed object management systems, through extension of its | |||
request methods, error codes and headers [47]. A feature of HTTP is | request methods, error codes and headers [47]. A feature of HTTP is | |||
the typing and negotiation of data representation, allowing systems | the typing and negotiation of data representation, allowing systems | |||
to be built independently of the data being transferred. | to be built independently of the data being transferred. | |||
HTTP has been in use by the World-Wide Web global information | HTTP has been in use by the World-Wide Web global information | |||
initiative since 1990. This specification defines the protocol | initiative since 1990. This specification defines the protocol | |||
referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. | referred to as "HTTP/1.1", and is an update to RFC2616. | |||
Editorial Note (To be removed by RFC Editor before publication) | ||||
Distribution of this document is unlimited. Please send comments to | ||||
the Hypertext Transfer Protocol (HTTP) mailing list at | ||||
ietf-http-wg@w3.org [51], which may be joined by sending a message | ||||
with subject "subscribe" to ietf-http-wg-request@w3.org [52]. | ||||
Discussions of the HTTP working group are archived at | ||||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. XML versions, | ||||
latest edits and the issues list for this document are available from | ||||
<http://www.w3.org/Protocols/HTTP/1.1/>. | ||||
The purpose of this document is to revise RFC2616 ([50]), doing only | ||||
minimal corrections. For now, it is not planned to advance the | ||||
standards level of HTTP, thus - if published - the specification will | ||||
still be a "Proposed Standard" (see [46]). | ||||
The current plan is to incorporate known errata, and to update the | ||||
specification text according to the current IETF publication | ||||
guidelines. In particular: | ||||
o Incorporate the corrections collected in the RFC2616 errata | ||||
document (<http://skrb.org/ietf/http_errata.html>) and potentially | ||||
newly discovered and agreed-upon errata. | ||||
o Update references, and re-classify them into "Normative" and | ||||
"Informative", based on the prior work done by Jim Gettys in | ||||
<http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00>. | ||||
This document is based on a variant of the original RFC2616 | ||||
specification formatted using Marshall T. Rose's "xml2rfc" tool (see | ||||
<http://xml.resource.org>) and therefore deviates from the original | ||||
text in word wrapping, page breaks, list formatting, reference | ||||
formatting, whitespace usage and appendix numbering. Otherwise, it | ||||
is supposed to contain an accurate copy of the original specification | ||||
text. See <http://www.w3.org/Protocols/HTTP/1.1/ | ||||
rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both | ||||
documents, as generated by "rfcdiff" | ||||
(<http://tools.ietf.org/tools/rfcdiff/>). | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 9 | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 13 | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 15 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . 16 | 2. Notational Conventions and Generic Grammar . . . . . . . . . 18 | |||
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 16 | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 18 | |||
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 18 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 20 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 20 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 23 | |||
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 21 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 23 | |||
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 21 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 22 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 24 | |||
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 22 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 24 | |||
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 22 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 24 | 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 26 | |||
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 24 | 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 26 | |||
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 25 | 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 27 | |||
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 25 | 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 27 | |||
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 26 | 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 28 | |||
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 27 | 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 29 | |||
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 29 | 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 31 | |||
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 29 | 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 31 | |||
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 30 | 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 32 | |||
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 31 | 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 31 | 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 32 | 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 34 | |||
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 | 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 34 | |||
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 33 | 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 35 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 36 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 37 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 38 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . 39 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 39 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 39 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 40 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 42 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . 41 | 5.2. The Resource Identified by a Request . . . . . . . . . . 43 | |||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 42 | 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 44 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 45 | |||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 46 | 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 48 | |||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 47 | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 49 | |||
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 48 | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 50 | |||
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 49 | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 51 | |||
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 49 | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 51 | |||
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 49 | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 51 | |||
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 51 | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 53 | |||
8.1.4. Practical Considerations . . . . . . . . . . . . . . 51 | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 53 | |||
8.2. Message Transmission Requirements . . . . . . . . . . . 52 | 8.2. Message Transmission Requirements . . . . . . . . . . . 54 | |||
8.2.1. Persistent Connections and Flow Control . . . . . . 52 | 8.2.1. Persistent Connections and Flow Control . . . . . . 54 | |||
8.2.2. Monitoring Connections for Error Status Messages . . 52 | 8.2.2. Monitoring Connections for Error Status Messages . . 54 | |||
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 53 | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 55 | |||
8.2.4. Client Behavior if Server Prematurely Closes | 8.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . 55 | Connection . . . . . . . . . . . . . . . . . . . . . 57 | |||
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 | 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 58 | |||
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 56 | 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 58 | |||
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 56 | 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 58 | |||
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 56 | 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 58 | |||
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 | 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 59 | |||
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 63 | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 65 | |||
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 63 | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 65 | |||
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 63 | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 65 | |||
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 63 | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 65 | |||
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 64 | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 64 | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 64 | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 64 | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 65 | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 67 | |||
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 65 | 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 67 | |||
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 65 | 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 67 | |||
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 66 | 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 68 | |||
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 66 | 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 68 | |||
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 67 | 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 69 | |||
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 67 | 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 69 | |||
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 68 | 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 70 | |||
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 68 | 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 70 | |||
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 69 | 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 71 | |||
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 69 | 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 71 | |||
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 70 | 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 72 | |||
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 70 | 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 72 | |||
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 70 | 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 72 | |||
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 71 | 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 73 | |||
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 71 | 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 73 | |||
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 71 | 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 73 | |||
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 71 | 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 73 | |||
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 71 | 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 73 | |||
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 72 | 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 74 | |||
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 72 | 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 74 | |||
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 72 | 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 74 | |||
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 73 | 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 75 | |||
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 73 | 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 75 | |||
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 73 | 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 75 | |||
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 74 | 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 76 | |||
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 74 | 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 76 | |||
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 74 | 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 76 | |||
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 74 | 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 76 | |||
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 74 | 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 76 | |||
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 74 | 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 76 | |||
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 75 | 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 77 | |||
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 75 | 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 77 | |||
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 75 | 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 77 | |||
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 75 | 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 77 | |||
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 75 | 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 77 | |||
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 76 | 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 78 | |||
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 76 | 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 78 | |||
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 76 | 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 78 | |||
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 77 | 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 79 | |||
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 78 | 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 80 | |||
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 78 | 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 80 | |||
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 79 | 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 81 | |||
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 80 | 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 82 | |||
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 81 | 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 83 | |||
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 | 13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 82 | 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 84 | |||
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 83 | 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 85 | |||
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 84 | 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 86 | |||
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 84 | 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 86 | |||
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 85 | 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 87 | |||
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 85 | 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 87 | |||
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 86 | 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 88 | |||
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 86 | 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 88 | |||
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 86 | 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 88 | |||
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 87 | 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 89 | |||
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 89 | 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 91 | |||
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 90 | 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 92 | |||
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 91 | 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 93 | |||
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 91 | 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 93 | |||
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 92 | 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 94 | |||
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 92 | 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 94 | |||
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 93 | 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 95 | |||
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 . . . . . . . . . . . . . . . . 95 | Last-Modified Dates . . . . . . . . . . . . . . . . 97 | |||
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 97 | 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 99 | |||
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 97 | 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 99 | |||
13.5. Constructing Responses From Caches . . . . . . . . . . . 98 | 13.5. Constructing Responses From Caches . . . . . . . . . . . 100 | |||
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 98 | 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 100 | |||
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 99 | 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 101 | |||
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 100 | 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 102 | |||
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 101 | 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 103 | |||
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 102 | 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 104 | |||
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 103 | 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 105 | |||
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 103 | 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 105 | |||
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 104 | 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 106 | |||
13.10. Invalidation After Updates or Deletions . . . . . . . . 104 | 13.10. Invalidation After Updates or Deletions . . . . . . . . 106 | |||
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 105 | 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 107 | |||
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 105 | 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 107 | |||
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 106 | 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 108 | |||
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 107 | 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 109 | |||
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 107 | 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 109 | |||
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 109 | 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 111 | |||
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 109 | 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 111 | |||
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 111 | 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 113 | |||
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 112 | 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 114 | |||
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 112 | 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 114 | |||
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 113 | 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 115 | |||
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 113 | 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 114 | 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 116 | 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 118 | |||
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 117 | 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 119 | |||
14.9.3. Modifications of the Basic Expiration Mechanism . . 118 | 14.9.3. Modifications of the Basic Expiration Mechanism . . 120 | |||
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 120 | 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 122 | |||
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 122 | 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 125 | |||
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 123 | 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 125 | |||
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 124 | 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 126 | |||
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125 | 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 127 | |||
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 125 | 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 128 | |||
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 126 | 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 128 | |||
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 127 | 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 129 | |||
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 128 | 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 130 | |||
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 129 | 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 131 | |||
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 131 | 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 131 | 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.18.1. Clockless Origin Server Operation . . . . . . . . . 132 | 14.18.1. Clockless Origin Server Operation . . . . . . . . . 134 | |||
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 133 | 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | |||
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 133 | 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 135 | |||
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 134 | 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 136 | |||
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 136 | 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137 | 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 139 | |||
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 139 | 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 141 | |||
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 140 | 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 142 | |||
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 141 | 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 143 | |||
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 141 | 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 143 | |||
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 142 | 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 142 | 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 143 | 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 145 | |||
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 144 | 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 146 | |||
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144 | 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 146 | |||
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 144 | 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 144 | 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 147 | |||
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 146 | 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 148 | |||
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 147 | 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 149 | |||
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 147 | 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 150 | |||
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 150 | |||
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 | |||
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 149 | 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 152 | |||
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 150 | 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 152 | |||
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 150 | 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 153 | |||
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 153 | 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 155 | |||
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 154 | 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157 | 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 159 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 158 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 160 | |||
15.1. Personal Information . . . . . . . . . . . . . . . . . . 158 | 15.1. Personal Information . . . . . . . . . . . . . . . . . . 160 | |||
15.1.1. Abuse of Server Log Information . . . . . . . . . . 158 | 15.1.1. Abuse of Server Log Information . . . . . . . . . . 160 | |||
15.1.2. Transfer of Sensitive Information . . . . . . . . . 158 | 15.1.2. Transfer of Sensitive Information . . . . . . . . . 160 | |||
15.1.3. Encoding Sensitive Information in URI's . . . . . . 159 | 15.1.3. Encoding Sensitive Information in URI's . . . . . . 161 | |||
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 160 | 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 162 | |||
15.2. Attacks Based On File and Path Names . . . . . . . . . . 160 | 15.2. Attacks Based On File and Path Names . . . . . . . . . . 162 | |||
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 161 | 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 163 | |||
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 161 | 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 163 | |||
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 162 | 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 164 | |||
15.6. Authentication Credentials and Idle Clients . . . . . . 162 | 15.6. Authentication Credentials and Idle Clients . . . . . . 164 | |||
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 162 | 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 164 | |||
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 163 | 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 165 | |||
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 166 | |||
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 | 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 166 | |||
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 170 | 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 168 | |||
A.1. Internet Media Type message/http and application/http . 170 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
A.2. Internet Media Type multipart/byteranges . . . . . . . . 171 | 17.1. References . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 172 | 17.2. Normative References . . . . . . . . . . . . . . . . . . 172 | |||
A.4. Differences Between HTTP Entities and RFC 2045 | Appendix A. Internet Media Type message/http and | |||
Entities . . . . . . . . . . . . . . . . . . . . . . . . 173 | application/http . . . . . . . . . . . . . . . . . . 174 | |||
A.4.1. MIME-Version . . . . . . . . . . . . . . . . . . . . 174 | Appendix B. Internet Media Type multipart/byteranges . . . . . . 176 | |||
A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 174 | Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 178 | |||
A.4.3. Conversion of Date Formats . . . . . . . . . . . . . 174 | Appendix D. Differences Between HTTP Entities and RFC 2045 | |||
A.4.4. Introduction of Content-Encoding . . . . . . . . . . 175 | Entities . . . . . . . . . . . . . . . . . . . . . . 179 | |||
A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 175 | D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 179 | |||
A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 175 | D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 179 | |||
A.4.7. MHTML and Line Length Limitations . . . . . . . . . 176 | D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 180 | |||
A.5. Additional Features . . . . . . . . . . . . . . . . . . 176 | D.4. Introduction of Content-Encoding . . . . . . . . . . . . 180 | |||
A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 176 | D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 180 | |||
A.6. Compatibility with Previous Versions . . . . . . . . . . 177 | D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 181 | |||
A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 178 | D.7. MHTML and Line Length Limitations . . . . . . . . . . . 181 | |||
A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 179 | Appendix E. Additional Features . . . . . . . . . . . . . . . . 182 | |||
A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 179 | E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 182 | |||
Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 183 | Appendix F. Compatibility with Previous Versions . . . . . . . . 183 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 | F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 183 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 196 | F.1.1. Changes to Simplify Multi-homed Web Servers and | |||
Intellectual Property and Copyright Statements . . . . . . . . . 198 | Conserve IP Addresses . . . . . . . . . . . . . . . 183 | |||
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 184 | ||||
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 185 | ||||
Appendix G. Change Log (to be removed by RFC Editor before | ||||
publication) . . . . . . . . . . . . . . . . . . . . 188 | ||||
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 188 | ||||
Appendix H. Open issues (to be removed by RFC Editor prior to | ||||
publication) . . . . . . . . . . . . . . . . . . . . 189 | ||||
H.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 189 | ||||
H.2. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 189 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 202 | ||||
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 13, line 27 | skipping to change at page 15, line 27 | |||
1.4. Overall Operation | 1.4. Overall Operation | |||
The HTTP protocol is a request/response protocol. A client sends a | The HTTP protocol is a request/response protocol. A client sends a | |||
request to the server in the form of a request method, URI, and | request to the server in the form of a request method, URI, and | |||
protocol version, followed by a MIME-like message containing request | protocol version, followed by a MIME-like message containing request | |||
modifiers, client information, and possible body content over a | modifiers, client information, and possible body content over a | |||
connection with a server. The server responds with a status line, | connection with a server. The server responds with a status line, | |||
including the message's protocol version and a success or error code, | including the message's protocol version and a success or error code, | |||
followed by a MIME-like message containing server information, entity | followed by a MIME-like message containing server information, entity | |||
metainformation, and possible entity-body content. The relationship | metainformation, and possible entity-body content. The relationship | |||
between HTTP and MIME is described in Appendix A.4. | between HTTP and MIME is described in Appendix D. | |||
Most HTTP communication is initiated by a user agent and consists of | Most HTTP communication is initiated by a user agent and consists of | |||
a request to be applied to a resource on some origin server. In the | a request to be applied to a resource on some origin server. In the | |||
simplest case, this may be accomplished via a single connection (v) | simplest case, this may be accomplished via a single connection (v) | |||
between the user agent (UA) and the origin server (O). | between the user agent (UA) and the origin server (O). | |||
request chain ------------------------> | request chain ------------------------> | |||
UA -------------------v------------------- O | UA -------------------v------------------- O | |||
<----------------------- response chain | <----------------------- response chain | |||
skipping to change at page 18, line 28 | skipping to change at page 20, line 28 | |||
DIGIT = <any US-ASCII digit "0".."9"> | DIGIT = <any US-ASCII digit "0".."9"> | |||
CTL = <any US-ASCII control character | CTL = <any US-ASCII control character | |||
(octets 0 - 31) and DEL (127)> | (octets 0 - 31) and DEL (127)> | |||
CR = <US-ASCII CR, carriage return (13)> | CR = <US-ASCII CR, carriage return (13)> | |||
LF = <US-ASCII LF, linefeed (10)> | LF = <US-ASCII LF, linefeed (10)> | |||
SP = <US-ASCII SP, space (32)> | SP = <US-ASCII SP, space (32)> | |||
HT = <US-ASCII HT, horizontal-tab (9)> | HT = <US-ASCII HT, horizontal-tab (9)> | |||
<"> = <US-ASCII double-quote mark (34)> | <"> = <US-ASCII double-quote mark (34)> | |||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |||
protocol elements except the entity-body (see Appendix A.3 for | protocol elements except the entity-body (see Appendix C for tolerant | |||
tolerant applications). The end-of-line marker within an entity-body | applications). The end-of-line marker within an entity-body is | |||
is defined by its associated media type, as described in Section 3.7. | defined by its associated media type, as described in Section 3.7. | |||
CRLF = CR LF | CRLF = CR LF | |||
HTTP/1.1 header field values can be folded onto multiple lines if the | HTTP/1.1 header field values can be folded onto multiple lines if the | |||
continuation line begins with a space or horizontal tab. All linear | continuation line begins with a space or horizontal tab. All linear | |||
white space, including folding, has the same semantics as SP. A | white space, including folding, has the same semantics as SP. A | |||
recipient MAY replace any linear white space with a single SP before | recipient MAY replace any linear white space with a single SP before | |||
interpreting the field value or forwarding the message downstream. | interpreting the field value or forwarding the message downstream. | |||
LWS = [CRLF] 1*( SP | HT ) | LWS = [CRLF] 1*( SP | HT ) | |||
skipping to change at page 22, line 10 | skipping to change at page 24, line 10 | |||
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: | |||
skipping to change at page 23, line 11 | skipping to change at page 25, line 11 | |||
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 | |||
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | |||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |||
The first format is preferred as an Internet standard and represents | The first format is preferred as an Internet standard and represents | |||
a fixed-length subset of that defined by RFC 1123 [8] (an update to | a fixed-length subset of that defined by RFC 1123 [8] (an update to | |||
RFC 822 [9]). The second format is in common use, but is based on | RFC 822 [9]). The second format is in common use, but is based on | |||
the obsolete RFC 850 [12] date format and lacks a four-digit year. | the obsolete RFC 850 [12] date format and lacks a four-digit year. | |||
HTTP/1.1 clients and servers that parse the date value MUST accept | HTTP/1.1 clients and servers that parse the date value MUST accept | |||
all three formats (for compatibility with HTTP/1.0), though they MUST | all three formats (for compatibility with HTTP/1.0), though they MUST | |||
only generate the RFC 1123 format for representing HTTP-date values | only generate the RFC 1123 format for representing HTTP-date values | |||
in header fields. See Appendix A.3 for further information. | in header fields. See Appendix C for further information. | |||
Note: Recipients of date values are encouraged to be robust in | Note: Recipients of date values are encouraged to be robust in | |||
accepting date values that may have been sent by non-HTTP | accepting date values that may have been sent by non-HTTP | |||
applications, as is sometimes the case when retrieving or posting | applications, as is sometimes the case when retrieving or posting | |||
messages via proxies/gateways to SMTP or NNTP. | messages via proxies/gateways to SMTP or NNTP. | |||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time | All HTTP date/time stamps MUST be represented in Greenwich Mean Time | |||
(GMT), without exception. For the purposes of HTTP, GMT is exactly | (GMT), without exception. For the purposes of HTTP, GMT is exactly | |||
equal to UTC (Coordinated Universal Time). This is indicated in the | equal to UTC (Coordinated Universal Time). This is indicated in the | |||
first two formats by the inclusion of "GMT" as the three-letter | first two formats by the inclusion of "GMT" as the three-letter | |||
skipping to change at page 29, line 4 | skipping to change at page 31, line 4 | |||
trailer fields might be silently discarded along the path to the | trailer fields might be silently discarded along the path to the | |||
client. | client. | |||
This requirement prevents an interoperability failure when the | This requirement prevents an interoperability failure when the | |||
message is being received by an HTTP/1.1 (or later) proxy and | message is being received by an HTTP/1.1 (or later) proxy and | |||
forwarded to an HTTP/1.0 recipient. It avoids a situation where | forwarded to an HTTP/1.0 recipient. It avoids a situation where | |||
compliance with the protocol would have necessitated a possibly | compliance with the protocol would have necessitated a possibly | |||
infinite buffer on the proxy. | infinite buffer on the proxy. | |||
An example process for decoding a Chunked-Body is presented in | An example process for decoding a Chunked-Body is presented in | |||
Appendix A.4.6. | Appendix D.6. | |||
All HTTP/1.1 applications MUST be able to receive and decode the | All HTTP/1.1 applications MUST be able to receive and decode the | |||
"chunked" transfer-coding, and MUST ignore chunk-extension extensions | "chunked" transfer-coding, and MUST ignore chunk-extension extensions | |||
they do not understand. | they do not understand. | |||
3.7. Media Types | 3.7. Media Types | |||
HTTP uses Internet Media Types [17] in the Content-Type | HTTP uses Internet Media Types [17] in the Content-Type | |||
(Section 14.17) and Accept (Section 14.1) header fields in order to | (Section 14.17) and Accept (Section 14.1) header fields in order to | |||
provide open and extensible data typing and type negotiation. | provide open and extensible data typing and type negotiation. | |||
skipping to change at page 30, line 43 | skipping to change at page 32, line 43 | |||
therefore use only CRLF to represent line breaks between body-parts. | therefore use only CRLF to represent line breaks between body-parts. | |||
Unlike in RFC 2046, the epilogue of any multipart message MUST be | Unlike in RFC 2046, the epilogue of any multipart message MUST be | |||
empty; HTTP applications MUST NOT transmit the epilogue (even if the | empty; HTTP applications MUST NOT transmit the epilogue (even if the | |||
original multipart contains an epilogue). These restrictions exist | original multipart contains an epilogue). These restrictions exist | |||
in order to preserve the self-delimiting nature of a multipart | in order to preserve the self-delimiting nature of a multipart | |||
message-body, wherein the "end" of the message-body is indicated by | message-body, wherein the "end" of the message-body is indicated by | |||
the ending multipart boundary. | the ending multipart boundary. | |||
In general, HTTP treats a multipart message-body no differently than | In general, HTTP treats a multipart message-body no differently than | |||
any other media type: strictly as payload. The one exception is the | any other media type: strictly as payload. The one exception is the | |||
"multipart/byteranges" type (Appendix A.2) when it appears in a 206 | "multipart/byteranges" type (Appendix B) when it appears in a 206 | |||
(Partial Content) response, which will be interpreted by some HTTP | (Partial Content) response, which will be interpreted by some HTTP | |||
caching mechanisms as described in sections 13.5.4 and 14.16. In all | caching mechanisms as described in sections 13.5.4 and 14.16. In all | |||
other cases, an HTTP user agent SHOULD follow the same or similar | other cases, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
The MIME header fields within each body-part of a multipart message- | The MIME header fields within each body-part of a multipart message- | |||
body do not have any significance to HTTP beyond that defined by | body do not have any significance to HTTP beyond that defined by | |||
their MIME semantics. | their MIME semantics. | |||
In general, an HTTP user agent SHOULD follow the same or similar | In general, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
skipping to change at page 41, line 8 | skipping to change at page 43, line 8 | |||
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.w3.org" and send | |||
the lines: | the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.w3.org | Host: www.w3.org | |||
followed by the remainder of the Request. Note that the absolute | followed by the remainder of the Request. Note that the absolute | |||
path cannot be empty; if none is present in the original URI, it MUST | path cannot be empty; if none is present in the original URI, it MUST | |||
be given as "/" (the server root). | be given as "/" (the server root). | |||
The Request-URI is transmitted in the format specified in | The Request-URI is transmitted in the format specified in section | |||
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" | 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding | |||
encoding [42], the origin server MUST decode the Request-URI in order | [42], the origin server MUST decode the Request-URI in order to | |||
to properly interpret the request. Servers SHOULD respond to invalid | 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 | |||
rewrite the Request-URI. | rewrite the Request-URI. | |||
5.2. The Resource Identified by a Request | 5.2. The Resource Identified by a Request | |||
The exact resource identified by an Internet request is determined by | The exact resource identified by an Internet request is determined by | |||
examining both the Request-URI and the Host header field. | examining both the Request-URI and the Host header field. | |||
An origin server that does not allow resources to differ by the | An origin server that does not allow resources to differ by the | |||
requested host MAY ignore the Host header field value when | requested host MAY ignore the Host header field value when | |||
determining the resource identified by an HTTP/1.1 request. (But see | determining the resource identified by an HTTP/1.1 request. (But see | |||
Appendix A.6.1.1 for other requirements on Host support in HTTP/1.1.) | Appendix F.1.1 for other requirements on Host support in HTTP/1.1.) | |||
An origin server that does differentiate resources based on the host | An origin server that does differentiate resources based on the host | |||
requested (sometimes referred to as virtual hosts or vanity host | requested (sometimes referred to as virtual hosts or vanity host | |||
names) MUST use the following rules for determining the requested | names) MUST use the following rules for determining the requested | |||
resource on an HTTP/1.1 request: | resource on an HTTP/1.1 request: | |||
1. If Request-URI is an absoluteURI, the host is part of the | 1. If Request-URI is an absoluteURI, the host is part of the | |||
Request-URI. Any Host header field value in the request MUST be | Request-URI. Any Host header field value in the request MUST be | |||
ignored. | ignored. | |||
skipping to change at page 45, line 14 | skipping to change at page 47, 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 50, line 36 | skipping to change at page 52, line 36 | |||
case the client does not want to maintain a connection for more than | case the client does not want to maintain a connection for more than | |||
that request, it SHOULD send a Connection header including the | that request, it SHOULD send a Connection header including the | |||
connection-token close. | connection-token close. | |||
If either the client or the server sends the close token in the | If either the client or the server sends the close token in the | |||
Connection header, that request becomes the last one for the | Connection header, that request becomes the last one for the | |||
connection. | connection. | |||
Clients and servers SHOULD NOT assume that a persistent connection is | Clients and servers SHOULD NOT assume that a persistent connection is | |||
maintained for HTTP versions less than 1.1 unless it is explicitly | maintained for HTTP versions less than 1.1 unless it is explicitly | |||
signaled. See Appendix A.6.2 for more information on backward | signaled. See Appendix F.2 for more information on backward | |||
compatibility with HTTP/1.0 clients. | compatibility with HTTP/1.0 clients. | |||
In order to remain persistent, all messages on the connection MUST | In order to remain persistent, all messages on the connection MUST | |||
have a self-defined message length (i.e., one not defined by closure | have a self-defined message length (i.e., one not defined by closure | |||
of the connection), as described in Section 4.4. | of the connection), as described in Section 4.4. | |||
8.1.2.2. Pipelining | 8.1.2.2. Pipelining | |||
A client that supports persistent connections MAY "pipeline" its | A client that supports persistent connections MAY "pipeline" its | |||
requests (i.e., send multiple requests without waiting for each | requests (i.e., send multiple requests without waiting for each | |||
skipping to change at page 100, line 35 | skipping to change at page 102, line 35 | |||
Warning: unnecessary modification of end-to-end headers might | Warning: unnecessary modification of end-to-end headers might | |||
cause authentication failures if stronger authentication | cause authentication failures if stronger authentication | |||
mechanisms are introduced in later versions of HTTP. Such | mechanisms are introduced in later versions of HTTP. Such | |||
authentication mechanisms MAY rely on the values of header fields | authentication mechanisms MAY rely on the values of header fields | |||
not listed here. | not listed here. | |||
The Content-Length field of a request or response is added or deleted | The Content-Length field of a request or response is added or deleted | |||
according to the rules in Section 4.4. A transparent proxy MUST | according to the rules in Section 4.4. A transparent proxy MUST | |||
preserve the entity-length (Section 7.2.2) of the entity-body, | preserve the entity-length (Section 7.2.2) of the entity-body, | |||
although it MAY change the transfer-length (Section 4.4). | although it MAY change the transfer-length (section Section 4.4). | |||
13.5.3. Combining Headers | 13.5.3. Combining Headers | |||
When a cache makes a validating request to a server, and the server | When a cache makes a validating request to a server, and the server | |||
provides a 304 (Not Modified) response or a 206 (Partial Content) | provides a 304 (Not Modified) response or a 206 (Partial Content) | |||
response, the cache then constructs a response to send to the | response, the cache then constructs a response to send to the | |||
requesting client. | requesting client. | |||
If the status code is 304 (Not Modified), the cache uses the entity- | If the status code is 304 (Not Modified), the cache uses the entity- | |||
body stored in the cache entry as the entity-body of this outgoing | body stored in the cache entry as the entity-body of this outgoing | |||
skipping to change at page 111, line 14 | skipping to change at page 113, line 14 | |||
agent or client. | agent or client. | |||
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |||
associated with content-codings. This means that qvalues will not | associated with content-codings. This means that qvalues will not | |||
work and are not permitted with x-gzip or x-compress. | work and are not permitted with x-gzip or x-compress. | |||
14.4. Accept-Language | 14.4. Accept-Language | |||
The Accept-Language request-header field is similar to Accept, but | The Accept-Language request-header field is similar to Accept, but | |||
restricts the set of natural languages that are preferred as a | restricts the set of natural languages that are preferred as a | |||
response to the request. Language tags are defined in Section 3.10. | response to the request. Language tags are defined in section | |||
Section 3.10. | ||||
Accept-Language = "Accept-Language" ":" | Accept-Language = "Accept-Language" ":" | |||
1#( language-range [ ";" "q" "=" qvalue ] ) | 1#( language-range [ ";" "q" "=" qvalue ] ) | |||
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |||
Each language-range MAY be given an associated quality value which | Each language-range MAY be given an associated quality value which | |||
represents an estimate of the user's preference for the languages | represents an estimate of the user's preference for the languages | |||
specified by that range. The quality value defaults to "q=1". For | specified by that range. The quality value defaults to "q=1". For | |||
example, | example, | |||
skipping to change at page 125, line 5 | skipping to change at page 127, line 15 | |||
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 | HTTP/1.1 applications that do not support persistent connections MUST | |||
include the "close" connection option in every message. | include the "close" connection option in every message. | |||
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 A.6.2. | See Appendix F.2. | |||
14.11. Content-Encoding | 14.11. Content-Encoding | |||
The Content-Encoding entity-header field is used as a modifier to the | The Content-Encoding entity-header field is used as a modifier to the | |||
media-type. When present, its value indicates what additional | media-type. When present, its value indicates what additional | |||
content codings have been applied to the entity-body, and thus what | content codings have been applied to the entity-body, and thus what | |||
decoding mechanisms must be applied in order to obtain the media-type | decoding mechanisms must be applied in order to obtain the media-type | |||
referenced by the Content-Type header field. Content-Encoding is | referenced by the Content-Type header field. Content-Encoding is | |||
primarily used to allow a document to be compressed without losing | primarily used to allow a document to be compressed without losing | |||
the identity of its underlying media type. | the identity of its underlying media type. | |||
skipping to change at page 130, line 11 | skipping to change at page 132, line 21 | |||
A server sending a response with status code 416 (Requested range not | A server sending a response with status code 416 (Requested range not | |||
satisfiable) SHOULD include a Content-Range field with a byte-range- | satisfiable) SHOULD include a Content-Range field with a byte-range- | |||
resp-spec of "*". The instance-length specifies the current length | resp-spec of "*". The instance-length specifies the current length | |||
of the selected resource. A response with status code 206 (Partial | of the selected resource. A response with status code 206 (Partial | |||
Content) MUST NOT include a Content-Range field with a byte-range- | Content) MUST NOT include a Content-Range field with a byte-range- | |||
resp-spec of "*". | resp-spec of "*". | |||
Examples of byte-content-range-spec values, assuming that the entity | Examples of byte-content-range-spec values, assuming that the entity | |||
contains a total of 1234 bytes: | contains a total of 1234 bytes: | |||
o The first 500 bytes: | . The first 500 bytes: | |||
bytes 0-499/1234 | bytes 0-499/1234 | |||
o The second 500 bytes: | . The second 500 bytes: | |||
bytes 500-999/1234 | bytes 500-999/1234 | |||
o All except for the first 500 bytes: | . All except for the first 500 bytes: | |||
bytes 500-1233/1234 | bytes 500-1233/1234 | |||
o The last 500 bytes: | . The last 500 bytes: | |||
bytes 734-1233/1234 | bytes 734-1233/1234 | |||
When an HTTP message includes the content of a single range (for | When an HTTP message includes the content of a single range (for | |||
example, a response to a request for a single range, or to a request | example, a response to a request for a single range, or to a request | |||
for a set of ranges that overlap without any holes), this content is | for a set of ranges that overlap without any holes), this content is | |||
transmitted with a Content-Range header, and a Content-Length header | transmitted with a Content-Range header, and a Content-Length header | |||
showing the number of bytes actually transferred. For example, | showing the number of bytes actually transferred. For example, | |||
HTTP/1.1 206 Partial content | HTTP/1.1 206 Partial content | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
Content-Range: bytes 21010-47021/47022 | Content-Range: bytes 21010-47021/47022 | |||
Content-Length: 26012 | Content-Length: 26012 | |||
Content-Type: image/gif | Content-Type: image/gif | |||
When an HTTP message includes the content of multiple ranges (for | When an HTTP message includes the content of multiple ranges (for | |||
example, a response to a request for multiple non-overlapping | example, a response to a request for multiple non-overlapping | |||
ranges), these are transmitted as a multipart message. The multipart | ranges), these are transmitted as a multipart message. The multipart | |||
media type used for this purpose is "multipart/byteranges" as defined | media type used for this purpose is "multipart/byteranges" as defined | |||
in Appendix A.2. See Appendix A.6.3 for a compatibility issue. | in Appendix B. See Appendix F.3 for a compatibility issue. | |||
A response to a request for a single range MUST NOT be sent using the | A response to a request for a single range MUST NOT be sent using the | |||
multipart/byteranges media type. A response to a request for | multipart/byteranges media type. A response to a request for | |||
multiple ranges, whose result is a single range, MAY be sent as a | multiple ranges, whose result is a single range, MAY be sent as a | |||
multipart/byteranges media type with one part. A client that cannot | multipart/byteranges media type with one part. A client that cannot | |||
decode a multipart/byteranges message MUST NOT ask for multiple byte- | decode a multipart/byteranges message MUST NOT ask for multiple byte- | |||
ranges in a single request. | ranges in a single request. | |||
When a client requests multiple byte-ranges in one request, the | When a client requests multiple byte-ranges in one request, the | |||
server SHOULD return them in the order that they appeared in the | server SHOULD return them in the order that they appeared in the | |||
skipping to change at page 136, line 22 | skipping to change at page 138, line 30 | |||
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. | |||
See sections 5.2 and A.6.1.1 for other requirements relating to Host. | See sections 5.2 and F.1.1 for other requirements relating to Host. | |||
14.24. If-Match | 14.24. If-Match | |||
The If-Match request-header field is used with a method to make it | The If-Match request-header field is used with a method to make it | |||
conditional. A client that has one or more entities previously | conditional. A client that has one or more entities previously | |||
obtained from the resource can verify that one of those entities is | obtained from the resource can verify that one of those entities is | |||
current by including a list of their associated entity tags in the | current by including a list of their associated entity tags in the | |||
If-Match header field. Entity tags are defined in Section 3.11. The | If-Match header field. Entity tags are defined in Section 3.11. The | |||
purpose of this feature is to allow efficient updates of cached | purpose of this feature is to allow efficient updates of cached | |||
information with a minimum amount of transaction overhead. It is | information with a minimum amount of transaction overhead. It is | |||
skipping to change at page 162, line 8 | skipping to change at page 164, line 8 | |||
If a single server supports multiple organizations that do not trust | If a single server supports multiple organizations that do not trust | |||
one another, then it MUST check the values of Location and Content- | one another, then it MUST check the values of Location and Content- | |||
Location headers in responses that are generated under control of | Location headers in responses that are generated under control of | |||
said organizations to make sure that they do not attempt to | said organizations to make sure that they do not attempt to | |||
invalidate resources over which they have no authority. | invalidate resources over which they have no authority. | |||
15.5. Content-Disposition Issues | 15.5. Content-Disposition Issues | |||
RFC 1806 [35], from which the often implemented Content-Disposition | RFC 1806 [35], from which the often implemented Content-Disposition | |||
(see Appendix A.5.1) header in HTTP is derived, has a number of very | (see Appendix E.1) header in HTTP is derived, has a number of very | |||
serious security considerations. Content-Disposition is not part of | serious security considerations. Content-Disposition is not part of | |||
the HTTP standard, but since it is widely implemented, we are | the HTTP standard, but since it is widely implemented, we are | |||
documenting its use and risks for implementors. See RFC 2183 [49] | documenting its use and risks for implementors. See RFC 2183 [49] | |||
(which updates RFC 1806) for details. | (which updates RFC 1806) for details. | |||
15.6. Authentication Credentials and Idle Clients | 15.6. Authentication Credentials and Idle Clients | |||
Existing HTTP clients and user agents typically retain authentication | Existing HTTP clients and user agents typically retain authentication | |||
information indefinitely. HTTP/1.1. does not provide a method for a | information indefinitely. HTTP/1.1. does not provide a method for a | |||
server to direct clients to discard these cached credentials. This | server to direct clients to discard these cached credentials. This | |||
skipping to change at page 164, line 7 | skipping to change at page 166, line 7 | |||
protect against a broad range of security and privacy attacks. Such | protect against a broad range of security and privacy attacks. Such | |||
cryptography is beyond the scope of the HTTP/1.1 specification. | cryptography is beyond the scope of the HTTP/1.1 specification. | |||
15.7.1. Denial of Service Attacks on Proxies | 15.7.1. Denial of Service Attacks on Proxies | |||
They exist. They are hard to defend against. Research continues. | They exist. They are hard to defend against. Research continues. | |||
Beware. | Beware. | |||
16. Acknowledgments | 16. Acknowledgments | |||
16.1. (RFC2616) | ||||
This specification makes heavy use of the augmented BNF and generic | This specification makes heavy use of the augmented BNF and generic | |||
constructs defined by David H. Crocker for RFC 822 [9]. Similarly, | constructs defined by David H. Crocker for RFC 822 [9]. Similarly, | |||
it reuses many of the definitions provided by Nathaniel Borenstein | it reuses many of the definitions provided by Nathaniel Borenstein | |||
and Ned Freed for MIME [7]. We hope that their inclusion in this | and Ned Freed for MIME [7]. We hope that their inclusion in this | |||
specification will help reduce past confusion over the relationship | specification will help reduce past confusion over the relationship | |||
between HTTP and Internet mail message formats. | between HTTP and Internet mail message formats. | |||
The HTTP protocol has evolved considerably over the years. It has | The HTTP protocol has evolved considerably over the years. It has | |||
benefited from a large and active developer community--the many | benefited from a large and active developer community--the many | |||
people who have participated on the www-talk mailing list--and it is | people who have participated on the www-talk mailing list--and it is | |||
skipping to change at page 166, line 5 | skipping to change at page 168, line 5 | |||
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | |||
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | |||
Larry Masinter for their help. And thanks go particularly to Jeff | Larry Masinter for their help. And thanks go particularly to Jeff | |||
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. | Mogul and Scott Lawrence for 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) | ||||
This document is based on [50], which was authored by Roy T. | ||||
Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, | ||||
Larry Masinter, Paul J. Leach and Tim Berners-Lee. | ||||
17. References | 17. 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 | |||
distributed document search and retrieval protocol)", RFC 1436, | distributed document search and retrieval protocol)", RFC 1436, | |||
March 1993. | March 1993. | |||
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | |||
Unifying Syntax for the Expression of Names and Addresses of | Unifying Syntax for the Expression of Names and Addresses of | |||
skipping to change at page 167, line 16 | skipping to change at page 170, line 17 | |||
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | |||
November 1996. | November 1996. | |||
[15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", | [15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", | |||
RFC 1867, November 1995. | RFC 1867, November 1995. | |||
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | |||
August 1982. | August 1982. | |||
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, | [17] Postel, J., "Media Type Registration Procedure", RFC 1590, | |||
November 1996. | March 1994. | |||
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, | [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, | |||
RFC 959, October 1985. | RFC 959, October 1985. | |||
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, | [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, | |||
RFC 1700, October 1994. | RFC 1700, October 1994. | |||
[20] Masinter, L. and K. Sollins, "Functional Requirements for | [20] Masinter, L. and K. Sollins, "Functional Requirements for | |||
Uniform Resource Names", RFC 1737, December 1994. | Uniform Resource Names", RFC 1737, December 1994. | |||
skipping to change at page 169, line 32 | skipping to change at page 172, 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", | |||
BCP 9, RFC 2026, October 1996. | 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. | |||
Appendix A. Appendices | 17.2. Normative References | |||
A.1. Internet Media Type message/http and application/http | [50] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |||
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | ||||
HTTP/1.1", RFC 2616, June 1999. | ||||
URIs | ||||
[51] <mailto:ietf-http-wg@w3.org> | ||||
[52] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | ||||
Appendix A. Internet Media Type message/http and application/http | ||||
In addition to defining the HTTP/1.1 protocol, this document serves | In addition to defining the HTTP/1.1 protocol, this document serves | |||
as the specification for the Internet media type "message/http" and | as the specification for the Internet media type "message/http" and | |||
"application/http". The message/http type can be used to enclose a | "application/http". The message/http type can be used to enclose a | |||
single HTTP request or response message, provided that it obeys the | single HTTP request or response message, provided that it obeys the | |||
MIME restrictions for all "message" types regarding line length and | MIME restrictions for all "message" types regarding line length and | |||
encodings. The application/http type can be used to enclose a | encodings. The application/http type can be used to enclose a | |||
pipeline of one or more HTTP request or response messages (not | pipeline of one or more HTTP request or response messages (not | |||
intermixed). The following is to be registered with IANA [17]. | intermixed). The following is to be registered with IANA [17]. | |||
skipping to change at page 171, line 15 | skipping to change at page 176, line 5 | |||
msgtype: The message type -- "request" or "response". If not | msgtype: The message type -- "request" or "response". If not | |||
present, the type can be determined from the first line of the | present, the type can be determined from the first line of the | |||
body. | body. | |||
Encoding considerations: HTTP messages enclosed by this type are in | Encoding considerations: HTTP messages enclosed by this type are in | |||
"binary" format; use of an appropriate Content-Transfer-Encoding | "binary" format; use of an appropriate Content-Transfer-Encoding | |||
is required when transmitted via E-mail. | is required when transmitted via E-mail. | |||
Security considerations: none | Security considerations: none | |||
A.2. Internet Media Type multipart/byteranges | Appendix B. Internet Media Type multipart/byteranges | |||
When an HTTP 206 (Partial Content) response message includes the | When an HTTP 206 (Partial Content) response message includes the | |||
content of multiple ranges (a response to a request for multiple non- | content of multiple ranges (a response to a request for multiple non- | |||
overlapping ranges), these are transmitted as a multipart message- | overlapping ranges), these are transmitted as a multipart message- | |||
body. The media type for this purpose is called "multipart/ | body. The media type for this purpose is called "multipart/ | |||
byteranges". | byteranges". | |||
The multipart/byteranges media type includes two or more parts, each | The multipart/byteranges media type includes two or more parts, each | |||
with its own Content-Type and Content-Range fields. The required | with its own Content-Type and Content-Range fields. The required | |||
boundary parameter specifies the boundary string used to separate | boundary parameter specifies the boundary string used to separate | |||
skipping to change at page 172, line 37 | skipping to change at page 178, line 5 | |||
2. Although RFC 2046 [40] permits the boundary string to be quoted, | 2. Although RFC 2046 [40] permits the boundary string to be quoted, | |||
some existing implementations handle a quoted boundary string | some existing implementations handle a quoted boundary string | |||
incorrectly. | incorrectly. | |||
3. A number of browsers and servers were coded to an early draft of | 3. A number of browsers and servers were coded to an early draft of | |||
the byteranges specification to use a media type of multipart/ | the byteranges specification to use a media type of multipart/ | |||
x-byteranges, which is almost, but not quite compatible with the | x-byteranges, which is almost, but not quite compatible with the | |||
version documented in HTTP/1.1. | version documented in HTTP/1.1. | |||
A.3. Tolerant Applications | Appendix C. Tolerant Applications | |||
Although this document specifies the requirements for the generation | Although this document specifies the requirements for the generation | |||
of HTTP/1.1 messages, not all applications will be correct in their | of HTTP/1.1 messages, not all applications will be correct in their | |||
implementation. We therefore recommend that operational applications | implementation. We therefore recommend that operational applications | |||
be tolerant of deviations whenever those deviations can be | be tolerant of deviations whenever those deviations can be | |||
interpreted unambiguously. | interpreted unambiguously. | |||
Clients SHOULD be tolerant in parsing the Status-Line and servers | Clients SHOULD be tolerant in parsing the Status-Line and servers | |||
tolerant when parsing the Request-Line. In particular, they SHOULD | tolerant when parsing the Request-Line. In particular, they SHOULD | |||
accept any amount of SP or HT characters between fields, even though | accept any amount of SP or HT characters between fields, even though | |||
skipping to change at page 173, line 32 | skipping to change at page 179, line 5 | |||
proper value. | proper value. | |||
o All expiration-related calculations MUST be done in GMT. The | o All expiration-related calculations MUST be done in GMT. The | |||
local time zone MUST NOT influence the calculation or comparison | local time zone MUST NOT influence the calculation or comparison | |||
of an age or expiration time. | of an age or expiration time. | |||
o If an HTTP header incorrectly carries a date value with a time | o If an HTTP header incorrectly carries a date value with a time | |||
zone other than GMT, it MUST be converted into GMT using the most | zone other than GMT, it MUST be converted into GMT using the most | |||
conservative possible conversion. | conservative possible conversion. | |||
A.4. Differences Between HTTP Entities and RFC 2045 Entities | Appendix D. Differences Between HTTP Entities and RFC 2045 Entities | |||
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | |||
822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | |||
allow entities to be transmitted in an open variety of | allow entities to be transmitted in an open variety of | |||
representations and with extensible mechanisms. However, RFC 2045 | representations and with extensible mechanisms. However, RFC 2045 | |||
discusses mail, and HTTP has a few features that are different from | discusses mail, and HTTP has a few features that are different from | |||
those described in RFC 2045. These differences were carefully chosen | those described in RFC 2045. These differences were carefully chosen | |||
to optimize performance over binary connections, to allow greater | to optimize performance over binary connections, to allow greater | |||
freedom in the use of new media types, to make date comparisons | freedom in the use of new media types, to make date comparisons | |||
easier, and to acknowledge the practice of some early HTTP servers | easier, and to acknowledge the practice of some early HTTP servers | |||
and clients. | and clients. | |||
This appendix describes specific areas where HTTP differs from RFC | This appendix describes specific areas where HTTP differs from RFC | |||
2045. Proxies and gateways to strict MIME environments SHOULD be | 2045. Proxies and gateways to strict MIME environments SHOULD be | |||
aware of these differences and provide the appropriate conversions | aware of these differences and provide the appropriate conversions | |||
where necessary. Proxies and gateways from MIME environments to HTTP | where necessary. Proxies and gateways from MIME environments to HTTP | |||
also need to be aware of the differences because some conversions | also need to be aware of the differences because some conversions | |||
might be required. | might be required. | |||
A.4.1. MIME-Version | D.1. MIME-Version | |||
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages | |||
MAY include a single MIME-Version general-header field to indicate | MAY include a single MIME-Version general-header field to indicate | |||
what version of the MIME protocol was used to construct the message. | what version of the MIME protocol was used to construct the message. | |||
Use of the MIME-Version header field indicates that the message is in | Use of the MIME-Version header field indicates that the message is in | |||
full compliance with the MIME protocol (as defined in RFC 2045[7]). | full compliance with the MIME protocol (as defined in RFC 2045[7]). | |||
Proxies/gateways are responsible for ensuring full compliance (where | Proxies/gateways are responsible for ensuring full compliance (where | |||
possible) when exporting HTTP messages to strict MIME environments. | possible) when exporting HTTP messages to strict MIME environments. | |||
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |||
MIME version "1.0" is the default for use in HTTP/1.1. However, | MIME version "1.0" is the default for use in HTTP/1.1. However, | |||
HTTP/1.1 message parsing and semantics are defined by this document | HTTP/1.1 message parsing and semantics are defined by this document | |||
and not the MIME specification. | and not the MIME specification. | |||
A.4.2. Conversion to Canonical Form | D.2. Conversion to Canonical Form | |||
RFC 2045 [7] requires that an Internet mail entity be converted to | RFC 2045 [7] requires that an Internet mail entity be converted to | |||
canonical form prior to being transferred, as described in section 4 | canonical form prior to being transferred, as described in section 4 | |||
of RFC 2049 [48]. Section 3.7.1 of this document describes the forms | of RFC 2049 [48]. Section 3.7.1 of this document describes the forms | |||
allowed for subtypes of the "text" media type when transmitted over | allowed for subtypes of the "text" media type when transmitted over | |||
HTTP. RFC 2046 requires that content with a type of "text" represent | HTTP. RFC 2046 requires that content with a type of "text" represent | |||
line breaks as CRLF and forbids the use of CR or LF outside of line | line breaks as CRLF and forbids the use of CR or LF outside of line | |||
break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate | break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate | |||
a line break within text content when a message is transmitted over | a line break within text content when a message is transmitted over | |||
HTTP. | HTTP. | |||
skipping to change at page 174, line 47 | skipping to change at page 180, line 19 | |||
complicated by the presence of a Content-Encoding and by the fact | complicated by the presence of a Content-Encoding and by the fact | |||
that HTTP allows the use of some character sets which do not use | that HTTP allows the use of some character sets which do not use | |||
octets 13 and 10 to represent CR and LF, as is the case for some | octets 13 and 10 to represent CR and LF, as is the case for some | |||
multi-byte character sets. | multi-byte character sets. | |||
Implementors should note that conversion will break any cryptographic | Implementors should note that conversion will break any cryptographic | |||
checksums applied to the original content unless the original content | checksums applied to the original content unless the original content | |||
is already in canonical form. Therefore, the canonical form is | is already in canonical form. Therefore, the canonical form is | |||
recommended for any content that uses such checksums in HTTP. | recommended for any content that uses such checksums in HTTP. | |||
A.4.3. Conversion of Date Formats | D.3. Conversion of Date Formats | |||
HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to | HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to | |||
simplify the process of date comparison. Proxies and gateways from | simplify the process of date comparison. Proxies and gateways from | |||
other protocols SHOULD ensure that any Date header field present in a | other protocols SHOULD ensure that any Date header field present in a | |||
message conforms to one of the HTTP/1.1 formats and rewrite the date | message conforms to one of the HTTP/1.1 formats and rewrite the date | |||
if necessary. | if necessary. | |||
A.4.4. Introduction of Content-Encoding | D.4. Introduction of Content-Encoding | |||
RFC 2045 does not include any concept equivalent to HTTP/1.1's | RFC 2045 does not include any concept equivalent to HTTP/1.1's | |||
Content-Encoding header field. Since this acts as a modifier on the | Content-Encoding header field. Since this acts as a modifier on the | |||
media type, proxies and gateways from HTTP to MIME-compliant | media type, proxies and gateways from HTTP to MIME-compliant | |||
protocols MUST either change the value of the Content-Type header | protocols MUST either change the value of the Content-Type header | |||
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). | |||
A.4.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 non-identity CTE ("quoted-printable" or "base64") | |||
encoding prior to delivering the response message to an HTTP client. | encoding prior to delivering the response message 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. | |||
A.4.6. Introduction of Transfer-Encoding | D.6. Introduction of Transfer-Encoding | |||
HTTP/1.1 introduces the Transfer-Encoding header field | HTTP/1.1 introduces the Transfer-Encoding header field | |||
(Section 14.41). Proxies/gateways MUST remove any transfer-coding | (Section 14.41). Proxies/gateways MUST remove any transfer-coding | |||
prior to forwarding a message via a MIME-compliant protocol. | prior to forwarding a message via a MIME-compliant protocol. | |||
A process for decoding the "chunked" transfer-coding (Section 3.6) | A process for decoding the "chunked" transfer-coding (Section 3.6) | |||
can be represented in pseudo-code as: | can be represented in pseudo-code as: | |||
length := 0 | length := 0 | |||
read chunk-size, chunk-extension (if any) and CRLF | read chunk-size, chunk-extension (if any) and CRLF | |||
skipping to change at page 176, line 21 | skipping to change at page 181, line 30 | |||
read chunk-size and CRLF | read chunk-size and CRLF | |||
} | } | |||
read entity-header | read entity-header | |||
while (entity-header not empty) { | while (entity-header not empty) { | |||
append entity-header to existing header fields | append entity-header to existing header fields | |||
read entity-header | read entity-header | |||
} | } | |||
Content-Length := length | Content-Length := length | |||
Remove "chunked" from Transfer-Encoding | Remove "chunked" from Transfer-Encoding | |||
A.4.7. MHTML and Line Length Limitations | D.7. MHTML and Line Length Limitations | |||
HTTP implementations which share code with MHTML [45] implementations | HTTP implementations which share code with MHTML [45] implementations | |||
need to be aware of MIME line length limitations. Since HTTP does | need to be aware of MIME line length limitations. Since HTTP does | |||
not have this limitation, HTTP does not fold long lines. MHTML | not have this limitation, HTTP does not fold long lines. MHTML | |||
messages being transported by HTTP follow all conventions of MHTML, | messages being transported by HTTP follow all conventions of MHTML, | |||
including line length limitations and folding, canonicalization, | including line length limitations and folding, canonicalization, | |||
etc., since HTTP transports all message-bodies as payload (see | etc., since HTTP transports all message-bodies as payload (see | |||
Section 3.7.2) and does not interpret the content or any MIME header | Section 3.7.2) and does not interpret the content or any MIME header | |||
lines that might be contained therein. | lines that might be contained therein. | |||
A.5. Additional Features | Appendix E. Additional Features | |||
RFC 1945 and RFC 2068 document protocol elements used by some | RFC 1945 and RFC 2068 document protocol elements used by some | |||
existing HTTP implementations, but not consistently and correctly | existing HTTP implementations, but not consistently and correctly | |||
across most HTTP/1.1 applications. Implementors are advised to be | across most HTTP/1.1 applications. Implementors are advised to be | |||
aware of these features, but cannot rely upon their presence in, or | aware of these features, but cannot rely upon their presence in, or | |||
interoperability with, other HTTP/1.1 applications. Some of these | interoperability with, other HTTP/1.1 applications. Some of these | |||
describe proposed experimental features, and some describe features | describe proposed experimental features, and some describe features | |||
that experimental deployment found lacking that are now addressed in | that experimental deployment found lacking that are now addressed in | |||
the base HTTP/1.1 specification. | the base HTTP/1.1 specification. | |||
A number of other headers, such as Content-Disposition and Title, | A number of other headers, such as Content-Disposition and Title, | |||
from SMTP and MIME are also often implemented (see RFC 2076 [37]). | from SMTP and MIME are also often implemented (see RFC 2076 [37]). | |||
A.5.1. Content-Disposition | E.1. Content-Disposition | |||
The Content-Disposition response-header field has been proposed as a | The Content-Disposition response-header field has been proposed as a | |||
means for the origin server to suggest a default filename if the user | means for the origin server to suggest a default filename if the user | |||
requests that the content is saved to a file. This usage is derived | requests that the content is saved to a file. This usage is derived | |||
from the definition of Content-Disposition in RFC 1806 [35]. | from the definition of Content-Disposition in RFC 1806 [35]. | |||
content-disposition = "Content-Disposition" ":" | content-disposition = "Content-Disposition" ":" | |||
disposition-type *( ";" disposition-parm ) | disposition-type *( ";" disposition-parm ) | |||
disposition-type = "attachment" | disp-extension-token | disposition-type = "attachment" | disp-extension-token | |||
disposition-parm = filename-parm | disp-extension-parm | disposition-parm = filename-parm | disp-extension-parm | |||
skipping to change at page 177, line 29 | skipping to change at page 183, line 5 | |||
parameter believed to apply to HTTP implementations at this time. | parameter believed to apply to HTTP implementations at this time. | |||
The filename SHOULD be treated as a terminal component only. | The filename SHOULD be treated as a terminal component only. | |||
If this header is used in a response with the application/ | If this header is used in a response with the application/ | |||
octet-stream content-type, the implied suggestion is that the user | octet-stream content-type, the implied suggestion is that the user | |||
agent should not display the response, but directly enter a `save | agent should not display the response, but directly enter a `save | |||
response as...' dialog. | response as...' dialog. | |||
See Section 15.5 for Content-Disposition security issues. | See Section 15.5 for Content-Disposition security issues. | |||
A.6. Compatibility with Previous Versions | Appendix F. Compatibility with Previous Versions | |||
It is beyond the scope of a protocol specification to mandate | It is beyond the scope of a protocol specification to mandate | |||
compliance with previous versions. HTTP/1.1 was deliberately | compliance with previous versions. HTTP/1.1 was deliberately | |||
designed, however, to make supporting previous versions easy. It is | designed, however, to make supporting previous versions easy. It is | |||
worth noting that, at the time of composing this specification | worth noting that, at the time of composing this specification | |||
(1996), we would expect commercial HTTP/1.1 servers to: | (1996), we would expect commercial HTTP/1.1 servers to: | |||
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | |||
1.1 requests; | 1.1 requests; | |||
skipping to change at page 178, line 8 | skipping to change at page 183, 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]. | |||
A.6.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. | |||
A.6.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 | missing from an HTTP/1.1 request, and accept absolute URIs (section | |||
(Section 5.1.2) are among the most important changes defined by this | 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 179, line 5 | skipping to change at page 184, line 26 | |||
o Both clients and servers MUST support the Host request-header. | o Both clients and servers MUST support the Host request-header. | |||
o A client that sends an HTTP/1.1 request MUST send a Host header. | o A client that sends an HTTP/1.1 request MUST send a Host header. | |||
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | |||
request does not include a Host request-header. | request does not include a Host request-header. | |||
o Servers MUST accept absolute URIs. | o Servers MUST accept absolute URIs. | |||
A.6.2. Compatibility with HTTP/1.0 Persistent Connections | F.2. Compatibility with HTTP/1.0 Persistent Connections | |||
Some clients and servers might wish to be compatible with some | Some clients and servers might wish to be compatible with some | |||
previous implementations of persistent connections in HTTP/1.0 | previous implementations of persistent connections in HTTP/1.0 | |||
clients and servers. Persistent connections in HTTP/1.0 are | clients and servers. Persistent connections in HTTP/1.0 are | |||
explicitly negotiated as they are not the default behavior. HTTP/1.0 | explicitly negotiated as they are not the default behavior. HTTP/1.0 | |||
experimental implementations of persistent connections are faulty, | experimental implementations of persistent connections are faulty, | |||
and the new facilities in HTTP/1.1 are designed to rectify these | and the new facilities in HTTP/1.1 are designed to rectify these | |||
problems. The problem was that some existing 1.0 clients may be | problems. The problem was that some existing 1.0 clients may be | |||
sending Keep-Alive to a proxy server that doesn't understand | sending Keep-Alive to a proxy server that doesn't understand | |||
Connection, which would then erroneously forward it to the next | Connection, which would then erroneously forward it to the next | |||
skipping to change at page 179, line 32 | skipping to change at page 185, line 5 | |||
connections, so that prohibition is clearly unacceptable. Therefore, | connections, so that prohibition is clearly unacceptable. Therefore, | |||
we need some other mechanism for indicating a persistent connection | we need some other mechanism for indicating a persistent connection | |||
is desired, which is safe to use even when talking to an old proxy | is desired, which is safe to use even when talking to an old proxy | |||
that ignores Connection. Persistent connections are the default for | that ignores Connection. Persistent connections are the default for | |||
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | |||
declaring non-persistence. See Section 14.10. | declaring non-persistence. See Section 14.10. | |||
The original HTTP/1.0 form of persistent connections (the Connection: | The original HTTP/1.0 form of persistent connections (the Connection: | |||
Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] | Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] | |||
A.6.3. Changes from RFC 2068 | F.3. Changes from RFC 2068 | |||
This specification has been carefully audited to correct and | This specification has been carefully audited to correct and | |||
disambiguate key word usage; RFC 2068 had many problems in respect to | disambiguate key word usage; RFC 2068 had many problems in respect to | |||
the conventions laid out in RFC 2119 [34]. | the conventions laid out in RFC 2119 [34]. | |||
Clarified which error code should be used for inbound server failures | Clarified which error code should be used for inbound server failures | |||
(e.g. DNS failures). (Section 10.5.5). | (e.g. DNS failures). (Section 10.5.5). | |||
CREATE had a race that required an Etag be sent when a resource is | CREATE had a race that required an Etag be sent when a resource is | |||
first created. (Section 10.2.2). | first created. (Section 10.2.2). | |||
skipping to change at page 183, line 5 | skipping to change at page 188, line 5 | |||
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]. | |||
Appendix B. Index | Appendix G. Change Log (to be removed by RFC Editor before publication) | |||
Please see the PostScript version of this RFC for the INDEX. | G.1. Since RFC2616 | |||
Update Authors. Add Editorial Note and Acknowledgements (containing | ||||
the original RFC2616 authors). Add "Normative References", | ||||
containing just RFC2616 for now. | ||||
Appendix H. Open issues (to be removed by RFC Editor prior to | ||||
publication) | ||||
H.1. rfc2616bis | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes | ||||
with respect to the revision process itself. | ||||
H.2. edit | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-08-10): Umbrella issue for | ||||
editorial fixes/enhancements. | ||||
Index | Index | |||
1 | 1 | |||
100 Continue (status code) 63 | 100 Continue (status code) 65 | |||
101 Switching Protocols (status code) 63 | 101 Switching Protocols (status code) 65 | |||
110 Response is stale (warn code) 156 | ||||
111 Revalidation failed (warn code) 156 | ||||
112 Disconnected operation (warn code) 156 | ||||
113 Heuristic expiration (warn code) 156 | ||||
199 Miscellaneous warning (warn code) 156 | ||||
2 | 2 | |||
200 OK (status code) 64 | 200 OK (status code) 66 | |||
201 Created (status code) 64 | 201 Created (status code) 66 | |||
202 Accepted (status code) 64 | 202 Accepted (status code) 66 | |||
203 Non-Authoritative Information (status code) 65 | 203 Non-Authoritative Information (status code) 67 | |||
204 No Content (status code) 65 | 204 No Content (status code) 67 | |||
205 Reset Content (status code) 65 | 205 Reset Content (status code) 67 | |||
206 Partial Content (status code) 66 | 206 Partial Content (status code) 68 | |||
214 Transformation applied (warn code) 156 | ||||
299 Miscellaneous persistent warning (warn code) 157 | ||||
3 | 3 | |||
300 Multiple Choices (status code) 67 | 300 Multiple Choices (status code) 69 | |||
301 Moved Permanently (status code) 67 | 301 Moved Permanently (status code) 69 | |||
302 Found (status code) 68 | 302 Found (status code) 70 | |||
303 See Other (status code) 68 | 303 See Other (status code) 70 | |||
304 Not Modified (status code) 69 | 304 Not Modified (status code) 71 | |||
305 Use Proxy (status code) 69 | 305 Use Proxy (status code) 71 | |||
306 (Unused) (status code) 70 | 306 (Unused) (status code) 72 | |||
307 Temporary Redirect (status code) 70 | 307 Temporary Redirect (status code) 72 | |||
4 | 4 | |||
400 Bad Request (status code) 71 | 400 Bad Request (status code) 73 | |||
401 Unauthorized (status code) 71 | 401 Unauthorized (status code) 73 | |||
402 Payment Required (status code) 71 | 402 Payment Required (status code) 73 | |||
403 Forbidden (status code) 71 | 403 Forbidden (status code) 73 | |||
404 Not Found (status code) 71 | 404 Not Found (status code) 73 | |||
405 Method Not Allowed (status code) 72 | 405 Method Not Allowed (status code) 74 | |||
406 Not Acceptable (status code) 72 | 406 Not Acceptable (status code) 74 | |||
407 Proxy Authentication Required (status code) 72 | 407 Proxy Authentication Required (status code) 74 | |||
408 Request Timeout (status code) 73 | 408 Request Timeout (status code) 75 | |||
409 Conflict (status code) 73 | 409 Conflict (status code) 75 | |||
410 Gone (status code) 73 | 410 Gone (status code) 75 | |||
411 Length Required (status code) 74 | 411 Length Required (status code) 76 | |||
412 Precondition Failed (status code) 74 | 412 Precondition Failed (status code) 76 | |||
413 Request Entity Too Large (status code) 74 | 413 Request Entity Too Large (status code) 76 | |||
414 Request-URI Too Long (status code) 74 | 414 Request-URI Too Long (status code) 76 | |||
415 Unsupported Media Type (status code) 74 | 415 Unsupported Media Type (status code) 76 | |||
416 Requested Range Not Satisfiable (status code) 74 | 416 Requested Range Not Satisfiable (status code) 76 | |||
417 Expectation Failed (status code) 75 | 417 Expectation Failed (status code) 77 | |||
5 | 5 | |||
500 Internal Server Error (status code) 75 | 500 Internal Server Error (status code) 77 | |||
501 Not Implemented (status code) 75 | 501 Not Implemented (status code) 77 | |||
502 Bad Gateway (status code) 75 | 502 Bad Gateway (status code) 77 | |||
503 Service Unavailable (status code) 76 | 503 Service Unavailable (status code) 78 | |||
504 Gateway Timeout (status code) 76 | 504 Gateway Timeout (status code) 78 | |||
505 HTTP Version Not Supported (status code) 76 | 505 HTTP Version Not Supported (status code) 78 | |||
A | A | |||
Accept header 107 | Accept header 109 | |||
Accept-Charset header 109 | Accept-Charset header 111 | |||
Accept-Encoding header 109 | Accept-Encoding header 111 | |||
Accept-Language header 111 | Accept-Language header 113 | |||
Accept-Ranges header 112 | Accept-Ranges header 114 | |||
Age header 112 | Age header 114 | |||
age 12 | age 14 | |||
Allow header 113 | Allow header 115 | |||
Alternates header 182 | Authorization header 116 | |||
application/http Media Type 170 | ||||
Authorization header 113 | ||||
C | C | |||
Cache Directives | Cache Directives | |||
max-age 119, 121 | max-age 121, 123 | |||
max-stale 119 | max-stale 121 | |||
min-fresh 119 | min-fresh 121 | |||
must-revalidate 121 | must-revalidate 123 | |||
no-cache 117 | no-cache 119 | |||
no-store 117 | no-store 119 | |||
no-transform 122 | no-transform 125 | |||
only-if-cached 121 | only-if-cached 123 | |||
private 116 | private 118 | |||
proxy-revalidate 122 | proxy-revalidate 124 | |||
public 116 | public 118 | |||
s-maxage 118 | s-maxage 120 | |||
cache 11 | cache 13 | |||
Cache-Control header 114 | Cache-Control header 116 | |||
cacheable 11 | cacheable 13 | |||
client 10 | client 12 | |||
compress (content coding) 25 | compress 27 | |||
CONNECT method 62 | CONNECT method 64 | |||
Connection header 124 | Connection header 126 | |||
connection 9 | connection 11 | |||
Content Codings 25 | content negotiation 12 | |||
compress 25 | Content-Encoding header 127 | |||
deflate 26 | Content-Language header 128 | |||
gzip 25 | Content-Length header 128 | |||
identity 26 | Content-Location header 129 | |||
content negotiation 10 | Content-MD5 header 130 | |||
Content-Base header 182 | Content-Range header 131 | |||
Content-Disposition header 176 | Content-Type header 133 | |||
Content-Encoding header 125 | ||||
Content-Language header 125 | ||||
Content-Length header 126 | ||||
Content-Location header 127 | ||||
Content-MD5 header 128 | ||||
Content-Range header 129 | ||||
Content-Type header 131 | ||||
Content-Version header 182 | ||||
D | D | |||
Date header 131 | Date header 133 | |||
deflate (content coding) 26 | deflate 28 | |||
DELETE method 61 | DELETE method 63 | |||
Derived-From header 182 | downstream 15 | |||
downstream 13 | ||||
E | E | |||
entity 9 | entity 11 | |||
ETag header 133 | ETag header 135 | |||
Expect header 133 | Expect header 135 | |||
Expires header 134 | Expires header 136 | |||
explicit expiration time 12 | explicit expiration time 14 | |||
F | F | |||
first-hand 11 | first-hand 13 | |||
fresh 12 | fresh 14 | |||
freshness lifetime 12 | freshness lifetime 14 | |||
From header 135 | From header 137 | |||
G | G | |||
gateway 11 | gateway 13 | |||
GET method 58 | GET method 60 | |||
Grammar | Grammar | |||
Accept 107 | Accept 109 | |||
Accept-Charset 109 | Accept-Charset 111 | |||
Accept-Encoding 109 | Accept-Encoding 111 | |||
accept-extension 107 | accept-extension 109 | |||
Accept-Language 111 | Accept-Language 113 | |||
accept-params 107 | accept-params 109 | |||
Accept-Ranges 112 | Accept-Ranges 114 | |||
acceptable-ranges 112 | acceptable-ranges 114 | |||
Age 113 | Age 115 | |||
age-value 113 | age-value 115 | |||
Allow 113 | Allow 115 | |||
ALPHA 18 | ALPHA 20 | |||
asctime-date 23 | asctime-date 25 | |||
attribute 26 | attribute 28 | |||
Authorization 114 | Authorization 116 | |||
byte-content-range-spec 129 | byte-content-range-spec 131 | |||
byte-range-resp-spec 129 | byte-range-resp-spec 131 | |||
byte-range-set 145 | byte-range-set 147 | |||
byte-range-spec 145 | byte-range-spec 147 | |||
byte-ranges-specifier 145 | byte-ranges-specifier 147 | |||
bytes-unit 33 | bytes-unit 35 | |||
Cache-Control 115 | Cache-Control 117 | |||
cache-directive 115 | cache-directive 117 | |||
cache-extension 115 | cache-extension 117 | |||
cache-request-directive 115 | cache-request-directive 117 | |||
cache-response-directive 115 | cache-response-directive 117 | |||
CHAR 18 | CHAR 20 | |||
charset 24 | charset 26 | |||
chunk 28 | chunk 30 | |||
chunk-data 28 | chunk-data 30 | |||
chunk-ext-name 28 | chunk-ext-name 30 | |||
chunk-ext-val 28 | chunk-ext-val 30 | |||
chunk-extension 28 | chunk-extension 30 | |||
chunk-size 28 | chunk-size 30 | |||
Chunked-Body 28 | Chunked-Body 30 | |||
codings 109 | codings 111 | |||
comment 19 | comment 21 | |||
Connection 124 | Connection 126 | |||
connection-token 124 | connection-token 126 | |||
content-coding 25 | content-coding 27 | |||
content-disposition 177 | content-disposition 182 | |||
Content-Encoding 125 | Content-Encoding 127 | |||
Content-Language 125 | Content-Language 128 | |||
Content-Length 126 | Content-Length 128 | |||
Content-Location 127 | Content-Location 129 | |||
Content-MD5 128 | Content-MD5 130 | |||
Content-Range 129 | Content-Range 131 | |||
content-range-spec 129 | content-range-spec 131 | |||
Content-Type 131 | Content-Type 133 | |||
CR 18 | CR 20 | |||
CRLF 18 | CRLF 20 | |||
ctext 19 | ctext 21 | |||
CTL 18 | CTL 20 | |||
Date 131 | Date 134 | |||
date1 23 | date1 25 | |||
date2 23 | date2 25 | |||
date3 23 | date3 25 | |||
delta-seconds 24 | delta-seconds 26 | |||
DIGIT 18 | DIGIT 20 | |||
disp-extension-parm 177 | disp-extension-parm 182 | |||
disp-extension-token 177 | disp-extension-token 182 | |||
disposition-parm 177 | disposition-parm 182 | |||
disposition-type 177 | disposition-type 182 | |||
entity-body 47 | entity-body 49 | |||
entity-header 47 | entity-header 49 | |||
entity-tag 32 | entity-tag 34 | |||
ETag 133 | ETag 135 | |||
Expect 133 | Expect 135 | |||
expect-params 133 | expect-params 135 | |||
expectation 133 | expectation 135 | |||
expectation-extension 133 | expectation-extension 135 | |||
Expires 134 | Expires 136 | |||
extension-code 45 | extension-code 47 | |||
extension-header 47 | extension-header 49 | |||
extension-method 39 | extension-method 41 | |||
extension-pragma 143 | extension-pragma 145 | |||
field-content 35 | field-content 37 | |||
field-name 35 | field-name 37 | |||
field-value 35 | field-value 37 | |||
filename-parm 177 | filename-parm 182 | |||
first-byte-pos 145 | first-byte-pos 147 | |||
From 135 | From 137 | |||
general-header 38 | general-header 40 | |||
generic-message 34 | generic-message 36 | |||
HEX 19 | HEX 21 | |||
Host 135 | Host 138 | |||
HT 18 | HT 20 | |||
HTTP-date 23 | HTTP-date 25 | |||
HTTP-message 34 | HTTP-message 36 | |||
HTTP-Version 20 | HTTP-Version 22 | |||
http_URL 21 | http_URL 23 | |||
If-Match 136 | If-Match 138 | |||
If-Modified-Since 137 | If-Modified-Since 139 | |||
If-None-Match 139 | If-None-Match 141 | |||
If-Range 140 | If-Range 142 | |||
If-Unmodified-Since 141 | If-Unmodified-Since 143 | |||
instance-length 129 | instance-length 131 | |||
language-range 111 | language-range 113 | |||
language-tag 32 | language-tag 34 | |||
last-byte-pos 145 | last-byte-pos 147 | |||
last-chunk 28 | last-chunk 30 | |||
Last-Modified 141 | Last-Modified 143 | |||
LF 18 | LF 20 | |||
LOALPHA 18 | LOALPHA 20 | |||
Location 142 | Location 144 | |||
LWS 18 | LWS 20 | |||
Max-Forwards 142 | Max-Forwards 145 | |||
md5-digest 128 | md5-digest 130 | |||
media-range 107 | media-range 109 | |||
media-type 29 | media-type 31 | |||
message-body 35 | message-body 37 | |||
message-header 35 | message-header 37 | |||
Method 39 | Method 41 | |||
MIME-Version 174 | MIME-Version 179 | |||
month 23 | month 25 | |||
OCTET 18 | OCTET 20 | |||
opaque-tag 32 | opaque-tag 34 | |||
other-range-unit 33 | other-range-unit 35 | |||
parameter 26 | parameter 28 | |||
Pragma 143 | Pragma 145 | |||
pragma-directive 143 | pragma-directive 145 | |||
primary-tag 32 | primary-tag 34 | |||
product 31 | product 33 | |||
product-version 31 | product-version 33 | |||
protocol-name 153 | protocol-name 155 | |||
protocol-version 153 | protocol-version 155 | |||
Proxy-Authenticate 144 | Proxy-Authenticate 146 | |||
Proxy-Authorization 144 | Proxy-Authorization 146 | |||
pseudonym 153 | pseudonym 155 | |||
qdtext 19 | qdtext 21 | |||
quoted-pair 19 | quoted-pair 21 | |||
quoted-string 19 | quoted-string 21 | |||
qvalue 31 | qvalue 33 | |||
Range 146 | Range 148 | |||
range-unit 33 | range-unit 35 | |||
ranges-specifier 145 | ranges-specifier 147 | |||
Reason-Phrase 45 | Reason-Phrase 47 | |||
received-by 153 | received-by 155 | |||
received-protocol 153 | received-protocol 155 | |||
Referer 147 | Referer 149 | |||
Request 39 | Request 41 | |||
request-header 42 | request-header 44 | |||
Request-Line 39 | Request-Line 41 | |||
Request-URI 40 | Request-URI 42 | |||
Response 43 | Response 45 | |||
response-header 46 | response-header 48 | |||
Retry-After 147 | Retry-After 150 | |||
rfc850-date 23 | rfc850-date 25 | |||
rfc1123-date 23 | rfc1123-date 25 | |||
separators 19 | separators 21 | |||
Server 148 | Server 150 | |||
SP 18 | SP 20 | |||
start-line 34 | start-line 36 | |||
Status-Code 45 | Status-Code 47 | |||
Status-Line 43 | Status-Line 45 | |||
subtag 32 | subtag 34 | |||
subtype 29 | subtype 31 | |||
suffix-byte-range-spec 145 | suffix-byte-range-spec 147 | |||
suffix-length 145 | suffix-length 147 | |||
t-codings 148 | t-codings 151 | |||
TE 148 | TE 151 | |||
TEXT 18 | TEXT 20 | |||
time 23 | time 25 | |||
token 19 | token 21 | |||
Trailer 150 | Trailer 152 | |||
trailer 28 | trailer 30 | |||
transfer-coding 26 | transfer-coding 28 | |||
Transfer-Encoding 150 | Transfer-Encoding 152 | |||
transfer-extension 26 | transfer-extension 28 | |||
type 29 | type 31 | |||
UPALPHA 18 | UPALPHA 20 | |||
Upgrade 151 | Upgrade 153 | |||
User-Agent 152 | User-Agent 154 | |||
value 26 | value 28 | |||
Vary 152 | Vary 154 | |||
Via 153 | Via 155 | |||
warn-agent 155 | warn-agent 157 | |||
warn-code 155 | warn-code 157 | |||
warn-date 155 | warn-date 157 | |||
warn-text 155 | warn-text 157 | |||
Warning 155 | Warning 157 | |||
warning-value 155 | warning-value 157 | |||
weak 32 | weak 34 | |||
weekday 23 | weekday 25 | |||
wkday 23 | wkday 25 | |||
WWW-Authenticate 157 | WWW-Authenticate 159 | |||
gzip (content coding) 25 | gzip 27 | |||
H | H | |||
HEAD method 58 | HEAD method 60 | |||
Headers | Headers | |||
Accept 107 | Accept 109 | |||
Accept-Charset 109 | Accept-Charset 111 | |||
Accept-Encoding 109 | Accept-Encoding 111 | |||
Accept-Language 111 | Accept-Language 113 | |||
Accept-Ranges 112 | Accept-Ranges 114 | |||
Age 112 | Age 114 | |||
Allow 113 | Allow 115 | |||
Alternate 182 | Authorization 116 | |||
Authorization 113 | Cache-Control 116 | |||
Cache-Control 114 | Connection 126 | |||
Connection 124 | Content-Encoding 127 | |||
Content-Base 182 | Content-Language 128 | |||
Content-Disposition 176 | Content-Length 128 | |||
Content-Encoding 125 | Content-Location 129 | |||
Content-Language 125 | Content-MD5 130 | |||
Content-Length 126 | Content-Range 131 | |||
Content-Location 127 | Content-Type 133 | |||
Content-MD5 128 | Date 133 | |||
Content-Range 129 | ETag 135 | |||
Content-Type 131 | Expect 135 | |||
Content-Version 182 | Expires 136 | |||
Date 131 | From 137 | |||
Derived-From 182 | Host 137 | |||
ETag 133 | If-Match 138 | |||
Expect 133 | If-Modified-Since 139 | |||
Expires 134 | If-None-Match 141 | |||
From 135 | If-Range 142 | |||
Host 135 | If-Unmodified-Since 143 | |||
If-Match 136 | Last-Modified 143 | |||
If-Modified-Since 137 | Location 144 | |||
If-None-Match 139 | Max-Forwards 144 | |||
If-Range 140 | Pragma 145 | |||
If-Unmodified-Since 141 | Proxy-Authenticate 146 | |||
Last-Modified 141 | Proxy-Authorization 146 | |||
Link 182 | Range 147 | |||
Location 142 | Referer 149 | |||
Max-Forwards 142 | Retry-After 150 | |||
Pragma 143 | Server 150 | |||
Proxy-Authenticate 144 | TE 151 | |||
Proxy-Authorization 144 | Trailer 152 | |||
Public 182 | Transfer-Encoding 152 | |||
Range 144 | Upgrade 153 | |||
Referer 147 | User-Agent 154 | |||
Retry-After 147 | Vary 154 | |||
Server 148 | Via 155 | |||
TE 148 | Warning 157 | |||
Trailer 149 | WWW-Authenticate 159 | |||
Transfer-Encoding 150 | heuristic expiration time 14 | |||
Upgrade 150 | Host header 137 | |||
URI 182 | ||||
User-Agent 152 | ||||
Vary 152 | ||||
Via 153 | ||||
Warning 154 | ||||
WWW-Authenticate 157 | ||||
heuristic expiration time 12 | ||||
Host header 135 | ||||
I | I | |||
identity (content coding) 26 | identity 28 | |||
If-Match header 136 | If-Match header 138 | |||
If-Modified-Since header 137 | If-Modified-Since header 139 | |||
If-None-Match header 139 | If-None-Match header 141 | |||
If-Range header 140 | If-Range header 142 | |||
If-Unmodified-Since header 141 | If-Unmodified-Since header 143 | |||
inbound 13 | inbound 15 | |||
L | L | |||
Last-Modified header 141 | Last-Modified header 143 | |||
Link header 182 | Location header 144 | |||
LINK method 181 | ||||
Location header 142 | ||||
M | M | |||
max-age | max-age | |||
Cache Directive 119, 121 | Cache Directive 121, 123 | |||
Max-Forwards header 142 | Max-Forwards header 144 | |||
max-stale | max-stale | |||
Cache Directive 119 | Cache Directive 121 | |||
Media Type | message 11 | |||
application/http 170 | ||||
message/http 170 | ||||
multipart/byteranges 171 | ||||
multipart/x-byteranges 172 | ||||
message 9 | ||||
message/http Media Type 170 | ||||
Methods | Methods | |||
CONNECT 62 | CONNECT 64 | |||
DELETE 61 | DELETE 63 | |||
GET 58 | GET 60 | |||
HEAD 58 | HEAD 60 | |||
LINK 181 | OPTIONS 59 | |||
OPTIONS 57 | POST 61 | |||
PATCH 181 | PUT 62 | |||
POST 59 | TRACE 63 | |||
PUT 60 | ||||
TRACE 61 | ||||
UNLINK 181 | ||||
min-fresh | min-fresh | |||
Cache Directive 119 | ||||
multipart/byteranges Media Type 171 | ||||
multipart/x-byteranges Media Type 172 | ||||
must-revalidate | ||||
Cache Directive 121 | Cache Directive 121 | |||
must-revalidate | ||||
Cache Directive 123 | ||||
N | N | |||
no-cache | no-cache | |||
Cache Directive 117 | Cache Directive 119 | |||
no-store | no-store | |||
Cache Directive 117 | Cache Directive 119 | |||
no-transform | no-transform | |||
Cache Directive 122 | Cache Directive 125 | |||
O | O | |||
only-if-cached | only-if-cached | |||
Cache Directive 121 | Cache Directive 123 | |||
OPTIONS method 57 | OPTIONS method 59 | |||
origin server 10 | origin server 12 | |||
outbound 13 | outbound 15 | |||
P | P | |||
PATCH method 181 | POST method 61 | |||
POST method 59 | Pragma header 145 | |||
Pragma header 143 | ||||
private | private | |||
Cache Directive 116 | Cache Directive 118 | |||
proxy 10 | proxy 12 | |||
Proxy-Authenticate header 144 | Proxy-Authenticate header 146 | |||
Proxy-Authorization header 144 | Proxy-Authorization header 146 | |||
proxy-revalidate | proxy-revalidate | |||
Cache Directive 122 | Cache Directive 124 | |||
Public header 182 | ||||
public | public | |||
Cache Directive 116 | Cache Directive 118 | |||
PUT method 60 | PUT method 62 | |||
R | R | |||
Range header 144 | Range header 147 | |||
Referer header 147 | Referer header 149 | |||
representation 9 | representation 11 | |||
request 9 | request 11 | |||
resource 9 | resource 11 | |||
response 9 | response 11 | |||
Retry-After header 147 | Retry-After header 150 | |||
S | S | |||
s-maxage | s-maxage | |||
Cache Directive 118 | Cache Directive 120 | |||
semantically transparent 12 | semantically transparent 14 | |||
Server header 148 | Server header 150 | |||
server 10 | server 12 | |||
stale 12 | stale 14 | |||
Status Codes | Status Codes | |||
100 Continue 63 | 100 Continue 65 | |||
101 Switching Protocols 63 | 101 Switching Protocols 65 | |||
200 OK 64 | 200 OK 66 | |||
201 Created 64 | 201 Created 66 | |||
202 Accepted 64 | 202 Accepted 66 | |||
203 Non-Authoritative Information 65 | 203 Non-Authoritative Information 67 | |||
204 No Content 65 | 204 No Content 67 | |||
205 Reset Content 65 | 205 Reset Content 67 | |||
206 Partial Content 66 | 206 Partial Content 68 | |||
300 Multiple Choices 67 | 300 Multiple Choices 69 | |||
301 Moved Permanently 67 | 301 Moved Permanently 69 | |||
302 Found 68 | 302 Found 70 | |||
303 See Other 68 | 303 See Other 70 | |||
304 Not Modified 69 | 304 Not Modified 71 | |||
305 Use Proxy 69 | 305 Use Proxy 71 | |||
306 (Unused) 70 | 306 (Unused) 72 | |||
307 Temporary Redirect 70 | 307 Temporary Redirect 72 | |||
400 Bad Request 71 | 400 Bad Request 73 | |||
401 Unauthorized 71 | 401 Unauthorized 73 | |||
402 Payment Required 71 | 402 Payment Required 73 | |||
403 Forbidden 71 | 403 Forbidden 73 | |||
404 Not Found 71 | 404 Not Found 73 | |||
405 Method Not Allowed 72 | 405 Method Not Allowed 74 | |||
406 Not Acceptable 72 | 406 Not Acceptable 74 | |||
407 Proxy Authentication Required 72 | 407 Proxy Authentication Required 74 | |||
408 Request Timeout 73 | 408 Request Timeout 75 | |||
409 Conflict 73 | 409 Conflict 75 | |||
410 Gone 73 | 410 Gone 75 | |||
411 Length Required 74 | 411 Length Required 76 | |||
412 Precondition Failed 74 | 412 Precondition Failed 76 | |||
413 Request Entity Too Large 74 | 413 Request Entity Too Large 76 | |||
414 Request-URI Too Long 74 | 414 Request-URI Too Long 76 | |||
415 Unsupported Media Type 74 | 415 Unsupported Media Type 76 | |||
416 Requested Range Not Satisfiable 74 | 416 Requested Range Not Satisfiable 76 | |||
417 Expectation Failed 75 | 417 Expectation Failed 77 | |||
500 Internal Server Error 75 | 500 Internal Server Error 77 | |||
501 Not Implemented 75 | 501 Not Implemented 77 | |||
502 Bad Gateway 75 | 502 Bad Gateway 77 | |||
503 Service Unavailable 76 | 503 Service Unavailable 78 | |||
504 Gateway Timeout 76 | 504 Gateway Timeout 78 | |||
505 HTTP Version Not Supported 76 | 505 HTTP Version Not Supported 78 | |||
T | T | |||
TE header 148 | TE header 151 | |||
TRACE method 61 | TRACE method 63 | |||
Trailer header 149 | Trailer header 152 | |||
Transfer-Encoding header 150 | Transfer-Encoding header 152 | |||
tunnel 11 | tunnel 13 | |||
U | U | |||
UNLINK method 181 | Upgrade header 153 | |||
Upgrade header 150 | upstream 15 | |||
upstream 13 | user agent 12 | |||
URI header 182 | User-Agent header 154 | |||
user agent 10 | ||||
User-Agent header 152 | ||||
V | V | |||
validator 12 | validator 14 | |||
variant 10 | variant 12 | |||
Vary header 152 | Vary header 154 | |||
Via header 153 | Via header 155 | |||
W | W | |||
Warn Codes | Warning header 157 | |||
110 Response is stale 156 | WWW-Authenticate header 159 | |||
111 Revalidation failed 156 | ||||
112 Disconnected operation 156 | ||||
113 Heuristic expiration 156 | ||||
199 Miscellaneous warning 156 | ||||
214 Transformation applied 156 | ||||
299 Miscellaneous persistent warning 157 | ||||
Warning header 154 | ||||
WWW-Authenticate header 157 | ||||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding | Yves Lafon | |||
Department of Information and Computer Science | ||||
University of California, Irvine | ||||
Irvine, CA 92697-3425 | ||||
Fax: +1(949)824-1715 | ||||
Email: fielding@ics.uci.edu | ||||
James Gettys | ||||
World Wide Web Consortium | ||||
MIT Laboratory for Computer Science, NE43-356 | ||||
545 Technology Square | ||||
Cambridge, MA 02139 | ||||
Fax: +1(617)258-8682 | ||||
Email: jg@w3.org | ||||
Jeffrey C. Mogul | ||||
Compaq Computer Corporation | ||||
Western Research Laboratory | ||||
250 University Avenue | ||||
Palo Alto, CA 94305 | ||||
Email: mogul@wrl.dec.com | ||||
Henrik Frystyk Nielsen | ||||
World Wide Web Consortium | World Wide Web Consortium | |||
MIT Laboratory for Computer Science, NE43-356 | 2004, Route des Lucioles | |||
545 Technology Square | Sophia Antipolis 06902 | |||
Cambridge, MA 02139 | France | |||
Fax: +1(617)258-8682 | ||||
Email: frystyk@w3.org | ||||
Larry Masinter | ||||
Xerox Corporation | ||||
MIT Laboratory for Computer Science, NE43-356 | ||||
3333 Coyote Hill Road | ||||
Palo Alto, CA 94034 | ||||
Email: masinter@parc.xerox.com | ||||
Paul J. Leach | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052 | ||||
Email: paulle@microsoft.com | Phone: +33 492387943 | |||
Fax: +33 492387822 | ||||
Email: ylafon@w3.org | ||||
URI: http://www.w3.org/ | ||||
Tim Berners-Lee | Julian F. Reschke | |||
World Wide Web Consortium | greenbytes GmbH | |||
MIT Laboratory for Computer Science, NE43-356 | Hafenweg 16 | |||
545 Technology Square | Muenster, NW 48155 | |||
Cambridge, MA 02139 | Germany | |||
Fax: +1(617)258-8682 | Phone: +49 251 2807760 | |||
Email: timbl@w3.org | Fax: +49 251 2807761 | |||
Email: julian.reschke@greenbytes.de | ||||
URI: http://greenbytes.de/tech/webdav/ | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (1999). | Copyright (C) The IETF Trust (2006). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Intellectual Property | Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
End of changes. 100 change blocks. | ||||
879 lines changed or deleted | 893 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/ |