rfc2616.txt | draft-lafon-rfc2616bis-latest.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 One Laptop per Child | |||
J. Mogul | Expires: June 3, 2008 J. Mogul | |||
Compaq | HP | |||
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 | ||||
December 2007 | ||||
Hypertext Transfer Protocol -- HTTP/1.1 | Hypertext Transfer Protocol -- HTTP/1.1 | |||
draft-lafon-rfc2616bis-latest | ||||
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. | ||||
Copyright Notice | 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. | ||||
Copyright (C) The Internet Society (1999). All Rights Reserved. | 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 June 3, 2008. | ||||
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 . . . . . . . . . . . . . . . . . . 35 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 39 | ||||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 39 | ||||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 39 | ||||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 40 | ||||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 41 | ||||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 42 | ||||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 45 | ||||
5.2. The Resource Identified by a Request . . . . . . . . . . 46 | ||||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 47 | ||||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 48 | ||||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 48 | ||||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 48 | ||||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 51 | ||||
4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 52 | |||
4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 52 | |||
4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 53 | |||
4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 54 | |||
5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 39 | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 54 | |||
5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 39 | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 54 | |||
5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 40 | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 56 | |||
5.2. The Resource Identified by a Request . . . . . . . . . . 41 | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 56 | |||
5.3. Request Header Fields . . . . . . . . . . . . . . . . . 42 | 8.2. Message Transmission Requirements . . . . . . . . . . . 57 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 8.2.1. Persistent Connections and Flow Control . . . . . . 57 | |||
6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 | 8.2.2. Monitoring Connections for Error Status Messages . . 57 | |||
6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 58 | |||
6.2. Response Header Fields . . . . . . . . . . . . . . . . . 46 | ||||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | ||||
7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 47 | ||||
7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 47 | ||||
7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 48 | ||||
7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 48 | ||||
8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
8.1. Persistent Connections . . . . . . . . . . . . . . . . . 49 | ||||
8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 49 | ||||
8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 51 | ||||
8.1.4. Practical Considerations . . . . . . . . . . . . . . 51 | ||||
8.2. Message Transmission Requirements . . . . . . . . . . . 52 | ||||
8.2.1. Persistent Connections and Flow Control . . . . . . 52 | ||||
8.2.2. Monitoring Connections for Error Status Messages . . 52 | ||||
8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 53 | ||||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 62 | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 63 | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 67 | |||
10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 63 | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 67 | |||
10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 63 | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 67 | |||
10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 63 | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 67 | |||
10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 64 | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 64 | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 64 | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 64 | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 68 | |||
10.2.4. 203 Non-Authoritative Information . . . . . . . . . 65 | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 69 | |||
10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 65 | 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 69 | |||
10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 65 | 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 69 | |||
10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 66 | 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 70 | |||
10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 66 | 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 70 | |||
10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 67 | 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 71 | |||
10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 67 | 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 71 | |||
10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 68 | 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 72 | |||
10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 68 | 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 72 | |||
10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 69 | 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 73 | |||
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) . . . . . . . . . . . . . . . . . . . . 74 | |||
10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 70 | 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 74 | |||
10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 70 | 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 74 | |||
10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 71 | 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75 | |||
10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 71 | 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 75 | |||
10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 71 | 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 75 | |||
10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 71 | 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 75 | |||
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 . . . . . . . . . . . . . . . 76 | |||
10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 72 | 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 76 | |||
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 . . . . . . . . . . . . . . . . 77 | |||
10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 73 | 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 77 | |||
10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 73 | 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 77 | |||
10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 74 | 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 78 | |||
10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 74 | 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 78 | |||
10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 74 | 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 78 | |||
10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 74 | 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 78 | |||
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 . . . . . . . . . . . . . . . 79 | |||
10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 75 | 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 79 | |||
10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 75 | 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 79 | |||
10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 75 | 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 79 | |||
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 . . . . . . . . . . . . . . 80 | |||
10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 76 | 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 80 | |||
10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 76 | 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 80 | |||
11. Access Authentication . . . . . . . . . . . . . . . . . . . . 77 | 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 81 | |||
12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 78 | 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 82 | |||
12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 78 | 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 82 | |||
12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 79 | 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 83 | |||
12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 80 | 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 84 | |||
13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 81 | 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 85 | |||
13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 | 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 85 | |||
13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 82 | 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 86 | |||
13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 83 | 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 87 | |||
13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 84 | 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 88 | |||
13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 84 | 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 88 | |||
13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 85 | 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 89 | |||
13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 85 | 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 89 | |||
13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 86 | 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 90 | |||
13.2.1. Server-Specified Expiration . . . . . . . . . . . . 86 | 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 90 | |||
13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 86 | 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 90 | |||
13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 87 | 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 91 | |||
13.2.4. Expiration Calculations . . . . . . . . . . . . . . 89 | 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 93 | |||
13.2.5. Disambiguating Expiration Values . . . . . . . . . . 90 | 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 94 | |||
13.2.6. Disambiguating Multiple Responses . . . . . . . . . 91 | 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 95 | |||
13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 91 | ||||
13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 92 | 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 95 | |||
13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 92 | 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 96 | |||
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 93 | 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 96 | |||
13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 97 | ||||
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 . . . . . . . . . . . . 101 | |||
13.4. Response Cacheability . . . . . . . . . . . . . . . . . 97 | 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 102 | |||
13.5. Constructing Responses From Caches . . . . . . . . . . . 98 | 13.5. Constructing Responses From Caches . . . . . . . . . . . 102 | |||
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 . . . . . . . . . . . . . . . 103 | |||
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 . . . . . . . . . . . . . . 106 | |||
13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 103 | 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 107 | |||
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 . . . . . . . . . . . . . . 108 | |||
13.10. Invalidation After Updates or Deletions . . . . . . . . 104 | 13.10. Invalidation After Updates or Deletions . . . . . . . . 108 | |||
13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 105 | 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 109 | |||
13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 105 | 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 110 | |||
13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 106 | 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 110 | |||
14. Header Field Definitions . . . . . . . . . . . . . . . . . . 107 | 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 111 | |||
14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 107 | 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 111 | |||
14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 109 | 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 113 | |||
14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 109 | 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 113 | |||
14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 111 | 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115 | |||
14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 112 | 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 112 | 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 113 | 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 117 | |||
14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 113 | 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 117 | |||
14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 114 | 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118 | |||
14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 116 | 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 120 | |||
14.9.2. What May be Stored by Caches . . . . . . . . . . . . 117 | 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 121 | |||
14.9.3. Modifications of the Basic Expiration Mechanism . . 118 | 14.9.3. Modifications of the Basic Expiration Mechanism . . 122 | |||
14.9.4. Cache Revalidation and Reload Controls . . . . . . . 120 | 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 124 | |||
14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 122 | 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 126 | |||
14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 123 | 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 127 | |||
14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 124 | 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 128 | |||
14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125 | 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 129 | |||
14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 125 | 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 130 | |||
14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 126 | 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 130 | |||
14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 127 | 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 131 | |||
14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 128 | 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 132 | |||
14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 129 | 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 131 | 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 135 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 133 | 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 134 | 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 139 | |||
14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 140 | |||
14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 136 | 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 140 | |||
14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137 | 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 141 | |||
14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 139 | 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 143 | |||
14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 140 | 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 141 | 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 145 | |||
14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 141 | 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145 | |||
14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 142 | 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 146 | |||
14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 142 | 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 143 | 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 144 | 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 148 | |||
14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144 | 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 149 | |||
14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 144 | 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 149 | |||
14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 144 | 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 149 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 152 | |||
14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 152 | |||
14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 | 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 | |||
14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 149 | 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 150 | 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 155 | |||
14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 150 | 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 155 | |||
14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 156 | |||
14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 152 | 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 153 | 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 154 | 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 159 | |||
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. Normative References . . . . . . . . . . . . . . . . . . 171 | |||
A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 172 | 17.2. Informative References . . . . . . . . . . . . . . . . . 172 | |||
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 . . . . . . 180 | |||
A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 174 | Appendix C. Tolerant Applications . . . . . . . . . . . . . . . 182 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 183 | |||
A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 175 | D.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 183 | |||
A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 175 | D.2. Conversion to Canonical Form . . . . . . . . . . . . . . 183 | |||
A.4.7. MHTML and Line Length Limitations . . . . . . . . . 176 | D.3. Conversion of Date Formats . . . . . . . . . . . . . . . 184 | |||
A.5. Additional Features . . . . . . . . . . . . . . . . . . 176 | D.4. Introduction of Content-Encoding . . . . . . . . . . . . 184 | |||
A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 176 | D.5. No Content-Transfer-Encoding . . . . . . . . . . . . . . 184 | |||
A.6. Compatibility with Previous Versions . . . . . . . . . . 177 | D.6. Introduction of Transfer-Encoding . . . . . . . . . . . 185 | |||
A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 178 | D.7. MHTML and Line Length Limitations . . . . . . . . . . . 185 | |||
A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 179 | Appendix E. Additional Features . . . . . . . . . . . . . . . . 186 | |||
A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 179 | E.1. Content-Disposition . . . . . . . . . . . . . . . . . . 186 | |||
Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 183 | Appendix F. Compatibility with Previous Versions . . . . . . . . 187 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 | F.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . 187 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 196 | F.1.1. Changes to Simplify Multi-homed Web Servers and | |||
Intellectual Property and Copyright Statements . . . . . . . . . 198 | Conserve IP Addresses . . . . . . . . . . . . . . . 187 | |||
F.2. Compatibility with HTTP/1.0 Persistent Connections . . . 188 | ||||
F.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . 189 | ||||
F.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . 191 | ||||
Appendix G. Change Log (to be removed by RFC Editor before | ||||
publication) . . . . . . . . . . . . . . . . . . . . 193 | ||||
G.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . 193 | ||||
G.2. Since draft-lafon-rfc2616bis-00 . . . . . . . . . . . . 193 | ||||
G.3. Since draft-lafon-rfc2616bis-01 . . . . . . . . . . . . 193 | ||||
G.4. Since draft-lafon-rfc2616bis-02 . . . . . . . . . . . . 193 | ||||
G.5. Since draft-lafon-rfc2616bis-03 . . . . . . . . . . . . 194 | ||||
G.6. Since draft-lafon-rfc2616bis-04 . . . . . . . . . . . . 195 | ||||
Appendix H. Resolved issues (to be removed by RFC Editor | ||||
before publication) . . . . . . . . . . . . . . . . 196 | ||||
H.1. abnf-dquote . . . . . . . . . . . . . . . . . . . . . . 196 | ||||
H.2. abnf-rule-names . . . . . . . . . . . . . . . . . . . . 196 | ||||
H.3. abnf-prose-cr . . . . . . . . . . . . . . . . . . . . . 196 | ||||
H.4. abnf-case-insensitive . . . . . . . . . . . . . . . . . 196 | ||||
H.5. i82-rel_path-not-used . . . . . . . . . . . . . . . . . 197 | ||||
H.6. abnf-chunk-data . . . . . . . . . . . . . . . . . . . . 198 | ||||
H.7. i70-cacheability-of-303 . . . . . . . . . . . . . . . . 198 | ||||
Appendix I. Open issues (to be removed by RFC Editor prior to | ||||
publication) . . . . . . . . . . . . . . . . . . . . 201 | ||||
I.1. rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 201 | ||||
I.2. i35-split-normative-and-informative-references . . . . . 201 | ||||
I.3. i40-header-registration . . . . . . . . . . . . . . . . 201 | ||||
I.4. need_iana_considerations . . . . . . . . . . . . . . . . 201 | ||||
I.5. edit . . . . . . . . . . . . . . . . . . . . . . . . . . 202 | ||||
I.6. abnf-avoid-prose . . . . . . . . . . . . . . . . . . . . 202 | ||||
I.7. abnf . . . . . . . . . . . . . . . . . . . . . . . . . . 202 | ||||
I.8. rfc2822_normative . . . . . . . . . . . . . . . . . . . 202 | ||||
I.9. rfc1737_informative_and_obsolete . . . . . . . . . . . . 203 | ||||
I.10. rfc2048_informative_and_obsolete . . . . . . . . . . . . 203 | ||||
I.11. i34-updated-reference-for-uris . . . . . . . . . . . . . 203 | ||||
I.12. i50-misc-typos . . . . . . . . . . . . . . . . . . . . . 203 | ||||
I.13. i52-sort-1.3-terminology . . . . . . . . . . . . . . . . 204 | ||||
I.14. i63-header-length-limit-with-encoded-words . . . . . . . 204 | ||||
I.15. i74-character-encodings-for-headers . . . . . . . . . . 205 | ||||
I.16. i64-ws-in-quoted-pair . . . . . . . . . . . . . . . . . 205 | ||||
I.17. i75-rfc2145-normative . . . . . . . . . . . . . . . . . 206 | ||||
I.18. i58-what-identifies-an-http-resource . . . . . . . . . . 206 | ||||
I.19. i51-http-date-vs-rfc1123-date . . . . . . . . . . . . . 206 | ||||
I.20. i73-clarification-of-the-term-deflate . . . . . . . . . 207 | ||||
I.21. i67-quoting-charsets . . . . . . . . . . . . . . . . . . 207 | ||||
I.22. i20-default-charsets-for-text-media-types . . . . . . . 208 | ||||
I.23. i90-delimiting-messages-with-multipart-byteranges . . . 209 | ||||
I.24. languagetag . . . . . . . . . . . . . . . . . . . . . . 210 | ||||
I.25. i85-custom-ranges . . . . . . . . . . . . . . . . . . . 210 | ||||
I.26. i30-header-lws . . . . . . . . . . . . . . . . . . . . . 211 | ||||
I.27. i77-line-folding . . . . . . . . . . . . . . . . . . . . 211 | ||||
I.28. i93-repeating-single-value-headers . . . . . . . . . . . 212 | ||||
I.29. i19-bodies-on-GET . . . . . . . . . . . . . . . . . . . 212 | ||||
I.30. i88-205-bodies . . . . . . . . . . . . . . . . . . . . . 213 | ||||
I.31. i28-connection-closing . . . . . . . . . . . . . . . . . 213 | ||||
I.32. uri_vs_request_uri . . . . . . . . . . . . . . . . . . . 213 | ||||
I.33. i32-options-asterisk . . . . . . . . . . . . . . . . . . 213 | ||||
I.34. i83-options-asterisk-and-proxies . . . . . . . . . . . . 214 | ||||
I.35. i56-6.1.1-can-be-misread-as-a-complete-list . . . . . . 215 | ||||
I.36. i57-status-code-and-reason-phrase . . . . . . . . . . . 215 | ||||
I.37. i59-status-code-registry . . . . . . . . . . . . . . . . 216 | ||||
I.38. i94-reason-phrase-bnf . . . . . . . . . . . . . . . . . 216 | ||||
I.39. i91-duplicate-host-header-requirements . . . . . . . . . 216 | ||||
I.40. i72-request-method-registry . . . . . . . . . . . . . . 217 | ||||
I.41. i21-put-side-effects . . . . . . . . . . . . . . . . . . 217 | ||||
I.42. i27-put-idempotency . . . . . . . . . . . . . . . . . . 218 | ||||
I.43. i79-content-headers-vs-put . . . . . . . . . . . . . . . 219 | ||||
I.44. i33-trace-security-considerations . . . . . . . . . . . 219 | ||||
I.45. i69-clarify-requested-variant . . . . . . . . . . . . . 220 | ||||
I.46. i76-deprecate-305-use-proxy . . . . . . . . . . . . . . 220 | ||||
I.47. i78-relationship-between-401-authorization-and-www-authe 221 | ||||
I.48. i24-requiring-allow-in-405-responses . . . . . . . . . . 221 | ||||
I.49. i81-content-negotiation-for-media-types . . . . . . . . 222 | ||||
I.50. i54-definition-of-1xx-warn-codes . . . . . . . . . . . . 223 | ||||
I.51. i29-age-calculation . . . . . . . . . . . . . . . . . . 223 | ||||
I.52. i71-examples-for-etag-matching . . . . . . . . . . . . . 225 | ||||
I.53. i60-13.5.1-and-13.5.2 . . . . . . . . . . . . . . . . . 225 | ||||
I.54. i53-allow-is-not-in-13.5.2 . . . . . . . . . . . . . . . 225 | ||||
I.55. i37-vary-and-non-existant-headers . . . . . . . . . . . 226 | ||||
I.56. i38-mismatched-vary . . . . . . . . . . . . . . . . . . 226 | ||||
I.57. i39-etag-uniqueness . . . . . . . . . . . . . . . . . . 227 | ||||
I.58. i23-no-store-invalidation . . . . . . . . . . . . . . . 227 | ||||
I.59. 14.11-content-encoding_response_vs_message . . . . . . . 228 | ||||
I.60. i80-content-location-is-not-special . . . . . . . . . . 229 | ||||
I.61. i22-etag-and-other-metadata-in-status-messages . . . . . 229 | ||||
I.62. i92-empty-host-headers . . . . . . . . . . . . . . . . . 229 | ||||
I.63. i89-if-dash-and-entities . . . . . . . . . . . . . . . . 230 | ||||
I.64. i61-redirection-vs-location . . . . . . . . . . . . . . 231 | ||||
I.65. fragment-combination . . . . . . . . . . . . . . . . . . 231 | ||||
I.66. i41-security-considerations . . . . . . . . . . . . . . 231 | ||||
I.67. i55-updating-to-rfc4288 . . . . . . . . . . . . . . . . 232 | ||||
I.68. link-header . . . . . . . . . . . . . . . . . . . . . . 232 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 248 | ||||
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 | |||
Internet Mail Extensions (MIME) [7]. | [RFC2822] 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 [RFC2821], 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 [RFC822ABNF]. 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 = %x00-1F | %x7F | |||
(octets 0 - 31) and DEL (127)> | ; (octets 0 - 31) and DEL (127) | |||
CR = <US-ASCII CR, carriage return (13)> | CR = <US-ASCII CR, carriage return (13)> | |||
LF = <US-ASCII LF, linefeed (10)> | LF = <US-ASCII LF, linefeed (10)> | |||
SP = <US-ASCII SP, space (32)> | SP = <US-ASCII SP, space (32)> | |||
HT = <US-ASCII HT, horizontal-tab (9)> | HT = <US-ASCII HT, horizontal-tab (9)> | |||
<"> = <US-ASCII double-quote mark (34)> | DQUOTE = <US-ASCII double-quote mark (34)> | |||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |||
protocol elements except the entity-body (see Appendix 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 = %x20-7E | %x80-FF | LWS | |||
but including LWS> | ; any OCTET except CTLs, but including LWS | |||
A CRLF is allowed in the definition of TEXT only as part of a header | A CRLF is allowed in the definition of TEXT only as part of a header | |||
field continuation. It is expected that the folding LWS will be | field continuation. It is expected that the folding LWS will be | |||
replaced with a single SP before interpretation of the TEXT value. | replaced with a single SP before interpretation of the TEXT value. | |||
Hexadecimal numeric characters are used in several protocol elements. | Hexadecimal numeric characters are used in several protocol elements. | |||
HEX = "A" | "B" | "C" | "D" | "E" | "F" | HEX = "A" | "B" | "C" | "D" | "E" | "F" | |||
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT | |||
Many HTTP/1.1 header field values consist of words separated by LWS | Many HTTP/1.1 header field values consist of words separated by LWS | |||
or special characters. These special characters MUST be in a quoted | or special characters. These special characters MUST be in a quoted | |||
string to be used within a parameter value (as defined in | string to be used within a parameter value (as defined in | |||
Section 3.6). | Section 3.6). | |||
token = 1*<any CHAR except CTLs or separators> | separators = "(" | ")" | "<" | ">" | "@" | |||
separators = "(" | ")" | "<" | ">" | "@" | | "," | ";" | ":" | "\" | DQUOTE | |||
| "," | ";" | ":" | "\" | <"> | | "/" | "[" | "]" | "?" | "=" | |||
| "/" | "[" | "]" | "?" | "=" | | "{" | "}" | SP | HT | |||
| "{" | "}" | SP | HT | ||||
tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*" | "+" | "-" | ||||
| "." | "^" | "_" | "`" | "|" | "~" | DIGIT | ALPHA | ||||
; any CHAR except CTLs or separators | ||||
token = 1*tchar | ||||
Comments can be included in some HTTP header fields by surrounding | Comments can be included in some HTTP header fields by surrounding | |||
the comment text with parentheses. Comments are only allowed in | the comment text with parentheses. Comments are only allowed in | |||
fields containing "comment" as part of their field value definition. | fields containing "comment" as part of their field value definition. | |||
In all other fields, parentheses are considered part of the field | In all other fields, parentheses are considered part of the field | |||
value. | value. | |||
comment = "(" *( ctext | quoted-pair | comment ) ")" | comment = "(" *( ctext | quoted-pair | comment ) ")" | |||
ctext = <any TEXT excluding "(" and ")"> | ctext = %x20-27 | %x2A-7E | %x80-FF | LWS | |||
; any TEXT excluding "(" and ")" | ||||
A string of text is parsed as a single word if it is quoted using | A string of text is parsed as a single word if it is quoted using | |||
double-quote marks. | double-quote marks. | |||
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) | quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) | |||
qdtext = <any TEXT except <">> | qdtext = %x20-21 | %x23-5B | %x5D-7E | %x80-FF | LWS | |||
; any TEXT excluding DQUOTE and "\" | ||||
The backslash character ("\") MAY be used as a single-character | The backslash character ("\") MAY be used as a single-character | |||
quoting mechanism only within quoted-string and comment constructs. | quoting mechanism only within quoted-string and comment constructs. | |||
quoted-pair = "\" CHAR | quoted-pair = "\" CHAR | |||
3. Protocol Parameters | 3. Protocol Parameters | |||
3.1. HTTP Version | 3.1. HTTP Version | |||
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions | |||
of the protocol. The protocol versioning policy is intended to allow | of the protocol. The protocol versioning policy is intended to allow | |||
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 is case-sensitive. | |||
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |||
Note that the major and minor numbers MUST be treated as separate | Note that the major and minor numbers MUST be treated as separate | |||
integers and that each MAY be incremented higher than a single digit. | integers and that each MAY be incremented higher than a single digit. | |||
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |||
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | |||
and MUST NOT be sent. | and MUST NOT be sent. | |||
An application that sends a request or response message that includes | An application that sends a request or response message that includes | |||
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant | |||
with this specification. Applications that are at least | with this specification. Applications that are at least | |||
conditionally compliant with this specification SHOULD use an HTTP- | conditionally compliant with this specification SHOULD use an HTTP- | |||
Version of "HTTP/1.1" in their messages, and MUST do so for any | Version of "HTTP/1.1" in their messages, and MUST do so for any | |||
message that is not compatible with HTTP/1.0. For more details on | message that is not compatible with HTTP/1.0. For more details on | |||
when to send specific HTTP-Version values, see 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. | |||
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", "query", and "authority" from that specification. | |||
from that specification. | ||||
absoluteURI = <absoluteURI, defined in [RFC2396], Section 3> | ||||
authority = <authority, defined in [RFC2396], Section 3.2> | ||||
path-absolute = <abs_path, defined in [RFC2396], Section 3> | ||||
port = <port, defined in [RFC2396], Section 3.2.2> | ||||
query = <query, defined in [RFC2396], Section 3.4> | ||||
relativeURI = <relativeURI, defined in [RFC2396], Section 5> | ||||
uri-host = <host, defined in [RFC2396], Section 3.2.2> | ||||
The HTTP protocol does not place any a priori limit on the length of | The HTTP protocol does not place any a priori limit on the length of | |||
a URI. Servers MUST be able to handle the URI of any resource they | a URI. Servers MUST be able to handle the URI of any resource they | |||
serve, and SHOULD be able to handle URIs of unbounded length if they | serve, and SHOULD be able to handle URIs of unbounded length if they | |||
provide GET-based forms that could generate such URIs. A server | provide GET-based forms that could generate such URIs. A server | |||
SHOULD return 414 (Request-URI Too Long) status if a URI is longer | SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |||
than the server can handle (see Section 10.4.15). | than the server can handle (see Section 10.4.15). | |||
Note: Servers ought to be cautious about depending on URI lengths | Note: Servers ought to be cautious about depending on URI lengths | |||
above 255 bytes, because some older client or proxy | above 255 bytes, because some older client or proxy | |||
implementations might not properly support these lengths. | implementations might not properly support these lengths. | |||
3.2.2. http URL | 3.2.2. http URL | |||
The "http" scheme is used to locate network resources via the HTTP | The "http" scheme is used to locate network resources via the HTTP | |||
protocol. This section defines the scheme-specific syntax and | protocol. This section defines the scheme-specific syntax and | |||
semantics for http URLs. | semantics for http URLs. | |||
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | http-URL = "http:" "//" uri-host [ ":" port ] [ path-absolute [ "?" query ]] | |||
If the port is empty or not given, port 80 is assumed. The semantics | If the port is empty or not given, port 80 is assumed. The semantics | |||
are that the identified resource is located at the server listening | are that the identified resource is located at the server listening | |||
for TCP connections on that port of that host, and the Request-URI | for TCP connections on that port of that host, and the Request-URI | |||
for the resource is abs_path (Section 5.1.2). The use of IP | for the resource is path-absolute (Section 5.1.2). The use of IP | |||
addresses in URLs SHOULD be avoided whenever possible (see 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 path-absolute is not present in the URL, it MUST | |||
as "/" when used as a Request-URI for a resource (Section 5.1.2). If | be 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 path-absolute is equivalent to an path-absolute 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 ; obsolete RFC 850 format | |||
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 other formats are described here only for | |||
the obsolete RFC 850 [12] date format and lacks a four-digit year. | compatibility with obsolete implementations. HTTP/1.1 clients and | |||
HTTP/1.1 clients and servers that parse the date value MUST accept | servers that parse the date value MUST accept all three formats (for | |||
all three formats (for compatibility with HTTP/1.0), though they MUST | compatibility with HTTP/1.0), though they MUST only generate the RFC | |||
only generate the RFC 1123 format for representing HTTP-date values | 1123 format for representing HTTP-date values in header fields. See | |||
in header fields. See Appendix A.3 for further information. | 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 | |||
abbreviation for time zone, and MUST be assumed when reading the | abbreviation for time zone, and MUST be assumed when reading the | |||
asctime format. HTTP-date is case sensitive and MUST NOT include | asctime format. HTTP-date is case sensitive and MUST NOT include | |||
additional LWS beyond that specifically included as SP in the | additional LWS beyond that specifically included as SP in the | |||
grammar. | grammar. | |||
HTTP-date = rfc1123-date | rfc850-date | asctime-date | HTTP-date = rfc1123-date ; for use in message producers | |||
rfc1123-date = wkday "," SP date1 SP time SP "GMT" | | obsolete-date ; only allowed in message parsing | |||
rfc850-date = weekday "," SP date2 SP time SP "GMT" | obsolete-date = rfc850-date | asctime-date | |||
asctime-date = wkday SP date3 SP time SP 4DIGIT | rfc1123-date = wkday "," SP date1 SP time SP "GMT" | |||
date1 = 2DIGIT SP month SP 4DIGIT | rfc850-date = weekday "," SP date2 SP time SP "GMT" | |||
; day month year (e.g., 02 Jun 1982) | asctime-date = wkday SP date3 SP time SP 4DIGIT | |||
date2 = 2DIGIT "-" month "-" 2DIGIT | date1 = 2DIGIT SP month SP 4DIGIT | |||
; day-month-year (e.g., 02-Jun-82) | ; day month year (e.g., 02 Jun 1982) | |||
date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | date2 = 2DIGIT "-" month "-" 2DIGIT | |||
; month day (e.g., Jun 2) | ; day-month-year (e.g., 02-Jun-82) | |||
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) | |||
; 00:00:00 - 23:59:59 | ; month day (e.g., Jun 2) | |||
wkday = "Mon" | "Tue" | "Wed" | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |||
| "Thu" | "Fri" | "Sat" | "Sun" | ; 00:00:00 - 23:59:59 | |||
weekday = "Monday" | "Tuesday" | "Wednesday" | wkday = "Mon" | "Tue" | "Wed" | |||
| "Thursday" | "Friday" | "Saturday" | "Sunday" | | "Thu" | "Fri" | "Sat" | "Sun" | |||
month = "Jan" | "Feb" | "Mar" | "Apr" | weekday = "Monday" | "Tuesday" | "Wednesday" | |||
| "May" | "Jun" | "Jul" | "Aug" | | "Thursday" | "Friday" | "Saturday" | "Sunday" | |||
| "Sep" | "Oct" | "Nov" | "Dec" | month = "Jan" | "Feb" | "Mar" | "Apr" | |||
| "May" | "Jun" | "Jul" | "Aug" | ||||
| "Sep" | "Oct" | "Nov" | "Dec" | ||||
Note: HTTP requirements for the date/time stamp format apply only to | Note: HTTP requirements for the date/time stamp format apply only to | |||
their usage within the protocol stream. Clients and servers are not | their usage within the protocol stream. Clients and servers are not | |||
required to use these formats for user presentation, request logging, | required to use these formats for user presentation, request logging, | |||
etc. | etc. | |||
3.3.2. Delta Seconds | 3.3.2. Delta Seconds | |||
Some HTTP header fields allow a time value to be specified as an | Some HTTP header fields allow a time value to be specified as an | |||
integer number of seconds, represented in decimal, after the time | integer number of seconds, represented in decimal, after the time | |||
that the message was received. | that the message was received. | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
3.4. Character Sets | 3.4. Character Sets | |||
HTTP uses the same definition of the term "character set" as that | HTTP uses the same definition of the term "character set" as that | |||
described for MIME: | described for MIME: | |||
The term "character set" is used in this document to refer to a | The term "character set" is used in this document to refer to a | |||
method used with one or more tables to convert a sequence of octets | method used with one or more tables to convert a sequence of octets | |||
into a sequence of characters. Note that unconditional conversion in | into a sequence of characters. Note that unconditional conversion in | |||
the other direction is not required, in that not all characters may | the other direction is not required, in that not all characters may | |||
skipping to change at page 24, line 39 ¶ | skipping to change at page 29, line 17 ¶ | |||
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 | ||||
[RFC3629] [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 30 ¶ | skipping to change at page 30, line 14 ¶ | |||
3.5. Content Codings | 3.5. Content Codings | |||
Content coding values indicate an encoding transformation that has | Content coding values indicate an encoding transformation that has | |||
been or can be applied to an entity. Content codings are primarily | been or can be applied to an entity. Content codings are primarily | |||
used to allow a document to be compressed or otherwise usefully | used to allow a document to be compressed or otherwise usefully | |||
transformed without losing the identity of its underlying media type | transformed without losing the identity of its underlying media type | |||
and without loss of information. Frequently, the entity is stored in | and without loss of information. Frequently, the entity is stored in | |||
coded form, transmitted directly, and only decoded by the recipient. | coded form, transmitted directly, and only decoded by the recipient. | |||
content-coding = token | content-coding = token | |||
All content-coding values are case-insensitive. HTTP/1.1 uses | All content-coding values are case-insensitive. HTTP/1.1 uses | |||
content-coding values in the Accept-Encoding (Section 14.3) and | content-coding values in the Accept-Encoding (Section 14.3) and | |||
Content-Encoding (Section 14.11) header fields. Although the value | Content-Encoding (Section 14.11) header fields. Although the value | |||
describes the content-coding, what is more important is that it | describes the content-coding, what is more important is that it | |||
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. | |||
3.6. Transfer Codings | 3.6. Transfer Codings | |||
Transfer-coding values are used to indicate an encoding | Transfer-coding values are used to indicate an encoding | |||
transformation that has been, can be, or may need to be applied to an | transformation that has been, can be, or may need to be applied to an | |||
entity-body in order to ensure "safe transport" through the network. | entity-body in order to ensure "safe transport" through the network. | |||
This differs from a content coding in that the transfer-coding is a | This differs from a content coding in that the transfer-coding is a | |||
property of the message, not of the original entity. | property of the message, not of the original entity. | |||
transfer-coding = "chunked" | transfer-extension | transfer-coding = "chunked" | transfer-extension | |||
transfer-extension = token *( ";" parameter ) | transfer-extension = token *( ";" parameter ) | |||
Parameters are in the form of attribute/value pairs. | Parameters are in the form of attribute/value pairs. | |||
parameter = attribute "=" value | parameter = attribute "=" value | |||
attribute = token | attribute = token | |||
value = token | quoted-string | value = token | quoted-string | |||
All transfer-coding values are case-insensitive. HTTP/1.1 uses | All transfer-coding values are case-insensitive. HTTP/1.1 uses | |||
transfer-coding values in the TE header field (Section 14.39) and in | transfer-coding values in the TE header field (Section 14.39) and in | |||
the Transfer-Encoding header field (Section 14.41). | the Transfer-Encoding header field (Section 14.41). | |||
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 (Not Implemented), 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 | |||
The chunked encoding modifies the body of a message in order to | The chunked encoding modifies the body of a message in order to | |||
transfer it as a series of chunks, each with its own size indicator, | transfer it as a series of chunks, each with its own size indicator, | |||
followed by an OPTIONAL trailer containing entity-header fields. | followed by an OPTIONAL trailer containing entity-header fields. | |||
This allows dynamically produced content to be transferred along with | This allows dynamically produced content to be transferred along with | |||
the information necessary for the recipient to verify that it has | the information necessary for the recipient to verify that it has | |||
received the full message. | received the full message. | |||
Chunked-Body = *chunk | Chunked-Body = *chunk | |||
last-chunk | last-chunk | |||
trailer | trailer-part | |||
CRLF | CRLF | |||
chunk = chunk-size [ chunk-extension ] CRLF | chunk = chunk-size [ chunk-extension ] CRLF | |||
chunk-data CRLF | chunk-data CRLF | |||
chunk-size = 1*HEX | chunk-size = 1*HEX | |||
last-chunk = 1*("0") [ chunk-extension ] CRLF | last-chunk = 1*("0") [ chunk-extension ] CRLF | |||
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token | quoted-string | chunk-ext-val = token | quoted-string | |||
chunk-data = chunk-size(OCTET) | ||||
trailer = *(entity-header CRLF) | chunk-data = 1*OCTET ; a sequence of chunk-size octets | |||
trailer-part = *(entity-header CRLF) | ||||
The chunk-size field is a string of hex digits indicating the size of | The chunk-size field is a string of hex digits indicating the size of | |||
the chunk. 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 29 ¶ | |||
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 [RFC2046] in the Content-Type | |||
(Section 14.17) and Accept (Section 14.1) header fields in order to | (Section 14.17) and Accept (Section 14.1) header fields in order to | |||
provide open and extensible data typing and type negotiation. | provide open and extensible data typing and type negotiation. | |||
media-type = type "/" subtype *( ";" parameter ) | media-type = type "/" subtype *( ";" parameter ) | |||
type = token | type = token | |||
subtype = token | subtype = token | |||
Parameters MAY follow the type/subtype in the form of attribute/value | Parameters MAY follow the type/subtype in the form of attribute/value | |||
pairs (as defined in Section 3.6). | pairs (as defined in Section 3.6). | |||
The type, subtype, and parameter attribute names are case- | The type, subtype, and parameter attribute names are case- | |||
insensitive. Parameter values might or might not be case-sensitive, | insensitive. Parameter values might or might not be case-sensitive, | |||
depending on the semantics of the parameter name. Linear white space | depending on the semantics of the parameter name. Linear white space | |||
(LWS) MUST NOT be used between the type and subtype, nor between an | (LWS) MUST NOT be used between the type and subtype, nor between an | |||
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 | [RFC4288]. 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 9 ¶ | |||
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 [RFC2388]. | |||
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. | |||
product = token ["/" product-version] | product = token ["/" product-version] | |||
product-version = token | product-version = token | |||
Examples: | Examples: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
Server: Apache/0.8.4 | Server: Apache/0.8.4 | |||
Product tokens SHOULD be short and to the point. They MUST NOT be | Product tokens SHOULD be short and to the point. They MUST NOT be | |||
used for advertising or other non-essential information. Although | used for advertising or other non-essential information. Although | |||
any token character MAY appear in a product-version, this token | any token character MAY appear in a product-version, this token | |||
SHOULD only be used for a version identifier (i.e., successive | SHOULD only be used for a version identifier (i.e., successive | |||
skipping to change at page 31, line 50 ¶ | skipping to change at page 36, line 27 ¶ | |||
HTTP content negotiation (Section 12) uses short "floating point" | HTTP content negotiation (Section 12) uses short "floating point" | |||
numbers to indicate the relative importance ("weight") of various | numbers to indicate the relative importance ("weight") of various | |||
negotiable parameters. A weight is normalized to a real number in | negotiable parameters. A weight is normalized to a real number in | |||
the range 0 through 1, where 0 is the minimum and 1 the maximum | the range 0 through 1, where 0 is the minimum and 1 the maximum | |||
value. If a parameter has a quality value of 0, then content with | value. If a parameter has a quality value of 0, then content with | |||
this parameter is `not acceptable' for the client. HTTP/1.1 | this parameter is `not acceptable' for the client. HTTP/1.1 | |||
applications MUST NOT generate more than three digits after the | applications MUST NOT generate more than three digits after the | |||
decimal point. User configuration of these values SHOULD also be | decimal point. User configuration of these values SHOULD also be | |||
limited in this fashion. | limited in this fashion. | |||
qvalue = ( "0" [ "." 0*3DIGIT ] ) | qvalue = ( "0" [ "." 0*3DIGIT ] ) | |||
| ( "1" [ "." 0*3("0") ] ) | | ( "1" [ "." 0*3("0") ] ) | |||
"Quality values" is a misnomer, since these values merely represent | "Quality values" is a misnomer, since these values merely represent | |||
relative degradation in desired quality. | relative degradation in desired quality. | |||
3.10. Language Tags | 3.10. Language Tags | |||
A language tag identifies a natural language spoken, written, or | A language tag identifies a natural language spoken, written, or | |||
otherwise conveyed by human beings for communication of information | otherwise conveyed by human beings for communication of information | |||
to other human beings. Computer languages are explicitly excluded. | to other human beings. Computer languages are explicitly excluded. | |||
HTTP uses language tags within the Accept-Language and Content- | HTTP uses language tags within the Accept-Language and Content- | |||
Language fields. | Language fields. | |||
The syntax and registry of HTTP language tags is the same as that | The syntax and registry of HTTP language tags is defined by | |||
defined by RFC 1766 [1]. In summary, a language tag is composed of 1 | [RFC4646]: | |||
or more parts: A primary language tag and a possibly empty series of | ||||
subtags: | ||||
language-tag = primary-tag *( "-" subtag ) | Language-Tag = <defined in [RFC4646], Section 2.1> | |||
primary-tag = 1*8ALPHA | ||||
subtag = 1*8ALPHA | ||||
White space is not allowed within the tag and all tags are case- | White space is not allowed within the tag and all tags are case- | |||
insensitive. The name space of language tags is administered by the | insensitive. The name space of language tags is administered by the | |||
IANA. Example tags include: | IANA. Example tags include: | |||
en, en-US, en-cockney, i-cherokee, x-pig-latin | en, en-US, en-cockney, i-cherokee, x-pig-latin | |||
where any two-letter primary-tag is an ISO-639 language abbreviation | where any two-letter primary-tag is an ISO-639 language abbreviation | |||
and any two-letter initial subtag is an ISO-3166 country code. (The | and any two-letter initial subtag is an ISO-3166 country code. (The | |||
last three tags above are not registered tags; all but the last are | last three tags above are not registered tags; all but the last are | |||
skipping to change at page 32, line 46 ¶ | skipping to change at page 37, line 18 ¶ | |||
3.11. Entity Tags | 3.11. Entity Tags | |||
Entity tags are used for comparing two or more entities from the same | Entity tags are used for comparing two or more entities from the same | |||
requested resource. HTTP/1.1 uses entity tags in the ETag | requested resource. HTTP/1.1 uses entity tags in the ETag | |||
(Section 14.19), If-Match (Section 14.24), If-None-Match | (Section 14.19), If-Match (Section 14.24), If-None-Match | |||
(Section 14.26), and If-Range (Section 14.27) header fields. The | (Section 14.26), and If-Range (Section 14.27) header fields. The | |||
definition of how they are used and compared as cache validators is | definition of how they are used and compared as cache validators is | |||
in Section 13.3.3. An entity tag consists of an opaque quoted | in Section 13.3.3. An entity tag consists of an opaque quoted | |||
string, possibly prefixed by a weakness indicator. | string, possibly prefixed by a weakness indicator. | |||
entity-tag = [ weak ] opaque-tag | entity-tag = [ weak ] opaque-tag | |||
weak = "W/" | weak = "W/" | |||
opaque-tag = quoted-string | opaque-tag = quoted-string | |||
A "strong entity tag" MAY be shared by two entities of a resource | A "strong entity tag" MAY be shared by two entities of a resource | |||
only if they are equivalent by octet equality. | only if they are equivalent by octet equality. | |||
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by | A "weak entity tag," indicated by the "W/" prefix, MAY be shared by | |||
two entities of a resource only if the entities are equivalent and | two entities of a resource only if the entities are equivalent and | |||
could be substituted for each other with no significant change in | could be substituted for each other with no significant change in | |||
semantics. A weak entity tag can only be used for weak comparison. | semantics. A weak entity tag can only be used for weak comparison. | |||
An entity tag MUST be unique across all versions of all entities | An entity tag MUST be unique across all versions of all entities | |||
skipping to change at page 33, line 25 ¶ | skipping to change at page 37, line 45 ¶ | |||
entities. | entities. | |||
3.12. Range Units | 3.12. Range Units | |||
HTTP/1.1 allows a client to request that only part (a range of) the | HTTP/1.1 allows a client to request that only part (a range of) the | |||
response entity be included within the response. HTTP/1.1 uses range | response entity be included within the response. HTTP/1.1 uses range | |||
units in the Range (Section 14.35) and Content-Range (Section 14.16) | units in the Range (Section 14.35) and Content-Range (Section 14.16) | |||
header fields. An entity can be broken down into subranges according | header fields. An entity can be broken down into subranges according | |||
to various structural units. | to various structural units. | |||
range-unit = bytes-unit | other-range-unit | range-unit = bytes-unit | other-range-unit | |||
bytes-unit = "bytes" | bytes-unit = "bytes" | |||
other-range-unit = token | other-range-unit = token | |||
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 | |||
implementations MAY ignore ranges specified using other units. | implementations MAY ignore ranges specified using other units. | |||
HTTP/1.1 has been designed to allow implementations of applications | HTTP/1.1 has been designed to allow implementations of applications | |||
that do not depend on knowledge of ranges. | that do not depend on knowledge of ranges. | |||
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 [RFC2822] 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, | |||
if the server is reading the protocol stream at the beginning of a | if the server is reading the protocol stream at the beginning of a | |||
message and receives a CRLF first, it should ignore the CRLF. | message and receives a CRLF first, it should ignore the CRLF. | |||
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 2.1 of [RFC2822]. Each header field consists | |||
of a name followed by a colon (":") and the field value. Field names | of 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 | |||
field-value = *( field-content | LWS ) | field-value = *( field-content | LWS ) | |||
field-content = <the OCTETs making up the field-value | field-content = <field content> | |||
and consisting of either *TEXT or combinations | ; the OCTETs making up the field-value | |||
of token, separators, and quoted-string> | ; and consisting of either *TEXT or combinations | |||
; of token, separators, and quoted-string | ||||
The field-content does not include any leading or trailing LWS: | The field-content does not include any leading or trailing LWS: | |||
linear white space occurring before the first non-whitespace | linear white space occurring before the first non-whitespace | |||
character of the field-value or after the last non-whitespace | character of the field-value or after the last non-whitespace | |||
character of the field-value. Such leading or trailing LWS MAY be | character of the field-value. Such leading or trailing LWS MAY be | |||
removed without changing the semantics of the field value. Any LWS | removed without changing the semantics of the field value. Any LWS | |||
that occurs between field-content MAY be replaced with a single SP | that occurs between field-content MAY be replaced with a single SP | |||
before interpreting the field value or forwarding the message | before interpreting the field value or forwarding the message | |||
downstream. | downstream. | |||
skipping to change at page 35, line 45 ¶ | skipping to change at page 40, line 46 ¶ | |||
change the order of these field values when a message is forwarded. | change the order of these field values when a message is forwarded. | |||
4.3. Message Body | 4.3. Message Body | |||
The message-body (if any) of an HTTP message is used to carry the | The message-body (if any) of an HTTP message is used to carry the | |||
entity-body associated with the request or response. The message- | entity-body associated with the request or response. The message- | |||
body differs from the entity-body only when a transfer-coding has | body differs from the entity-body only when a transfer-coding has | |||
been applied, as indicated by the Transfer-Encoding header field | been applied, as indicated by the Transfer-Encoding header field | |||
(Section 14.41). | (Section 14.41). | |||
message-body = entity-body | message-body = entity-body | |||
| <entity-body encoded as per Transfer-Encoding> | | <entity-body encoded as per Transfer-Encoding> | |||
Transfer-Encoding MUST be used to indicate any transfer-codings | Transfer-Encoding MUST be used to indicate any transfer-codings | |||
applied by an application to ensure safe and proper transfer of the | applied by an application to ensure safe and proper transfer of the | |||
message. Transfer-Encoding is a property of the message, not of the | message. Transfer-Encoding is a property of the message, not of the | |||
entity, and thus MAY be added or removed by any application along the | entity, and thus MAY be added or removed by any application along the | |||
request/response chain. (However, Section 3.6 places restrictions on | request/response chain. (However, Section 3.6 places restrictions on | |||
when certain transfer-codings may be used.) | when certain transfer-codings may be used.) | |||
The rules for when a message-body is allowed in a message differ for | The rules for when a message-body is allowed in a message differ for | |||
requests and responses. | requests and responses. | |||
skipping to change at page 36, line 23 ¶ | skipping to change at page 41, line 25 ¶ | |||
(Section 5.1.1) does not allow sending an entity-body in requests. A | (Section 5.1.1) does not allow sending an entity-body in requests. A | |||
server SHOULD read and forward a message-body on any request; if the | server SHOULD read and forward a message-body on any request; if the | |||
request method does not include defined semantics for an entity-body, | request method does not include defined semantics for an entity-body, | |||
then the message-body SHOULD be ignored when handling the request. | then the message-body SHOULD be ignored when handling the request. | |||
For response messages, whether or not a message-body is included with | For response messages, whether or not a message-body is included with | |||
a message is dependent on both the request method and the response | a message is dependent on both the request method and the response | |||
status code (Section 6.1.1). All responses to the HEAD request | status code (Section 6.1.1). All responses to the HEAD request | |||
method MUST NOT include a message-body, even though the presence of | method MUST NOT include a message-body, even though the presence of | |||
entity-header fields might lead one to believe they do. All 1xx | entity-header fields might lead one to believe they do. All 1xx | |||
(informational), 204 (no content), and 304 (not modified) responses | (informational), 204 (No Content), and 304 (Not Modified) responses | |||
MUST NOT include a message-body. All other responses do include a | MUST NOT include a message-body. All other responses do include a | |||
message-body, although it MAY be of zero length. | message-body, although it MAY be of zero length. | |||
4.4. Message Length | 4.4. Message Length | |||
The transfer-length of a message is the length of the message-body as | The transfer-length of a message is the length of the message-body as | |||
it appears in the message; that is, after any transfer-codings have | it appears in the message; that is, after any transfer-codings have | |||
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.) | |||
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests | |||
containing a message-body MUST include a valid Content-Length header | containing a message-body MUST include a valid Content-Length header | |||
field unless the server is known to be HTTP/1.1 compliant. If a | field unless the server is known to be HTTP/1.1 compliant. If a | |||
request contains a message-body and a Content-Length is not given, | request contains a message-body and a Content-Length is not given, | |||
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 | |||
entity being transferred. These header fields apply only to the | entity being transferred. These header fields apply only to the | |||
message being transmitted. | message being transmitted. | |||
general-header = Cache-Control ; Section 14.9 | general-header = Cache-Control ; Section 14.9 | |||
| Connection ; Section 14.10 | | Connection ; Section 14.10 | |||
| Date ; Section 14.18 | | Date ; Section 14.18 | |||
| Pragma ; Section 14.32 | | Pragma ; Section 14.32 | |||
| Trailer ; Section 14.40 | | Trailer ; Section 14.40 | |||
| Transfer-Encoding ; Section 14.41 | | Transfer-Encoding ; Section 14.41 | |||
| Upgrade ; Section 14.42 | | Upgrade ; Section 14.42 | |||
| Via ; Section 14.45 | | Via ; Section 14.45 | |||
| Warning ; Section 14.46 | | Warning ; Section 14.46 | |||
General-header field names can be extended reliably only in | General-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields may be given the semantics of general | experimental header fields may be given the semantics of general | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be general-header fields. Unrecognized header fields are treated as | be general-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
5. Request | 5. Request | |||
A request message from a client to a server includes, within the | A request message from a client to a server includes, within the | |||
first line of that message, the method to be applied to the resource, | first line of that message, the method to be applied to the resource, | |||
the identifier of the resource, and the protocol version in use. | the identifier of the resource, and the protocol version in use. | |||
Request = Request-Line ; Section 5.1 | Request = Request-Line ; Section 5.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 4.5 | |||
| request-header ; Section 5.3 | | request-header ; Section 5.3 | |||
| entity-header ) CRLF) ; Section 7.1 | | entity-header ) CRLF) ; Section 7.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 4.3 | [ message-body ] ; Section 4.3 | |||
5.1. Request-Line | 5.1. Request-Line | |||
The Request-Line begins with a method token, followed by the Request- | The Request-Line begins with a method token, followed by the Request- | |||
URI and the protocol version, and ending with CRLF. The elements are | URI and the protocol version, and ending with CRLF. The elements are | |||
separated by SP characters. No CR or LF is allowed except in the | separated by SP characters. No CR or LF is allowed except in the | |||
final CRLF sequence. | final CRLF sequence. | |||
Request-Line = Method SP Request-URI SP HTTP-Version CRLF | Request-Line = Method SP Request-URI SP HTTP-Version CRLF | |||
5.1.1. Method | 5.1.1. Method | |||
The Method token indicates the method to be performed on the resource | The Method token indicates the method to be performed on the resource | |||
identified by the Request-URI. The method is case-sensitive. | identified by the Request-URI. The method is case-sensitive. | |||
Method = "OPTIONS" ; Section 9.2 | Method = "OPTIONS" ; Section 9.2 | |||
| "GET" ; Section 9.3 | | "GET" ; Section 9.3 | |||
| "HEAD" ; Section 9.4 | | "HEAD" ; Section 9.4 | |||
| "POST" ; Section 9.5 | | "POST" ; Section 9.5 | |||
| "PUT" ; Section 9.6 | | "PUT" ; Section 9.6 | |||
| "DELETE" ; Section 9.7 | | "DELETE" ; Section 9.7 | |||
| "TRACE" ; Section 9.8 | | "TRACE" ; Section 9.8 | |||
| "CONNECT" ; Section 9.9 | | "CONNECT" ; Section 9.9 | |||
| extension-method | | extension-method | |||
extension-method = token | extension-method = token | |||
The list of methods allowed by a resource can be specified in an | The list of methods allowed by a resource can be specified in an | |||
Allow header field (Section 14.7). The return code of the response | Allow header field (Section 14.7). The return code of the response | |||
always notifies the client whether a method is currently allowed on a | always notifies the client whether a method is currently allowed on a | |||
resource, since the set of allowed methods can change dynamically. | resource, since the set of allowed methods can change dynamically. | |||
An origin server SHOULD return the status code 405 (Method Not | An origin server SHOULD return the status code 405 (Method Not | |||
Allowed) if the method is known by the origin server but not allowed | Allowed) if the method is known by the origin server but not allowed | |||
for the requested resource, and 501 (Not Implemented) if the method | for the requested resource, and 501 (Not Implemented) if the method | |||
is unrecognized or not implemented by the origin server. The methods | is unrecognized or not implemented by the origin server. The methods | |||
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 | ||||
| path-absolute [ "?" 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, path- | |||
the Request-URI, and the network location of the URI (authority) MUST | absolute) as the Request-URI, and the network location of the URI | |||
be transmitted in a Host header field. For example, a client wishing | (authority) MUST be transmitted in a Host header field. For example, | |||
to retrieve the resource above directly from the origin server would | a client wishing to retrieve the resource above directly from the | |||
create a TCP connection to port 80 of the host "www.w3.org" and send | origin server would create a TCP connection to port 80 of the host | |||
the lines: | "www.example.org" and send the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.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 "path-absolute" part of the | |||
received Request-URI when forwarding it to the next inbound server, | received Request-URI when forwarding it to the next inbound server, | |||
except as noted above to replace a null abs_path with "/". | except as noted above to replace a null path-absolute with "/". | |||
Note: The "no rewrite" rule prevents the proxy from changing the | Note: The "no rewrite" rule prevents the proxy from changing the | |||
meaning of the request when the origin server is improperly using | meaning of the request when the origin server is improperly using | |||
a non-reserved URI character for a reserved purpose. Implementors | a non-reserved URI character for a reserved purpose. Implementors | |||
should be aware that some pre-HTTP/1.1 proxies have been known to | should be aware that some pre-HTTP/1.1 proxies have been known to | |||
rewrite the Request-URI. | rewrite the Request-URI. | |||
5.2. The Resource Identified by a Request | 5.2. The Resource Identified by a Request | |||
The exact resource identified by an Internet request is determined by | The exact resource identified by an Internet request is determined by | |||
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 42, line 16 ¶ | skipping to change at page 47, line 19 ¶ | |||
exact resource is being requested. | exact resource is being requested. | |||
5.3. Request Header Fields | 5.3. Request Header Fields | |||
The request-header fields allow the client to pass additional | The request-header fields allow the client to pass additional | |||
information about the request, and about the client itself, to the | information about the request, and about the client itself, to the | |||
server. These fields act as request modifiers, with semantics | server. These fields act as request modifiers, with semantics | |||
equivalent to the parameters on a programming language method | equivalent to the parameters on a programming language method | |||
invocation. | invocation. | |||
request-header = Accept ; Section 14.1 | request-header = Accept ; Section 14.1 | |||
| Accept-Charset ; Section 14.2 | | Accept-Charset ; Section 14.2 | |||
| Accept-Encoding ; Section 14.3 | | Accept-Encoding ; Section 14.3 | |||
| Accept-Language ; Section 14.4 | | Accept-Language ; Section 14.4 | |||
| Authorization ; Section 14.8 | | Authorization ; Section 14.8 | |||
| Expect ; Section 14.20 | | Expect ; Section 14.20 | |||
| From ; Section 14.22 | | From ; Section 14.22 | |||
| Host ; Section 14.23 | | Host ; Section 14.23 | |||
| If-Match ; Section 14.24 | | If-Match ; Section 14.24 | |||
| If-Modified-Since ; Section 14.25 | | If-Modified-Since ; Section 14.25 | |||
| If-None-Match ; Section 14.26 | | If-None-Match ; Section 14.26 | |||
| If-Range ; Section 14.27 | | If-Range ; Section 14.27 | |||
| If-Unmodified-Since ; Section 14.28 | | If-Unmodified-Since ; Section 14.28 | |||
| Max-Forwards ; Section 14.31 | | Max-Forwards ; Section 14.31 | |||
| Proxy-Authorization ; Section 14.34 | | Proxy-Authorization ; Section 14.34 | |||
| Range ; Section 14.35 | | Range ; Section 14.35 | |||
| Referer ; Section 14.36 | | Referer ; Section 14.36 | |||
| TE ; Section 14.39 | | TE ; Section 14.39 | |||
| User-Agent ; Section 14.43 | | User-Agent ; Section 14.43 | |||
Request-header field names can be extended reliably only in | Request-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of request- | experimental header fields MAY be given the semantics of request- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be request-header fields. Unrecognized header fields are treated as | be request-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
6. Response | 6. Response | |||
After receiving and interpreting a request message, a server responds | After receiving and interpreting a request message, a server responds | |||
with an HTTP response message. | with an HTTP response message. | |||
Response = Status-Line ; Section 6.1 | Response = Status-Line ; Section 6.1 | |||
*(( general-header ; Section 4.5 | *(( general-header ; Section 4.5 | |||
| response-header ; Section 6.2 | | response-header ; Section 6.2 | |||
| entity-header ) CRLF) ; Section 7.1 | | entity-header ) CRLF) ; Section 7.1 | |||
CRLF | CRLF | |||
[ message-body ] ; Section 7.2 | [ message-body ] ; Section 7.2 | |||
6.1. Status-Line | 6.1. Status-Line | |||
The first line of a Response message is the Status-Line, consisting | The first line of a Response message is the Status-Line, consisting | |||
of the protocol version followed by a numeric status code and its | of the protocol version followed by a numeric status code and its | |||
associated textual phrase, with each element separated by SP | associated textual phrase, with each element separated by SP | |||
characters. No CR or LF is allowed except in the final CRLF | characters. No CR or LF is allowed except in the final CRLF | |||
sequence. | sequence. | |||
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF | |||
6.1.1. Status Code and Reason Phrase | 6.1.1. Status Code and Reason Phrase | |||
The Status-Code element is a 3-digit integer result code of the | The Status-Code element is a 3-digit integer result code of the | |||
attempt to understand and satisfy the request. These codes are fully | attempt to understand and satisfy the request. These codes are fully | |||
defined in Section 10. The Reason-Phrase is intended to give a short | defined in Section 10. The Reason-Phrase is intended to give a short | |||
textual description of the Status-Code. The Status-Code is intended | textual description of the Status-Code. The Status-Code is intended | |||
for use by automata and the Reason-Phrase is intended for the human | for use by automata and the Reason-Phrase is intended for the human | |||
user. The client is not required to examine or display the Reason- | user. The client is not required to examine or display the Reason- | |||
Phrase. | Phrase. | |||
skipping to change at page 45, line 5 ¶ | skipping to change at page 50, line 5 ¶ | |||
o 5xx: Server Error - The server failed to fulfill an apparently | o 5xx: Server Error - The server failed to fulfill an apparently | |||
valid request | valid request | |||
The individual values of the numeric status codes defined for | The individual values of the numeric status codes defined for | |||
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | |||
presented below. The reason phrases listed here are only | presented below. The reason phrases listed here are only | |||
recommendations -- they MAY be replaced by local equivalents without | recommendations -- they MAY be replaced by local equivalents without | |||
affecting the protocol. | affecting the protocol. | |||
Status-Code = | Status-Code = | |||
"100" ; Section 10.1.1: Continue | "100" ; Section 10.1.1: Continue | |||
| "101" ; Section 10.1.2: Switching Protocols | | "101" ; Section 10.1.2: Switching Protocols | |||
| "200" ; Section 10.2.1: OK | | "200" ; Section 10.2.1: OK | |||
| "201" ; Section 10.2.2: Created | | "201" ; Section 10.2.2: Created | |||
| "202" ; Section 10.2.3: Accepted | | "202" ; Section 10.2.3: Accepted | |||
| "203" ; Section 10.2.4: Non-Authoritative Information | | "203" ; Section 10.2.4: Non-Authoritative Information | |||
| "204" ; Section 10.2.5: No Content | | "204" ; Section 10.2.5: No Content | |||
| "205" ; Section 10.2.6: Reset Content | | "205" ; Section 10.2.6: Reset Content | |||
| "206" ; Section 10.2.7: Partial Content | | "206" ; Section 10.2.7: Partial Content | |||
| "300" ; Section 10.3.1: Multiple Choices | | "300" ; Section 10.3.1: Multiple Choices | |||
| "301" ; Section 10.3.2: Moved Permanently | | "301" ; Section 10.3.2: Moved Permanently | |||
| "302" ; Section 10.3.3: Found | | "302" ; Section 10.3.3: Found | |||
| "303" ; Section 10.3.4: See Other | | "303" ; Section 10.3.4: See Other | |||
| "304" ; Section 10.3.5: Not Modified | | "304" ; Section 10.3.5: Not Modified | |||
| "305" ; Section 10.3.6: Use Proxy | | "305" ; Section 10.3.6: Use Proxy | |||
| "307" ; Section 10.3.8: Temporary Redirect | | "307" ; Section 10.3.8: Temporary Redirect | |||
| "400" ; Section 10.4.1: Bad Request | | "400" ; Section 10.4.1: Bad Request | |||
| "401" ; Section 10.4.2: Unauthorized | | "401" ; Section 10.4.2: Unauthorized | |||
| "402" ; Section 10.4.3: Payment Required | | "402" ; Section 10.4.3: Payment Required | |||
| "403" ; Section 10.4.4: Forbidden | | "403" ; Section 10.4.4: Forbidden | |||
| "404" ; Section 10.4.5: Not Found | | "404" ; Section 10.4.5: Not Found | |||
| "405" ; Section 10.4.6: Method Not Allowed | | "405" ; Section 10.4.6: Method Not Allowed | |||
| "406" ; Section 10.4.7: Not Acceptable | | "406" ; Section 10.4.7: Not Acceptable | |||
| "407" ; Section 10.4.8: Proxy Authentication Required | | "407" ; Section 10.4.8: Proxy Authentication Required | |||
| "408" ; Section 10.4.9: Request Time-out | | "408" ; Section 10.4.9: Request Time-out | |||
| "409" ; Section 10.4.10: Conflict | | "409" ; Section 10.4.10: Conflict | |||
| "410" ; Section 10.4.11: Gone | | "410" ; Section 10.4.11: Gone | |||
| "411" ; Section 10.4.12: Length Required | | "411" ; Section 10.4.12: Length Required | |||
| "412" ; Section 10.4.13: Precondition Failed | | "412" ; Section 10.4.13: Precondition Failed | |||
| "413" ; Section 10.4.14: Request Entity Too Large | | "413" ; Section 10.4.14: Request Entity Too Large | |||
| "414" ; Section 10.4.15: Request-URI Too Large | | "414" ; Section 10.4.15: Request-URI Too Large | |||
| "415" ; Section 10.4.16: Unsupported Media Type | | "415" ; Section 10.4.16: Unsupported Media Type | |||
| "416" ; Section 10.4.17: Requested range not satisfiable | | "416" ; Section 10.4.17: Requested range not satisfiable | |||
| "417" ; Section 10.4.18: Expectation Failed | | "417" ; Section 10.4.18: Expectation Failed | |||
| "500" ; Section 10.5.1: Internal Server Error | | "500" ; Section 10.5.1: Internal Server Error | |||
| "501" ; Section 10.5.2: Not Implemented | | "501" ; Section 10.5.2: Not Implemented | |||
| "502" ; Section 10.5.3: Bad Gateway | | "502" ; Section 10.5.3: Bad Gateway | |||
| "503" ; Section 10.5.4: Service Unavailable | | "503" ; Section 10.5.4: Service Unavailable | |||
| "504" ; Section 10.5.5: Gateway Time-out | | "504" ; Section 10.5.5: Gateway Time-out | |||
| "505" ; Section 10.5.6: HTTP Version not supported | | "505" ; Section 10.5.6: HTTP Version not supported | |||
| extension-code | | extension-code | |||
extension-code = 3DIGIT | extension-code = 3DIGIT | |||
Reason-Phrase = *<TEXT, excluding CR, LF> | Reason-Phrase = *( HT | %x20-7E | %x80-FF ) | |||
HTTP status codes are extensible. HTTP applications are not required | HTTP status codes are extensible. HTTP applications are not required | |||
to understand the meaning of all registered status codes, though such | to understand the meaning of all registered status codes, though such | |||
understanding is obviously desirable. However, applications MUST | understanding is obviously desirable. However, applications MUST | |||
understand the class of any status code, as indicated by the first | understand the class of any status code, as indicated by the first | |||
digit, and treat any unrecognized response as being equivalent to the | digit, and treat any unrecognized response as being equivalent to the | |||
x00 status code of that class, with the exception that an | x00 status code of that class, with the exception that an | |||
unrecognized response MUST NOT be cached. For example, if an | unrecognized response MUST NOT be cached. For example, if an | |||
unrecognized status code of 431 is received by the client, it can | unrecognized status code of 431 is received by the client, it can | |||
safely assume that there was something wrong with its request and | safely assume that there was something wrong with its request and | |||
skipping to change at page 46, line 23 ¶ | skipping to change at page 51, line 23 ¶ | |||
with the response, since that entity is likely to include human- | with the response, since that entity is likely to include human- | |||
readable information which will explain the unusual status. | readable information which will explain the unusual status. | |||
6.2. Response Header Fields | 6.2. Response Header Fields | |||
The response-header fields allow the server to pass additional | The response-header fields allow the server to pass additional | |||
information about the response which cannot be placed in the Status- | information about the response which cannot be placed in the Status- | |||
Line. These header fields give information about the server and | Line. These header fields give information about the server and | |||
about further access to the resource identified by the Request-URI. | about further access to the resource identified by the Request-URI. | |||
response-header = Accept-Ranges ; Section 14.5 | response-header = Accept-Ranges ; Section 14.5 | |||
| Age ; Section 14.6 | | Age ; Section 14.6 | |||
| ETag ; Section 14.19 | | ETag ; Section 14.19 | |||
| Location ; Section 14.30 | | Location ; Section 14.30 | |||
| Proxy-Authenticate ; Section 14.33 | | Proxy-Authenticate ; Section 14.33 | |||
| Retry-After ; Section 14.37 | | Retry-After ; Section 14.37 | |||
| Server ; Section 14.38 | | Server ; Section 14.38 | |||
| Vary ; Section 14.44 | | Vary ; Section 14.44 | |||
| WWW-Authenticate ; Section 14.47 | | WWW-Authenticate ; Section 14.47 | |||
Response-header field names can be extended reliably only in | Response-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of response- | experimental header fields MAY be given the semantics of response- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be response-header fields. Unrecognized header fields are treated as | be response-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
7. Entity | 7. Entity | |||
skipping to change at page 47, line 22 ¶ | skipping to change at page 52, line 22 ¶ | |||
In this section, both sender and recipient refer to either the client | In this section, both sender and recipient refer to either the client | |||
or the server, depending on who sends and who receives the entity. | or the server, depending on who sends and who receives the entity. | |||
7.1. Entity Header Fields | 7.1. Entity Header Fields | |||
Entity-header fields define metainformation about the entity-body or, | Entity-header fields define metainformation about the entity-body or, | |||
if no body is present, about the resource identified by the request. | if no body is present, about the resource identified by the request. | |||
Some of this metainformation is OPTIONAL; some might be REQUIRED by | Some of this metainformation is OPTIONAL; some might be REQUIRED by | |||
portions of this specification. | portions of this specification. | |||
entity-header = Allow ; Section 14.7 | entity-header = Allow ; Section 14.7 | |||
| Content-Encoding ; Section 14.11 | | Content-Encoding ; Section 14.11 | |||
| Content-Language ; Section 14.12 | | Content-Language ; Section 14.12 | |||
| Content-Length ; Section 14.13 | | Content-Length ; Section 14.13 | |||
| Content-Location ; Section 14.14 | | Content-Location ; Section 14.14 | |||
| Content-MD5 ; Section 14.15 | | Content-MD5 ; Section 14.15 | |||
| Content-Range ; Section 14.16 | | Content-Range ; Section 14.16 | |||
| Content-Type ; Section 14.17 | | Content-Type ; Section 14.17 | |||
| Expires ; Section 14.21 | | Expires ; Section 14.21 | |||
| Last-Modified ; Section 14.29 | | Last-Modified ; Section 14.29 | |||
| extension-header | | extension-header | |||
extension-header = message-header | extension-header = message-header | |||
The extension-header mechanism allows additional entity-header fields | The extension-header mechanism allows additional entity-header fields | |||
to be defined without changing the protocol, but these fields cannot | to be defined without changing the protocol, but these fields cannot | |||
be assumed to be recognizable by the recipient. Unrecognized header | be assumed to be recognizable by the recipient. Unrecognized header | |||
fields SHOULD be ignored by the recipient and MUST be forwarded by | fields SHOULD be ignored by the recipient and MUST be forwarded by | |||
transparent proxies. | transparent proxies. | |||
7.2. Entity Body | 7.2. Entity Body | |||
The entity-body (if any) sent with an HTTP request or response is in | The entity-body (if any) sent with an HTTP request or response is in | |||
a format and encoding defined by the entity-header fields. | a format and encoding defined by the entity-header fields. | |||
entity-body = *OCTET | entity-body = *OCTET | |||
An entity-body is only present in a message when a message-body is | An entity-body is only present in a message when a message-body is | |||
present, as described in Section 4.3. The entity-body is obtained | present, as described in Section 4.3. The entity-body is obtained | |||
from the message-body by decoding any Transfer-Encoding that might | from the message-body by decoding any Transfer-Encoding that might | |||
have been applied to ensure safe and proper transfer of the message. | have been applied to ensure safe and proper transfer of the message. | |||
7.2.1. Type | 7.2.1. Type | |||
When an entity-body is included with a message, the data type of that | When an entity-body is included with a message, the data type of that | |||
body is determined via the header fields Content-Type and Content- | body is determined via the header fields Content-Type and Content- | |||
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 | |||
header (see Section 14.30). | header (see Section 14.30). | |||
Responses to this method are not cacheable, unless the response | Responses to this method are not cacheable, unless the response | |||
includes appropriate Cache-Control or Expires header fields. | includes appropriate Cache-Control or Expires header fields. | |||
However, the 303 (See Other) response can be used to direct the user | However, the 303 (See Other) response can be used to direct the user | |||
agent to retrieve a cacheable resource. | agent to retrieve a cacheable resource. | |||
POST requests MUST obey the message transmission requirements set out | ||||
in Section 8.2. | ||||
See Section 15.1.3 for security considerations. | ||||
9.6. PUT | 9.6. PUT | |||
The PUT method requests that the enclosed entity be stored under the | The PUT method requests that the enclosed entity be stored under the | |||
supplied Request-URI. If the Request-URI refers to an already | supplied Request-URI. If the Request-URI refers to an already | |||
existing resource, the enclosed entity SHOULD be considered as a | existing resource, the enclosed entity SHOULD be considered as a | |||
modified version of the one residing on the origin server. If the | modified version of the one residing on the origin server. If the | |||
Request-URI does not point to an existing resource, and that URI is | Request-URI does not point to an existing resource, and that URI is | |||
capable of being defined as a new resource by the requesting user | capable of being defined as a new resource by the requesting user | |||
agent, the origin server can create the resource with that URI. If a | agent, the origin server can create the resource with that URI. If a | |||
new resource is created, the origin server MUST inform the user agent | new resource is created, the origin server MUST inform the user agent | |||
skipping to change at page 61, line 8 ¶ | skipping to change at page 65, line 46 ¶ | |||
A single resource MAY be identified by many different URIs. For | A single resource MAY be identified by many different URIs. For | |||
example, an article might have a URI for identifying "the current | example, an article might have a URI for identifying "the current | |||
version" which is separate from the URI identifying each particular | version" which is separate from the URI identifying each particular | |||
version. In this case, a PUT request on a general URI might result | version. In this case, a PUT request on a general URI might result | |||
in several other URIs being defined by the origin server. | in several other URIs being defined by the origin server. | |||
HTTP/1.1 does not define how a PUT method affects the state of an | HTTP/1.1 does not define how a PUT method affects the state of an | |||
origin server. | origin server. | |||
PUT requests MUST obey the message transmission requirements set out | ||||
in Section 8.2. | ||||
Unless otherwise specified for a particular entity-header, the | Unless otherwise specified for a particular entity-header, the | |||
entity-headers in the PUT request SHOULD be applied to the resource | entity-headers in the PUT request SHOULD be applied to the resource | |||
created or modified by the PUT. | created or modified by the PUT. | |||
9.7. DELETE | 9.7. DELETE | |||
The DELETE method requests that the origin server delete the resource | The DELETE method requests that the origin server delete the resource | |||
identified by the Request-URI. This method MAY be overridden by | identified by the Request-URI. This method MAY be overridden by | |||
human intervention (or other means) on the origin server. The client | human intervention (or other means) on the origin server. The client | |||
cannot be guaranteed that the operation has been carried out, even if | cannot be guaranteed that the operation has been carried out, even if | |||
skipping to change at page 62, line 13 ¶ | skipping to change at page 66, line 52 ¶ | |||
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 70, 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 Content) responses. | |||
10.3. Redirection 3xx | 10.3. Redirection 3xx | |||
This class of status code indicates that further action needs to be | This class of status code indicates that further action needs to be | |||
taken by the user agent in order to fulfill the request. The action | taken by the user agent in order to fulfill the request. The action | |||
required MAY be carried out by the user agent without interaction | required MAY be carried out by the user agent without interaction | |||
with the user if and only if the method used in the second request is | with the user if and only if the method used in the second request is | |||
GET or HEAD. A client SHOULD detect infinite redirection loops, | GET or HEAD. A client SHOULD detect infinite redirection loops, | |||
since such loops generate network traffic for each redirection. | since such loops generate network traffic for each redirection. | |||
skipping to change at page 67, line 50 ¶ | skipping to change at page 71, 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 | |||
The response to the request can be found under a different URI and | The server directs the user agent to a different resource, indicated | |||
SHOULD be retrieved using a GET method on that resource. This method | by a URI in the Location header field, that provides an indirect | |||
exists primarily to allow the output of a POST-activated script to | response to the original request. The user agent MAY perform a GET | |||
redirect the user agent to a selected resource. The new URI is not a | request on the URI in the Location field in order to obtain a | |||
substitute reference for the originally requested resource. The 303 | representation corresponding to the response, be redirected again, or | |||
response MUST NOT be cached, but the response to the second | end with an error status. The Location URI is not a substitute | |||
(redirected) request might be cacheable. | reference for the originally requested resource. | |||
The different URI SHOULD be given by the Location field in the | The 303 status is generally applicable to any HTTP method. It is | |||
response. Unless the request method was HEAD, the entity of the | primarily used to allow the output of a POST action to redirect the | |||
response SHOULD contain a short hypertext note with a hyperlink to | user agent to a selected resource, since doing so provides the | |||
the new URI(s). | information corresponding to the POST response in a form that can be | |||
separately identified, bookmarked, and cached independent of the | ||||
original request. | ||||
Note: Many pre-HTTP/1.1 user agents do not understand the 303 | A 303 response to a GET request indicates that the requested resource | |||
status. When interoperability with such clients is a concern, the | does not have a representation of its own that can be transferred by | |||
302 status code may be used instead, since most user agents react | the server over HTTP. The Location URI indicates a resource that is | |||
to a 302 response as described here for 303. | descriptive of the requested resource such that the follow-on | |||
representation may be useful without implying that it adequately | ||||
represents the previously requested resource. Note that answers to | ||||
the questions of what can be represented, what representations are | ||||
adequate, and what might be a useful description are outside the | ||||
scope of HTTP and thus entirely determined by the resource owner(s). | ||||
A 303 response SHOULD NOT be cached unless it is indicated as | ||||
cacheable by Cache-Control or Expires header fields. Except for | ||||
responses to a HEAD request, the entity of a 303 response SHOULD | ||||
contain a short hypertext note with a hyperlink to the Location URI. | ||||
10.3.5. 304 Not Modified | 10.3.5. 304 Not Modified | |||
If the client has performed a conditional GET request and access is | If the client has performed a conditional GET request and access is | |||
allowed, but the document has not been modified, the server SHOULD | allowed, but the document has not been modified, the server SHOULD | |||
respond with this status code. The 304 response MUST NOT contain a | respond with this status code. The 304 response MUST NOT contain a | |||
message-body, and thus is always terminated by the first empty line | message-body, and thus is always terminated by the first empty line | |||
after the header fields. | after the header fields. | |||
The response MUST include the following header fields: | The response MUST include the following header fields: | |||
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 74, line 37 ¶ | |||
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 75, line 38 ¶ | |||
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 14 ¶ | |||
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 81, 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 81, line 7 ¶ | skipping to change at page 85, line 7 ¶ | |||
server and also removing the second request delay of agent-driven | server and also removing the second request delay of agent-driven | |||
negotiation when the cache is able to correctly guess the right | negotiation when the cache is able to correctly guess the right | |||
response. | response. | |||
This specification does not define any mechanism for transparent | This specification does not define any mechanism for transparent | |||
negotiation, though it also does not prevent any such mechanism from | negotiation, though it also does not prevent any such mechanism from | |||
being developed as an extension that could be used within HTTP/1.1. | being developed as an extension that could be used within HTTP/1.1. | |||
13. Caching in HTTP | 13. Caching in HTTP | |||
13.1. Overview | ||||
HTTP is typically used for distributed information systems, where | HTTP is typically used for distributed information systems, where | |||
performance can be improved by the use of response caches. The | performance can be improved by the use of response caches. The | |||
HTTP/1.1 protocol includes a number of elements intended to make | HTTP/1.1 protocol includes a number of elements intended to make | |||
caching work as well as possible. Because these elements are | caching work as well as possible. Because these elements are | |||
inextricable from other aspects of the protocol, and because they | inextricable from other aspects of the protocol, and because they | |||
interact with each other, it is useful to describe the basic caching | interact with each other, it is useful to describe the basic caching | |||
design of HTTP separately from the detailed descriptions of methods, | design of HTTP separately from the detailed descriptions of methods, | |||
headers, response codes, etc. | headers, response codes, etc. | |||
Caching would be useless if it did not significantly improve | Caching would be useless if it did not significantly improve | |||
skipping to change at page 82, line 13 ¶ | skipping to change at page 86, line 15 ¶ | |||
A basic principle is that it must be possible for the clients to | A basic principle is that it must be possible for the clients to | |||
detect any potential relaxation of semantic transparency. | detect any potential relaxation of semantic transparency. | |||
Note: The server, cache, or client implementor might be faced with | Note: The server, cache, or client implementor might be faced with | |||
design decisions not explicitly discussed in this specification. | design decisions not explicitly discussed in this specification. | |||
If a decision might affect semantic transparency, the implementor | If a decision might affect semantic transparency, the implementor | |||
ought to err on the side of maintaining transparency unless a | ought to err on the side of maintaining transparency unless a | |||
careful and complete analysis shows significant benefits in | careful and complete analysis shows significant benefits in | |||
breaking transparency. | breaking transparency. | |||
13.1. | ||||
13.1.1. Cache Correctness | 13.1.1. Cache Correctness | |||
A correct cache MUST respond to a request with the most up-to-date | A correct cache MUST respond to a request with the most up-to-date | |||
response held by the cache that is appropriate to the request (see | response held by the cache that is appropriate to the request (see | |||
sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | Sections 13.2.5, 13.2.6, and 13.12) which meets one of the following | |||
conditions: | conditions: | |||
1. It has been checked for equivalence with what the origin server | 1. It has been checked for equivalence with what the origin server | |||
would have returned by revalidating the response with the origin | would have returned by revalidating the response with the origin | |||
server (Section 13.3); | server (Section 13.3); | |||
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 (Use Proxy), 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 | |||
warning indicating that there was a communication failure. | warning indicating that there was a communication failure. | |||
If a cache receives a response (either an entire response, or a 304 | If a cache receives a response (either an entire response, or a 304 | |||
(Not Modified) response) that it would normally forward to the | (Not Modified) response) that it would normally forward to the | |||
requesting client, and the received response is no longer fresh, the | requesting client, and the received response is no longer fresh, the | |||
skipping to change at page 83, line 28 ¶ | skipping to change at page 87, line 27 ¶ | |||
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 6 ¶ | skipping to change at page 91, line 6 ¶ | |||
and history mechanisms. | and history mechanisms. | |||
13.2.2. Heuristic Expiration | 13.2.2. Heuristic Expiration | |||
Since origin servers do not always provide explicit expiration times, | Since origin servers do not always provide explicit expiration times, | |||
HTTP caches typically assign heuristic expiration times, employing | HTTP caches typically assign heuristic expiration times, employing | |||
algorithms that use other header values (such as the Last-Modified | algorithms that use other header values (such as the Last-Modified | |||
time) to estimate a plausible expiration time. The HTTP/1.1 | time) to estimate a plausible expiration time. The HTTP/1.1 | |||
specification does not provide specific algorithms, but does impose | specification does not provide specific algorithms, but does impose | |||
worst-case constraints on their results. Since heuristic expiration | worst-case constraints on their results. Since heuristic expiration | |||
times might compromise semantic transparency, they ought to used | times might compromise semantic transparency, they ought to be used | |||
cautiously, and we encourage origin servers to provide explicit | cautiously, and we encourage origin servers to provide explicit | |||
expiration times as much as possible. | expiration times as much as possible. | |||
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 97, 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 94, line 23 ¶ | skipping to change at page 98, line 23 ¶ | |||
or not: | or not: | |||
o The strong comparison function: in order to be considered equal, | o The strong comparison function: in order to be considered equal, | |||
both validators MUST be identical in every way, and both MUST NOT | both validators MUST be identical in every way, and both MUST NOT | |||
be weak. | be weak. | |||
o The weak comparison function: in order to be considered equal, | o The weak comparison function: in order to be considered equal, | |||
both validators MUST be identical in every way, but either or both | both validators MUST be identical in every way, but either or both | |||
of them MAY be tagged as "weak" without affecting the result. | of them MAY be tagged as "weak" without affecting the result. | |||
The example below shows the results for a set of entity tag pairs, | ||||
and both the weak and strong comparison function results: | ||||
+--------+--------+-------------------+-----------------+ | ||||
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | ||||
+--------+--------+-------------------+-----------------+ | ||||
| W/"1" | W/"1" | no match | match | | ||||
| | | | | | ||||
| W/"1" | W/"2" | no match | no match | | ||||
| | | | | | ||||
| W/"1" | "1" | no match | match | | ||||
| | | | | | ||||
| "1" | "1" | match | match | | ||||
+--------+--------+-------------------+-----------------+ | ||||
An entity tag is strong unless it is explicitly tagged as weak. | An entity tag is strong unless it is explicitly tagged as weak. | |||
Section 3.11 gives the syntax for entity tags. | Section 3.11 gives the syntax for entity tags. | |||
A Last-Modified time, when used as a validator in a request, is | A Last-Modified time, when used as a validator in a request, is | |||
implicitly weak unless it is possible to deduce that it is strong, | implicitly weak unless it is possible to deduce that it is strong, | |||
using the following rules: | using the following rules: | |||
o The validator is being compared by an origin server to the actual | o The validator is being compared by an origin server to the actual | |||
current validator for the entity and, | current validator for the entity and, | |||
skipping to change at page 99, line 21 ¶ | skipping to change at page 103, line 35 ¶ | |||
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 104, line 20 ¶ | skipping to change at page 108, line 36 ¶ | |||
Unless the origin server explicitly prohibits the caching of their | Unless the origin server explicitly prohibits the caching of their | |||
responses, the application of GET and HEAD methods to any resources | responses, the application of GET and HEAD methods to any resources | |||
SHOULD NOT have side effects that would lead to erroneous behavior if | SHOULD NOT have side effects that would lead to erroneous behavior if | |||
these responses are taken from a cache. They MAY still have side | these responses are taken from a cache. They MAY still have side | |||
effects, but a cache is not required to consider such side effects in | effects, but a cache is not required to consider such side effects in | |||
its caching decisions. Caches are always expected to observe an | its caching decisions. Caches are always expected to observe an | |||
origin server's explicit restrictions on caching. | origin server's explicit restrictions on caching. | |||
We note one exception to this rule: since some applications have | We note one exception to this rule: since some applications have | |||
traditionally used GETs and HEADs with query URLs (those containing a | traditionally used GETs and HEADs with URLs containing a query part | |||
"?" in the rel_path part) to perform operations with significant side | to perform operations with significant side effects, caches MUST NOT | |||
effects, caches MUST NOT treat responses to such URIs as fresh unless | treat responses to such URIs as fresh unless the server provides an | |||
the server provides an explicit expiration time. This specifically | explicit expiration time. This specifically means that responses | |||
means that responses from HTTP/1.0 servers for such URIs SHOULD NOT | from HTTP/1.0 servers for such URIs SHOULD NOT be taken from a cache. | |||
be taken from a cache. See Section 9.1.1 for related information. | See Section 9.1.1 for related information. | |||
13.10. Invalidation After Updates or Deletions | 13.10. Invalidation After Updates or Deletions | |||
The effect of certain methods performed on a resource at the origin | The effect of certain methods performed on a resource at the origin | |||
server might cause one or more existing cache entries to become non- | server might cause one or more existing cache entries to become non- | |||
transparently invalid. That is, although they might continue to be | transparently invalid. That is, although they might continue to be | |||
"fresh," they do not accurately reflect what the origin server would | "fresh," they do not accurately reflect what the origin server would | |||
return for a new request on that resource. | return for a new request on that resource. | |||
There is no way for the HTTP protocol to guarantee that all such | There is no way for the HTTP protocol to guarantee that all such | |||
skipping to change at page 105, line 11 ¶ | skipping to change at page 109, line 26 ¶ | |||
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 7 ¶ | |||
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 110, line 46 ¶ | |||
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 | |||
sends and who receives the entity. | sends and who receives the entity. | |||
14.1. Accept | 14.1. Accept | |||
The Accept request-header field can be used to specify certain media | The Accept request-header field can be used to specify certain media | |||
types which are acceptable for the response. Accept headers can be | types which are acceptable for the response. Accept headers can be | |||
used to indicate that the request is specifically limited to a small | used to indicate that the request is specifically limited to a small | |||
set of desired types, as in the case of a request for an in-line | set of desired types, as in the case of a request for an in-line | |||
image. | image. | |||
Accept = "Accept" ":" | Accept = "Accept" ":" | |||
#( media-range [ accept-params ] ) | #( media-range [ accept-params ] ) | |||
media-range = ( "*/*" | media-range = ( "*/*" | |||
| ( type "/" "*" ) | | ( type "/" "*" ) | |||
| ( type "/" subtype ) | | ( type "/" subtype ) | |||
) *( ";" parameter ) | ) *( ";" parameter ) | |||
accept-params = ";" "q" "=" qvalue *( accept-extension ) | accept-params = ";" "q" "=" qvalue *( accept-extension ) | |||
accept-extension = ";" token [ "=" ( token | quoted-string ) ] | accept-extension = ";" token [ "=" ( token | quoted-string ) ] | |||
The asterisk "*" character is used to group media types into ranges, | The asterisk "*" character is used to group media types into ranges, | |||
with "*/*" indicating all media types and "type/*" indicating all | with "*/*" indicating all media types and "type/*" indicating all | |||
subtypes of that type. The media-range MAY include media type | subtypes of that type. The media-range MAY include media type | |||
parameters that are applicable to that range. | parameters that are applicable to that range. | |||
Each media-range MAY be followed by one or more accept-params, | Each media-range MAY be followed by one or more accept-params, | |||
beginning with the "q" parameter for indicating a relative quality | beginning with the "q" parameter for indicating a relative quality | |||
factor. The first "q" parameter (if any) separates the media-range | factor. The first "q" parameter (if any) separates the media-range | |||
parameter(s) from the accept-params. Quality factors allow the user | parameter(s) from the accept-params. Quality factors allow the user | |||
skipping to change at page 108, line 13 ¶ | skipping to change at page 112, line 13 ¶ | |||
The example | The example | |||
Accept: audio/*; q=0.2, audio/basic | Accept: audio/*; q=0.2, audio/basic | |||
SHOULD be interpreted as "I prefer audio/basic, but send me any audio | SHOULD be interpreted as "I prefer audio/basic, but send me any audio | |||
type if it is the best available after an 80% mark-down in quality." | type if it is the best available after an 80% mark-down in quality." | |||
If no Accept header field is present, then it is assumed that the | If no Accept header field is present, then it is assumed that the | |||
client accepts all media types. If an Accept header field is | client accepts all media types. If an Accept header field is | |||
present, and if the server cannot send a response which is acceptable | present, and if the server cannot send a response which is acceptable | |||
according to the combined Accept field value, then the server SHOULD | according to the combined Accept field value, then the server SHOULD | |||
send a 406 (not acceptable) response. | send a 406 (Not Acceptable) response. | |||
A more elaborate example is | A more elaborate example is | |||
Accept: text/plain; q=0.5, text/html, | Accept: text/plain; q=0.5, text/html, | |||
text/x-dvi; q=0.8, text/x-c | text/x-dvi; q=0.8, text/x-c | |||
Verbally, this would be interpreted as "text/html and text/x-c are | Verbally, this would be interpreted as "text/html and text/x-c are | |||
the preferred media types, but if they do not exist, then send the | the preferred media types, but if they do not exist, then send the | |||
text/x-dvi entity, and if that does not exist, send the text/plain | text/x-dvi entity, and if that does not exist, send the text/plain | |||
entity." | entity." | |||
skipping to change at page 109, line 19 ¶ | skipping to change at page 113, line 19 ¶ | |||
default set ought to be configurable by the user. | default set ought to be configurable by the user. | |||
14.2. Accept-Charset | 14.2. Accept-Charset | |||
The Accept-Charset request-header field can be used to indicate what | The Accept-Charset request-header field can be used to indicate what | |||
character sets are acceptable for the response. This field allows | character sets are acceptable for the response. This field allows | |||
clients capable of understanding more comprehensive or special- | clients capable of understanding more comprehensive or special- | |||
purpose character sets to signal that capability to a server which is | purpose character sets to signal that capability to a server which is | |||
capable of representing documents in those character sets. | capable of representing documents in those character sets. | |||
Accept-Charset = "Accept-Charset" ":" | Accept-Charset = "Accept-Charset" ":" | |||
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) | 1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] ) | |||
Character set values are described in Section 3.4. Each charset MAY | Character set values are described in Section 3.4. Each charset MAY | |||
be given an associated quality value which represents the user's | be given an associated quality value which represents the user's | |||
preference for that charset. The default value is q=1. An example | preference for that charset. The default value is q=1. An example | |||
is | is | |||
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 | |||
The special value "*", if present in the Accept-Charset field, | The special value "*", if present in the Accept-Charset field, | |||
matches every character set (including ISO-8859-1) which is not | matches every character set (including ISO-8859-1) which is not | |||
mentioned elsewhere in the Accept-Charset field. If no "*" is | mentioned elsewhere in the Accept-Charset field. If no "*" is | |||
present in an Accept-Charset field, then all character sets not | present in an Accept-Charset field, then all character sets not | |||
explicitly mentioned get a quality value of 0, except for ISO-8859-1, | explicitly mentioned get a quality value of 0, except for ISO-8859-1, | |||
which gets a quality value of 1 if not explicitly mentioned. | which gets a quality value of 1 if not explicitly mentioned. | |||
If no Accept-Charset header is present, the default is that any | If no Accept-Charset header is present, the default is that any | |||
character set is acceptable. If an Accept-Charset header is present, | character set is acceptable. If an Accept-Charset header is present, | |||
and if the server cannot send a response which is acceptable | and if the server cannot send a response which is acceptable | |||
according to the Accept-Charset header, then the server SHOULD send | according to the Accept-Charset header, then the server SHOULD send | |||
an error response with the 406 (not acceptable) status code, though | an error response with the 406 (Not Acceptable) status code, though | |||
the sending of an unacceptable response is also allowed. | the sending of an unacceptable response is also allowed. | |||
14.3. Accept-Encoding | 14.3. Accept-Encoding | |||
The Accept-Encoding request-header field is similar to Accept, but | The Accept-Encoding request-header field is similar to Accept, but | |||
restricts the content-codings (Section 3.5) that are acceptable in | restricts the content-codings (Section 3.5) that are acceptable in | |||
the response. | the response. | |||
Accept-Encoding = "Accept-Encoding" ":" | Accept-Encoding = "Accept-Encoding" ":" | |||
1#( codings [ ";" "q" "=" qvalue ] ) | #( codings [ ";" "q" "=" qvalue ] ) | |||
codings = ( content-coding | "*" ) | codings = ( content-coding | "*" ) | |||
Examples of its use are: | Examples of its use are: | |||
Accept-Encoding: compress, gzip | Accept-Encoding: compress, gzip | |||
Accept-Encoding: | Accept-Encoding: | |||
Accept-Encoding: * | Accept-Encoding: * | |||
Accept-Encoding: compress;q=0.5, gzip;q=1.0 | Accept-Encoding: compress;q=0.5, gzip;q=1.0 | |||
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 | |||
A server tests whether a content-coding is acceptable, according to | A server tests whether a content-coding is acceptable, according to | |||
skipping to change at page 111, line 16 ¶ | skipping to change at page 115, line 16 ¶ | |||
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |||
associated with content-codings. This means that qvalues will not | associated with content-codings. This means that qvalues will not | |||
work and are not permitted with x-gzip or x-compress. | work and are not permitted with x-gzip or x-compress. | |||
14.4. Accept-Language | 14.4. Accept-Language | |||
The Accept-Language request-header field is similar to Accept, but | The Accept-Language request-header field is similar to Accept, but | |||
restricts the set of natural languages that are preferred as a | restricts the set of natural languages that are preferred as a | |||
response to the request. Language tags are defined in Section 3.10. | response to the request. Language tags are defined in Section 3.10. | |||
Accept-Language = "Accept-Language" ":" | Accept-Language = "Accept-Language" ":" | |||
1#( language-range [ ";" "q" "=" qvalue ] ) | 1#( language-range [ ";" "q" "=" qvalue ] ) | |||
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |||
Each language-range MAY be given an associated quality value which | Each language-range MAY be given an associated quality value which | |||
represents an estimate of the user's preference for the languages | represents an estimate of the user's preference for the languages | |||
specified by that range. The quality value defaults to "q=1". For | specified by that range. The quality value defaults to "q=1". For | |||
example, | example, | |||
Accept-Language: da, en-gb;q=0.8, en;q=0.7 | Accept-Language: da, en-gb;q=0.8, en;q=0.7 | |||
would mean: "I prefer Danish, but will accept British English and | would mean: "I prefer Danish, but will accept British English and | |||
other types of English." A language-range matches a language-tag if | other types of English." A language-range matches a Language-Tag if | |||
it exactly equals the tag, or if it exactly equals a prefix of the | it exactly equals the tag, or if it exactly equals a prefix of the | |||
tag such that the first tag character following the prefix is "-". | tag such that the first tag character following the prefix is "-". | |||
The special range "*", if present in the Accept-Language field, | The special range "*", if present in the Accept-Language field, | |||
matches every tag not matched by any other range present in the | matches every tag not matched by any other range present in the | |||
Accept-Language field. | Accept-Language field. | |||
Note: This use of a prefix matching rule does not imply that | Note: This use of a prefix matching rule does not imply that | |||
language tags are assigned to languages in such a way that it is | language tags are assigned to languages in such a way that it is | |||
always true that if a user understands a language with a certain | always true that if a user understands a language with a certain | |||
tag, then this user will also understand all languages with tags | tag, then this user will also understand all languages with tags | |||
for which this tag is a prefix. The prefix rule simply allows the | for which this tag is a prefix. The prefix rule simply allows the | |||
use of prefix tags if this is the case. | use of prefix tags if this is the case. | |||
The language quality factor assigned to a language-tag by the Accept- | The language quality factor assigned to a Language-Tag by the Accept- | |||
Language field is the quality value of the longest language-range in | Language field is the quality value of the longest language-range in | |||
the field that matches the language-tag. If no language-range in the | the field that matches the Language-Tag. If no language-range in the | |||
field matches the tag, the language quality factor assigned is 0. If | field matches the tag, the language quality factor assigned is 0. If | |||
no Accept-Language header is present in the request, the server | no Accept-Language header is present in the request, the server | |||
SHOULD assume that all languages are equally acceptable. If an | SHOULD assume that all languages are equally acceptable. If an | |||
Accept-Language header is present, then all languages which are | Accept-Language header is present, then all languages which are | |||
assigned a quality factor greater than 0 are acceptable. | assigned a quality factor greater than 0 are acceptable. | |||
It might be contrary to the privacy expectations of the user to send | It might be contrary to the privacy expectations of the user to send | |||
an Accept-Language header with the complete linguistic preferences of | an Accept-Language header with the complete linguistic preferences of | |||
the user in every request. For a discussion of this issue, see | the user in every request. For a discussion of this issue, see | |||
Section 15.1.4. | Section 15.1.4. | |||
skipping to change at page 112, line 28 ¶ | skipping to change at page 116, line 28 ¶ | |||
might assume that on selecting "en-gb", they will be served any | might assume that on selecting "en-gb", they will be served any | |||
kind of English document if British English is not available. A | kind of English document if British English is not available. A | |||
user agent might suggest in such a case to add "en" to get the | user agent might suggest in such a case to add "en" to get the | |||
best matching behavior. | best matching behavior. | |||
14.5. Accept-Ranges | 14.5. Accept-Ranges | |||
The Accept-Ranges response-header field allows the server to indicate | The Accept-Ranges response-header field allows the server to indicate | |||
its acceptance of range requests for a resource: | its acceptance of range requests for a resource: | |||
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges | |||
acceptable-ranges = 1#range-unit | "none" | acceptable-ranges = 1#range-unit | "none" | |||
Origin servers that accept byte-range requests MAY send | Origin servers that accept byte-range requests MAY send | |||
Accept-Ranges: bytes | Accept-Ranges: bytes | |||
but are not required to do so. Clients MAY generate byte-range | but are not required to do so. Clients MAY generate byte-range | |||
requests without having received this header for the resource | requests without having received this header for the resource | |||
involved. Range units are defined in Section 3.12. | involved. Range units are defined in Section 3.12. | |||
Servers that do not accept any kind of range request for a resource | Servers that do not accept any kind of range request for a resource | |||
skipping to change at page 113, line 6 ¶ | skipping to change at page 117, line 6 ¶ | |||
to advise the client not to attempt a range request. | to advise the client not to attempt a range request. | |||
14.6. Age | 14.6. Age | |||
The Age response-header field conveys the sender's estimate of the | The Age response-header field conveys the sender's estimate of the | |||
amount of time since the response (or its revalidation) was generated | amount of time since the response (or its revalidation) was generated | |||
at the origin server. A cached response is "fresh" if its age does | at the origin server. A cached response is "fresh" if its age does | |||
not exceed its freshness lifetime. Age values are calculated as | not exceed its freshness lifetime. Age values are calculated as | |||
specified in Section 13.2.3. | specified in Section 13.2.3. | |||
Age = "Age" ":" age-value | Age = "Age" ":" age-value | |||
age-value = delta-seconds | age-value = delta-seconds | |||
Age values are non-negative decimal integers, representing time in | Age values are non-negative decimal integers, representing time in | |||
seconds. | seconds. | |||
If a cache receives a value larger than the largest positive integer | If a cache receives a value larger than the largest positive integer | |||
it can represent, or if any of its age calculations overflows, it | it can represent, or if any of its age calculations overflows, it | |||
MUST transmit an Age header with a value of 2147483648 (2^31). An | MUST transmit an Age header with a value of 2147483648 (2^31). An | |||
HTTP/1.1 server that includes a cache MUST include an Age header | HTTP/1.1 server that includes a cache MUST include an Age header | |||
field in every response generated from its own cache. Caches SHOULD | field in every response generated from its own cache. Caches SHOULD | |||
use an arithmetic type of at least 31 bits of range. | use an arithmetic type of at least 31 bits of range. | |||
14.7. Allow | 14.7. Allow | |||
The Allow entity-header field lists the set of methods supported by | The Allow entity-header field lists the set of methods supported by | |||
the resource identified by the Request-URI. The purpose of this | the resource identified by the Request-URI. The purpose of this | |||
field is strictly to inform the recipient of valid methods associated | field is strictly to inform the recipient of valid methods associated | |||
with the resource. An Allow header field MUST be present in a 405 | with the resource. An Allow header field MUST be present in a 405 | |||
(Method Not Allowed) response. | (Method Not Allowed) response. | |||
Allow = "Allow" ":" #Method | Allow = "Allow" ":" #Method | |||
Example of use: | Example of use: | |||
Allow: GET, HEAD, PUT | Allow: GET, HEAD, PUT | |||
This field cannot prevent a client from trying other methods. | This field cannot prevent a client from trying other methods. | |||
However, the indications given by the Allow header field value SHOULD | However, the indications given by the Allow header field value SHOULD | |||
be followed. The actual set of allowed methods is defined by the | be followed. The actual set of allowed methods is defined by the | |||
origin server at the time of each request. | origin server at the time of each request. | |||
skipping to change at page 114, line 9 ¶ | skipping to change at page 118, line 9 ¶ | |||
14.8. Authorization | 14.8. Authorization | |||
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 115, line 30 ¶ | skipping to change at page 119, line 30 ¶ | |||
cache-request-directive = | cache-request-directive = | |||
"no-cache" ; Section 14.9.1 | "no-cache" ; Section 14.9.1 | |||
| "no-store" ; Section 14.9.2 | | "no-store" ; Section 14.9.2 | |||
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | | "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4 | |||
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | | "max-stale" [ "=" delta-seconds ] ; Section 14.9.3 | |||
| "min-fresh" "=" delta-seconds ; Section 14.9.3 | | "min-fresh" "=" delta-seconds ; Section 14.9.3 | |||
| "no-transform" ; Section 14.9.5 | | "no-transform" ; Section 14.9.5 | |||
| "only-if-cached" ; Section 14.9.4 | | "only-if-cached" ; Section 14.9.4 | |||
| cache-extension ; Section 14.9.6 | | cache-extension ; Section 14.9.6 | |||
cache-response-directive = | cache-response-directive = | |||
"public" ; Section 14.9.1 | "public" ; Section 14.9.1 | |||
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1 | | "private" [ "=" DQUOTE 1#field-name DQUOTE ] | |||
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1 | ; Section 14.9.1 | |||
| "no-store" ; Section 14.9.2 | | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] | |||
| "no-transform" ; Section 14.9.5 | ; Section 14.9.1 | |||
| "must-revalidate" ; Section 14.9.4 | | "no-store" ; Section 14.9.2 | |||
| "proxy-revalidate" ; Section 14.9.4 | | "no-transform" ; Section 14.9.5 | |||
| "max-age" "=" delta-seconds ; Section 14.9.3 | | "must-revalidate" ; Section 14.9.4 | |||
| "s-maxage" "=" delta-seconds ; Section 14.9.3 | | "proxy-revalidate" ; Section 14.9.4 | |||
| cache-extension ; Section 14.9.6 | | "max-age" "=" delta-seconds ; Section 14.9.3 | |||
| "s-maxage" "=" delta-seconds ; Section 14.9.3 | ||||
| cache-extension ; Section 14.9.6 | ||||
cache-extension = token [ "=" ( token | quoted-string ) ] | cache-extension = token [ "=" ( token | quoted-string ) ] | |||
When a directive appears without any 1#field-name parameter, the | When a directive appears without any 1#field-name parameter, the | |||
directive applies to the entire request or response. When such a | directive applies to the entire request or response. When such a | |||
directive appears with a 1#field-name parameter, it applies only to | directive appears with a 1#field-name parameter, it applies only to | |||
the named field or fields, and not to the rest of the request or | the named field or fields, and not to the rest of the request or | |||
response. This mechanism supports extensibility; implementations of | response. This mechanism supports extensibility; implementations of | |||
future versions of the HTTP protocol might apply these directives to | future versions of the HTTP protocol might apply these directives to | |||
header fields not defined in HTTP/1.1. | header fields not defined in HTTP/1.1. | |||
skipping to change at page 124, line 20 ¶ | skipping to change at page 128, line 24 ¶ | |||
correct even if the cache does not understand the extension(s). | correct even if the cache does not understand the extension(s). | |||
14.10. Connection | 14.10. Connection | |||
The Connection general-header field allows the sender to specify | The Connection general-header field allows the sender to specify | |||
options that are desired for that particular connection and MUST NOT | options that are desired for that particular connection and MUST NOT | |||
be communicated by proxies over further connections. | be communicated by proxies over further connections. | |||
The Connection header has the following grammar: | The Connection header has the following grammar: | |||
Connection = "Connection" ":" 1#(connection-token) | Connection = "Connection" ":" 1#(connection-token) | |||
connection-token = token | connection-token = token | |||
HTTP/1.1 proxies MUST parse the Connection header field before a | HTTP/1.1 proxies MUST parse the Connection header field before a | |||
message is forwarded and, for each connection-token in this field, | message is forwarded and, for each connection-token in this field, | |||
remove any header field(s) from the message with the same name as the | remove any header field(s) from the message with the same name as the | |||
connection-token. Connection options are signaled by the presence of | connection-token. Connection options are signaled by the presence of | |||
a connection-token in the Connection header field, not by any | a connection-token in the Connection header field, not by any | |||
corresponding additional header field(s), since the additional header | corresponding additional header field(s), since the additional header | |||
field may not be sent if there are no parameters associated with that | field may not be sent if there are no parameters associated with that | |||
connection option. | connection option. | |||
skipping to change at page 124, line 45 ¶ | skipping to change at page 128, line 49 ¶ | |||
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. | |||
Content-Encoding = "Content-Encoding" ":" 1#content-coding | Content-Encoding = "Content-Encoding" ":" 1#content-coding | |||
Content codings are defined in Section 3.5. An example of its use is | Content codings are defined in Section 3.5. An example of its use is | |||
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. | |||
14.12. Content-Language | 14.12. Content-Language | |||
The Content-Language entity-header field describes the natural | The Content-Language entity-header field describes the natural | |||
language(s) of the intended audience for the enclosed entity. Note | language(s) of the intended audience for the enclosed entity. Note | |||
that this might not be equivalent to all the languages used within | that this might not be equivalent to all the languages used within | |||
the entity-body. | the entity-body. | |||
Content-Language = "Content-Language" ":" 1#language-tag | Content-Language = "Content-Language" ":" 1#Language-Tag | |||
Language tags are defined in Section 3.10. The primary purpose of | Language tags are defined in Section 3.10. The primary purpose of | |||
Content-Language is to allow a user to identify and differentiate | Content-Language is to allow a user to identify and differentiate | |||
entities according to the user's own preferred language. Thus, if | entities according to the user's own preferred language. Thus, if | |||
the body content is intended only for a Danish-literate audience, the | the body content is intended only for a Danish-literate audience, the | |||
appropriate field is | appropriate field is | |||
Content-Language: da | Content-Language: da | |||
If no Content-Language is specified, the default is that the content | If no Content-Language is specified, the default is that the content | |||
skipping to change at page 126, line 42 ¶ | skipping to change at page 130, line 51 ¶ | |||
Content-Language MAY be applied to any media type -- it is not | Content-Language MAY be applied to any media type -- it is not | |||
limited to textual documents. | limited to textual documents. | |||
14.13. Content-Length | 14.13. Content-Length | |||
The Content-Length entity-header field indicates the size of the | The Content-Length entity-header field indicates the size of the | |||
entity-body, in decimal number of OCTETs, sent to the recipient or, | entity-body, in decimal number of OCTETs, sent to the recipient or, | |||
in the case of the HEAD method, the size of the entity-body that | in the case of the HEAD method, the size of the entity-body that | |||
would have been sent had the request been a GET. | would have been sent had the request been a GET. | |||
Content-Length = "Content-Length" ":" 1*DIGIT | Content-Length = "Content-Length" ":" 1*DIGIT | |||
An example is | An example is | |||
Content-Length: 3495 | Content-Length: 3495 | |||
Applications SHOULD use this field to indicate the transfer-length of | Applications SHOULD use this field to indicate the transfer-length of | |||
the message-body, unless this is prohibited by the rules in | the message-body, unless this is prohibited by the rules in | |||
Section 4.4. | Section 4.4. | |||
Any Content-Length greater than or equal to zero is a valid value. | Any Content-Length greater than or equal to zero is a valid value. | |||
skipping to change at page 127, line 27 ¶ | skipping to change at page 131, line 36 ¶ | |||
The Content-Location entity-header field MAY be used to supply the | The Content-Location entity-header field MAY be used to supply the | |||
resource location for the entity enclosed in the message when that | resource location for the entity enclosed in the message when that | |||
entity is accessible from a location separate from the requested | entity is accessible from a location separate from the requested | |||
resource's URI. A server SHOULD provide a Content-Location for the | resource's URI. A server SHOULD provide a Content-Location for the | |||
variant corresponding to the response entity; especially in the case | variant corresponding to the response entity; especially in the case | |||
where a resource has multiple entities associated with it, and those | where a resource has multiple entities associated with it, and those | |||
entities actually have separate locations by which they might be | entities actually have separate locations by which they might be | |||
individually accessed, the server SHOULD provide a Content-Location | individually accessed, the server SHOULD provide a Content-Location | |||
for the particular variant which is returned. | for the particular variant which is returned. | |||
Content-Location = "Content-Location" ":" | Content-Location = "Content-Location" ":" | |||
( absoluteURI | relativeURI ) | ( absoluteURI | relativeURI ) | |||
The value of Content-Location also defines the base URI for the | The value of Content-Location also defines the base URI for the | |||
entity. | entity. | |||
The Content-Location value is not a replacement for the original | The Content-Location value is not a replacement for the original | |||
requested URI; it is only a statement of the location of the resource | requested URI; it is only a statement of the location of the resource | |||
corresponding to this particular entity at the time of the request. | corresponding to this particular entity at the time of the request. | |||
Future requests MAY specify the Content-Location URI as the request- | Future requests MAY specify the Content-Location URI as the request- | |||
URI if the desire is to identify the source of that particular | URI if the desire is to identify the source of that particular | |||
entity. | entity. | |||
skipping to change at page 128, line 7 ¶ | skipping to change at page 132, line 15 ¶ | |||
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 129, line 23 ¶ | skipping to change at page 133, line 32 ¶ | |||
the digest is the transmission byte order defined for the type. | the digest is the transmission byte order defined for the type. | |||
Lastly, HTTP allows transmission of text types with any of several | Lastly, HTTP allows transmission of text types with any of several | |||
line break conventions and not just the canonical form using CRLF. | line break conventions and not just the canonical form using CRLF. | |||
14.16. Content-Range | 14.16. Content-Range | |||
The Content-Range entity-header is sent with a partial entity-body to | The Content-Range entity-header is sent with a partial entity-body to | |||
specify where in the full entity-body the partial body should be | specify where in the full entity-body the partial body should be | |||
applied. Range units are defined in Section 3.12. | applied. Range units are defined in Section 3.12. | |||
Content-Range = "Content-Range" ":" content-range-spec | Content-Range = "Content-Range" ":" content-range-spec | |||
content-range-spec = byte-content-range-spec | content-range-spec = byte-content-range-spec | |||
byte-content-range-spec = bytes-unit SP | byte-content-range-spec = bytes-unit SP | |||
byte-range-resp-spec "/" | byte-range-resp-spec "/" | |||
( instance-length | "*" ) | ( instance-length | "*" ) | |||
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | |||
| "*" | | "*" | |||
instance-length = 1*DIGIT | instance-length = 1*DIGIT | |||
The header SHOULD indicate the total length of the full entity-body, | The header SHOULD indicate the total length of the full entity-body, | |||
unless this length is unknown or difficult to determine. The | unless this length is unknown or difficult to determine. The | |||
asterisk "*" character means that the instance-length is unknown at | asterisk "*" character means that the instance-length is unknown at | |||
the time when the response was generated. | the time when the response was generated. | |||
Unlike byte-ranges-specifier values (see Section 14.35.1), a byte- | Unlike byte-ranges-specifier values (see Section 14.35.1), a byte- | |||
range-resp-spec MUST only specify one range, and MUST contain | range-resp-spec MUST only specify one range, and MUST contain | |||
absolute byte positions for both the first and last byte of the | absolute byte positions for both the first and last byte of the | |||
range. | range. | |||
skipping to change at page 130, line 33 ¶ | skipping to change at page 134, line 43 ¶ | |||
o The last 500 bytes: | o The last 500 bytes: | |||
bytes 734-1233/1234 | bytes 734-1233/1234 | |||
When an HTTP message includes the content of a single range (for | When an HTTP message includes the content of a single range (for | |||
example, a response to a request for a single range, or to a request | example, a response to a request for a single range, or to a request | |||
for a set of ranges that overlap without any holes), this content is | for a set of ranges that overlap without any holes), this content is | |||
transmitted with a Content-Range header, and a Content-Length header | transmitted with a Content-Range header, and a Content-Length header | |||
showing the number of bytes actually transferred. For example, | showing the number of bytes actually transferred. For example, | |||
HTTP/1.1 206 Partial content | HTTP/1.1 206 Partial Content | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
Content-Range: bytes 21010-47021/47022 | Content-Range: bytes 21010-47021/47022 | |||
Content-Length: 26012 | Content-Length: 26012 | |||
Content-Type: image/gif | Content-Type: image/gif | |||
When an HTTP message includes the content of multiple ranges (for | When an HTTP message includes the content of multiple ranges (for | |||
example, a response to a request for multiple non-overlapping | example, a response to a request for multiple non-overlapping | |||
ranges), these are transmitted as a multipart message. The multipart | ranges), these are transmitted as a multipart message. The multipart | |||
media type used for this purpose is "multipart/byteranges" as defined | media type used for this purpose is "multipart/byteranges" as defined | |||
in Appendix A.2. See Appendix A.6.3 for a compatibility issue. | in Appendix B. See Appendix F.3 for a compatibility issue. | |||
A response to a request for a single range MUST NOT be sent using the | A response to a request for a single range MUST NOT be sent using the | |||
multipart/byteranges media type. A response to a request for | multipart/byteranges media type. A response to a request for | |||
multiple ranges, whose result is a single range, MAY be sent as a | multiple ranges, whose result is a single range, MAY be sent as a | |||
multipart/byteranges media type with one part. A client that cannot | multipart/byteranges media type with one part. A client that cannot | |||
decode a multipart/byteranges message MUST NOT ask for multiple byte- | decode a multipart/byteranges message MUST NOT ask for multiple byte- | |||
ranges in a single request. | ranges in a single request. | |||
When a client requests multiple byte-ranges in one request, the | When a client requests multiple byte-ranges in one request, the | |||
server SHOULD return them in the order that they appeared in the | server SHOULD return them in the order that they appeared in the | |||
skipping to change at page 131, line 32 ¶ | skipping to change at page 135, line 41 ¶ | |||
range not satisfiable) response instead of a 200 (OK) response for | range not satisfiable) response instead of a 200 (OK) response for | |||
an unsatisfiable Range request-header, since not all servers | an unsatisfiable Range request-header, since not all servers | |||
implement this request-header. | implement this request-header. | |||
14.17. Content-Type | 14.17. Content-Type | |||
The Content-Type entity-header field indicates the media type of the | The Content-Type entity-header field indicates the media type of the | |||
entity-body sent to the recipient or, in the case of the HEAD method, | entity-body sent to the recipient or, in the case of the HEAD method, | |||
the media type that would have been sent had the request been a GET. | the media type that would have been sent had the request been a GET. | |||
Content-Type = "Content-Type" ":" media-type | Content-Type = "Content-Type" ":" media-type | |||
Media types are defined in Section 3.7. An example of the field is | Media types are defined in Section 3.7. An example of the field is | |||
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 | [RFC2822]. 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 | |||
skipping to change at page 132, line 26 ¶ | skipping to change at page 136, line 39 ¶ | |||
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 132, line 40 ¶ | skipping to change at page 137, line 4 ¶ | |||
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 | |||
generating a reasonably accurate date and time. In theory, the date | generating a reasonably accurate date and time. In theory, the date | |||
ought to represent the moment just before the entity is generated. | ought to represent the moment just before the entity is generated. | |||
In practice, the date can be generated at any time during the message | In practice, the date can be generated at any time during the message | |||
origination without affecting its semantic value. | origination without affecting its semantic value. | |||
14.18.1. Clockless Origin Server Operation | 14.18.1. Clockless Origin Server Operation | |||
Some origin server implementations might not have a clock available. | Some origin server implementations might not have a clock available. | |||
An origin server without a clock MUST NOT assign Expires or Last- | An origin server without a clock MUST NOT assign Expires or Last- | |||
Modified values to a response, unless these values were associated | Modified values to a response, unless these values were associated | |||
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: "" | |||
14.20. Expect | 14.20. Expect | |||
The Expect request-header field is used to indicate that particular | The Expect request-header field is used to indicate that particular | |||
server behaviors are required by the client. | server behaviors are required by the client. | |||
Expect = "Expect" ":" 1#expectation | Expect = "Expect" ":" 1#expectation | |||
expectation = "100-continue" | expectation-extension | expectation = "100-continue" | expectation-extension | |||
expectation-extension = token [ "=" ( token | quoted-string ) | expectation-extension = token [ "=" ( token | quoted-string ) | |||
*expect-params ] | *expect-params ] | |||
expect-params = ";" token [ "=" ( token | quoted-string ) ] | expect-params = ";" token [ "=" ( token | quoted-string ) ] | |||
A server that does not understand or is unable to comply with any of | A server that does not understand or is unable to comply with any of | |||
the expectation values in the Expect field of a request MUST respond | the expectation values in the Expect field of a request MUST respond | |||
with appropriate error status. The server MUST respond with a 417 | with appropriate error status. The server MUST respond with a 417 | |||
(Expectation Failed) status if any of the expectations cannot be met | (Expectation Failed) status if any of the expectations cannot be met | |||
or, if there are other problems with the request, some other 4xx | or, if there are other problems with the request, some other 4xx | |||
status. | status. | |||
This header field is defined with extensible syntax to allow for | This header field is defined with extensible syntax to allow for | |||
future extensions. If a server receives a request containing an | future extensions. If a server receives a request containing an | |||
skipping to change at page 134, line 9 ¶ | skipping to change at page 138, line 23 ¶ | |||
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST | |||
return a 417 (Expectation Failed) status if it receives a request | return a 417 (Expectation Failed) status if it receives a request | |||
with an expectation that it cannot meet. However, the Expect | with an expectation that it cannot meet. However, the Expect | |||
request-header itself is end-to-end; it MUST be forwarded if the | request-header itself is end-to-end; it MUST be forwarded if the | |||
request is forwarded. | request is forwarded. | |||
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | |||
Expect header. | Expect header. | |||
See Section 8.2.3 for the use of the 100 (continue) status. | See Section 8.2.3 for the use of the 100 (Continue) status. | |||
14.21. Expires | 14.21. Expires | |||
The Expires entity-header field gives the date/time after which the | The Expires entity-header field gives the date/time after which the | |||
response is considered stale. A stale cache entry may not normally | response is considered stale. A stale cache entry may not normally | |||
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. | |||
HTTP/1.1 clients and caches MUST treat other invalid date formats, | HTTP/1.1 clients and caches MUST treat other invalid date formats, | |||
skipping to change at page 135, line 12 ¶ | skipping to change at page 139, line 25 ¶ | |||
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 Section 3.4 of [RFC2822]: | |||
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 | |||
interpretation of this field is that the request is being performed | interpretation of this field is that the request is being performed | |||
on behalf of the person given, who accepts responsibility for the | on behalf of the person given, who accepts responsibility for the | |||
skipping to change at page 135, line 51 ¶ | skipping to change at page 140, line 16 ¶ | |||
The Host request-header field specifies the Internet host and port | The Host request-header field specifies the Internet host and port | |||
number of the resource being requested, as obtained from the original | number of the resource being requested, as obtained from the original | |||
URI given by the user or referring resource (generally an HTTP URL, | URI given by the user or referring resource (generally an HTTP URL, | |||
as described in Section 3.2.2). The Host field value MUST represent | as described in Section 3.2.2). The Host field value MUST represent | |||
the naming authority of the origin server or gateway given by the | the naming authority of the origin server or gateway given by the | |||
original URL. This allows the origin server or gateway to | original URL. This allows the origin server or gateway to | |||
differentiate between internally-ambiguous URLs, such as the root "/" | differentiate between internally-ambiguous URLs, such as the root "/" | |||
URL of a server for multiple host names on a single IP address. | URL of a server for multiple host names on a single IP address. | |||
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 | Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2 | |||
A "host" without any trailing port information implies the default | A "host" without any trailing port information implies the default | |||
port for the service requested (e.g., "80" for an HTTP URL). For | port for the service requested (e.g., "80" for an HTTP URL). For | |||
example, a request on the origin server for | example, a request on the origin server for | |||
<http://www.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 | |||
also used, on updating requests, to prevent inadvertent modification | also used, on updating requests, to prevent inadvertent modification | |||
of the wrong version of a resource. As a special case, the value "*" | of the wrong version of a resource. As a special case, the value "*" | |||
matches any current entity of the resource. | matches any current entity of the resource. | |||
If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) | |||
If any of the entity tags match the entity tag of the entity that | If any of the entity tags match the entity tag of the entity that | |||
would have been returned in the response to a similar GET request | would have been returned in the response to a similar GET request | |||
(without the If-Match header) on that resource, or if "*" is given | (without the If-Match header) on that resource, or if "*" is given | |||
and any current entity exists for that resource, then the server MAY | and any current entity exists for that resource, then the server MAY | |||
perform the requested method as if the If-Match header field did not | perform the requested method as if the If-Match header field did not | |||
exist. | exist. | |||
A server MUST use the strong comparison function (see Section 13.3.3) | A server MUST use the strong comparison function (see Section 13.3.3) | |||
to compare the entity tags in If-Match. | to compare the entity tags in If-Match. | |||
skipping to change at page 137, line 38 ¶ | skipping to change at page 141, line 52 ¶ | |||
The result of a request having both an If-Match header field and | The result of a request having both an If-Match header field and | |||
either an If-None-Match or an If-Modified-Since header fields is | either an If-None-Match or an If-Modified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
14.25. If-Modified-Since | 14.25. If-Modified-Since | |||
The If-Modified-Since request-header field is used with a method to | The If-Modified-Since request-header field is used with a method to | |||
make it conditional: if the requested variant has not been modified | make it conditional: if the requested variant has not been modified | |||
since the time specified in this field, an entity will not be | since the time specified in this field, an entity will not be | |||
returned from the server; instead, a 304 (not modified) response will | returned from the server; instead, a 304 (Not Modified) response will | |||
be returned without any message-body. | be returned without any message-body. | |||
If-Modified-Since = "If-Modified-Since" ":" HTTP-date | If-Modified-Since = "If-Modified-Since" ":" HTTP-date | |||
An example of the field is: | An example of the field is: | |||
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
A GET method with an If-Modified-Since header and no Range header | A GET method with an If-Modified-Since header and no Range header | |||
requests that the identified entity be transferred only if it has | requests that the identified entity be transferred only if it has | |||
been modified since the date given by the If-Modified-Since header. | been modified since the date given by the If-Modified-Since header. | |||
The algorithm for determining this includes the following cases: | The algorithm for determining this includes the following cases: | |||
skipping to change at page 139, line 20 ¶ | skipping to change at page 143, line 32 ¶ | |||
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-None-Match header field. The purpose of this feature is to allow | If-None-Match header field. The purpose of this feature is to allow | |||
efficient updates of cached information with a minimum amount of | efficient updates of cached information with a minimum amount of | |||
transaction overhead. It is also used to prevent a method (e.g. | transaction overhead. It is also used to prevent a method (e.g. | |||
PUT) from inadvertently modifying an existing resource when the | PUT) from inadvertently modifying an existing resource when the | |||
client believes that the resource does not exist. | client believes that the resource does not exist. | |||
As a special case, the value "*" matches any current entity of the | As a special case, the value "*" matches any current entity of the | |||
resource. | resource. | |||
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) | |||
If any of the entity tags match the entity tag of the entity that | If any of the entity tags match the entity tag of the entity that | |||
would have been returned in the response to a similar GET request | would have been returned in the response to a similar GET request | |||
(without the If-None-Match header) on that resource, or if "*" is | (without the If-None-Match header) on that resource, or if "*" is | |||
given and any current entity exists for that resource, then the | given and any current entity exists for that resource, then the | |||
server MUST NOT perform the requested method, unless required to do | server MUST NOT perform the requested method, unless required to do | |||
so because the resource's modification date fails to match that | so because the resource's modification date fails to match that | |||
supplied in an If-Modified-Since header field in the request. | supplied in an If-Modified-Since header field in the request. | |||
Instead, if the request method was GET or HEAD, the server SHOULD | Instead, if the request method was GET or HEAD, the server SHOULD | |||
respond with a 304 (Not Modified) response, including the cache- | respond with a 304 (Not Modified) response, including the cache- | |||
skipping to change at page 140, line 36 ¶ | skipping to change at page 144, line 49 ¶ | |||
either or both of If-Unmodified-Since and If-Match.) However, if the | either or both of If-Unmodified-Since and If-Match.) However, if the | |||
condition fails because the entity has been modified, the client | condition fails because the entity has been modified, the client | |||
would then have to make a second request to obtain the entire current | would then have to make a second request to obtain the entire current | |||
entity-body. | entity-body. | |||
The If-Range header allows a client to "short-circuit" the second | The If-Range header allows a client to "short-circuit" the second | |||
request. Informally, its meaning is `if the entity is unchanged, | request. Informally, its meaning is `if the entity is unchanged, | |||
send me the part(s) that I am missing; otherwise, send me the entire | send me the part(s) that I am missing; otherwise, send me the entire | |||
new entity'. | new entity'. | |||
If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) | |||
If the client has no entity tag for an entity, but does have a Last- | If the client has no entity tag for an entity, but does have a Last- | |||
Modified date, it MAY use that date in an If-Range header. (The | Modified date, it MAY use that date in an If-Range header. (The | |||
server can distinguish between a valid HTTP-date and any form of | server can distinguish between a valid HTTP-date and any form of | |||
entity-tag by examining no more than two characters.) The If-Range | entity-tag by examining no more than two characters.) The If-Range | |||
header SHOULD only be used together with a Range header, and MUST be | header SHOULD only be used together with a Range header, and MUST be | |||
ignored if the request does not include a Range header, or if the | ignored if the request does not include a Range header, or if the | |||
server does not support the sub-range operation. | server does not support the sub-range operation. | |||
If the entity tag given in the If-Range header matches the current | If the entity tag given in the If-Range header matches the current | |||
entity tag for the entity, then the server SHOULD provide the | entity tag for the entity, then the server SHOULD provide the | |||
specified sub-range of the entity using a 206 (Partial content) | specified sub-range of the entity using a 206 (Partial Content) | |||
response. If the entity tag does not match, then the server SHOULD | response. If the entity tag does not match, then the server SHOULD | |||
return the entire entity using a 200 (OK) response. | return the entire entity using a 200 (OK) response. | |||
14.28. If-Unmodified-Since | 14.28. If-Unmodified-Since | |||
The If-Unmodified-Since request-header field is used with a method to | The If-Unmodified-Since request-header field is used with a method to | |||
make it conditional. If the requested resource has not been modified | make it conditional. If the requested resource has not been modified | |||
since the time specified in this field, the server SHOULD perform the | since the time specified in this field, the server SHOULD perform the | |||
requested operation as if the If-Unmodified-Since header were not | requested operation as if the If-Unmodified-Since header were not | |||
present. | present. | |||
If the requested variant has been modified since the specified time, | If the requested variant has been modified since the specified time, | |||
the server MUST NOT perform the requested operation, and MUST return | the server MUST NOT perform the requested operation, and MUST return | |||
a 412 (Precondition Failed). | a 412 (Precondition Failed). | |||
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date | |||
An example of the field is: | An example of the field is: | |||
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
If the request normally (i.e., without the If-Unmodified-Since | If the request normally (i.e., without the If-Unmodified-Since | |||
header) would result in anything other than a 2xx or 412 status, the | header) would result in anything other than a 2xx or 412 status, the | |||
If-Unmodified-Since header SHOULD be ignored. | If-Unmodified-Since header SHOULD be ignored. | |||
If the specified date is invalid, the header is ignored. | If the specified date is invalid, the header is ignored. | |||
The result of a request having both an If-Unmodified-Since header | The result of a request having both an If-Unmodified-Since header | |||
field and either an If-None-Match or an If-Modified-Since header | field and either an If-None-Match or an If-Modified-Since header | |||
fields is undefined by this specification. | fields is undefined by this specification. | |||
14.29. Last-Modified | 14.29. Last-Modified | |||
The Last-Modified entity-header field indicates the date and time at | The Last-Modified entity-header field indicates the date and time at | |||
which the origin server believes the variant was last modified. | which the origin server believes the variant was last modified. | |||
Last-Modified = "Last-Modified" ":" HTTP-date | Last-Modified = "Last-Modified" ":" HTTP-date | |||
An example of its use is | An example of its use is | |||
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |||
The exact meaning of this header field depends on the implementation | The exact meaning of this header field depends on the implementation | |||
of the origin server and the nature of the original resource. For | of the origin server and the nature of the original resource. For | |||
files, it may be just the file system last-modified time. For | files, it may be just the file system last-modified time. For | |||
entities with dynamically included parts, it may be the most recent | entities with dynamically included parts, it may be the most recent | |||
of the set of last-modify times for its component parts. For | of the set of last-modify times for its component parts. For | |||
skipping to change at page 142, line 29 ¶ | skipping to change at page 146, line 42 ¶ | |||
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 | |||
The Max-Forwards value is a decimal integer indicating the remaining | The Max-Forwards value is a decimal integer indicating the remaining | |||
number of times this request message may be forwarded. | number of times this request message may be forwarded. | |||
Each proxy or gateway recipient of a TRACE or OPTIONS request | Each proxy or gateway recipient of a TRACE or OPTIONS request | |||
containing a Max-Forwards header field MUST check and update its | containing a Max-Forwards header field MUST check and update its | |||
value prior to forwarding the request. If the received value is zero | value prior to forwarding the request. If the received value is zero | |||
(0), the recipient MUST NOT forward the request; instead, it MUST | (0), the recipient MUST NOT forward the request; instead, it MUST | |||
respond as the final recipient. If the received Max-Forwards value | respond as the final recipient. If the received Max-Forwards value | |||
is greater than zero, then the forwarded message MUST contain an | is greater than zero, then the forwarded message MUST contain an | |||
skipping to change at page 143, line 28 ¶ | skipping to change at page 148, line 5 ¶ | |||
it is not explicitly referred to as part of that method definition. | it is not explicitly referred to as part of that method definition. | |||
14.32. Pragma | 14.32. Pragma | |||
The Pragma general-header field is used to include implementation- | The Pragma general-header field is used to include implementation- | |||
specific directives that might apply to any recipient along the | specific directives that might apply to any recipient along the | |||
request/response chain. All pragma directives specify optional | request/response chain. All pragma directives specify optional | |||
behavior from the viewpoint of the protocol; however, some systems | behavior from the viewpoint of the protocol; however, some systems | |||
MAY require that behavior be consistent with the directives. | MAY require that behavior be consistent with the directives. | |||
Pragma = "Pragma" ":" 1#pragma-directive | Pragma = "Pragma" ":" 1#pragma-directive | |||
pragma-directive = "no-cache" | extension-pragma | pragma-directive = "no-cache" | extension-pragma | |||
extension-pragma = token [ "=" ( token | quoted-string ) ] | extension-pragma = token [ "=" ( token | quoted-string ) ] | |||
When the no-cache directive is present in a request message, an | When the no-cache directive is present in a request message, an | |||
application SHOULD forward the request toward the origin server even | application SHOULD forward the request toward the origin server even | |||
if it has a cached copy of what is being requested. This pragma | if it has a cached copy of what is being requested. This pragma | |||
directive has the same semantics as the no-cache cache-directive (see | directive has the same semantics as the no-cache cache-directive (see | |||
Section 14.9) and is defined here for backward compatibility with | Section 14.9) and is defined here for backward compatibility with | |||
HTTP/1.0. Clients SHOULD include both header fields when a no-cache | HTTP/1.0. Clients SHOULD include both header fields when a no-cache | |||
request is sent to a server not known to be HTTP/1.1 compliant. | request is sent to a server not known to be HTTP/1.1 compliant. | |||
Pragma directives MUST be passed through by a proxy or gateway | Pragma directives MUST be passed through by a proxy or gateway | |||
skipping to change at page 144, line 13 ¶ | skipping to change at page 148, line 39 ¶ | |||
header field is not actually specified, it does not provide a | header field is not actually specified, it does not provide a | |||
reliable replacement for "Cache-Control: no-cache" in a response | reliable replacement for "Cache-Control: no-cache" in a response | |||
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.) | |||
Byte range specifications in HTTP apply to the sequence of bytes in | Byte range specifications in HTTP apply to the sequence of bytes in | |||
the entity-body (not necessarily the same as the message-body). | the entity-body (not necessarily the same as the message-body). | |||
A byte range operation MAY specify a single range of bytes, or a set | A byte range operation MAY specify a single range of bytes, or a set | |||
of ranges within a single entity. | of ranges within a single entity. | |||
ranges-specifier = byte-ranges-specifier | ranges-specifier = byte-ranges-specifier | |||
byte-ranges-specifier = bytes-unit "=" byte-range-set | byte-ranges-specifier = bytes-unit "=" byte-range-set | |||
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec ) | |||
byte-range-spec = first-byte-pos "-" [last-byte-pos] | byte-range-spec = first-byte-pos "-" [last-byte-pos] | |||
first-byte-pos = 1*DIGIT | first-byte-pos = 1*DIGIT | |||
last-byte-pos = 1*DIGIT | last-byte-pos = 1*DIGIT | |||
The first-byte-pos value in a byte-range-spec gives the byte-offset | The first-byte-pos value in a byte-range-spec gives the byte-offset | |||
of the first byte in a range. The last-byte-pos value gives the | of the first byte in a range. The last-byte-pos value gives the | |||
byte-offset of the last byte in the range; that is, the byte | byte-offset of the last byte in the range; that is, the byte | |||
positions specified are inclusive. Byte offsets start at zero. | positions specified are inclusive. Byte offsets start at zero. | |||
If the last-byte-pos value is present, it MUST be greater than or | If the last-byte-pos value is present, it MUST be greater than or | |||
equal to the first-byte-pos in that byte-range-spec, or the byte- | equal to the first-byte-pos in that byte-range-spec, or the byte- | |||
range-spec is syntactically invalid. The recipient of a byte-range- | range-spec is syntactically invalid. The recipient of a byte-range- | |||
set that includes one or more syntactically invalid byte-range-spec | set that includes one or more syntactically invalid byte-range-spec | |||
skipping to change at page 145, line 39 ¶ | skipping to change at page 150, line 20 ¶ | |||
set. | set. | |||
If the last-byte-pos value is absent, or if the value is greater than | If the last-byte-pos value is absent, or if the value is greater than | |||
or equal to the current length of the entity-body, last-byte-pos is | or equal to the current length of the entity-body, last-byte-pos is | |||
taken to be equal to one less than the current length of the entity- | taken to be equal to one less than the current length of the entity- | |||
body in bytes. | body in bytes. | |||
By its choice of last-byte-pos, a client can limit the number of | By its choice of last-byte-pos, a client can limit the number of | |||
bytes retrieved without knowing the size of the entity. | bytes retrieved without knowing the size of the entity. | |||
suffix-byte-range-spec = "-" suffix-length | suffix-byte-range-spec = "-" suffix-length | |||
suffix-length = 1*DIGIT | suffix-length = 1*DIGIT | |||
A suffix-byte-range-spec is used to specify the suffix of the entity- | A suffix-byte-range-spec is used to specify the suffix of the entity- | |||
body, of a length given by the suffix-length value. (That is, this | body, of a length given by the suffix-length value. (That is, this | |||
form specifies the last N bytes of an entity-body.) If the entity is | form specifies the last N bytes of an entity-body.) If the entity is | |||
shorter than the specified suffix-length, the entire entity-body is | shorter than the specified suffix-length, the entire entity-body is | |||
used. | used. | |||
If a syntactically valid byte-range-set includes at least one byte- | If a syntactically valid byte-range-set includes at least one byte- | |||
range-spec whose first-byte-pos is less than the current length of | range-spec whose first-byte-pos is less than the current length of | |||
the entity-body, or at least one suffix-byte-range-spec with a non- | the entity-body, or at least one suffix-byte-range-spec with a non- | |||
skipping to change at page 146, line 23 ¶ | skipping to change at page 151, line 4 ¶ | |||
o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 | o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 | |||
o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- | o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- | |||
999 | 999 | |||
o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- | o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- | |||
500 | 500 | |||
o Or bytes=9500- | o Or bytes=9500- | |||
o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 | o The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1 | |||
o Several legal but not canonical specifications of the second 500 | o Several legal but not canonical specifications of the second 500 | |||
bytes (byte offsets 500-999, inclusive): | bytes (byte offsets 500-999, inclusive): | |||
bytes=500-600,601-999 | bytes=500-600,601-999 | |||
bytes=500-700,601-999 | bytes=500-700,601-999 | |||
14.35.2. Range Retrieval Requests | 14.35.2. Range Retrieval Requests | |||
HTTP retrieval requests using conditional or unconditional GET | HTTP retrieval requests using conditional or unconditional GET | |||
methods MAY request one or more sub-ranges of the entity, instead of | methods MAY request one or more sub-ranges of the entity, instead of | |||
the entire entity, using the Range request header, which applies to | the entire entity, using the Range request header, which applies to | |||
the entity returned as the result of the request: | the entity returned as the result of the request: | |||
Range = "Range" ":" ranges-specifier | Range = "Range" ":" ranges-specifier | |||
A server MAY ignore the Range header. However, HTTP/1.1 origin | A server MAY ignore the Range header. However, HTTP/1.1 origin | |||
servers and intermediate caches ought to support byte ranges when | servers and intermediate caches ought to support byte ranges when | |||
possible, since Range supports efficient recovery from partially | possible, since Range supports efficient recovery from partially | |||
failed transfers, and supports efficient partial retrieval of large | failed transfers, and supports efficient partial retrieval of large | |||
entities. | entities. | |||
If the server supports the Range header and the specified range or | If the server supports the Range header and the specified range or | |||
ranges are appropriate for the entity: | ranges are appropriate for the entity: | |||
skipping to change at page 147, line 33 ¶ | skipping to change at page 152, line 17 ¶ | |||
The Referer[sic] request-header field allows the client to specify, | The Referer[sic] request-header field allows the client to specify, | |||
for the server's benefit, the address (URI) of the resource from | for the server's benefit, the address (URI) of the resource from | |||
which the Request-URI was obtained (the "referrer", although the | which the Request-URI was obtained (the "referrer", although the | |||
header field is misspelled.) The Referer request-header allows a | header field is misspelled.) The Referer request-header allows a | |||
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 | |||
with any 3xx (Redirection) response to indicate the minimum time the | with any 3xx (Redirection) response to indicate the minimum time the | |||
user-agent is asked wait before issuing the redirected request. The | user-agent is asked wait before issuing the redirected request. The | |||
value of this field can be either an HTTP-date or an integer number | value of this field can be either an HTTP-date or an integer number | |||
of seconds (in decimal) after the time of the response. | of seconds (in decimal) after the time of the response. | |||
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) | |||
Two examples of its use are | Two examples of its use are | |||
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | |||
Retry-After: 120 | Retry-After: 120 | |||
In the latter example, the delay is 2 minutes. | In the latter example, the delay is 2 minutes. | |||
14.38. Server | 14.38. Server | |||
The Server response-header field contains information about the | The Server response-header field contains information about the | |||
software used by the origin server to handle the request. The field | software used by the origin server to handle the request. The field | |||
can contain multiple product tokens (Section 3.8) and comments | can contain multiple product tokens (Section 3.8) and comments | |||
identifying the server and any significant subproducts. The product | identifying the server and any significant subproducts. The product | |||
tokens are listed in order of their significance for identifying the | tokens are listed in order of their significance for identifying the | |||
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 | |||
it is willing to accept in the response and whether or not it is | it is willing to accept in the response and whether or not it is | |||
willing to accept trailer fields in a chunked transfer-coding. Its | willing to accept trailer fields in a chunked transfer-coding. Its | |||
value may consist of the keyword "trailers" and/or a comma-separated | value may consist of the keyword "trailers" and/or a comma-separated | |||
list of extension transfer-coding names with optional accept | list of extension transfer-coding names with optional accept | |||
parameters (as described in Section 3.6). | parameters (as described in Section 3.6). | |||
TE = "TE" ":" #( t-codings ) | TE = "TE" ":" #( t-codings ) | |||
t-codings = "trailers" | ( transfer-extension [ accept-params ] ) | t-codings = "trailers" | ( transfer-extension [ accept-params ] ) | |||
The presence of the keyword "trailers" indicates that the client is | The presence of the keyword "trailers" indicates that the client is | |||
willing to accept trailer fields in a chunked transfer-coding, as | willing to accept trailer fields in a chunked transfer-coding, as | |||
defined in Section 3.6.1. This keyword is reserved for use with | defined in Section 3.6.1. This keyword is reserved for use with | |||
transfer-coding values even though it does not itself represent a | transfer-coding values even though it does not itself represent a | |||
transfer-coding. | transfer-coding. | |||
Examples of its use are: | Examples of its use are: | |||
TE: deflate | TE: deflate | |||
skipping to change at page 150, line 5 ¶ | skipping to change at page 154, line 37 ¶ | |||
If the TE field-value is empty or if no TE field is present, the only | If the TE field-value is empty or if no TE field is present, the only | |||
transfer-coding is "chunked". A message with no transfer-coding is | transfer-coding is "chunked". A message with no transfer-coding is | |||
always acceptable. | always acceptable. | |||
14.40. Trailer | 14.40. Trailer | |||
The Trailer general field value indicates that the given set of | The Trailer general field value indicates that the given set of | |||
header fields is present in the trailer of a message encoded with | header fields is present in the trailer of a message encoded with | |||
chunked transfer-coding. | chunked transfer-coding. | |||
Trailer = "Trailer" ":" 1#field-name | Trailer = "Trailer" ":" 1#field-name | |||
An HTTP/1.1 message SHOULD include a Trailer header field in a | An HTTP/1.1 message SHOULD include a Trailer header field in a | |||
message using chunked transfer-coding with a non-empty trailer. | message using chunked transfer-coding with a non-empty trailer. | |||
Doing so allows the recipient to know which header fields to expect | Doing so allows the recipient to know which header fields to expect | |||
in the trailer. | in the trailer. | |||
If no Trailer header field is present, the trailer SHOULD NOT include | If no Trailer header field is present, the trailer SHOULD NOT include | |||
any header fields. See Section 3.6.1 for restrictions on the use of | any header fields. See Section 3.6.1 for restrictions on the use of | |||
trailer fields in a "chunked" transfer-coding. | trailer fields in a "chunked" transfer-coding. | |||
skipping to change at page 151, line 6 ¶ | skipping to change at page 155, line 38 ¶ | |||
Encoding header. | Encoding header. | |||
14.42. Upgrade | 14.42. Upgrade | |||
The Upgrade general-header allows the client to specify what | The Upgrade general-header allows the client to specify what | |||
additional communication protocols it supports and would like to use | additional communication protocols it supports and would like to use | |||
if the server finds it appropriate to switch protocols. The server | if the server finds it appropriate to switch protocols. The server | |||
MUST use the Upgrade header field within a 101 (Switching Protocols) | MUST use the Upgrade header field within a 101 (Switching Protocols) | |||
response to indicate which protocol(s) are being switched. | response to indicate which protocol(s) are being switched. | |||
Upgrade = "Upgrade" ":" 1#product | Upgrade = "Upgrade" ":" 1#product | |||
For example, | For example, | |||
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | |||
The Upgrade header field is intended to provide a simple mechanism | The Upgrade header field is intended to provide a simple mechanism | |||
for transition from HTTP/1.1 to some other, incompatible protocol. | for transition from HTTP/1.1 to some other, incompatible protocol. | |||
It does so by allowing the client to advertise its desire to use | It does so by allowing the client to advertise its desire to use | |||
another protocol, such as a later version of HTTP with a higher major | another protocol, such as a later version of HTTP with a higher major | |||
version number, even though the current request has been made using | version number, even though the current request has been made using | |||
skipping to change at page 152, line 18 ¶ | skipping to change at page 156, line 46 ¶ | |||
user agent originating the request. This is for statistical | user agent originating the request. This is for statistical | |||
purposes, the tracing of protocol violations, and automated | purposes, the tracing of protocol violations, and automated | |||
recognition of user agents for the sake of tailoring responses to | recognition of user agents for the sake of tailoring responses to | |||
avoid particular user agent limitations. User agents SHOULD include | avoid particular user agent limitations. User agents SHOULD include | |||
this field with requests. The field can contain multiple product | this field with requests. The field can contain multiple product | |||
tokens (Section 3.8) and comments identifying the agent and any | tokens (Section 3.8) and comments identifying the agent and any | |||
subproducts which form a significant part of the user agent. By | subproducts which form a significant part of the user agent. By | |||
convention, the product tokens are listed in order of their | convention, the product tokens are listed in order of their | |||
significance for identifying the application. | significance for identifying the application. | |||
User-Agent = "User-Agent" ":" 1*( product | comment ) | User-Agent = "User-Agent" ":" 1*( product | comment ) | |||
Example: | Example: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
14.44. Vary | 14.44. Vary | |||
The Vary field value indicates the set of request-header fields that | The Vary field value indicates the set of request-header fields that | |||
fully determines, while the response is fresh, whether a cache is | fully determines, while the response is fresh, whether a cache is | |||
permitted to use the response to reply to a subsequent request | permitted to use the response to reply to a subsequent request | |||
without revalidation. For uncacheable or stale responses, the Vary | without revalidation. For uncacheable or stale responses, the Vary | |||
field value advises the user agent about the criteria that were used | field value advises the user agent about the criteria that were used | |||
to select the representation. A Vary field value of "*" implies that | to select the representation. A Vary field value of "*" implies that | |||
a cache cannot determine from the request headers of a subsequent | a cache cannot determine from the request headers of a subsequent | |||
request whether this response is the appropriate representation. See | request whether this response is the appropriate representation. See | |||
Section 13.6 for use of the Vary header field by caches. | Section 13.6 for use of the Vary header field by caches. | |||
Vary = "Vary" ":" ( "*" | 1#field-name ) | Vary = "Vary" ":" ( "*" | 1#field-name ) | |||
An HTTP/1.1 server SHOULD include a Vary header field with any | An HTTP/1.1 server SHOULD include a Vary header field with any | |||
cacheable response that is subject to server-driven negotiation. | cacheable response that is subject to server-driven negotiation. | |||
Doing so allows a cache to properly interpret future requests on that | Doing so allows a cache to properly interpret future requests on that | |||
resource and informs the user agent about the presence of negotiation | resource and informs the user agent about the presence of negotiation | |||
on that resource. A server MAY include a Vary header field with a | on that resource. A server MAY include a Vary header field with a | |||
non-cacheable response that is subject to server-driven negotiation, | non-cacheable response that is subject to server-driven negotiation, | |||
since this might provide the user agent with useful information about | since this might provide the user agent with useful information about | |||
the dimensions over which the response varies at the time of the | the dimensions over which the response varies at the time of the | |||
response. | response. | |||
skipping to change at page 153, line 23 ¶ | skipping to change at page 158, line 4 ¶ | |||
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, | ||||
[RFC2822] and is intended to be used for tracking message forwards, | ||||
avoiding request loops, and identifying the protocol capabilities of | avoiding request loops, and identifying the protocol capabilities of | |||
all senders along the request/response chain. | all senders along the request/response chain. | |||
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
received-by = ( host [ ":" port ] ) | pseudonym | received-by = ( uri-host [ ":" port ] ) | pseudonym | |||
pseudonym = token | pseudonym = token | |||
The received-protocol indicates the protocol version of the message | The received-protocol indicates the protocol version of the message | |||
received by the server or client along each segment of the request/ | received by the server or client along each segment of the request/ | |||
response chain. The received-protocol version is appended to the Via | response chain. The received-protocol version is appended to the Via | |||
field value when the message is forwarded so that information about | field value when the message is forwarded so that information about | |||
the protocol capabilities of upstream applications remains visible to | the protocol capabilities of upstream applications remains visible to | |||
all recipients. | all recipients. | |||
The protocol-name is optional if and only if it would be "HTTP". The | The protocol-name is optional if and only if it would be "HTTP". The | |||
received-by field is normally the host and optional port number of a | received-by field is normally the host and optional port number of a | |||
skipping to change at page 155, line 5 ¶ | skipping to change at page 159, line 35 ¶ | |||
The Warning general-header field is used to carry additional | The Warning general-header field is used to carry additional | |||
information about the status or transformation of a message which | information about the status or transformation of a message which | |||
might not be reflected in the message. This information is typically | might not be reflected in the message. This information is typically | |||
used to warn about a possible lack of semantic transparency from | used to warn about a possible lack of semantic transparency from | |||
caching operations or transformations applied to the entity body of | caching operations or transformations applied to the entity body of | |||
the message. | the message. | |||
Warning headers are sent with responses using: | Warning headers are sent with responses using: | |||
Warning = "Warning" ":" 1#warning-value | Warning = "Warning" ":" 1#warning-value | |||
warning-value = warn-code SP warn-agent SP warn-text | warning-value = warn-code SP warn-agent SP warn-text | |||
[SP warn-date] | [SP warn-date] | |||
warn-code = 3DIGIT | warn-code = 3DIGIT | |||
warn-agent = ( host [ ":" port ] ) | pseudonym | warn-agent = ( uri-host [ ":" port ] ) | pseudonym | |||
; the name or pseudonym of the server adding | ; the name or pseudonym of the server adding | |||
; the Warning header, for use in debugging | ; the Warning header, for use in debugging | |||
warn-text = quoted-string | warn-text = quoted-string | |||
warn-date = <"> HTTP-date <"> | warn-date = DQUOTE HTTP-date DQUOTE | |||
A response MAY carry more than one Warning header. | A response MAY carry more than one Warning header. | |||
The warn-text SHOULD be in a natural language and character set that | The warn-text SHOULD be in a natural language and character set that | |||
is most likely to be intelligible to the human user receiving the | is most likely to be intelligible to the human user receiving the | |||
response. This decision MAY be based on any available knowledge, | response. This decision MAY be based on any available knowledge, | |||
such as the location of the cache or user, the Accept-Language field | such as the location of the cache or user, the Accept-Language field | |||
in a request, the Content-Language field in a response, etc. The | in a request, the Content-Language field in a response, etc. The | |||
default language is English and the default character set is ISO- | default language is English and the default character set is ISO- | |||
8859-1. | 8859-1. | |||
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 30 ¶ | skipping to change at page 162, line 12 ¶ | |||
of the warning-values are deleted for this reason, the Warning header | of the warning-values are deleted for this reason, the Warning header | |||
MUST be deleted as well. | MUST be deleted as well. | |||
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 [RFC822ABNF]. Similarly, | |||
it reuses many of the definitions provided by Nathaniel Borenstein | it reuses many of the definitions provided by Nathaniel Borenstein | |||
and Ned Freed for MIME [7]. We hope that their inclusion in this | and Ned Freed for MIME [RFC2045]. We hope that their inclusion in | |||
specification will help reduce past confusion over the relationship | this specification will help reduce past confusion over the | |||
between HTTP and Internet mail message formats. | relationship 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. | |||
16.2. (This Document) | ||||
This document has benefited greatly from the comments of all those | ||||
participating in the HTTP-WG. In particular, we thank Scott Lawrence | ||||
for maintaining the RFC2616 Errata list, and Mark Baker, David Booth, | ||||
Adrien de Croy, Martin Duerst, Roy Fielding, Hugo Haas, Bjoern | ||||
Hoehrmann, Brian Kell, Jamie Lokier, Paul Marquess, Larry Masinter, | ||||
Howard Melman, Alexey Melnikov, Jeff Mogul, Henrik Nordstrom, Joe | ||||
Orton, Alex Rousskov, Travis Snoozy and Dan Winship for further | ||||
contributions. | ||||
17. References | 17. References | |||
[1] Alvestrand, H., "Tags for the Identification of Languages", | 17.1. Normative References | |||
RFC 1766, March 1995. | ||||
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | [ISO-8859-1] | |||
D., and B. Alberti, "The Internet Gopher Protocol (a | International Organization for Standardization, | |||
distributed document search and retrieval protocol)", RFC 1436, | "Information technology -- 8-bit single-byte coded graphic | |||
March 1993. | character sets -- Part 1: Latin alphabet No. 1", ISO/ | |||
IEC 8859-1:1998, 1998. | ||||
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", | |||
Unifying Syntax for the Expression of Names and Addresses of | RFC 1864, October 1995. | |||
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 | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | |||
Resource Locators (URL)", RFC 1738, December 1994. | Specification version 3.3", RFC 1950, May 1996. | |||
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - | RFC1950 is an Informational RFC, thus it may be less | |||
2.0", RFC 1866, November 1995. | stable than this specification. On the other hand, this | |||
downward reference was present since [RFC2068] (published | ||||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[6] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | version 1.3", RFC 1951, May 1996. | |||
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | RFC1951 is an Informational RFC, thus it may be less | |||
Extensions (MIME) Part One: Format of Internet Message Bodies", | stable than this specification. On the other hand, this | |||
RFC 2045, November 1996. | downward reference was present since [RFC2068] (published | |||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[8] Braden, R., "Requirements for Internet Hosts - Application and | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | |||
Support", STD 3, RFC 1123, October 1989. | Randers-Pehrson, "GZIP file format specification version | |||
4.3", RFC 1952, May 1996. | ||||
[9] Crocker, D., "Standard for the format of ARPA Internet text | RFC1952 is an Informational RFC, thus it may be less | |||
messages", STD 11, RFC 822, August 1982. | stable than this specification. On the other hand, this | |||
downward reference was present since [RFC2068] (published | ||||
in 1997), therefore it is unlikely to cause problems in | ||||
practice. | ||||
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol | Extensions (MIME) Part One: Format of Internet Message | |||
Prototype Functional Specification (v1.5)", Thinking Machines | Bodies", RFC 2045, November 1996. | |||
Corporation , April 1990. | ||||
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
June 1995. | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
November 1996. | ||||
[12] Horton, M. and R. Adams, "Standard for interchange of USENET | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | |||
messages", RFC 1036, December 1987. | Part Three: Message Header Extensions for Non-ASCII Text", | |||
RFC 2047, November 1996. | ||||
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
RFC 977, February 1986. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |||
November 1996. | August 1998. | |||
[15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |||
RFC 1867, November 1995. | Leach, P., Luotonen, A., and L. Stewart, "HTTP | |||
Authentication: Basic and Digest Access Authentication", | ||||
RFC 2617, June 1999. | ||||
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | |||
August 1982. | April 2001. | |||
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, | [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and | |||
November 1996. | Registration Procedures", BCP 13, RFC 4288, December 2005. | |||
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, | [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying | |||
RFC 959, October 1985. | Languages", BCP 47, RFC 4646, September 2006. | |||
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, | [RFC822ABNF] | |||
RFC 1700, October 1994. | Crocker, D., "Standard for the format of ARPA Internet | |||
text messages", STD 11, RFC 822, August 1982. | ||||
[20] Masinter, L. and K. Sollins, "Functional Requirements for | [USASCII] American National Standards Institute, "Coded Character | |||
Uniform Resource Names", RFC 1737, December 1994. | Set -- 7-bit American Standard Code for Information | |||
Interchange", ANSI X3.4, 1986. | ||||
[21] American National Standards Institute, "Coded Character Set -- | 17.2. Informative References | |||
7-bit American Standard Code for Information Interchange", | ||||
ANSI X3.4, 1986. | ||||
[22] International Organization for Standardization, "Information | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web | |||
technology - 8-bit single byte coded graphic - character sets", | proxy servers", draft-luotonen-web-proxy-tunneling-01 | |||
1987-1990. | (work in progress), August 1998. | |||
Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and | |||
alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, | |||
3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, | and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , | |||
1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part | Sep 1997. | |||
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", | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | |||
RFC 1864, October 1995. | Computer Networks and ISDN Systems v. 28, pp. 25-35, | |||
Dec 1995. | ||||
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | Slightly revised version of paper in Proc. 2nd | |||
RFC 1900, February 1996. | International WWW Conference '94: Mosaic and the Web, Oct. | |||
1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ | ||||
IT94/Proceedings/DDay/mogul/HTTPLatency.html>. | ||||
[25] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application | |||
Randers-Pehrson, "GZIP file format specification version 4.3", | and Support", STD 3, RFC 1123, October 1989. | |||
RFC 1952, May 1996. | ||||
[26] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | [RFC1305] Mills, D., "Network Time Protocol (Version 3) | |||
Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995. | Specification, Implementation", RFC 1305, March 1992. | |||
Slightly revised version of paper in Proc. 2nd International | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., | |||
WWW Conference '94: Mosaic and the Web, Oct. 1994, which is | Torrey, D., and B. Alberti, "The Internet Gopher Protocol | |||
available at <http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/ | (a distributed document search and retrieval protocol)", | |||
DDay/mogul/HTTPLatency.html>. | RFC 1436, March 1993. | |||
[27] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of HTTP | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | |||
Performance", ISI Research Report ISI/RR-98-463 (original | Unifying Syntax for the Expression of Names and Addresses | |||
report dated Aug.1996), Aug 1998, | of Objects on the Network as used in the World-Wide Web", | |||
<http://www.isi.edu/touch/pubs/http-perf96/>. | RFC 1630, June 1994. | |||
[28] Mills, D., "Network Time Protocol (Version 3) Specification, | [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for | |||
Implementation", RFC 1305, March 1992. | Uniform Resource Names", RFC 1737, December 1994. | |||
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | |||
version 1.3", RFC 1951, May 1996. | Resource Locators (URL)", RFC 1738, December 1994. | |||
[30] Spero, S., "Analysis of HTTP Performance Problems", | [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation | |||
<http://sunsite.unc.edu/mdma-release/http-prob.html>. | Information in Internet Messages: The Content-Disposition | |||
Header", RFC 1806, June 1995. | ||||
[31] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", | |||
Specification version 3.3", RFC 1950, May 1996. | RFC 1808, June 1995. | |||
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | |||
Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : | RFC 1900, February 1996. | |||
Digest Access Authentication", RFC 2069, January 1997. | ||||
[33] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
RFC 2068, January 1997. | ||||
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision | |||
Levels", BCP 14, RFC 2119, March 1997. | 3", BCP 9, RFC 2026, October 1996. | |||
[35] Troost, R. and S. Dorner, "Communicating Presentation | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Information in Internet Messages: The Content-Disposition | Extensions (MIME) Part Five: Conformance Criteria and | |||
Header", RFC 1806, June 1995. | Examples", RFC 2049, November 1996. | |||
[36] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
Interpretation of HTTP Version Numbers", RFC 2145, May 1997. | ||||
[37] Palme, J., "Common Internet Message Headers", RFC 2076, | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | |||
February 1997. | RFC 2068, January 1997. | |||
[38] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, | |||
RFC 2279, January 1998. | February 1997. | |||
[39] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use | |||
Lilley, "Network Performance Effects of HTTP/1.1, CSS1, and | and Interpretation of HTTP Version Numbers", RFC 2145, | |||
PNG", Proceedings of ACM SIGCOMM '97, Cannes France , Sep 1997. | May 1997. | |||
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating | |||
Extensions (MIME) Part Two: Media Types", RFC 2046, | Presentation Information in Internet Messages: The | |||
November 1996. | Content-Disposition Header Field", RFC 2183, August 1997. | |||
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
BCP 18, RFC 2277, January 1998. | Languages", BCP 18, RFC 2277, January 1998. | |||
[42] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |||
Resource Identifiers (URI): Generic Syntax", RFC 2396, | (HTCPCP/1.0)", RFC 2324, April 1998. | |||
August 1998. | ||||
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ | |||
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: | form-data", RFC 2388, August 1998. | |||
Basic and Digest Access Authentication", RFC 2617, June 1999. | ||||
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy | [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, | |||
servers", Work in Progress. | "MIME Encapsulation of Aggregate Documents, such as HTML | |||
(MHTML)", RFC 2557, March 1999. | ||||
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Aggregate Documents, such as HTML (MHTML)", RFC 2110, | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
March 1997. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[46] Bradner, S., "The Internet Standards Process -- Revision 3", | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |||
BCP 9, RFC 2026, October 1996. | April 2001. | |||
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
(HTCPCP/1.0)", RFC 2324, April 1998. | 10646", RFC 3629, STD 63, November 2003. | |||
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", | |||
Extensions (MIME) Part Five: Conformance Criteria and | RFC 3977, October 2006. | |||
Examples", RFC 2049, November 1996. | ||||
[49] Troost, R., Dorner, S., and K. Moore, "Communicating | [RFC822] Crocker, D., "Standard for the format of ARPA Internet | |||
Presentation Information in Internet Messages: The Content- | text messages", STD 11, RFC 822, August 1982. | |||
Disposition Header Field", RFC 2183, August 1997. | ||||
Appendix A. Appendices | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", | |||
STD 9, RFC 959, October 1985. | ||||
A.1. Internet Media Type message/http and application/http | [Spero] Spero, S., "Analysis of HTTP Performance Problems", | |||
<http://sunsite.unc.edu/mdma-release/http-prob.html>. | ||||
[Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of | ||||
HTTP Performance", USC/ISI ISI/RR-98-463, Dec 1998, | ||||
<http://www.isi.edu/touch/pubs/http-perf96/>. | ||||
(Original report dated Aug. 1996) | ||||
[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. | ||||
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 [RFC4288]. | |||
Media Type name: message | Type name: message | |||
Media subtype name: http | Subtype name: http | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed message (e.g., | version: The HTTP-Version number of the enclosed message (e.g., | |||
"1.1"). If not present, the version can be determined from the | "1.1"). If not present, the version can be determined from the | |||
first line of the body. | first line of the body. | |||
msgtype: The message type -- "request" or "response". If not | msgtype: The message type -- "request" or "response". If not | |||
present, the type can be determined from the first line of the | present, the type can be determined from the first line of the | |||
body. | body. | |||
Encoding considerations: only "7bit", "8bit", or "binary" are | Encoding considerations: only "7bit", "8bit", or "binary" are | |||
permitted | permitted | |||
Security considerations: none | Security considerations: none | |||
Media Type name: application | Interoperability considerations: none | |||
Media subtype name: http | Published specification: This specification (see Appendix A). | |||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
Type name: application | ||||
Subtype name: http | ||||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed messages (e.g., | version: The HTTP-Version number of the enclosed messages (e.g., | |||
"1.1"). If not present, the version can be determined from the | "1.1"). If not present, the version can be determined from the | |||
first line of the body. | first line of the body. | |||
msgtype: The message type -- "request" or "response". If not | msgtype: The message type -- "request" or "response". If not | |||
present, the type can be determined from the first line of the | present, the type can be determined from the first line of the | |||
body. | body. | |||
Encoding considerations: HTTP messages enclosed by this type are in | Encoding considerations: HTTP messages enclosed by this type are in | |||
"binary" format; use of an appropriate Content-Transfer-Encoding | "binary" format; use of an appropriate Content-Transfer-Encoding | |||
is required when transmitted via E-mail. | is required when transmitted via E-mail. | |||
Security considerations: none | Security considerations: none | |||
A.2. Internet Media Type multipart/byteranges | Interoperability considerations: none | |||
Published specification: This specification (see Appendix A). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
Appendix B. Internet Media Type multipart/byteranges | ||||
When an HTTP 206 (Partial Content) response message includes the | When an HTTP 206 (Partial Content) response message includes the | |||
content of multiple ranges (a response to a request for multiple non- | content of multiple ranges (a response to a request for multiple non- | |||
overlapping ranges), these are transmitted as a multipart message- | overlapping ranges), these are transmitted as a multipart message- | |||
body. The media type for this purpose is called "multipart/ | body. The media type for this purpose is called "multipart/ | |||
byteranges". | byteranges". | |||
The multipart/byteranges media type includes two or more parts, each | The multipart/byteranges media type includes two or more parts, each | |||
with its own Content-Type and Content-Range fields. The required | with its own Content-Type and Content-Range fields. The required | |||
boundary parameter specifies the boundary string used to separate | boundary parameter specifies the boundary string used to separate | |||
each body-part. | each body-part. | |||
Media Type name: multipart | Type name: multipart | |||
Media subtype name: byteranges | Subtype name: byteranges | |||
Required parameters: boundary | Required parameters: boundary | |||
Optional parameters: none | Optional parameters: none | |||
Encoding considerations: only "7bit", "8bit", or "binary" are | Encoding considerations: only "7bit", "8bit", or "binary" are | |||
permitted | permitted | |||
Security considerations: none | Security considerations: none | |||
Interoperability considerations: none | ||||
Published specification: This specification (see Appendix B). | ||||
Applications that use this media type: | ||||
Additional information: | ||||
Magic number(s): none | ||||
File extension(s): none | ||||
Macintosh file type code(s): none | ||||
Person and email address to contact for further information: See | ||||
Authors Section. | ||||
Intended usage: COMMON | ||||
Restrictions on usage: none | ||||
Author/Change controller: IESG | ||||
For example: | For example: | |||
HTTP/1.1 206 Partial Content | HTTP/1.1 206 Partial Content | |||
Date: Wed, 15 Nov 1995 06:25:24 GMT | Date: Wed, 15 Nov 1995 06:25:24 GMT | |||
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT | |||
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES | |||
--THIS_STRING_SEPARATES | --THIS_STRING_SEPARATES | |||
Content-type: application/pdf | Content-type: application/pdf | |||
Content-range: bytes 500-999/8000 | Content-range: bytes 500-999/8000 | |||
skipping to change at page 172, line 28 ¶ | skipping to change at page 181, line 32 ¶ | |||
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 |