rfc2616.txt | draft-lafon-rfc2616bis-03.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding | Network Working Group R. Fielding | |||
Request for Comments: 2616 UC Irvine | Internet-Draft Day Software | |||
Obsoletes: 2068 J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Category: Standards Track Compaq/W3C | Intended status: Standards Track J. Mogul | |||
J. Mogul | Expires: January 1, 2008 HP | |||
Compaq | ||||
H. Frystyk | H. Frystyk | |||
W3C/MIT | Microsoft | |||
L. Masinter | L. Masinter | |||
Xerox | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
June 1999 | Y. Lafon, Ed. | |||
W3C | ||||
J. Reschke, Ed. | ||||
greenbytes | ||||
June 30, 2007 | ||||
Hypertext Transfer Protocol -- HTTP/1.1 | Hypertext Transfer Protocol -- HTTP/1.1 | |||
draft-lafon-rfc2616bis-03 | ||||
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 January 1, 2008. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (1999). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. It is a generic, stateless, protocol which can be used for | systems. It is a generic, stateless, protocol which can be used for | |||
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 [RFC2324]. A feature of | |||
the typing and negotiation of data representation, allowing systems | HTTP is the typing and negotiation of data representation, allowing | |||
to be built independently of the data being transferred. | systems 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 [1], which may be joined by sending a message | ||||
with subject "subscribe" to ietf-http-wg-request@w3.org [2]. | ||||
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/rfc2616bis/>. | ||||
The purpose of this document is to revise [RFC2616], 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 [RFC2026]). | ||||
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://purl.org/NET/http-errata>) (most of the | ||||
suggested fixes have been applied to draft 01 [3]). | ||||
o Incorporate corrections for newly discovered and agreed-upon | ||||
problems, using the HTTP WG mailing list as forum and | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/> as | ||||
issues list. | ||||
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 . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 9 | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 13 | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17 | |||
2. Notational Conventions and Generic Grammar . . . . . . . . . 16 | 2. Notational Conventions and Generic Grammar . . . . . . . . . 20 | |||
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 16 | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 20 | |||
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 18 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 20 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 25 | |||
3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 21 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 25 | |||
3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 21 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 26 | |||
3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 22 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 26 | |||
3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 22 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 27 | |||
3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 22 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 27 | |||
3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 24 | 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 28 | |||
3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 24 | 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 28 | |||
3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 25 | 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 29 | |||
3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 25 | 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 30 | |||
3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 26 | 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 31 | |||
3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 27 | 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 32 | |||
3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 29 | 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.7.1. Canonicalization and Text Defaults . . . . . . . . . 29 | 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 34 | |||
3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 30 | 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 34 | |||
3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 31 | 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 35 | |||
3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 31 | 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 32 | 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 32 | 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 37 | |||
3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 33 | 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 37 | |||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . 42 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 39 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 39 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 40 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 45 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . 41 | 5.2. The Resource Identified by a Request . . . . . . . . . . 46 | |||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 42 | 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 47 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 48 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 48 | |||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 46 | 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 51 | |||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 47 | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 52 | |||
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 52 | |||
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 48 | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 53 | |||
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 49 | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 54 | |||
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 49 | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 54 | |||
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 49 | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 54 | |||
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 51 | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 56 | |||
8.1.4. Practical Considerations . . . . . . . . . . . . . . 51 | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 56 | |||
8.2. Message Transmission Requirements . . . . . . . . . . . 52 | 8.2. Message Transmission Requirements . . . . . . . . . . . 57 | |||
8.2.1. Persistent Connections and Flow Control . . . . . . 52 | 8.2.1. Persistent Connections and Flow Control . . . . . . 57 | |||
8.2.2. Monitoring Connections for Error Status Messages . . 52 | 8.2.2. Monitoring Connections for Error Status Messages . . 57 | |||
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 53 | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 58 | |||
8.2.4. Client Behavior if Server Prematurely Closes | 8.2.4. Client Behavior if Server Prematurely Closes | |||
Connection . . . . . . . . . . . . . . . . . . . . . 55 | Connection . . . . . . . . . . . . . . . . . . . . . 60 | |||
9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 56 | 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 | |||
9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 56 | 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 61 | |||
9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 56 | 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 61 | |||
9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 56 | 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 61 | |||
9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 57 | 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 67 | |||
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 63 | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 68 | |||
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 63 | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 68 | |||
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 63 | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 68 | |||
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 63 | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 68 | |||
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 64 | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 64 | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 64 | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 64 | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 65 | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 70 | |||
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 65 | 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 70 | |||
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 65 | 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 70 | |||
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 66 | 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 71 | |||
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 66 | 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 71 | |||
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 67 | 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 72 | |||
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 67 | 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 72 | |||
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 68 | 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 73 | |||
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 68 | 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 73 | |||
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 69 | 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74 | |||
10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 69 | 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 74 | |||
10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 70 | 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 75 | |||
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 70 | 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 75 | |||
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 70 | 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75 | |||
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 71 | 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 76 | |||
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 71 | 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 76 | |||
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 71 | 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 76 | |||
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 71 | 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 76 | |||
10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 71 | 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 76 | |||
10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 72 | 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 77 | |||
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 72 | 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 77 | |||
10.4.8. 407 Proxy Authentication Required . . . . . . . . . 72 | 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 77 | |||
10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 73 | 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 78 | |||
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 73 | 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 78 | |||
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 73 | 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 78 | |||
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 74 | 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 79 | |||
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 74 | 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 79 | |||
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 74 | 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 79 | |||
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 74 | 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 79 | |||
10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 74 | 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 79 | |||
10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 74 | 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 79 | |||
10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 75 | 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 80 | |||
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 75 | 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80 | |||
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 75 | 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 80 | |||
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 75 | 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 80 | |||
10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 75 | 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 80 | |||
10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 76 | 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 81 | |||
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 76 | 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 81 | |||
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 76 | 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 81 | |||
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 77 | 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 82 | |||
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 78 | 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 83 | |||
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 78 | 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 83 | |||
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 79 | 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 84 | |||
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 80 | 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 85 | |||
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 81 | 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 86 | |||
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 | 13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 | |||
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 82 | 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 87 | |||
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 83 | 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 88 | |||
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 84 | 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 89 | |||
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 84 | 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 89 | |||
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 85 | 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 90 | |||
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 85 | 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 90 | |||
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 86 | 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 91 | |||
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 86 | 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 91 | |||
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 86 | 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 91 | |||
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 87 | 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 92 | |||
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 89 | 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 94 | |||
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 90 | 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 95 | |||
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 91 | 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 96 | |||
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 91 | 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 96 | |||
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 92 | 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 97 | |||
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 92 | 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 97 | |||
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 93 | 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 98 | |||
13.3.4. Rules for When to Use Entity Tags and | 13.3.4. Rules for When to Use Entity Tags and | |||
Last-Modified Dates . . . . . . . . . . . . . . . . 95 | Last-Modified Dates . . . . . . . . . . . . . . . . 100 | |||
13.3.5. Non-validating Conditionals . . . . . . . . . . . . 97 | 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 102 | |||
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 97 | 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 102 | |||
13.5. Constructing Responses From Caches . . . . . . . . . . . 98 | 13.5. Constructing Responses From Caches . . . . . . . . . . . 103 | |||
13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 98 | 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 103 | |||
13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 99 | 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 104 | |||
13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 100 | 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 105 | |||
13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 101 | 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 106 | |||
13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 102 | 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 107 | |||
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 103 | 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 108 | |||
13.8. Errors or Incomplete Response Cache Behavior . . . . . . 103 | 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 108 | |||
13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 104 | 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 109 | |||
13.10. Invalidation After Updates or Deletions . . . . . . . . 104 | 13.10. Invalidation After Updates or Deletions . . . . . . . . 109 | |||
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 105 | 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 110 | |||
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 105 | 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 110 | |||
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 106 | 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 111 | |||
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 107 | 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 112 | |||
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 107 | 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112 | |||
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 109 | 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 114 | |||
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 109 | 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114 | |||
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 111 | 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 116 | |||
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 112 | 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 117 | |||
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 112 | 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 117 | |||
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 113 | 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118 | |||
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 113 | 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 118 | |||
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 114 | 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 119 | |||
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 116 | 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 121 | |||
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 117 | 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 122 | |||
14.9.3. Modifications of the Basic Expiration Mechanism . . 118 | 14.9.3. Modifications of the Basic Expiration Mechanism . . 123 | |||
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 120 | 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 125 | |||
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 122 | 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 127 | |||
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 123 | 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 128 | |||
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 124 | 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 129 | |||
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125 | 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 130 | |||
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 125 | 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 130 | |||
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 126 | 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 131 | |||
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 127 | 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 132 | |||
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 128 | 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 129 | 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 134 | |||
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 131 | 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 136 | |||
14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 131 | 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 136 | |||
14.18.1. Clockless Origin Server Operation . . . . . . . . . 132 | 14.18.1. Clockless Origin Server Operation . . . . . . . . . 137 | |||
14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 133 | 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 133 | 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 134 | 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 139 | |||
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 140 | |||
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 140 | |||
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 136 | 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 141 | |||
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137 | 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 142 | |||
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 139 | 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 140 | 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 145 | |||
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 141 | 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 146 | |||
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 141 | 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 146 | |||
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 142 | 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 142 | 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 148 | |||
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 143 | 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 148 | |||
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 144 | 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 149 | |||
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144 | 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 149 | |||
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 144 | 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 150 | |||
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 144 | 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 150 | |||
14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 146 | 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 151 | |||
14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 147 | 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 152 | |||
14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 147 | 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 153 | |||
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 153 | |||
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 149 | 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 155 | |||
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 150 | 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 155 | |||
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 150 | 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 156 | |||
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 153 | 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 158 | |||
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 154 | 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 160 | |||
14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157 | 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 162 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 158 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 163 | |||
15.1. Personal Information . . . . . . . . . . . . . . . . . . 158 | 15.1. Personal Information . . . . . . . . . . . . . . . . . . 163 | |||
15.1.1. Abuse of Server Log Information . . . . . . . . . . 158 | 15.1.1. Abuse of Server Log Information . . . . . . . . . . 163 | |||
15.1.2. Transfer of Sensitive Information . . . . . . . . . 158 | 15.1.2. Transfer of Sensitive Information . . . . . . . . . 163 | |||
15.1.3. Encoding Sensitive Information in URI's . . . . . . 159 | 15.1.3. Encoding Sensitive Information in URI's . . . . . . 164 | |||
15.1.4. Privacy Issues Connected to Accept Headers . . . . . 160 | 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 165 | |||
15.2. Attacks Based On File and Path Names . . . . . . . . . . 160 | 15.2. Attacks Based On File and Path Names . . . . . . . . . . 165 | |||
15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 161 | 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 166 | |||
15.4. Location Headers and Spoofing . . . . . . . . . . . . . 161 | 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 166 | |||
15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 162 | 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 167 | |||
15.6. Authentication Credentials and Idle Clients . . . . . . 162 | 15.6. Authentication Credentials and Idle Clients . . . . . . 167 | |||
15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 162 | 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 167 | |||
15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 163 | 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 168 | |||
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 | 16.1. (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 170 | 16.2. (This Document) . . . . . . . . . . . . . . . . . . . . 170 | |||
A.1. Internet Media Type message/http and application/http . 170 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 171 | |||
A.2. Internet Media Type multipart/byteranges . . . . . . . . 171 | 17.1. References (to be classified) . . . . . . . . . . . . . 171 | |||
A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 172 | 17.2. Informative References . . . . . . . . . . . . . . . . . 174 | |||
A.4. Differences Between HTTP Entities and RFC 2045 | Appendix A. Internet Media Type message/http and | |||
Entities . . . . . . . . . . . . . . . . . . . . . . . . 173 | application/http . . . . . . . . . . . . . . . . . . 177 | |||
A.4.1. MIME-Version . . . . . . . . . . . . . . . . . . . . 174 | Appendix B. Internet Media Type multipart/byteranges . . . . . . 179 | |||
A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 174 | Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 181 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 182 | |||
A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 175 | D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 182 | |||
A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 175 | D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 182 | |||
A.4.7. MHTML and Line Length Limitations . . . . . . . . . 176 | D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 183 | |||
A.5. Additional Features . . . . . . . . . . . . . . . . . . 176 | D.4. Introduction of Content-Encoding . . . . . . . . . . . . 183 | |||
A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 176 | D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 183 | |||
A.6. Compatibility with Previous Versions . . . . . . . . . . 177 | D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 184 | |||
A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 178 | D.7. MHTML and Line Length Limitations . . . . . . . . . . . 184 | |||
A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 179 | Appendix E. Additional Features . . . . . . . . . . . . . . . . 185 | |||
A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 179 | E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 185 | |||
Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 183 | Appendix F. Compatibility with Previous Versions . . . . . . . . 186 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 | F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 186 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 196 | F.1.1. Changes to Simplify Multi-homed Web Servers and | |||
Intellectual Property and Copyright Statements . . . . . . . . . 198 | Conserve IP Addresses . . . . . . . . . . . . . . . 186 | |||
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 187 | ||||
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 188 | ||||
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 190 | ||||
Appendix G. Change Log (to be removed by RFC Editor before | ||||
publication) . . . . . . . . . . . . . . . . . . . . 192 | ||||
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 192 | ||||
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 192 | ||||
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 192 | ||||
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 192 | ||||
Appendix H. Resolved issues (to be removed by RFC Editor | ||||
before publication) . . . . . . . . . . . . . . . . 194 | ||||
H.1. i45-rfc977-reference . . . . . . . . . . . . . . . . . . 194 | ||||
H.2. i46-rfc1700_remove . . . . . . . . . . . . . . . . . . . 194 | ||||
H.3. i47-inconsistency-in-date-format-explanation . . . . . . 194 | ||||
H.4. i49-connection-header-text . . . . . . . . . . . . . . . 195 | ||||
H.5. i48-date-reference-typo . . . . . . . . . . . . . . . . 195 | ||||
Appendix I. Open issues (to be removed by RFC Editor prior to | ||||
publication) . . . . . . . . . . . . . . . . . . . . 197 | ||||
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 197 | ||||
I.2. unneeded_references . . . . . . . . . . . . . . . . . . 197 | ||||
I.3. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 197 | ||||
I.4. i66-iso8859-1-reference . . . . . . . . . . . . . . . . 197 | ||||
I.5. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 197 | ||||
I.6. rfc2048_informative_and_obsolete . . . . . . . . . . . . 198 | ||||
I.7. i34-updated-reference-for-uris . . . . . . . . . . . . . 198 | ||||
I.8. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 198 | ||||
I.9. i65-informative-references . . . . . . . . . . . . . . . 198 | ||||
I.10. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 199 | ||||
I.11. i63-header-length-limit-with-encoded-words . . . . . . . 200 | ||||
I.12. i31-qdtext-bnf . . . . . . . . . . . . . . . . . . . . . 200 | ||||
I.13. i62-whitespace-in-quoted-pair . . . . . . . . . . . . . 200 | ||||
I.14. i58-what-identifies-an-http-resource . . . . . . . . . . 201 | ||||
I.15. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 201 | ||||
I.16. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 201 | ||||
I.17. media-reg . . . . . . . . . . . . . . . . . . . . . . . 201 | ||||
I.18. languagetag . . . . . . . . . . . . . . . . . . . . . . 202 | ||||
I.19. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 202 | ||||
I.20. i57-status-code-and-reason-phrase . . . . . . . . . . . 202 | ||||
I.21. i59-status-code-registry . . . . . . . . . . . . . . . . 203 | ||||
I.22. i21-put-side-effects . . . . . . . . . . . . . . . . . . 203 | ||||
I.23. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 203 | ||||
I.24. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 203 | ||||
I.25. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 203 | ||||
I.26. i25-accept-encoding-bnf . . . . . . . . . . . . . . . . 204 | ||||
I.27. i61-redirection-vs-location . . . . . . . . . . . . . . 204 | ||||
I.28. fragment-combination . . . . . . . . . . . . . . . . . . 205 | ||||
I.29. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 205 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 218 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 221 | ||||
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 | |||
across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved | across the Internet. HTTP/1.0, as defined by [RFC1945], improved the | |||
the protocol by allowing messages to be in the format of MIME-like | protocol by allowing messages to be in the format of MIME-like | |||
messages, containing metainformation about the data transferred and | messages, containing metainformation about the data transferred and | |||
modifiers on the request/response semantics. However, HTTP/1.0 does | modifiers on the request/response semantics. However, HTTP/1.0 does | |||
not sufficiently take into consideration the effects of hierarchical | not sufficiently take into consideration the effects of hierarchical | |||
proxies, caching, the need for persistent connections, or virtual | proxies, caching, the need for persistent connections, or virtual | |||
hosts. In addition, the proliferation of incompletely-implemented | hosts. In addition, the proliferation of incompletely-implemented | |||
applications calling themselves "HTTP/1.0" has necessitated a | applications calling themselves "HTTP/1.0" has necessitated a | |||
protocol version change in order for two communicating applications | protocol version change in order for two communicating applications | |||
to determine each other's true capabilities. | to determine each other's true capabilities. | |||
This specification defines the protocol referred to as "HTTP/1.1". | This specification defines the protocol referred to as "HTTP/1.1". | |||
This protocol includes more stringent requirements than HTTP/1.0 in | This protocol includes more stringent requirements than HTTP/1.0 in | |||
order to ensure reliable implementation of its features. | order to ensure reliable implementation of its features. | |||
Practical information systems require more functionality than simple | Practical information systems require more functionality than simple | |||
retrieval, including search, front-end update, and annotation. HTTP | retrieval, including search, front-end update, and annotation. HTTP | |||
allows an open-ended set of methods and headers that indicate the | allows an open-ended set of methods and headers that indicate the | |||
purpose of a request [47]. It builds on the discipline of reference | purpose of a request [RFC2324]. It builds on the discipline of | |||
provided by the Uniform Resource Identifier (URI) [3], as a location | reference provided by the Uniform Resource Identifier (URI) | |||
(URL) [4] or name (URN) [20], for indicating the resource to which a | [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for | |||
method is to be applied. Messages are passed in a format similar to | indicating the resource to which a method is to be applied. Messages | |||
that used by Internet mail [9] as defined by the Multipurpose | are passed in a format similar to that used by Internet mail [RFC822] | |||
Internet Mail Extensions (MIME) [7]. | as defined by the Multipurpose Internet Mail Extensions (MIME) | |||
[RFC2045]. | ||||
HTTP is also used as a generic protocol for communication between | HTTP is also used as a generic protocol for communication between | |||
user agents and proxies/gateways to other Internet systems, including | user agents and proxies/gateways to other Internet systems, including | |||
those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], | those supported by the SMTP [RFC821], NNTP [RFC3977], FTP [RFC959], | |||
and WAIS [10] protocols. In this way, HTTP allows basic hypermedia | Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP | |||
access to resources available from diverse applications. | allows basic hypermedia access to resources available from diverse | |||
applications. | ||||
1.2. Requirements | 1.2. Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [34]. | document are to be interpreted as described in [RFC2119]. | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the MUST or REQUIRED level requirements for the protocols it | of the MUST or REQUIRED level requirements for the protocols it | |||
implements. An implementation that satisfies all the MUST or | implements. An implementation that satisfies all the MUST or | |||
REQUIRED level and all the SHOULD level requirements for its | REQUIRED level and all the SHOULD level requirements for its | |||
protocols is said to be "unconditionally compliant"; one that | protocols is said to be "unconditionally compliant"; one that | |||
satisfies all the MUST level requirements but not all the SHOULD | satisfies all the MUST level requirements but not all the SHOULD | |||
level requirements for its protocols is said to be "conditionally | level requirements for its protocols is said to be "conditionally | |||
compliant." | compliant." | |||
skipping to change at page 10, line 19 | skipping to change at page 14, line 19 | |||
The mechanism for selecting the appropriate representation when | The mechanism for selecting the appropriate representation when | |||
servicing a request, as described in Section 12. The | servicing a request, as described in Section 12. The | |||
representation of entities in any response can be negotiated | representation of entities in any response can be negotiated | |||
(including error responses). | (including error responses). | |||
variant | variant | |||
A resource may have one, or more than one, representation(s) | A resource may have one, or more than one, representation(s) | |||
associated with it at any given instant. Each of these | associated with it at any given instant. Each of these | |||
representations is termed a `varriant'. Use of the term `variant' | representations is termed a `variant'. Use of the term `variant' | |||
does not necessarily imply that the resource is subject to content | does not necessarily imply that the resource is subject to content | |||
negotiation. | negotiation. | |||
client | client | |||
A program that establishes connections for the purpose of sending | A program that establishes connections for the purpose of sending | |||
requests. | requests. | |||
user agent | user agent | |||
skipping to change at page 13, line 27 | skipping to change at page 17, 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 15, line 4 | skipping to change at page 19, line 4 | |||
subsets of cached data via CD-ROM, and so on. HTTP systems are used | subsets of cached data via CD-ROM, and so on. HTTP systems are used | |||
in corporate intranets over high-bandwidth links, and for access via | in corporate intranets over high-bandwidth links, and for access via | |||
PDAs with low-power radio links and intermittent connectivity. The | PDAs with low-power radio links and intermittent connectivity. The | |||
goal of HTTP/1.1 is to support the wide diversity of configurations | goal of HTTP/1.1 is to support the wide diversity of configurations | |||
already deployed while introducing protocol constructs that meet the | already deployed while introducing protocol constructs that meet the | |||
needs of those who build web applications that require high | needs of those who build web applications that require high | |||
reliability and, failing that, at least reliable indications of | reliability and, failing that, at least reliable indications of | |||
failure. | failure. | |||
HTTP communication usually takes place over TCP/IP connections. The | HTTP communication usually takes place over TCP/IP connections. The | |||
default port is TCP 80 [19], but other ports can be used. This does | default port is TCP 80 | |||
not preclude HTTP from being implemented on top of any other protocol | (<http://www.iana.org/assignments/port-numbers>), but other ports can | |||
on the Internet, or on other networks. HTTP only presumes a reliable | be used. This does not preclude HTTP from being implemented on top | |||
transport; any protocol that provides such guarantees can be used; | of any other protocol on the Internet, or on other networks. HTTP | |||
the mapping of the HTTP/1.1 request and response structures onto the | only presumes a reliable transport; any protocol that provides such | |||
transport data units of the protocol in question is outside the scope | guarantees can be used; the mapping of the HTTP/1.1 request and | |||
of this specification. | response structures onto the transport data units of the protocol in | |||
question is outside the scope of this specification. | ||||
In HTTP/1.0, most implementations used a new connection for each | In HTTP/1.0, most implementations used a new connection for each | |||
request/response exchange. In HTTP/1.1, a connection may be used for | request/response exchange. In HTTP/1.1, a connection may be used for | |||
one or more request/response exchanges, although connections may be | one or more request/response exchanges, although connections may be | |||
closed for a variety of reasons (see Section 8.1). | closed for a variety of reasons (see Section 8.1). | |||
2. Notational Conventions and Generic Grammar | 2. Notational Conventions and Generic Grammar | |||
2.1. Augmented BNF | 2.1. Augmented BNF | |||
All of the mechanisms specified in this document are described in | All of the mechanisms specified in this document are described in | |||
both prose and an augmented Backus-Naur Form (BNF) similar to that | both prose and an augmented Backus-Naur Form (BNF) similar to that | |||
used by RFC 822 [9]. Implementors will need to be familiar with the | used by [RFC822]. Implementors will need to be familiar with the | |||
notation in order to understand this specification. The augmented | notation in order to understand this specification. The augmented | |||
BNF includes the following constructs: | BNF includes the following constructs: | |||
name = definition | name = definition | |||
The name of a rule is simply the name itself (without any | The name of a rule is simply the name itself (without any | |||
enclosing "<" and ">") and is separated from its definition by the | enclosing "<" and ">") and is separated from its definition by the | |||
equal "=" character. White space is only significant in that | equal "=" character. White space is only significant in that | |||
indentation of continuation lines is used to indicate a rule | indentation of continuation lines is used to indicate a rule | |||
definition that spans more than one line. Certain basic rules are | definition that spans more than one line. Certain basic rules are | |||
skipping to change at page 18, line 11 | skipping to change at page 22, line 11 | |||
between adjacent words and separators, without changing the | between adjacent words and separators, without changing the | |||
interpretation of a field. At least one delimiter (LWS and/or | interpretation of a field. At least one delimiter (LWS and/or | |||
separators) MUST exist between any two tokens (for the definition | separators) MUST exist between any two tokens (for the definition | |||
of "token" below), since they would otherwise be interpreted as a | of "token" below), since they would otherwise be interpreted as a | |||
single token. | single token. | |||
2.2. Basic Rules | 2.2. Basic Rules | |||
The following rules are used throughout this specification to | The following rules are used throughout this specification to | |||
describe basic parsing constructs. The US-ASCII coded character set | describe basic parsing constructs. The US-ASCII coded character set | |||
is defined by ANSI X3.4-1986 [21]. | is defined by ANSI X3.4-1986 [USASCII]. | |||
OCTET = <any 8-bit sequence of data> | OCTET = <any 8-bit sequence of data> | |||
CHAR = <any US-ASCII character (octets 0 - 127)> | CHAR = <any US-ASCII character (octets 0 - 127)> | |||
UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> | |||
LOALPHA = <any US-ASCII lowercase letter "a".."z"> | LOALPHA = <any US-ASCII lowercase letter "a".."z"> | |||
ALPHA = UPALPHA | LOALPHA | ALPHA = UPALPHA | LOALPHA | |||
DIGIT = <any US-ASCII digit "0".."9"> | DIGIT = <any US-ASCII digit "0".."9"> | |||
CTL = <any US-ASCII control character | CTL = <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 ) | |||
The TEXT rule is only used for descriptive field contents and values | The TEXT rule is only used for descriptive field contents and values | |||
that are not intended to be interpreted by the message parser. Words | that are not intended to be interpreted by the message parser. Words | |||
of *TEXT MAY contain characters from character sets other than ISO- | of *TEXT MAY contain characters from character sets other than ISO- | |||
8859-1 [22] only when encoded according to the rules of RFC 2047 | 8859-1 [ISO-8859-1] only when encoded according to the rules of | |||
[14]. | [RFC2047]. | |||
TEXT = <any OCTET except CTLs, | TEXT = <any OCTET except CTLs, | |||
but including LWS> | but including LWS> | |||
A CRLF is allowed in the definition of TEXT only as part of a header | A CRLF is allowed in the definition of TEXT only as part of a header | |||
field continuation. It is expected that the folding LWS will be | field continuation. It is expected that the folding LWS will be | |||
replaced with a single SP before interpretation of the TEXT value. | replaced with a single SP before interpretation of the TEXT value. | |||
Hexadecimal numeric characters are used in several protocol elements. | Hexadecimal numeric characters are used in several protocol elements. | |||
skipping to change at page 20, line 21 | skipping to change at page 24, line 21 | |||
the sender to indicate the format of a message and its capacity for | the sender to indicate the format of a message and its capacity for | |||
understanding further HTTP communication, rather than the features | understanding further HTTP communication, rather than the features | |||
obtained via that communication. No change is made to the version | obtained via that communication. No change is made to the version | |||
number for the addition of message components which do not affect | number for the addition of message components which do not affect | |||
communication behavior or which only add to extensible field values. | communication behavior or which only add to extensible field values. | |||
The <minor> number is incremented when the changes made to the | The <minor> number is incremented when the changes made to the | |||
protocol add features which do not change the general message parsing | protocol add features which do not change the general message parsing | |||
algorithm, but which may add to the message semantics and imply | algorithm, but which may add to the message semantics and imply | |||
additional capabilities of the sender. The <major> number is | additional capabilities of the sender. The <major> number is | |||
incremented when the format of a message within the protocol is | incremented when the format of a message within the protocol is | |||
changed. See RFC 2145 [36] for a fuller explanation. | changed. See [RFC2145] for a fuller explanation. | |||
The version of an HTTP message is indicated by an HTTP-Version field | The version of an HTTP message is indicated by an HTTP-Version field | |||
in the first line of the message. | in the first line of the message. | |||
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |||
Note that the major and minor numbers MUST be treated as separate | Note that the major and minor numbers MUST be treated as separate | |||
integers and that each MAY be incremented higher than a single digit. | integers and that each MAY be incremented higher than a single digit. | |||
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |||
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | |||
and MUST NOT be sent. | and MUST NOT be sent. | |||
An application that sends a request or response message that includes | An application that sends a request or response message that includes | |||
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | |||
with this specification. Applications that are at least | with this specification. Applications that are at least | |||
conditionally compliant with this specification SHOULD use an HTTP- | conditionally compliant with this specification SHOULD use an HTTP- | |||
Version of "HTTP/1.1" in their messages, and MUST do so for any | Version of "HTTP/1.1" in their messages, and MUST do so for any | |||
message that is not compatible with HTTP/1.0. For more details on | message that is not compatible with HTTP/1.0. For more details on | |||
when to send specific HTTP-Version values, see RFC 2145 [36]. | when to send specific HTTP-Version values, see [RFC2145]. | |||
The HTTP version of an application is the highest HTTP version for | The HTTP version of an application is the highest HTTP version for | |||
which the application is at least conditionally compliant. | which the application is at least conditionally compliant. HTTP- | |||
Version is case-sensitive. | ||||
Proxy and gateway applications need to be careful when forwarding | Proxy and gateway applications need to be careful when forwarding | |||
messages in protocol versions different from that of the application. | messages in protocol versions different from that of the application. | |||
Since the protocol version indicates the protocol capability of the | Since the protocol version indicates the protocol capability of the | |||
sender, a proxy/gateway MUST NOT send a message with a version | sender, a proxy/gateway MUST NOT send a message with a version | |||
indicator which is greater than its actual version. If a higher | indicator which is greater than its actual version. If a higher | |||
version request is received, the proxy/gateway MUST either downgrade | version request is received, the proxy/gateway MUST either downgrade | |||
the request version, or respond with an error, or switch to tunnel | the request version, or respond with an error, or switch to tunnel | |||
behavior. | behavior. | |||
Due to interoperability problems with HTTP/1.0 proxies discovered | Due to interoperability problems with HTTP/1.0 proxies discovered | |||
since the publication of RFC 2068 [33], caching proxies MUST, | since the publication of [RFC2068], caching proxies MUST, gateways | |||
gateways MAY, and tunnels MUST NOT upgrade the request to the highest | MAY, and tunnels MUST NOT upgrade the request to the highest version | |||
version they support. The proxy/gateway's response to that request | they support. The proxy/gateway's response to that request MUST be | |||
MUST be in the same major version as the request. | in the same major version as the request. | |||
Note: Converting between versions of HTTP may involve modification | Note: Converting between versions of HTTP may involve modification | |||
of header fields required or forbidden by the versions involved. | of header fields required or forbidden by the versions involved. | |||
3.2. Uniform Resource Identifiers | 3.2. Uniform Resource Identifiers | |||
URIs have been known by many names: WWW addresses, Universal Document | URIs have been known by many names: WWW addresses, Universal Document | |||
Identifiers, Universal Resource Identifiers [3], and finally the | Identifiers, Universal Resource Identifiers [RFC1630], and finally | |||
combination of Uniform Resource Locators (URL) [4] and Names (URN) | the combination of Uniform Resource Locators (URL) [RFC1738] and | |||
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are | Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource | |||
simply formatted strings which identify--via name, location, or any | Identifiers are simply formatted strings which identify--via name, | |||
other characteristic--a resource. | location, or any other characteristic--a resource. | |||
3.2.1. General Syntax | 3.2.1. General Syntax | |||
URIs in HTTP can be represented in absolute form or relative to some | URIs in HTTP can be represented in absolute form or relative to some | |||
known base URI [11], depending upon the context of their use. The | known base URI [RFC1808], depending upon the context of their use. | |||
two forms are differentiated by the fact that absolute URIs always | The two forms are differentiated by the fact that absolute URIs | |||
begin with a scheme name followed by a colon. For definitive | always begin with a scheme name followed by a colon. For definitive | |||
information on URL syntax and semantics, see "Uniform Resource | information on URL syntax and semantics, see "Uniform Resource | |||
Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] | Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which | |||
(which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification | replaces [RFC1738] and [RFC1808]). This specification adopts the | |||
adopts the definitions of "URI-reference", "absoluteURI", | definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | |||
"relativeURI", "port", "host","abs_path", "rel_path", and "authority" | "host", "abs_path", "rel_path", and "authority" from that | |||
from that specification. | specification. | |||
The HTTP protocol does not place any a priori limit on the length of | The HTTP protocol does not place any a priori limit on the length of | |||
a URI. Servers MUST be able to handle the URI of any resource they | a URI. Servers MUST be able to handle the URI of any resource they | |||
serve, and SHOULD be able to handle URIs of unbounded length if they | serve, and SHOULD be able to handle URIs of unbounded length if they | |||
provide GET-based forms that could generate such URIs. A server | provide GET-based forms that could generate such URIs. A server | |||
SHOULD return 414 (Request-URI Too Long) status if a URI is longer | SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |||
than the server can handle (see Section 10.4.15). | than the server can handle (see Section 10.4.15). | |||
Note: Servers ought to be cautious about depending on URI lengths | Note: Servers ought to be cautious about depending on URI lengths | |||
above 255 bytes, because some older client or proxy | above 255 bytes, because some older client or proxy | |||
skipping to change at page 22, line 11 | skipping to change at page 26, line 17 | |||
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 | |||
[24]). If the abs_path is not present in the URL, it MUST be given | [RFC1900]). If the abs_path is not present in the URL, it MUST be | |||
as "/" when used as a Request-URI for a resource (Section 5.1.2). If | given as "/" when used as a Request-URI for a resource | |||
a proxy receives a host name which is not a fully qualified domain | (Section 5.1.2). If a proxy receives a host name which is not a | |||
name, it MAY add its domain to the host name it received. If a proxy | fully qualified domain name, it MAY add its domain to the host name | |||
receives a fully qualified domain name, the proxy MUST NOT change the | it received. If a proxy receives a fully qualified domain name, the | |||
host name. | proxy MUST NOT change the host name. | |||
3.2.3. URI Comparison | 3.2.3. URI Comparison | |||
When comparing two URIs to decide if they match or not, a client | When comparing two URIs to decide if they match or not, a client | |||
SHOULD use a case-sensitive octet-by-octet comparison of the entire | SHOULD use a case-sensitive octet-by-octet comparison of the entire | |||
URIs, with these exceptions: | URIs, with these exceptions: | |||
o A port that is empty or not given is equivalent to the default | o A port that is empty or not given is equivalent to the default | |||
port for that URI-reference; | port for that URI-reference; | |||
o Comparisons of host names MUST be case-insensitive; | o Comparisons of host names MUST be case-insensitive; | |||
o Comparisons of scheme names MUST be case-insensitive; | o Comparisons of scheme names MUST be case-insensitive; | |||
o An empty abs_path is equivalent to an abs_path of "/". | o An empty abs_path is equivalent to an abs_path of "/". | |||
Characters other than those in the "reserved" and "unsafe" sets (see | Characters other than those in the "reserved" set (see [RFC2396]) are | |||
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. | equivalent to their ""%" HEX HEX" encoding. | |||
For example, the following three URIs are equivalent: | For example, the following three URIs are equivalent: | |||
http://abc.com:80/~smith/home.html | http://example.com:80/~smith/home.html | |||
http://ABC.com/%7Esmith/home.html | http://EXAMPLE.com/%7Esmith/home.html | |||
http://ABC.com:/%7esmith/home.html | http://EXAMPLE.com:/%7esmith/home.html | |||
3.3. Date/Time Formats | 3.3. Date/Time Formats | |||
3.3.1. Full Date | 3.3.1. Full Date | |||
HTTP applications have historically allowed three different formats | HTTP applications have historically allowed three different formats | |||
for the representation of date/time stamps: | for the representation of date/time stamps: | |||
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 | Sun, 06 Nov 1994 08:49:37 GMT ; [RFC822], updated by [RFC1123] | |||
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 [RFC1036] | |||
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 [RFC1123] (an update to | |||
RFC 822 [9]). The second format is in common use, but is based on | [RFC822]). The second format is in common use, but is based on the | |||
the obsolete RFC 850 [12] date format and lacks a four-digit year. | obsolete RFC 1036 date format [RFC1036] 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 24, line 39 | skipping to change at page 29, line 15 | |||
to characters. In particular, use of external profiling information | to characters. In particular, use of external profiling information | |||
to determine the exact mapping is not permitted. | to determine the exact mapping is not permitted. | |||
Note: This use of the term "character set" is more commonly | Note: This use of the term "character set" is more commonly | |||
referred to as a "character encoding." However, since HTTP and | referred to as a "character encoding." However, since HTTP and | |||
MIME share the same registry, it is important that the terminology | MIME share the same registry, it is important that the terminology | |||
also be shared. | also be shared. | |||
HTTP character sets are identified by case-insensitive tokens. The | HTTP character sets are identified by case-insensitive tokens. The | |||
complete set of tokens is defined by the IANA Character Set registry | complete set of tokens is defined by the IANA Character Set registry | |||
[19]. | (<http://www.iana.org/assignments/character-sets>). | |||
charset = token | charset = token | |||
Although HTTP allows an arbitrary token to be used as a charset | Although HTTP allows an arbitrary token to be used as a charset | |||
value, any token that has a predefined value within the IANA | value, any token that has a predefined value within the IANA | |||
Character Set registry [19] MUST represent the character set defined | Character Set registry MUST represent the character set defined by | |||
by that registry. Applications SHOULD limit their use of character | that registry. Applications SHOULD limit their use of character sets | |||
sets to those defined by the IANA registry. | to those defined by the IANA registry. | |||
Implementors should be aware of IETF character set requirements [38] | HTTP uses charset in two contexts: within an Accept-Charset request | |||
[41]. | header (in which the charset value is an unquoted token) and as the | |||
value of a parameter in a Content-Type header (within a request or | ||||
response), in which case the parameter value of the charset parameter | ||||
may be quoted. | ||||
Implementors should be aware of IETF character set requirements | ||||
[RFC2279] [RFC2277]. | ||||
3.4.1. Missing Charset | 3.4.1. Missing Charset | |||
Some HTTP/1.0 software has interpreted a Content-Type header without | Some HTTP/1.0 software has interpreted a Content-Type header without | |||
charset parameter incorrectly to mean "recipient should guess." | charset parameter incorrectly to mean "recipient should guess." | |||
Senders wishing to defeat this behavior MAY include a charset | Senders wishing to defeat this behavior MAY include a charset | |||
parameter even when the charset is ISO-8859-1 and SHOULD do so when | parameter even when the charset is ISO-8859-1 and SHOULD do so when | |||
it is known that it will not confuse the recipient. | it is known that it will not confuse the recipient. | |||
Unfortunately, some older HTTP/1.0 clients did not deal properly with | Unfortunately, some older HTTP/1.0 clients did not deal properly with | |||
skipping to change at page 25, line 46 | skipping to change at page 30, line 30 | |||
indicates what decoding mechanism will be required to remove the | indicates what decoding mechanism will be required to remove the | |||
encoding. | encoding. | |||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
content-coding value tokens. Initially, the registry contains the | content-coding value tokens. Initially, the registry contains the | |||
following tokens: | following tokens: | |||
gzip | gzip | |||
An encoding format produced by the file compression program "gzip" | An encoding format produced by the file compression program "gzip" | |||
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel- | (GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv | |||
Ziv coding (LZ77) with a 32 bit CRC. | coding (LZ77) with a 32 bit CRC. | |||
compress | compress | |||
The encoding format produced by the common UNIX file compression | The encoding format produced by the common UNIX file compression | |||
program "compress". This format is an adaptive Lempel-Ziv-Welch | program "compress". This format is an adaptive Lempel-Ziv-Welch | |||
coding (LZW). | coding (LZW). | |||
Use of program names for the identification of encoding formats is | Use of program names for the identification of encoding formats is | |||
not desirable and is discouraged for future encodings. Their use | not desirable and is discouraged for future encodings. Their use | |||
here is representative of historical practice, not good design. | here is representative of historical practice, not good design. | |||
For compatibility with previous implementations of HTTP, | For compatibility with previous implementations of HTTP, | |||
applications SHOULD consider "x-gzip" and "x-compress" to be | applications SHOULD consider "x-gzip" and "x-compress" to be | |||
equivalent to "gzip" and "compress" respectively. | equivalent to "gzip" and "compress" respectively. | |||
deflate | deflate | |||
The "zlib" format defined in RFC 1950 [31] in combination with the | The "zlib" format defined in [RFC1950] in combination with the | |||
"deflate" compression mechanism described in RFC 1951 [29]. | "deflate" compression mechanism described in [RFC1951]. | |||
identity | identity | |||
The default (identity) encoding; the use of no transformation | The default (identity) encoding; the use of no transformation | |||
whatsoever. This content-coding is used only in the Accept- | whatsoever. This content-coding is used only in the Accept- | |||
Encoding header, and SHOULD NOT be used in the Content-Encoding | Encoding header, and SHOULD NOT be used in the Content-Encoding | |||
header. | header. | |||
New content-coding value tokens SHOULD be registered; to allow | New content-coding value tokens SHOULD be registered; to allow | |||
interoperability between clients and servers, specifications of the | interoperability between clients and servers, specifications of the | |||
content coding algorithms needed to implement a new value SHOULD be | content coding algorithms needed to implement a new value SHOULD be | |||
publicly available and adequate for independent implementation, and | publicly available and adequate for independent implementation, and | |||
conform to the purpose of content coding defined in this section. | conform to the purpose of content coding defined in this section. | |||
skipping to change at page 27, line 14 | skipping to change at page 31, line 45 | |||
Whenever a transfer-coding is applied to a message-body, the set of | Whenever a transfer-coding is applied to a message-body, the set of | |||
transfer-codings MUST include "chunked", unless the message is | transfer-codings MUST include "chunked", unless the message is | |||
terminated by closing the connection. When the "chunked" transfer- | terminated by closing the connection. When the "chunked" transfer- | |||
coding is used, it MUST be the last transfer-coding applied to the | coding is used, it MUST be the last transfer-coding applied to the | |||
message-body. The "chunked" transfer-coding MUST NOT be applied more | message-body. The "chunked" transfer-coding MUST NOT be applied more | |||
than once to a message-body. These rules allow the recipient to | than once to a message-body. These rules allow the recipient to | |||
determine the transfer-length of the message (Section 4.4). | determine the transfer-length of the message (Section 4.4). | |||
Transfer-codings are analogous to the Content-Transfer-Encoding | Transfer-codings are analogous to the Content-Transfer-Encoding | |||
values of MIME [7], which were designed to enable safe transport of | values of MIME [RFC2045], which were designed to enable safe | |||
binary data over a 7-bit transport service. However, safe transport | transport of binary data over a 7-bit transport service. However, | |||
has a different focus for an 8bit-clean transfer protocol. In HTTP, | safe transport has a different focus for an 8bit-clean transfer | |||
the only unsafe characteristic of message-bodies is the difficulty in | protocol. In HTTP, the only unsafe characteristic of message-bodies | |||
determining the exact body length (Section 7.2.2), or the desire to | is the difficulty in determining the exact body length | |||
encrypt data over a shared transport. | (Section 7.2.2), or the desire to encrypt data over a shared | |||
transport. | ||||
The Internet Assigned Numbers Authority (IANA) acts as a registry for | The Internet Assigned Numbers Authority (IANA) acts as a registry for | |||
transfer-coding value tokens. Initially, the registry contains the | transfer-coding value tokens. Initially, the registry contains the | |||
following tokens: "chunked" (Section 3.6.1), "identity" (section | following tokens: "chunked" (Section 3.6.1), "gzip" (Section 3.5), | |||
3.6.2), "gzip" (Section 3.5), "compress" (Section 3.5), and "deflate" | "compress" (Section 3.5), and "deflate" (Section 3.5). | |||
(Section 3.5). | ||||
New transfer-coding value tokens SHOULD be registered in the same way | New transfer-coding value tokens SHOULD be registered in the same way | |||
as new content-coding value tokens (Section 3.5). | as new content-coding value tokens (Section 3.5). | |||
A server which receives an entity-body with a transfer-coding it does | A server which receives an entity-body with a transfer-coding it does | |||
not understand SHOULD return 501 (Unimplemented), and close the | not understand SHOULD return 501 (Unimplemented), and close the | |||
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | |||
client. | client. | |||
3.6.1. Chunked Transfer Coding | 3.6.1. Chunked Transfer Coding | |||
skipping to change at page 28, line 22 | skipping to change at page 32, line 44 | |||
chunk-size = 1*HEX | chunk-size = 1*HEX | |||
last-chunk = 1*("0") [ chunk-extension ] CRLF | last-chunk = 1*("0") [ chunk-extension ] CRLF | |||
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token | quoted-string | chunk-ext-val = token | quoted-string | |||
chunk-data = chunk-size(OCTET) | chunk-data = chunk-size(OCTET) | |||
trailer = *(entity-header CRLF) | trailer = *(entity-header CRLF) | |||
The chunk-size field is a string of hex digits indicating the size of | The chunk-size field is a string of hex digits indicating the size of | |||
the chunk. The chunked encoding is ended by any chunk whose size is | the chunk-data in octets. The chunked encoding is ended by any chunk | |||
zero, followed by the trailer, which is terminated by an empty line. | whose size is zero, followed by the trailer, which is terminated by | |||
an empty line. | ||||
The trailer allows the sender to include additional HTTP header | The trailer allows the sender to include additional HTTP header | |||
fields at the end of the message. The Trailer header field can be | fields at the end of the message. The Trailer header field can be | |||
used to indicate which header fields are included in a trailer (see | used to indicate which header fields are included in a trailer (see | |||
Section 14.40). | Section 14.40). | |||
A server using chunked transfer-coding in a response MUST NOT use the | A server using chunked transfer-coding in a response MUST NOT use the | |||
trailer for any header fields unless at least one of the following is | trailer for any header fields unless at least one of the following is | |||
true: | true: | |||
skipping to change at page 29, line 4 | skipping to change at page 33, line 28 | |||
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 [RFC1590] in the Content-Type | |||
(Section 14.17) and Accept (Section 14.1) header fields in order to | (Section 14.17) and Accept (Section 14.1) header fields in order to | |||
provide open and extensible data typing and type negotiation. | provide open and extensible data typing and type negotiation. | |||
media-type = type "/" subtype *( ";" parameter ) | media-type = type "/" subtype *( ";" parameter ) | |||
type = token | type = token | |||
subtype = token | subtype = token | |||
Parameters MAY follow the type/subtype in the form of attribute/value | Parameters MAY follow the type/subtype in the form of attribute/value | |||
pairs (as defined in Section 3.6). | pairs (as defined in Section 3.6). | |||
skipping to change at page 29, line 37 | skipping to change at page 34, line 12 | |||
attribute and its value. The presence or absence of a parameter | attribute and its value. The presence or absence of a parameter | |||
might be significant to the processing of a media-type, depending on | might be significant to the processing of a media-type, depending on | |||
its definition within the media type registry. | its definition within the media type registry. | |||
Note that some older HTTP applications do not recognize media type | Note that some older HTTP applications do not recognize media type | |||
parameters. When sending data to older HTTP applications, | parameters. When sending data to older HTTP applications, | |||
implementations SHOULD only use media type parameters when they are | implementations SHOULD only use media type parameters when they are | |||
required by that type/subtype definition. | required by that type/subtype definition. | |||
Media-type values are registered with the Internet Assigned Number | Media-type values are registered with the Internet Assigned Number | |||
Authority (IANA [19]). The media type registration process is | Authority (IANA). The media type registration process is outlined in | |||
outlined in RFC 1590 [17]. Use of non-registered media types is | [RFC1590]. Use of non-registered media types is discouraged. | |||
discouraged. | ||||
3.7.1. Canonicalization and Text Defaults | 3.7.1. Canonicalization and Text Defaults | |||
Internet media types are registered with a canonical form. An | Internet media types are registered with a canonical form. An | |||
entity-body transferred via HTTP messages MUST be represented in the | entity-body transferred via HTTP messages MUST be represented in the | |||
appropriate canonical form prior to its transmission except for | appropriate canonical form prior to its transmission except for | |||
"text" types, as defined in the next paragraph. | "text" types, as defined in the next paragraph. | |||
When in canonical form, media subtypes of the "text" type use CRLF as | When in canonical form, media subtypes of the "text" type use CRLF as | |||
the text line break. HTTP relaxes this requirement and allows the | the text line break. HTTP relaxes this requirement and allows the | |||
skipping to change at page 30, line 30 | skipping to change at page 35, line 4 | |||
parameter is provided by the sender, media subtypes of the "text" | parameter is provided by the sender, media subtypes of the "text" | |||
type are defined to have a default charset value of "ISO-8859-1" when | type are defined to have a default charset value of "ISO-8859-1" when | |||
received via HTTP. Data in character sets other than "ISO-8859-1" or | received via HTTP. Data in character sets other than "ISO-8859-1" or | |||
its subsets MUST be labeled with an appropriate charset value. See | its subsets MUST be labeled with an appropriate charset value. See | |||
Section 3.4.1 for compatibility problems. | Section 3.4.1 for compatibility problems. | |||
3.7.2. Multipart Types | 3.7.2. Multipart Types | |||
MIME provides for a number of "multipart" types -- encapsulations of | MIME provides for a number of "multipart" types -- encapsulations of | |||
one or more entities within a single message-body. All multipart | one or more entities within a single message-body. All multipart | |||
types share a common syntax, as defined in section 5.1.1 of RFC 2046 | types share a common syntax, as defined in Section 5.1.1 of | |||
[40], and MUST include a boundary parameter as part of the media type | [RFC2046], and MUST include a boundary parameter as part of the media | |||
value. The message body is itself a protocol element and MUST | type value. The message body is itself a protocol element and MUST | |||
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. | |||
If an application receives an unrecognized multipart subtype, the | If an application receives an unrecognized multipart subtype, the | |||
application MUST treat it as being equivalent to "multipart/mixed". | application MUST treat it as being equivalent to "multipart/mixed". | |||
Note: The "multipart/form-data" type has been specifically defined | Note: The "multipart/form-data" type has been specifically defined | |||
for carrying form data suitable for processing via the POST | for carrying form data suitable for processing via the POST | |||
request method, as described in RFC 1867 [15]. | request method, as described in RFC 1867 [RFC1867]. | |||
3.8. Product Tokens | 3.8. Product Tokens | |||
Product tokens are used to allow communicating applications to | Product tokens are used to allow communicating applications to | |||
identify themselves by software name and version. Most fields using | identify themselves by software name and version. Most fields using | |||
product tokens also allow sub-products which form a significant part | product tokens also allow sub-products which form a significant part | |||
of the application to be listed, separated by white space. By | of the application to be listed, separated by white space. By | |||
convention, the products are listed in order of their significance | convention, the products are listed in order of their significance | |||
for identifying the application. | for identifying the application. | |||
skipping to change at page 32, line 16 | skipping to change at page 36, line 38 | |||
3.10. Language Tags | 3.10. Language Tags | |||
A language tag identifies a natural language spoken, written, or | A language tag identifies a natural language spoken, written, or | |||
otherwise conveyed by human beings for communication of information | otherwise conveyed by human beings for communication of information | |||
to other human beings. Computer languages are explicitly excluded. | to other human beings. Computer languages are explicitly excluded. | |||
HTTP uses language tags within the Accept-Language and Content- | HTTP uses language tags within the Accept-Language and Content- | |||
Language fields. | Language fields. | |||
The syntax and registry of HTTP language tags is the same as that | The syntax and registry of HTTP language tags is the same as that | |||
defined by RFC 1766 [1]. In summary, a language tag is composed of 1 | defined by [RFC1766]. In summary, a language tag is composed of 1 or | |||
or more parts: A primary language tag and a possibly empty series of | more parts: A primary language tag and a possibly empty series of | |||
subtags: | subtags: | |||
language-tag = primary-tag *( "-" subtag ) | language-tag = primary-tag *( "-" subtag ) | |||
primary-tag = 1*8ALPHA | primary-tag = 1*8ALPHA | |||
subtag = 1*8ALPHA | subtag = 1*8ALPHA | |||
White space is not allowed within the tag and all tags are case- | White space is not allowed within the tag and all tags are case- | |||
insensitive. The name space of language tags is administered by the | insensitive. The name space of language tags is administered by the | |||
IANA. Example tags include: | IANA. Example tags include: | |||
skipping to change at page 34, line 15 | skipping to change at page 39, line 15 | |||
4. HTTP Message | 4. HTTP Message | |||
4.1. Message Types | 4.1. Message Types | |||
HTTP messages consist of requests from client to server and responses | HTTP messages consist of requests from client to server and responses | |||
from server to client. | from server to client. | |||
HTTP-message = Request | Response ; HTTP/1.1 messages | HTTP-message = Request | Response ; HTTP/1.1 messages | |||
Request (Section 5) and Response (Section 6) messages use the generic | Request (Section 5) and Response (Section 6) messages use the generic | |||
message format of RFC 822 [9] for transferring entities (the payload | message format of [RFC822] for transferring entities (the payload of | |||
of the message). Both types of message consist of a start-line, zero | the message). Both types of message consist of a start-line, zero or | |||
or more header fields (also known as "headers"), an empty line (i.e., | more header fields (also known as "headers"), an empty line (i.e., a | |||
a line with nothing preceding the CRLF) indicating the end of the | line with nothing preceding the CRLF) indicating the end of the | |||
header fields, and possibly a message-body. | header fields, and possibly a message-body. | |||
generic-message = start-line | generic-message = start-line | |||
*(message-header CRLF) | *(message-header CRLF) | |||
CRLF | CRLF | |||
[ message-body ] | [ message-body ] | |||
start-line = Request-Line | Status-Line | start-line = Request-Line | Status-Line | |||
In the interest of robustness, servers SHOULD ignore any empty | In the interest of robustness, servers SHOULD ignore any empty | |||
line(s) received where a Request-Line is expected. In other words, | line(s) received where a Request-Line is expected. In other words, | |||
skipping to change at page 34, line 42 | skipping to change at page 39, line 42 | |||
Certain buggy HTTP/1.0 client implementations generate extra CRLF's | Certain buggy HTTP/1.0 client implementations generate extra CRLF's | |||
after a POST request. To restate what is explicitly forbidden by the | after a POST request. To restate what is explicitly forbidden by the | |||
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an | |||
extra CRLF. | extra CRLF. | |||
4.2. Message Headers | 4.2. Message Headers | |||
HTTP header fields, which include general-header (Section 4.5), | HTTP header fields, which include general-header (Section 4.5), | |||
request-header (Section 5.3), response-header (Section 6.2), and | request-header (Section 5.3), response-header (Section 6.2), and | |||
entity-header (Section 7.1) fields, follow the same generic format as | entity-header (Section 7.1) fields, follow the same generic format as | |||
that given in Section 3.1 of RFC 822 [9]. Each header field consists | that given in Section 3.1 of [RFC822]. Each header field consists of | |||
of a name followed by a colon (":") and the field value. Field names | a name followed by a colon (":") and the field value. Field names | |||
are case-insensitive. The field value MAY be preceded by any amount | are case-insensitive. The field value MAY be preceded by any amount | |||
of LWS, though a single SP is preferred. Header fields can be | of LWS, though a single SP is preferred. Header fields can be | |||
extended over multiple lines by preceding each extra line with at | extended over multiple lines by preceding each extra line with at | |||
least one SP or HT. Applications ought to follow "common form", | least one SP or HT. Applications ought to follow "common form", | |||
where one is known or indicated, when generating HTTP constructs, | where one is known or indicated, when generating HTTP constructs, | |||
since there might exist some implementations that fail to accept | since there might exist some implementations that fail to accept | |||
anything beyond the common forms. | anything beyond the common forms. | |||
message-header = field-name ":" [ field-value ] | message-header = field-name ":" [ field-value ] | |||
field-name = token | field-name = token | |||
skipping to change at page 36, line 41 | skipping to change at page 41, line 41 | |||
been applied. When a message-body is included with a message, the | been applied. When a message-body is included with a message, the | |||
transfer-length of that body is determined by one of the following | transfer-length of that body is determined by one of the following | |||
(in order of precedence): | (in order of precedence): | |||
1. Any response message which "MUST NOT" include a message-body | 1. Any response message which "MUST NOT" include a message-body | |||
(such as the 1xx, 204, and 304 responses and any response to a | (such as the 1xx, 204, and 304 responses and any response to a | |||
HEAD request) is always terminated by the first empty line after | HEAD request) is always terminated by the first empty line after | |||
the header fields, regardless of the entity-header fields present | the header fields, regardless of the entity-header fields present | |||
in the message. | in the message. | |||
2. If a Transfer-Encoding header field (Section 14.41) is present | 2. If a Transfer-Encoding header field (Section 14.41) is present, | |||
and has any value other than "identity", then the transfer-length | then the transfer-length is defined by use of the "chunked" | |||
is defined by use of the "chunked" transfer-coding (Section 3.6), | transfer-coding (Section 3.6), unless the message is terminated | |||
unless the message is terminated by closing the connection. | by closing the connection. | |||
3. If a Content-Length header field (Section 14.13) is present, its | 3. If a Content-Length header field (Section 14.13) is present, its | |||
decimal value in OCTETs represents both the entity-length and the | decimal value in OCTETs represents both the entity-length and the | |||
transfer-length. The Content-Length header field MUST NOT be | transfer-length. The Content-Length header field MUST NOT be | |||
sent if these two lengths are different (i.e., if a Transfer- | sent if these two lengths are different (i.e., if a Transfer- | |||
Encoding header field is present). If a message is received with | Encoding header field is present). If a message is received with | |||
both a Transfer-Encoding header field and a Content-Length header | both a Transfer-Encoding header field and a Content-Length header | |||
field, the latter MUST be ignored. | field, the latter MUST be ignored. | |||
4. If the message uses the media type "multipart/byteranges", and | 4. If the message uses the media type "multipart/byteranges", and | |||
the ransfer-length is not otherwise specified, then this self- | the transfer-length is not otherwise specified, then this self- | |||
elimiting media type defines the transfer-length. This media | delimiting media type defines the transfer-length. This media | |||
type UST NOT be used unless the sender knows that the recipient | type MUST NOT be used unless the sender knows that the recipient | |||
can arse it; the presence in a request of a Range header with | can parse it; the presence in a request of a Range header with | |||
ultiple byte-range specifiers from a 1.1 client implies that the | multiple byte-range specifiers from a 1.1 client implies that the | |||
lient can parse multipart/byteranges responses. | client can parse multipart/byteranges responses. | |||
A range header might be forwarded by a 1.0 proxy that does not | A range header might be forwarded by a 1.0 proxy that does not | |||
understand multipart/byteranges; in this case the server MUST | understand multipart/byteranges; in this case the server MUST | |||
delimit the message using methods defined in items 1, 3 or 5 | delimit the message using methods defined in items 1, 3 or 5 | |||
of this section. | of this section. | |||
5. By the server closing the connection. (Closing the connection | 5. By the server closing the connection. (Closing the connection | |||
cannot be used to indicate the end of a request body, since that | cannot be used to indicate the end of a request body, since that | |||
would leave no possibility for the server to send back a | would leave no possibility for the server to send back a | |||
response.) | response.) | |||
skipping to change at page 37, line 38 | skipping to change at page 42, line 38 | |||
the server SHOULD respond with 400 (bad request) if it cannot | the server SHOULD respond with 400 (bad request) if it cannot | |||
determine the length of the message, or with 411 (length required) if | determine the length of the message, or with 411 (length required) if | |||
it wishes to insist on receiving a valid Content-Length. | it wishes to insist on receiving a valid Content-Length. | |||
All HTTP/1.1 applications that receive entities MUST accept the | All HTTP/1.1 applications that receive entities MUST accept the | |||
"chunked" transfer-coding (Section 3.6), thus allowing this mechanism | "chunked" transfer-coding (Section 3.6), thus allowing this mechanism | |||
to be used for messages when the message length cannot be determined | to be used for messages when the message length cannot be determined | |||
in advance. | in advance. | |||
Messages MUST NOT include both a Content-Length header field and a | Messages MUST NOT include both a Content-Length header field and a | |||
non-identity transfer-coding. If the message does include a non- | transfer-coding. If the message does include a transfer-coding, the | |||
identity transfer-coding, the Content-Length MUST be ignored. | Content-Length MUST be ignored. | |||
When a Content-Length is given in a message where a message-body is | When a Content-Length is given in a message where a message-body is | |||
allowed, its field value MUST exactly match the number of OCTETs in | allowed, its field value MUST exactly match the number of OCTETs in | |||
the message-body. HTTP/1.1 user agents MUST notify the user when an | the message-body. HTTP/1.1 user agents MUST notify the user when an | |||
invalid length is received and detected. | invalid length is received and detected. | |||
4.5. General Header Fields | 4.5. General Header Fields | |||
There are a few header fields which have general applicability for | There are a few header fields which have general applicability for | |||
both request and response messages, but which do not apply to the | both request and response messages, but which do not apply to the | |||
skipping to change at page 40, line 12 | skipping to change at page 45, line 12 | |||
GET and HEAD MUST be supported by all general-purpose servers. All | GET and HEAD MUST be supported by all general-purpose servers. All | |||
other methods are OPTIONAL; however, if the above methods are | other methods are OPTIONAL; however, if the above methods are | |||
implemented, they MUST be implemented with the same semantics as | implemented, they MUST be implemented with the same semantics as | |||
those specified in Section 9. | those specified in Section 9. | |||
5.1.2. Request-URI | 5.1.2. Request-URI | |||
The Request-URI is a Uniform Resource Identifier (Section 3.2) and | The Request-URI is a Uniform Resource Identifier (Section 3.2) and | |||
identifies the resource upon which to apply the request. | identifies the resource upon which to apply the request. | |||
Request-URI = "*" | absoluteURI | abs_path | authority | Request-URI = "*" | |||
| absoluteURI | ||||
| abs_path [ "?" query ] | ||||
| authority | ||||
The four options for Request-URI are dependent on the nature of the | The four options for Request-URI are dependent on the nature of the | |||
request. The asterisk "*" means that the request does not apply to a | request. The asterisk "*" means that the request does not apply to a | |||
particular resource, but to the server itself, and is only allowed | particular resource, but to the server itself, and is only allowed | |||
when the method used does not necessarily apply to a resource. One | when the method used does not necessarily apply to a resource. One | |||
example would be | example would be | |||
OPTIONS * HTTP/1.1 | OPTIONS * HTTP/1.1 | |||
The absoluteURI form is REQUIRED when the request is being made to a | The absoluteURI form is REQUIRED when the request is being made to a | |||
proxy. The proxy is requested to forward the request or service it | proxy. The proxy is requested to forward the request or service it | |||
from a valid cache, and return the response. Note that the proxy MAY | from a valid cache, and return the response. Note that the proxy MAY | |||
forward the request on to another proxy or directly to the server | forward the request on to another proxy or directly to the server | |||
specified by the absoluteURI. In order to avoid request loops, a | specified by the absoluteURI. In order to avoid request loops, a | |||
proxy MUST be able to recognize all of its server names, including | proxy MUST be able to recognize all of its server names, including | |||
any aliases, local variations, and the numeric IP address. An | any aliases, local variations, and the numeric IP address. An | |||
example Request-Line would be: | example Request-Line would be: | |||
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 | |||
To allow for transition to absoluteURIs in all requests in future | To allow for transition to absoluteURIs in all requests in future | |||
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI | versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI | |||
form in requests, even though HTTP/1.1 clients will only generate | form in requests, even though HTTP/1.1 clients will only generate | |||
them in requests to proxies. | them in requests to proxies. | |||
The authority form is only used by the CONNECT method (Section 9.9). | The authority form is only used by the CONNECT method (Section 9.9). | |||
The most common form of Request-URI is that used to identify a | The most common form of Request-URI is that used to identify a | |||
resource on an origin server or gateway. In this case the absolute | resource on an origin server or gateway. In this case the absolute | |||
path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as | path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as | |||
the Request-URI, and the network location of the URI (authority) MUST | the Request-URI, and the network location of the URI (authority) MUST | |||
be transmitted in a Host header field. For example, a client wishing | be transmitted in a Host header field. For example, a client wishing | |||
to retrieve the resource above directly from the origin server would | to retrieve the resource above directly from the origin server would | |||
create a TCP connection to port 80 of the host "www.w3.org" and send | create a TCP connection to port 80 of the host "www.example.org" and | |||
the lines: | send the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.w3.org | Host: www.example.org | |||
followed by the remainder of the Request. Note that the absolute | followed by the remainder of the Request. Note that the absolute | |||
path cannot be empty; if none is present in the original URI, it MUST | path cannot be empty; if none is present in the original URI, it MUST | |||
be given as "/" (the server root). | be given as "/" (the server root). | |||
The Request-URI is transmitted in the format specified in | The Request-URI is transmitted in the format specified in | |||
Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" | Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" | |||
encoding [42], the origin server MUST decode the Request-URI in order | encoding [RFC2396], the origin server MUST decode the Request-URI in | |||
to properly interpret the request. Servers SHOULD respond to invalid | order to properly interpret the request. Servers SHOULD respond to | |||
Request-URIs with an appropriate status code. | invalid Request-URIs with an appropriate status code. | |||
A transparent proxy MUST NOT rewrite the "abs_path" part of the | A transparent proxy MUST NOT rewrite the "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 49, line 17 | skipping to change at page 54, line 17 | |||
8.1. Persistent Connections | 8.1. Persistent Connections | |||
8.1.1. Purpose | 8.1.1. Purpose | |||
Prior to persistent connections, a separate TCP connection was | Prior to persistent connections, a separate TCP connection was | |||
established to fetch each URL, increasing the load on HTTP servers | established to fetch each URL, increasing the load on HTTP servers | |||
and causing congestion on the Internet. The use of inline images and | and causing congestion on the Internet. The use of inline images and | |||
other associated data often require a client to make multiple | other associated data often require a client to make multiple | |||
requests of the same server in a short amount of time. Analysis of | requests of the same server in a short amount of time. Analysis of | |||
these performance problems and results from a prototype | these performance problems and results from a prototype | |||
implementation are available [26] [30]. Implementation experience | implementation are available [Pad1995] [Spero]. Implementation | |||
and measurements of actual HTTP/1.1 (RFC 2068) implementations show | experience and measurements of actual HTTP/1.1 ([RFC2068]) | |||
good results [39]. Alternatives have also been explored, for | implementations show good results [Nie1997]. Alternatives have also | |||
example, T/TCP [27]. | been explored, for example, T/TCP [Tou1998]. | |||
Persistent HTTP connections have a number of advantages: | Persistent HTTP connections have a number of advantages: | |||
o By opening and closing fewer TCP connections, CPU time is saved in | o By opening and closing fewer TCP connections, CPU time is saved in | |||
routers and hosts (clients, servers, proxies, gateways, tunnels, | routers and hosts (clients, servers, proxies, gateways, tunnels, | |||
or caches), and memory used for TCP protocol control blocks can be | or caches), and memory used for TCP protocol control blocks can be | |||
saved in hosts. | saved in hosts. | |||
o HTTP requests and responses can be pipelined on a connection. | o HTTP requests and responses can be pipelined on a connection. | |||
Pipelining allows a client to make multiple requests without | Pipelining allows a client to make multiple requests without | |||
skipping to change at page 50, line 36 | skipping to change at page 55, 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 51, line 29 | skipping to change at page 56, line 29 | |||
It is especially important that proxies correctly implement the | It is especially important that proxies correctly implement the | |||
properties of the Connection header field as specified in | properties of the Connection header field as specified in | |||
Section 14.10. | Section 14.10. | |||
The proxy server MUST signal persistent connections separately with | The proxy server MUST signal persistent connections separately with | |||
its clients and the origin servers (or other proxy servers) that it | its clients and the origin servers (or other proxy servers) that it | |||
connects to. Each persistent connection applies to only one | connects to. Each persistent connection applies to only one | |||
transport link. | transport link. | |||
A proxy server MUST NOT establish a HTTP/1.1 persistent connection | A proxy server MUST NOT establish a HTTP/1.1 persistent connection | |||
with an HTTP/1.0 client (but see RFC 2068 [33] for information and | with an HTTP/1.0 client (but see [RFC2068] for information and | |||
discussion of the problems with the Keep-Alive header implemented by | discussion of the problems with the Keep-Alive header implemented by | |||
many HTTP/1.0 clients). | many HTTP/1.0 clients). | |||
8.1.4. Practical Considerations | 8.1.4. Practical Considerations | |||
Servers will usually have some time-out value beyond which they will | Servers will usually have some time-out value beyond which they will | |||
no longer maintain an inactive connection. Proxy servers might make | no longer maintain an inactive connection. Proxy servers might make | |||
this a higher value since it is likely that the client will be making | this a higher value since it is likely that the client will be making | |||
more connections through the same server. The use of persistent | more connections through the same server. The use of persistent | |||
connections places no requirements on the length (or existence) of | connections places no requirements on the length (or existence) of | |||
skipping to change at page 59, line 16 | skipping to change at page 64, line 16 | |||
information contained in the response MAY be used to update a | information contained in the response MAY be used to update a | |||
previously cached entity from that resource. If the new field values | previously cached entity from that resource. If the new field values | |||
indicate that the cached entity differs from the current entity (as | indicate that the cached entity differs from the current entity (as | |||
would be indicated by a change in Content-Length, Content-MD5, ETag | would be indicated by a change in Content-Length, Content-MD5, ETag | |||
or Last-Modified), then the cache MUST treat the cache entry as | or Last-Modified), then the cache MUST treat the cache entry as | |||
stale. | stale. | |||
9.5. POST | 9.5. POST | |||
The POST method is used to request that the origin server accept the | The POST method is used to request that the origin server accept the | |||
entity enclosed in the request as a new subordinate of the resource | entity enclosed in the request as data to be processed by the | |||
identified by the Request-URI in the Request-Line. POST is designed | resource identified by the Request-URI in the Request-Line. POST is | |||
to allow a uniform method to cover the following functions: | designed to allow a uniform method to cover the following functions: | |||
o Annotation of existing resources; | o Annotation of existing resources; | |||
o Posting a message to a bulletin board, newsgroup, mailing list, or | o Posting a message to a bulletin board, newsgroup, mailing list, or | |||
similar group of articles; | similar group of articles; | |||
o Providing a block of data, such as the result of submitting a | o Providing a block of data, such as the result of submitting a | |||
form, to a data-handling process; | form, to a data-handling process; | |||
o Extending a database through an append operation. | o Extending a database through an append operation. | |||
The actual function performed by the POST method is determined by the | The actual function performed by the POST method is determined by the | |||
server and is usually dependent on the Request-URI. The posted | server and is usually dependent on the Request-URI. | |||
entity is subordinate to that URI in the same way that a file is | ||||
subordinate to a directory containing it, a news article is | ||||
subordinate to a newsgroup to which it is posted, or a record is | ||||
subordinate to a database. | ||||
The action performed by the POST method might not result in a | The action performed by the POST method might not result in a | |||
resource that can be identified by a URI. In this case, either 200 | resource that can be identified by a URI. In this case, either 200 | |||
(OK) or 204 (No Content) is the appropriate response status, | (OK) or 204 (No Content) is the appropriate response status, | |||
depending on whether or not the response includes an entity that | depending on whether or not the response includes an entity that | |||
describes the result. | describes the result. | |||
If a resource has been created on the origin server, the response | If a resource has been created on the origin server, the response | |||
SHOULD be 201 (Created) and contain an entity which describes the | SHOULD be 201 (Created) and contain an entity which describes the | |||
status of the request and refers to the new resource, and a Location | status of the request and refers to the new resource, and a Location | |||
skipping to change at page 62, line 13 | skipping to change at page 67, line 9 | |||
proxies forwarding messages in an infinite loop. | proxies forwarding messages in an infinite loop. | |||
If the request is valid, the response SHOULD contain the entire | If the request is valid, the response SHOULD contain the entire | |||
request message in the entity-body, with a Content-Type of "message/ | request message in the entity-body, with a Content-Type of "message/ | |||
http". Responses to this method MUST NOT be cached. | http". Responses to this method MUST NOT be cached. | |||
9.9. CONNECT | 9.9. CONNECT | |||
This specification reserves the method name CONNECT for use with a | This specification reserves the method name CONNECT for use with a | |||
proxy that can dynamically switch to being a tunnel (e.g. SSL | proxy that can dynamically switch to being a tunnel (e.g. SSL | |||
tunneling [44]). | tunneling [Luo1998]). | |||
10. Status Code Definitions | 10. Status Code Definitions | |||
Each Status-Code is described below, including a description of which | Each Status-Code is described below, including a description of which | |||
method(s) it can follow and any metainformation required in the | method(s) it can follow and any metainformation required in the | |||
response. | response. | |||
10.1. Informational 1xx | 10.1. Informational 1xx | |||
This class of status code indicates a provisional response, | This class of status code indicates a provisional response, | |||
skipping to change at page 66, line 32 | skipping to change at page 71, line 32 | |||
o Date | o Date | |||
o ETag and/or Content-Location, if the header would have been sent | o ETag and/or Content-Location, if the header would have been sent | |||
in a 200 response to the same request | in a 200 response to the same request | |||
o Expires, Cache-Control, and/or Vary, if the field-value might | o Expires, Cache-Control, and/or Vary, if the field-value might | |||
differ from that sent in any previous response for the same | differ from that sent in any previous response for the same | |||
variant | variant | |||
If the 206 response is the result of an If-Range request that used a | If the 206 response is the result of an If-Range request, the | |||
strong cache validator (see Section 13.3.3), the response SHOULD NOT | response SHOULD NOT include other entity-headers. Otherwise, the | |||
include other entity-headers. If the response is the result of an | response MUST include all of the entity-headers that would have been | |||
If-Range request that used a weak validator, the response MUST NOT | returned with a 200 (OK) response to the same request. | |||
include other entity-headers; this prevents inconsistencies between | ||||
cached entity-bodies and updated headers. Otherwise, the response | ||||
MUST include all of the entity-headers that would have been returned | ||||
with a 200 (OK) response to the same request. | ||||
A cache MUST NOT combine a 206 response with other previously cached | A cache MUST NOT combine a 206 response with other previously cached | |||
content if the ETag or Last-Modified headers do not match exactly, | content if the ETag or Last-Modified headers do not match exactly, | |||
see 13.5.4. | see 13.5.4. | |||
A cache that does not support the Range and Content-Range headers | A cache that does not support the Range and Content-Range headers | |||
MUST NOT cache 206 (Partial) responses. | MUST NOT cache 206 (Partial) responses. | |||
10.3. Redirection 3xx | 10.3. Redirection 3xx | |||
skipping to change at page 67, line 50 | skipping to change at page 72, line 46 | |||
URIs. Clients with link editing capabilities ought to automatically | URIs. Clients with link editing capabilities ought to automatically | |||
re-link references to the Request-URI to one or more of the new | re-link references to the Request-URI to one or more of the new | |||
references returned by the server, where possible. This response is | references returned by the server, where possible. This response is | |||
cacheable unless indicated otherwise. | cacheable unless indicated otherwise. | |||
The new permanent URI SHOULD be given by the Location field in the | The new permanent URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s). | the new URI(s). | |||
If the 301 status code is received in response to a request other | If the 301 status code is received in response to a request method | |||
than GET or HEAD, the user agent MUST NOT automatically redirect the | that is known to be "safe", as defined in Section 9.1.1, then the | |||
request unless it can be confirmed by the user, since this might | request MAY be automatically redirected by the user agent without | |||
change the conditions under which the request was issued. | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | ||||
this might change the conditions under which the request was issued. | ||||
Note: When automatically redirecting a POST request after | Note: When automatically redirecting a POST request after | |||
receiving a 301 status code, some existing HTTP/1.0 user agents | receiving a 301 status code, some existing HTTP/1.0 user agents | |||
will erroneously change it into a GET request. | will erroneously change it into a GET request. | |||
10.3.3. 302 Found | 10.3.3. 302 Found | |||
The requested resource resides temporarily under a different URI. | The requested resource resides temporarily under a different URI. | |||
Since the redirection might be altered on occasion, the client SHOULD | Since the redirection might be altered on occasion, the client SHOULD | |||
continue to use the Request-URI for future requests. This response | continue to use the Request-URI for future requests. This response | |||
is only cacheable if indicated by a Cache-Control or Expires header | is only cacheable if indicated by a Cache-Control or Expires header | |||
field. | field. | |||
The temporary URI SHOULD be given by the Location field in the | The temporary URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s). | the new URI(s). | |||
If the 302 status code is received in response to a request other | If the 302 status code is received in response to a request method | |||
than GET or HEAD, the user agent MUST NOT automatically redirect the | that is known to be "safe", as defined in Section 9.1.1, then the | |||
request unless it can be confirmed by the user, since this might | request MAY be automatically redirected by the user agent without | |||
change the conditions under which the request was issued. | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | ||||
this might change the conditions under which the request was issued. | ||||
Note: RFC 1945 and RFC 2068 specify that the client is not allowed | Note: RFC 1945 and RFC 2068 specify that the client is not allowed | |||
to change the method on the redirected request. However, most | to change the method on the redirected request. However, most | |||
existing user agent implementations treat 302 as if it were a 303 | existing user agent implementations treat 302 as if it were a 303 | |||
response, performing a GET on the Location field-value regardless | response, performing a GET on the Location field-value regardless | |||
of the original request method. The status codes 303 and 307 have | of the original request method. The status codes 303 and 307 have | |||
been added for servers that wish to make unambiguously clear which | been added for servers that wish to make unambiguously clear which | |||
kind of reaction is expected of the client. | kind of reaction is expected of the client. | |||
10.3.4. 303 See Other | 10.3.4. 303 See Other | |||
skipping to change at page 69, line 24 | skipping to change at page 74, line 24 | |||
respond with this status code. The 304 response MUST NOT contain a | respond with this status code. The 304 response MUST NOT contain a | |||
message-body, and thus is always terminated by the first empty line | message-body, and thus is always terminated by the first empty line | |||
after the header fields. | after the header fields. | |||
The response MUST include the following header fields: | The response MUST include the following header fields: | |||
o Date, unless its omission is required by Section 14.18.1 | o Date, unless its omission is required by Section 14.18.1 | |||
If a clockless origin server obeys these rules, and proxies and | If a clockless origin server obeys these rules, and proxies and | |||
clients add their own Date to any response received without one (as | clients add their own Date to any response received without one (as | |||
already specified by [RFC 2068], section 14.19), caches will operate | already specified by [RFC2068], Section 14.19), caches will operate | |||
correctly. | correctly. | |||
o ETag and/or Content-Location, if the header would have been sent | o ETag and/or Content-Location, if the header would have been sent | |||
in a 200 response to the same request | in a 200 response to the same request | |||
o Expires, Cache-Control, and/or Vary, if the field-value might | o Expires, Cache-Control, and/or Vary, if the field-value might | |||
differ from that sent in any previous response for the same | differ from that sent in any previous response for the same | |||
variant | variant | |||
If the conditional GET used a strong cache validator (see | If the conditional GET used a strong cache validator (see | |||
skipping to change at page 70, line 28 | skipping to change at page 75, line 28 | |||
The requested resource resides temporarily under a different URI. | The requested resource resides temporarily under a different URI. | |||
Since the redirection MAY be altered on occasion, the client SHOULD | Since the redirection MAY be altered on occasion, the client SHOULD | |||
continue to use the Request-URI for future requests. This response | continue to use the Request-URI for future requests. This response | |||
is only cacheable if indicated by a Cache-Control or Expires header | is only cacheable if indicated by a Cache-Control or Expires header | |||
field. | field. | |||
The temporary URI SHOULD be given by the Location field in the | The temporary URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s) , since many pre-HTTP/1.1 user agents do not | the new URI(s), since many pre-HTTP/1.1 user agents do not understand | |||
understand the 307 status. Therefore, the note SHOULD contain the | the 307 status. Therefore, the note SHOULD contain the information | |||
information necessary for a user to repeat the original request on | necessary for a user to repeat the original request on the new URI. | |||
the new URI. | ||||
If the 307 status code is received in response to a request other | If the 307 status code is received in response to a request method | |||
than GET or HEAD, the user agent MUST NOT automatically redirect the | that is known to be "safe", as defined in Section 9.1.1, then the | |||
request unless it can be confirmed by the user, since this might | request MAY be automatically redirected by the user agent without | |||
change the conditions under which the request was issued. | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | ||||
this might change the conditions under which the request was issued. | ||||
10.4. Client Error 4xx | 10.4. Client Error 4xx | |||
The 4xx class of status code is intended for cases in which the | The 4xx class of status code is intended for cases in which the | |||
client seems to have erred. Except when responding to a HEAD | client seems to have erred. Except when responding to a HEAD | |||
request, the server SHOULD include an entity containing an | request, the server SHOULD include an entity containing an | |||
explanation of the error situation, and whether it is a temporary or | explanation of the error situation, and whether it is a temporary or | |||
permanent condition. These status codes are applicable to any | permanent condition. These status codes are applicable to any | |||
request method. User agents SHOULD display any included entity to | request method. User agents SHOULD display any included entity to | |||
the user. | the user. | |||
skipping to change at page 71, line 27 | skipping to change at page 76, line 28 | |||
challenge applicable to the requested resource. The client MAY | challenge applicable to the requested resource. The client MAY | |||
repeat the request with a suitable Authorization header field | repeat the request with a suitable Authorization header field | |||
(Section 14.8). If the request already included Authorization | (Section 14.8). If the request already included Authorization | |||
credentials, then the 401 response indicates that authorization has | credentials, then the 401 response indicates that authorization has | |||
been refused for those credentials. If the 401 response contains the | been refused for those credentials. If the 401 response contains the | |||
same challenge as the prior response, and the user agent has already | same challenge as the prior response, and the user agent has already | |||
attempted authentication at least once, then the user SHOULD be | attempted authentication at least once, then the user SHOULD be | |||
presented the entity that was given in the response, since that | presented the entity that was given in the response, since that | |||
entity might include relevant diagnostic information. HTTP access | entity might include relevant diagnostic information. HTTP access | |||
authentication is explained in "HTTP Authentication: Basic and Digest | authentication is explained in "HTTP Authentication: Basic and Digest | |||
Access Authentication" [43]. | Access Authentication" [RFC2617]. | |||
10.4.3. 402 Payment Required | 10.4.3. 402 Payment Required | |||
This code is reserved for future use. | This code is reserved for future use. | |||
10.4.4. 403 Forbidden | 10.4.4. 403 Forbidden | |||
The server understood the request, but is refusing to fulfill it. | The server understood the request, but is refusing to fulfill it. | |||
Authorization will not help and the request SHOULD NOT be repeated. | Authorization will not help and the request SHOULD NOT be repeated. | |||
If the request method was not HEAD and the server wishes to make | If the request method was not HEAD and the server wishes to make | |||
skipping to change at page 72, line 47 | skipping to change at page 77, line 48 | |||
10.4.8. 407 Proxy Authentication Required | 10.4.8. 407 Proxy Authentication Required | |||
This code is similar to 401 (Unauthorized), but indicates that the | This code is similar to 401 (Unauthorized), but indicates that the | |||
client must first authenticate itself with the proxy. The proxy MUST | client must first authenticate itself with the proxy. The proxy MUST | |||
return a Proxy-Authenticate header field (Section 14.33) containing a | return a Proxy-Authenticate header field (Section 14.33) containing a | |||
challenge applicable to the proxy for the requested resource. The | challenge applicable to the proxy for the requested resource. The | |||
client MAY repeat the request with a suitable Proxy-Authorization | client MAY repeat the request with a suitable Proxy-Authorization | |||
header field (Section 14.34). HTTP access authentication is | header field (Section 14.34). HTTP access authentication is | |||
explained in "HTTP Authentication: Basic and Digest Access | explained in "HTTP Authentication: Basic and Digest Access | |||
Authentication" [43]. | Authentication" [RFC2617]. | |||
10.4.9. 408 Request Timeout | 10.4.9. 408 Request Timeout | |||
The client did not produce a request within the time that the server | The client did not produce a request within the time that the server | |||
was prepared to wait. The client MAY repeat the request without | was prepared to wait. The client MAY repeat the request without | |||
modifications at any later time. | modifications at any later time. | |||
10.4.10. 409 Conflict | 10.4.10. 409 Conflict | |||
The request could not be completed due to a conflict with the current | The request could not be completed due to a conflict with the current | |||
skipping to change at page 77, line 12 | skipping to change at page 82, line 12 | |||
contain an entity describing why that version is not supported and | contain an entity describing why that version is not supported and | |||
what other protocols are supported by that server. | what other protocols are supported by that server. | |||
11. Access Authentication | 11. Access Authentication | |||
HTTP provides several OPTIONAL challenge-response authentication | HTTP provides several OPTIONAL challenge-response authentication | |||
mechanisms which can be used by a server to challenge a client | mechanisms which can be used by a server to challenge a client | |||
request and by a client to provide authentication information. The | request and by a client to provide authentication information. The | |||
general framework for access authentication, and the specification of | general framework for access authentication, and the specification of | |||
"basic" and "digest" authentication, are specified in "HTTP | "basic" and "digest" authentication, are specified in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [43]. This | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
specification adopts the definitions of "challenge" and "credentials" | This specification adopts the definitions of "challenge" and | |||
from that specification. | "credentials" from that specification. | |||
12. Content Negotiation | 12. Content Negotiation | |||
Most HTTP responses include an entity which contains information for | Most HTTP responses include an entity which contains information for | |||
interpretation by a human user. Naturally, it is desirable to supply | interpretation by a human user. Naturally, it is desirable to supply | |||
the user with the "best available" entity corresponding to the | the user with the "best available" entity corresponding to the | |||
request. Unfortunately for servers and caches, not all users have | request. Unfortunately for servers and caches, not all users have | |||
the same preferences for what is "best," and not all user agents are | the same preferences for what is "best," and not all user agents are | |||
equally capable of rendering all entity types. For that reason, HTTP | equally capable of rendering all entity types. For that reason, HTTP | |||
has provisions for several mechanisms for "content negotiation" -- | has provisions for several mechanisms for "content negotiation" -- | |||
skipping to change at page 82, line 19 | skipping to change at page 87, line 19 | |||
ought to err on the side of maintaining transparency unless a | ought to err on the side of maintaining transparency unless a | |||
careful and complete analysis shows significant benefits in | careful and complete analysis shows significant benefits in | |||
breaking transparency. | breaking transparency. | |||
13.1. | 13.1. | |||
13.1.1. Cache Correctness | 13.1.1. Cache Correctness | |||
A correct cache MUST respond to a request with the most up-to-date | A correct cache MUST respond to a request with the most up-to-date | |||
response held by the cache that is appropriate to the request (see | response held by the cache that is appropriate to the request (see | |||
sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | Sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | |||
conditions: | conditions: | |||
1. It has been checked for equivalence with what the origin server | 1. It has been checked for equivalence with what the origin server | |||
would have returned by revalidating the response with the origin | would have returned by revalidating the response with the origin | |||
server (Section 13.3); | server (Section 13.3); | |||
2. It is "fresh enough" (see Section 13.2). In the default case, | 2. It is "fresh enough" (see Section 13.2). In the default case, | |||
this means it meets the least restrictive freshness requirement | this means it meets the least restrictive freshness requirement | |||
of the client, origin server, and cache (see Section 14.9); if | of the client, origin server, and cache (see Section 14.9); if | |||
the origin server so specifies, it is the freshness requirement | the origin server so specifies, it is the freshness requirement | |||
of the origin server alone. If a stored response is not "fresh | of the origin server alone. If a stored response is not "fresh | |||
enough" by the most restrictive freshness requirement of both the | enough" by the most restrictive freshness requirement of both the | |||
client and the origin server, in carefully considered | client and the origin server, in carefully considered | |||
circumstances the cache MAY still return the response with the | circumstances the cache MAY still return the response with the | |||
appropriate Warning header (see section 13.1.5 and 14.46), unless | appropriate Warning header (see Section 13.1.5 and 14.46), unless | |||
such a response is prohibited (e.g., by a "no-store" cache- | such a response is prohibited (e.g., by a "no-store" cache- | |||
directive, or by a "no-cache" cache-request-directive; see | directive, or by a "no-cache" cache-request-directive; see | |||
Section 14.9). | Section 14.9). | |||
3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or | 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or | |||
error (4xx or 5xx) response message. | error (4xx or 5xx) response message. | |||
If the cache can not communicate with the origin server, then a | If the cache can not communicate with the origin server, then a | |||
correct cache SHOULD respond as above if the response can be | correct cache SHOULD respond as above if the response can be | |||
correctly served from the cache; if not it MUST return an error or | correctly served from the cache; if not it MUST return an error or | |||
skipping to change at page 83, line 28 | skipping to change at page 88, line 28 | |||
Warnings MAY be used for other purposes, both cache-related and | Warnings MAY be used for other purposes, both cache-related and | |||
otherwise. The use of a warning, rather than an error status code, | otherwise. The use of a warning, rather than an error status code, | |||
distinguish these responses from true failures. | distinguish these responses from true failures. | |||
Warnings are assigned three digit warn-codes. The first digit | Warnings are assigned three digit warn-codes. The first digit | |||
indicates whether the Warning MUST or MUST NOT be deleted from a | indicates whether the Warning MUST or MUST NOT be deleted from a | |||
stored cache entry after a successful revalidation: | stored cache entry after a successful revalidation: | |||
1xx Warnings that describe the freshness or revalidation status of | 1xx Warnings that describe the freshness or revalidation status of | |||
the response, and so MUST be deleted after a successful | the response, and so MUST be deleted after a successful | |||
revalidation. 1XX warn-codes MAY be generated by a cache only when | revalidation. 1xx warn-codes MAY be generated by a cache only when | |||
validating a cached entry. It MUST NOT be generated by clients. | validating a cached entry. It MUST NOT be generated by clients. | |||
2xx Warnings that describe some aspect of the entity body or entity | 2xx Warnings that describe some aspect of the entity body or entity | |||
headers that is not rectified by a revalidation (for example, a | headers that is not rectified by a revalidation (for example, a | |||
lossy compression of the entity bodies) and which MUST NOT be | lossy compression of the entity bodies) and which MUST NOT be | |||
deleted after a successful revalidation. | deleted after a successful revalidation. | |||
See Section 14.46 for the definitions of the codes themselves. | See Section 14.46 for the definitions of the codes themselves. | |||
HTTP/1.0 caches will cache all Warnings in responses, without | HTTP/1.0 caches will cache all Warnings in responses, without | |||
skipping to change at page 87, line 20 | skipping to change at page 92, line 20 | |||
13.2.3. Age Calculations | 13.2.3. Age Calculations | |||
In order to know if a cached entry is fresh, a cache needs to know if | In order to know if a cached entry is fresh, a cache needs to know if | |||
its age exceeds its freshness lifetime. We discuss how to calculate | its age exceeds its freshness lifetime. We discuss how to calculate | |||
the latter in Section 13.2.4; this section describes how to calculate | the latter in Section 13.2.4; this section describes how to calculate | |||
the age of a response or cache entry. | the age of a response or cache entry. | |||
In this discussion, we use the term "now" to mean "the current value | In this discussion, we use the term "now" to mean "the current value | |||
of the clock at the host performing the calculation." Hosts that use | of the clock at the host performing the calculation." Hosts that use | |||
HTTP, but especially hosts running origin servers and caches, SHOULD | HTTP, but especially hosts running origin servers and caches, SHOULD | |||
use NTP [28] or some similar protocol to synchronize their clocks to | use NTP [RFC1305] or some similar protocol to synchronize their | |||
a globally accurate time standard. | clocks to a globally accurate time standard. | |||
HTTP/1.1 requires origin servers to send a Date header, if possible, | HTTP/1.1 requires origin servers to send a Date header, if possible, | |||
with every response, giving the time at which the response was | with every response, giving the time at which the response was | |||
generated (see Section 14.18). We use the term "date_value" to | generated (see Section 14.18). We use the term "date_value" to | |||
denote the value of the Date header, in a form appropriate for | denote the value of the Date header, in a form appropriate for | |||
arithmetic operations. | arithmetic operations. | |||
HTTP/1.1 uses the Age response-header to convey the estimated age of | HTTP/1.1 uses the Age response-header to convey the estimated age of | |||
the response message when obtained from a cache. The Age field value | the response message when obtained from a cache. The Age field value | |||
is the cache's estimate of the amount of time since the response was | is the cache's estimate of the amount of time since the response was | |||
skipping to change at page 93, line 6 | skipping to change at page 98, line 6 | |||
13.3.2. Entity Tag Cache Validators | 13.3.2. Entity Tag Cache Validators | |||
The ETag response-header field value, an entity tag, provides for an | The ETag response-header field value, an entity tag, provides for an | |||
"opaque" cache validator. This might allow more reliable validation | "opaque" cache validator. This might allow more reliable validation | |||
in situations where it is inconvenient to store modification dates, | in situations where it is inconvenient to store modification dates, | |||
where the one-second resolution of HTTP date values is not | where the one-second resolution of HTTP date values is not | |||
sufficient, or where the origin server wishes to avoid certain | sufficient, or where the origin server wishes to avoid certain | |||
paradoxes that might arise from the use of modification dates. | paradoxes that might arise from the use of modification dates. | |||
Entity Tags are described in Section 3.11. The headers used with | Entity Tags are described in Section 3.11. The headers used with | |||
entity tags are described in sections 14.19, 14.24, 14.26 and 14.44. | entity tags are described in Sections 14.19, 14.24, 14.26 and 14.44. | |||
13.3.3. Weak and Strong Validators | 13.3.3. Weak and Strong Validators | |||
Since both origin servers and caches will compare two validators to | Since both origin servers and caches will compare two validators to | |||
decide if they represent the same or different entities, one normally | decide if they represent the same or different entities, one normally | |||
would expect that if the entity (the entity-body or any entity- | would expect that if the entity (the entity-body or any entity- | |||
headers) changes in any way, then the associated validator would | headers) changes in any way, then the associated validator would | |||
change as well. If this is true, then we call this validator a | change as well. If this is true, then we call this validator a | |||
"strong validator." | "strong validator." | |||
skipping to change at page 99, line 21 | skipping to change at page 104, line 21 | |||
o Connection | o Connection | |||
o Keep-Alive | o Keep-Alive | |||
o Proxy-Authenticate | o Proxy-Authenticate | |||
o Proxy-Authorization | o Proxy-Authorization | |||
o TE | o TE | |||
o Trailers | o Trailer | |||
o Transfer-Encoding | o Transfer-Encoding | |||
o Upgrade | o Upgrade | |||
All other headers defined by HTTP/1.1 are end-to-end headers. | All other headers defined by HTTP/1.1 are end-to-end headers. | |||
Other hop-by-hop headers MUST be listed in a Connection header, | Other hop-by-hop headers, if they are introduced either in HTTP/1.1 | |||
(Section 14.10) to be introduced into HTTP/1.1 (or later). | or later versions of HTTP/1.x, MUST be listed in a Connection header | |||
(Section 14.10). | ||||
13.5.2. Non-modifiable Headers | 13.5.2. Non-modifiable Headers | |||
Some features of the HTTP/1.1 protocol, such as Digest | Some features of the HTTP/1.1 protocol, such as Digest | |||
Authentication, depend on the value of certain end-to-end headers. A | Authentication, depend on the value of certain end-to-end headers. A | |||
transparent proxy SHOULD NOT modify an end-to-end header unless the | transparent proxy SHOULD NOT modify an end-to-end header unless the | |||
definition of that header requires or specifically allows that. | definition of that header requires or specifically allows that. | |||
A transparent proxy MUST NOT modify any of the following fields in a | A transparent proxy MUST NOT modify any of the following fields in a | |||
request or response, and it MUST NOT add any of these fields if not | request or response, and it MUST NOT add any of these fields if not | |||
skipping to change at page 105, line 11 | skipping to change at page 110, line 11 | |||
is either the entity referred to by the Request-URI, or by the | is either the entity referred to by the Request-URI, or by the | |||
Location or Content-Location headers (if present). These methods | Location or Content-Location headers (if present). These methods | |||
are: | are: | |||
o PUT | o PUT | |||
o DELETE | o DELETE | |||
o POST | o POST | |||
In order to prevent denial of service attacks, an invalidation based | An invalidation based on the URI in a Location or Content-Location | |||
on the URI in a Location or Content-Location header MUST only be | header MUST NOT be performed if the host part of that URI differs | |||
performed if the host part is the same as in the Request-URI. | from the host part in the Request-URI. This helps prevent denial of | |||
service attacks. | ||||
A cache that passes through requests for methods it does not | A cache that passes through requests for methods it does not | |||
understand SHOULD invalidate any entities referred to by the Request- | understand SHOULD invalidate any entities referred to by the Request- | |||
URI. | URI. | |||
13.11. Write-Through Mandatory | 13.11. Write-Through Mandatory | |||
All methods that might be expected to cause modifications to the | All methods that might be expected to cause modifications to the | |||
origin server's resources MUST be written through to the origin | origin server's resources MUST be written through to the origin | |||
server. This currently includes all methods except for GET and HEAD. | server. This currently includes all methods except for GET and HEAD. | |||
skipping to change at page 105, line 37 | skipping to change at page 110, line 38 | |||
prevent a proxy cache from sending a 100 (Continue) response before | prevent a proxy cache from sending a 100 (Continue) response before | |||
the inbound server has sent its final reply. | the inbound server has sent its final reply. | |||
The alternative (known as "write-back" or "copy-back" caching) is not | The alternative (known as "write-back" or "copy-back" caching) is not | |||
allowed in HTTP/1.1, due to the difficulty of providing consistent | allowed in HTTP/1.1, due to the difficulty of providing consistent | |||
updates and the problems arising from server, cache, or network | updates and the problems arising from server, cache, or network | |||
failure prior to write-back. | failure prior to write-back. | |||
13.12. Cache Replacement | 13.12. Cache Replacement | |||
If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) | If a new cacheable (see Sections 14.9.2, 13.2.5, 13.2.6 and 13.8) | |||
response is received from a resource while any existing responses for | response is received from a resource while any existing responses for | |||
the same resource are cached, the cache SHOULD use the new response | the same resource are cached, the cache SHOULD use the new response | |||
to reply to the current request. It MAY insert it into cache storage | to reply to the current request. It MAY insert it into cache storage | |||
and MAY, if it meets all other requirements, use it to respond to any | and MAY, if it meets all other requirements, use it to respond to any | |||
future requests that would previously have caused the old response to | future requests that would previously have caused the old response to | |||
be returned. If it inserts the new response into cache storage the | be returned. If it inserts the new response into cache storage the | |||
rules in Section 13.5.3 apply. | rules in Section 13.5.3 apply. | |||
Note: a new response that has an older Date header value than | Note: a new response that has an older Date header value than | |||
existing cached responses is not cacheable. | existing cached responses is not cacheable. | |||
skipping to change at page 106, line 32 | skipping to change at page 111, line 32 | |||
This is not to be construed to prohibit the history mechanism from | This is not to be construed to prohibit the history mechanism from | |||
telling the user that a view might be stale. | telling the user that a view might be stale. | |||
Note: if history list mechanisms unnecessarily prevent users from | Note: if history list mechanisms unnecessarily prevent users from | |||
viewing stale resources, this will tend to force service authors | viewing stale resources, this will tend to force service authors | |||
to avoid using HTTP expiration controls and cache controls when | to avoid using HTTP expiration controls and cache controls when | |||
they would otherwise like to. Service authors may consider it | they would otherwise like to. Service authors may consider it | |||
important that users not be presented with error messages or | important that users not be presented with error messages or | |||
warning messages when they use navigation controls (such as BACK) | warning messages when they use navigation controls (such as BACK) | |||
to view previously fetched resources. Even though sometimes such | to view previously fetched resources. Even though sometimes such | |||
resources ought not to cached, or ought to expire quickly, user | resources ought not be cached, or ought to expire quickly, user | |||
interface considerations may force service authors to resort to | interface considerations may force service authors to resort to | |||
other means of preventing caching (e.g. "once-only" URLs) in order | other means of preventing caching (e.g. "once-only" URLs) in order | |||
not to suffer the effects of improperly functioning history | not to suffer the effects of improperly functioning history | |||
mechanisms. | mechanisms. | |||
14. Header Field Definitions | 14. Header Field Definitions | |||
This section defines the syntax and semantics of all standard | This section defines the syntax and semantics of all standard | |||
HTTP/1.1 header fields. For entity-header fields, both sender and | HTTP/1.1 header fields. For entity-header fields, both sender and | |||
recipient refer to either the client or the server, depending on who | recipient refer to either the client or the server, depending on who | |||
skipping to change at page 114, line 12 | skipping to change at page 119, line 12 | |||
A user agent that wishes to authenticate itself with a server-- | A user agent that wishes to authenticate itself with a server-- | |||
usually, but not necessarily, after receiving a 401 response--does so | usually, but not necessarily, after receiving a 401 response--does so | |||
by including an Authorization request-header field with the request. | by including an Authorization request-header field with the request. | |||
The Authorization field value consists of credentials containing the | The Authorization field value consists of credentials containing the | |||
authentication information of the user agent for the realm of the | authentication information of the user agent for the realm of the | |||
resource being requested. | resource being requested. | |||
Authorization = "Authorization" ":" credentials | Authorization = "Authorization" ":" credentials | |||
HTTP access authentication is described in "HTTP Authentication: | HTTP access authentication is described in "HTTP Authentication: | |||
Basic and Digest Access Authentication" [43]. If a request is | Basic and Digest Access Authentication" [RFC2617]. If a request is | |||
authenticated and a realm specified, the same credentials SHOULD be | authenticated and a realm specified, the same credentials SHOULD be | |||
valid for all other requests within this realm (assuming that the | valid for all other requests within this realm (assuming that the | |||
authentication scheme itself does not require otherwise, such as | authentication scheme itself does not require otherwise, such as | |||
credentials that vary according to a challenge value or using | credentials that vary according to a challenge value or using | |||
synchronized clocks). | synchronized clocks). | |||
When a shared cache (see Section 13.7) receives a request containing | When a shared cache (see Section 13.7) receives a request containing | |||
an Authorization field, it MUST NOT return the corresponding response | an Authorization field, it MUST NOT return the corresponding response | |||
as a reply to any other request, unless one of the following specific | as a reply to any other request, unless one of the following specific | |||
exceptions holds: | exceptions holds: | |||
skipping to change at page 124, line 45 | skipping to change at page 129, line 45 | |||
HTTP/1.1 defines the "close" connection option for the sender to | HTTP/1.1 defines the "close" connection option for the sender to | |||
signal that the connection will be closed after completion of the | signal that the connection will be closed after completion of the | |||
response. For example, | response. For example, | |||
Connection: close | Connection: close | |||
in either the request or the response header fields indicates that | in either the request or the response header fields indicates that | |||
the connection SHOULD NOT be considered `persistent' (Section 8.1) | the connection SHOULD NOT be considered `persistent' (Section 8.1) | |||
after the current request/response is complete. | after the current request/response is complete. | |||
HTTP/1.1 applications that do not support persistent connections MUST | An HTTP/1.1 client that does not support persistent connections MUST | |||
include the "close" connection option in every message. | include the "close" connection option in every request message. | |||
An HTTP/1.1 server that does not support persistent connections MUST | ||||
include the "close" connection option in every response message that | ||||
does not have a 1xx (informational) status code. | ||||
A system receiving an HTTP/1.0 (or lower-version) message that | A system receiving an HTTP/1.0 (or lower-version) message that | |||
includes a Connection header MUST, for each connection-token in this | includes a Connection header MUST, for each connection-token in this | |||
field, remove and ignore any header field(s) from the message with | field, remove and ignore any header field(s) from the message with | |||
the same name as the connection-token. This protects against | the same name as the connection-token. This protects against | |||
mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. | |||
See Appendix 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 125, line 31 | skipping to change at page 130, line 36 | |||
Content-Encoding: gzip | Content-Encoding: gzip | |||
The content-coding is a characteristic of the entity identified by | The content-coding is a characteristic of the entity identified by | |||
the Request-URI. Typically, the entity-body is stored with this | the Request-URI. Typically, the entity-body is stored with this | |||
encoding and is only decoded before rendering or analogous usage. | encoding and is only decoded before rendering or analogous usage. | |||
However, a non-transparent proxy MAY modify the content-coding if the | However, a non-transparent proxy MAY modify the content-coding if the | |||
new coding is known to be acceptable to the recipient, unless the | new coding is known to be acceptable to the recipient, unless the | |||
"no-transform" cache-control directive is present in the message. | "no-transform" cache-control directive is present in the message. | |||
If the content-coding of an entity is not "identity", then the | If the content-coding of an entity is not "identity", then the | |||
response MUST include a Content-Encoding entity-header | response MUST include a Content-Encoding entity-header that lists the | |||
(Section 14.11) that lists the non-identity content-coding(s) used. | non-identity content-coding(s) used. | |||
If the content-coding of an entity in a request message is not | If the content-coding of an entity in a request message is not | |||
acceptable to the origin server, the server SHOULD respond with a | acceptable to the origin server, the server SHOULD respond with a | |||
status code of 415 (Unsupported Media Type). | status code of 415 (Unsupported Media Type). | |||
If multiple encodings have been applied to an entity, the content | If multiple encodings have been applied to an entity, the content | |||
codings MUST be listed in the order in which they were applied. | codings MUST be listed in the order in which they were applied. | |||
Additional information about the encoding parameters MAY be provided | Additional information about the encoding parameters MAY be provided | |||
by other entity-header fields not defined by this specification. | by other entity-header fields not defined by this specification. | |||
skipping to change at page 128, line 7 | skipping to change at page 133, line 10 | |||
Section 13.6. | Section 13.6. | |||
If the Content-Location is a relative URI, the relative URI is | If the Content-Location is a relative URI, the relative URI is | |||
interpreted relative to the Request-URI. | interpreted relative to the Request-URI. | |||
The meaning of the Content-Location header in PUT or POST requests is | The meaning of the Content-Location header in PUT or POST requests is | |||
undefined; servers are free to ignore it in those cases. | undefined; servers are free to ignore it in those cases. | |||
14.15. Content-MD5 | 14.15. Content-MD5 | |||
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is | The Content-MD5 entity-header field, as defined in [RFC1864], is an | |||
an MD5 digest of the entity-body for the purpose of providing an end- | MD5 digest of the entity-body for the purpose of providing an end-to- | |||
to-end message integrity check (MIC) of the entity-body. (Note: a | end message integrity check (MIC) of the entity-body. (Note: a MIC | |||
MIC is good for detecting accidental modification of the entity-body | is good for detecting accidental modification of the entity-body in | |||
in transit, but is not proof against malicious attacks.) | transit, but is not proof against malicious attacks.) | |||
Content-MD5 = "Content-MD5" ":" md5-digest | Content-MD5 = "Content-MD5" ":" md5-digest | |||
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> | md5-digest = <base64 of 128 bit MD5 digest as per [RFC1864]> | |||
The Content-MD5 header field MAY be generated by an origin server or | The Content-MD5 header field MAY be generated by an origin server or | |||
client to function as an integrity check of the entity-body. Only | client to function as an integrity check of the entity-body. Only | |||
origin servers or clients MAY generate the Content-MD5 header field; | origin servers or clients MAY generate the Content-MD5 header field; | |||
proxies and gateways MUST NOT generate it, as this would defeat its | proxies and gateways MUST NOT generate it, as this would defeat its | |||
value as an end-to-end integrity check. Any recipient of the entity- | value as an end-to-end integrity check. Any recipient of the entity- | |||
body, including gateways and proxies, MAY check that the digest value | body, including gateways and proxies, MAY check that the digest value | |||
in this header field matches that of the entity-body as received. | in this header field matches that of the entity-body as received. | |||
The MD5 digest is computed based on the content of the entity-body, | The MD5 digest is computed based on the content of the entity-body, | |||
skipping to change at page 130, line 44 | skipping to change at page 135, line 48 | |||
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 131, line 46 | skipping to change at page 136, line 49 | |||
Content-Type: text/html; charset=ISO-8859-4 | Content-Type: text/html; charset=ISO-8859-4 | |||
Further discussion of methods for identifying the media type of an | Further discussion of methods for identifying the media type of an | |||
entity is provided in Section 7.2.1. | entity is provided in Section 7.2.1. | |||
14.18. Date | 14.18. Date | |||
The Date general-header field represents the date and time at which | The Date general-header field represents the date and time at which | |||
the message was originated, having the same semantics as orig-date in | the message was originated, having the same semantics as orig-date in | |||
RFC 822. The field value is an HTTP-date, as described in | RFC 822. The field value is an HTTP-date, as described in | |||
Section 3.3.1; it MUST be sent in RFC 1123 [8]-date format. | Section 3.3.1; it MUST be sent in rfc1123-date format. | |||
Date = "Date" ":" HTTP-date | Date = "Date" ":" HTTP-date | |||
An example is | An example is | |||
Date: Tue, 15 Nov 1994 08:12:31 GMT | Date: Tue, 15 Nov 1994 08:12:31 GMT | |||
Origin servers MUST include a Date header field in all responses, | Origin servers MUST include a Date header field in all responses, | |||
except in these cases: | except in these cases: | |||
1. If the response status code is 100 (Continue) or 101 (Switching | 1. If the response status code is 100 (Continue) or 101 (Switching | |||
Protocols), the response MAY include a Date header field, at the | Protocols), the response MAY include a Date header field, at the | |||
server's option. | server's option. | |||
2. If the response status code conveys a server error, e.g. 500 | 2. If the response status code conveys a server error, e.g. 500 | |||
(Internal Server Error) or 503 (Service Unavailable), and it is | (Internal Server Error) or 503 (Service Unavailable), and it is | |||
inconvenient or impossible to generate a valid Date. | inconvenient or impossible to generate a valid Date. | |||
skipping to change at page 132, line 25 | skipping to change at page 137, line 29 | |||
3. If the server does not have a clock that can provide a reasonable | 3. If the server does not have a clock that can provide a reasonable | |||
approximation of the current time, its responses MUST NOT include | approximation of the current time, its responses MUST NOT include | |||
a Date header field. In this case, the rules in Section 14.18.1 | a Date header field. In this case, the rules in Section 14.18.1 | |||
MUST be followed. | MUST be followed. | |||
A received message that does not have a Date header field MUST be | A received message that does not have a Date header field MUST be | |||
assigned one by the recipient if the message will be cached by that | assigned one by the recipient if the message will be cached by that | |||
recipient or gatewayed via a protocol which requires a Date. An HTTP | recipient or gatewayed via a protocol which requires a Date. An HTTP | |||
implementation without a clock MUST NOT cache responses without | implementation without a clock MUST NOT cache responses without | |||
revalidating them on every use. An HTTP cache, especially a shared | revalidating them on every use. An HTTP cache, especially a shared | |||
cache, SHOULD use a mechanism, such as NTP [28], to synchronize its | cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize | |||
clock with a reliable external standard. | its clock with a reliable external standard. | |||
Clients SHOULD only send a Date header field in messages that include | Clients SHOULD only send a Date header field in messages that include | |||
an entity-body, as in the case of the PUT and POST requests, and even | an entity-body, as in the case of the PUT and POST requests, and even | |||
then it is optional. A client without a clock MUST NOT send a Date | then it is optional. A client without a clock MUST NOT send a Date | |||
header field in a request. | header field in a request. | |||
The HTTP-date sent in a Date header SHOULD NOT represent a date and | The HTTP-date sent in a Date header SHOULD NOT represent a date and | |||
time subsequent to the generation of the message. It SHOULD | time subsequent to the generation of the message. It SHOULD | |||
represent the best available approximation of the date and time of | represent the best available approximation of the date and time of | |||
message generation, unless the implementation has no means of | message generation, unless the implementation has no means of | |||
skipping to change at page 133, line 9 | skipping to change at page 138, line 13 | |||
with the resource by a system or user with a reliable clock. It MAY | with the resource by a system or user with a reliable clock. It MAY | |||
assign an Expires value that is known, at or before server | assign an Expires value that is known, at or before server | |||
configuration time, to be in the past (this allows "pre-expiration" | configuration time, to be in the past (this allows "pre-expiration" | |||
of responses without storing separate Expires values for each | of responses without storing separate Expires values for each | |||
resource). | resource). | |||
14.19. ETag | 14.19. ETag | |||
The ETag response-header field provides the current value of the | The ETag response-header field provides the current value of the | |||
entity tag for the requested variant. The headers used with entity | entity tag for the requested variant. The headers used with entity | |||
tags are described in sections 14.24, 14.26 and 14.44. The entity | tags are described in Sections 14.24, 14.26 and 14.44. The entity | |||
tag MAY be used for comparison with other entities from the same | tag MAY be used for comparison with other entities from the same | |||
resource (see Section 13.3.3). | resource (see Section 13.3.3). | |||
ETag = "ETag" ":" entity-tag | ETag = "ETag" ":" entity-tag | |||
Examples: | Examples: | |||
ETag: "xyzzy" | ETag: "xyzzy" | |||
ETag: W/"xyzzy" | ETag: W/"xyzzy" | |||
ETag: "" | ETag: "" | |||
skipping to change at page 134, line 25 | skipping to change at page 139, line 30 | |||
be returned by a cache (either a proxy cache or a user agent cache) | be returned by a cache (either a proxy cache or a user agent cache) | |||
unless it is first validated with the origin server (or with an | unless it is first validated with the origin server (or with an | |||
intermediate cache that has a fresh copy of the entity). See | intermediate cache that has a fresh copy of the entity). See | |||
Section 13.2 for further discussion of the expiration model. | Section 13.2 for further discussion of the expiration model. | |||
The presence of an Expires field does not imply that the original | The presence of an Expires field does not imply that the original | |||
resource will change or cease to exist at, before, or after that | resource will change or cease to exist at, before, or after that | |||
time. | time. | |||
The format is an absolute date and time as defined by HTTP-date in | The format is an absolute date and time as defined by HTTP-date in | |||
Section 3.3.1; it MUST be in RFC 1123 date format: | Section 3.3.1; it MUST be in rfc1123-date format: | |||
Expires = "Expires" ":" HTTP-date | Expires = "Expires" ":" HTTP-date | |||
An example of its use is | An example of its use is | |||
Expires: Thu, 01 Dec 1994 16:00:00 GMT | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |||
Note: if a response includes a Cache-Control field with the max- | Note: if a response includes a Cache-Control field with the max- | |||
age directive (see Section 14.9.3), that directive overrides the | age directive (see Section 14.9.3), that directive overrides the | |||
Expires field. | Expires field. | |||
skipping to change at page 135, line 12 | skipping to change at page 140, line 16 | |||
The presence of an Expires header field with a date value of some | The presence of an Expires header field with a date value of some | |||
time in the future on a response that otherwise would by default be | time in the future on a response that otherwise would by default be | |||
non-cacheable indicates that the response is cacheable, unless | non-cacheable indicates that the response is cacheable, unless | |||
indicated otherwise by a Cache-Control header field (Section 14.9). | indicated otherwise by a Cache-Control header field (Section 14.9). | |||
14.22. From | 14.22. From | |||
The From request-header field, if given, SHOULD contain an Internet | The From request-header field, if given, SHOULD contain an Internet | |||
e-mail address for the human user who controls the requesting user | e-mail address for the human user who controls the requesting user | |||
agent. The address SHOULD be machine-usable, as defined by "mailbox" | agent. The address SHOULD be machine-usable, as defined by "mailbox" | |||
in RFC 822 [9] as updated by RFC 1123 [8]: | in [RFC822] as updated by [RFC1123]: | |||
From = "From" ":" mailbox | From = "From" ":" mailbox | |||
An example is: | An example is: | |||
From: webmaster@w3.org | From: webmaster@w3.org | |||
This header field MAY be used for logging purposes and as a means for | This header field MAY be used for logging purposes and as a means for | |||
identifying the source of invalid or unwanted requests. It SHOULD | identifying the source of invalid or unwanted requests. It SHOULD | |||
NOT be used as an insecure form of access protection. The | NOT be used as an insecure form of access protection. The | |||
skipping to change at page 136, line 4 | skipping to change at page 141, line 8 | |||
The Host request-header field specifies the Internet host and port | The Host request-header field specifies the Internet host and port | |||
number of the resource being requested, as obtained from the original | number of the resource being requested, as obtained from the original | |||
URI given by the user or referring resource (generally an HTTP URL, | URI given by the user or referring resource (generally an HTTP URL, | |||
as described in Section 3.2.2). The Host field value MUST represent | as described in Section 3.2.2). The Host field value MUST represent | |||
the naming authority of the origin server or gateway given by the | the naming authority of the origin server or gateway given by the | |||
original URL. This allows the origin server or gateway to | original URL. This allows the origin server or gateway to | |||
differentiate between internally-ambiguous URLs, such as the root "/" | differentiate between internally-ambiguous URLs, such as the root "/" | |||
URL of a server for multiple host names on a single IP address. | URL of a server for multiple host names on a single IP address. | |||
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | |||
A "host" without any trailing port information implies the default | A "host" without any trailing port information implies the default | |||
port for the service requested (e.g., "80" for an HTTP URL). For | port for the service requested (e.g., "80" for an HTTP URL). For | |||
example, a request on the origin server for | example, a request on the origin server for | |||
<http://www.w3.org/pub/WWW/> would properly include: | <http://www.example.org/pub/WWW/> would properly include: | |||
GET /pub/WWW/ HTTP/1.1 | GET /pub/WWW/ HTTP/1.1 | |||
Host: www.w3.org | Host: www.example.org | |||
A client MUST include a Host header field in all HTTP/1.1 request | A client MUST include a Host header field in all HTTP/1.1 request | |||
messages . If the requested URI does not include an Internet host | messages . If the requested URI does not include an Internet host | |||
name for the service being requested, then the Host header field MUST | name for the service being requested, then the Host header field MUST | |||
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | |||
request message it forwards does contain an appropriate Host header | request message it forwards does contain an appropriate Host header | |||
field that identifies the service being requested by the proxy. All | field that identifies the service being requested by the proxy. All | |||
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | |||
status code to any HTTP/1.1 request message which lacks a Host header | status code to any HTTP/1.1 request message which lacks a Host header | |||
field. | field. | |||
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 142, line 29 | skipping to change at page 147, line 32 | |||
14.30. Location | 14.30. Location | |||
The Location response-header field is used to redirect the recipient | The Location response-header field is used to redirect the recipient | |||
to a location other than the Request-URI for completion of the | to a location other than the Request-URI for completion of the | |||
request or identification of a new resource. For 201 (Created) | request or identification of a new resource. For 201 (Created) | |||
responses, the Location is that of the new resource which was created | responses, the Location is that of the new resource which was created | |||
by the request. For 3xx responses, the location SHOULD indicate the | by the request. For 3xx responses, the location SHOULD indicate the | |||
server's preferred URI for automatic redirection to the resource. | server's preferred URI for automatic redirection to the resource. | |||
The field value consists of a single absolute URI. | The field value consists of a single absolute URI. | |||
Location = "Location" ":" absoluteURI | Location = "Location" ":" absoluteURI [ "#" fragment ] | |||
An example is: | An example is: | |||
Location: http://www.w3.org/pub/WWW/People.html | Location: http://www.example.org/pub/WWW/People.html | |||
Note: The Content-Location header field (Section 14.14) differs | Note: The Content-Location header field (Section 14.14) differs | |||
from Location in that the Content-Location identifies the original | from Location in that the Content-Location identifies the original | |||
location of the entity enclosed in the request. It is therefore | location of the entity enclosed in the request. It is therefore | |||
possible for a response to contain header fields for both Location | possible for a response to contain header fields for both Location | |||
and Content-Location. Also see Section 13.10 for cache | and Content-Location. Also see Section 13.10 for cache | |||
requirements of some methods. | requirements of some methods. | |||
There are circumstances in which a fragment identifier in a Location | ||||
URL would not be appropriate: | ||||
o With a 201 Created response, because in this usage the Location | ||||
header specifies the URL for the entire created resource. | ||||
o With a 300 Multiple Choices, since the choice decision is intended | ||||
to be made on resource characteristics and not fragment | ||||
characteristics. | ||||
o With 305 Use Proxy. | ||||
14.31. Max-Forwards | 14.31. Max-Forwards | |||
The Max-Forwards request-header field provides a mechanism with the | The Max-Forwards request-header field provides a mechanism with the | |||
TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the | TRACE (Section 9.8) and OPTIONS (Section 9.2) methods to limit the | |||
number of proxies or gateways that can forward the request to the | number of proxies or gateways that can forward the request to the | |||
next inbound server. This can be useful when the client is | next inbound server. This can be useful when the client is | |||
attempting to trace a request chain which appears to be failing or | attempting to trace a request chain which appears to be failing or | |||
looping in mid-chain. | looping in mid-chain. | |||
Max-Forwards = "Max-Forwards" ":" 1*DIGIT | Max-Forwards = "Max-Forwards" ":" 1*DIGIT | |||
skipping to change at page 144, line 16 | skipping to change at page 149, line 33 | |||
14.33. Proxy-Authenticate | 14.33. Proxy-Authenticate | |||
The Proxy-Authenticate response-header field MUST be included as part | The Proxy-Authenticate response-header field MUST be included as part | |||
of a 407 (Proxy Authentication Required) response. The field value | of a 407 (Proxy Authentication Required) response. The field value | |||
consists of a challenge that indicates the authentication scheme and | consists of a challenge that indicates the authentication scheme and | |||
parameters applicable to the proxy for this Request-URI. | parameters applicable to the proxy for this Request-URI. | |||
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge | Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [43]. Unlike | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
WWW-Authenticate, the Proxy-Authenticate header field applies only to | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies | |||
the current connection and SHOULD NOT be passed on to downstream | only to the current connection and SHOULD NOT be passed on to | |||
clients. However, an intermediate proxy might need to obtain its own | downstream clients. However, an intermediate proxy might need to | |||
credentials by requesting them from the downstream client, which in | obtain its own credentials by requesting them from the downstream | |||
some circumstances will appear as if the proxy is forwarding the | client, which in some circumstances will appear as if the proxy is | |||
Proxy-Authenticate header field. | forwarding the Proxy-Authenticate header field. | |||
14.34. Proxy-Authorization | 14.34. Proxy-Authorization | |||
The Proxy-Authorization request-header field allows the client to | The Proxy-Authorization request-header field allows the client to | |||
identify itself (or its user) to a proxy which requires | identify itself (or its user) to a proxy which requires | |||
authentication. The Proxy-Authorization field value consists of | authentication. The Proxy-Authorization field value consists of | |||
credentials containing the authentication information of the user | credentials containing the authentication information of the user | |||
agent for the proxy and/or realm of the resource being requested. | agent for the proxy and/or realm of the resource being requested. | |||
Proxy-Authorization = "Proxy-Authorization" ":" credentials | Proxy-Authorization = "Proxy-Authorization" ":" credentials | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [43]. Unlike | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
Authorization, the Proxy-Authorization header field applies only to | Unlike Authorization, the Proxy-Authorization header field applies | |||
the next outbound proxy that demanded authentication using the Proxy- | only to the next outbound proxy that demanded authentication using | |||
Authenticate field. When multiple proxies are used in a chain, the | the Proxy-Authenticate field. When multiple proxies are used in a | |||
Proxy-Authorization header field is consumed by the first outbound | chain, the Proxy-Authorization header field is consumed by the first | |||
proxy that was expecting to receive credentials. A proxy MAY relay | outbound proxy that was expecting to receive credentials. A proxy | |||
the credentials from the client request to the next proxy if that is | MAY relay the credentials from the client request to the next proxy | |||
the mechanism by which the proxies cooperatively authenticate a given | if that is the mechanism by which the proxies cooperatively | |||
request. | authenticate a given request. | |||
14.35. Range | 14.35. Range | |||
14.35.1. Byte Ranges | 14.35.1. Byte Ranges | |||
Since all HTTP entities are represented in HTTP messages as sequences | Since all HTTP entities are represented in HTTP messages as sequences | |||
of bytes, the concept of a byte range is meaningful for any HTTP | of bytes, the concept of a byte range is meaningful for any HTTP | |||
entity. (However, not all clients and servers need to support byte- | entity. (However, not all clients and servers need to support byte- | |||
range operations.) | range operations.) | |||
skipping to change at page 147, line 37 | skipping to change at page 153, line 5 | |||
server to generate lists of back-links to resources for interest, | server to generate lists of back-links to resources for interest, | |||
logging, optimized caching, etc. It also allows obsolete or mistyped | logging, optimized caching, etc. It also allows obsolete or mistyped | |||
links to be traced for maintenance. The Referer field MUST NOT be | links to be traced for maintenance. The Referer field MUST NOT be | |||
sent if the Request-URI was obtained from a source that does not have | sent if the Request-URI was obtained from a source that does not have | |||
its own URI, such as input from the user keyboard. | its own URI, such as input from the user keyboard. | |||
Referer = "Referer" ":" ( absoluteURI | relativeURI ) | Referer = "Referer" ":" ( absoluteURI | relativeURI ) | |||
Example: | Example: | |||
Referer: http://www.w3.org/hypertext/DataSources/Overview.html | Referer: http://www.example.org/hypertext/Overview.html | |||
If the field value is a relative URI, it SHOULD be interpreted | If the field value is a relative URI, it SHOULD be interpreted | |||
relative to the Request-URI. The URI MUST NOT include a fragment. | relative to the Request-URI. The URI MUST NOT include a fragment. | |||
See Section 15.1.3 for security considerations. | See Section 15.1.3 for security considerations. | |||
14.37. Retry-After | 14.37. Retry-After | |||
The Retry-After response-header field can be used with a 503 (Service | The Retry-After response-header field can be used with a 503 (Service | |||
Unavailable) response to indicate how long the service is expected to | Unavailable) response to indicate how long the service is expected to | |||
be unavailable to the requesting client. This field MAY also be used | be unavailable to the requesting client. This field MAY also be used | |||
skipping to change at page 148, line 31 | skipping to change at page 153, line 47 | |||
application. | application. | |||
Server = "Server" ":" 1*( product | comment ) | Server = "Server" ":" 1*( product | comment ) | |||
Example: | Example: | |||
Server: CERN/3.0 libwww/2.17 | Server: CERN/3.0 libwww/2.17 | |||
If the response is being forwarded through a proxy, the proxy | If the response is being forwarded through a proxy, the proxy | |||
application MUST NOT modify the Server response-header. Instead, it | application MUST NOT modify the Server response-header. Instead, it | |||
SHOULD include a Via field (as described in Section 14.45). | MUST include a Via field (as described in Section 14.45). | |||
Note: Revealing the specific software version of the server might | Note: Revealing the specific software version of the server might | |||
allow the server machine to become more vulnerable to attacks | allow the server machine to become more vulnerable to attacks | |||
against software that is known to contain security holes. Server | against software that is known to contain security holes. Server | |||
implementors are encouraged to make this field a configurable | implementors are encouraged to make this field a configurable | |||
option. | option. | |||
14.39. TE | 14.39. TE | |||
The TE request-header field indicates what extension transfer-codings | The TE request-header field indicates what extension transfer-codings | |||
skipping to change at page 153, line 23 | skipping to change at page 158, line 37 | |||
client), play a role in the selection of the response representation. | client), play a role in the selection of the response representation. | |||
The "*" value MUST NOT be generated by a proxy server; it may only be | The "*" value MUST NOT be generated by a proxy server; it may only be | |||
generated by an origin server. | generated by an origin server. | |||
14.45. Via | 14.45. Via | |||
The Via general-header field MUST be used by gateways and proxies to | The Via general-header field MUST be used by gateways and proxies to | |||
indicate the intermediate protocols and recipients between the user | indicate the intermediate protocols and recipients between the user | |||
agent and the server on requests, and between the origin server and | agent and the server on requests, and between the origin server and | |||
the client on responses. It is analogous to the "Received" field of | the client on responses. It is analogous to the "Received" field of | |||
RFC 822 [9] and is intended to be used for tracking message forwards, | [RFC822] and is intended to be used for tracking message forwards, | |||
avoiding request loops, and identifying the protocol capabilities of | avoiding request loops, and identifying the protocol capabilities of | |||
all senders along the request/response chain. | all senders along the request/response chain. | |||
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
received-by = ( host [ ":" port ] ) | pseudonym | received-by = ( host [ ":" port ] ) | pseudonym | |||
pseudonym = token | pseudonym = token | |||
skipping to change at page 155, line 28 | skipping to change at page 160, line 42 | |||
The warn-text SHOULD be in a natural language and character set that | The warn-text SHOULD be in a natural language and character set that | |||
is most likely to be intelligible to the human user receiving the | is most likely to be intelligible to the human user receiving the | |||
response. This decision MAY be based on any available knowledge, | response. This decision MAY be based on any available knowledge, | |||
such as the location of the cache or user, the Accept-Language field | such as the location of the cache or user, the Accept-Language field | |||
in a request, the Content-Language field in a response, etc. The | in a request, the Content-Language field in a response, etc. The | |||
default language is English and the default character set is ISO- | default language is English and the default character set is ISO- | |||
8859-1. | 8859-1. | |||
If a character set other than ISO-8859-1 is used, it MUST be encoded | If a character set other than ISO-8859-1 is used, it MUST be encoded | |||
in the warn-text using the method described in RFC 2047 [14]. | in the warn-text using the method described in [RFC2047]. | |||
Warning headers can in general be applied to any message, however | Warning headers can in general be applied to any message, however | |||
some specific warn-codes are specific to caches and can only be | some specific warn-codes are specific to caches and can only be | |||
applied to response messages. New Warning headers SHOULD be added | applied to response messages. New Warning headers SHOULD be added | |||
after any existing Warning headers. A cache MUST NOT delete any | after any existing Warning headers. A cache MUST NOT delete any | |||
Warning header that it received with a message. However, if a cache | Warning header that it received with a message. However, if a cache | |||
successfully validates a cache entry, it SHOULD remove any Warning | successfully validates a cache entry, it SHOULD remove any Warning | |||
headers previously attached to that entry except as specified for | headers previously attached to that entry except as specified for | |||
specific Warning codes. It MUST then add any Warning headers | specific Warning codes. It MUST then add any Warning headers | |||
received in the validating response. In other words, Warning headers | received in the validating response. In other words, Warning headers | |||
skipping to change at page 157, line 33 | skipping to change at page 162, line 46 | |||
14.47. WWW-Authenticate | 14.47. WWW-Authenticate | |||
The WWW-Authenticate response-header field MUST be included in 401 | The WWW-Authenticate response-header field MUST be included in 401 | |||
(Unauthorized) response messages. The field value consists of at | (Unauthorized) response messages. The field value consists of at | |||
least one challenge that indicates the authentication scheme(s) and | least one challenge that indicates the authentication scheme(s) and | |||
parameters applicable to the Request-URI. | parameters applicable to the Request-URI. | |||
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge | |||
The HTTP access authentication process is described in "HTTP | The HTTP access authentication process is described in "HTTP | |||
Authentication: Basic and Digest Access Authentication" [43]. User | Authentication: Basic and Digest Access Authentication" [RFC2617]. | |||
agents are advised to take special care in parsing the WWW- | User agents are advised to take special care in parsing the WWW- | |||
Authenticate field value as it might contain more than one challenge, | Authenticate field value as it might contain more than one challenge, | |||
or if more than one WWW-Authenticate header field is provided, the | or if more than one WWW-Authenticate header field is provided, the | |||
contents of a challenge itself can contain a comma-separated list of | contents of a challenge itself can contain a comma-separated list of | |||
authentication parameters. | authentication parameters. | |||
15. Security Considerations | 15. Security Considerations | |||
This section is meant to inform application developers, information | This section is meant to inform application developers, information | |||
providers, and users of the security limitations in HTTP/1.1 as | providers, and users of the security limitations in HTTP/1.1 as | |||
described by this document. The discussion does not include | described by this document. The discussion does not include | |||
skipping to change at page 161, line 33 | skipping to change at page 166, line 33 | |||
to be cached, however, only when the TTL (Time To Live) information | to be cached, however, only when the TTL (Time To Live) information | |||
reported by the name server makes it likely that the cached | reported by the name server makes it likely that the cached | |||
information will remain useful. | information will remain useful. | |||
If HTTP clients cache the results of host name lookups in order to | If HTTP clients cache the results of host name lookups in order to | |||
achieve a performance improvement, they MUST observe the TTL | achieve a performance improvement, they MUST observe the TTL | |||
information reported by DNS. | information reported by DNS. | |||
If HTTP clients do not observe this rule, they could be spoofed when | If HTTP clients do not observe this rule, they could be spoofed when | |||
a previously-accessed server's IP address changes. As network | a previously-accessed server's IP address changes. As network | |||
renumbering is expected to become increasingly common [24], the | renumbering is expected to become increasingly common [RFC1900], the | |||
possibility of this form of attack will grow. Observing this | possibility of this form of attack will grow. Observing this | |||
requirement thus reduces this potential security vulnerability. | requirement thus reduces this potential security vulnerability. | |||
This requirement also improves the load-balancing behavior of clients | This requirement also improves the load-balancing behavior of clients | |||
for replicated servers using the same DNS name and reduces the | for replicated servers using the same DNS name and reduces the | |||
likelihood of a user's experiencing failure in accessing sites which | likelihood of a user's experiencing failure in accessing sites which | |||
use that strategy. | use that strategy. | |||
15.4. Location Headers and Spoofing | 15.4. Location Headers and Spoofing | |||
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 | [RFC1806], from which the often implemented Content-Disposition (see | |||
(see Appendix A.5.1) header in HTTP is derived, has a number of very | Appendix E.1) header in HTTP is derived, has a number of very serious | |||
serious security considerations. Content-Disposition is not part of | security considerations. Content-Disposition is not part of the HTTP | |||
the HTTP standard, but since it is widely implemented, we are | standard, but since it is widely implemented, we are documenting its | |||
documenting its use and risks for implementors. See RFC 2183 [49] | use and risks for implementors. See [RFC2183] (which updates RFC | |||
(which updates RFC 1806) for details. | 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 | |||
is a significant defect that requires further extensions to HTTP. | is a significant defect that requires further extensions to HTTP. | |||
Circumstances under which credential caching can interfere with the | Circumstances under which credential caching can interfere with the | |||
application's security model include but are not limited to: | application's security model include but are not limited to: | |||
o Clients which have been idle for an extended period following | o Clients which have been idle for an extended period following | |||
which the server might wish to cause the client to reprompt the | which the server might wish to cause the client to reprompt the | |||
user for credentials. | user for credentials. | |||
o Applications which include a session termination indication (such | o Applications which include a session termination indication (such | |||
skipping to change at page 164, line 7 | skipping to change at page 169, 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 [RFC822]. Similarly, it | |||
it reuses many of the definitions provided by Nathaniel Borenstein | reuses many of the definitions provided by Nathaniel Borenstein and | |||
and Ned Freed for MIME [7]. We hope that their inclusion in this | Ned Freed for MIME [RFC2045]. 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 | |||
that community which has been most responsible for the success of | that community which has been most responsible for the success of | |||
HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert | |||
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois | |||
Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob | |||
McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc | |||
VanHeyningen deserve special recognition for their efforts in | VanHeyningen deserve special recognition for their efforts in | |||
defining early aspects of the protocol. | defining early aspects of the protocol. | |||
This document has benefited greatly from the comments of all those | This document has benefited greatly from the comments of all those | |||
participating in the HTTP-WG. In addition to those already | participating in the HTTP-WG. In addition to those already | |||
mentioned, the following individuals have contributed to this | mentioned, the following individuals have contributed to this | |||
specification: | specification: | |||
Gary Adams Ross Patterson | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, | |||
Harald Tveit Alvestrand Albert Lunde | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, | |||
Keith Ball John C. Mallery | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc | |||
Brian Behlendorf Jean-Philippe Martin-Flatin | Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel | |||
Paul Burchard Mitra | Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, | |||
Maurizio Codogno David Morris | David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert | |||
Mike Cowlishaw Gavin Nicol | Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David | |||
Roman Czyborra Bill Perry | Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott | |||
Michael A. Dolan Jeffrey Perry | Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich | |||
David J. Fiander Scott Powers | Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, | |||
Alan Freier Owen Rees | Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) | |||
Marc Hedlund Luigi Rizzo | Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. | |||
Greg Herlihy David Robinson | ||||
Koen Holtman Marc Salomon | ||||
Alex Hopmann Rich Salz | ||||
Bob Jernigan Allan M. Schiffman | ||||
Shel Kaphan Jim Seidman | ||||
Rohit Khare Chuck Shotton | ||||
John Klensin Eric W. Sink | ||||
Martijn Koster Simon E. Spero | ||||
Alexei Kosut Richard N. Taylor | ||||
David M. Kristol Robert S. Thau | ||||
Daniel LaLiberte Bill (BearHeart) Weinman | ||||
Ben Laurie Francois Yergeau | ||||
Paul J. Leach Mary Ellen Zurko | ||||
Daniel DuBois Josh Cohen | ||||
Much of the content and presentation of the caching design is due to | Much of the content and presentation of the caching design is due to | |||
suggestions and comments from individuals including: Shel Kaphan, | suggestions and comments from individuals including: Shel Kaphan, | |||
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | |||
Most of the specification of ranges is based on work originally done | Most of the specification of ranges is based on work originally done | |||
by Ari Luotonen and John Franks, with additional input from Steve | by Ari Luotonen and John Franks, with additional input from Steve | |||
Zilles. | Zilles. | |||
Thanks to the "cave men" of Palo Alto. You know who you are. | Thanks to the "cave men" of Palo Alto. You know who you are. | |||
Jim Gettys (the current editor of this document) wishes particularly | Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy | |||
to thank Roy Fielding, the previous editor of this document, along | Fielding, the editor of [RFC2068], along with John Klensin, Jeff | |||
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh | |||
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their | |||
Larry Masinter for their help. And thanks go particularly to Jeff | help. And thanks go particularly to Jeff Mogul and Scott Lawrence | |||
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. | 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. | |||
17. References | 16.2. (This Document) | |||
[1] Alvestrand, H., "Tags for the Identification of Languages", | ||||
RFC 1766, March 1995. | ||||
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | This document has benefited greatly from the comments of all those | |||
D., and B. Alberti, "The Internet Gopher Protocol (a | participating in the HTTP-WG. In particular, we thank Scott Lawrence | |||
distributed document search and retrieval protocol)", RFC 1436, | for maintaining the RFC2616 Errata list, and Mark Baker, Roy | |||
March 1993. | Fielding, Bjoern Hoehrmann, Brian Kell, Jamie Lokier, Larry Masinter, | |||
Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Alex | ||||
Rousskov, Travis Snoozy and Dan Winship for contributions to it. | ||||
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | 17. References | |||
Unifying Syntax for the Expression of Names and Addresses of | ||||
Objects on the Network as used in the World-Wide Web", | ||||
RFC 1630, June 1994. | ||||
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | 17.1. References (to be classified) | |||
Resource Locators (URL)", RFC 1738, December 1994. | ||||
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - | [ISO-8859-1] | |||
2.0", RFC 1866, November 1995. | International Organization for Standardization, | |||
"Information technology - 8-bit single byte coded graphic | ||||
- character sets", 1987-1990. | ||||
[6] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin | |||
alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet | ||||
No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, | ||||
ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO- | ||||
8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, | ||||
1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | ||||
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | ||||
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web | |||
Extensions (MIME) Part One: Format of Internet Message Bodies", | proxy servers", Work in Progress. | |||
RFC 2045, November 1996. | ||||
[8] Braden, R., "Requirements for Internet Hosts - Application and | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | |||
Support", STD 3, RFC 1123, October 1989. | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | |||
and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , | ||||
Sep 1997. | ||||
[9] Crocker, D., "Standard for the format of ARPA Internet text | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | |||
messages", STD 11, RFC 822, August 1982. | Computer Networks and ISDN Systems v. 28, pp. 25-35, | |||
Dec 1995. | ||||
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, | Slightly revised version of paper in Proc. 2nd | |||
R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol | International WWW Conference '94: Mosaic and the Web, Oct. | |||
Prototype Functional Specification (v1.5)", Thinking Machines | 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ | |||
Corporation , April 1990. | IT94/Proceedings/DDay/mogul/HTTPLatency.html>. | |||
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, | [RFC1036] Horton, M. and R. Adams, "Standard for interchange of | |||
June 1995. | USENET messages", RFC 1036, December 1987. | |||
[12] Horton, M. and R. Adams, "Standard for interchange of USENET | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | |||
messages", RFC 1036, December 1987. | and Support", STD 3, RFC 1123, October 1989. | |||
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", | [RFC1305] Mills, D., "Network Time Protocol (Version 3) | |||
RFC 977, February 1986. | Specification, Implementation", RFC 1305, March 1992. | |||
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | |||
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | Torrey, D., and B. Alberti, "The Internet Gopher Protocol | |||
November 1996. | (a distributed document search and retrieval protocol)", | |||
RFC 1436, March 1993. | ||||
[15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", | [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, | |||
RFC 1867, November 1995. | March 1994. | |||
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | |||
August 1982. | Unifying Syntax for the Expression of Names and Addresses | |||
of Objects on the Network as used in the World-Wide Web", | ||||
RFC 1630, June 1994. | ||||
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, | [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for | |||
November 1996. | Uniform Resource Names", RFC 1737, December 1994. | |||
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | |||
RFC 959, October 1985. | Resource Locators (URL)", RFC 1738, December 1994. | |||
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, | [RFC1766] Alvestrand, H., "Tags for the Identification of | |||
RFC 1700, October 1994. | Languages", RFC 1766, March 1995. | |||
[20] Masinter, L. and K. Sollins, "Functional Requirements for | [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation | |||
Uniform Resource Names", RFC 1737, December 1994. | Information in Internet Messages: The Content-Disposition | |||
Header", RFC 1806, June 1995. | ||||
[21] American National Standards Institute, "Coded Character Set -- | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", | |||
7-bit American Standard Code for Information Interchange", | RFC 1808, June 1995. | |||
ANSI X3.4, 1986. | ||||
[22] International Organization for Standardization, "Information | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | |||
technology - 8-bit single byte coded graphic - character sets", | RFC 1864, October 1995. | |||
1987-1990. | ||||
Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin | [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup | |||
alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. | Language - 2.0", RFC 1866, November 1995. | |||
3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, | ||||
1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part | ||||
6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/ | ||||
Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew | ||||
alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO- | ||||
8859-9, 1990. | ||||
[23] Myers, J. and M. Rose, "The Content-MD5 Header Field", | [RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in | |||
RFC 1864, October 1995. | HTML", RFC 1867, November 1995. | |||
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | |||
RFC 1900, February 1996. | RFC 1900, February 1996. | |||
[25] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Randers-Pehrson, "GZIP file format specification version 4.3", | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
RFC 1952, May 1996. | ||||
[26] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | |||
Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995. | Specification version 3.3", RFC 1950, May 1996. | |||
Slightly revised version of paper in Proc. 2nd International | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | |||
WWW Conference '94: Mosaic and the Web, Oct. 1994, which is | version 1.3", RFC 1951, May 1996. | |||
available at <http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/ | ||||
DDay/mogul/HTTPLatency.html>. | ||||
[27] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of HTTP | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | |||
Performance", ISI Research Report ISI/RR-98-463 (original | Randers-Pehrson, "GZIP file format specification version | |||
report dated Aug.1996), Aug 1998, | 4.3", RFC 1952, May 1996. | |||
<http://www.isi.edu/touch/pubs/http-perf96/>. | ||||
[28] Mills, D., "Network Time Protocol (Version 3) Specification, | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
Implementation", RFC 1305, March 1992. | 3", BCP 9, RFC 2026, October 1996. | |||
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
version 1.3", RFC 1951, May 1996. | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, November 1996. | ||||
[30] Spero, S., "Analysis of HTTP Performance Problems", | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
<http://sunsite.unc.edu/mdma-release/http-prob.html>. | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
November 1996. | ||||
[31] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |||
Specification version 3.3", RFC 1950, May 1996. | Part Three: Message Header Extensions for Non-ASCII Text", | |||
RFC 2047, November 1996. | ||||
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : | Extensions (MIME) Part Five: Conformance Criteria and | |||
Digest Access Authentication", RFC 2069, January 1997. | Examples", RFC 2049, November 1996. | |||
[33] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | |||
RFC 2068, January 1997. | RFC 2068, January 1997. | |||
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |||
Levels", BCP 14, RFC 2119, March 1997. | Luotonen, A., Sink, E., and L. Stewart, "An Extension to | |||
HTTP : Digest Access Authentication", RFC 2069, | ||||
January 1997. | ||||
[35] Troost, R. and S. Dorner, "Communicating Presentation | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, | |||
Information in Internet Messages: The Content-Disposition | February 1997. | |||
Header", RFC 1806, June 1995. | ||||
[36] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and | [RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | |||
Interpretation of HTTP Version Numbers", RFC 2145, May 1997. | Aggregate Documents, such as HTML (MHTML)", RFC 2110, | |||
March 1997. | ||||
[37] Palme, J., "Common Internet Message Headers", RFC 2076, | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
February 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[38] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | |||
RFC 2279, January 1998. | and Interpretation of HTTP Version Numbers", RFC 2145, | |||
May 1997. | ||||
[39] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating | |||
Lilley, "Network Performance Effects of HTTP/1.1, CSS1, and | Presentation Information in Internet Messages: The | |||
PNG", Proceedings of ACM SIGCOMM '97, Cannes France , Sep 1997. | Content-Disposition Header Field", RFC 2183, August 1997. | |||
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
Extensions (MIME) Part Two: Media Types", RFC 2046, | Languages", BCP 18, RFC 2277, January 1998. | |||
November 1996. | ||||
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", | [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO | |||
BCP 18, RFC 2277, January 1998. | 10646", RFC 2279, January 1998. | |||
[42] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |||
(HTCPCP/1.0)", RFC 2324, April 1998. | ||||
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | ||||
Resource Identifiers (URI): Generic Syntax", RFC 2396, | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |||
August 1998. | August 1998. | |||
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |||
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: | Leach, P., Luotonen, A., and L. Stewart, "HTTP | |||
Basic and Digest Access Authentication", RFC 2617, June 1999. | Authentication: Basic and Digest Access Authentication", | |||
RFC 2617, June 1999. | ||||
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, | |||
servers", Work in Progress. | RFC 821, August 1982. | |||
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | [RFC822] Crocker, D., "Standard for the format of ARPA Internet | |||
Aggregate Documents, such as HTML (MHTML)", RFC 2110, | text messages", STD 11, RFC 822, August 1982. | |||
March 1997. | ||||
[46] Bradner, S., "The Internet Standards Process -- Revision 3", | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | |||
BCP 9, RFC 2026, October 1996. | STD 9, RFC 959, October 1985. | |||
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol | [Spero] Spero, S., "Analysis of HTTP Performance Problems", | |||
(HTCPCP/1.0)", RFC 2324, April 1998. | <http://sunsite.unc.edu/mdma-release/http-prob.html>. | |||
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | |||
Extensions (MIME) Part Five: Conformance Criteria and | HTTP Performance", ISI Research Report ISI/RR-98-463 | |||
Examples", RFC 2049, November 1996. | (original report dated Aug.1996), Aug 1998, | |||
<http://www.isi.edu/touch/pubs/http-perf96/>. | ||||
[49] Troost, R., Dorner, S., and K. Moore, "Communicating | [USASCII] American National Standards Institute, "Coded Character | |||
Presentation Information in Internet Messages: The Content- | Set -- 7-bit American Standard Code for Information | |||
Disposition Header Field", RFC 2183, August 1997. | Interchange", ANSI X3.4, 1986. | |||
Appendix A. Appendices | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., | |||
Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface | ||||
Protocol Prototype Functional Specification (v1.5)", | ||||
Thinking Machines Corporation , April 1990. | ||||
A.1. Internet Media Type message/http and application/http | 17.2. Informative References | |||
[RFC2616] 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. | ||||
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | ||||
RFC 3977, October 2006. | ||||
URIs | ||||
[1] <mailto:ietf-http-wg@w3.org> | ||||
[2] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | ||||
[3] <http://tools.ietf.org/html/draft-lafon-rfc2616bis-01> | ||||
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 [RFC1590]. | |||
Media Type name: message | Media Type name: message | |||
Media subtype name: http | Media subtype name: http | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed message (e.g., | version: The HTTP-Version number of the enclosed message (e.g., | |||
skipping to change at page 171, line 15 | skipping to change at page 179, 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 28 | skipping to change at page 180, line 8 | |||
Content-range: bytes 7000-7999/8000 | Content-range: bytes 7000-7999/8000 | |||
...the second range | ...the second range | |||
--THIS_STRING_SEPARATES-- | --THIS_STRING_SEPARATES-- | |||
Notes: | Notes: | |||
1. Additional CRLFs may precede the first boundary string in the | 1. Additional CRLFs may precede the first boundary string in the | |||
entity. | entity. | |||
2. Although RFC 2046 [40] permits the boundary string to be quoted, | 2. Although [RFC2046] permits the boundary string to be quoted, some | |||
some existing implementations handle a quoted boundary string | 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 | |||
only a single SP is required. | only a single SP is required. | |||
The line terminator for message-header fields is the sequence CRLF. | The line terminator for message-header fields is the sequence CRLF. | |||
However, we recommend that applications, when parsing such headers, | However, we recommend that applications, when parsing such headers, | |||
recognize a single LF as a line terminator and ignore the leading CR. | recognize a single LF as a line terminator and ignore the leading CR. | |||
The character set of an entity-body SHOULD be labeled as the lowest | The character set of an entity-body SHOULD be labeled as the lowest | |||
common denominator of the character codes used within that body, with | common denominator of the character codes used within that body, with | |||
the exception that not labeling the entity is preferred over labeling | the exception that not labeling the entity is preferred over labeling | |||
the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 | the entity with the labels US-ASCII or ISO-8859-1. See Section 3.7.1 | |||
and 3.4.1. | and 3.4.1. | |||
Additional rules for requirements on parsing and encoding of dates | Additional rules for requirements on parsing and encoding of dates | |||
and other potential problems with date encodings include: | and other potential problems with date encodings include: | |||
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | |||
which appears to be more than 50 years in the future is in fact in | which appears to be more than 50 years in the future is in fact in | |||
the past (this helps solve the "year 2000" problem). | the past (this helps solve the "year 2000" problem). | |||
o An HTTP/1.1 implementation MAY internally represent a parsed | o An HTTP/1.1 implementation MAY internally represent a parsed | |||
skipping to change at page 173, line 32 | skipping to change at page 182, 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 | |||
822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | ([RFC822]) and the Multipurpose Internet Mail Extensions (MIME | |||
allow entities to be transmitted in an open variety of | [RFC2045]) to 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 [RFC2045]). | |||
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 | [RFC2045] 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 [RFC2049]. 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. | |||
Where it is possible, a proxy or gateway from HTTP to a strict MIME | Where it is possible, a proxy or gateway from HTTP to a strict MIME | |||
environment SHOULD translate all line breaks within the text media | environment SHOULD translate all line breaks within the text media | |||
types described in Section 3.7.1 of this document to the RFC 2049 | types described in Section 3.7.1 of this document to the RFC 2049 | |||
skipping to change at page 174, line 47 | skipping to change at page 183, 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 CTE encoding prior to delivering the response message | |||
encoding prior to delivering the response message to an HTTP client. | to an HTTP client. | |||
Proxies and gateways from HTTP to MIME-compliant protocols are | Proxies and gateways from HTTP to MIME-compliant protocols are | |||
responsible for ensuring that the message is in the correct format | responsible for ensuring that the message is in the correct format | |||
and encoding for safe transport on that protocol, where "safe | and encoding for safe transport on that protocol, where "safe | |||
transport" is defined by the limitations of the protocol being used. | transport" is defined by the limitations of the protocol being used. | |||
Such a proxy or gateway SHOULD label the data with an appropriate | Such a proxy or gateway SHOULD label the data with an appropriate | |||
Content-Transfer-Encoding if doing so will improve the likelihood of | Content-Transfer-Encoding if doing so will improve the likelihood of | |||
safe transport over the destination protocol. | safe transport over the destination protocol. | |||
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 184, 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 [RFC2110] | |||
need to be aware of MIME line length limitations. Since HTTP does | implementations need to be aware of MIME line length limitations. | |||
not have this limitation, HTTP does not fold long lines. MHTML | Since HTTP does not have this limitation, HTTP does not fold long | |||
messages being transported by HTTP follow all conventions of MHTML, | lines. MHTML messages being transported by HTTP follow all | |||
including line length limitations and folding, canonicalization, | conventions of MHTML, including line length limitations and folding, | |||
etc., since HTTP transports all message-bodies as payload (see | canonicalization, etc., since HTTP transports all message-bodies as | |||
Section 3.7.2) and does not interpret the content or any MIME header | payload (see Section 3.7.2) and does not interpret the content or any | |||
lines that might be contained therein. | MIME header 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 [RFC2076]). | |||
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 [RFC1806]. | |||
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 | |||
filename-parm = "filename" "=" quoted-string | filename-parm = "filename" "=" quoted-string | |||
disp-extension-token = token | disp-extension-token = token | |||
disp-extension-parm = token "=" ( token | quoted-string ) | disp-extension-parm = token "=" ( token | quoted-string ) | |||
An example is | An example is | |||
skipping to change at page 177, line 29 | skipping to change at page 186, 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 186, line 33 | |||
o recognize the format of the Status-Line for HTTP/1.0 and 1.1 | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 | |||
responses; | responses; | |||
o understand any valid response in the format of HTTP/0.9, 1.0, or | o understand any valid response in the format of HTTP/0.9, 1.0, or | |||
1.1. | 1.1. | |||
For most implementations of HTTP/1.0, each connection is established | For most implementations of HTTP/1.0, each connection is established | |||
by the client prior to the request and closed by the server after | by the client prior to the request and closed by the server after | |||
sending the response. Some implementations implement the Keep-Alive | sending the response. Some implementations implement the Keep-Alive | |||
version of persistent connections described in Section 19.7.1 of RFC | version of persistent connections described in Section 19.7.1 of | |||
2068 [33]. | [RFC2068]. | |||
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 5.1.2) are among the most important changes defined by this | (Section 5.1.2) are among the most important changes defined by this | |||
specification. | specification. | |||
Older HTTP/1.0 clients assumed a one-to-one relationship of IP | Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |||
addresses and servers; there was no other established mechanism for | addresses and servers; there was no other established mechanism for | |||
skipping to change at page 179, line 5 | skipping to change at page 187, 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 30 | skipping to change at page 187, line 51 | |||
However, talking to proxies is the most important use of persistent | However, talking to proxies is the most important use of persistent | |||
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 [RFC2068]. | |||
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 [RFC2119]. | |||
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). | |||
Content-Base was deleted from the specification: it was not | Content-Base was deleted from the specification: it was not | |||
implemented widely, and there is no simple, safe way to introduce it | implemented widely, and there is no simple, safe way to introduce it | |||
without a robust extension mechanism. In addition, it is used in a | without a robust extension mechanism. In addition, it is used in a | |||
similar, but not identical fashion in MHTML [45]. | similar, but not identical fashion in MHTML [RFC2110]. | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. | to straighten out exactly how message lengths are computed. | |||
(Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | |||
A content-coding of "identity" was introduced, to solve problems | A content-coding of "identity" was introduced, to solve problems | |||
discovered in caching. (Section 3.5) | discovered in caching. (Section 3.5) | |||
Quality Values of zero should indicate that "I don't want something" | Quality Values of zero should indicate that "I don't want something" | |||
to allow clients to refuse a representation. (Section 3.9) | to allow clients to refuse a representation. (Section 3.9) | |||
The use and interpretation of HTTP version numbers has been clarified | The use and interpretation of HTTP version numbers has been clarified | |||
by RFC 2145. Require proxies to upgrade requests to highest protocol | by RFC 2145. Require proxies to upgrade requests to highest protocol | |||
skipping to change at page 181, line 24 | skipping to change at page 189, line 47 | |||
5. Require that the origin server MUST NOT wait for the request body | 5. Require that the origin server MUST NOT wait for the request body | |||
before it sends a required 100 (Continue) response. | before it sends a required 100 (Continue) response. | |||
6. Allow, rather than require, a server to omit 100 (Continue) if it | 6. Allow, rather than require, a server to omit 100 (Continue) if it | |||
has already seen some of the request body. | has already seen some of the request body. | |||
7. Allow servers to defend against denial-of-service attacks and | 7. Allow servers to defend against denial-of-service attacks and | |||
broken clients. | broken clients. | |||
This change adds the Expect header and 417 status code. The message | This change adds the Expect header and 417 status code. The message | |||
transmission requirements fixes are in sections 8.2, 10.4.18, | transmission requirements fixes are in Sections 8.2, 10.4.18, | |||
8.1.2.2, 13.11, and 14.20. | 8.1.2.2, 13.11, and 14.20. | |||
Proxies should be able to add Content-Length when appropriate. | Proxies should be able to add Content-Length when appropriate. | |||
(Section 13.5.2) | (Section 13.5.2) | |||
Clean up confusion between 403 and 404 responses. (Section 10.4.4, | Clean up confusion between 403 and 404 responses. (Section 10.4.4, | |||
10.4.5, and 10.4.11) | 10.4.5, and 10.4.11) | |||
Warnings could be cached incorrectly, or not updated appropriately. | Warnings could be cached incorrectly, or not updated appropriately. | |||
(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | |||
also needed to be a general header, as PUT or other methods may have | also needed to be a general header, as PUT or other methods may have | |||
need for it in requests. | need for it in requests. | |||
Transfer-coding had significant problems, particularly with | Transfer-coding had significant problems, particularly with | |||
interactions with chunked encoding. The solution is that transfer- | interactions with chunked encoding. The solution is that transfer- | |||
skipping to change at page 181, line 44 | skipping to change at page 190, line 18 | |||
(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | |||
also needed to be a general header, as PUT or other methods may have | also needed to be a general header, as PUT or other methods may have | |||
need for it in requests. | need for it in requests. | |||
Transfer-coding had significant problems, particularly with | Transfer-coding had significant problems, particularly with | |||
interactions with chunked encoding. The solution is that transfer- | interactions with chunked encoding. The solution is that transfer- | |||
codings become as full fledged as content-codings. This involves | codings become as full fledged as content-codings. This involves | |||
adding an IANA registry for transfer-codings (separate from content | adding an IANA registry for transfer-codings (separate from content | |||
codings), a new header field (TE) and enabling trailer headers in the | codings), a new header field (TE) and enabling trailer headers in the | |||
future. Transfer encoding is a major performance benefit, so it was | future. Transfer encoding is a major performance benefit, so it was | |||
worth fixing [39]. TE also solves another, obscure, downward | worth fixing [Nie1997]. TE also solves another, obscure, downward | |||
interoperability problem that could have occurred due to interactions | interoperability problem that could have occurred due to interactions | |||
between authentication trailers, chunked encoding and HTTP/1.0 | between authentication trailers, chunked encoding and HTTP/1.0 | |||
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 | |||
[33]. | [RFC2068]. | |||
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 [RFC2068]. | |||
Appendix B. Index | F.4. Changes from RFC 2616 | |||
Please see the PostScript version of this RFC for the INDEX. | Clarify that HTTP-Version is case sensitive. (Section 3.1) | |||
Eliminate overlooked reference to "unsafe" characters. | ||||
(Section 3.2.3) | ||||
Clarify contexts that charset is used in. (Section 3.4) | ||||
Remove reference to non-existant identity transfer-coding value | ||||
tokens. (Sections 3.6, 4.4 and D.5) | ||||
Clarification that the chunk length does not include the count of the | ||||
octets in the chunk header and trailer. (Section 3.6.1) | ||||
Fix BNF to add query, as the abs_path production in Section 3 of | ||||
[RFC2396] doesn't define it. (Section 5.1.2) | ||||
Clarify definition of POST. (Section 9.5) | ||||
Clarify that it's not ok to use a weak cache validator in a 206 | ||||
response. (Section 10.2.7) | ||||
Failed to consider that there are many other request methods that are | ||||
safe to automatically redirect, and further that the user agent is | ||||
able to make that determination based on the request method | ||||
semantics. (Sections 10.3.2, 10.3.3 and 10.3.8 ) | ||||
Fix misspelled header and clarify requirements for hop-by-hop headers | ||||
introduced in future specifications. (Section 13.5.1) | ||||
Clarify denial of service attack avoidance requirement. | ||||
(Section 13.10) | ||||
Clarify exactly when close connection options must be sent. | ||||
(Section 14.10) | ||||
Correct syntax of Location header to allow fragment, as referred | ||||
symbol wasn't what was expected, and add some clarifications as to | ||||
when it would not be appropriate. (Section 14.30) | ||||
In the description of the Server header, the Via field was described | ||||
as a SHOULD. The requirement was and is stated correctly in the | ||||
description of the Via header, Section 14.45. (Section 14.38) | ||||
Appendix G. Change Log (to be removed by RFC Editor before publication) | ||||
G.1. Since RFC2616 | ||||
Update Authors. Add Editorial Note and Acknowledgements (containing | ||||
the original RFC2616 authors). Add "Normative References", | ||||
containing just RFC2616 for now. | ||||
G.2. Since draft-lafon-rfc2616bis-00 | ||||
Add and resolve issues "charactersets", "chunk-size", "editor-notes", | ||||
"identity", "ifrange206", "invalidupd", "msg-len-chars", | ||||
"noclose1xx", "post", "saferedirect", "trailer-hop", "unsafe-uri", | ||||
"uriquery", "verscase" and "via-must" as proposed in | ||||
<http://purl.org/NET/http-errata>. Add and resolve issue "rfc2606- | ||||
compliance". | ||||
Add issues "languagetag", "media-reg" and "unneeded_references". Add | ||||
issue "location-fragments" and partly resolve it. | ||||
Reformat HTTP-WG contributors as a plain text paragraph. | ||||
Change [RFC2616] to be an informative reference. Fix RFC2026 | ||||
reference (broken in draft 00). Outdent artwork to more closely | ||||
match RFC2616. (No change tracking for these changes). | ||||
Mark Yves Lafon and Julian Reschke as "Editor" in the front page and | ||||
the Authors section. Re-add all of the authors of RFC2616 for now. | ||||
(No change tracking for these changes). | ||||
G.3. Since draft-lafon-rfc2616bis-01 | ||||
Add issues "fragment-combination" and | ||||
"rfc2048_informative_and_obsolete". | ||||
Resolve issues "location-fragments" (by moving the remaining issue | ||||
into the new issue "fragment-combination") and "media-reg" (by adding | ||||
"rfc2048_informative_and_obsolete" instead). | ||||
Reopen and close issue "rfc2606-compliance" again (other instances | ||||
where found). | ||||
Add and resolve issue "references_style". | ||||
G.4. Since draft-lafon-rfc2616bis-02 | ||||
Add issues "i21-put-side-effects", "i34-updated-reference-for-uris", | ||||
"i50-misc-typos", "i51-http-date-vs-rfc1123-date", "i52-sort-1.3- | ||||
terminology", "i53-allow-is-not-in-13.5.2", "i54-definition-of-1xx- | ||||
warn-codes", "i55-updating-to-rfc4288", "i56-6.1.1-can-be-misread-as- | ||||
a-complete-list", "i57-status-code-and-reason-phrase", "i58-what- | ||||
identifies-an-http-resource", "i59-status-code-registry", "i60- | ||||
13.5.1-and-13.5.2", "i61-redirection-vs-location", "i62-whitespace- | ||||
in-quoted-pair", "i63-header-length-limit-with-encoded-words" and | ||||
"i67-quoting-charsets". | ||||
Add and resolve issues "i45-rfc977-reference", "i46-rfc1700_remove", | ||||
"i47-inconsistency-in-date-format-explanation", "i48-date-reference- | ||||
typo" and "i49-connection-header-text". | ||||
Rename "References" to "References (to be classified)". | ||||
Appendix H. Resolved issues (to be removed by RFC Editor before | ||||
publication) | ||||
Issues that were either rejected or resolved in this version of this | ||||
document. | ||||
H.1. i45-rfc977-reference | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i45> | ||||
julian.reschke@greenbytes.de (2006-10-26): Classify RFC977 (NNTP) as | ||||
informative, and update the reference to RFC3977. | ||||
Resolution (2006-10-26): Done. | ||||
H.2. i46-rfc1700_remove | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i46> | ||||
julian.reschke@greenbytes.de (2006-11-12): RFC1700 ("ASSIGNED | ||||
NUMBERS") has been obsoleted by RFC3232 ("Assigned Numbers: RFC 1700 | ||||
is Replaced by an On-line Database"). | ||||
draft-gettys-http-v11-spec-rev-00 just updates the reference, which I | ||||
think is a bug. | ||||
In fact, RFC2616 refers to RCF1700 | ||||
(1) for the definition of the default TCP port (Section 1.4), | ||||
(2) for a reference to the character set registry (Section 3.4) and | ||||
(3) for a reference to the media type registry (Section 3.7). | ||||
I propose to remove the reference, and to make the following changes: | ||||
(1) Replace reference with in-lined URL of the IANA port registry, | ||||
(2) Replace the first reference with the in-lined URL of the IANA | ||||
character set registry, and drop the second one, and | ||||
(3) Drop the reference, as the next sentence refers to the Media Type | ||||
Registration Process anyway. | ||||
(see also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2006OctDec/0181.html> | ||||
Resolution (2007-03-18): Accepted during the Prague meeting, see | ||||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action21. | ||||
H.3. i47-inconsistency-in-date-format-explanation | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i47> | ||||
julian.reschke@greenbytes.de (2006-11-20): Should say "...obsolete | ||||
RFC1036 date format [...]..." instead of "...obsolete RFC 850 [12] | ||||
date format...". | ||||
See also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2006OctDec/0187.html>. | ||||
Resolution (2006-11-20): Done. | ||||
H.4. i49-connection-header-text | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i49> | ||||
julian.reschke@greenbytes.de (2006-12-12): "Other hop-by-hop headers | ||||
MUST be listed in a Connection header, (section 14.10) to be | ||||
introduced into HTTP/1.1 (or later)." doesn't really make sense. | ||||
(See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/ | ||||
0264.html>) | ||||
Jeff.Mogul@hp.com (2006-12-12): Proposed rewrite: " Other hop-by-hop | ||||
headers, if they are introduced either in HTTP/1.1 or later versions | ||||
of HTTP/1.x, MUST be listed in a Connection header (Section 14.10)." | ||||
(See <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/ | ||||
0265.html>) | ||||
Resolution (2006-12-15): Resolve as proposed by Jeff Mogul in <http:/ | ||||
/lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0265.html>. | ||||
H.5. i48-date-reference-typo | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i48> | ||||
julian.reschke@greenbytes.de (2006-11-20): Should say "rfc1123-date | ||||
format [...]" instead of "[...]-date format". | ||||
See also <http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2006OctDec/0186.html> | ||||
hno@squid-cache.org (2006-11-29): Better without the [8], making it | ||||
an internal reference to the grammar. The rfc1123-date is not a copy | ||||
of RFC1123, only a subset thereof. | ||||
The relation to RFC 1123 is already well established elsewhere in | ||||
3.3.1, including the MUST level requirement on sending the RFC 1123 | ||||
derived format. | ||||
A similar RFC 1123 reference which is better replaced by a rfc1123- | ||||
date grammar reference is also seen in 14.21 Last-Modified. | ||||
Resolution (2006-11-30): Done. | ||||
Appendix I. Open issues (to be removed by RFC Editor prior to | ||||
publication) | ||||
I.1. rfc2616bis | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes | ||||
with respect to the revision process itself. | ||||
I.2. unneeded_references | ||||
Type: edit | ||||
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0054> | ||||
julian.reschke@greenbytes.de (2006-10-19): The reference entries for | ||||
RFC1866, RFC2069 and RFC2026 are unused. Remove them? | ||||
julian.reschke@greenbytes.de (2006-11-02): See also | ||||
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0118 and | ||||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i44. | ||||
I.3. edit | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-10-08): Umbrella issue for | ||||
editorial fixes/enhancements. | ||||
I.4. i66-iso8859-1-reference | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i66> | ||||
julian.reschke@greenbytes.de (2006-10-28): Classify ISO8859 as | ||||
normative, and simplify reference to only refer to ISO8859 Part 1 | ||||
(because that's the only part needed here), and update to the 1998 | ||||
version. | ||||
I.5. abnf | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i36> | ||||
julian.reschke@greenbytes.de (2006-12-03): Update BNF to RFC4234 | ||||
(plan to be added). | ||||
I.6. rfc2048_informative_and_obsolete | ||||
Type: edit | ||||
julian.reschke@greenbytes.de (2006-11-15): Classify RFC2048 | ||||
("Multipurpose Internet Mail Extensions (MIME) Part Four: | ||||
Registration Procedures") as informative, update to RFC4288, | ||||
potentially update the application/http and multipart/byteranges MIME | ||||
type registration. Also, in Section 3.7 fix first reference to refer | ||||
to RFC2046 (it's about media types in general, not the registration | ||||
procedure). | ||||
julian.reschke@greenbytes.de (2007-04-20): Separate issue for | ||||
updating the registration template: i55-updating-to-rfc4288. | ||||
I.7. i34-updated-reference-for-uris | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i34> | ||||
julian.reschke@greenbytes.de (2006-11-14): Update RFC2396 ("Uniform | ||||
Resource Identifiers (URI): Generic Syntax") to RFC3986. | ||||
I.8. i50-misc-typos | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i50> | ||||
a-travis@microsoft.com (2006-12-18): (See http://lists.w3.org/ | ||||
Archives/Public/ietf-http-wg/2006OctDec/0275.html). | ||||
julian.reschke@greenbytes.de (2007-06-29): Some of the strictly | ||||
editorial issues have been resolves as part of issue "edit". | ||||
I.9. i65-informative-references | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i65> | ||||
julian.reschke@greenbytes.de (2007-05-28): The following references | ||||
are informative: Luo1998 ("Tunneling TCP based protocols through Web | ||||
proxy servers", also update reference to quote the expired Internet | ||||
Draft properly). Nie1997 ("Network Performance Effects of HTTP/1.1, | ||||
CSS1, and PNG"). Pad1995 ("Improving HTTP Latency"). RFC821 (SMTP), | ||||
also update the reference to RFC2821. RFC822 ("STANDARD FOR THE | ||||
FORMAT OF ARPA INTERNET TEXT MESSAGES") -- but add another instance | ||||
as RFC822ABNF for the cases where the reference if for the ABNF part | ||||
(these references will later be replaced by references to RFC4234 | ||||
(see issue abnf)). RFC959 (FTP). RFC1036 ("Standard for Interchange | ||||
of USENET Messages"). RFC1123 ("Requirements for Internet Hosts -- | ||||
Application and Support") -- it is only used as a background | ||||
reference for rfc1123-date, which this spec defines itself (note this | ||||
disagrees with draft-gettys-http-v11-spec-rev-00 which made it | ||||
normative). RFC1305 ("Network Time Protocol (Version 3)"). RFC1436 | ||||
(Gopher). RFC1630 (URI Syntax) -- there'll be a normative reference | ||||
to a newer spec. RFC1738 (URL) -- there'll be a normative reference | ||||
to a newer spec. RFC1806 ("Communicating Presentation Information in | ||||
Internet Messages: The Content-Disposition Header"). RFC1808 | ||||
(Relative Uniform Resource Locators). RFC1867 ("Form-based File | ||||
Upload in HTML"), also update the reference to RFC2388 ("Returning | ||||
Values from Forms: multipart/form-data"). RFC1900 ("Renumbering | ||||
Needs Work"). RFC1945 (HTTP/1.0). RFC2026 ("The Internet Standards | ||||
Process -- Revision 3"). RFC2049 ("Multipurpose Internet Mail | ||||
Extensions (MIME) Part Five: Conformance Criteria and Examples"). | ||||
RFC2068 (HTTP/1.1). RFC2076 ("Common Internet Message Headers"). | ||||
RFC2110 (MHTML), also update the reference to RFC2557. RFC2145 ("Use | ||||
and Interpretation of HTTP Version Numbers"). RFC2183 | ||||
("Communicating Presentation Information in Internet Messages: The | ||||
Content-Disposition Header Field"). RFC2277 ("IETF Policy on | ||||
Character Sets and Languages"). RFC2279 (UTF8), also update the | ||||
reference to RFC3629. RFC2324 (HTCPCP/1.0). Spero ("Analysis of | ||||
HTTP Performance Problems"). Tou1998 ("Analysis of HTTP | ||||
Performance"). WAIS ("WAIS Interface Protocol Prototype Functional | ||||
Specification (v1.5)"). | ||||
derhoermi@gmx.net (2007-05-28): _On RFC1950-1952:_ Understanding | ||||
these documents is required in order to understand the coding values | ||||
defined for the coding registry established and used by the document; | ||||
why would it be appropriate to cite them as informative? | ||||
I.10. i52-sort-1.3-terminology | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i52> | ||||
a-travis@microsoft.com (2006-12-21): It's irritating to try and look | ||||
up definitions in section 1.3. IMHO, the entries really should be | ||||
sorted alphabetically, despite the fact that the terms have | ||||
dependencies on one another. | ||||
julian.reschke@greenytes.de (2006-06-15): See action item | ||||
http://www.w3.org/2007/03/18-rfc2616-minutes.html#action23 and | ||||
proposal in http://lists.w3.org/Archives/Public/ietf-http-wg/ | ||||
2007AprJun/0350.html. | ||||
julian.reschke@greenytes.de (2006-06-15): I personally think we | ||||
should not do this change: | ||||
(1) Sorting paragraphs makes it very hard to verify the changes; in | ||||
essence, a reviewer would either need to trust us, or re-do the | ||||
shuffling to control whether it's correct (nothing lost, no change in | ||||
the definitions). | ||||
(2) In the RFC2616 ordering, things that belong together (such as | ||||
"client", "user agent", "server" ...) are close to each other. | ||||
(3) Contrary to RFC2616, the text version of new spec will contain an | ||||
alphabetical index section anyway (unless it's removed upon | ||||
publication :-). | ||||
I.11. i63-header-length-limit-with-encoded-words | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i63> | ||||
derhoermi@gmx.net (2007-05-14): (See http://lists.w3.org/Archives/ | ||||
Public/ietf-http-wg/2007AprJun/0050.html). | ||||
I.12. i31-qdtext-bnf | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i31> | ||||
jamie@shareable.org (2004-03-15): ...I wrote a regular expression | ||||
based on the RFC 2616 definition, and that allows "foo\" as a quoted- | ||||
string. That's not intended, is it? | ||||
I.13. i62-whitespace-in-quoted-pair | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i62> | ||||
dan.winship@gmail.com (2007-04-20): (...) RFC 2822 updates RFC 822's | ||||
quoted-pair rule to disallow CR, LF, and NUL. We should probably | ||||
make the same change. | ||||
I.14. i58-what-identifies-an-http-resource | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i58> | ||||
julian.reschke@gmx.de (2007-01-23): 3.2.2 really doesn't say what | ||||
identifies the resource: | ||||
"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 for TCP connections on that port of that host, and the | ||||
Request-URI for the resource is abs_path (Section 5.1.2)." | ||||
But it *does* say what part of the HTTP URL becomes the Request-URI, | ||||
and that definitively needs to be fixed. | ||||
I.15. i51-http-date-vs-rfc1123-date | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i51> | ||||
a-travis@microsoft.com (2006-12-18): On closer inspection, shouldn't | ||||
the BNF for that section (14.18) be "rfc1123-date" and not "HTTP- | ||||
date"? I mean, why say it's an HTTP-date, but only RFC 1123 form is | ||||
allowed (conflicting with the definition of HTTP-date)*? Likewise, | ||||
shouldn't we just use the rfc1123-date moniker throughout the | ||||
document whenever explicitly referring to only dates in RFC 1123 | ||||
format? | ||||
I.16. i67-quoting-charsets | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i67> | ||||
maiera@de.ibm.com (2007-05-23): (See http://lists.w3.org/Archives/ | ||||
Public/ietf-http-wg/2007AprJun/0065.html). | ||||
I.17. media-reg | ||||
Type: change | ||||
<http://purl.org/NET/http-errata#media-reg> | ||||
derhoermi@gmx.net (2000-09-10): See | ||||
http://lists.w3.org/Archives/Public/ietf-http-wg-old/2000SepDec/0013. | ||||
julian.reschke@greenbytes.de (2007-04-20): See also | ||||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i8. | ||||
I.18. languagetag | ||||
Type: change | ||||
<http://purl.org/NET/http-errata#languagetag> | ||||
julian.reschke@greenbytes.de (2006-10-14): See | ||||
http://purl.org/NET/http-errata#languagetag. | ||||
julian.reschke@greenbytes.de (2006-10-14): In the meantime RFC3066 | ||||
has been obsoleted by RFC4646. See also | ||||
http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0001. | ||||
julian.reschke@greenbytes.de (2006-11-15): See also | ||||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i13. | ||||
I.19. i56-6.1.1-can-be-misread-as-a-complete-list | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> | ||||
henrik@henriknordstrom.net (2007-01-11): The second sentence in the | ||||
first paragraph can on a quick reading be misread as section 10 | ||||
contains a complete definiton of all possible status codes, where it | ||||
in reality only has the status codes defined by this RFC. | ||||
I.20. i57-status-code-and-reason-phrase | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i57> | ||||
henrik@henriknordstrom.net (2007-01-11): 6.1.1 is apparently a bit | ||||
too vague about how applications should parse and process the | ||||
information, making some implementations parse the reason phrase | ||||
(probably exact matches on the complete status line, not just status | ||||
code) to determine the outcome. | ||||
There should be a SHOULD requirement or equivalent that applications | ||||
use the status code to determine the status of the response and only | ||||
process the Reason Phrase as a comment intended for humans. | ||||
It's true that later in the same section there is a reverse MAY | ||||
requirement implying this by saying that the phrases in the rfc is | ||||
just an example and may be replaced without affecting the protocol, | ||||
but apparently it's not sufficient for implementers to understand | ||||
that applications should not decide the outcome based on the reason | ||||
phrase. | ||||
I.21. i59-status-code-registry | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i59> | ||||
henrik@henriknordstrom.net (2007-02-18): The IANA status code | ||||
registry should be referred to. | ||||
I.22. i21-put-side-effects | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i21> | ||||
mnot@yahoo-inc.com (2006-04-03): (See http://lists.w3.org/Archives/ | ||||
Public/ietf-http-wg/2006AprJun/0002.html). | ||||
I.23. i54-definition-of-1xx-warn-codes | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54> | ||||
a-travis@microsoft.com (2006-12-22): See | ||||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i54. | ||||
I.24. i60-13.5.1-and-13.5.2 | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i60> | ||||
mnot@yahoo-inc.com (2007-03-30): 13.5.1 and 13.5.2 describe how | ||||
proxies should handle headers, even though it's in a section entitled | ||||
"Caching in HTTP." People have a hard time finding them. Would it | ||||
be helpful to try to separate out the purely intermediary-related | ||||
material from section 13 to a more appropriate place (e.g., section | ||||
8, or a new section)? | ||||
I.25. i53-allow-is-not-in-13.5.2 | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i53> | ||||
a-travis@microsoft.com (2006-12-20): Section 14.7 states: | ||||
"A proxy MUST NOT modify the Allow header field even if it does not | ||||
understand all the methods specified, since the user agent might have | ||||
other means of communicating with the origin server." | ||||
However, section 13.5.2 (Non-modifiable Headers) makes no mention of | ||||
Allow. This seems like an error, but I'm not entirely sure what the | ||||
fix should be -- remove 13.5.2 and push the (not-)modifiable | ||||
information in the definition of the respective headers, or to | ||||
maintain 13.5.2 in parallel with all of the header definitions, or to | ||||
push all the information out of the header definitions into 13.5.2. | ||||
The easy fix for now would be to just make a mention of Allow in | ||||
13.5.2. | ||||
Additionally, Server should also be included. | ||||
I.26. i25-accept-encoding-bnf | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i25> | ||||
abodeman@yahoo.com (2005-06-02): In section 14.3, the definition of | ||||
Accept-Encoding is given as follows: | ||||
Accept-Encoding = "Accept-Encoding" ":" 1#( codings [ ";" "q" "=" | ||||
qvalue ] ) | ||||
This definition implies that there must be at least one non-null | ||||
codings. However, just below this definition, one of the examples | ||||
given has an empty Accept-Encoding field-value: | ||||
Accept-Encoding: compress, gzip | ||||
Accept-Encoding: | ||||
Accept-Encoding: * | ||||
Accept-Encoding: compress;q=0.5, gzip;q=1.0 | ||||
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | ||||
Furthermore, the fourth rule for testing whether a content-coding is | ||||
acceptable mentions the possibility that the field-value may be | ||||
empty. | ||||
It seems, then, that the definition for Accept-Encoding should be | ||||
revised: | ||||
Accept-Encoding = "Accept-Encoding" ":" #( codings [ ";" "q" "=" | ||||
qvalue ] ) | ||||
I.27. i61-redirection-vs-location | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i61> | ||||
julian.reschke@gmx.de (2007-04-19): The first sentence could be | ||||
understood as if the presence of the "Location" response header | ||||
always implies some kind of redirection. See also http:// | ||||
lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0020.html. | ||||
I.28. fragment-combination | ||||
Type: change | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43> | ||||
fielding@kiwi.ics.uci.edu (1999-08-06): See | ||||
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0103. | ||||
julian.reschke@greenbytes.de (2006-10-29): Part of this was fixed in | ||||
draft 01 (see issue location-fragments). This leaves us with the | ||||
open issue: _At present, the behavior in the case where there was a | ||||
fragment with the original URI, e.g.: | ||||
http://host1.example.com/resource1#fragment1 where /resource1 | ||||
redirects to http://host2.example.com/resource2#fragment2 is | ||||
'fragment1' discarded? Do you find fragment2 and then find fragment1 | ||||
within it? We don't have fragment combination rules._. See also | ||||
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i43. | ||||
I.29. i55-updating-to-rfc4288 | ||||
Type: edit | ||||
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i56> | ||||
julian.reschke@gmx.de (2007-01-05): The update from RFC2048 to | ||||
RFC4288 requires minor modifications for the media type registrations | ||||
for "message/http", "application/http" and "multipart/byteranges". | ||||
Index | Index | |||
1 | 1 | |||
100 Continue (status code) 63 | 100 Continue (status code) 68 | |||
101 Switching Protocols (status code) 63 | 101 Switching Protocols (status code) 68 | |||
2 | 2 | |||
200 OK (status code) 64 | 200 OK (status code) 69 | |||
201 Created (status code) 64 | 201 Created (status code) 69 | |||
202 Accepted (status code) 64 | 202 Accepted (status code) 69 | |||
203 Non-Authoritative Information (status code) 65 | 203 Non-Authoritative Information (status code) 70 | |||
204 No Content (status code) 65 | 204 No Content (status code) 70 | |||
205 Reset Content (status code) 65 | 205 Reset Content (status code) 70 | |||
206 Partial Content (status code) 66 | 206 Partial Content (status code) 71 | |||
3 | 3 | |||
300 Multiple Choices (status code) 67 | 300 Multiple Choices (status code) 72 | |||
301 Moved Permanently (status code) 67 | 301 Moved Permanently (status code) 72 | |||
302 Found (status code) 68 | 302 Found (status code) 73 | |||
303 See Other (status code) 68 | 303 See Other (status code) 73 | |||
304 Not Modified (status code) 69 | 304 Not Modified (status code) 74 | |||
305 Use Proxy (status code) 69 | 305 Use Proxy (status code) 74 | |||
306 (Unused) (status code) 70 | 306 (Unused) (status code) 75 | |||
307 Temporary Redirect (status code) 70 | 307 Temporary Redirect (status code) 75 | |||
4 | 4 | |||
400 Bad Request (status code) 71 | 400 Bad Request (status code) 76 | |||
401 Unauthorized (status code) 71 | 401 Unauthorized (status code) 76 | |||
402 Payment Required (status code) 71 | 402 Payment Required (status code) 76 | |||
403 Forbidden (status code) 71 | 403 Forbidden (status code) 76 | |||
404 Not Found (status code) 71 | 404 Not Found (status code) 76 | |||
405 Method Not Allowed (status code) 72 | 405 Method Not Allowed (status code) 77 | |||
406 Not Acceptable (status code) 72 | 406 Not Acceptable (status code) 77 | |||
407 Proxy Authentication Required (status code) 72 | 407 Proxy Authentication Required (status code) 77 | |||
408 Request Timeout (status code) 73 | 408 Request Timeout (status code) 78 | |||
409 Conflict (status code) 73 | 409 Conflict (status code) 78 | |||
410 Gone (status code) 73 | 410 Gone (status code) 78 | |||
411 Length Required (status code) 74 | 411 Length Required (status code) 79 | |||
412 Precondition Failed (status code) 74 | 412 Precondition Failed (status code) 79 | |||
413 Request Entity Too Large (status code) 74 | 413 Request Entity Too Large (status code) 79 | |||
414 Request-URI Too Long (status code) 74 | 414 Request-URI Too Long (status code) 79 | |||
415 Unsupported Media Type (status code) 74 | 415 Unsupported Media Type (status code) 79 | |||
416 Requested Range Not Satisfiable (status code) 74 | 416 Requested Range Not Satisfiable (status code) 79 | |||
417 Expectation Failed (status code) 75 | 417 Expectation Failed (status code) 80 | |||
5 | 5 | |||
500 Internal Server Error (status code) 75 | 500 Internal Server Error (status code) 80 | |||
501 Not Implemented (status code) 75 | 501 Not Implemented (status code) 80 | |||
502 Bad Gateway (status code) 75 | 502 Bad Gateway (status code) 80 | |||
503 Service Unavailable (status code) 76 | 503 Service Unavailable (status code) 81 | |||
504 Gateway Timeout (status code) 76 | 504 Gateway Timeout (status code) 81 | |||
505 HTTP Version Not Supported (status code) 76 | 505 HTTP Version Not Supported (status code) 81 | |||
A | A | |||
Accept header 107 | Accept header 112 | |||
Accept-Charset header 109 | Accept-Charset header 114 | |||
Accept-Encoding header 109 | Accept-Encoding header 114 | |||
Accept-Language header 111 | Accept-Language header 116 | |||
Accept-Ranges header 112 | Accept-Ranges header 117 | |||
Age header 112 | Age header 117 | |||
age 12 | age 16 | |||
Allow header 113 | Allow header 118 | |||
Alternates header 182 | Alternates header 190 | |||
application/http Media Type 170 | application/http Media Type 177 | |||
Authorization header 113 | Authorization header 118 | |||
C | C | |||
Cache Directives | Cache Directives | |||
max-age 119, 121 | max-age 124, 126 | |||
max-stale 119 | max-stale 124 | |||
min-fresh 119 | min-fresh 124 | |||
must-revalidate 121 | must-revalidate 126 | |||
no-cache 117 | no-cache 122 | |||
no-store 117 | no-store 122 | |||
no-transform 122 | no-transform 127 | |||
only-if-cached 121 | only-if-cached 126 | |||
private 116 | private 121 | |||
proxy-revalidate 122 | proxy-revalidate 127 | |||
public 116 | public 121 | |||
s-maxage 118 | s-maxage 123 | |||
cache 11 | cache 15 | |||
Cache-Control header 114 | Cache-Control header 119 | |||
cacheable 11 | cacheable 15 | |||
client 10 | client 14 | |||
compress 25 | compress 30 | |||
CONNECT method 62 | CONNECT method 67 | |||
Connection header 124 | Connection header 129 | |||
connection 9 | connection 13 | |||
content negotiation 10 | content negotiation 14 | |||
Content-Base header 182 | Content-Base header 190 | |||
Content-Disposition header 176 | Content-Disposition header 185 | |||
Content-Encoding header 125 | Content-Encoding header 130 | |||
Content-Language header 125 | Content-Language header 130 | |||
Content-Length header 126 | Content-Length header 131 | |||
Content-Location header 127 | Content-Location header 132 | |||
Content-MD5 header 128 | Content-MD5 header 133 | |||
Content-Range header 129 | Content-Range header 134 | |||
Content-Type header 131 | Content-Type header 136 | |||
Content-Version header 182 | Content-Version header 190 | |||
D | D | |||
Date header 131 | Date header 136 | |||
deflate 26 | deflate 30 | |||
DELETE method 61 | DELETE method 66 | |||
Derived-From header 182 | Derived-From header 190 | |||
downstream 13 | downstream 17 | |||
E | E | |||
entity 9 | entity 13 | |||
ETag header 133 | ETag header 138 | |||
Expect header 133 | Expect header 138 | |||
Expires header 134 | Expires header 139 | |||
explicit expiration time 12 | explicit expiration time 16 | |||
F | F | |||
first-hand 11 | first-hand 15 | |||
fresh 12 | fresh 16 | |||
freshness lifetime 12 | freshness lifetime 16 | |||
From header 135 | From header 140 | |||
G | G | |||
gateway 11 | gateway 15 | |||
GET method 58 | GET method 63 | |||
Grammar | Grammar | |||
Accept 107 | Accept 112 | |||
Accept-Charset 109 | Accept-Charset 114 | |||
Accept-Encoding 109 | Accept-Encoding 114 | |||
accept-extension 107 | accept-extension 112 | |||
Accept-Language 111 | Accept-Language 116 | |||
accept-params 107 | accept-params 112 | |||
Accept-Ranges 112 | Accept-Ranges 117 | |||
acceptable-ranges 112 | acceptable-ranges 117 | |||
Age 113 | Age 118 | |||
age-value 113 | age-value 118 | |||
Allow 113 | Allow 118 | |||
ALPHA 18 | ALPHA 22 | |||
asctime-date 23 | asctime-date 28 | |||
attribute 26 | attribute 31 | |||
Authorization 114 | Authorization 119 | |||
byte-content-range-spec 129 | byte-content-range-spec 134 | |||
byte-range-resp-spec 129 | byte-range-resp-spec 134 | |||
byte-range-set 145 | byte-range-set 150 | |||
byte-range-spec 145 | byte-range-spec 150 | |||
byte-ranges-specifier 145 | byte-ranges-specifier 150 | |||
bytes-unit 33 | bytes-unit 37 | |||
Cache-Control 115 | Cache-Control 120 | |||
cache-directive 115 | cache-directive 120 | |||
cache-extension 115 | cache-extension 120 | |||
cache-request-directive 115 | cache-request-directive 120 | |||
cache-response-directive 115 | cache-response-directive 120 | |||
CHAR 18 | CHAR 22 | |||
charset 24 | charset 29 | |||
chunk 28 | chunk 32 | |||
chunk-data 28 | chunk-data 32 | |||
chunk-ext-name 28 | chunk-ext-name 32 | |||
chunk-ext-val 28 | chunk-ext-val 32 | |||
chunk-extension 28 | chunk-extension 32 | |||
chunk-size 28 | chunk-size 32 | |||
Chunked-Body 28 | Chunked-Body 32 | |||
codings 109 | codings 114 | |||
comment 19 | comment 23 | |||
Connection 124 | Connection 129 | |||
connection-token 124 | connection-token 129 | |||
content-coding 25 | content-coding 30 | |||
content-disposition 177 | content-disposition 185 | |||
Content-Encoding 125 | Content-Encoding 130 | |||
Content-Language 125 | Content-Language 131 | |||
Content-Length 126 | Content-Length 131 | |||
Content-Location 127 | Content-Location 132 | |||
Content-MD5 128 | Content-MD5 133 | |||
Content-Range 129 | Content-Range 134 | |||
content-range-spec 129 | content-range-spec 134 | |||
Content-Type 131 | Content-Type 136 | |||
CR 18 | CR 22 | |||
CRLF 18 | CRLF 22 | |||
ctext 19 | ctext 23 | |||
CTL 18 | CTL 22 | |||
Date 131 | Date 136 | |||
date1 23 | date1 28 | |||
date2 23 | date2 28 | |||
date3 23 | date3 28 | |||
delta-seconds 24 | delta-seconds 28 | |||
DIGIT 18 | DIGIT 22 | |||
disp-extension-parm 177 | disp-extension-parm 185 | |||
disp-extension-token 177 | disp-extension-token 185 | |||
disposition-parm 177 | disposition-parm 185 | |||
disposition-type 177 | disposition-type 185 | |||
entity-body 47 | entity-body 52 | |||
entity-header 47 | entity-header 52 | |||
entity-tag 32 | entity-tag 37 | |||
ETag 133 | ETag 138 | |||
Expect 133 | Expect 138 | |||
expect-params 133 | expect-params 138 | |||
expectation 133 | expectation 138 | |||
expectation-extension 133 | expectation-extension 138 | |||
Expires 134 | Expires 139 | |||
extension-code 45 | extension-code 50 | |||
extension-header 47 | extension-header 52 | |||
extension-method 39 | extension-method 44 | |||
extension-pragma 143 | extension-pragma 148 | |||
field-content 35 | field-content 40 | |||
field-name 35 | field-name 40 | |||
field-value 35 | field-value 40 | |||
filename-parm 177 | filename-parm 185 | |||
first-byte-pos 145 | first-byte-pos 150 | |||
From 135 | From 140 | |||
general-header 38 | general-header 43 | |||
generic-message 34 | generic-message 39 | |||
HEX 19 | HEX 23 | |||
Host 135 | Host 141 | |||
HT 18 | HT 22 | |||
HTTP-date 23 | HTTP-date 28 | |||
HTTP-message 34 | HTTP-message 39 | |||
HTTP-Version 20 | HTTP-Version 24 | |||
http_URL 21 | http_URL 26 | |||
If-Match 136 | If-Match 141 | |||
If-Modified-Since 137 | If-Modified-Since 142 | |||
If-None-Match 139 | If-None-Match 144 | |||
If-Range 140 | If-Range 145 | |||
If-Unmodified-Since 141 | If-Unmodified-Since 146 | |||
instance-length 129 | instance-length 134 | |||
language-range 111 | language-range 116 | |||
language-tag 32 | language-tag 36 | |||
last-byte-pos 145 | last-byte-pos 150 | |||
last-chunk 28 | last-chunk 32 | |||
Last-Modified 141 | Last-Modified 146 | |||
LF 18 | LF 22 | |||
LOALPHA 18 | LOALPHA 22 | |||
Location 142 | Location 147 | |||
LWS 18 | LWS 22 | |||
Max-Forwards 142 | Max-Forwards 148 | |||
md5-digest 128 | md5-digest 133 | |||
media-range 107 | media-range 112 | |||
media-type 29 | media-type 33 | |||
message-body 35 | message-body 40 | |||
message-header 35 | message-header 40 | |||
Method 39 | Method 44 | |||
MIME-Version 174 | MIME-Version 182 | |||
month 23 | month 28 | |||
OCTET 18 | OCTET 22 | |||
opaque-tag 32 | opaque-tag 37 | |||
other-range-unit 33 | other-range-unit 37 | |||
parameter 26 | parameter 31 | |||
Pragma 143 | Pragma 148 | |||
pragma-directive 143 | pragma-directive 148 | |||
primary-tag 32 | primary-tag 36 | |||
product 31 | product 35 | |||
product-version 31 | product-version 35 | |||
protocol-name 153 | protocol-name 158 | |||
protocol-version 153 | protocol-version 158 | |||
Proxy-Authenticate 144 | Proxy-Authenticate 149 | |||
Proxy-Authorization 144 | Proxy-Authorization 149 | |||
pseudonym 153 | pseudonym 158 | |||
qdtext 19 | qdtext 23 | |||
quoted-pair 19 | quoted-pair 23 | |||
quoted-string 19 | quoted-string 23 | |||
qvalue 31 | qvalue 36 | |||
Range 146 | Range 152 | |||
range-unit 33 | range-unit 37 | |||
ranges-specifier 145 | ranges-specifier 150 | |||
Reason-Phrase 45 | Reason-Phrase 50 | |||
received-by 153 | received-by 158 | |||
received-protocol 153 | received-protocol 158 | |||
Referer 147 | Referer 152 | |||
Request 39 | Request 44 | |||
request-header 42 | request-header 47 | |||
Request-Line 39 | Request-Line 44 | |||
Request-URI 40 | Request-URI 45 | |||
Response 43 | Response 48 | |||
response-header 46 | response-header 51 | |||
Retry-After 147 | Retry-After 153 | |||
rfc850-date 23 | rfc850-date 28 | |||
rfc1123-date 23 | rfc1123-date 28 | |||
separators 19 | separators 23 | |||
Server 148 | Server 153 | |||
SP 18 | SP 22 | |||
start-line 34 | start-line 39 | |||
Status-Code 45 | Status-Code 50 | |||
Status-Line 43 | Status-Line 48 | |||
subtag 32 | subtag 36 | |||
subtype 29 | subtype 33 | |||
suffix-byte-range-spec 145 | suffix-byte-range-spec 151 | |||
suffix-length 145 | suffix-length 151 | |||
t-codings 148 | t-codings 154 | |||
TE 148 | TE 154 | |||
TEXT 18 | TEXT 22 | |||
time 23 | time 28 | |||
token 19 | token 23 | |||
Trailer 150 | Trailer 155 | |||
trailer 28 | trailer 32 | |||
transfer-coding 26 | transfer-coding 31 | |||
Transfer-Encoding 150 | Transfer-Encoding 155 | |||
transfer-extension 26 | transfer-extension 31 | |||
type 29 | type 33 | |||
UPALPHA 18 | UPALPHA 22 | |||
Upgrade 151 | Upgrade 156 | |||
User-Agent 152 | User-Agent 157 | |||
value 26 | value 31 | |||
Vary 152 | Vary 157 | |||
Via 153 | Via 158 | |||
warn-agent 155 | warn-agent 160 | |||
warn-code 155 | warn-code 160 | |||
warn-date 155 | warn-date 160 | |||
warn-text 155 | warn-text 160 | |||
Warning 155 | Warning 160 | |||
warning-value 155 | warning-value 160 | |||
weak 32 | weak 37 | |||
weekday 23 | weekday 28 | |||
wkday 23 | wkday 28 | |||
WWW-Authenticate 157 | WWW-Authenticate 162 | |||
gzip 25 | gzip 30 | |||
H | H | |||
HEAD method 58 | HEAD method 63 | |||
Headers | Headers | |||
Accept 107 | Accept 112 | |||
Accept-Charset 109 | Accept-Charset 114 | |||
Accept-Encoding 109 | Accept-Encoding 114 | |||
Accept-Language 111 | Accept-Language 116 | |||
Accept-Ranges 112 | Accept-Ranges 117 | |||
Age 112 | Age 117 | |||
Allow 113 | Allow 118 | |||
Alternate 182 | Alternate 190 | |||
Authorization 113 | Authorization 118 | |||
Cache-Control 114 | Cache-Control 119 | |||
Connection 124 | Connection 129 | |||
Content-Base 182 | Content-Base 190 | |||
Content-Disposition 176 | Content-Disposition 185 | |||
Content-Encoding 125 | Content-Encoding 130 | |||
Content-Language 125 | Content-Language 130 | |||
Content-Length 126 | Content-Length 131 | |||
Content-Location 127 | Content-Location 132 | |||
Content-MD5 128 | Content-MD5 133 | |||
Content-Range 129 | Content-Range 134 | |||
Content-Type 131 | Content-Type 136 | |||
Content-Version 182 | Content-Version 190 | |||
Date 131 | Date 136 | |||
Derived-From 182 | Derived-From 190 | |||
ETag 133 | ETag 138 | |||
Expect 133 | Expect 138 | |||
Expires 134 | Expires 139 | |||
From 135 | From 140 | |||
Host 135 | Host 140 | |||
If-Match 136 | If-Match 141 | |||
If-Modified-Since 137 | If-Modified-Since 142 | |||
If-None-Match 139 | If-None-Match 144 | |||
If-Range 140 | If-Range 145 | |||
If-Unmodified-Since 141 | If-Unmodified-Since 146 | |||
Last-Modified 141 | Last-Modified 146 | |||
Link 182 | Link 190 | |||
Location 142 | Location 147 | |||
Max-Forwards 142 | Max-Forwards 148 | |||
Pragma 143 | Pragma 148 | |||
Proxy-Authenticate 144 | Proxy-Authenticate 149 | |||
Proxy-Authorization 144 | Proxy-Authorization 149 | |||
Public 182 | Public 190 | |||
Range 144 | Range 150 | |||
Referer 147 | Referer 152 | |||
Retry-After 147 | Retry-After 153 | |||
Server 148 | Server 153 | |||
TE 148 | TE 154 | |||
Trailer 149 | Trailer 155 | |||
Transfer-Encoding 150 | Transfer-Encoding 155 | |||
Upgrade 150 | Upgrade 156 | |||
URI 182 | URI 190 | |||
User-Agent 152 | User-Agent 157 | |||
Vary 152 | Vary 157 | |||
Via 153 | Via 158 | |||
Warning 154 | Warning 160 | |||
WWW-Authenticate 157 | WWW-Authenticate 162 | |||
heuristic expiration time 12 | heuristic expiration time 16 | |||
Host header 135 | Host header 140 | |||
I | I | |||
identity 26 | identity 30 | |||
If-Match header 136 | If-Match header 141 | |||
If-Modified-Since header 137 | If-Modified-Since header 142 | |||
If-None-Match header 139 | If-None-Match header 144 | |||
If-Range header 140 | If-Range header 145 | |||
If-Unmodified-Since header 141 | If-Unmodified-Since header 146 | |||
inbound 13 | inbound 17 | |||
L | L | |||
Last-Modified header 141 | Last-Modified header 146 | |||
Link header 182 | Link header 190 | |||
LINK method 181 | LINK method 190 | |||
Location header 142 | Location header 147 | |||
M | M | |||
max-age | max-age | |||
Cache Directive 119, 121 | Cache Directive 124, 126 | |||
Max-Forwards header 142 | Max-Forwards header 148 | |||
max-stale | max-stale | |||
Cache Directive 119 | Cache Directive 124 | |||
Media Type | Media Type | |||
application/http 170 | application/http 177 | |||
message/http 170 | message/http 177 | |||
multipart/byteranges 171 | multipart/byteranges 179 | |||
multipart/x-byteranges 172 | multipart/x-byteranges 180 | |||
message 9 | message 13 | |||
message/http Media Type 170 | message/http Media Type 177 | |||
Methods | Methods | |||
CONNECT 62 | CONNECT 67 | |||
DELETE 61 | DELETE 66 | |||
GET 58 | GET 63 | |||
HEAD 58 | HEAD 63 | |||
LINK 181 | LINK 190 | |||
OPTIONS 57 | OPTIONS 62 | |||
PATCH 181 | PATCH 190 | |||
POST 59 | POST 64 | |||
PUT 60 | PUT 65 | |||
TRACE 61 | TRACE 66 | |||
UNLINK 181 | UNLINK 190 | |||
min-fresh | min-fresh | |||
Cache Directive 119 | Cache Directive 124 | |||
multipart/byteranges Media Type 171 | multipart/byteranges Media Type 179 | |||
multipart/x-byteranges Media Type 172 | multipart/x-byteranges Media Type 180 | |||
must-revalidate | must-revalidate | |||
Cache Directive 121 | Cache Directive 126 | |||
N | N | |||
no-cache | no-cache | |||
Cache Directive 117 | Cache Directive 122 | |||
no-store | no-store | |||
Cache Directive 117 | ||||
no-transform | ||||
Cache Directive 122 | Cache Directive 122 | |||
no-transform | ||||
Cache Directive 127 | ||||
O | O | |||
only-if-cached | only-if-cached | |||
Cache Directive 121 | Cache Directive 126 | |||
OPTIONS method 57 | OPTIONS method 62 | |||
origin server 10 | origin server 14 | |||
outbound 13 | outbound 17 | |||
P | P | |||
PATCH method 181 | PATCH method 190 | |||
POST method 59 | POST method 64 | |||
Pragma header 143 | Pragma header 148 | |||
private | private | |||
Cache Directive 116 | Cache Directive 121 | |||
proxy 10 | proxy 14 | |||
Proxy-Authenticate header 144 | Proxy-Authenticate header 149 | |||
Proxy-Authorization header 144 | Proxy-Authorization header 149 | |||
proxy-revalidate | proxy-revalidate | |||
Cache Directive 122 | Cache Directive 127 | |||
Public header 182 | Public header 190 | |||
public | public | |||
Cache Directive 116 | Cache Directive 121 | |||
PUT method 60 | PUT method 65 | |||
R | R | |||
Range header 144 | Range header 150 | |||
Referer header 147 | Referer header 152 | |||
representation 9 | representation 13 | |||
request 9 | request 13 | |||
resource 9 | resource 13 | |||
response 9 | response 13 | |||
Retry-After header 147 | Retry-After header 153 | |||
S | S | |||
s-maxage | s-maxage | |||
Cache Directive 118 | Cache Directive 123 | |||
semantically transparent 12 | semantically transparent 16 | |||
Server header 148 | Server header 153 | |||
server 10 | server 14 | |||
stale 12 | stale 16 | |||
Status Codes | Status Codes | |||
100 Continue 63 | 100 Continue 68 | |||
101 Switching Protocols 63 | 101 Switching Protocols 68 | |||
200 OK 64 | 200 OK 69 | |||
201 Created 64 | 201 Created 69 | |||
202 Accepted 64 | 202 Accepted 69 | |||
203 Non-Authoritative Information 65 | 203 Non-Authoritative Information 70 | |||
204 No Content 65 | 204 No Content 70 | |||
205 Reset Content 65 | 205 Reset Content 70 | |||
206 Partial Content 66 | 206 Partial Content 71 | |||
300 Multiple Choices 67 | 300 Multiple Choices 72 | |||
301 Moved Permanently 67 | 301 Moved Permanently 72 | |||
302 Found 68 | 302 Found 73 | |||
303 See Other 68 | 303 See Other 73 | |||
304 Not Modified 69 | 304 Not Modified 74 | |||
305 Use Proxy 69 | 305 Use Proxy 74 | |||
306 (Unused) 70 | 306 (Unused) 75 | |||
307 Temporary Redirect 70 | 307 Temporary Redirect 75 | |||
400 Bad Request 71 | 400 Bad Request 76 | |||
401 Unauthorized 71 | 401 Unauthorized 76 | |||
402 Payment Required 71 | 402 Payment Required 76 | |||
403 Forbidden 71 | 403 Forbidden 76 | |||
404 Not Found 71 | 404 Not Found 76 | |||
405 Method Not Allowed 72 | 405 Method Not Allowed 77 | |||
406 Not Acceptable 72 | 406 Not Acceptable 77 | |||
407 Proxy Authentication Required 72 | 407 Proxy Authentication Required 77 | |||
408 Request Timeout 73 | 408 Request Timeout 78 | |||
409 Conflict 73 | 409 Conflict 78 | |||
410 Gone 73 | 410 Gone 78 | |||
411 Length Required 74 | 411 Length Required 79 | |||
412 Precondition Failed 74 | 412 Precondition Failed 79 | |||
413 Request Entity Too Large 74 | 413 Request Entity Too Large 79 | |||
414 Request-URI Too Long 74 | 414 Request-URI Too Long 79 | |||
415 Unsupported Media Type 74 | 415 Unsupported Media Type 79 | |||
416 Requested Range Not Satisfiable 74 | 416 Requested Range Not Satisfiable 79 | |||
417 Expectation Failed 75 | 417 Expectation Failed 80 | |||
500 Internal Server Error 75 | 500 Internal Server Error 80 | |||
501 Not Implemented 75 | 501 Not Implemented 80 | |||
502 Bad Gateway 75 | 502 Bad Gateway 80 | |||
503 Service Unavailable 76 | 503 Service Unavailable 81 | |||
504 Gateway Timeout 76 | 504 Gateway Timeout 81 | |||
505 HTTP Version Not Supported 76 | 505 HTTP Version Not Supported 81 | |||
T | T | |||
TE header 148 | TE header 154 | |||
TRACE method 61 | TRACE method 66 | |||
Trailer header 149 | Trailer header 155 | |||
Transfer-Encoding header 150 | Transfer-Encoding header 155 | |||
tunnel 11 | tunnel 15 | |||
U | U | |||
UNLINK method 181 | UNLINK method 190 | |||
Upgrade header 150 | Upgrade header 156 | |||
upstream 13 | upstream 17 | |||
URI header 182 | URI header 190 | |||
user agent 10 | user agent 14 | |||
User-Agent header 152 | User-Agent header 157 | |||
V | V | |||
validator 12 | validator 16 | |||
variant 10 | variant 14 | |||
Vary header 152 | Vary header 157 | |||
Via header 153 | Via header 158 | |||
W | W | |||
Warning header 154 | Warning header 160 | |||
WWW-Authenticate header 157 | WWW-Authenticate header 162 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding | Roy T. Fielding | |||
Department of Information and Computer Science | Day Software | |||
University of California, Irvine | 23 Corporate Plaza DR, Suite 215 | |||
Irvine, CA 92697-3425 | Newport Beach, CA 92660 | |||
USA | ||||
Fax: +1(949)824-1715 | Phone: +1-949-706-5300 | |||
Email: fielding@ics.uci.edu | Fax: +1-949-706-5305 | |||
Email: fielding@gbiv.com | ||||
URI: http://roy.gbiv.com/ | ||||
James Gettys | James Gettys | |||
World Wide Web Consortium | Hewlett-Packard Company | |||
MIT Laboratory for Computer Science, NE43-356 | HP Labs, Cambridge Research Laboratory | |||
545 Technology Square | One Cambridge Center | |||
Cambridge, MA 02139 | Cambridge, MA 02138 | |||
USA | ||||
Fax: +1(617)258-8682 | Email: Jim.Gettys@hp.com | |||
Email: jg@w3.org | ||||
Jeffrey C. Mogul | Jeffrey C. Mogul | |||
Compaq Computer Corporation | Hewlett-Packard Company | |||
Western Research Laboratory | HP Labs, Large Scale Systems Group | |||
250 University Avenue | 1501 Page Mill Road, MS 1177 | |||
Palo Alto, CA 94305 | Palo Alto, CA 94304 | |||
USA | ||||
Email: mogul@wrl.dec.com | Email: JeffMogul@acm.org | |||
Henrik Frystyk Nielsen | Henrik Frystyk Nielsen | |||
World Wide Web Consortium | Microsoft Corporation | |||
MIT Laboratory for Computer Science, NE43-356 | 1 Microsoft Way | |||
545 Technology Square | Redmond, WA 98052 | |||
Cambridge, MA 02139 | USA | |||
Fax: +1(617)258-8682 | ||||
Email: frystyk@w3.org | ||||
Email: henrikn@microsoft.com | ||||
Larry Masinter | Larry Masinter | |||
Xerox Corporation | Adobe Systems, Incorporated | |||
MIT Laboratory for Computer Science, NE43-356 | 345 Park Ave | |||
3333 Coyote Hill Road | San Jose, CA 95110 | |||
Palo Alto, CA 94034 | USA | |||
Email: LMM@acm.org | ||||
URI: http://larry.masinter.net/ | ||||
Email: masinter@parc.xerox.com | ||||
Paul J. Leach | Paul J. Leach | |||
Microsoft Corporation | Microsoft Corporation | |||
1 Microsoft Way | 1 Microsoft Way | |||
Redmond, WA 98052 | Redmond, WA 98052 | |||
Email: paulle@microsoft.com | Email: paulle@microsoft.com | |||
Tim Berners-Lee | Tim Berners-Lee | |||
World Wide Web Consortium | World Wide Web Consortium | |||
MIT Laboratory for Computer Science, NE43-356 | MIT Laboratory for Computer Science | |||
545 Technology Square | 545 Technology Square | |||
Cambridge, MA 02139 | Cambridge, MA 02139 | |||
USA | ||||
Fax: +1(617)258-8682 | Fax: +1 (617) 258 8682 | |||
Email: timbl@w3.org | Email: timbl@w3.org | |||
Yves Lafon (editor) | ||||
World Wide Web Consortium | ||||
2004, Route des Lucioles | ||||
Sophia Antipolis 06902 | ||||
France | ||||
Phone: +33 492387943 | ||||
Fax: +33 492387822 | ||||
Email: ylafon@w3.org | ||||
URI: http://www.w3.org/ | ||||
Julian F. Reschke (editor) | ||||
greenbytes GmbH | ||||
Hafenweg 16 | ||||
Muenster, NW 48155 | ||||
Germany | ||||
Phone: +49 251 2807760 | ||||
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 (2007). | |||
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. | ||||
This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |