rfc2616-orig.txt | draft-rfc2616bis-00.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding | Network Working Group Y. Lafon | |||
Request for Comments: 2616 UC Irvine | Internet-Draft W3C | |||
Obsoletes: 2068 J. Gettys | Obsoletes: 2616 (if approved) J. Reschke | |||
Category: Standards Track Compaq/W3C | Intended status: Standards Track greenbytes | |||
J. Mogul | Expires: April 16, 2007 October 13, 2006 | |||
Compaq | ||||
H. Frystyk | ||||
W3C/MIT | ||||
L. Masinter | ||||
Xerox | ||||
P. Leach | ||||
Microsoft | ||||
T. Berners-Lee | ||||
W3C/MIT | ||||
June 1999 | ||||
Hypertext Transfer Protocol -- HTTP/1.1 | Hypertext Transfer Protocol -- HTTP/1.1 | |||
draft-lafon-rfc2616bis-00 | ||||
Status of this Memo | Status of this Memo | |||
This document specifies an Internet standards track protocol for the | By submitting this Internet-Draft, each author represents that any | |||
Internet community, and requests discussion and suggestions for | applicable patent or other IPR claims of which he or she is aware | |||
improvements. Please refer to the current edition of the "Internet | have been or will be disclosed, and any of which he or she becomes | |||
Official Protocol Standards" (STD 1) for the standardization state | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on April 16, 2007. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (1999). All Rights Reserved. | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. It is a generic, stateless, protocol which can be used for | systems. It is a generic, stateless, protocol which can be used for | |||
many tasks beyond its use for hypertext, such as name servers and | many tasks beyond its use for hypertext, such as name servers and | |||
distributed object management systems, through extension of its | distributed object management systems, through extension of its | |||
request methods, error codes and headers [47]. A feature of HTTP is | request methods, error codes and headers [47]. A feature of HTTP is | |||
the typing and negotiation of data representation, allowing systems | the typing and negotiation of data representation, allowing systems | |||
to be built independently of the data being transferred. | to be built independently of the data being transferred. | |||
HTTP has been in use by the World-Wide Web global information | HTTP has been in use by the World-Wide Web global information | |||
initiative since 1990. This specification defines the protocol | initiative since 1990. This specification defines the protocol | |||
referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. | referred to as "HTTP/1.1", and is an update to RFC2616. | |||
Editorial Note (To be removed by RFC Editor before publication) | ||||
Distribution of this document is unlimited. Please send comments to | ||||
the Hypertext Transfer Protocol (HTTP) mailing list at | ||||
ietf-http-wg@w3.org [51], which may be joined by sending a message | ||||
with subject "subscribe" to ietf-http-wg-request@w3.org [52]. | ||||
Discussions of the HTTP working group are archived at | ||||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. XML versions, | ||||
latest edits and the issues list for this document are available from | ||||
<http://www.w3.org/Protocols/HTTP/1.1/>. | ||||
The purpose of this document is to revise RFC2616 ([50]), doing only | ||||
minimal corrections. For now, it is not planned to advance the | ||||
standards level of HTTP, thus - if published - the specification will | ||||
still be a "Proposed Standard" (see [46]). | ||||
The current plan is to incorporate known errata, and to update the | ||||
specification text according to the current IETF publication | ||||
guidelines. In particular: | ||||
o Incorporate the corrections collected in the RFC2616 errata | ||||
document (<http://skrb.org/ietf/http_errata.html>) and potentially | ||||
newly discovered and agreed-upon errata. | ||||
o Update references, and re-classify them into "Normative" and | ||||
"Informative", based on the prior work done by Jim Gettys in | ||||
<http://tools.ietf.org/html/draft-gettys-http-v11-spec-rev-00>. | ||||
This document is based on a variant of the original RFC2616 | ||||
specification formatted using Marshall T. Rose's "xml2rfc" tool (see | ||||
<http://xml.resource.org>) and therefore deviates from the original | ||||
text in word wrapping, page breaks, list formatting, reference | ||||
formatting, whitespace usage and appendix numbering. Otherwise, it | ||||
is supposed to contain an accurate copy of the original specification | ||||
text. See <http://www.w3.org/Protocols/HTTP/1.1/ | ||||
rfc2616bis-00-from-rfc2616.diff.html> for a comparison between both | ||||
documents, as generated by "rfcdiff" | ||||
(<http://tools.ietf.org/tools/rfcdiff/>). | ||||
Table of Contents | Table of Contents | |||
1 Introduction ...................................................7 | 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.1 Purpose......................................................7 | 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.2 Requirements .................................................8 | 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1.3 Terminology ..................................................8 | 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1.4 Overall Operation ...........................................12 | 1.4 Overall Operation . . . . . . . . . . . . . . . . . . . . 15 | |||
2 Notational Conventions and Generic Grammar ....................14 | 2 Notational Conventions and Generic Grammar . . . . . . . . . 18 | |||
2.1 Augmented BNF ...............................................14 | 2.1 Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 18 | |||
2.2 Basic Rules .................................................15 | 2.2 Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
3 Protocol Parameters ...........................................17 | 3 Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.1 HTTP Version ................................................17 | 3.1 HTTP Version . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.2 Uniform Resource Identifiers ................................18 | 3.2 Uniform Resource Identifiers . . . . . . . . . . . . . . 23 | |||
3.2.1 General Syntax ...........................................19 | 3.2.1 General Syntax . . . . . . . . . . . . . . . . . . . 23 | |||
3.2.2 http URL .................................................19 | 3.2.2 http URL . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3.2.3 URI Comparison ...........................................20 | 3.2.3 URI Comparison . . . . . . . . . . . . . . . . . . . 24 | |||
3.3 Date/Time Formats ...........................................20 | 3.3 Date/Time Formats . . . . . . . . . . . . . . . . . . . . 24 | |||
3.3.1 Full Date ................................................20 | 3.3.1 Full Date . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.3.2 Delta Seconds ............................................21 | 3.3.2 Delta Seconds . . . . . . . . . . . . . . . . . . . . 26 | |||
3.4 Character Sets ..............................................21 | 3.4 Character Sets . . . . . . . . . . . . . . . . . . . . . 26 | |||
3.4.1 Missing Charset ..........................................22 | 3.4.1 Missing Charset . . . . . . . . . . . . . . . . . . . 27 | |||
3.5 Content Codings .............................................23 | 3.5 Content Codings . . . . . . . . . . . . . . . . . . . . . 27 | |||
3.6 Transfer Codings ............................................24 | 3.6 Transfer Codings . . . . . . . . . . . . . . . . . . . . 28 | |||
3.6.1 Chunked Transfer Coding ..................................25 | 3.6.1 Chunked Transfer Coding . . . . . . . . . . . . . . . 29 | |||
3.7 Media Types .................................................26 | 3.7 Media Types . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
3.7.1 Canonicalization and Text Defaults .......................27 | 3.7.1 Canonicalization and Text Defaults . . . . . . . . . 31 | |||
3.7.2 Multipart Types ..........................................27 | 3.7.2 Multipart Types . . . . . . . . . . . . . . . . . . . 32 | |||
3.8 Product Tokens ..............................................28 | 3.8 Product Tokens . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.9 Quality Values ..............................................29 | 3.9 Quality Values . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.10 Language Tags ...............................................29 | 3.10 Language Tags . . . . . . . . . . . . . . . . . . . . . . 34 | |||
3.11 Entity Tags .................................................30 | 3.11 Entity Tags . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
3.12 Range Units .................................................30 | 3.12 Range Units . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
4 HTTP Message ..................................................31 | 4 HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
4.1 Message Types ...............................................31 | 4.1 Message Types . . . . . . . . . . . . . . . . . . . . . . 36 | |||
4.2 Message Headers .............................................31 | 4.2 Message Headers . . . . . . . . . . . . . . . . . . . . . 36 | |||
4.3 Message Body ................................................32 | 4.3 Message Body . . . . . . . . . . . . . . . . . . . . . . 37 | |||
4.4 Message Length ..............................................33 | 4.4 Message Length . . . . . . . . . . . . . . . . . . . . . 38 | |||
4.5 General Header Fields .......................................34 | 4.5 General Header Fields . . . . . . . . . . . . . . . . . . 39 | |||
5 Request .......................................................35 | 5 Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1 Request-Line ................................................35 | 5.1 Request-Line . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1.1 Method ...................................................36 | 5.1.1 Method . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.1.2 Request-URI ..............................................36 | 5.1.2 Request-URI . . . . . . . . . . . . . . . . . . . . . 42 | |||
5.2 The Resource Identified by a Request ........................38 | 5.2 The Resource Identified by a Request . . . . . . . . . . 43 | |||
5.3 Request Header Fields .......................................38 | 5.3 Request Header Fields . . . . . . . . . . . . . . . . . . 44 | |||
6 Response ......................................................39 | 6 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6.1 Status-Line .................................................39 | 6.1 Status-Line . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
6.1.1 Status Code and Reason Phrase ............................39 | 6.1.1 Status Code and Reason Phrase . . . . . . . . . . . . 45 | |||
6.2 Response Header Fields ......................................41 | 6.2 Response Header Fields . . . . . . . . . . . . . . . . . 48 | |||
7 Entity ........................................................42 | 7 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.1 Entity Header Fields ........................................42 | 7.1 Entity Header Fields . . . . . . . . . . . . . . . . . . 49 | |||
7.2 Entity Body .................................................43 | 7.2 Entity Body . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
7.2.1 Type .....................................................43 | 7.2.1 Type . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
7.2.2 Entity Length ............................................43 | 7.2.2 Entity Length . . . . . . . . . . . . . . . . . . . . 50 | |||
8 Connections ...................................................44 | 8 Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
8.1 Persistent Connections ......................................44 | 8.1 Persistent Connections . . . . . . . . . . . . . . . . . 51 | |||
8.1.1 Purpose ..................................................44 | 8.1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
8.1.2 Overall Operation ........................................45 | 8.1.2 Overall Operation . . . . . . . . . . . . . . . . . . 51 | |||
8.1.3 Proxy Servers ............................................46 | 8.1.3 Proxy Servers . . . . . . . . . . . . . . . . . . . . 53 | |||
8.1.4 Practical Considerations .................................46 | 8.1.4 Practical Considerations . . . . . . . . . . . . . . 53 | |||
8.2 Message Transmission Requirements ...........................47 | 8.2 Message Transmission Requirements . . . . . . . . . . . . 54 | |||
8.2.1 Persistent Connections and Flow Control ..................47 | 8.2.1 Persistent Connections and Flow Control . . . . . . . 54 | |||
8.2.2 Monitoring Connections for Error Status Messages .........48 | 8.2.2 Monitoring Connections for Error Status Messages . . 54 | |||
8.2.3 Use of the 100 (Continue) Status .........................48 | 8.2.3 Use of the 100 (Continue) Status . . . . . . . . . . 55 | |||
8.2.4 Client Behavior if Server Prematurely Closes Connection ..50 | 8.2.4 Client Behavior if Server Prematurely Closes | |||
9 Method Definitions ............................................51 | Connection . . . . . . . . . . . . . . . . . . . . . 57 | |||
9.1 Safe and Idempotent Methods .................................51 | 9 Method Definitions . . . . . . . . . . . . . . . . . . . . . 58 | |||
9.1.1 Safe Methods .............................................51 | 9.1 Safe and Idempotent Methods . . . . . . . . . . . . . . . 58 | |||
9.1.2 Idempotent Methods .......................................51 | 9.1.1 Safe Methods . . . . . . . . . . . . . . . . . . . . 58 | |||
9.2 OPTIONS .....................................................52 | 9.1.2 Idempotent Methods . . . . . . . . . . . . . . . . . 58 | |||
9.3 GET .........................................................53 | 9.2 OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 59 | |||
9.4 HEAD ........................................................54 | 9.3 GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
9.5 POST ........................................................54 | 9.4 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
9.6 PUT .........................................................55 | 9.5 POST . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
9.7 DELETE ......................................................56 | 9.6 PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
9.8 TRACE .......................................................56 | 9.7 DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9.9 CONNECT .....................................................57 | 9.8 TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
10 Status Code Definitions ......................................57 | 9.9 CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
10.1 Informational 1xx ...........................................57 | 10 Status Code Definitions . . . . . . . . . . . . . . . . . . . 65 | |||
10.1.1 100 Continue .............................................58 | 10.1 Informational 1xx . . . . . . . . . . . . . . . . . . . . 65 | |||
10.1.2 101 Switching Protocols ..................................58 | 10.1.1 100 Continue . . . . . . . . . . . . . . . . . . . . 65 | |||
10.2 Successful 2xx ..............................................58 | 10.1.2 101 Switching Protocols . . . . . . . . . . . . . . . 65 | |||
10.2.1 200 OK ...................................................58 | 10.2 Successful 2xx . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.2 201 Created ..............................................59 | 10.2.1 200 OK . . . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.3 202 Accepted .............................................59 | 10.2.2 201 Created . . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.4 203 Non-Authoritative Information ........................59 | 10.2.3 202 Accepted . . . . . . . . . . . . . . . . . . . . 66 | |||
10.2.5 204 No Content ...........................................60 | 10.2.4 203 Non-Authoritative Information . . . . . . . . . . 67 | |||
10.2.6 205 Reset Content ........................................60 | 10.2.5 204 No Content . . . . . . . . . . . . . . . . . . . 67 | |||
10.2.7 206 Partial Content ......................................60 | 10.2.6 205 Reset Content . . . . . . . . . . . . . . . . . . 67 | |||
10.3 Redirection 3xx .............................................61 | 10.2.7 206 Partial Content . . . . . . . . . . . . . . . . . 68 | |||
10.3.1 300 Multiple Choices .....................................61 | 10.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 68 | |||
10.3.2 301 Moved Permanently ....................................62 | 10.3.1 300 Multiple Choices . . . . . . . . . . . . . . . . 69 | |||
10.3.3 302 Found ................................................62 | 10.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . 69 | |||
10.3.4 303 See Other ............................................63 | 10.3.3 302 Found . . . . . . . . . . . . . . . . . . . . . . 70 | |||
10.3.5 304 Not Modified .........................................63 | 10.3.4 303 See Other . . . . . . . . . . . . . . . . . . . . 70 | |||
10.3.6 305 Use Proxy ............................................64 | 10.3.5 304 Not Modified . . . . . . . . . . . . . . . . . . 71 | |||
10.3.7 306 (Unused) .............................................64 | 10.3.6 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 71 | |||
10.3.8 307 Temporary Redirect ...................................65 | 10.3.7 306 (Unused) . . . . . . . . . . . . . . . . . . . . 72 | |||
10.4 Client Error 4xx ............................................65 | 10.3.8 307 Temporary Redirect . . . . . . . . . . . . . . . 72 | |||
10.4.1 400 Bad Request .........................................65 | 10.4 Client Error 4xx . . . . . . . . . . . . . . . . . . . . 72 | |||
10.4.2 401 Unauthorized ........................................66 | 10.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . 73 | |||
10.4.3 402 Payment Required ....................................66 | 10.4.2 401 Unauthorized . . . . . . . . . . . . . . . . . . 73 | |||
10.4.4 403 Forbidden ...........................................66 | 10.4.3 402 Payment Required . . . . . . . . . . . . . . . . 73 | |||
10.4.5 404 Not Found ...........................................66 | 10.4.4 403 Forbidden . . . . . . . . . . . . . . . . . . . . 73 | |||
10.4.6 405 Method Not Allowed ..................................66 | 10.4.5 404 Not Found . . . . . . . . . . . . . . . . . . . . 73 | |||
10.4.7 406 Not Acceptable ......................................67 | 10.4.6 405 Method Not Allowed . . . . . . . . . . . . . . . 74 | |||
10.4.8 407 Proxy Authentication Required .......................67 | 10.4.7 406 Not Acceptable . . . . . . . . . . . . . . . . . 74 | |||
10.4.9 408 Request Timeout .....................................67 | 10.4.8 407 Proxy Authentication Required . . . . . . . . . . 74 | |||
10.4.10 409 Conflict ............................................67 | 10.4.9 408 Request Timeout . . . . . . . . . . . . . . . . . 75 | |||
10.4.11 410 Gone ................................................68 | 10.4.10 409 Conflict . . . . . . . . . . . . . . . . . . . . 75 | |||
10.4.12 411 Length Required .....................................68 | 10.4.11 410 Gone . . . . . . . . . . . . . . . . . . . . . . 75 | |||
10.4.13 412 Precondition Failed .................................68 | 10.4.12 411 Length Required . . . . . . . . . . . . . . . . . 76 | |||
10.4.14 413 Request Entity Too Large ............................69 | 10.4.13 412 Precondition Failed . . . . . . . . . . . . . . . 76 | |||
10.4.15 414 Request-URI Too Long ................................69 | 10.4.14 413 Request Entity Too Large . . . . . . . . . . . . 76 | |||
10.4.16 415 Unsupported Media Type ..............................69 | 10.4.15 414 Request-URI Too Long . . . . . . . . . . . . . . 76 | |||
10.4.17 416 Requested Range Not Satisfiable .....................69 | 10.4.16 415 Unsupported Media Type . . . . . . . . . . . . . 76 | |||
10.4.18 417 Expectation Failed ..................................70 | 10.4.17 416 Requested Range Not Satisfiable . . . . . . . . . 76 | |||
10.5 Server Error 5xx ............................................70 | 10.4.18 417 Expectation Failed . . . . . . . . . . . . . . . 77 | |||
10.5.1 500 Internal Server Error ................................70 | 10.5 Server Error 5xx . . . . . . . . . . . . . . . . . . . . 77 | |||
10.5.2 501 Not Implemented ......................................70 | 10.5.1 500 Internal Server Error . . . . . . . . . . . . . . 77 | |||
10.5.3 502 Bad Gateway ..........................................70 | 10.5.2 501 Not Implemented . . . . . . . . . . . . . . . . . 77 | |||
10.5.4 503 Service Unavailable ..................................70 | 10.5.3 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 77 | |||
10.5.5 504 Gateway Timeout ......................................71 | 10.5.4 503 Service Unavailable . . . . . . . . . . . . . . . 78 | |||
10.5.6 505 HTTP Version Not Supported ...........................71 | 10.5.5 504 Gateway Timeout . . . . . . . . . . . . . . . . . 78 | |||
11 Access Authentication ........................................71 | 10.5.6 505 HTTP Version Not Supported . . . . . . . . . . . 78 | |||
12 Content Negotiation ..........................................71 | 11 Access Authentication . . . . . . . . . . . . . . . . . . . . 79 | |||
12.1 Server-driven Negotiation ...................................72 | 12 Content Negotiation . . . . . . . . . . . . . . . . . . . . . 80 | |||
12.2 Agent-driven Negotiation ....................................73 | 12.1 Server-driven Negotiation . . . . . . . . . . . . . . . . 80 | |||
12.3 Transparent Negotiation .....................................74 | 12.2 Agent-driven Negotiation . . . . . . . . . . . . . . . . 81 | |||
13 Caching in HTTP ..............................................74 | 12.3 Transparent Negotiation . . . . . . . . . . . . . . . . . 82 | |||
13.1.1 Cache Correctness ........................................75 | 13 Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 83 | |||
13.1.2 Warnings .................................................76 | 13.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
13.1.3 Cache-control Mechanisms .................................77 | 13.1.1 Cache Correctness . . . . . . . . . . . . . . . . . . 84 | |||
13.1.4 Explicit User Agent Warnings .............................78 | 13.1.2 Warnings . . . . . . . . . . . . . . . . . . . . . . 85 | |||
13.1.5 Exceptions to the Rules and Warnings .....................78 | 13.1.3 Cache-control Mechanisms . . . . . . . . . . . . . . 86 | |||
13.1.6 Client-controlled Behavior ...............................79 | 13.1.4 Explicit User Agent Warnings . . . . . . . . . . . . 86 | |||
13.2 Expiration Model ............................................79 | 13.1.5 Exceptions to the Rules and Warnings . . . . . . . . 87 | |||
13.2.1 Server-Specified Expiration ..............................79 | 13.1.6 Client-controlled Behavior . . . . . . . . . . . . . 87 | |||
13.2.2 Heuristic Expiration .....................................80 | 13.2 Expiration Model . . . . . . . . . . . . . . . . . . . . 88 | |||
13.2.3 Age Calculations .........................................80 | 13.2.1 Server-Specified Expiration . . . . . . . . . . . . . 88 | |||
13.2.4 Expiration Calculations ..................................83 | 13.2.2 Heuristic Expiration . . . . . . . . . . . . . . . . 88 | |||
13.2.5 Disambiguating Expiration Values .........................84 | 13.2.3 Age Calculations . . . . . . . . . . . . . . . . . . 89 | |||
13.2.6 Disambiguating Multiple Responses ........................84 | 13.2.4 Expiration Calculations . . . . . . . . . . . . . . . 91 | |||
13.3 Validation Model ............................................85 | 13.2.5 Disambiguating Expiration Values . . . . . . . . . . 92 | |||
13.3.1 Last-Modified Dates ......................................86 | 13.2.6 Disambiguating Multiple Responses . . . . . . . . . . 93 | |||
13.3.2 Entity Tag Cache Validators ..............................86 | 13.3 Validation Model . . . . . . . . . . . . . . . . . . . . 93 | |||
13.3.3 Weak and Strong Validators ...............................86 | 13.3.1 Last-Modified Dates . . . . . . . . . . . . . . . . . 94 | |||
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89 | 13.3.2 Entity Tag Cache Validators . . . . . . . . . . . . . 94 | |||
13.3.5 Non-validating Conditionals ..............................90 | 13.3.3 Weak and Strong Validators . . . . . . . . . . . . . 95 | |||
13.4 Response Cacheability .......................................91 | 13.3.4 Rules for When to Use Entity Tags and | |||
13.5 Constructing Responses From Caches ..........................92 | Last-Modified Dates . . . . . . . . . . . . . . . . . 97 | |||
13.5.1 End-to-end and Hop-by-hop Headers ........................92 | 13.3.5 Non-validating Conditionals . . . . . . . . . . . . . 99 | |||
13.5.2 Non-modifiable Headers ...................................92 | 13.4 Response Cacheability . . . . . . . . . . . . . . . . . . 99 | |||
13.5.3 Combining Headers ........................................94 | 13.5 Constructing Responses From Caches . . . . . . . . . . . 100 | |||
13.5.4 Combining Byte Ranges ....................................95 | 13.5.1 End-to-end and Hop-by-hop Headers . . . . . . . . . . 100 | |||
13.6 Caching Negotiated Responses ................................95 | 13.5.2 Non-modifiable Headers . . . . . . . . . . . . . . . 101 | |||
13.7 Shared and Non-Shared Caches ................................96 | 13.5.3 Combining Headers . . . . . . . . . . . . . . . . . . 102 | |||
13.8 Errors or Incomplete Response Cache Behavior ................97 | 13.5.4 Combining Byte Ranges . . . . . . . . . . . . . . . . 103 | |||
13.9 Side Effects of GET and HEAD ................................97 | 13.6 Caching Negotiated Responses . . . . . . . . . . . . . . 104 | |||
13.10 Invalidation After Updates or Deletions ...................97 | 13.7 Shared and Non-Shared Caches . . . . . . . . . . . . . . 105 | |||
13.11 Write-Through Mandatory ...................................98 | 13.8 Errors or Incomplete Response Cache Behavior . . . . . . 105 | |||
13.12 Cache Replacement .........................................99 | 13.9 Side Effects of GET and HEAD . . . . . . . . . . . . . . 106 | |||
13.13 History Lists .............................................99 | 13.10 Invalidation After Updates or Deletions . . . . . . . . . 106 | |||
14 Header Field Definitions ....................................100 | 13.11 Write-Through Mandatory . . . . . . . . . . . . . . . . . 107 | |||
14.1 Accept .....................................................100 | 13.12 Cache Replacement . . . . . . . . . . . . . . . . . . . . 107 | |||
14.2 Accept-Charset .............................................102 | 13.13 History Lists . . . . . . . . . . . . . . . . . . . . . . 108 | |||
14.3 Accept-Encoding ............................................102 | 14 Header Field Definitions . . . . . . . . . . . . . . . . . . 109 | |||
14.4 Accept-Language ............................................104 | 14.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . 109 | |||
14.5 Accept-Ranges ..............................................105 | 14.2 Accept-Charset . . . . . . . . . . . . . . . . . . . . . 111 | |||
14.6 Age ........................................................106 | 14.3 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 111 | |||
14.7 Allow ......................................................106 | 14.4 Accept-Language . . . . . . . . . . . . . . . . . . . . . 113 | |||
14.8 Authorization ..............................................107 | 14.5 Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 114 | |||
14.9 Cache-Control ..............................................108 | 14.6 Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 | |||
14.9.1 What is Cacheable .......................................109 | 14.7 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 115 | |||
14.9.2 What May be Stored by Caches ............................110 | 14.8 Authorization . . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.9.3 Modifications of the Basic Expiration Mechanism .........111 | 14.9 Cache-Control . . . . . . . . . . . . . . . . . . . . . . 116 | |||
14.9.4 Cache Revalidation and Reload Controls ..................113 | 14.9.1 What is Cacheable . . . . . . . . . . . . . . . . . . 118 | |||
14.9.5 No-Transform Directive ..................................115 | 14.9.2 What May be Stored by Caches . . . . . . . . . . . . 119 | |||
14.9.6 Cache Control Extensions ................................116 | 14.9.3 Modifications of the Basic Expiration Mechanism . . . 120 | |||
14.10 Connection ...............................................117 | 14.9.4 Cache Revalidation and Reload Controls . . . . . . . 122 | |||
14.11 Content-Encoding .........................................118 | 14.9.5 No-Transform Directive . . . . . . . . . . . . . . . 125 | |||
14.12 Content-Language .........................................118 | 14.9.6 Cache Control Extensions . . . . . . . . . . . . . . 125 | |||
14.13 Content-Length ...........................................119 | 14.10 Connection . . . . . . . . . . . . . . . . . . . . . . . 126 | |||
14.14 Content-Location .........................................120 | 14.11 Content-Encoding . . . . . . . . . . . . . . . . . . . . 127 | |||
14.15 Content-MD5 ..............................................121 | 14.12 Content-Language . . . . . . . . . . . . . . . . . . . . 128 | |||
14.16 Content-Range ............................................122 | 14.13 Content-Length . . . . . . . . . . . . . . . . . . . . . 128 | |||
14.17 Content-Type .............................................124 | 14.14 Content-Location . . . . . . . . . . . . . . . . . . . . 129 | |||
14.18 Date .....................................................124 | 14.15 Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 130 | |||
14.18.1 Clockless Origin Server Operation ......................125 | 14.16 Content-Range . . . . . . . . . . . . . . . . . . . . . . 131 | |||
14.19 ETag .....................................................126 | 14.17 Content-Type . . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.20 Expect ...................................................126 | 14.18 Date . . . . . . . . . . . . . . . . . . . . . . . . . . 133 | |||
14.21 Expires ..................................................127 | 14.18.1 Clockless Origin Server Operation . . . . . . . . . . 134 | |||
14.22 From .....................................................128 | 14.19 ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 135 | |||
14.23 Host .....................................................128 | 14.20 Expect . . . . . . . . . . . . . . . . . . . . . . . . . 135 | |||
14.24 If-Match .................................................129 | 14.21 Expires . . . . . . . . . . . . . . . . . . . . . . . . . 136 | |||
14.25 If-Modified-Since ........................................130 | 14.22 From . . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.26 If-None-Match ............................................132 | 14.23 Host . . . . . . . . . . . . . . . . . . . . . . . . . . 137 | |||
14.27 If-Range .................................................133 | 14.24 If-Match . . . . . . . . . . . . . . . . . . . . . . . . 138 | |||
14.28 If-Unmodified-Since ......................................134 | 14.25 If-Modified-Since . . . . . . . . . . . . . . . . . . . . 139 | |||
14.29 Last-Modified ............................................134 | 14.26 If-None-Match . . . . . . . . . . . . . . . . . . . . . . 141 | |||
14.30 Location .................................................135 | 14.27 If-Range . . . . . . . . . . . . . . . . . . . . . . . . 142 | |||
14.31 Max-Forwards .............................................136 | 14.28 If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 143 | |||
14.32 Pragma ...................................................136 | 14.29 Last-Modified . . . . . . . . . . . . . . . . . . . . . . 143 | |||
14.33 Proxy-Authenticate .......................................137 | 14.30 Location . . . . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.34 Proxy-Authorization ......................................137 | 14.31 Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 144 | |||
14.35 Range ....................................................138 | 14.32 Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 145 | |||
14.35.1 Byte Ranges ...........................................138 | 14.33 Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 146 | |||
14.35.2 Range Retrieval Requests ..............................139 | 14.34 Proxy-Authorization . . . . . . . . . . . . . . . . . . . 146 | |||
14.36 Referer ..................................................140 | 14.35 Range . . . . . . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.37 Retry-After ..............................................141 | 14.35.1 Byte Ranges . . . . . . . . . . . . . . . . . . . . . 147 | |||
14.38 Server ...................................................141 | 14.35.2 Range Retrieval Requests . . . . . . . . . . . . . . 148 | |||
14.39 TE .......................................................142 | 14.36 Referer . . . . . . . . . . . . . . . . . . . . . . . . . 149 | |||
14.40 Trailer ..................................................143 | 14.37 Retry-After . . . . . . . . . . . . . . . . . . . . . . . 150 | |||
14.41 Transfer-Encoding..........................................143 | 14.38 Server . . . . . . . . . . . . . . . . . . . . . . . . . 150 | |||
14.42 Upgrade ..................................................144 | 14.39 TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 | |||
14.43 User-Agent ...............................................145 | 14.40 Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 152 | |||
14.44 Vary .....................................................145 | 14.41 Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 152 | |||
14.45 Via ......................................................146 | 14.42 Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 153 | |||
14.46 Warning ..................................................148 | 14.43 User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
14.47 WWW-Authenticate .........................................150 | 14.44 Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 154 | |||
15 Security Considerations .......................................150 | 14.45 Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 | |||
15.1 Personal Information....................................151 | 14.46 Warning . . . . . . . . . . . . . . . . . . . . . . . . . 157 | |||
15.1.1 Abuse of Server Log Information .........................151 | 14.47 WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 159 | |||
15.1.2 Transfer of Sensitive Information .......................151 | 15 Security Considerations . . . . . . . . . . . . . . . . . . . 160 | |||
15.1.3 Encoding Sensitive Information in URI's .................152 | 15.1 Personal Information . . . . . . . . . . . . . . . . . . 160 | |||
15.1.4 Privacy Issues Connected to Accept Headers ..............152 | 15.1.1 Abuse of Server Log Information . . . . . . . . . . . 160 | |||
15.2 Attacks Based On File and Path Names .......................153 | 15.1.2 Transfer of Sensitive Information . . . . . . . . . . 160 | |||
15.3 DNS Spoofing ...............................................154 | 15.1.3 Encoding Sensitive Information in URI's . . . . . . . 161 | |||
15.4 Location Headers and Spoofing ..............................154 | 15.1.4 Privacy Issues Connected to Accept Headers . . . . . 162 | |||
15.5 Content-Disposition Issues .................................154 | 15.2 Attacks Based On File and Path Names . . . . . . . . . . 162 | |||
15.6 Authentication Credentials and Idle Clients ................155 | 15.3 DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 163 | |||
15.7 Proxies and Caching ........................................155 | 15.4 Location Headers and Spoofing . . . . . . . . . . . . . . 163 | |||
15.7.1 Denial of Service Attacks on Proxies....................156 | 15.5 Content-Disposition Issues . . . . . . . . . . . . . . . 164 | |||
16 Acknowledgments .............................................156 | 15.6 Authentication Credentials and Idle Clients . . . . . . . 164 | |||
17 References ..................................................158 | 15.7 Proxies and Caching . . . . . . . . . . . . . . . . . . . 164 | |||
18 Authors' Addresses ..........................................162 | 15.7.1 Denial of Service Attacks on Proxies . . . . . . . . 165 | |||
19 Appendices ..................................................164 | 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 166 | |||
19.1 Internet Media Type message/http and application/http ......164 | 16.1 (RFC2616) . . . . . . . . . . . . . . . . . . . . . . . . 166 | |||
19.2 Internet Media Type multipart/byteranges ...................165 | 16.2 (This Document) . . . . . . . . . . . . . . . . . . . . . 168 | |||
19.3 Tolerant Applications ......................................166 | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167 | 17.1 References . . . . . . . . . . . . . . . . . . . . . . . 169 | |||
19.4.1 MIME-Version ............................................167 | 17.2 Normative References . . . . . . . . . . . . . . . . . . 172 | |||
19.4.2 Conversion to Canonical Form ............................167 | Appendix A Internet Media Type message/http and | |||
19.4.3 Conversion of Date Formats ..............................168 | application/http . . . . . . . . . . . . . . . . . . 174 | |||
19.4.4 Introduction of Content-Encoding ........................168 | Appendix B Internet Media Type multipart/byteranges . . . . . . 176 | |||
19.4.5 No Content-Transfer-Encoding ............................168 | Appendix C Tolerant Applications . . . . . . . . . . . . . . . . 178 | |||
19.4.6 Introduction of Transfer-Encoding .......................169 | Appendix D Differences Between HTTP Entities and RFC 2045 | |||
19.4.7 MHTML and Line Length Limitations .......................169 | Entities . . . . . . . . . . . . . . . . . . . . . . 179 | |||
19.5 Additional Features ........................................169 | D.1 MIME-Version . . . . . . . . . . . . . . . . . . . . . . 179 | |||
19.5.1 Content-Disposition .....................................170 | D.2 Conversion to Canonical Form . . . . . . . . . . . . . . 179 | |||
19.6 Compatibility with Previous Versions .......................170 | D.3 Conversion of Date Formats . . . . . . . . . . . . . . . 180 | |||
19.6.1 Changes from HTTP/1.0 ...................................171 | D.4 Introduction of Content-Encoding . . . . . . . . . . . . 180 | |||
19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172 | D.5 No Content-Transfer-Encoding . . . . . . . . . . . . . . 180 | |||
19.6.3 Changes from RFC 2068 ...................................172 | D.6 Introduction of Transfer-Encoding . . . . . . . . . . . . 181 | |||
20 Index .......................................................175 | D.7 MHTML and Line Length Limitations . . . . . . . . . . . . 181 | |||
21 Full Copyright Statement ....................................176 | Appendix E Additional Features . . . . . . . . . . . . . . . . . 182 | |||
E.1 Content-Disposition . . . . . . . . . . . . . . . . . . . 182 | ||||
Appendix F Compatibility with Previous Versions . . . . . . . . 183 | ||||
F.1 Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 183 | ||||
F.1.1 Changes to Simplify Multi-homed Web Servers and | ||||
Conserve IP Addresses . . . . . . . . . . . . . . . . 183 | ||||
F.2 Compatibility with HTTP/1.0 Persistent Connections . . . 184 | ||||
F.3 Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 185 | ||||
Appendix G Change Log (to be removed by RFC Editor before | ||||
publication) . . . . . . . . . . . . . . . . . . . . 188 | ||||
G.1 Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 188 | ||||
Appendix H Open issues (to be removed by RFC Editor prior to | ||||
publication) . . . . . . . . . . . . . . . . . . . . 189 | ||||
H.1 rfc2616bis . . . . . . . . . . . . . . . . . . . . . . . 189 | ||||
H.2 edit . . . . . . . . . . . . . . . . . . . . . . . . . . 189 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . 202 | ||||
1 Introduction | 1 Introduction | |||
1.1 Purpose | 1.1 Purpose | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World-Wide Web global | systems. HTTP has been in use by the World-Wide Web global | |||
information initiative since 1990. The first version of HTTP, | information initiative since 1990. The first version of HTTP, | |||
referred to as HTTP/0.9, was a simple protocol for raw data transfer | referred to as HTTP/0.9, was a simple protocol for raw data transfer | |||
skipping to change at page 8, line 22 | skipping to change at page 11, line 4 | |||
access to resources available from diverse applications. | 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 RFC 2119 [34]. | |||
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 REQUIRED | implements. An implementation that satisfies all the MUST or | |||
level and all the SHOULD level requirements for its protocols is said | REQUIRED level and all the SHOULD level requirements for its | |||
to be "unconditionally compliant"; one that satisfies all the MUST | protocols is said to be "unconditionally compliant"; one that | |||
level requirements but not all the SHOULD level requirements for its | satisfies all the MUST level requirements but not all the SHOULD | |||
protocols is said to be "conditionally compliant." | level requirements for its protocols is said to be "conditionally | |||
compliant." | ||||
1.3 Terminology | 1.3 Terminology | |||
This specification uses a number of terms to refer to the roles | This specification uses a number of terms to refer to the roles | |||
played by participants in, and objects of, the HTTP communication. | played by participants in, and objects of, the HTTP communication. | |||
connection | connection | |||
A transport layer virtual circuit established between two programs | A transport layer virtual circuit established between two programs | |||
for the purpose of communication. | for the purpose of communication. | |||
message | message | |||
The basic unit of HTTP communication, consisting of a structured | The basic unit of HTTP communication, consisting of a structured | |||
sequence of octets matching the syntax defined in section 4 and | sequence of octets matching the syntax defined in section 4 and | |||
transmitted via the connection. | transmitted via the connection. | |||
request | request | |||
An HTTP request message, as defined in section 5. | An HTTP request message, as defined in section 5. | |||
response | response | |||
An HTTP response message, as defined in section 6. | An HTTP response message, as defined in section 6. | |||
resource | resource | |||
A network data object or service that can be identified by a URI, | A network data object or service that can be identified by a URI, | |||
as defined in section 3.2. Resources may be available in multiple | as defined in section 3.2. Resources may be available in multiple | |||
representations (e.g. multiple languages, data formats, size, and | representations (e.g. multiple languages, data formats, size, and | |||
resolutions) or vary in other ways. | resolutions) or vary in other ways. | |||
entity | entity | |||
The information transferred as the payload of a request or | The information transferred as the payload of a request or | |||
response. An entity consists of metainformation in the form of | response. An entity consists of metainformation in the form of | |||
entity-header fields and content in the form of an entity-body, as | entity-header fields and content in the form of an entity-body, as | |||
described in section 7. | described in section 7. | |||
representation | representation | |||
An entity included with a response that is subject to content | An entity included with a response that is subject to content | |||
negotiation, as described in section 12. There may exist multiple | negotiation, as described in section 12. There may exist multiple | |||
representations associated with a particular response status. | representations associated with a particular response status. | |||
skipping to change at page 10, line 6 | skipping to change at page 12, line 45 | |||
An application program that accepts connections in order to | An application program that accepts connections in order to | |||
service requests by sending back responses. Any given program may | service requests by sending back responses. Any given program may | |||
be capable of being both a client and a server; our use of these | be capable of being both a client and a server; our use of these | |||
terms refers only to the role being performed by the program for a | terms refers only to the role being performed by the program for a | |||
particular connection, rather than to the program's capabilities | particular connection, rather than to the program's capabilities | |||
in general. Likewise, any server may act as an origin server, | in general. Likewise, any server may act as an origin server, | |||
proxy, gateway, or tunnel, switching behavior based on the nature | proxy, gateway, or tunnel, switching behavior based on the nature | |||
of each request. | of each request. | |||
origin server | origin server | |||
The server on which a given resource resides or is to be created. | The server on which a given resource resides or is to be created. | |||
proxy | proxy | |||
An intermediary program which acts as both a server and a client | An intermediary program which acts as both a server and a client | |||
for the purpose of making requests on behalf of other clients. | for the purpose of making requests on behalf of other clients. | |||
Requests are serviced internally or by passing them on, with | Requests are serviced internally or by passing them on, with | |||
possible translation, to other servers. A proxy MUST implement | possible translation, to other servers. A proxy MUST implement | |||
both the client and server requirements of this specification. A | both the client and server requirements of this specification. A | |||
"transparent proxy" is a proxy that does not modify the request or | "transparent proxy" is a proxy that does not modify the request or | |||
response beyond what is required for proxy authentication and | response beyond what is required for proxy authentication and | |||
identification. A "non-transparent proxy" is a proxy that modifies | identification. A "non-transparent proxy" is a proxy that | |||
the request or response in order to provide some added service to | modifies the request or response in order to provide some added | |||
the user agent, such as group annotation services, media type | service to the user agent, such as group annotation services, | |||
transformation, protocol reduction, or anonymity filtering. Except | media type transformation, protocol reduction, or anonymity | |||
where either transparent or non-transparent behavior is explicitly | filtering. Except where either transparent or non-transparent | |||
stated, the HTTP proxy requirements apply to both types of | behavior is explicitly stated, the HTTP proxy requirements apply | |||
proxies. | to both types of proxies. | |||
gateway | gateway | |||
A server which acts as an intermediary for some other server. | A server which acts as an intermediary for some other server. | |||
Unlike a proxy, a gateway receives requests as if it were the | Unlike a proxy, a gateway receives requests as if it were the | |||
origin server for the requested resource; the requesting client | origin server for the requested resource; the requesting client | |||
may not be aware that it is communicating with a gateway. | may not be aware that it is communicating with a gateway. | |||
tunnel | tunnel | |||
An intermediary program which is acting as a blind relay between | An intermediary program which is acting as a blind relay between | |||
two connections. Once active, a tunnel is not considered a party | two connections. Once active, a tunnel is not considered a party | |||
to the HTTP communication, though the tunnel may have been | to the HTTP communication, though the tunnel may have been | |||
initiated by an HTTP request. The tunnel ceases to exist when both | initiated by an HTTP request. The tunnel ceases to exist when | |||
ends of the relayed connections are closed. | both ends of the relayed connections are closed. | |||
cache | cache | |||
A program's local store of response messages and the subsystem | A program's local store of response messages and the subsystem | |||
that controls its message storage, retrieval, and deletion. A | that controls its message storage, retrieval, and deletion. A | |||
cache stores cacheable responses in order to reduce the response | cache stores cacheable responses in order to reduce the response | |||
time and network bandwidth consumption on future, equivalent | time and network bandwidth consumption on future, equivalent | |||
requests. Any client or server may include a cache, though a cache | requests. Any client or server may include a cache, though a | |||
cannot be used by a server that is acting as a tunnel. | cache cannot be used by a server that is acting as a tunnel. | |||
cacheable | cacheable | |||
A response is cacheable if a cache is allowed to store a copy of | A response is cacheable if a cache is allowed to store a copy of | |||
the response message for use in answering subsequent requests. The | the response message for use in answering subsequent requests. | |||
rules for determining the cacheability of HTTP responses are | The rules for determining the cacheability of HTTP responses are | |||
defined in section 13. Even if a resource is cacheable, there may | defined in section 13. Even if a resource is cacheable, there may | |||
be additional constraints on whether a cache can use the cached | be additional constraints on whether a cache can use the cached | |||
copy for a particular request. | copy for a particular request. | |||
first-hand | first-hand | |||
A response is first-hand if it comes directly and without | A response is first-hand if it comes directly and without | |||
unnecessary delay from the origin server, perhaps via one or more | unnecessary delay from the origin server, perhaps via one or more | |||
proxies. A response is also first-hand if its validity has just | proxies. A response is also first-hand if its validity has just | |||
been checked directly with the origin server. | been checked directly with the origin server. | |||
skipping to change at page 12, line 20 | skipping to change at page 15, line 27 | |||
1.4 Overall Operation | 1.4 Overall Operation | |||
The HTTP protocol is a request/response protocol. A client sends a | The HTTP protocol is a request/response protocol. A client sends a | |||
request to the server in the form of a request method, URI, and | request to the server in the form of a request method, URI, and | |||
protocol version, followed by a MIME-like message containing request | protocol version, followed by a MIME-like message containing request | |||
modifiers, client information, and possible body content over a | modifiers, client information, and possible body content over a | |||
connection with a server. The server responds with a status line, | connection with a server. The server responds with a status line, | |||
including the message's protocol version and a success or error code, | including the message's protocol version and a success or error code, | |||
followed by a MIME-like message containing server information, entity | followed by a MIME-like message containing server information, entity | |||
metainformation, and possible entity-body content. The relationship | metainformation, and possible entity-body content. The relationship | |||
between HTTP and MIME is described in appendix 19.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 13, line 6 | skipping to change at page 16, line 15 | |||
request chain --------------------------------------> | request chain --------------------------------------> | |||
UA -----v----- A -----v----- B -----v----- C -----v----- O | UA -----v----- A -----v----- B -----v----- C -----v----- O | |||
<------------------------------------- response chain | <------------------------------------- response chain | |||
The figure above shows three intermediaries (A, B, and C) between the | The figure above shows three intermediaries (A, B, and C) between the | |||
user agent and origin server. A request or response message that | user agent and origin server. A request or response message that | |||
travels the whole chain will pass through four separate connections. | travels the whole chain will pass through four separate connections. | |||
This distinction is important because some HTTP communication options | This distinction is important because some HTTP communication options | |||
may apply only to the connection with the nearest, non-tunnel | may apply only to the connection with the nearest, non-tunnel | |||
neighbor, only to the end-points of the chain, or to all connections | neighbor, only to the end-points of the chain, or to all connections | |||
along the chain. Although the diagram is linear, each participant may | along the chain. Although the diagram is linear, each participant | |||
be engaged in multiple, simultaneous communications. For example, B | may be engaged in multiple, simultaneous communications. For | |||
may be receiving requests from many clients other than A, and/or | example, B may be receiving requests from many clients other than A, | |||
forwarding requests to servers other than C, at the same time that it | and/or forwarding requests to servers other than C, at the same time | |||
is handling A's request. | that it is handling A's request. | |||
Any party to the communication which is not acting as a tunnel may | Any party to the communication which is not acting as a tunnel may | |||
employ an internal cache for handling requests. The effect of a cache | employ an internal cache for handling requests. The effect of a | |||
is that the request/response chain is shortened if one of the | cache is that the request/response chain is shortened if one of the | |||
participants along the chain has a cached response applicable to that | participants along the chain has a cached response applicable to that | |||
request. The following illustrates the resulting chain if B has a | request. The following illustrates the resulting chain if B has a | |||
cached copy of an earlier response from O (via C) for a request which | cached copy of an earlier response from O (via C) for a request which | |||
has not been cached by UA or A. | has not been cached by UA or A. | |||
request chain ----------> | request chain ----------> | |||
UA -----v----- A -----v----- B - - - - - - C - - - - - - O | UA -----v----- A -----v----- B - - - - - - C - - - - - - O | |||
<--------- response chain | <--------- response chain | |||
Not all responses are usefully cacheable, and some requests may | Not all responses are usefully cacheable, and some requests may | |||
skipping to change at page 14, line 17 | skipping to change at page 18, line 12 | |||
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 RFC 822 [9]. Implementors will need to be familiar with the | |||
notation in order to understand this specification. The augmented BNF | notation in order to understand this specification. The augmented | |||
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 | |||
in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle | in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle | |||
brackets are used within definitions whenever their presence will | brackets are used within definitions whenever their presence will | |||
facilitate discerning the use of rule names. | facilitate discerning the use of rule names. | |||
"literal" | "literal" | |||
skipping to change at page 16, line 20 | skipping to change at page 20, line 28 | |||
DIGIT = <any US-ASCII digit "0".."9"> | DIGIT = <any US-ASCII digit "0".."9"> | |||
CTL = <any US-ASCII control character | CTL = <any US-ASCII control character | |||
(octets 0 - 31) and DEL (127)> | (octets 0 - 31) and DEL (127)> | |||
CR = <US-ASCII CR, carriage return (13)> | CR = <US-ASCII CR, carriage return (13)> | |||
LF = <US-ASCII LF, linefeed (10)> | LF = <US-ASCII LF, linefeed (10)> | |||
SP = <US-ASCII SP, space (32)> | SP = <US-ASCII SP, space (32)> | |||
HT = <US-ASCII HT, horizontal-tab (9)> | HT = <US-ASCII HT, horizontal-tab (9)> | |||
<"> = <US-ASCII double-quote mark (34)> | <"> = <US-ASCII double-quote mark (34)> | |||
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all | |||
protocol elements except the entity-body (see appendix 19.3 for | protocol elements except the entity-body (see appendix C for tolerant | |||
tolerant applications). The end-of-line marker within an entity-body | applications). The end-of-line marker within an entity-body is | |||
is defined by its associated media type, as described in section 3.7. | defined by its associated media type, as described in section 3.7. | |||
CRLF = CR LF | CRLF = CR LF | |||
HTTP/1.1 header field values can be folded onto multiple lines if the | HTTP/1.1 header field values can be folded onto multiple lines if the | |||
continuation line begins with a space or horizontal tab. All linear | continuation line begins with a space or horizontal tab. All linear | |||
white space, including folding, has the same semantics as SP. A | white space, including folding, has the same semantics as SP. A | |||
recipient MAY replace any linear white space with a single SP before | recipient MAY replace any linear white space with a single SP before | |||
interpreting the field value or forwarding the message downstream. | interpreting the field value or forwarding the message downstream. | |||
LWS = [CRLF] 1*( SP | HT ) | LWS = [CRLF] 1*( SP | HT ) | |||
skipping to change at page 17, line 4 | skipping to change at page 21, line 11 | |||
but including LWS> | but including LWS> | |||
A CRLF is allowed in the definition of TEXT only as part of a header | A CRLF is allowed in the definition of TEXT only as part of a header | |||
field continuation. It is expected that the folding LWS will be | field continuation. It is expected that the folding LWS will be | |||
replaced with a single SP before interpretation of the TEXT value. | replaced with a single SP before interpretation of the TEXT value. | |||
Hexadecimal numeric characters are used in several protocol elements. | Hexadecimal numeric characters are used in several protocol elements. | |||
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 section | string to be used within a parameter value (as defined in | |||
3.6). | section 3.6). | |||
token = 1*<any CHAR except CTLs or separators> | token = 1*<any CHAR except CTLs or separators> | |||
separators = "(" | ")" | "<" | ">" | "@" | separators = "(" | ")" | "<" | ">" | "@" | |||
| "," | ";" | ":" | "\" | <"> | | "," | ";" | ":" | "\" | <"> | |||
| "/" | "[" | "]" | "?" | "=" | | "/" | "[" | "]" | "?" | "=" | |||
| "{" | "}" | SP | HT | | "{" | "}" | SP | HT | |||
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. | |||
skipping to change at page 18, line 13 | skipping to change at page 22, line 31 | |||
changed. See RFC 2145 [36] for a fuller explanation. | changed. See RFC 2145 [36] for a fuller explanation. | |||
The version of an HTTP message is indicated by an HTTP-Version field | The version of an HTTP message is indicated by an HTTP-Version field | |||
in the first line of the message. | in the first line of the message. | |||
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT | |||
Note that the major and minor numbers MUST be treated as separate | Note that the major and minor numbers MUST be treated as separate | |||
integers and that each MAY be incremented higher than a single digit. | integers and that each MAY be incremented higher than a single digit. | |||
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is | |||
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients | |||
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 conditionally | with this specification. Applications that are at least | |||
compliant with this specification SHOULD use an HTTP-Version of | conditionally compliant with this specification SHOULD use an HTTP- | |||
"HTTP/1.1" in their messages, and MUST do so for any message that is | Version of "HTTP/1.1" in their messages, and MUST do so for any | |||
not compatible with HTTP/1.0. For more details on when to send | message that is not compatible with HTTP/1.0. For more details on | |||
specific HTTP-Version values, see RFC 2145 [36]. | when to send specific HTTP-Version values, see RFC 2145 [36]. | |||
The HTTP version of an application is the highest HTTP version for | The HTTP version of an application is the highest HTTP version for | |||
which the application is at least conditionally compliant. | which the application is at least conditionally compliant. | |||
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, gateways | since the publication of RFC 2068 [33], caching proxies MUST, | |||
MAY, and tunnels MUST NOT upgrade the request to the highest version | gateways MAY, and tunnels MUST NOT upgrade the request to the highest | |||
they support. The proxy/gateway's response to that request MUST be in | version they support. The proxy/gateway's response to that request | |||
the same major version as the request. | MUST be 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 [3], and finally the | |||
combination of Uniform Resource Locators (URL) [4] and Names (URN) | combination of Uniform Resource Locators (URL) [4] and Names (URN) | |||
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are | [20]. As far as HTTP is concerned, Uniform Resource Identifiers are | |||
simply formatted strings which identify--via name, location, or any | simply formatted strings which identify--via name, location, or any | |||
other characteristic--a resource. | 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 two | known base URI [11], depending upon the context of their use. The | |||
forms are differentiated by the fact that absolute URIs always begin | two forms are differentiated by the fact that absolute URIs always | |||
with a scheme name followed by a colon. For definitive information on | begin with a scheme name followed by a colon. For definitive | |||
URL syntax and semantics, see "Uniform Resource Identifiers (URI): | information on URL syntax and semantics, see "Uniform Resource | |||
Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs | Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] | |||
1738 [4] and RFC 1808 [11]). This specification adopts the | (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification | |||
definitions of "URI-reference", "absoluteURI", "relativeURI", "port", | adopts the definitions of "URI-reference", "absoluteURI", | |||
"host","abs_path", "rel_path", and "authority" from that | "relativeURI", "port", "host","abs_path", "rel_path", and "authority" | |||
specification. | from that specification. | |||
The HTTP protocol does not place any a priori limit on the length of | The HTTP protocol does not place any a priori limit on the length of | |||
a URI. Servers MUST be able to handle the URI of any resource they | a URI. Servers MUST be able to handle the URI of any resource they | |||
serve, and SHOULD be able to handle URIs of unbounded length if they | serve, and SHOULD be able to handle URIs of unbounded length if they | |||
provide GET-based forms that could generate such URIs. A server | provide GET-based forms that could generate such URIs. A server | |||
SHOULD return 414 (Request-URI Too Long) status if a URI is longer | SHOULD return 414 (Request-URI Too Long) status if a URI is longer | |||
than the server can handle (see section 10.4.15). | than the server can handle (see section 10.4.15). | |||
Note: Servers ought to be cautious about depending on URI lengths | Note: Servers ought to be cautious about depending on URI lengths | |||
above 255 bytes, because some older client or proxy | above 255 bytes, because some older client or proxy | |||
skipping to change at page 19, line 40 | skipping to change at page 24, line 10 | |||
The "http" scheme is used to locate network resources via the HTTP | The "http" scheme is used to locate network resources via the HTTP | |||
protocol. This section defines the scheme-specific syntax and | protocol. This section defines the scheme-specific syntax and | |||
semantics for http URLs. | semantics for http URLs. | |||
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] | |||
If the port is empty or not given, port 80 is assumed. The semantics | If the port is empty or not given, port 80 is assumed. The semantics | |||
are that the identified resource is located at the server listening | are that the identified resource is located at the server listening | |||
for TCP connections on that port of that host, and the Request-URI | for TCP connections on that port of that host, and the Request-URI | |||
for the resource is abs_path (section 5.1.2). The use of IP addresses | for the resource is abs_path (section 5.1.2). The use of IP | |||
in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If | addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 | |||
the abs_path is not present in the URL, it MUST be given as "/" when | [24]). If the abs_path is not present in the URL, it MUST be given | |||
used as a Request-URI for a resource (section 5.1.2). If a proxy | as "/" when used as a Request-URI for a resource (section 5.1.2). If | |||
receives a host name which is not a fully qualified domain name, it | a proxy receives a host name which is not a fully qualified domain | |||
MAY add its domain to the host name it received. If a proxy receives | name, it MAY add its domain to the host name it received. If a proxy | |||
a fully qualified domain name, the proxy MUST NOT change the host | receives a fully qualified domain name, the proxy MUST NOT change the | |||
name. | host name. | |||
3.2.3 URI Comparison | 3.2.3 URI Comparison | |||
When comparing two URIs to decide if they match or not, a client | When comparing two URIs to decide if they match or not, a client | |||
SHOULD use a case-sensitive octet-by-octet comparison of the entire | SHOULD use a case-sensitive octet-by-octet comparison of the entire | |||
URIs, with these exceptions: | URIs, with these exceptions: | |||
- 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; | |||
- Comparisons of host names MUST be case-insensitive; | o Comparisons of host names MUST be case-insensitive; | |||
- Comparisons of scheme names MUST be case-insensitive; | o Comparisons of scheme names MUST be case-insensitive; | |||
- An empty abs_path is equivalent to an abs_path of "/". | o An empty abs_path is equivalent to an abs_path of "/". | |||
Characters other than those in the "reserved" and "unsafe" sets (see | Characters other than those in the "reserved" and "unsafe" sets (see | |||
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. | RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. | |||
For example, the following three URIs are equivalent: | For example, the following three URIs are equivalent: | |||
http://abc.com:80/~smith/home.html | http://abc.com:80/~smith/home.html | |||
http://ABC.com/%7Esmith/home.html | http://ABC.com/%7Esmith/home.html | |||
http://ABC.com:/%7esmith/home.html | http://ABC.com:/%7esmith/home.html | |||
skipping to change at page 20, line 39 | skipping to change at page 25, line 4 | |||
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 ; RFC 822, updated by RFC 1123 | |||
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 | |||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |||
The first format is preferred as an Internet standard and represents | The first format is preferred as an Internet standard and represents | |||
a fixed-length subset of that defined by RFC 1123 [8] (an update to | a fixed-length subset of that defined by RFC 1123 [8] (an update to | |||
RFC 822 [9]). The second format is in common use, but is based on the | RFC 822 [9]). The second format is in common use, but is based on | |||
obsolete RFC 850 [12] date format and lacks a four-digit year. | the obsolete RFC 850 [12] date format and lacks a four-digit year. | |||
HTTP/1.1 clients and servers that parse the date value MUST accept | HTTP/1.1 clients and servers that parse the date value MUST accept | |||
all three formats (for compatibility with HTTP/1.0), though they MUST | all three formats (for compatibility with HTTP/1.0), though they MUST | |||
only generate the RFC 1123 format for representing HTTP-date values | only generate the RFC 1123 format for representing HTTP-date values | |||
in header fields. See section 19.3 for further information. | in header fields. See appendix C for further information. | |||
Note: Recipients of date values are encouraged to be robust in | Note: Recipients of date values are encouraged to be robust in | |||
accepting date values that may have been sent by non-HTTP | accepting date values that may have been sent by non-HTTP | |||
applications, as is sometimes the case when retrieving or posting | applications, as is sometimes the case when retrieving or posting | |||
messages via proxies/gateways to SMTP or NNTP. | messages via proxies/gateways to SMTP or NNTP. | |||
All HTTP date/time stamps MUST be represented in Greenwich Mean Time | All HTTP date/time stamps MUST be represented in Greenwich Mean Time | |||
(GMT), without exception. For the purposes of HTTP, GMT is exactly | (GMT), without exception. For the purposes of HTTP, GMT is exactly | |||
equal to UTC (Coordinated Universal Time). This is indicated in the | equal to UTC (Coordinated Universal Time). This is indicated in the | |||
first two formats by the inclusion of "GMT" as the three-letter | first two formats by the inclusion of "GMT" as the three-letter | |||
skipping to change at page 21, line 34 | skipping to change at page 25, line 47 | |||
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT | |||
; 00:00:00 - 23:59:59 | ; 00:00:00 - 23:59:59 | |||
wkday = "Mon" | "Tue" | "Wed" | wkday = "Mon" | "Tue" | "Wed" | |||
| "Thu" | "Fri" | "Sat" | "Sun" | | "Thu" | "Fri" | "Sat" | "Sun" | |||
weekday = "Monday" | "Tuesday" | "Wednesday" | weekday = "Monday" | "Tuesday" | "Wednesday" | |||
| "Thursday" | "Friday" | "Saturday" | "Sunday" | | "Thursday" | "Friday" | "Saturday" | "Sunday" | |||
month = "Jan" | "Feb" | "Mar" | "Apr" | month = "Jan" | "Feb" | "Mar" | "Apr" | |||
| "May" | "Jun" | "Jul" | "Aug" | | "May" | "Jun" | "Jul" | "Aug" | |||
| "Sep" | "Oct" | "Nov" | "Dec" | | "Sep" | "Oct" | "Nov" | "Dec" | |||
Note: HTTP requirements for the date/time stamp format apply only | Note: HTTP requirements for the date/time stamp format apply only to | |||
to their usage within the protocol stream. Clients and servers are | their usage within the protocol stream. Clients and servers are not | |||
not required to use these formats for user presentation, request | required to use these formats for user presentation, request logging, | |||
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 | |||
skipping to change at page 23, line 30 | skipping to change at page 27, line 43 | |||
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 An encoding format produced by the file compression program | gzip | |||
"gzip" (GNU zip) as described in RFC 1952 [25]. This format is a | ||||
Lempel-Ziv coding (LZ77) with a 32 bit CRC. | An encoding format produced by the file compression program "gzip" | |||
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel- | ||||
Ziv 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 | Use of program names for the identification of encoding formats is | |||
is not desirable and is discouraged for future encodings. Their | not desirable and is discouraged for future encodings. Their use | |||
use here is representative of historical practice, not good | here is representative of historical practice, not good design. | |||
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 "deflate" compression mechanism described in RFC 1951 [29]. | The "zlib" format defined in RFC 1950 [31] in combination with the | |||
"deflate" compression mechanism described in RFC 1951 [29]. | ||||
identity | identity | |||
The default (identity) encoding; the use of no transformation | The default (identity) encoding; the use of no transformation | |||
whatsoever. This content-coding is used only in the Accept- | whatsoever. This content-coding is used only in the Accept- | |||
Encoding header, and SHOULD NOT be used in the Content-Encoding | Encoding header, and SHOULD NOT be used in the Content-Encoding | |||
header. | header. | |||
New content-coding value tokens SHOULD be registered; to allow | New content-coding value tokens SHOULD be registered; to allow | |||
interoperability between clients and servers, specifications of the | interoperability between clients and servers, specifications of the | |||
content coding algorithms needed to implement a new value SHOULD be | content coding algorithms needed to implement a new value SHOULD be | |||
publicly available and adequate for independent implementation, and | publicly available and adequate for independent implementation, and | |||
conform to the purpose of content coding defined in this section. | conform to the purpose of content coding defined in this section. | |||
skipping to change at page 25, line 23 | skipping to change at page 29, line 39 | |||
A server which receives an entity-body with a transfer-coding it does | A server which receives an entity-body with a transfer-coding it does | |||
not understand SHOULD return 501 (Unimplemented), and close the | not understand SHOULD return 501 (Unimplemented), and close the | |||
connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 | |||
client. | client. | |||
3.6.1 Chunked Transfer Coding | 3.6.1 Chunked Transfer Coding | |||
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. This | followed by an OPTIONAL trailer containing entity-header fields. | |||
allows dynamically produced content to be transferred along with the | This allows dynamically produced content to be transferred along with | |||
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 | |||
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 | |||
skipping to change at page 26, line 9 | skipping to change at page 30, line 34 | |||
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: | |||
a)the request included a TE header field that indicates "trailers" is | 1. the request included a TE header field that indicates "trailers" | |||
acceptable in the transfer-coding of the response, as described in | is acceptable in the transfer-coding of the response, as | |||
section 14.39; or, | described in section 14.39; or, | |||
b)the server is the origin server for the response, the trailer | 2. the server is the origin server for the response, the trailer | |||
fields consist entirely of optional metadata, and the recipient | fields consist entirely of optional metadata, and the recipient | |||
could use the message (in a manner acceptable to the origin server) | could use the message (in a manner acceptable to the origin | |||
without receiving this metadata. In other words, the origin server | server) without receiving this metadata. In other words, the | |||
is willing to accept the possibility that the trailer fields might | origin server is willing to accept the possibility that the | |||
be silently discarded along the path to the client. | trailer fields might be silently discarded along the path to the | |||
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 19.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 (section | HTTP uses Internet Media Types [17] in the Content-Type | |||
14.17) and Accept (section 14.1) header fields in order to provide | (section 14.17) and Accept (section 14.1) header fields in order to | |||
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 might | attribute and its value. The presence or absence of a parameter | |||
be significant to the processing of a media-type, depending on its | might be significant to the processing of a media-type, depending on | |||
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 [19]). The media type registration process is | |||
outlined in RFC 1590 [17]. Use of non-registered media types is | outlined in RFC 1590 [17]. Use of non-registered media types is | |||
discouraged. | discouraged. | |||
skipping to change at page 28, line 9 | skipping to change at page 32, line 36 | |||
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 RFC 2046 | |||
[40], and MUST include a boundary parameter as part of the media type | [40], and MUST include a boundary parameter as part of the media type | |||
value. The message body is itself a protocol element and MUST | 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 in | original multipart contains an epilogue). These restrictions exist | |||
order to preserve the self-delimiting nature of a multipart message- | in order to preserve the self-delimiting nature of a multipart | |||
body, wherein the "end" of the message-body is indicated by the | message-body, wherein the "end" of the message-body is indicated by | |||
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 19.2) when it appears in a 206 | "multipart/byteranges" type (appendix B) when it appears in a 206 | |||
(Partial Content) response, which will be interpreted by some HTTP | (Partial Content) response, which will be interpreted by some HTTP | |||
caching mechanisms as described in sections 13.5.4 and 14.16. In all | caching mechanisms as described in sections 13.5.4 and 14.16. In all | |||
other cases, an HTTP user agent SHOULD follow the same or similar | other cases, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
The MIME header fields within each body-part of a multipart message- | The MIME header fields within each body-part of a multipart message- | |||
body do not have any significance to HTTP beyond that defined by | body do not have any significance to HTTP beyond that defined by | |||
their MIME semantics. | their MIME semantics. | |||
In general, an HTTP user agent SHOULD follow the same or similar | In general, an HTTP user agent SHOULD follow the same or similar | |||
behavior as a MIME user agent would upon receipt of a multipart type. | behavior as a MIME user agent would upon receipt of a multipart type. | |||
skipping to change at page 29, line 4 | skipping to change at page 33, line 30 | |||
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 any | used for advertising or other non-essential information. Although | |||
token character MAY appear in a product-version, this token SHOULD | any token character MAY appear in a product-version, this token | |||
only be used for a version identifier (i.e., successive versions of | SHOULD only be used for a version identifier (i.e., successive | |||
the same product SHOULD only differ in the product-version portion of | versions of the same product SHOULD only differ in the product- | |||
the product value). | version portion of the product value). | |||
3.9 Quality Values | 3.9 Quality Values | |||
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 | |||
skipping to change at page 30, line 4 | skipping to change at page 34, line 29 | |||
language-tag = primary-tag *( "-" subtag ) | language-tag = primary-tag *( "-" subtag ) | |||
primary-tag = 1*8ALPHA | primary-tag = 1*8ALPHA | |||
subtag = 1*8ALPHA | subtag = 1*8ALPHA | |||
White space is not allowed within the tag and all tags are case- | White space is not allowed within the tag and all tags are case- | |||
insensitive. The name space of language tags is administered by the | insensitive. The name space of language tags is administered by the | |||
IANA. Example tags include: | IANA. Example tags include: | |||
en, en-US, en-cockney, i-cherokee, x-pig-latin | en, en-US, en-cockney, i-cherokee, x-pig-latin | |||
where any two-letter primary-tag is an ISO-639 language abbreviation | where any two-letter primary-tag is an ISO-639 language abbreviation | |||
and any two-letter initial subtag is an ISO-3166 country code. (The | and any two-letter initial subtag is an ISO-3166 country code. (The | |||
last three tags above are not registered tags; all but the last are | last three tags above are not registered tags; all but the last are | |||
examples of tags which could be registered in future.) | examples of tags which could be registered in future.) | |||
3.11 Entity Tags | 3.11 Entity Tags | |||
Entity tags are used for comparing two or more entities from the same | Entity tags are used for comparing two or more entities from the same | |||
requested resource. HTTP/1.1 uses entity tags in the ETag (section | requested resource. HTTP/1.1 uses entity tags in the ETag | |||
14.19), If-Match (section 14.24), If-None-Match (section 14.26), and | (section 14.19), If-Match (section 14.24), If-None-Match | |||
If-Range (section 14.27) header fields. The definition of how they | (section 14.26), and If-Range (section 14.27) header fields. The | |||
are used and compared as cache validators is in section 13.3.3. An | definition of how they are used and compared as cache validators is | |||
entity tag consists of an opaque quoted string, possibly prefixed by | in section 13.3.3. An entity tag consists of an opaque quoted | |||
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 | |||
skipping to change at page 31, line 31 | skipping to change at page 36, line 28 | |||
a line with nothing preceding the CRLF) indicating the end of the | a 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, if | line(s) received where a Request-Line is expected. In other words, | |||
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 3.1 of RFC 822 [9]. 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", where | least one SP or HT. Applications ought to follow "common form", | |||
one is known or indicated, when generating HTTP constructs, since | where one is known or indicated, when generating HTTP constructs, | |||
there might exist some implementations that fail to accept anything | since there might exist some implementations that fail to accept | |||
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 = <the OCTETs making up the field-value | |||
and consisting of either *TEXT or combinations | and consisting of either *TEXT or combinations | |||
of token, separators, and quoted-string> | 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 | |||
skipping to change at page 32, line 41 | skipping to change at page 37, line 40 | |||
"field-name: field-value" pair, without changing the semantics of the | "field-name: field-value" pair, without changing the semantics of the | |||
message, by appending each subsequent field-value to the first, each | message, by appending each subsequent field-value to the first, each | |||
separated by a comma. The order in which header fields with the same | separated by a comma. The order in which header fields with the same | |||
field-name are received is therefore significant to the | field-name are received is therefore significant to the | |||
interpretation of the combined field value, and thus a proxy MUST NOT | interpretation of the combined field value, and thus a proxy MUST NOT | |||
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-body | entity-body associated with the request or response. The message- | |||
differs from the entity-body only when a transfer-coding has been | body differs from the entity-body only when a transfer-coding has | |||
applied, as indicated by the Transfer-Encoding header field (section | been applied, as indicated by the Transfer-Encoding header field | |||
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. | |||
The presence of a message-body in a request is signaled by the | The presence of a message-body in a request is signaled by the | |||
inclusion of a Content-Length or Transfer-Encoding header field in | inclusion of a Content-Length or Transfer-Encoding header field in | |||
the request's message-headers. A message-body MUST NOT be included in | the request's message-headers. A message-body MUST NOT be included | |||
a request if the specification of the request method (section 5.1.1) | in a request if the specification of the request method | |||
does not allow sending an entity-body in requests. A server SHOULD | (section 5.1.1) does not allow sending an entity-body in requests. A | |||
read and forward a message-body on any request; if the request method | server SHOULD read and forward a message-body on any request; if the | |||
does not include defined semantics for an entity-body, then the | request method does not include defined semantics for an entity-body, | |||
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 method | status code (section 6.1.1). All responses to the HEAD request | |||
MUST NOT include a message-body, even though the presence of entity- | method MUST NOT include a message-body, even though the presence of | |||
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 (such | 1. Any response message which "MUST NOT" include a message-body | |||
as the 1xx, 204, and 304 responses and any response to a HEAD | (such as the 1xx, 204, and 304 responses and any response to a | |||
request) is always terminated by the first empty line after the | HEAD request) is always terminated by the first empty line after | |||
header fields, regardless of the entity-header fields present in | the header fields, regardless of the entity-header fields present | |||
the message. | in the message. | |||
2.If a Transfer-Encoding header field (section 14.41) is present and | 2. If a Transfer-Encoding header field (section 14.41) is present | |||
has any value other than "identity", then the transfer-length is | and has any value other than "identity", then the transfer-length | |||
defined by use of the "chunked" transfer-coding (section 3.6), | is defined by use of the "chunked" transfer-coding (section 3.6), | |||
unless the message is terminated by closing the connection. | unless the message is terminated 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 sent | transfer-length. The Content-Length header field MUST NOT be | |||
if these two lengths are different (i.e., if a Transfer-Encoding | sent if these two lengths are different (i.e., if a Transfer- | |||
header field is present). If a message is received with both a | Encoding header field is present). If a message is received with | |||
Transfer-Encoding header field and a Content-Length header field, | both a Transfer-Encoding header field and a Content-Length header | |||
the latter MUST be ignored. | field, the latter MUST be ignored. | |||
4.If the message uses the media type "multipart/byteranges", and the | 4. If the message uses the media type "multipart/byteranges", and | |||
ransfer-length is not otherwise specified, then this self- | the ransfer-length is not otherwise specified, then this self- | |||
elimiting media type defines the transfer-length. This media type | elimiting media type defines the transfer-length. This media | |||
UST NOT be used unless the sender knows that the recipient can arse | type UST NOT be used unless the sender knows that the recipient | |||
it; the presence in a request of a Range header with ultiple byte- | can arse it; the presence in a request of a Range header with | |||
range specifiers from a 1.1 client implies that the lient can parse | ultiple byte-range specifiers from a 1.1 client implies that the | |||
multipart/byteranges responses. | lient 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 of | delimit the message using methods defined in items 1, 3 or 5 | |||
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 response.) | would leave no possibility for the server to send back a | |||
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 | |||
skipping to change at page 35, line 38 | skipping to change at page 41, line 20 | |||
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 | The Request-Line begins with a method token, followed by the Request- | |||
Request-URI and the protocol version, and ending with CRLF. The | URI and the protocol version, and ending with CRLF. The elements are | |||
elements are separated by SP characters. No CR or LF is allowed | separated by SP characters. No CR or LF is allowed except in the | |||
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 | The Method token indicates the method to be performed on the resource | |||
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. An | resource, since the set of allowed methods can change dynamically. | |||
origin server SHOULD return the status code 405 (Method Not Allowed) | An origin server SHOULD return the status code 405 (Method Not | |||
if the method is known by the origin server but not allowed for the | Allowed) if the method is known by the origin server but not allowed | |||
requested resource, and 501 (Not Implemented) if the method is | for the requested resource, and 501 (Not Implemented) if the method | |||
unrecognized or not implemented by the origin server. The methods GET | is unrecognized or not implemented by the origin server. The methods | |||
and HEAD MUST be supported by all general-purpose servers. All other | GET and HEAD MUST be supported by all general-purpose servers. All | |||
methods are OPTIONAL; however, if the above methods are implemented, | other methods are OPTIONAL; however, if the above methods are | |||
they MUST be implemented with the same semantics as those specified | implemented, they MUST be implemented with the same semantics as | |||
in section 9. | those specified in section 9. | |||
5.1.2 Request-URI | 5.1.2 Request-URI | |||
The Request-URI is a Uniform Resource Identifier (section 3.2) and | The Request-URI is a Uniform Resource Identifier (section 3.2) and | |||
identifies the resource upon which to apply the request. | identifies the resource upon which to apply the request. | |||
Request-URI = "*" | absoluteURI | abs_path | authority | Request-URI = "*" | absoluteURI | abs_path | 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 | |||
skipping to change at page 37, line 6 | skipping to change at page 42, line 28 | |||
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 example | any aliases, local variations, and the numeric IP address. An | |||
Request-Line would be: | example Request-Line would be: | |||
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 | GET http://www.w3.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). | |||
skipping to change at page 37, line 29 | skipping to change at page 43, line 4 | |||
resource on an origin server or gateway. In this case the absolute | resource on an origin server or gateway. In this case the absolute | |||
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as | path of the URI MUST be transmitted (see section 3.2.1, abs_path) as | |||
the Request-URI, and the network location of the URI (authority) MUST | the Request-URI, and the network location of the URI (authority) MUST | |||
be transmitted in a Host header field. For example, a client wishing | be transmitted in a Host header field. For example, a client wishing | |||
to retrieve the resource above directly from the origin server would | to retrieve the resource above directly from the origin server would | |||
create a TCP connection to port 80 of the host "www.w3.org" and send | create a TCP connection to port 80 of the host "www.w3.org" and send | |||
the lines: | the lines: | |||
GET /pub/WWW/TheProject.html HTTP/1.1 | GET /pub/WWW/TheProject.html HTTP/1.1 | |||
Host: www.w3.org | Host: www.w3.org | |||
followed by the remainder of the Request. Note that the absolute | ||||
followed by the remainder of the Request. Note that the absolute path | path cannot be empty; if none is present in the original URI, it MUST | |||
cannot be empty; if none is present in the original URI, it MUST be | be given as "/" (the server root). | |||
given as "/" (the server root). | ||||
The Request-URI is transmitted in the format specified in section | The Request-URI is transmitted in the format specified in section | |||
3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding | 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 to | [42], the origin server MUST decode the Request-URI in order to | |||
properly interpret the request. Servers SHOULD respond to invalid | properly interpret the request. Servers SHOULD respond to invalid | |||
Request-URIs with an appropriate status code. | Request-URIs with an appropriate status code. | |||
A transparent proxy MUST NOT rewrite the "abs_path" part of the | A transparent proxy MUST NOT rewrite the "abs_path" part of the | |||
received Request-URI when forwarding it to the next inbound server, | received Request-URI when forwarding it to the next inbound server, | |||
except as noted above to replace a null abs_path with "/". | except as noted above to replace a null abs_path with "/". | |||
skipping to change at page 38, line 13 | skipping to change at page 43, line 32 | |||
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 | |||
section 19.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. | |||
2. If the Request-URI is not an absoluteURI, and the request includes | 2. If the Request-URI is not an absoluteURI, and the request | |||
a Host header field, the host is determined by the Host header | includes a Host header field, the host is determined by the Host | |||
field value. | header field value. | |||
3. If the host as determined by rule 1 or 2 is not a valid host on | 3. If the host as determined by rule 1 or 2 is not a valid host on | |||
the server, the response MUST be a 400 (Bad Request) error message. | the server, the response MUST be a 400 (Bad Request) error | |||
message. | ||||
Recipients of an HTTP/1.0 request that lacks a Host header field MAY | Recipients of an HTTP/1.0 request that lacks a Host header field MAY | |||
attempt to use heuristics (e.g., examination of the URI path for | attempt to use heuristics (e.g., examination of the URI path for | |||
something unique to a particular host) in order to determine what | something unique to a particular host) in order to determine what | |||
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 | |||
skipping to change at page 39, line 39 | skipping to change at page 45, line 22 | |||
| 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 sequence. | characters. No CR or LF is allowed except in the final CRLF | |||
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. | |||
The first digit of the Status-Code defines the class of response. The | The first digit of the Status-Code defines the class of response. | |||
last two digits do not have any categorization role. There are 5 | The last two digits do not have any categorization role. There are 5 | |||
values for the first digit: | values for the first digit: | |||
- 1xx: Informational - Request received, continuing process | o 1xx: Informational - Request received, continuing process | |||
- 2xx: Success - The action was successfully received, | o 2xx: Success - The action was successfully received, understood, | |||
understood, and accepted | and accepted | |||
- 3xx: Redirection - Further action must be taken in order to | o 3xx: Redirection - Further action must be taken in order to | |||
complete the request | complete the request | |||
- 4xx: Client Error - The request contains bad syntax or cannot | o 4xx: Client Error - The request contains bad syntax or cannot be | |||
be fulfilled | fulfilled | |||
o 5xx: Server Error - The server failed to fulfill an apparently | ||||
- 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 | |||
skipping to change at page 41, line 44 | skipping to change at page 48, line 20 | |||
safely assume that there was something wrong with its request and | safely assume that there was something wrong with its request and | |||
treat the response as if it had received a 400 status code. In such | treat the response as if it had received a 400 status code. In such | |||
cases, user agents SHOULD present to the user the entity returned | cases, user agents SHOULD present to the user the entity returned | |||
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 about | Line. These header fields give information about the server and | |||
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 | |||
skipping to change at page 43, line 42 | skipping to change at page 50, line 30 | |||
Content-Type header field defining the media type of that body. If | Content-Type header field defining the media type of that body. If | |||
and only if the media type is not given by a Content-Type field, the | and only if the media type is not given by a Content-Type field, the | |||
recipient MAY attempt to guess the media type via inspection of its | recipient MAY attempt to guess the media type via inspection of its | |||
content and/or the name extension(s) of the URI used to identify the | content and/or the name extension(s) of the URI used to identify the | |||
resource. If the media type remains unknown, the recipient SHOULD | resource. If the media type remains unknown, the recipient SHOULD | |||
treat it as type "application/octet-stream". | treat it as type "application/octet-stream". | |||
7.2.2 Entity Length | 7.2.2 Entity Length | |||
The entity-length of a message is the length of the message-body | The entity-length of a message is the length of the message-body | |||
before any transfer-codings have been applied. Section 4.4 defines | before any transfer-codings have been applied. section 4.4 defines | |||
how the transfer-length of a message-body is determined. | how the transfer-length of a message-body is determined. | |||
8 Connections | 8 Connections | |||
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 and | implementation are available [26] [30]. Implementation experience | |||
measurements of actual HTTP/1.1 (RFC 2068) implementations show good | and measurements of actual HTTP/1.1 (RFC 2068) implementations show | |||
results [39]. Alternatives have also been explored, for example, | good results [39]. Alternatives have also been explored, for | |||
T/TCP [27]. | example, T/TCP [27]. | |||
Persistent HTTP connections have a number of advantages: | Persistent HTTP connections have a number of advantages: | |||
- By opening and closing fewer TCP connections, CPU time is saved | o By opening and closing fewer TCP connections, CPU time is saved in | |||
in routers and hosts (clients, servers, proxies, gateways, | routers and hosts (clients, servers, proxies, gateways, tunnels, | |||
tunnels, or caches), and memory used for TCP protocol control | or caches), and memory used for TCP protocol control blocks can be | |||
blocks can be saved in hosts. | saved in hosts. | |||
- 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 | |||
waiting for each response, allowing a single TCP connection to | waiting for each response, allowing a single TCP connection to be | |||
be used much more efficiently, with much lower elapsed time. | used much more efficiently, with much lower elapsed time. | |||
- Network congestion is reduced by reducing the number of packets | o Network congestion is reduced by reducing the number of packets | |||
caused by TCP opens, and by allowing TCP sufficient time to | caused by TCP opens, and by allowing TCP sufficient time to | |||
determine the congestion state of the network. | determine the congestion state of the network. | |||
- Latency on subsequent requests is reduced since there is no time | o Latency on subsequent requests is reduced since there is no time | |||
spent in TCP's connection opening handshake. | spent in TCP's connection opening handshake. | |||
- HTTP can evolve more gracefully, since errors can be reported | o HTTP can evolve more gracefully, since errors can be reported | |||
without the penalty of closing the TCP connection. Clients using | without the penalty of closing the TCP connection. Clients using | |||
future versions of HTTP might optimistically try a new feature, | future versions of HTTP might optimistically try a new feature, | |||
but if communicating with an older server, retry with old | but if communicating with an older server, retry with old | |||
semantics after an error is reported. | semantics after an error is reported. | |||
HTTP implementations SHOULD implement persistent connections. | HTTP implementations SHOULD implement persistent connections. | |||
8.1.2 Overall Operation | 8.1.2 Overall Operation | |||
A significant difference between HTTP/1.1 and earlier versions of | A significant difference between HTTP/1.1 and earlier versions of | |||
HTTP is that persistent connections are the default behavior of any | HTTP is that persistent connections are the default behavior of any | |||
HTTP connection. That is, unless otherwise indicated, the client | HTTP connection. That is, unless otherwise indicated, the client | |||
SHOULD assume that the server will maintain a persistent connection, | SHOULD assume that the server will maintain a persistent connection, | |||
even after error responses from the server. | even after error responses from the server. | |||
Persistent connections provide a mechanism by which a client and a | Persistent connections provide a mechanism by which a client and a | |||
server can signal the close of a TCP connection. This signaling takes | server can signal the close of a TCP connection. This signaling | |||
place using the Connection header field (section 14.10). Once a close | takes place using the Connection header field (section 14.10). Once | |||
has been signaled, the client MUST NOT send any more requests on that | a close has been signaled, the client MUST NOT send any more requests | |||
connection. | on that connection. | |||
8.1.2.1 Negotiation | 8.1.2.1 Negotiation | |||
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to | |||
maintain a persistent connection unless a Connection header including | maintain a persistent connection unless a Connection header including | |||
the connection-token "close" was sent in the request. If the server | the connection-token "close" was sent in the request. If the server | |||
chooses to close the connection immediately after sending the | chooses to close the connection immediately after sending the | |||
response, it SHOULD send a Connection header including the | response, it SHOULD send a Connection header including the | |||
connection-token close. | connection-token close. | |||
An HTTP/1.1 client MAY expect a connection to remain open, but would | An HTTP/1.1 client MAY expect a connection to remain open, but would | |||
decide to keep it open based on whether the response from a server | decide to keep it open based on whether the response from a server | |||
contains a Connection header with the connection-token close. In case | contains a Connection header with the connection-token close. In | |||
the client does not want to maintain a connection for more than that | case the client does not want to maintain a connection for more than | |||
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 section 19.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 | |||
response). A server MUST send its responses to those requests in the | response). A server MUST send its responses to those requests in the | |||
same order that the requests were received. | same order that the requests were received. | |||
Clients which assume persistent connections and pipeline immediately | Clients which assume persistent connections and pipeline immediately | |||
after connection establishment SHOULD be prepared to retry their | after connection establishment SHOULD be prepared to retry their | |||
connection if the first pipelined attempt fails. If a client does | connection if the first pipelined attempt fails. If a client does | |||
such a retry, it MUST NOT pipeline before it knows the connection is | such a retry, it MUST NOT pipeline before it knows the connection is | |||
persistent. Clients MUST also be prepared to resend their requests if | persistent. Clients MUST also be prepared to resend their requests | |||
the server closes the connection before sending all of the | if the server closes the connection before sending all of the | |||
corresponding responses. | corresponding responses. | |||
Clients SHOULD NOT pipeline requests using non-idempotent methods or | Clients SHOULD NOT pipeline requests using non-idempotent methods or | |||
non-idempotent sequences of methods (see section 9.1.2). Otherwise, a | non-idempotent sequences of methods (see section 9.1.2). Otherwise, | |||
premature termination of the transport connection could lead to | a premature termination of the transport connection could lead to | |||
indeterminate results. A client wishing to send a non-idempotent | indeterminate results. A client wishing to send a non-idempotent | |||
request SHOULD wait to send that request until it has received the | request SHOULD wait to send that request until it has received the | |||
response status for the previous request. | response status for the previous request. | |||
8.1.3 Proxy Servers | 8.1.3 Proxy Servers | |||
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 section | properties of the Connection header field as specified in | |||
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 transport | connects to. Each persistent connection applies to only one | |||
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 RFC 2068 [33] 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 | |||
skipping to change at page 47, line 25 | skipping to change at page 54, line 14 | |||
connection. From the server's point of view, the connection is being | connection. From the server's point of view, the connection is being | |||
closed while it was idle, but from the client's point of view, a | closed while it was idle, but from the client's point of view, a | |||
request is in progress. | request is in progress. | |||
This means that clients, servers, and proxies MUST be able to recover | This means that clients, servers, and proxies MUST be able to recover | |||
from asynchronous close events. Client software SHOULD reopen the | from asynchronous close events. Client software SHOULD reopen the | |||
transport connection and retransmit the aborted sequence of requests | transport connection and retransmit the aborted sequence of requests | |||
without user interaction so long as the request sequence is | without user interaction so long as the request sequence is | |||
idempotent (see section 9.1.2). Non-idempotent methods or sequences | idempotent (see section 9.1.2). Non-idempotent methods or sequences | |||
MUST NOT be automatically retried, although user agents MAY offer a | MUST NOT be automatically retried, although user agents MAY offer a | |||
human operator the choice of retrying the request(s). Confirmation by | human operator the choice of retrying the request(s). Confirmation | |||
user-agent software with semantic understanding of the application | by user-agent software with semantic understanding of the application | |||
MAY substitute for user confirmation. The automatic retry SHOULD NOT | MAY substitute for user confirmation. The automatic retry SHOULD NOT | |||
be repeated if the second sequence of requests fails. | be repeated if the second sequence of requests fails. | |||
Servers SHOULD always respond to at least one request per connection, | Servers SHOULD always respond to at least one request per connection, | |||
if at all possible. Servers SHOULD NOT close a connection in the | if at all possible. Servers SHOULD NOT close a connection in the | |||
middle of transmitting a response, unless a network or client failure | middle of transmitting a response, unless a network or client failure | |||
is suspected. | is suspected. | |||
Clients that use persistent connections SHOULD limit the number of | Clients that use persistent connections SHOULD limit the number of | |||
simultaneous connections that they maintain to a given server. A | simultaneous connections that they maintain to a given server. A | |||
skipping to change at page 48, line 28 | skipping to change at page 55, line 17 | |||
The purpose of the 100 (Continue) status (see section 10.1.1) is to | The purpose of the 100 (Continue) status (see section 10.1.1) is to | |||
allow a client that is sending a request message with a request body | allow a client that is sending a request message with a request body | |||
to determine if the origin server is willing to accept the request | to determine if the origin server is willing to accept the request | |||
(based on the request headers) before the client sends the request | (based on the request headers) before the client sends the request | |||
body. In some cases, it might either be inappropriate or highly | body. In some cases, it might either be inappropriate or highly | |||
inefficient for the client to send the body if the server will reject | inefficient for the client to send the body if the server will reject | |||
the message without looking at the body. | the message without looking at the body. | |||
Requirements for HTTP/1.1 clients: | Requirements for HTTP/1.1 clients: | |||
- If a client will wait for a 100 (Continue) response before | o If a client will wait for a 100 (Continue) response before sending | |||
sending the request body, it MUST send an Expect request-header | the request body, it MUST send an Expect request-header field | |||
field (section 14.20) with the "100-continue" expectation. | (section 14.20) with the "100-continue" expectation. | |||
- A client MUST NOT send an Expect request-header field (section | o A client MUST NOT send an Expect request-header field | |||
14.20) with the "100-continue" expectation if it does not intend | (section 14.20) with the "100-continue" expectation if it does not | |||
to send a request body. | intend to send a request body. | |||
Because of the presence of older implementations, the protocol allows | Because of the presence of older implementations, the protocol allows | |||
ambiguous situations in which a client may send "Expect: 100- | ambiguous situations in which a client may send "Expect: 100- | |||
continue" without receiving either a 417 (Expectation Failed) status | continue" without receiving either a 417 (Expectation Failed) status | |||
or a 100 (Continue) status. Therefore, when a client sends this | or a 100 (Continue) status. Therefore, when a client sends this | |||
header field to an origin server (possibly via a proxy) from which it | header field to an origin server (possibly via a proxy) from which it | |||
has never seen a 100 (Continue) status, the client SHOULD NOT wait | has never seen a 100 (Continue) status, the client SHOULD NOT wait | |||
for an indefinite period before sending the request body. | for an indefinite period before sending the request body. | |||
Requirements for HTTP/1.1 origin servers: | Requirements for HTTP/1.1 origin servers: | |||
- Upon receiving a request which includes an Expect request-header | o Upon receiving a request which includes an Expect request-header | |||
field with the "100-continue" expectation, an origin server MUST | field with the "100-continue" expectation, an origin server MUST | |||
either respond with 100 (Continue) status and continue to read | either respond with 100 (Continue) status and continue to read | |||
from the input stream, or respond with a final status code. The | from the input stream, or respond with a final status code. The | |||
origin server MUST NOT wait for the request body before sending | origin server MUST NOT wait for the request body before sending | |||
the 100 (Continue) response. If it responds with a final status | the 100 (Continue) response. If it responds with a final status | |||
code, it MAY close the transport connection or it MAY continue | code, it MAY close the transport connection or it MAY continue to | |||
to read and discard the rest of the request. It MUST NOT | read and discard the rest of the request. It MUST NOT perform the | |||
perform the requested method if it returns a final status code. | requested method if it returns a final status code. | |||
- An origin server SHOULD NOT send a 100 (Continue) response if | o An origin server SHOULD NOT send a 100 (Continue) response if the | |||
the request message does not include an Expect request-header | request message does not include an Expect request-header field | |||
field with the "100-continue" expectation, and MUST NOT send a | with the "100-continue" expectation, and MUST NOT send a 100 | |||
100 (Continue) response if such a request comes from an HTTP/1.0 | (Continue) response if such a request comes from an HTTP/1.0 (or | |||
(or earlier) client. There is an exception to this rule: for | earlier) client. There is an exception to this rule: for | |||
compatibility with RFC 2068, a server MAY send a 100 (Continue) | compatibility with RFC 2068, a server MAY send a 100 (Continue) | |||
status in response to an HTTP/1.1 PUT or POST request that does | status in response to an HTTP/1.1 PUT or POST request that does | |||
not include an Expect request-header field with the "100- | not include an Expect request-header field with the "100-continue" | |||
continue" expectation. This exception, the purpose of which is | expectation. This exception, the purpose of which is to minimize | |||
to minimize any client processing delays associated with an | any client processing delays associated with an undeclared wait | |||
undeclared wait for 100 (Continue) status, applies only to | for 100 (Continue) status, applies only to HTTP/1.1 requests, and | |||
HTTP/1.1 requests, and not to requests with any other HTTP- | not to requests with any other HTTP-version value. | |||
version value. | ||||
- An origin server MAY omit a 100 (Continue) response if it has | o An origin server MAY omit a 100 (Continue) response if it has | |||
already received some or all of the request body for the | already received some or all of the request body for the | |||
corresponding request. | corresponding request. | |||
- An origin server that sends a 100 (Continue) response MUST | o An origin server that sends a 100 (Continue) response MUST | |||
ultimately send a final status code, once the request body is | ultimately send a final status code, once the request body is | |||
received and processed, unless it terminates the transport | received and processed, unless it terminates the transport | |||
connection prematurely. | connection prematurely. | |||
- If an origin server receives a request that does not include an | o If an origin server receives a request that does not include an | |||
Expect request-header field with the "100-continue" expectation, | Expect request-header field with the "100-continue" expectation, | |||
the request includes a request body, and the server responds | the request includes a request body, and the server responds with | |||
with a final status code before reading the entire request body | a final status code before reading the entire request body from | |||
from the transport connection, then the server SHOULD NOT close | the transport connection, then the server SHOULD NOT close the | |||
the transport connection until it has read the entire request, | transport connection until it has read the entire request, or | |||
or until the client closes the connection. Otherwise, the client | until the client closes the connection. Otherwise, the client | |||
might not reliably receive the response message. However, this | might not reliably receive the response message. However, this | |||
requirement is not be construed as preventing a server from | requirement is not be construed as preventing a server from | |||
defending itself against denial-of-service attacks, or from | defending itself against denial-of-service attacks, or from badly | |||
badly broken client implementations. | broken client implementations. | |||
Requirements for HTTP/1.1 proxies: | Requirements for HTTP/1.1 proxies: | |||
- If a proxy receives a request that includes an Expect request- | o If a proxy receives a request that includes an Expect request- | |||
header field with the "100-continue" expectation, and the proxy | header field with the "100-continue" expectation, and the proxy | |||
either knows that the next-hop server complies with HTTP/1.1 or | either knows that the next-hop server complies with HTTP/1.1 or | |||
higher, or does not know the HTTP version of the next-hop | higher, or does not know the HTTP version of the next-hop server, | |||
server, it MUST forward the request, including the Expect header | it MUST forward the request, including the Expect header field. | |||
field. | ||||
- If the proxy knows that the version of the next-hop server is | o If the proxy knows that the version of the next-hop server is | |||
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST | |||
respond with a 417 (Expectation Failed) status. | respond with a 417 (Expectation Failed) status. | |||
- Proxies SHOULD maintain a cache recording the HTTP version | o Proxies SHOULD maintain a cache recording the HTTP version numbers | |||
numbers received from recently-referenced next-hop servers. | received from recently-referenced next-hop servers. | |||
- A proxy MUST NOT forward a 100 (Continue) response if the | o A proxy MUST NOT forward a 100 (Continue) response if the request | |||
request message was received from an HTTP/1.0 (or earlier) | message was received from an HTTP/1.0 (or earlier) client and did | |||
client and did not include an Expect request-header field with | not include an Expect request-header field with the "100-continue" | |||
the "100-continue" expectation. This requirement overrides the | expectation. This requirement overrides the general rule for | |||
general rule for forwarding of 1xx responses (see section 10.1). | forwarding of 1xx responses (see section 10.1). | |||
8.2.4 Client Behavior if Server Prematurely Closes Connection | 8.2.4 Client Behavior if Server Prematurely Closes Connection | |||
If an HTTP/1.1 client sends a request which includes a request body, | If an HTTP/1.1 client sends a request which includes a request body, | |||
but which does not include an Expect request-header field with the | but which does not include an Expect request-header field with the | |||
"100-continue" expectation, and if the client is not directly | "100-continue" expectation, and if the client is not directly | |||
connected to an HTTP/1.1 origin server, and if the client sees the | connected to an HTTP/1.1 origin server, and if the client sees the | |||
connection close before receiving any status from the server, the | connection close before receiving any status from the server, the | |||
client SHOULD retry the request. If the client does retry this | client SHOULD retry the request. If the client does retry this | |||
request, it MAY use the following "binary exponential backoff" | request, it MAY use the following "binary exponential backoff" | |||
skipping to change at page 50, line 38 | skipping to change at page 57, line 25 | |||
1. Initiate a new connection to the server | 1. Initiate a new connection to the server | |||
2. Transmit the request-headers | 2. Transmit the request-headers | |||
3. Initialize a variable R to the estimated round-trip time to the | 3. Initialize a variable R to the estimated round-trip time to the | |||
server (e.g., based on the time it took to establish the | server (e.g., based on the time it took to establish the | |||
connection), or to a constant value of 5 seconds if the round- | connection), or to a constant value of 5 seconds if the round- | |||
trip time is not available. | trip time is not available. | |||
4. Compute T = R * (2**N), where N is the number of previous | 4. Compute T = R * (2**N), where N is the number of previous retries | |||
retries of this request. | of this request. | |||
5. Wait either for an error response from the server, or for T | 5. Wait either for an error response from the server, or for T | |||
seconds (whichever comes first) | seconds (whichever comes first) | |||
6. If no error response is received, after T seconds transmit the | 6. If no error response is received, after T seconds transmit the | |||
body of the request. | body of the request. | |||
7. If client sees that the connection is closed prematurely, | 7. If client sees that the connection is closed prematurely, repeat | |||
repeat from step 1 until the request is accepted, an error | from step 1 until the request is accepted, an error response is | |||
response is received, or the user becomes impatient and | received, or the user becomes impatient and terminates the retry | |||
terminates the retry process. | process. | |||
If at any point an error status is received, the client | If at any point an error status is received, the client | |||
- SHOULD NOT continue and | o SHOULD NOT continue and | |||
- SHOULD close the connection if it has not completed sending the | o SHOULD close the connection if it has not completed sending the | |||
request message. | request message. | |||
9 Method Definitions | 9 Method Definitions | |||
The set of common methods for HTTP/1.1 is defined below. Although | The set of common methods for HTTP/1.1 is defined below. Although | |||
this set can be expanded, additional methods cannot be assumed to | this set can be expanded, additional methods cannot be assumed to | |||
share the same semantics for separately extended clients and servers. | share the same semantics for separately extended clients and servers. | |||
The Host request-header field (section 14.23) MUST accompany all | The Host request-header field (section 14.23) MUST accompany all | |||
HTTP/1.1 requests. | HTTP/1.1 requests. | |||
9.1 Safe and Idempotent Methods | 9.1 Safe and Idempotent Methods | |||
9.1.1 Safe Methods | 9.1.1 Safe Methods | |||
Implementors should be aware that the software represents the user in | Implementors should be aware that the software represents the user in | |||
their interactions over the Internet, and should be careful to allow | their interactions over the Internet, and should be careful to allow | |||
the user to be aware of any actions they might take which may have an | the user to be aware of any actions they might take which may have an | |||
skipping to change at page 52, line 41 | skipping to change at page 59, line 30 | |||
specification does not define any use for such a body, future | specification does not define any use for such a body, future | |||
extensions to HTTP might use the OPTIONS body to make more detailed | extensions to HTTP might use the OPTIONS body to make more detailed | |||
queries on the server. A server that does not support such an | queries on the server. A server that does not support such an | |||
extension MAY discard the request body. | extension MAY discard the request body. | |||
If the Request-URI is an asterisk ("*"), the OPTIONS request is | If the Request-URI is an asterisk ("*"), the OPTIONS request is | |||
intended to apply to the server in general rather than to a specific | intended to apply to the server in general rather than to a specific | |||
resource. Since a server's communication options typically depend on | resource. Since a server's communication options typically depend on | |||
the resource, the "*" request is only useful as a "ping" or "no-op" | the resource, the "*" request is only useful as a "ping" or "no-op" | |||
type of method; it does nothing beyond allowing the client to test | type of method; it does nothing beyond allowing the client to test | |||
the capabilities of the server. For example, this can be used to test | the capabilities of the server. For example, this can be used to | |||
a proxy for HTTP/1.1 compliance (or lack thereof). | test a proxy for HTTP/1.1 compliance (or lack thereof). | |||
If the Request-URI is not an asterisk, the OPTIONS request applies | If the Request-URI is not an asterisk, the OPTIONS request applies | |||
only to the options that are available when communicating with that | only to the options that are available when communicating with that | |||
resource. | resource. | |||
A 200 response SHOULD include any header fields that indicate | A 200 response SHOULD include any header fields that indicate | |||
optional features implemented by the server and applicable to that | optional features implemented by the server and applicable to that | |||
resource (e.g., Allow), possibly including extensions not defined by | resource (e.g., Allow), possibly including extensions not defined by | |||
this specification. The response body, if any, SHOULD also include | this specification. The response body, if any, SHOULD also include | |||
information about the communication options. The format for such a | information about the communication options. The format for such a | |||
body is not defined by this specification, but might be defined by | body is not defined by this specification, but might be defined by | |||
future extensions to HTTP. Content negotiation MAY be used to select | future extensions to HTTP. Content negotiation MAY be used to select | |||
the appropriate response format. If no response body is included, the | the appropriate response format. If no response body is included, | |||
response MUST include a Content-Length field with a field-value of | the response MUST include a Content-Length field with a field-value | |||
"0". | of "0". | |||
The Max-Forwards request-header field MAY be used to target a | The Max-Forwards request-header field MAY be used to target a | |||
specific proxy in the request chain. When a proxy receives an OPTIONS | specific proxy in the request chain. When a proxy receives an | |||
request on an absoluteURI for which request forwarding is permitted, | OPTIONS request on an absoluteURI for which request forwarding is | |||
the proxy MUST check for a Max-Forwards field. If the Max-Forwards | permitted, the proxy MUST check for a Max-Forwards field. If the | |||
field-value is zero ("0"), the proxy MUST NOT forward the message; | Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward | |||
instead, the proxy SHOULD respond with its own communication options. | the message; instead, the proxy SHOULD respond with its own | |||
If the Max-Forwards field-value is an integer greater than zero, the | communication options. If the Max-Forwards field-value is an integer | |||
proxy MUST decrement the field-value when it forwards the request. If | greater than zero, the proxy MUST decrement the field-value when it | |||
no Max-Forwards field is present in the request, then the forwarded | forwards the request. If no Max-Forwards field is present in the | |||
request MUST NOT include a Max-Forwards field. | request, then the forwarded request MUST NOT include a Max-Forwards | |||
field. | ||||
9.3 GET | 9.3 GET | |||
The GET method means retrieve whatever information (in the form of an | The GET method means retrieve whatever information (in the form of an | |||
entity) is identified by the Request-URI. If the Request-URI refers | entity) is identified by the Request-URI. If the Request-URI refers | |||
to a data-producing process, it is the produced data which shall be | to a data-producing process, it is the produced data which shall be | |||
returned as the entity in the response and not the source text of the | returned as the entity in the response and not the source text of the | |||
process, unless that text happens to be the output of the process. | process, unless that text happens to be the output of the process. | |||
The semantics of the GET method change to a "conditional GET" if the | The semantics of the GET method change to a "conditional GET" if the | |||
request message includes an If-Modified-Since, If-Unmodified-Since, | request message includes an If-Modified-Since, If-Unmodified-Since, | |||
If-Match, If-None-Match, or If-Range header field. A conditional GET | If-Match, If-None-Match, or If-Range header field. A conditional GET | |||
method requests that the entity be transferred only under the | method requests that the entity be transferred only under the | |||
circumstances described by the conditional header field(s). The | circumstances described by the conditional header field(s). The | |||
conditional GET method is intended to reduce unnecessary network | conditional GET method is intended to reduce unnecessary network | |||
usage by allowing cached entities to be refreshed without requiring | usage by allowing cached entities to be refreshed without requiring | |||
multiple requests or transferring data already held by the client. | multiple requests or transferring data already held by the client. | |||
The semantics of the GET method change to a "partial GET" if the | The semantics of the GET method change to a "partial GET" if the | |||
request message includes a Range header field. A partial GET requests | request message includes a Range header field. A partial GET | |||
that only part of the entity be transferred, as described in section | requests that only part of the entity be transferred, as described in | |||
14.35. The partial GET method is intended to reduce unnecessary | section 14.35. The partial GET method is intended to reduce | |||
network usage by allowing partially-retrieved entities to be | unnecessary network usage by allowing partially-retrieved entities to | |||
completed without transferring data already held by the client. | be completed without transferring data already held by the client. | |||
The response to a GET request is cacheable if and only if it meets | The response to a GET request is cacheable if and only if it meets | |||
the requirements for HTTP caching described in section 13. | the requirements for HTTP caching described in section 13. | |||
See section 15.1.3 for security considerations when used for forms. | See section 15.1.3 for security considerations when used for forms. | |||
9.4 HEAD | 9.4 HEAD | |||
The HEAD method is identical to GET except that the server MUST NOT | The HEAD method is identical to GET except that the server MUST NOT | |||
return a message-body in the response. The metainformation contained | return a message-body in the response. The metainformation contained | |||
in the HTTP headers in response to a HEAD request SHOULD be identical | in the HTTP headers in response to a HEAD request SHOULD be identical | |||
to the information sent in response to a GET request. This method can | to the information sent in response to a GET request. This method | |||
be used for obtaining metainformation about the entity implied by the | can be used for obtaining metainformation about the entity implied by | |||
request without transferring the entity-body itself. This method is | the request without transferring the entity-body itself. This method | |||
often used for testing hypertext links for validity, accessibility, | is often used for testing hypertext links for validity, | |||
and recent modification. | accessibility, and recent modification. | |||
The response to a HEAD request MAY be cacheable in the sense that the | The response to a HEAD request MAY be cacheable in the sense that the | |||
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 a new subordinate of the resource | |||
identified by the Request-URI in the Request-Line. POST is designed | identified by the Request-URI in the Request-Line. POST is designed | |||
to allow a uniform method to cover the following functions: | to allow a uniform method to cover the following functions: | |||
- Annotation of existing resources; | o Annotation of existing resources; | |||
- Posting a message to a bulletin board, newsgroup, mailing list, | o Posting a message to a bulletin board, newsgroup, mailing list, or | |||
or similar group of articles; | similar group of articles; | |||
- 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; | |||
- 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 entity | server and is usually dependent on the Request-URI. The posted | |||
is subordinate to that URI in the same way that a file is subordinate | entity is subordinate to that URI in the same way that a file is | |||
to a directory containing it, a news article is subordinate to a | subordinate to a directory containing it, a news article is | |||
newsgroup to which it is posted, or a record is subordinate to a | subordinate to a newsgroup to which it is posted, or a record is | |||
database. | 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. However, | includes appropriate Cache-Control or Expires header fields. | |||
the 303 (See Other) response can be used to direct the user agent to | However, the 303 (See Other) response can be used to direct the user | |||
retrieve a cacheable resource. | agent to retrieve a cacheable resource. | |||
POST requests MUST obey the message transmission requirements set out | POST requests MUST obey the message transmission requirements set out | |||
in section 8.2. | in section 8.2. | |||
See section 15.1.3 for security considerations. | 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 | |||
skipping to change at page 55, line 36 | skipping to change at page 62, line 26 | |||
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 | |||
via the 201 (Created) response. If an existing resource is modified, | via the 201 (Created) response. If an existing resource is modified, | |||
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent | either the 200 (OK) or 204 (No Content) response codes SHOULD be sent | |||
to indicate successful completion of the request. If the resource | to indicate successful completion of the request. If the resource | |||
could not be created or modified with the Request-URI, an appropriate | could not be created or modified with the Request-URI, an appropriate | |||
error response SHOULD be given that reflects the nature of the | error response SHOULD be given that reflects the nature of the | |||
problem. The recipient of the entity MUST NOT ignore any Content-* | problem. The recipient of the entity MUST NOT ignore any Content-* | |||
(e.g. Content-Range) headers that it does not understand or implement | (e.g. Content-Range) headers that it does not understand or | |||
and MUST return a 501 (Not Implemented) response in such cases. | implement and MUST return a 501 (Not Implemented) response in such | |||
cases. | ||||
If the request passes through a cache and the Request-URI identifies | If the request passes through a cache and the Request-URI identifies | |||
one or more currently cached entities, those entries SHOULD be | one or more currently cached entities, those entries SHOULD be | |||
treated as stale. Responses to this method are not cacheable. | treated as stale. Responses to this method are not cacheable. | |||
The fundamental difference between the POST and PUT requests is | The fundamental difference between the POST and PUT requests is | |||
reflected in the different meaning of the Request-URI. The URI in a | reflected in the different meaning of the Request-URI. The URI in a | |||
POST request identifies the resource that will handle the enclosed | POST request identifies the resource that will handle the enclosed | |||
entity. That resource might be a data-accepting process, a gateway to | entity. That resource might be a data-accepting process, a gateway | |||
some other protocol, or a separate entity that accepts annotations. | to some other protocol, or a separate entity that accepts | |||
In contrast, the URI in a PUT request identifies the entity enclosed | annotations. In contrast, the URI in a PUT request identifies the | |||
with the request -- the user agent knows what URI is intended and the | entity enclosed with the request -- the user agent knows what URI is | |||
server MUST NOT attempt to apply the request to some other resource. | intended and the server MUST NOT attempt to apply the request to some | |||
If the server desires that the request be applied to a different URI, | other resource. If the server desires that the request be applied to | |||
it MUST send a 301 (Moved Permanently) response; the user agent MAY | a different URI, it MUST send a 301 (Moved Permanently) response; the | |||
then make its own decision regarding whether or not to redirect the | user agent MAY then make its own decision regarding whether or not to | |||
request. | redirect the request. | |||
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 in | version. In this case, a PUT request on a general URI might result | |||
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 | PUT requests MUST obey the message transmission requirements set out | |||
in section 8.2. | 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 human | identified by the Request-URI. This method MAY be overridden by | |||
intervention (or other means) on the origin server. The client cannot | human intervention (or other means) on the origin server. The client | |||
be guaranteed that the operation has been carried out, even if the | cannot be guaranteed that the operation has been carried out, even if | |||
status code returned from the origin server indicates that the action | the status code returned from the origin server indicates that the | |||
has been completed successfully. However, the server SHOULD NOT | action has been completed successfully. However, the server SHOULD | |||
indicate success unless, at the time the response is given, it | NOT indicate success unless, at the time the response is given, it | |||
intends to delete the resource or move it to an inaccessible | intends to delete the resource or move it to an inaccessible | |||
location. | location. | |||
A successful response SHOULD be 200 (OK) if the response includes an | A successful response SHOULD be 200 (OK) if the response includes an | |||
entity describing the status, 202 (Accepted) if the action has not | entity describing the status, 202 (Accepted) if the action has not | |||
yet been enacted, or 204 (No Content) if the action has been enacted | yet been enacted, or 204 (No Content) if the action has been enacted | |||
but the response does not include an entity. | but the response does not include an entity. | |||
If the request passes through a cache and the Request-URI identifies | If the request passes through a cache and the Request-URI identifies | |||
one or more currently cached entities, those entries SHOULD be | one or more currently cached entities, those entries SHOULD be | |||
treated as stale. Responses to this method are not cacheable. | treated as stale. Responses to this method are not cacheable. | |||
9.8 TRACE | 9.8 TRACE | |||
The TRACE method is used to invoke a remote, application-layer loop- | The TRACE method is used to invoke a remote, application-layer loop- | |||
back of the request message. The final recipient of the request | back of the request message. The final recipient of the request | |||
SHOULD reflect the message received back to the client as the | SHOULD reflect the message received back to the client as the entity- | |||
entity-body of a 200 (OK) response. The final recipient is either the | body of a 200 (OK) response. The final recipient is either the | |||
origin server or the first proxy or gateway to receive a Max-Forwards | origin server or the first proxy or gateway to receive a Max-Forwards | |||
value of zero (0) in the request (see section 14.31). A TRACE request | value of zero (0) in the request (see section 14.31). A TRACE | |||
MUST NOT include an entity. | request MUST NOT include an entity. | |||
TRACE allows the client to see what is being received at the other | TRACE allows the client to see what is being received at the other | |||
end of the request chain and use that data for testing or diagnostic | end of the request chain and use that data for testing or diagnostic | |||
information. The value of the Via header field (section 14.45) is of | information. The value of the Via header field (section 14.45) is of | |||
particular interest, since it acts as a trace of the request chain. | particular interest, since it acts as a trace of the request chain. | |||
Use of the Max-Forwards header field allows the client to limit the | Use of the Max-Forwards header field allows the client to limit the | |||
length of the request chain, which is useful for testing a chain of | length of the request chain, which is useful for testing a chain of | |||
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 | request message in the entity-body, with a Content-Type of "message/ | |||
"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 [44]). | |||
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 | |||
skipping to change at page 58, line 10 | skipping to change at page 65, line 34 | |||
Proxies MUST forward 1xx responses, unless the connection between the | Proxies MUST forward 1xx responses, unless the connection between the | |||
proxy and its client has been closed, or unless the proxy itself | proxy and its client has been closed, or unless the proxy itself | |||
requested the generation of the 1xx response. (For example, if a | requested the generation of the 1xx response. (For example, if a | |||
proxy adds a "Expect: 100-continue" field when it forwards a request, | proxy adds a "Expect: 100-continue" field when it forwards a request, | |||
then it need not forward the corresponding 100 (Continue) | then it need not forward the corresponding 100 (Continue) | |||
response(s).) | response(s).) | |||
10.1.1 100 Continue | 10.1.1 100 Continue | |||
The client SHOULD continue with its request. This interim response is | The client SHOULD continue with its request. This interim response | |||
used to inform the client that the initial part of the request has | is used to inform the client that the initial part of the request has | |||
been received and has not yet been rejected by the server. The client | been received and has not yet been rejected by the server. The | |||
SHOULD continue by sending the remainder of the request or, if the | client SHOULD continue by sending the remainder of the request or, if | |||
request has already been completed, ignore this response. The server | the request has already been completed, ignore this response. The | |||
MUST send a final response after the request has been completed. See | server MUST send a final response after the request has been | |||
section 8.2.3 for detailed discussion of the use and handling of this | completed. See section 8.2.3 for detailed discussion of the use and | |||
status code. | handling of this status code. | |||
10.1.2 101 Switching Protocols | 10.1.2 101 Switching Protocols | |||
The server understands and is willing to comply with the client's | The server understands and is willing to comply with the client's | |||
request, via the Upgrade message header field (section 14.42), for a | request, via the Upgrade message header field (section 14.42), for a | |||
change in the application protocol being used on this connection. The | change in the application protocol being used on this connection. | |||
server will switch protocols to those defined by the response's | The server will switch protocols to those defined by the response's | |||
Upgrade header field immediately after the empty line which | Upgrade header field immediately after the empty line which | |||
terminates the 101 response. | terminates the 101 response. | |||
The protocol SHOULD be switched only when it is advantageous to do | The protocol SHOULD be switched only when it is advantageous to do | |||
so. For example, switching to a newer version of HTTP is advantageous | so. For example, switching to a newer version of HTTP is | |||
over older versions, and switching to a real-time, synchronous | advantageous over older versions, and switching to a real-time, | |||
protocol might be advantageous when delivering resources that use | synchronous protocol might be advantageous when delivering resources | |||
such features. | that use such features. | |||
10.2 Successful 2xx | 10.2 Successful 2xx | |||
This class of status code indicates that the client's request was | This class of status code indicates that the client's request was | |||
successfully received, understood, and accepted. | successfully received, understood, and accepted. | |||
10.2.1 200 OK | 10.2.1 200 OK | |||
The request has succeeded. The information returned with the response | The request has succeeded. The information returned with the | |||
is dependent on the method used in the request, for example: | response is dependent on the method used in the request, for example: | |||
GET an entity corresponding to the requested resource is sent in | GET an entity corresponding to the requested resource is sent in the | |||
the response; | response; | |||
HEAD the entity-header fields corresponding to the requested | HEAD the entity-header fields corresponding to the requested | |||
resource are sent in the response without any message-body; | resource are sent in the response without any message-body; | |||
POST an entity describing or containing the result of the action; | POST an entity describing or containing the result of the action; | |||
TRACE an entity containing the request message as received by the | TRACE an entity containing the request message as received by the | |||
end server. | end server. | |||
10.2.2 201 Created | 10.2.2 201 Created | |||
The request has been fulfilled and resulted in a new resource being | The request has been fulfilled and resulted in a new resource being | |||
created. The newly created resource can be referenced by the URI(s) | created. The newly created resource can be referenced by the URI(s) | |||
returned in the entity of the response, with the most specific URI | returned in the entity of the response, with the most specific URI | |||
for the resource given by a Location header field. The response | for the resource given by a Location header field. The response | |||
SHOULD include an entity containing a list of resource | SHOULD include an entity containing a list of resource | |||
skipping to change at page 59, line 46 | skipping to change at page 67, line 21 | |||
requiring that the user agent's connection to the server persist | requiring that the user agent's connection to the server persist | |||
until the process is completed. The entity returned with this | until the process is completed. The entity returned with this | |||
response SHOULD include an indication of the request's current status | response SHOULD include an indication of the request's current status | |||
and either a pointer to a status monitor or some estimate of when the | and either a pointer to a status monitor or some estimate of when the | |||
user can expect the request to be fulfilled. | user can expect the request to be fulfilled. | |||
10.2.4 203 Non-Authoritative Information | 10.2.4 203 Non-Authoritative Information | |||
The returned metainformation in the entity-header is not the | The returned metainformation in the entity-header is not the | |||
definitive set as available from the origin server, but is gathered | definitive set as available from the origin server, but is gathered | |||
from a local or a third-party copy. The set presented MAY be a subset | from a local or a third-party copy. The set presented MAY be a | |||
or superset of the original version. For example, including local | subset or superset of the original version. For example, including | |||
annotation information about the resource might result in a superset | local annotation information about the resource might result in a | |||
of the metainformation known by the origin server. Use of this | superset of the metainformation known by the origin server. Use of | |||
response code is not required and is only appropriate when the | this response code is not required and is only appropriate when the | |||
response would otherwise be 200 (OK). | response would otherwise be 200 (OK). | |||
10.2.5 204 No Content | 10.2.5 204 No Content | |||
The server has fulfilled the request but does not need to return an | The server has fulfilled the request but does not need to return an | |||
entity-body, and might want to return updated metainformation. The | entity-body, and might want to return updated metainformation. The | |||
response MAY include new or updated metainformation in the form of | response MAY include new or updated metainformation in the form of | |||
entity-headers, which if present SHOULD be associated with the | entity-headers, which if present SHOULD be associated with the | |||
requested variant. | requested variant. | |||
skipping to change at page 60, line 41 | skipping to change at page 68, line 16 | |||
10.2.7 206 Partial Content | 10.2.7 206 Partial Content | |||
The server has fulfilled the partial GET request for the resource. | The server has fulfilled the partial GET request for the resource. | |||
The request MUST have included a Range header field (section 14.35) | The request MUST have included a Range header field (section 14.35) | |||
indicating the desired range, and MAY have included an If-Range | indicating the desired range, and MAY have included an If-Range | |||
header field (section 14.27) to make the request conditional. | header field (section 14.27) to make the request conditional. | |||
The response MUST include the following header fields: | The response MUST include the following header fields: | |||
- Either a Content-Range header field (section 14.16) indicating | o Either a Content-Range header field (section 14.16) indicating the | |||
the range included with this response, or a multipart/byteranges | range included with this response, or a multipart/byteranges | |||
Content-Type including Content-Range fields for each part. If a | Content-Type including Content-Range fields for each part. If a | |||
Content-Length header field is present in the response, its | Content-Length header field is present in the response, its value | |||
value MUST match the actual number of OCTETs transmitted in the | MUST match the actual number of OCTETs transmitted in the message- | |||
message-body. | body. | |||
- Date | o Date | |||
- 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 | |||
- 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 that used a | |||
strong cache validator (see section 13.3.3), the response SHOULD NOT | strong cache validator (see section 13.3.3), the response SHOULD NOT | |||
include other entity-headers. If the response is the result of an | include other entity-headers. If the response is the result of an | |||
If-Range request that used a weak validator, the response MUST NOT | If-Range request that used a weak validator, the response MUST NOT | |||
include other entity-headers; this prevents inconsistencies between | include other entity-headers; this prevents inconsistencies between | |||
cached entity-bodies and updated headers. Otherwise, the response | cached entity-bodies and updated headers. Otherwise, the response | |||
MUST include all of the entity-headers that would have been returned | MUST include all of the entity-headers that would have been returned | |||
skipping to change at page 61, line 30 | skipping to change at page 69, line 6 | |||
A cache that does not support the Range and Content-Range headers | A cache that does not support the Range and Content-Range headers | |||
MUST NOT cache 206 (Partial) responses. | MUST NOT cache 206 (Partial) responses. | |||
10.3 Redirection 3xx | 10.3 Redirection 3xx | |||
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, since | GET or HEAD. A client SHOULD detect infinite redirection loops, | |||
such loops generate network traffic for each redirection. | since such loops generate network traffic for each redirection. | |||
Note: previous versions of this specification recommended a | Note: previous versions of this specification recommended a | |||
maximum of five redirections. Content developers should be aware | maximum of five redirections. Content developers should be aware | |||
that there might be clients that implement such a fixed | that there might be clients that implement such a fixed | |||
limitation. | limitation. | |||
10.3.1 300 Multiple Choices | 10.3.1 300 Multiple Choices | |||
The requested resource corresponds to any one of a set of | The requested resource corresponds to any one of a set of | |||
representations, each with its own specific location, and agent- | representations, each with its own specific location, and agent- | |||
driven negotiation information (section 12) is being provided so that | driven negotiation information (section 12) is being provided so that | |||
the user (or user agent) can select a preferred representation and | the user (or user agent) can select a preferred representation and | |||
redirect its request to that location. | redirect its request to that location. | |||
Unless it was a HEAD request, the response SHOULD include an entity | Unless it was a HEAD request, the response SHOULD include an entity | |||
containing a list of resource characteristics and location(s) from | containing a list of resource characteristics and location(s) from | |||
which the user or user agent can choose the one most appropriate. The | which the user or user agent can choose the one most appropriate. | |||
entity format is specified by the media type given in the Content- | The entity format is specified by the media type given in the | |||
Type header field. Depending upon the format and the capabilities of | Content-Type header field. Depending upon the format and the | |||
the user agent, selection of the most appropriate choice MAY be | capabilities of the user agent, selection of the most appropriate | |||
performed automatically. However, this specification does not define | choice MAY be performed automatically. However, this specification | |||
any standard for such automatic selection. | does not define any standard for such automatic selection. | |||
If the server has a preferred choice of representation, it SHOULD | If the server has a preferred choice of representation, it SHOULD | |||
include the specific URI for that representation in the Location | include the specific URI for that representation in the Location | |||
field; user agents MAY use the Location field value for automatic | field; user agents MAY use the Location field value for automatic | |||
redirection. This response is cacheable unless indicated otherwise. | redirection. This response is cacheable unless indicated otherwise. | |||
10.3.2 301 Moved Permanently | 10.3.2 301 Moved Permanently | |||
The requested resource has been assigned a new permanent URI and any | The requested resource has been assigned a new permanent URI and any | |||
future references to this resource SHOULD use one of the returned | future references to this resource SHOULD use one of the returned | |||
skipping to change at page 63, line 48 | skipping to change at page 71, line 20 | |||
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: | |||
- 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 [RFC 2068], section 14.19), caches will operate | |||
correctly. | correctly. | |||
- 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 | |||
- 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 section | If the conditional GET used a strong cache validator (see | |||
13.3.3), the response SHOULD NOT include other entity-headers. | section 13.3.3), the response SHOULD NOT include other entity- | |||
Otherwise (i.e., the conditional GET used a weak validator), the | headers. Otherwise (i.e., the conditional GET used a weak | |||
response MUST NOT include other entity-headers; this prevents | validator), the response MUST NOT include other entity-headers; this | |||
inconsistencies between cached entity-bodies and updated headers. | prevents inconsistencies between cached entity-bodies and updated | |||
headers. | ||||
If a 304 response indicates an entity not currently cached, then the | If a 304 response indicates an entity not currently cached, then the | |||
cache MUST disregard the response and repeat the request without the | cache MUST disregard the response and repeat the request without the | |||
conditional. | conditional. | |||
If a cache uses a received 304 response to update a cache entry, the | If a cache uses a received 304 response to update a cache entry, the | |||
cache MUST update the entry to reflect any new field values given in | cache MUST update the entry to reflect any new field values given in | |||
the response. | the response. | |||
10.3.6 305 Use Proxy | 10.3.6 305 Use Proxy | |||
skipping to change at page 65, line 29 | skipping to change at page 72, line 41 | |||
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 other | |||
than GET or HEAD, the user agent MUST NOT automatically redirect the | than GET or HEAD, the user agent MUST NOT automatically redirect the | |||
request unless it can be confirmed by the user, since this might | request unless it can be confirmed by the user, since this might | |||
change the conditions under which the request was issued. | 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 request, | client seems to have erred. Except when responding to a HEAD | |||
the server SHOULD include an entity containing an explanation of the | request, the server SHOULD include an entity containing an | |||
error situation, and whether it is a temporary or permanent | explanation of the error situation, and whether it is a temporary or | |||
condition. These status codes are applicable to any request method. | permanent condition. These status codes are applicable to any | |||
User agents SHOULD display any included entity to the user. | request method. User agents SHOULD display any included entity to | |||
the user. | ||||
If the client is sending data, a server implementation using TCP | If the client is sending data, a server implementation using TCP | |||
SHOULD be careful to ensure that the client acknowledges receipt of | SHOULD be careful to ensure that the client acknowledges receipt of | |||
the packet(s) containing the response, before the server closes the | the packet(s) containing the response, before the server closes the | |||
input connection. If the client continues sending data to the server | input connection. If the client continues sending data to the server | |||
after the close, the server's TCP stack will send a reset packet to | after the close, the server's TCP stack will send a reset packet to | |||
the client, which may erase the client's unacknowledged input buffers | the client, which may erase the client's unacknowledged input buffers | |||
before they can be read and interpreted by the HTTP application. | before they can be read and interpreted by the HTTP application. | |||
10.4.1 400 Bad Request | 10.4.1 400 Bad Request | |||
The request could not be understood by the server due to malformed | The request could not be understood by the server due to malformed | |||
syntax. The client SHOULD NOT repeat the request without | syntax. The client SHOULD NOT repeat the request without | |||
modifications. | modifications. | |||
10.4.2 401 Unauthorized | 10.4.2 401 Unauthorized | |||
The request requires user authentication. The response MUST include a | The request requires user authentication. The response MUST include | |||
WWW-Authenticate header field (section 14.47) containing a challenge | a WWW-Authenticate header field (section 14.47) containing a | |||
applicable to the requested resource. The client MAY repeat the | challenge applicable to the requested resource. The client MAY | |||
request with a suitable Authorization header field (section 14.8). If | repeat the request with a suitable Authorization header field | |||
the request already included Authorization credentials, then the 401 | (section 14.8). If the request already included Authorization | |||
response indicates that authorization has been refused for those | credentials, then the 401 response indicates that authorization has | |||
credentials. If the 401 response contains the same challenge as the | been refused for those credentials. If the 401 response contains the | |||
prior response, and the user agent has already attempted | same challenge as the prior response, and the user agent has already | |||
authentication at least once, then the user SHOULD be presented the | attempted authentication at least once, then the user SHOULD be | |||
entity that was given in the response, since that entity might | presented the entity that was given in the response, since that | |||
include relevant diagnostic information. HTTP access authentication | entity might include relevant diagnostic information. HTTP access | |||
is explained in "HTTP Authentication: Basic and Digest Access | authentication is explained in "HTTP Authentication: Basic and Digest | |||
Authentication" [43]. | Access Authentication" [43]. | |||
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 67, line 23 | skipping to change at page 74, line 31 | |||
from which the user or user agent can choose the one most | from which the user or user agent can choose the one most | |||
appropriate. The entity format is specified by the media type given | appropriate. The entity format is specified by the media type given | |||
in the Content-Type header field. Depending upon the format and the | in the Content-Type header field. Depending upon the format and the | |||
capabilities of the user agent, selection of the most appropriate | capabilities of the user agent, selection of the most appropriate | |||
choice MAY be performed automatically. However, this specification | choice MAY be performed automatically. However, this specification | |||
does not define any standard for such automatic selection. | does not define any standard for such automatic selection. | |||
Note: HTTP/1.1 servers are allowed to return responses which are | Note: HTTP/1.1 servers are allowed to return responses which are | |||
not acceptable according to the accept headers sent in the | not acceptable according to the accept headers sent in the | |||
request. In some cases, this may even be preferable to sending a | request. In some cases, this may even be preferable to sending a | |||
406 response. User agents are encouraged to inspect the headers of | 406 response. User agents are encouraged to inspect the headers | |||
an incoming response to determine if it is acceptable. | of an incoming response to determine if it is acceptable. | |||
If the response could be unacceptable, a user agent SHOULD | If the response could be unacceptable, a user agent SHOULD | |||
temporarily stop receipt of more data and query the user for a | temporarily stop receipt of more data and query the user for a | |||
decision on further actions. | decision on further actions. | |||
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 explained | header field (section 14.34). HTTP access authentication is | |||
in "HTTP Authentication: Basic and Digest Access Authentication" | explained in "HTTP Authentication: Basic and Digest Access | |||
[43]. | Authentication" [43]. | |||
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 68, line 15 | skipping to change at page 75, line 28 | |||
Ideally, the response entity would include enough information for the | Ideally, the response entity would include enough information for the | |||
user or user agent to fix the problem; however, that might not be | user or user agent to fix the problem; however, that might not be | |||
possible and is not required. | possible and is not required. | |||
Conflicts are most likely to occur in response to a PUT request. For | Conflicts are most likely to occur in response to a PUT request. For | |||
example, if versioning were being used and the entity being PUT | example, if versioning were being used and the entity being PUT | |||
included changes to a resource which conflict with those made by an | included changes to a resource which conflict with those made by an | |||
earlier (third-party) request, the server might use the 409 response | earlier (third-party) request, the server might use the 409 response | |||
to indicate that it can't complete the request. In this case, the | to indicate that it can't complete the request. In this case, the | |||
response entity would likely contain a list of the differences | response entity would likely contain a list of the differences | |||
between the two versions in a format defined by the response | between the two versions in a format defined by the response Content- | |||
Content-Type. | Type. | |||
10.4.11 410 Gone | 10.4.11 410 Gone | |||
The requested resource is no longer available at the server and no | The requested resource is no longer available at the server and no | |||
forwarding address is known. This condition is expected to be | forwarding address is known. This condition is expected to be | |||
considered permanent. Clients with link editing capabilities SHOULD | considered permanent. Clients with link editing capabilities SHOULD | |||
delete references to the Request-URI after user approval. If the | delete references to the Request-URI after user approval. If the | |||
server does not know, or has no facility to determine, whether or not | server does not know, or has no facility to determine, whether or not | |||
the condition is permanent, the status code 404 (Not Found) SHOULD be | the condition is permanent, the status code 404 (Not Found) SHOULD be | |||
used instead. This response is cacheable unless indicated otherwise. | used instead. This response is cacheable unless indicated otherwise. | |||
The 410 response is primarily intended to assist the task of web | The 410 response is primarily intended to assist the task of web | |||
maintenance by notifying the recipient that the resource is | maintenance by notifying the recipient that the resource is | |||
intentionally unavailable and that the server owners desire that | intentionally unavailable and that the server owners desire that | |||
remote links to that resource be removed. Such an event is common for | remote links to that resource be removed. Such an event is common | |||
limited-time, promotional services and for resources belonging to | for limited-time, promotional services and for resources belonging to | |||
individuals no longer working at the server's site. It is not | individuals no longer working at the server's site. It is not | |||
necessary to mark all permanently unavailable resources as "gone" or | necessary to mark all permanently unavailable resources as "gone" or | |||
to keep the mark for any length of time -- that is left to the | to keep the mark for any length of time -- that is left to the | |||
discretion of the server owner. | discretion of the server owner. | |||
10.4.12 411 Length Required | 10.4.12 411 Length Required | |||
The server refuses to accept the request without a defined Content- | The server refuses to accept the request without a defined Content- | |||
Length. The client MAY repeat the request if it adds a valid | Length. The client MAY repeat the request if it adds a valid | |||
Content-Length header field containing the length of the message-body | Content-Length header field containing the length of the message-body | |||
skipping to change at page 69, line 46 | skipping to change at page 77, line 12 | |||
A server SHOULD return a response with this status code if a request | A server SHOULD return a response with this status code if a request | |||
included a Range request-header field (section 14.35), and none of | included a Range request-header field (section 14.35), and none of | |||
the range-specifier values in this field overlap the current extent | the range-specifier values in this field overlap the current extent | |||
of the selected resource, and the request did not include an If-Range | of the selected resource, and the request did not include an If-Range | |||
request-header field. (For byte-ranges, this means that the first- | request-header field. (For byte-ranges, this means that the first- | |||
byte-pos of all of the byte-range-spec values were greater than the | byte-pos of all of the byte-range-spec values were greater than the | |||
current length of the selected resource.) | current length of the selected resource.) | |||
When this status code is returned for a byte-range request, the | When this status code is returned for a byte-range request, the | |||
response SHOULD include a Content-Range entity-header field | response SHOULD include a Content-Range entity-header field | |||
specifying the current length of the selected resource (see section | specifying the current length of the selected resource (see | |||
14.16). This response MUST NOT use the multipart/byteranges content- | section 14.16). This response MUST NOT use the multipart/byteranges | |||
type. | content-type. | |||
10.4.18 417 Expectation Failed | 10.4.18 417 Expectation Failed | |||
The expectation given in an Expect request-header field (see section | The expectation given in an Expect request-header field (see | |||
14.20) could not be met by this server, or, if the server is a proxy, | section 14.20) could not be met by this server, or, if the server is | |||
the server has unambiguous evidence that the request could not be met | a proxy, the server has unambiguous evidence that the request could | |||
by the next-hop server. | not be met by the next-hop server. | |||
10.5 Server Error 5xx | 10.5 Server Error 5xx | |||
Response status codes beginning with the digit "5" indicate cases in | Response status codes beginning with the digit "5" indicate cases in | |||
which the server is aware that it has erred or is incapable of | which the server is aware that it has erred or is incapable of | |||
performing the request. Except when responding to a HEAD request, the | performing the request. Except when responding to a HEAD request, | |||
server SHOULD include an entity containing an explanation of the | the server SHOULD include an entity containing an explanation of the | |||
error situation, and whether it is a temporary or permanent | error situation, and whether it is a temporary or permanent | |||
condition. User agents SHOULD display any included entity to the | condition. User agents SHOULD display any included entity to the | |||
user. These response codes are applicable to any request method. | user. These response codes are applicable to any request method. | |||
10.5.1 500 Internal Server Error | 10.5.1 500 Internal Server Error | |||
The server encountered an unexpected condition which prevented it | The server encountered an unexpected condition which prevented it | |||
from fulfilling the request. | from fulfilling the request. | |||
10.5.2 501 Not Implemented | 10.5.2 501 Not Implemented | |||
skipping to change at page 70, line 50 | skipping to change at page 78, line 15 | |||
10.5.4 503 Service Unavailable | 10.5.4 503 Service Unavailable | |||
The server is currently unable to handle the request due to a | The server is currently unable to handle the request due to a | |||
temporary overloading or maintenance of the server. The implication | temporary overloading or maintenance of the server. The implication | |||
is that this is a temporary condition which will be alleviated after | is that this is a temporary condition which will be alleviated after | |||
some delay. If known, the length of the delay MAY be indicated in a | some delay. If known, the length of the delay MAY be indicated in a | |||
Retry-After header. If no Retry-After is given, the client SHOULD | Retry-After header. If no Retry-After is given, the client SHOULD | |||
handle the response as it would for a 500 response. | handle the response as it would for a 500 response. | |||
Note: The existence of the 503 status code does not imply that a | Note: The existence of the 503 status code does not imply that a | |||
server must use it when becoming overloaded. Some servers may wish | server must use it when becoming overloaded. Some servers may | |||
to simply refuse the connection. | wish to simply refuse the connection. | |||
10.5.5 504 Gateway Timeout | 10.5.5 504 Gateway Timeout | |||
The server, while acting as a gateway or proxy, did not receive a | The server, while acting as a gateway or proxy, did not receive a | |||
timely response from the upstream server specified by the URI (e.g. | timely response from the upstream server specified by the URI (e.g. | |||
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed | |||
to access in attempting to complete the request. | to access in attempting to complete the request. | |||
Note: Note to implementors: some deployed proxies are known to | Note: Note to implementors: some deployed proxies are known to | |||
return 400 or 500 when DNS lookups time out. | return 400 or 500 when DNS lookups time out. | |||
10.5.6 505 HTTP Version Not Supported | 10.5.6 505 HTTP Version Not Supported | |||
The server does not support, or refuses to support, the HTTP protocol | The server does not support, or refuses to support, the HTTP protocol | |||
version that was used in the request message. The server is | version that was used in the request message. The server is | |||
indicating that it is unable or unwilling to complete the request | indicating that it is unable or unwilling to complete the request | |||
using the same major version as the client, as described in section | using the same major version as the client, as described in | |||
3.1, other than with this error message. The response SHOULD contain | section 3.1, other than with this error message. The response SHOULD | |||
an entity describing why that version is not supported and what other | contain an entity describing why that version is not supported and | |||
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" [43]. This | |||
specification adopts the definitions of "challenge" and "credentials" | specification adopts the definitions of "challenge" and "credentials" | |||
from that specification. | 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 the | request. Unfortunately for servers and caches, not all users have | |||
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" -- | |||
the process of selecting the best representation for a given response | the process of selecting the best representation for a given response | |||
when there are multiple representations available. | when there are multiple representations available. | |||
Note: This is not called "format negotiation" because the | Note: This is not called "format negotiation" because the | |||
alternate representations may be of the same media type, but use | alternate representations may be of the same media type, but use | |||
different capabilities of that type, be in different languages, | different capabilities of that type, be in different languages, | |||
etc. | etc. | |||
Any response containing an entity-body MAY be subject to negotiation, | Any response containing an entity-body MAY be subject to negotiation, | |||
including error responses. | including error responses. | |||
There are two kinds of content negotiation which are possible in | There are two kinds of content negotiation which are possible in | |||
HTTP: server-driven and agent-driven negotiation. These two kinds of | HTTP: server-driven and agent-driven negotiation. These two kinds of | |||
negotiation are orthogonal and thus may be used separately or in | negotiation are orthogonal and thus may be used separately or in | |||
combination. One method of combination, referred to as transparent | combination. One method of combination, referred to as transparent | |||
negotiation, occurs when a cache uses the agent-driven negotiation | negotiation, occurs when a cache uses the agent-driven negotiation | |||
information provided by the origin server in order to provide | information provided by the origin server in order to provide server- | |||
server-driven negotiation for subsequent requests. | driven negotiation for subsequent requests. | |||
12.1 Server-driven Negotiation | 12.1 Server-driven Negotiation | |||
If the selection of the best representation for a response is made by | If the selection of the best representation for a response is made by | |||
an algorithm located at the server, it is called server-driven | an algorithm located at the server, it is called server-driven | |||
negotiation. Selection is based on the available representations of | negotiation. Selection is based on the available representations of | |||
the response (the dimensions over which it can vary; e.g. language, | the response (the dimensions over which it can vary; e.g. language, | |||
content-coding, etc.) and the contents of particular header fields in | content-coding, etc.) and the contents of particular header fields in | |||
the request message or on other information pertaining to the request | the request message or on other information pertaining to the request | |||
(such as the network address of the client). | (such as the network address of the client). | |||
Server-driven negotiation is advantageous when the algorithm for | Server-driven negotiation is advantageous when the algorithm for | |||
selecting from among the available representations is difficult to | selecting from among the available representations is difficult to | |||
describe to the user agent, or when the server desires to send its | describe to the user agent, or when the server desires to send its | |||
"best guess" to the client along with the first response (hoping to | "best guess" to the client along with the first response (hoping to | |||
avoid the round-trip delay of a subsequent request if the "best | avoid the round-trip delay of a subsequent request if the "best | |||
guess" is good enough for the user). In order to improve the server's | guess" is good enough for the user). In order to improve the | |||
guess, the user agent MAY include request header fields (Accept, | server's guess, the user agent MAY include request header fields | |||
Accept-Language, Accept-Encoding, etc.) which describe its | (Accept, Accept-Language, Accept-Encoding, etc.) which describe its | |||
preferences for such a response. | preferences for such a response. | |||
Server-driven negotiation has disadvantages: | Server-driven negotiation has disadvantages: | |||
1. It is impossible for the server to accurately determine what | 1. It is impossible for the server to accurately determine what | |||
might be "best" for any given user, since that would require | might be "best" for any given user, since that would require | |||
complete knowledge of both the capabilities of the user agent | complete knowledge of both the capabilities of the user agent and | |||
and the intended use for the response (e.g., does the user want | the intended use for the response (e.g., does the user want to | |||
to view it on screen or print it on paper?). | view it on screen or print it on paper?). | |||
2. Having the user agent describe its capabilities in every | 2. Having the user agent describe its capabilities in every request | |||
request can be both very inefficient (given that only a small | can be both very inefficient (given that only a small percentage | |||
percentage of responses have multiple representations) and a | of responses have multiple representations) and a potential | |||
potential violation of the user's privacy. | violation of the user's privacy. | |||
3. It complicates the implementation of an origin server and the | 3. It complicates the implementation of an origin server and the | |||
algorithms for generating responses to a request. | algorithms for generating responses to a request. | |||
4. It may limit a public cache's ability to use the same response | 4. It may limit a public cache's ability to use the same response | |||
for multiple user's requests. | for multiple user's requests. | |||
HTTP/1.1 includes the following request-header fields for enabling | HTTP/1.1 includes the following request-header fields for enabling | |||
server-driven negotiation through description of user agent | server-driven negotiation through description of user agent | |||
capabilities and user preferences: Accept (section 14.1), Accept- | capabilities and user preferences: Accept (section 14.1), Accept- | |||
Charset (section 14.2), Accept-Encoding (section 14.3), Accept- | Charset (section 14.2), Accept-Encoding (section 14.3), Accept- | |||
Language (section 14.4), and User-Agent (section 14.43). However, an | Language (section 14.4), and User-Agent (section 14.43). However, an | |||
origin server is not limited to these dimensions and MAY vary the | origin server is not limited to these dimensions and MAY vary the | |||
response based on any aspect of the request, including information | response based on any aspect of the request, including information | |||
outside the request-header fields or within extension header fields | outside the request-header fields or within extension header fields | |||
not defined by this specification. | not defined by this specification. | |||
The Vary header field can be used to express the parameters the | The Vary header field can be used to express the parameters the | |||
server uses to select a representation that is subject to server- | server uses to select a representation that is subject to server- | |||
driven negotiation. See section 13.6 for use of the Vary header field | driven negotiation. See section 13.6 for use of the Vary header | |||
by caches and section 14.44 for use of the Vary header field by | field by caches and section 14.44 for use of the Vary header field by | |||
servers. | servers. | |||
12.2 Agent-driven Negotiation | 12.2 Agent-driven Negotiation | |||
With agent-driven negotiation, selection of the best representation | With agent-driven negotiation, selection of the best representation | |||
for a response is performed by the user agent after receiving an | for a response is performed by the user agent after receiving an | |||
initial response from the origin server. Selection is based on a list | initial response from the origin server. Selection is based on a | |||
of the available representations of the response included within the | list of the available representations of the response included within | |||
header fields or entity-body of the initial response, with each | the header fields or entity-body of the initial response, with each | |||
representation identified by its own URI. Selection from among the | representation identified by its own URI. Selection from among the | |||
representations may be performed automatically (if the user agent is | representations may be performed automatically (if the user agent is | |||
capable of doing so) or manually by the user selecting from a | capable of doing so) or manually by the user selecting from a | |||
generated (possibly hypertext) menu. | generated (possibly hypertext) menu. | |||
Agent-driven negotiation is advantageous when the response would vary | Agent-driven negotiation is advantageous when the response would vary | |||
over commonly-used dimensions (such as type, language, or encoding), | over commonly-used dimensions (such as type, language, or encoding), | |||
when the origin server is unable to determine a user agent's | when the origin server is unable to determine a user agent's | |||
capabilities from examining the request, and generally when public | capabilities from examining the request, and generally when public | |||
caches are used to distribute server load and reduce network usage. | caches are used to distribute server load and reduce network usage. | |||
skipping to change at page 74, line 13 | skipping to change at page 82, line 25 | |||
HTTP/1.1. | HTTP/1.1. | |||
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) | |||
status codes for enabling agent-driven negotiation when the server is | status codes for enabling agent-driven negotiation when the server is | |||
unwilling or unable to provide a varying response using server-driven | unwilling or unable to provide a varying response using server-driven | |||
negotiation. | negotiation. | |||
12.3 Transparent Negotiation | 12.3 Transparent Negotiation | |||
Transparent negotiation is a combination of both server-driven and | Transparent negotiation is a combination of both server-driven and | |||
agent-driven negotiation. When a cache is supplied with a form of the | agent-driven negotiation. When a cache is supplied with a form of | |||
list of available representations of the response (as in agent-driven | the list of available representations of the response (as in agent- | |||
negotiation) and the dimensions of variance are completely understood | driven negotiation) and the dimensions of variance are completely | |||
by the cache, then the cache becomes capable of performing server- | understood by the cache, then the cache becomes capable of performing | |||
driven negotiation on behalf of the origin server for subsequent | server-driven negotiation on behalf of the origin server for | |||
requests on that resource. | subsequent requests on that resource. | |||
Transparent negotiation has the advantage of distributing the | Transparent negotiation has the advantage of distributing the | |||
negotiation work that would otherwise be required of the origin | negotiation work that would otherwise be required of the origin | |||
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. | |||
skipping to change at page 74, line 42 | skipping to change at page 83, line 17 | |||
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 | |||
performance. The goal of caching in HTTP/1.1 is to eliminate the need | performance. The goal of caching in HTTP/1.1 is to eliminate the | |||
to send requests in many cases, and to eliminate the need to send | need to send requests in many cases, and to eliminate the need to | |||
full responses in many other cases. The former reduces the number of | send full responses in many other cases. The former reduces the | |||
network round-trips required for many operations; we use an | number of network round-trips required for many operations; we use an | |||
"expiration" mechanism for this purpose (see section 13.2). The | "expiration" mechanism for this purpose (see section 13.2). The | |||
latter reduces network bandwidth requirements; we use a "validation" | latter reduces network bandwidth requirements; we use a "validation" | |||
mechanism for this purpose (see section 13.3). | mechanism for this purpose (see section 13.3). | |||
Requirements for performance, availability, and disconnected | Requirements for performance, availability, and disconnected | |||
operation require us to be able to relax the goal of semantic | operation require us to be able to relax the goal of semantic | |||
transparency. The HTTP/1.1 protocol allows origin servers, caches, | transparency. The HTTP/1.1 protocol allows origin servers, caches, | |||
and clients to explicitly reduce transparency when necessary. | and clients to explicitly reduce transparency when necessary. | |||
However, because non-transparent operation may confuse non-expert | However, because non-transparent operation may confuse non-expert | |||
users, and might be incompatible with certain server applications | users, and might be incompatible with certain server applications | |||
(such as those for ordering merchandise), the protocol requires that | (such as those for ordering merchandise), the protocol requires that | |||
transparency be relaxed | transparency be relaxed | |||
- only by an explicit protocol-level request when relaxed by | o only by an explicit protocol-level request when relaxed by client | |||
client or origin server | or origin server | |||
- only with an explicit warning to the end user when relaxed by | o only with an explicit warning to the end user when relaxed by | |||
cache or client | cache or client | |||
Therefore, the HTTP/1.1 protocol provides these important elements: | Therefore, the HTTP/1.1 protocol provides these important elements: | |||
1. Protocol features that provide full semantic transparency when | 1. Protocol features that provide full semantic transparency when | |||
this is required by all parties. | this is required by all parties. | |||
2. Protocol features that allow an origin server or user agent to | 2. Protocol features that allow an origin server or user agent to | |||
explicitly request and control non-transparent operation. | explicitly request and control non-transparent operation. | |||
skipping to change at page 75, line 38 | skipping to change at page 84, line 13 | |||
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 | would have returned by revalidating the response with the origin | |||
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. | of the origin server alone. If a stored response is not "fresh | |||
enough" by the most restrictive freshness requirement of both the | ||||
If a stored response is not "fresh enough" by the most | client and the origin server, in carefully considered | |||
restrictive freshness requirement of both the client and the | circumstances the cache MAY still return the response with the | |||
origin server, in carefully considered circumstances the cache | appropriate Warning header (see section 13.1.5 and 14.46), unless | |||
MAY still return the response with the appropriate Warning | such a response is prohibited (e.g., by a "no-store" cache- | |||
header (see section 13.1.5 and 14.46), unless such a response | directive, or by a "no-cache" cache-request-directive; see | |||
is prohibited (e.g., by a "no-store" cache-directive, or by a | section 14.9). | |||
"no-cache" cache-request-directive; see section 14.9). | ||||
3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), | 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or | |||
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 | |||
cache SHOULD forward it to the requesting client without adding a new | cache SHOULD forward it to the requesting client without adding a new | |||
skipping to change at page 77, line 44 | skipping to change at page 86, line 17 | |||
practical or reasonable to display all of them to the user. This | practical or reasonable to display all of them to the user. This | |||
version of HTTP does not specify strict priority rules for deciding | version of HTTP does not specify strict priority rules for deciding | |||
which warnings to display and in what order, but does suggest some | which warnings to display and in what order, but does suggest some | |||
heuristics. | heuristics. | |||
13.1.3 Cache-control Mechanisms | 13.1.3 Cache-control Mechanisms | |||
The basic cache mechanisms in HTTP/1.1 (server-specified expiration | The basic cache mechanisms in HTTP/1.1 (server-specified expiration | |||
times and validators) are implicit directives to caches. In some | times and validators) are implicit directives to caches. In some | |||
cases, a server or client might need to provide explicit directives | cases, a server or client might need to provide explicit directives | |||
to the HTTP caches. We use the Cache-Control header for this purpose. | to the HTTP caches. We use the Cache-Control header for this | |||
purpose. | ||||
The Cache-Control header allows a client or server to transmit a | The Cache-Control header allows a client or server to transmit a | |||
variety of directives in either requests or responses. These | variety of directives in either requests or responses. These | |||
directives typically override the default caching algorithms. As a | directives typically override the default caching algorithms. As a | |||
general rule, if there is any apparent conflict between header | general rule, if there is any apparent conflict between header | |||
values, the most restrictive interpretation is applied (that is, the | values, the most restrictive interpretation is applied (that is, the | |||
one that is most likely to preserve semantic transparency). However, | one that is most likely to preserve semantic transparency). However, | |||
in some cases, cache-control directives are explicitly specified as | in some cases, cache-control directives are explicitly specified as | |||
weakening the approximation of semantic transparency (for example, | weakening the approximation of semantic transparency (for example, | |||
"max-stale" or "public"). | "max-stale" or "public"). | |||
skipping to change at page 78, line 25 | skipping to change at page 86, line 47 | |||
never validated. Or the user agent might habitually add "Cache- | never validated. Or the user agent might habitually add "Cache- | |||
Control: max-stale=3600" to every request. The user agent SHOULD NOT | Control: max-stale=3600" to every request. The user agent SHOULD NOT | |||
default to either non-transparent behavior, or behavior that results | default to either non-transparent behavior, or behavior that results | |||
in abnormally ineffective caching, but MAY be explicitly configured | in abnormally ineffective caching, but MAY be explicitly configured | |||
to do so by an explicit action of the user. | to do so by an explicit action of the user. | |||
If the user has overridden the basic caching mechanisms, the user | If the user has overridden the basic caching mechanisms, the user | |||
agent SHOULD explicitly indicate to the user whenever this results in | agent SHOULD explicitly indicate to the user whenever this results in | |||
the display of information that might not meet the server's | the display of information that might not meet the server's | |||
transparency requirements (in particular, if the displayed entity is | transparency requirements (in particular, if the displayed entity is | |||
known to be stale). Since the protocol normally allows the user agent | known to be stale). Since the protocol normally allows the user | |||
to determine if responses are stale or not, this indication need only | agent to determine if responses are stale or not, this indication | |||
be displayed when this actually happens. The indication need not be a | need only be displayed when this actually happens. The indication | |||
dialog box; it could be an icon (for example, a picture of a rotting | need not be a dialog box; it could be an icon (for example, a picture | |||
fish) or some other indicator. | of a rotting fish) or some other indicator. | |||
If the user has overridden the caching mechanisms in a way that would | If the user has overridden the caching mechanisms in a way that would | |||
abnormally reduce the effectiveness of caches, the user agent SHOULD | abnormally reduce the effectiveness of caches, the user agent SHOULD | |||
continually indicate this state to the user (for example, by a | continually indicate this state to the user (for example, by a | |||
display of a picture of currency in flames) so that the user does not | display of a picture of currency in flames) so that the user does not | |||
inadvertently consume excess resources or suffer from excessive | inadvertently consume excess resources or suffer from excessive | |||
latency. | latency. | |||
13.1.5 Exceptions to the Rules and Warnings | 13.1.5 Exceptions to the Rules and Warnings | |||
skipping to change at page 79, line 27 | skipping to change at page 87, line 45 | |||
directives of the Cache-Control header. | directives of the Cache-Control header. | |||
A client's request MAY specify the maximum age it is willing to | A client's request MAY specify the maximum age it is willing to | |||
accept of an unvalidated response; specifying a value of zero forces | accept of an unvalidated response; specifying a value of zero forces | |||
the cache(s) to revalidate all responses. A client MAY also specify | the cache(s) to revalidate all responses. A client MAY also specify | |||
the minimum time remaining before a response expires. Both of these | the minimum time remaining before a response expires. Both of these | |||
options increase constraints on the behavior of caches, and so cannot | options increase constraints on the behavior of caches, and so cannot | |||
further relax the cache's approximation of semantic transparency. | further relax the cache's approximation of semantic transparency. | |||
A client MAY also specify that it will accept stale responses, up to | A client MAY also specify that it will accept stale responses, up to | |||
some maximum amount of staleness. This loosens the constraints on the | some maximum amount of staleness. This loosens the constraints on | |||
caches, and so might violate the origin server's specified | the caches, and so might violate the origin server's specified | |||
constraints on semantic transparency, but might be necessary to | constraints on semantic transparency, but might be necessary to | |||
support disconnected operation, or high availability in the face of | support disconnected operation, or high availability in the face of | |||
poor connectivity. | poor connectivity. | |||
13.2 Expiration Model | 13.2 Expiration Model | |||
13.2.1 Server-Specified Expiration | 13.2.1 Server-Specified Expiration | |||
HTTP caching works best when caches can entirely avoid making | HTTP caching works best when caches can entirely avoid making | |||
requests to the origin server. The primary mechanism for avoiding | requests to the origin server. The primary mechanism for avoiding | |||
skipping to change at page 80, line 11 | skipping to change at page 88, line 29 | |||
expiration time is reached. This normally preserves semantic | expiration time is reached. This normally preserves semantic | |||
transparency, as long as the server's expiration times are carefully | transparency, as long as the server's expiration times are carefully | |||
chosen. | chosen. | |||
The expiration mechanism applies only to responses taken from a cache | The expiration mechanism applies only to responses taken from a cache | |||
and not to first-hand responses forwarded immediately to the | and not to first-hand responses forwarded immediately to the | |||
requesting client. | requesting client. | |||
If an origin server wishes to force a semantically transparent cache | If an origin server wishes to force a semantically transparent cache | |||
to validate every request, it MAY assign an explicit expiration time | to validate every request, it MAY assign an explicit expiration time | |||
in the past. This means that the response is always stale, and so the | in the past. This means that the response is always stale, and so | |||
cache SHOULD validate it before using it for subsequent requests. See | the cache SHOULD validate it before using it for subsequent requests. | |||
section 14.9.4 for a more restrictive way to force revalidation. | See section 14.9.4 for a more restrictive way to force revalidation. | |||
If an origin server wishes to force any HTTP/1.1 cache, no matter how | If an origin server wishes to force any HTTP/1.1 cache, no matter how | |||
it is configured, to validate every request, it SHOULD use the "must- | it is configured, to validate every request, it SHOULD use the "must- | |||
revalidate" cache-control directive (see section 14.9). | revalidate" cache-control directive (see section 14.9). | |||
Servers specify explicit expiration times using either the Expires | Servers specify explicit expiration times using either the Expires | |||
header, or the max-age directive of the Cache-Control header. | header, or the max-age directive of the Cache-Control header. | |||
An expiration time cannot be used to force a user agent to refresh | An expiration time cannot be used to force a user agent to refresh | |||
its display or reload a resource; its semantics apply only to caching | its display or reload a resource; its semantics apply only to caching | |||
skipping to change at page 81, line 7 | skipping to change at page 89, line 25 | |||
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 [28] or some similar protocol to synchronize their clocks to | |||
a globally accurate time standard. | 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 denote | generated (see section 14.18). We use the term "date_value" to | |||
the value of the Date header, in a form appropriate for arithmetic | denote the value of the Date header, in a form appropriate for | |||
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 | |||
generated or revalidated by the origin server. | generated or revalidated by the origin server. | |||
In essence, the Age value is the sum of the time that the response | In essence, the Age value is the sum of the time that the response | |||
has been resident in each of the caches along the path from the | has been resident in each of the caches along the path from the | |||
origin server, plus the amount of time it has been in transit along | origin server, plus the amount of time it has been in transit along | |||
network paths. | network paths. | |||
We use the term "age_value" to denote the value of the Age header, in | We use the term "age_value" to denote the value of the Age header, in | |||
a form appropriate for arithmetic operations. | a form appropriate for arithmetic operations. | |||
A response's age can be calculated in two entirely independent ways: | A response's age can be calculated in two entirely independent ways: | |||
1. now minus date_value, if the local clock is reasonably well | 1. now minus date_value, if the local clock is reasonably well | |||
synchronized to the origin server's clock. If the result is | synchronized to the origin server's clock. If the result is | |||
negative, the result is replaced by zero. | negative, the result is replaced by zero. | |||
2. age_value, if all of the caches along the response path | 2. age_value, if all of the caches along the response path implement | |||
implement HTTP/1.1. | HTTP/1.1. | |||
Given that we have two independent ways to compute the age of a | Given that we have two independent ways to compute the age of a | |||
response when it is received, we can combine these as | response when it is received, we can combine these as | |||
corrected_received_age = max(now - date_value, age_value) | corrected_received_age = max(now - date_value, age_value) | |||
and as long as we have either nearly synchronized clocks or all- | and as long as we have either nearly synchronized clocks or all- | |||
HTTP/1.1 paths, one gets a reliable (conservative) result. | HTTP/1.1 paths, one gets a reliable (conservative) result. | |||
Because of network-imposed delays, some significant interval might | Because of network-imposed delays, some significant interval might | |||
pass between the time that a server generates a response and the time | pass between the time that a server generates a response and the time | |||
it is received at the next outbound cache or client. If uncorrected, | it is received at the next outbound cache or client. If uncorrected, | |||
this delay could result in improperly low ages. | this delay could result in improperly low ages. | |||
Because the request that resulted in the returned Age value must have | Because the request that resulted in the returned Age value must have | |||
been initiated prior to that Age value's generation, we can correct | been initiated prior to that Age value's generation, we can correct | |||
for delays imposed by the network by recording the time at which the | for delays imposed by the network by recording the time at which the | |||
request was initiated. Then, when an Age value is received, it MUST | request was initiated. Then, when an Age value is received, it MUST | |||
be interpreted relative to the time the request was initiated, not | be interpreted relative to the time the request was initiated, not | |||
the time that the response was received. This algorithm results in | the time that the response was received. This algorithm results in | |||
conservative behavior no matter how much delay is experienced. So, we | conservative behavior no matter how much delay is experienced. So, | |||
compute: | we compute: | |||
corrected_initial_age = corrected_received_age | corrected_initial_age = corrected_received_age | |||
+ (now - request_time) | + (now - request_time) | |||
where "request_time" is the time (according to the local clock) when | where "request_time" is the time (according to the local clock) when | |||
the request that elicited this response was sent. | the request that elicited this response was sent. | |||
Summary of age calculation algorithm, when a cache receives a | Summary of age calculation algorithm, when a cache receives a | |||
response: | response: | |||
skipping to change at page 83, line 34 | skipping to change at page 92, line 19 | |||
freshness_lifetime = max_age_value | freshness_lifetime = max_age_value | |||
Otherwise, if Expires is present in the response, the calculation is: | Otherwise, if Expires is present in the response, the calculation is: | |||
freshness_lifetime = expires_value - date_value | freshness_lifetime = expires_value - date_value | |||
Note that neither of these calculations is vulnerable to clock skew, | Note that neither of these calculations is vulnerable to clock skew, | |||
since all of the information comes from the origin server. | since all of the information comes from the origin server. | |||
If none of Expires, Cache-Control: max-age, or Cache-Control: s- | If none of Expires, Cache-Control: max-age, or Cache-Control: | |||
maxage (see section 14.9.3) appears in the response, and the response | s-maxage (see section 14.9.3) appears in the response, and the | |||
does not include other restrictions on caching, the cache MAY compute | response does not include other restrictions on caching, the cache | |||
a freshness lifetime using a heuristic. The cache MUST attach Warning | MAY compute a freshness lifetime using a heuristic. The cache MUST | |||
113 to any response whose age is more than 24 hours if such warning | attach Warning 113 to any response whose age is more than 24 hours if | |||
has not already been added. | such warning has not already been added. | |||
Also, if the response does have a Last-Modified time, the heuristic | Also, if the response does have a Last-Modified time, the heuristic | |||
expiration value SHOULD be no more than some fraction of the interval | expiration value SHOULD be no more than some fraction of the interval | |||
since that time. A typical setting of this fraction might be 10%. | since that time. A typical setting of this fraction might be 10%. | |||
The calculation to determine if a response has expired is quite | The calculation to determine if a response has expired is quite | |||
simple: | simple: | |||
response_is_fresh = (freshness_lifetime > current_age) | response_is_fresh = (freshness_lifetime > current_age) | |||
skipping to change at page 84, line 36 | skipping to change at page 93, line 18 | |||
Because a client might be receiving responses via multiple paths, so | Because a client might be receiving responses via multiple paths, so | |||
that some responses flow through one set of caches and other | that some responses flow through one set of caches and other | |||
responses flow through a different set of caches, a client might | responses flow through a different set of caches, a client might | |||
receive responses in an order different from that in which the origin | receive responses in an order different from that in which the origin | |||
server sent them. We would like the client to use the most recently | server sent them. We would like the client to use the most recently | |||
generated response, even if older responses are still apparently | generated response, even if older responses are still apparently | |||
fresh. | fresh. | |||
Neither the entity tag nor the expiration value can impose an | Neither the entity tag nor the expiration value can impose an | |||
ordering on responses, since it is possible that a later response | ordering on responses, since it is possible that a later response | |||
intentionally carries an earlier expiration time. The Date values are | intentionally carries an earlier expiration time. The Date values | |||
ordered to a granularity of one second. | are ordered to a granularity of one second. | |||
When a client tries to revalidate a cache entry, and the response it | When a client tries to revalidate a cache entry, and the response it | |||
receives contains a Date header that appears to be older than the one | receives contains a Date header that appears to be older than the one | |||
for the existing entry, then the client SHOULD repeat the request | for the existing entry, then the client SHOULD repeat the request | |||
unconditionally, and include | unconditionally, and include | |||
Cache-Control: max-age=0 | Cache-Control: max-age=0 | |||
to force any intermediate caches to validate their copies directly | to force any intermediate caches to validate their copies directly | |||
with the origin server, or | with the origin server, or | |||
skipping to change at page 85, line 45 | skipping to change at page 94, line 28 | |||
entity-body). Thus, we avoid transmitting the full response if the | entity-body). Thus, we avoid transmitting the full response if the | |||
validator matches, and we avoid an extra round trip if it does not | validator matches, and we avoid an extra round trip if it does not | |||
match. | match. | |||
In HTTP/1.1, a conditional request looks exactly the same as a normal | In HTTP/1.1, a conditional request looks exactly the same as a normal | |||
request for the same resource, except that it carries a special | request for the same resource, except that it carries a special | |||
header (which includes the validator) that implicitly turns the | header (which includes the validator) that implicitly turns the | |||
method (usually, GET) into a conditional. | method (usually, GET) into a conditional. | |||
The protocol includes both positive and negative senses of cache- | The protocol includes both positive and negative senses of cache- | |||
validating conditions. That is, it is possible to request either that | validating conditions. That is, it is possible to request either | |||
a method be performed if and only if a validator matches or if and | that a method be performed if and only if a validator matches or if | |||
only if no validators match. | and only if no validators match. | |||
Note: a response that lacks a validator may still be cached, and | Note: a response that lacks a validator may still be cached, and | |||
served from cache until it expires, unless this is explicitly | served from cache until it expires, unless this is explicitly | |||
prohibited by a cache-control directive. However, a cache cannot | prohibited by a cache-control directive. However, a cache cannot | |||
do a conditional retrieval if it does not have a validator for the | do a conditional retrieval if it does not have a validator for the | |||
entity, which means it will not be refreshable after it expires. | entity, which means it will not be refreshable after it expires. | |||
13.3.1 Last-Modified Dates | 13.3.1 Last-Modified Dates | |||
The Last-Modified entity-header field value is often used as a cache | The Last-Modified entity-header field value is often used as a cache | |||
skipping to change at page 86, line 40 | skipping to change at page 95, line 19 | |||
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." | |||
However, there might be cases when a server prefers to change the | However, there might be cases when a server prefers to change the | |||
validator only on semantically significant changes, and not when | validator only on semantically significant changes, and not when | |||
insignificant aspects of the entity change. A validator that does not | insignificant aspects of the entity change. A validator that does | |||
always change when the resource changes is a "weak validator." | not always change when the resource changes is a "weak validator." | |||
Entity tags are normally "strong validators," but the protocol | Entity tags are normally "strong validators," but the protocol | |||
provides a mechanism to tag an entity tag as "weak." One can think of | provides a mechanism to tag an entity tag as "weak." One can think | |||
a strong validator as one that changes whenever the bits of an entity | of a strong validator as one that changes whenever the bits of an | |||
changes, while a weak value changes whenever the meaning of an entity | entity changes, while a weak value changes whenever the meaning of an | |||
changes. Alternatively, one can think of a strong validator as part | entity changes. Alternatively, one can think of a strong validator | |||
of an identifier for a specific entity, while a weak validator is | as part of an identifier for a specific entity, while a weak | |||
part of an identifier for a set of semantically equivalent entities. | validator is part of an identifier for a set of semantically | |||
equivalent entities. | ||||
Note: One example of a strong validator is an integer that is | Note: One example of a strong validator is an integer that is | |||
incremented in stable storage every time an entity is changed. | incremented in stable storage every time an entity is changed. | |||
An entity's modification time, if represented with one-second | An entity's modification time, if represented with one-second | |||
resolution, could be a weak validator, since it is possible that | resolution, could be a weak validator, since it is possible that | |||
the resource might be modified twice during a single second. | the resource might be modified twice during a single second. | |||
Support for weak validators is optional. However, weak validators | Support for weak validators is optional. However, weak validators | |||
allow for more efficient caching of equivalent objects; for | allow for more efficient caching of equivalent objects; for | |||
example, a hit counter on a site is probably good enough if it is | example, a hit counter on a site is probably good enough if it is | |||
updated every few days or weeks, and any value during that period | updated every few days or weeks, and any value during that period | |||
is likely "good enough" to be equivalent. | is likely "good enough" to be equivalent. | |||
A "use" of a validator is either when a client generates a request | A "use" of a validator is either when a client generates a request | |||
and includes the validator in a validating header field, or when a | and includes the validator in a validating header field, or when a | |||
server compares two validators. | server compares two validators. | |||
Strong validators are usable in any context. Weak validators are only | Strong validators are usable in any context. Weak validators are | |||
usable in contexts that do not depend on exact equality of an entity. | only usable in contexts that do not depend on exact equality of an | |||
For example, either kind is usable for a conditional GET of a full | entity. For example, either kind is usable for a conditional GET of | |||
entity. However, only a strong validator is usable for a sub-range | a full entity. However, only a strong validator is usable for a sub- | |||
retrieval, since otherwise the client might end up with an internally | range retrieval, since otherwise the client might end up with an | |||
inconsistent entity. | internally inconsistent entity. | |||
Clients MAY issue simple (non-subrange) GET requests with either weak | Clients MAY issue simple (non-subrange) GET requests with either weak | |||
validators or strong validators. Clients MUST NOT use weak validators | validators or strong validators. Clients MUST NOT use weak | |||
in other forms of request. | validators in other forms of request. | |||
The only function that the HTTP/1.1 protocol defines on validators is | The only function that the HTTP/1.1 protocol defines on validators is | |||
comparison. There are two validator comparison functions, depending | comparison. There are two validator comparison functions, depending | |||
on whether the comparison context allows the use of weak validators | on whether the comparison context allows the use of weak validators | |||
or not: | or not: | |||
- 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 | both validators MUST be identical in every way, and both MUST NOT | |||
NOT be weak. | be weak. | |||
- 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 validators MUST be identical in every way, but either or both | |||
both of them MAY be tagged as "weak" without affecting the | of them MAY be tagged as "weak" without affecting the result. | |||
result. | ||||
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: | |||
- The validator is being compared by an origin server to the | o The validator is being compared by an origin server to the actual | |||
actual current validator for the entity and, | current validator for the entity and, | |||
- That origin server reliably knows that the associated entity did | ||||
o That origin server reliably knows that the associated entity did | ||||
not change twice during the second covered by the presented | not change twice during the second covered by the presented | |||
validator. | validator. | |||
or | or | |||
- The validator is about to be used by a client in an If- | o The validator is about to be used by a client in an If-Modified- | |||
Modified-Since or If-Unmodified-Since header, because the client | Since or If-Unmodified-Since header, because the client has a | |||
has a cache entry for the associated entity, and | cache entry for the associated entity, and | |||
- That cache entry includes a Date value, which gives the time | o That cache entry includes a Date value, which gives the time when | |||
when the origin server sent the original response, and | the origin server sent the original response, and | |||
- The presented Last-Modified time is at least 60 seconds before | o The presented Last-Modified time is at least 60 seconds before the | |||
the Date value. | Date value. | |||
or | or | |||
o The validator is being compared by an intermediate cache to the | ||||
- The validator is being compared by an intermediate cache to the | ||||
validator stored in its cache entry for the entity, and | validator stored in its cache entry for the entity, and | |||
- That cache entry includes a Date value, which gives the time | o That cache entry includes a Date value, which gives the time when | |||
when the origin server sent the original response, and | the origin server sent the original response, and | |||
- The presented Last-Modified time is at least 60 seconds before | o The presented Last-Modified time is at least 60 seconds before the | |||
the Date value. | Date value. | |||
This method relies on the fact that if two different responses were | This method relies on the fact that if two different responses were | |||
sent by the origin server during the same second, but both had the | sent by the origin server during the same second, but both had the | |||
same Last-Modified time, then at least one of those responses would | same Last-Modified time, then at least one of those responses would | |||
have a Date value equal to its Last-Modified time. The arbitrary 60- | have a Date value equal to its Last-Modified time. The arbitrary 60- | |||
second limit guards against the possibility that the Date and Last- | second limit guards against the possibility that the Date and Last- | |||
Modified values are generated from different clocks, or at somewhat | Modified values are generated from different clocks, or at somewhat | |||
different times during the preparation of the response. An | different times during the preparation of the response. An | |||
implementation MAY use a value larger than 60 seconds, if it is | implementation MAY use a value larger than 60 seconds, if it is | |||
believed that 60 seconds is too short. | believed that 60 seconds is too short. | |||
skipping to change at page 89, line 14 | skipping to change at page 97, line 44 | |||
servers. | servers. | |||
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates | 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates | |||
We adopt a set of rules and recommendations for origin servers, | We adopt a set of rules and recommendations for origin servers, | |||
clients, and caches regarding when various validator types ought to | clients, and caches regarding when various validator types ought to | |||
be used, and for what purposes. | be used, and for what purposes. | |||
HTTP/1.1 origin servers: | HTTP/1.1 origin servers: | |||
- SHOULD send an entity tag validator unless it is not feasible to | o SHOULD send an entity tag validator unless it is not feasible to | |||
generate one. | generate one. | |||
- MAY send a weak entity tag instead of a strong entity tag, if | o MAY send a weak entity tag instead of a strong entity tag, if | |||
performance considerations support the use of weak entity tags, | performance considerations support the use of weak entity tags, or | |||
or if it is unfeasible to send a strong entity tag. | if it is unfeasible to send a strong entity tag. | |||
- SHOULD send a Last-Modified value if it is feasible to send one, | o SHOULD send a Last-Modified value if it is feasible to send one, | |||
unless the risk of a breakdown in semantic transparency that | unless the risk of a breakdown in semantic transparency that could | |||
could result from using this date in an If-Modified-Since header | result from using this date in an If-Modified-Since header would | |||
would lead to serious problems. | lead to serious problems. | |||
In other words, the preferred behavior for an HTTP/1.1 origin server | In other words, the preferred behavior for an HTTP/1.1 origin server | |||
is to send both a strong entity tag and a Last-Modified value. | is to send both a strong entity tag and a Last-Modified value. | |||
In order to be legal, a strong entity tag MUST change whenever the | In order to be legal, a strong entity tag MUST change whenever the | |||
associated entity value changes in any way. A weak entity tag SHOULD | associated entity value changes in any way. A weak entity tag SHOULD | |||
change whenever the associated entity changes in a semantically | change whenever the associated entity changes in a semantically | |||
significant way. | significant way. | |||
Note: in order to provide semantically transparent caching, an | Note: in order to provide semantically transparent caching, an | |||
origin server must avoid reusing a specific strong entity tag | origin server must avoid reusing a specific strong entity tag | |||
value for two different entities, or reusing a specific weak | value for two different entities, or reusing a specific weak | |||
entity tag value for two semantically different entities. Cache | entity tag value for two semantically different entities. Cache | |||
entries might persist for arbitrarily long periods, regardless of | entries might persist for arbitrarily long periods, regardless of | |||
expiration times, so it might be inappropriate to expect that a | expiration times, so it might be inappropriate to expect that a | |||
cache will never again attempt to validate an entry using a | cache will never again attempt to validate an entry using a | |||
validator that it obtained at some point in the past. | validator that it obtained at some point in the past. | |||
HTTP/1.1 clients: | HTTP/1.1 clients: | |||
- If an entity tag has been provided by the origin server, MUST | o If an entity tag has been provided by the origin server, MUST use | |||
use that entity tag in any cache-conditional request (using If- | that entity tag in any cache-conditional request (using If-Match | |||
Match or If-None-Match). | or If-None-Match). | |||
- If only a Last-Modified value has been provided by the origin | o If only a Last-Modified value has been provided by the origin | |||
server, SHOULD use that value in non-subrange cache-conditional | server, SHOULD use that value in non-subrange cache-conditional | |||
requests (using If-Modified-Since). | requests (using If-Modified-Since). | |||
- If only a Last-Modified value has been provided by an HTTP/1.0 | o If only a Last-Modified value has been provided by an HTTP/1.0 | |||
origin server, MAY use that value in subrange cache-conditional | origin server, MAY use that value in subrange cache-conditional | |||
requests (using If-Unmodified-Since:). The user agent SHOULD | requests (using If-Unmodified-Since:). The user agent SHOULD | |||
provide a way to disable this, in case of difficulty. | provide a way to disable this, in case of difficulty. | |||
- If both an entity tag and a Last-Modified value have been | o If both an entity tag and a Last-Modified value have been provided | |||
provided by the origin server, SHOULD use both validators in | by the origin server, SHOULD use both validators in cache- | |||
cache-conditional requests. This allows both HTTP/1.0 and | conditional requests. This allows both HTTP/1.0 and HTTP/1.1 | |||
HTTP/1.1 caches to respond appropriately. | caches to respond appropriately. | |||
An HTTP/1.1 origin server, upon receiving a conditional request that | An HTTP/1.1 origin server, upon receiving a conditional request that | |||
includes both a Last-Modified date (e.g., in an If-Modified-Since or | includes both a Last-Modified date (e.g., in an If-Modified-Since or | |||
If-Unmodified-Since header field) and one or more entity tags (e.g., | If-Unmodified-Since header field) and one or more entity tags (e.g., | |||
in an If-Match, If-None-Match, or If-Range header field) as cache | in an If-Match, If-None-Match, or If-Range header field) as cache | |||
validators, MUST NOT return a response status of 304 (Not Modified) | validators, MUST NOT return a response status of 304 (Not Modified) | |||
unless doing so is consistent with all of the conditional header | unless doing so is consistent with all of the conditional header | |||
fields in the request. | fields in the request. | |||
An HTTP/1.1 caching proxy, upon receiving a conditional request that | An HTTP/1.1 caching proxy, upon receiving a conditional request that | |||
skipping to change at page 91, line 14 | skipping to change at page 99, line 45 | |||
13.4 Response Cacheability | 13.4 Response Cacheability | |||
Unless specifically constrained by a cache-control (section 14.9) | Unless specifically constrained by a cache-control (section 14.9) | |||
directive, a caching system MAY always store a successful response | directive, a caching system MAY always store a successful response | |||
(see section 13.8) as a cache entry, MAY return it without validation | (see section 13.8) as a cache entry, MAY return it without validation | |||
if it is fresh, and MAY return it after successful validation. If | if it is fresh, and MAY return it after successful validation. If | |||
there is neither a cache validator nor an explicit expiration time | there is neither a cache validator nor an explicit expiration time | |||
associated with a response, we do not expect it to be cached, but | associated with a response, we do not expect it to be cached, but | |||
certain caches MAY violate this expectation (for example, when little | certain caches MAY violate this expectation (for example, when little | |||
or no network connectivity is available). A client can usually detect | or no network connectivity is available). A client can usually | |||
that such a response was taken from a cache by comparing the Date | detect that such a response was taken from a cache by comparing the | |||
header to the current time. | Date header to the current time. | |||
Note: some HTTP/1.0 caches are known to violate this expectation | Note: some HTTP/1.0 caches are known to violate this expectation | |||
without providing any Warning. | without providing any Warning. | |||
However, in some cases it might be inappropriate for a cache to | However, in some cases it might be inappropriate for a cache to | |||
retain an entity, or to return it in response to a subsequent | retain an entity, or to return it in response to a subsequent | |||
request. This might be because absolute semantic transparency is | request. This might be because absolute semantic transparency is | |||
deemed necessary by the service author, or because of security or | deemed necessary by the service author, or because of security or | |||
privacy considerations. Certain cache-control directives are | privacy considerations. Certain cache-control directives are | |||
therefore provided so that the server can indicate that certain | therefore provided so that the server can indicate that certain | |||
skipping to change at page 92, line 19 | skipping to change at page 100, line 47 | |||
many cases, a cache simply returns the appropriate parts of a | many cases, a cache simply returns the appropriate parts of a | |||
response to the requester. However, if the cache holds a cache entry | response to the requester. However, if the cache holds a cache entry | |||
based on a previous response, it might have to combine parts of a new | based on a previous response, it might have to combine parts of a new | |||
response with what is held in the cache entry. | response with what is held in the cache entry. | |||
13.5.1 End-to-end and Hop-by-hop Headers | 13.5.1 End-to-end and Hop-by-hop Headers | |||
For the purpose of defining the behavior of caches and non-caching | For the purpose of defining the behavior of caches and non-caching | |||
proxies, we divide HTTP headers into two categories: | proxies, we divide HTTP headers into two categories: | |||
- End-to-end headers, which are transmitted to the ultimate | o End-to-end headers, which are transmitted to the ultimate | |||
recipient of a request or response. End-to-end headers in | recipient of a request or response. End-to-end headers in | |||
responses MUST be stored as part of a cache entry and MUST be | responses MUST be stored as part of a cache entry and MUST be | |||
transmitted in any response formed from a cache entry. | transmitted in any response formed from a cache entry. | |||
- Hop-by-hop headers, which are meaningful only for a single | o Hop-by-hop headers, which are meaningful only for a single | |||
transport-level connection, and are not stored by caches or | transport-level connection, and are not stored by caches or | |||
forwarded by proxies. | forwarded by proxies. | |||
The following HTTP/1.1 headers are hop-by-hop headers: | The following HTTP/1.1 headers are hop-by-hop headers: | |||
- Connection | o Connection | |||
- Keep-Alive | ||||
- Proxy-Authenticate | o Keep-Alive | |||
- Proxy-Authorization | ||||
- TE | o Proxy-Authenticate | |||
- Trailers | ||||
- Transfer-Encoding | o Proxy-Authorization | |||
- Upgrade | ||||
o TE | ||||
o Trailers | ||||
o Transfer-Encoding | ||||
o Upgrade | ||||
All other headers defined by HTTP/1.1 are end-to-end headers. | All other headers defined by HTTP/1.1 are end-to-end headers. | |||
Other hop-by-hop headers MUST be listed in a Connection header, | Other hop-by-hop headers MUST be listed in a Connection header, | |||
(section 14.10) to be introduced into HTTP/1.1 (or later). | (section 14.10) to be introduced into HTTP/1.1 (or later). | |||
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 | |||
already present: | already present: | |||
- Content-Location | o Content-Location | |||
- Content-MD5 | o Content-MD5 | |||
- ETag | o ETag | |||
- Last-Modified | o Last-Modified | |||
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 | |||
response: | response: | |||
- Expires | o Expires | |||
but it MAY add any of these fields if not already present. If an | but it MAY add any of these fields if not already present. If an | |||
Expires header is added, it MUST be given a field-value identical to | Expires header is added, it MUST be given a field-value identical to | |||
that of the Date header in that response. | that of the Date header in that response. | |||
A proxy MUST NOT modify or add any of the following fields in a | A proxy MUST NOT modify or add any of the following fields in a | |||
message that contains the no-transform cache-control directive, or in | message that contains the no-transform cache-control directive, or in | |||
any request: | any request: | |||
- Content-Encoding | o Content-Encoding | |||
- Content-Range | o Content-Range | |||
- Content-Type | o Content-Type | |||
A non-transparent proxy MAY modify or add these fields to a message | A non-transparent proxy MAY modify or add these fields to a message | |||
that does not include no-transform, but if it does so, it MUST add a | that does not include no-transform, but if it does so, it MUST add a | |||
Warning 214 (Transformation applied) if one does not already appear | Warning 214 (Transformation applied) if one does not already appear | |||
in the message (see section 14.46). | in the message (see section 14.46). | |||
Warning: unnecessary modification of end-to-end headers might | Warning: unnecessary modification of end-to-end headers might | |||
cause authentication failures if stronger authentication | cause authentication failures if stronger authentication | |||
mechanisms are introduced in later versions of HTTP. Such | mechanisms are introduced in later versions of HTTP. Such | |||
authentication mechanisms MAY rely on the values of header fields | authentication mechanisms MAY rely on the values of header fields | |||
not listed here. | not listed here. | |||
The Content-Length field of a request or response is added or deleted | The Content-Length field of a request or response is added or deleted | |||
according to the rules in section 4.4. A transparent proxy MUST | according to the rules in section 4.4. A transparent proxy MUST | |||
preserve the entity-length (section 7.2.2) of the entity-body, | preserve the entity-length (section 7.2.2) of the entity-body, | |||
although it MAY change the transfer-length (section 4.4). | although it MAY change the transfer-length (section section 4.4). | |||
13.5.3 Combining Headers | 13.5.3 Combining Headers | |||
When a cache makes a validating request to a server, and the server | When a cache makes a validating request to a server, and the server | |||
provides a 304 (Not Modified) response or a 206 (Partial Content) | provides a 304 (Not Modified) response or a 206 (Partial Content) | |||
response, the cache then constructs a response to send to the | response, the cache then constructs a response to send to the | |||
requesting client. | requesting client. | |||
If the status code is 304 (Not Modified), the cache uses the entity- | If the status code is 304 (Not Modified), the cache uses the entity- | |||
body stored in the cache entry as the entity-body of this outgoing | body stored in the cache entry as the entity-body of this outgoing | |||
response. If the status code is 206 (Partial Content) and the ETag or | response. If the status code is 206 (Partial Content) and the ETag | |||
Last-Modified headers match exactly, the cache MAY combine the | or Last-Modified headers match exactly, the cache MAY combine the | |||
contents stored in the cache entry with the new contents received in | contents stored in the cache entry with the new contents received in | |||
the response and use the result as the entity-body of this outgoing | the response and use the result as the entity-body of this outgoing | |||
response, (see 13.5.4). | response, (see 13.5.4). | |||
The end-to-end headers stored in the cache entry are used for the | The end-to-end headers stored in the cache entry are used for the | |||
constructed response, except that | constructed response, except that | |||
- any stored Warning headers with warn-code 1xx (see section | o any stored Warning headers with warn-code 1xx (see section 14.46) | |||
14.46) MUST be deleted from the cache entry and the forwarded | MUST be deleted from the cache entry and the forwarded response. | |||
response. | ||||
- any stored Warning headers with warn-code 2xx MUST be retained | o any stored Warning headers with warn-code 2xx MUST be retained in | |||
in the cache entry and the forwarded response. | the cache entry and the forwarded response. | |||
- any end-to-end headers provided in the 304 or 206 response MUST | o any end-to-end headers provided in the 304 or 206 response MUST | |||
replace the corresponding headers from the cache entry. | replace the corresponding headers from the cache entry. | |||
Unless the cache decides to remove the cache entry, it MUST also | Unless the cache decides to remove the cache entry, it MUST also | |||
replace the end-to-end headers stored with the cache entry with | replace the end-to-end headers stored with the cache entry with | |||
corresponding headers received in the incoming response, except for | corresponding headers received in the incoming response, except for | |||
Warning headers as described immediately above. If a header field- | Warning headers as described immediately above. If a header field- | |||
name in the incoming response matches more than one header in the | name in the incoming response matches more than one header in the | |||
cache entry, all such old headers MUST be replaced. | cache entry, all such old headers MUST be replaced. | |||
In other words, the set of end-to-end headers received in the | In other words, the set of end-to-end headers received in the | |||
incoming response overrides all corresponding end-to-end headers | incoming response overrides all corresponding end-to-end headers | |||
stored with the cache entry (except for stored Warning headers with | stored with the cache entry (except for stored Warning headers with | |||
warn-code 1xx, which are deleted even if not overridden). | warn-code 1xx, which are deleted even if not overridden). | |||
Note: this rule allows an origin server to use a 304 (Not | Note: this rule allows an origin server to use a 304 (Not | |||
Modified) or a 206 (Partial Content) response to update any header | Modified) or a 206 (Partial Content) response to update any header | |||
associated with a previous response for the same entity or sub- | associated with a previous response for the same entity or sub- | |||
ranges thereof, although it might not always be meaningful or | ranges thereof, although it might not always be meaningful or | |||
correct to do so. This rule does not allow an origin server to use | correct to do so. This rule does not allow an origin server to | |||
a 304 (Not Modified) or a 206 (Partial Content) response to | use a 304 (Not Modified) or a 206 (Partial Content) response to | |||
entirely delete a header that it had provided with a previous | entirely delete a header that it had provided with a previous | |||
response. | response. | |||
13.5.4 Combining Byte Ranges | 13.5.4 Combining Byte Ranges | |||
A response might transfer only a subrange of the bytes of an entity- | A response might transfer only a subrange of the bytes of an entity- | |||
body, either because the request included one or more Range | body, either because the request included one or more Range | |||
specifications, or because a connection was broken prematurely. After | specifications, or because a connection was broken prematurely. | |||
several such transfers, a cache might have received several ranges of | After several such transfers, a cache might have received several | |||
the same entity-body. | ranges of the same entity-body. | |||
If a cache has a stored non-empty set of subranges for an entity, and | If a cache has a stored non-empty set of subranges for an entity, and | |||
an incoming response transfers another subrange, the cache MAY | an incoming response transfers another subrange, the cache MAY | |||
combine the new subrange with the existing set if both the following | combine the new subrange with the existing set if both the following | |||
conditions are met: | conditions are met: | |||
- Both the incoming response and the cache entry have a cache | o Both the incoming response and the cache entry have a cache | |||
validator. | validator. | |||
- The two cache validators match using the strong comparison | o The two cache validators match using the strong comparison | |||
function (see section 13.3.3). | function (see section 13.3.3). | |||
If either requirement is not met, the cache MUST use only the most | If either requirement is not met, the cache MUST use only the most | |||
recent partial response (based on the Date values transmitted with | recent partial response (based on the Date values transmitted with | |||
every response, and using the incoming response if these values are | every response, and using the incoming response if these values are | |||
equal or missing), and MUST discard the other partial information. | equal or missing), and MUST discard the other partial information. | |||
13.6 Caching Negotiated Responses | 13.6 Caching Negotiated Responses | |||
Use of server-driven content negotiation (section 12.1), as indicated | Use of server-driven content negotiation (section 12.1), as indicated | |||
skipping to change at page 96, line 38 | skipping to change at page 105, line 23 | |||
entry, the new response SHOULD be used to update the header fields of | entry, the new response SHOULD be used to update the header fields of | |||
the existing entry, and the result MUST be returned to the client. | the existing entry, and the result MUST be returned to the client. | |||
If any of the existing cache entries contains only partial content | If any of the existing cache entries contains only partial content | |||
for the associated entity, its entity-tag SHOULD NOT be included in | for the associated entity, its entity-tag SHOULD NOT be included in | |||
the If-None-Match header field unless the request is for a range that | the If-None-Match header field unless the request is for a range that | |||
would be fully satisfied by that entry. | would be fully satisfied by that entry. | |||
If a cache receives a successful response whose Content-Location | If a cache receives a successful response whose Content-Location | |||
field matches that of an existing cache entry for the same Request- | field matches that of an existing cache entry for the same Request- | |||
]URI, whose entity-tag differs from that of the existing entry, and | URI, whose entity-tag differs from that of the existing entry, and | |||
whose Date is more recent than that of the existing entry, the | whose Date is more recent than that of the existing entry, the | |||
existing entry SHOULD NOT be returned in response to future requests | existing entry SHOULD NOT be returned in response to future requests | |||
and SHOULD be deleted from the cache. | and SHOULD be deleted from the cache. | |||
13.7 Shared and Non-Shared Caches | 13.7 Shared and Non-Shared Caches | |||
For reasons of security and privacy, it is necessary to make a | For reasons of security and privacy, it is necessary to make a | |||
distinction between "shared" and "non-shared" caches. A non-shared | distinction between "shared" and "non-shared" caches. A non-shared | |||
cache is one that is accessible only to a single user. Accessibility | cache is one that is accessible only to a single user. Accessibility | |||
in this case SHOULD be enforced by appropriate security mechanisms. | in this case SHOULD be enforced by appropriate security mechanisms. | |||
All other caches are considered to be "shared." Other sections of | All other caches are considered to be "shared." Other sections of | |||
this specification place certain constraints on the operation of | this specification place certain constraints on the operation of | |||
shared caches in order to prevent loss of privacy or failure of | shared caches in order to prevent loss of privacy or failure of | |||
access controls. | access controls. | |||
13.8 Errors or Incomplete Response Cache Behavior | 13.8 Errors or Incomplete Response Cache Behavior | |||
A cache that receives an incomplete response (for example, with fewer | A cache that receives an incomplete response (for example, with fewer | |||
bytes of data than specified in a Content-Length header) MAY store | bytes of data than specified in a Content-Length header) MAY store | |||
the response. However, the cache MUST treat this as a partial | the response. However, the cache MUST treat this as a partial | |||
response. Partial responses MAY be combined as described in section | response. Partial responses MAY be combined as described in | |||
13.5.4; the result might be a full response or might still be | section 13.5.4; the result might be a full response or might still be | |||
partial. A cache MUST NOT return a partial response to a client | partial. A cache MUST NOT return a partial response to a client | |||
without explicitly marking it as such, using the 206 (Partial | without explicitly marking it as such, using the 206 (Partial | |||
Content) status code. A cache MUST NOT return a partial response | Content) status code. A cache MUST NOT return a partial response | |||
using a status code of 200 (OK). | using a status code of 200 (OK). | |||
If a cache receives a 5xx response while attempting to revalidate an | If a cache receives a 5xx response while attempting to revalidate an | |||
entry, it MAY either forward this response to the requesting client, | entry, it MAY either forward this response to the requesting client, | |||
or act as if the server failed to respond. In the latter case, it MAY | or act as if the server failed to respond. In the latter case, it | |||
return a previously received response unless the cached entry | MAY return a previously received response unless the cached entry | |||
includes the "must-revalidate" cache-control directive (see section | includes the "must-revalidate" cache-control directive (see | |||
14.9). | section 14.9). | |||
13.9 Side Effects of GET and HEAD | 13.9 Side Effects of GET and HEAD | |||
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. | |||
skipping to change at page 98, line 17 | skipping to change at page 106, line 47 | |||
caused the change at the origin server might not have gone through | caused the change at the origin server might not have gone through | |||
the proxy where a cache entry is stored. However, several rules help | the proxy where a cache entry is stored. However, several rules help | |||
reduce the likelihood of erroneous behavior. | reduce the likelihood of erroneous behavior. | |||
In this section, the phrase "invalidate an entity" means that the | In this section, the phrase "invalidate an entity" means that the | |||
cache will either remove all instances of that entity from its | cache will either remove all instances of that entity from its | |||
storage, or will mark these as "invalid" and in need of a mandatory | storage, or will mark these as "invalid" and in need of a mandatory | |||
revalidation before they can be returned in response to a subsequent | revalidation before they can be returned in response to a subsequent | |||
request. | request. | |||
Some HTTP methods MUST cause a cache to invalidate an entity. This is | Some HTTP methods MUST cause a cache to invalidate an entity. This | |||
either the entity referred to by the Request-URI, or by the Location | is either the entity referred to by the Request-URI, or by the | |||
or Content-Location headers (if present). These methods are: | Location or Content-Location headers (if present). These methods | |||
are: | ||||
- PUT | o PUT | |||
- DELETE | o DELETE | |||
- POST | o POST | |||
In order to prevent denial of service attacks, an invalidation based | In order to prevent denial of service attacks, an invalidation based | |||
on the URI in a Location or Content-Location header MUST only be | on the URI in a Location or Content-Location header MUST only be | |||
performed if the host part is the same as in the Request-URI. | performed if the host part is the same as in the Request-URI. | |||
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 | understand SHOULD invalidate any entities referred to by the Request- | |||
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. | |||
A cache MUST NOT reply to such a request from a client before having | A cache MUST NOT reply to such a request from a client before having | |||
transmitted the request to the inbound server, and having received a | transmitted the request to the inbound server, and having received a | |||
corresponding response from the inbound server. This does not prevent | corresponding response from the inbound server. This does not | |||
a proxy cache from sending a 100 (Continue) response before the | prevent a proxy cache from sending a 100 (Continue) response before | |||
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 | |||
skipping to change at page 99, line 27 | skipping to change at page 108, line 13 | |||
existing cached responses is not cacheable. | existing cached responses is not cacheable. | |||
13.13 History Lists | 13.13 History Lists | |||
User agents often have history mechanisms, such as "Back" buttons and | User agents often have history mechanisms, such as "Back" buttons and | |||
history lists, which can be used to redisplay an entity retrieved | history lists, which can be used to redisplay an entity retrieved | |||
earlier in a session. | earlier in a session. | |||
History mechanisms and caches are different. In particular history | History mechanisms and caches are different. In particular history | |||
mechanisms SHOULD NOT try to show a semantically transparent view of | mechanisms SHOULD NOT try to show a semantically transparent view of | |||
the current state of a resource. Rather, a history mechanism is meant | the current state of a resource. Rather, a history mechanism is | |||
to show exactly what the user saw at the time when the resource was | meant to show exactly what the user saw at the time when the resource | |||
retrieved. | was retrieved. | |||
By default, an expiration time does not apply to history mechanisms. | By default, an expiration time does not apply to history mechanisms. | |||
If the entity is still in storage, a history mechanism SHOULD display | If the entity is still in storage, a history mechanism SHOULD display | |||
it even if the entity has expired, unless the user has specifically | it even if the entity has expired, unless the user has specifically | |||
configured the agent to refresh expired history documents. | configured the agent to refresh expired history documents. | |||
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 | |||
skipping to change at page 101, line 6 | skipping to change at page 110, line 4 | |||
Note: Use of the "q" parameter name to separate media type | Note: Use of the "q" parameter name to separate media type | |||
parameters from Accept extension parameters is due to historical | parameters from Accept extension parameters is due to historical | |||
practice. Although this prevents any media type parameter named | practice. Although this prevents any media type parameter named | |||
"q" from being used with a media range, such an event is believed | "q" from being used with a media range, such an event is believed | |||
to be unlikely given the lack of any "q" parameters in the IANA | to be unlikely given the lack of any "q" parameters in the IANA | |||
media type registry and the rare usage of any media type | media type registry and the rare usage of any media type | |||
parameters in Accept. Future media types are discouraged from | parameters in Accept. Future media types are discouraged from | |||
registering any parameter named "q". | registering any parameter named "q". | |||
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 present, | client accepts all media types. If an Accept header field is | |||
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." | |||
Media ranges can be overridden by more specific media ranges or | Media ranges can be overridden by more specific media ranges or | |||
specific media types. If more than one media range applies to a given | specific media types. If more than one media range applies to a | |||
type, the most specific reference has precedence. For example, | given type, the most specific reference has precedence. For example, | |||
Accept: text/*, text/html, text/html;level=1, */* | Accept: text/*, text/html, text/html;level=1, */* | |||
have the following precedence: | have the following precedence: | |||
1) text/html;level=1 | 1) text/html;level=1 | |||
2) text/html | 2) text/html | |||
3) text/* | 3) text/* | |||
4) */* | 4) */* | |||
skipping to change at page 102, line 9 | skipping to change at page 111, line 7 | |||
would cause the following values to be associated: | would cause the following values to be associated: | |||
text/html;level=1 = 1 | text/html;level=1 = 1 | |||
text/html = 0.7 | text/html = 0.7 | |||
text/plain = 0.3 | text/plain = 0.3 | |||
image/jpeg = 0.5 | image/jpeg = 0.5 | |||
text/html;level=2 = 0.4 | text/html;level=2 = 0.4 | |||
text/html;level=3 = 0.7 | text/html;level=3 = 0.7 | |||
Note: A user agent might be provided with a default set of quality | Note: A user agent might be provided with a default set of quality | |||
values for certain media ranges. However, unless the user agent is | values for certain media ranges. However, unless the user agent is a | |||
a closed system which cannot interact with other rendering agents, | closed system which cannot interact with other rendering agents, this | |||
this 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 is | preference for that charset. The default value is q=1. An example | |||
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 present | mentioned elsewhere in the Accept-Charset field. If no "*" is | |||
in an Accept-Charset field, then all character sets not explicitly | present in an Accept-Charset field, then all character sets not | |||
mentioned get a quality value of 0, except for ISO-8859-1, which gets | explicitly mentioned get a quality value of 0, except for ISO-8859-1, | |||
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 | |||
skipping to change at page 103, line 18 | skipping to change at page 112, line 15 | |||
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 | |||
an Accept-Encoding field, using these rules: | an Accept-Encoding field, using these rules: | |||
1. If the content-coding is one of the content-codings listed in | 1. If the content-coding is one of the content-codings listed in the | |||
the Accept-Encoding field, then it is acceptable, unless it is | Accept-Encoding field, then it is acceptable, unless it is | |||
accompanied by a qvalue of 0. (As defined in section 3.9, a | accompanied by a qvalue of 0. (As defined in section 3.9, a | |||
qvalue of 0 means "not acceptable.") | qvalue of 0 means "not acceptable.") | |||
2. The special "*" symbol in an Accept-Encoding field matches any | 2. The special "*" symbol in an Accept-Encoding field matches any | |||
available content-coding not explicitly listed in the header | available content-coding not explicitly listed in the header | |||
field. | field. | |||
3. If multiple content-codings are acceptable, then the acceptable | 3. If multiple content-codings are acceptable, then the acceptable | |||
content-coding with the highest non-zero qvalue is preferred. | content-coding with the highest non-zero qvalue is preferred. | |||
skipping to change at page 103, line 50 | skipping to change at page 112, line 47 | |||
with the 406 (Not Acceptable) status code. | with the 406 (Not Acceptable) status code. | |||
If no Accept-Encoding field is present in a request, the server MAY | If no Accept-Encoding field is present in a request, the server MAY | |||
assume that the client will accept any content coding. In this case, | assume that the client will accept any content coding. In this case, | |||
if "identity" is one of the available content-codings, then the | if "identity" is one of the available content-codings, then the | |||
server SHOULD use the "identity" content-coding, unless it has | server SHOULD use the "identity" content-coding, unless it has | |||
additional information that a different content-coding is meaningful | additional information that a different content-coding is meaningful | |||
to the client. | to the client. | |||
Note: If the request does not include an Accept-Encoding field, | Note: If the request does not include an Accept-Encoding field, | |||
and if the "identity" content-coding is unavailable, then | and if the "identity" content-coding is unavailable, then content- | |||
content-codings commonly understood by HTTP/1.0 clients (i.e., | codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and | |||
"gzip" and "compress") are preferred; some older clients | "compress") are preferred; some older clients improperly display | |||
improperly display messages sent with other content-codings. The | messages sent with other content-codings. The server might also | |||
server might also make this decision based on information about | make this decision based on information about the particular user- | |||
the particular user-agent or client. | agent or client. | |||
Note: Most HTTP/1.0 applications do not recognize or obey qvalues | Note: Most HTTP/1.0 applications do not recognize or obey qvalues | |||
associated with content-codings. This means that qvalues will not | associated with content-codings. This means that qvalues will not | |||
work and are not permitted with x-gzip or x-compress. | work and are not permitted with x-gzip or x-compress. | |||
14.4 Accept-Language | 14.4 Accept-Language | |||
The Accept-Language request-header field is similar to Accept, but | The Accept-Language request-header field is similar to Accept, but | |||
restricts the set of natural languages that are preferred as a | restricts the set of natural languages that are preferred as a | |||
response to the request. Language tags are defined in section 3.10. | response to the request. Language tags are defined in section | |||
section 3.10. | ||||
Accept-Language = "Accept-Language" ":" | Accept-Language = "Accept-Language" ":" | |||
1#( language-range [ ";" "q" "=" qvalue ] ) | 1#( language-range [ ";" "q" "=" qvalue ] ) | |||
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) | |||
Each language-range MAY be given an associated quality value which | Each language-range MAY be given an associated quality value which | |||
represents an estimate of the user's preference for the languages | represents an estimate of the user's preference for the languages | |||
specified by that range. The quality value defaults to "q=1". For | specified by that range. The quality value defaults to "q=1". For | |||
example, | example, | |||
skipping to change at page 104, line 45 | skipping to change at page 113, line 43 | |||
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 | The language quality factor assigned to a language-tag by the Accept- | |||
Accept-Language field is the quality value of the longest language- | Language field is the quality value of the longest language-range in | |||
range in the field that matches the language-tag. If no language- | the field that matches the language-tag. If no language-range in the | |||
range in the field matches the tag, the language quality factor | field matches the tag, the language quality factor assigned is 0. If | |||
assigned is 0. If no Accept-Language header is present in the | no Accept-Language header is present in the request, the server | |||
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. | |||
As intelligibility is highly dependent on the individual user, it is | As intelligibility is highly dependent on the individual user, it is | |||
skipping to change at page 105, line 30 | skipping to change at page 114, line 27 | |||
the user, we remind implementors of the fact that users are not | the user, we remind implementors of the fact that users are not | |||
familiar with the details of language matching as described above, | familiar with the details of language matching as described above, | |||
and should provide appropriate guidance. As an example, users | and should provide appropriate guidance. As an example, users | |||
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 | The Accept-Ranges response-header field allows the server to indicate | |||
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 | Servers that do not accept any kind of range request for a resource | |||
resource MAY send | MAY send | |||
Accept-Ranges: none | Accept-Ranges: none | |||
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 | amount of time since the response (or its revalidation) was generated | |||
generated at the origin server. A cached response is "fresh" if | at the origin server. A cached response is "fresh" if its age does | |||
its age does not exceed its freshness lifetime. Age values are | not exceed its freshness lifetime. Age values are calculated as | |||
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 | If a cache receives a value larger than the largest positive integer | |||
integer it can represent, or if any of its age calculations | it can represent, or if any of its age calculations overflows, it | |||
overflows, it MUST transmit an Age header with a value of | MUST transmit an Age header with a value of 2147483648 (2^31). An | |||
2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST | HTTP/1.1 server that includes a cache MUST include an Age header | |||
include an Age header field in every response generated from its | field in every response generated from its own cache. Caches SHOULD | |||
own cache. Caches SHOULD use an arithmetic type of at least 31 | use an arithmetic type of at least 31 bits of range. | |||
bits of range. | ||||
14.7 Allow | 14.7 Allow | |||
The Allow entity-header field lists the set of methods supported | The Allow entity-header field lists the set of methods supported by | |||
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 | field is strictly to inform the recipient of valid methods associated | |||
associated with the resource. An Allow header field MUST be | with the resource. An Allow header field MUST be present in a 405 | |||
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 | However, the indications given by the Allow header field value SHOULD | |||
SHOULD be followed. The actual set of allowed methods is defined | be followed. The actual set of allowed methods is defined by the | |||
by the origin server at the time of each request. | origin server at the time of each request. | |||
The Allow header field MAY be provided with a PUT request to | The Allow header field MAY be provided with a PUT request to | |||
recommend the methods to be supported by the new or modified | recommend the methods to be supported by the new or modified | |||
resource. The server is not required to support these methods and | resource. The server is not required to support these methods and | |||
SHOULD include an Allow header in the response giving the actual | SHOULD include an Allow header in the response giving the actual | |||
supported methods. | supported methods. | |||
A proxy MUST NOT modify the Allow header field even if it does not | A proxy MUST NOT modify the Allow header field even if it does not | |||
understand all the methods specified, since the user agent might | understand all the methods specified, since the user agent might have | |||
have other means of communicating with the origin server. | other means of communicating with the origin server. | |||
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 | usually, but not necessarily, after receiving a 401 response--does so | |||
so by including an Authorization request-header field with the | by including an Authorization request-header field with the request. | |||
request. The Authorization field value consists of credentials | The Authorization field value consists of credentials containing the | |||
containing the authentication information of the user agent for | authentication information of the user agent for the realm of the | |||
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" [43]. If a request is | |||
authenticated and a realm specified, the same credentials SHOULD | authenticated and a realm specified, the same credentials SHOULD be | |||
be valid for all other requests within this realm (assuming that | valid for all other requests within this realm (assuming that the | |||
the authentication scheme itself does not require otherwise, such | authentication scheme itself does not require otherwise, such as | |||
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 | When a shared cache (see section 13.7) receives a request containing | |||
containing an Authorization field, it MUST NOT return the | an Authorization field, it MUST NOT return the corresponding response | |||
corresponding response as a reply to any other request, unless one | as a reply to any other request, unless one of the following specific | |||
of the following specific exceptions holds: | exceptions holds: | |||
1. If the response includes the "s-maxage" cache-control | 1. If the response includes the "s-maxage" cache-control directive, | |||
directive, the cache MAY use that response in replying to a | the cache MAY use that response in replying to a subsequent | |||
subsequent request. But (if the specified maximum age has | request. But (if the specified maximum age has passed) a proxy | |||
passed) a proxy cache MUST first revalidate it with the origin | cache MUST first revalidate it with the origin server, using the | |||
server, using the request-headers from the new request to allow | request-headers from the new request to allow the origin server | |||
the origin server to authenticate the new request. (This is the | to authenticate the new request. (This is the defined behavior | |||
defined behavior for s-maxage.) If the response includes "s- | for s-maxage.) If the response includes "s-maxage=0", the proxy | |||
maxage=0", the proxy MUST always revalidate it before re-using | MUST always revalidate it before re-using it. | |||
it. | ||||
2. If the response includes the "must-revalidate" cache-control | 2. If the response includes the "must-revalidate" cache-control | |||
directive, the cache MAY use that response in replying to a | directive, the cache MAY use that response in replying to a | |||
subsequent request. But if the response is stale, all caches | subsequent request. But if the response is stale, all caches | |||
MUST first revalidate it with the origin server, using the | MUST first revalidate it with the origin server, using the | |||
request-headers from the new request to allow the origin server | request-headers from the new request to allow the origin server | |||
to authenticate the new request. | to authenticate the new request. | |||
3. If the response includes the "public" cache-control directive, | 3. If the response includes the "public" cache-control directive, it | |||
it MAY be returned in reply to any subsequent request. | MAY be returned in reply to any subsequent request. | |||
14.9 Cache-Control | 14.9 Cache-Control | |||
The Cache-Control general-header field is used to specify directives | The Cache-Control general-header field is used to specify directives | |||
that MUST be obeyed by all caching mechanisms along the | that MUST be obeyed by all caching mechanisms along the request/ | |||
request/response chain. The directives specify behavior intended to | response chain. The directives specify behavior intended to prevent | |||
prevent caches from adversely interfering with the request or | caches from adversely interfering with the request or response. | |||
response. These directives typically override the default caching | These directives typically override the default caching algorithms. | |||
algorithms. Cache directives are unidirectional in that the presence | Cache directives are unidirectional in that the presence of a | |||
of a directive in a request does not imply that the same directive is | directive in a request does not imply that the same directive is to | |||
to be given in the response. | be given in the response. | |||
Note that HTTP/1.0 caches might not implement Cache-Control and | Note that HTTP/1.0 caches might not implement Cache-Control and | |||
might only implement Pragma: no-cache (see section 14.32). | might only implement Pragma: no-cache (see section 14.32). | |||
Cache directives MUST be passed through by a proxy or gateway | Cache directives MUST be passed through by a proxy or gateway | |||
application, regardless of their significance to that application, | application, regardless of their significance to that application, | |||
since the directives might be applicable to all recipients along the | since the directives might be applicable to all recipients along the | |||
request/response chain. It is not possible to specify a cache- | request/response chain. It is not possible to specify a cache- | |||
directive for a specific cache. | directive for a specific cache. | |||
skipping to change at page 109, line 15 | skipping to change at page 118, line 11 | |||
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. | |||
The cache-control directives can be broken down into these general | The cache-control directives can be broken down into these general | |||
categories: | categories: | |||
- Restrictions on what are cacheable; these may only be imposed by | o Restrictions on what are cacheable; these may only be imposed by | |||
the origin server. | the origin server. | |||
- Restrictions on what may be stored by a cache; these may be | o Restrictions on what may be stored by a cache; these may be | |||
imposed by either the origin server or the user agent. | imposed by either the origin server or the user agent. | |||
- Modifications of the basic expiration mechanism; these may be | o Modifications of the basic expiration mechanism; these may be | |||
imposed by either the origin server or the user agent. | imposed by either the origin server or the user agent. | |||
- Controls over cache revalidation and reload; these may only be | o Controls over cache revalidation and reload; these may only be | |||
imposed by a user agent. | imposed by a user agent. | |||
- Control over transformation of entities. | o Control over transformation of entities. | |||
- Extensions to the caching system. | o Extensions to the caching system. | |||
14.9.1 What is Cacheable | 14.9.1 What is Cacheable | |||
By default, a response is cacheable if the requirements of the | By default, a response is cacheable if the requirements of the | |||
request method, request header fields, and the response status | request method, request header fields, and the response status | |||
indicate that it is cacheable. Section 13.4 summarizes these defaults | indicate that it is cacheable. section 13.4 summarizes these defaults | |||
for cacheability. The following Cache-Control response directives | for cacheability. The following Cache-Control response directives | |||
allow an origin server to override the default cacheability of a | allow an origin server to override the default cacheability of a | |||
response: | response: | |||
public | public | |||
Indicates that the response MAY be cached by any cache, even if it | Indicates that the response MAY be cached by any cache, even if it | |||
would normally be non-cacheable or cacheable only within a non- | would normally be non-cacheable or cacheable only within a non- | |||
shared cache. (See also Authorization, section 14.8, for | shared cache. (See also Authorization, section 14.8, for | |||
additional details.) | additional details.) | |||
private | private | |||
Indicates that all or part of the response message is intended for | Indicates that all or part of the response message is intended for | |||
a single user and MUST NOT be cached by a shared cache. This | a single user and MUST NOT be cached by a shared cache. This | |||
allows an origin server to state that the specified parts of the | allows an origin server to state that the specified parts of the | |||
response are intended for only one user and are not a valid | response are intended for only one user and are not a valid | |||
response for requests by other users. A private (non-shared) cache | response for requests by other users. A private (non-shared) | |||
MAY cache the response. | cache MAY cache the response. | |||
Note: This usage of the word private only controls where the | Note: This usage of the word private only controls where the | |||
response may be cached, and cannot ensure the privacy of the | response may be cached, and cannot ensure the privacy of the | |||
message content. | message content. | |||
no-cache | no-cache | |||
If the no-cache directive does not specify a field-name, then a | If the no-cache directive does not specify a field-name, then a | |||
cache MUST NOT use the response to satisfy a subsequent request | cache MUST NOT use the response to satisfy a subsequent request | |||
without successful revalidation with the origin server. This | without successful revalidation with the origin server. This | |||
allows an origin server to prevent caching even by caches that | allows an origin server to prevent caching even by caches that | |||
have been configured to return stale responses to client requests. | have been configured to return stale responses to client requests. | |||
If the no-cache directive does specify one or more field-names, | If the no-cache directive does specify one or more field-names, | |||
then a cache MAY use the response to satisfy a subsequent request, | then a cache MAY use the response to satisfy a subsequent request, | |||
subject to any other restrictions on caching. However, the | subject to any other restrictions on caching. However, the | |||
specified field-name(s) MUST NOT be sent in the response to a | specified field-name(s) MUST NOT be sent in the response to a | |||
skipping to change at page 111, line 29 | skipping to change at page 120, line 29 | |||
it MAY be specified using the max-age directive in a response. When | it MAY be specified using the max-age directive in a response. When | |||
the max-age cache-control directive is present in a cached response, | the max-age cache-control directive is present in a cached response, | |||
the response is stale if its current age is greater than the age | the response is stale if its current age is greater than the age | |||
value given (in seconds) at the time of a new request for that | value given (in seconds) at the time of a new request for that | |||
resource. The max-age directive on a response implies that the | resource. The max-age directive on a response implies that the | |||
response is cacheable (i.e., "public") unless some other, more | response is cacheable (i.e., "public") unless some other, more | |||
restrictive cache directive is also present. | restrictive cache directive is also present. | |||
If a response includes both an Expires header and a max-age | If a response includes both an Expires header and a max-age | |||
directive, the max-age directive overrides the Expires header, even | directive, the max-age directive overrides the Expires header, even | |||
if the Expires header is more restrictive. This rule allows an origin | if the Expires header is more restrictive. This rule allows an | |||
server to provide, for a given response, a longer expiration time to | origin server to provide, for a given response, a longer expiration | |||
an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be | time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This | |||
useful if certain HTTP/1.0 caches improperly calculate ages or | might be useful if certain HTTP/1.0 caches improperly calculate ages | |||
expiration times, perhaps due to desynchronized clocks. | or expiration times, perhaps due to desynchronized clocks. | |||
Many HTTP/1.0 cache implementations will treat an Expires value that | Many HTTP/1.0 cache implementations will treat an Expires value that | |||
is less than or equal to the response Date value as being equivalent | is less than or equal to the response Date value as being equivalent | |||
to the Cache-Control response directive "no-cache". If an HTTP/1.1 | to the Cache-Control response directive "no-cache". If an HTTP/1.1 | |||
cache receives such a response, and the response does not include a | cache receives such a response, and the response does not include a | |||
Cache-Control header field, it SHOULD consider the response to be | Cache-Control header field, it SHOULD consider the response to be | |||
non-cacheable in order to retain compatibility with HTTP/1.0 servers. | non-cacheable in order to retain compatibility with HTTP/1.0 servers. | |||
Note: An origin server might wish to use a relatively new HTTP | Note: An origin server might wish to use a relatively new HTTP | |||
cache control feature, such as the "private" directive, on a | cache control feature, such as the "private" directive, on a | |||
skipping to change at page 112, line 13 | skipping to change at page 121, line 11 | |||
caching the response. | caching the response. | |||
s-maxage | s-maxage | |||
If a response includes an s-maxage directive, then for a shared | If a response includes an s-maxage directive, then for a shared | |||
cache (but not for a private cache), the maximum age specified by | cache (but not for a private cache), the maximum age specified by | |||
this directive overrides the maximum age specified by either the | this directive overrides the maximum age specified by either the | |||
max-age directive or the Expires header. The s-maxage directive | max-age directive or the Expires header. The s-maxage directive | |||
also implies the semantics of the proxy-revalidate directive (see | also implies the semantics of the proxy-revalidate directive (see | |||
section 14.9.4), i.e., that the shared cache must not use the | section 14.9.4), i.e., that the shared cache must not use the | |||
entry after it becomes stale to respond to a subsequent request | entry after it becomes stale to respond to a subsequent request | |||
without first revalidating it with the origin server. The s- | without first revalidating it with the origin server. The | |||
maxage directive is always ignored by a private cache. | s-maxage directive is always ignored by a private cache. | |||
Note that most older caches, not compliant with this specification, | Note that most older caches, not compliant with this specification, | |||
do not implement any cache-control directives. An origin server | do not implement any cache-control directives. An origin server | |||
wishing to use a cache-control directive that restricts, but does not | wishing to use a cache-control directive that restricts, but does not | |||
prevent, caching by an HTTP/1.1-compliant cache MAY exploit the | prevent, caching by an HTTP/1.1-compliant cache MAY exploit the | |||
requirement that the max-age directive overrides the Expires header, | requirement that the max-age directive overrides the Expires header, | |||
and the fact that pre-HTTP/1.1-compliant caches do not observe the | and the fact that pre-HTTP/1.1-compliant caches do not observe the | |||
max-age directive. | max-age directive. | |||
Other directives allow a user agent to modify the basic expiration | Other directives allow a user agent to modify the basic expiration | |||
skipping to change at page 114, line 20 | skipping to change at page 123, line 25 | |||
directive, to revalidate its own cache entry, and the client has | directive, to revalidate its own cache entry, and the client has | |||
supplied its own validator in the request, the supplied validator | supplied its own validator in the request, the supplied validator | |||
might differ from the validator currently stored with the cache | might differ from the validator currently stored with the cache | |||
entry. In this case, the cache MAY use either validator in making | entry. In this case, the cache MAY use either validator in making | |||
its own request without affecting semantic transparency. | its own request without affecting semantic transparency. | |||
However, the choice of validator might affect performance. The | However, the choice of validator might affect performance. The | |||
best approach is for the intermediate cache to use its own | best approach is for the intermediate cache to use its own | |||
validator when making its request. If the server replies with 304 | validator when making its request. If the server replies with 304 | |||
(Not Modified), then the cache can return its now validated copy | (Not Modified), then the cache can return its now validated copy | |||
to the client with a 200 (OK) response. If the server replies with | to the client with a 200 (OK) response. If the server replies | |||
a new entity and cache validator, however, the intermediate cache | with a new entity and cache validator, however, the intermediate | |||
can compare the returned validator with the one provided in the | cache can compare the returned validator with the one provided in | |||
client's request, using the strong comparison function. If the | the client's request, using the strong comparison function. If | |||
client's validator is equal to the origin server's, then the | the client's validator is equal to the origin server's, then the | |||
intermediate cache simply returns 304 (Not Modified). Otherwise, | intermediate cache simply returns 304 (Not Modified). Otherwise, | |||
it returns the new entity with a 200 (OK) response. | it returns the new entity with a 200 (OK) response. | |||
If a request includes the no-cache directive, it SHOULD NOT | If a request includes the no-cache directive, it SHOULD NOT | |||
include min-fresh, max-stale, or max-age. | include min-fresh, max-stale, or max-age. | |||
only-if-cached | only-if-cached | |||
In some cases, such as times of extremely poor network | In some cases, such as times of extremely poor network | |||
connectivity, a client may want a cache to return only those | connectivity, a client may want a cache to return only those | |||
responses that it currently has stored, and not to reload or | responses that it currently has stored, and not to reload or | |||
revalidate with the origin server. To do this, the client may | revalidate with the origin server. To do this, the client may | |||
include the only-if-cached directive in a request. If it receives | include the only-if-cached directive in a request. If it receives | |||
this directive, a cache SHOULD either respond using a cached entry | this directive, a cache SHOULD either respond using a cached entry | |||
that is consistent with the other constraints of the request, or | that is consistent with the other constraints of the request, or | |||
respond with a 504 (Gateway Timeout) status. However, if a group | respond with a 504 (Gateway Timeout) status. However, if a group | |||
of caches is being operated as a unified system with good internal | of caches is being operated as a unified system with good internal | |||
connectivity, such a request MAY be forwarded within that group of | connectivity, such a request MAY be forwarded within that group of | |||
skipping to change at page 117, line 31 | skipping to change at page 126, line 42 | |||
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. | |||
Message headers listed in the Connection header MUST NOT include | Message headers listed in the Connection header MUST NOT include end- | |||
end-to-end headers, such as Cache-Control. | to-end headers, such as Cache-Control. | |||
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 | HTTP/1.1 applications that do not support persistent connections MUST | |||
include the "close" connection option in every message. | include the "close" connection option in every message. | |||
A system receiving an HTTP/1.0 (or lower-version) message that | A system receiving an HTTP/1.0 (or lower-version) message that | |||
includes a Connection header MUST, for each connection-token in this | includes a Connection header MUST, for each connection-token in this | |||
field, remove and ignore any header field(s) from the message with | field, remove and ignore any header field(s) from the message with | |||
the same name as the connection-token. This protects against mistaken | the same name as the connection-token. This protects against | |||
forwarding of such header fields by pre-HTTP/1.1 proxies. See section | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. | |||
19.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 content | media-type. When present, its value indicates what additional | |||
codings have been applied to the entity-body, and thus what decoding | content codings have been applied to the entity-body, and thus what | |||
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 (section | response MUST include a Content-Encoding entity-header | |||
14.11) that lists the non-identity content-coding(s) used. | (section 14.11) that lists the non-identity content-coding(s) used. | |||
If the content-coding of an entity in a request message is not | If the content-coding of an entity in a request message is not | |||
acceptable to the origin server, the server SHOULD respond with a | acceptable to the origin server, the server SHOULD respond with a | |||
status code of 415 (Unsupported Media Type). | status code of 415 (Unsupported Media Type). | |||
If multiple encodings have been applied to an entity, the content | If multiple encodings have been applied to an entity, the content | |||
codings MUST be listed in the order in which they were applied. | codings MUST be listed in the order in which they were applied. | |||
Additional information about the encoding parameters MAY be provided | Additional information about the encoding parameters MAY be provided | |||
by other entity-header fields not defined by this specification. | by other entity-header fields not defined by this specification. | |||
skipping to change at page 119, line 4 | skipping to change at page 128, line 13 | |||
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 the | entities according to the user's own preferred language. Thus, if | |||
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 | |||
is intended for all language audiences. This might mean that the | is intended for all language audiences. This might mean that the | |||
sender does not consider it to be specific to any natural language, | sender does not consider it to be specific to any natural language, | |||
or that the sender does not know for which language it is intended. | or that the sender does not know for which language it is intended. | |||
Multiple languages MAY be listed for content that is intended for | Multiple languages MAY be listed for content that is intended for | |||
multiple audiences. For example, a rendition of the "Treaty of | multiple audiences. For example, a rendition of the "Treaty of | |||
Waitangi," presented simultaneously in the original Maori and English | Waitangi," presented simultaneously in the original Maori and English | |||
versions, would call for | versions, would call for | |||
Content-Language: mi, en | Content-Language: mi, en | |||
However, just because multiple languages are present within an entity | However, just because multiple languages are present within an entity | |||
does not mean that it is intended for multiple linguistic audiences. | does not mean that it is intended for multiple linguistic audiences. | |||
An example would be a beginner's language primer, such as "A First | An example would be a beginner's language primer, such as "A First | |||
Lesson in Latin," which is clearly intended to be used by an | Lesson in Latin," which is clearly intended to be used by an English- | |||
English-literate audience. In this case, the Content-Language would | literate audience. In this case, the Content-Language would properly | |||
properly only include "en". | only include "en". | |||
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. | |||
skipping to change at page 119, line 42 | skipping to change at page 129, line 4 | |||
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 section | the message-body, unless this is prohibited by the rules in | |||
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. | |||
Section 4.4 describes how to determine the length of a message-body | section 4.4 describes how to determine the length of a message-body | |||
if a Content-Length is not given. | if a Content-Length is not given. | |||
Note that the meaning of this field is significantly different from | Note that the meaning of this field is significantly different from | |||
the corresponding definition in MIME, where it is an optional field | the corresponding definition in MIME, where it is an optional field | |||
used within the "message/external-body" content-type. In HTTP, it | used within the "message/external-body" content-type. In HTTP, it | |||
SHOULD be sent whenever the message's length can be determined prior | SHOULD be sent whenever the message's length can be determined prior | |||
to being transferred, unless this is prohibited by the rules in | to being transferred, unless this is prohibited by the rules in | |||
section 4.4. | section 4.4. | |||
14.14 Content-Location | 14.14 Content-Location | |||
skipping to change at page 120, line 45 | skipping to change at page 130, line 4 | |||
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. | |||
A cache cannot assume that an entity with a Content-Location | A cache cannot assume that an entity with a Content-Location | |||
different from the URI used to retrieve it can be used to respond to | different from the URI used to retrieve it can be used to respond to | |||
later requests on that Content-Location URI. However, the Content- | later requests on that Content-Location URI. However, the Content- | |||
Location can be used to differentiate between multiple entities | Location can be used to differentiate between multiple entities | |||
retrieved from a single requested resource, as described in section | retrieved from a single requested resource, as described in | |||
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 RFC 1864 [23], is | |||
an MD5 digest of the entity-body for the purpose of providing an | an MD5 digest of the entity-body for the purpose of providing an end- | |||
end-to-end message integrity check (MIC) of the entity-body. (Note: a | to-end message integrity check (MIC) of the entity-body. (Note: a | |||
MIC is good for detecting accidental modification of the entity-body | MIC is good for detecting accidental modification of the entity-body | |||
in transit, but is not proof against malicious attacks.) | in 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 RFC 1864> | |||
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 | |||
skipping to change at page 121, line 39 | skipping to change at page 130, line 47 | |||
This has the result that the digest is computed on the octets of the | This has the result that the digest is computed on the octets of the | |||
entity-body exactly as, and in the order that, they would be sent if | entity-body exactly as, and in the order that, they would be sent if | |||
no transfer-encoding were being applied. | no transfer-encoding were being applied. | |||
HTTP extends RFC 1864 to permit the digest to be computed for MIME | HTTP extends RFC 1864 to permit the digest to be computed for MIME | |||
composite media-types (e.g., multipart/* and message/rfc822), but | composite media-types (e.g., multipart/* and message/rfc822), but | |||
this does not change how the digest is computed as defined in the | this does not change how the digest is computed as defined in the | |||
preceding paragraph. | preceding paragraph. | |||
There are several consequences of this. The entity-body for composite | There are several consequences of this. The entity-body for | |||
types MAY contain many body-parts, each with its own MIME and HTTP | composite types MAY contain many body-parts, each with its own MIME | |||
headers (including Content-MD5, Content-Transfer-Encoding, and | and HTTP headers (including Content-MD5, Content-Transfer-Encoding, | |||
Content-Encoding headers). If a body-part has a Content-Transfer- | and Content-Encoding headers). If a body-part has a Content- | |||
Encoding or Content-Encoding header, it is assumed that the content | Transfer-Encoding or Content-Encoding header, it is assumed that the | |||
of the body-part has had the encoding applied, and the body-part is | content of the body-part has had the encoding applied, and the body- | |||
included in the Content-MD5 digest as is -- i.e., after the | part is included in the Content-MD5 digest as is -- i.e., after the | |||
application. The Transfer-Encoding header field is not allowed within | application. The Transfer-Encoding header field is not allowed | |||
body-parts. | within body-parts. | |||
Conversion of all line breaks to CRLF MUST NOT be done before | Conversion of all line breaks to CRLF MUST NOT be done before | |||
computing or checking the digest: the line break convention used in | computing or checking the digest: the line break convention used in | |||
the text actually transmitted MUST be left unaltered when computing | the text actually transmitted MUST be left unaltered when computing | |||
the digest. | the digest. | |||
Note: while the definition of Content-MD5 is exactly the same for | Note: while the definition of Content-MD5 is exactly the same for | |||
HTTP as in RFC 1864 for MIME entity-bodies, there are several ways | HTTP as in RFC 1864 for MIME entity-bodies, there are several ways | |||
in which the application of Content-MD5 to HTTP entity-bodies | in which the application of Content-MD5 to HTTP entity-bodies | |||
differs from its application to MIME entity-bodies. One is that | differs from its application to MIME entity-bodies. One is that | |||
skipping to change at page 122, line 35 | skipping to change at page 131, line 44 | |||
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 asterisk | unless this length is unknown or difficult to determine. The | |||
"*" character means that the instance-length is unknown at the time | asterisk "*" character means that the instance-length is unknown at | |||
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. | |||
A byte-content-range-spec with a byte-range-resp-spec whose last- | A byte-content-range-spec with a byte-range-resp-spec whose last- | |||
byte-pos value is less than its first-byte-pos value, or whose | byte-pos value is less than its first-byte-pos value, or whose | |||
instance-length value is less than or equal to its last-byte-pos | instance-length value is less than or equal to its last-byte-pos | |||
value, is invalid. The recipient of an invalid byte-content-range- | value, is invalid. The recipient of an invalid byte-content-range- | |||
spec MUST ignore it and any content transferred along with it. | spec MUST ignore it and any content transferred along with it. | |||
A server sending a response with status code 416 (Requested range not | A server sending a response with status code 416 (Requested range not | |||
satisfiable) SHOULD include a Content-Range field with a byte-range- | satisfiable) SHOULD include a Content-Range field with a byte-range- | |||
resp-spec of "*". The instance-length specifies the current length of | resp-spec of "*". The instance-length specifies the current length | |||
the selected resource. A response with status code 206 (Partial | of the selected resource. A response with status code 206 (Partial | |||
Content) MUST NOT include a Content-Range field with a byte-range- | Content) MUST NOT include a Content-Range field with a byte-range- | |||
resp-spec of "*". | resp-spec of "*". | |||
Examples of byte-content-range-spec values, assuming that the entity | Examples of byte-content-range-spec values, assuming that the entity | |||
contains a total of 1234 bytes: | contains a total of 1234 bytes: | |||
. The first 500 bytes: | . The first 500 bytes: | |||
bytes 0-499/1234 | bytes 0-499/1234 | |||
. The second 500 bytes: | . The second 500 bytes: | |||
skipping to change at page 123, line 40 | skipping to change at page 132, line 50 | |||
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 19.2. See appendix 19.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 | decode a multipart/byteranges message MUST NOT ask for multiple byte- | |||
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 | |||
request. | request. | |||
If the server ignores a byte-range-spec because it is syntactically | If the server ignores a byte-range-spec because it is syntactically | |||
invalid, the server SHOULD treat the request as if the invalid Range | invalid, the server SHOULD treat the request as if the invalid Range | |||
header field did not exist. (Normally, this means return a 200 | header field did not exist. (Normally, this means return a 200 | |||
response containing the full entity). | response containing the full entity). | |||
skipping to change at page 124, line 41 | skipping to change at page 133, line 50 | |||
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 section | RFC 822. The field value is an HTTP-date, as described in | |||
3.3.1; it MUST be sent in RFC 1123 [8]-date format. | section 3.3.1; it MUST be sent in RFC 1123 [8]-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 | Protocols), the response MAY include a Date header field, at the | |||
the server's option. | server's option. | |||
2. If the response status code conveys a server error, e.g. 500 | 2. If the response status code conveys a server error, e.g. 500 | |||
(Internal Server Error) or 503 (Service Unavailable), and it is | (Internal Server Error) or 503 (Service Unavailable), and it is | |||
inconvenient or impossible to generate a valid Date. | inconvenient or impossible to generate a valid Date. | |||
3. If the server does not have a clock that can provide a | 3. If the server does not have a clock that can provide a reasonable | |||
reasonable approximation of the current time, its responses | approximation of the current time, its responses MUST NOT include | |||
MUST NOT include a Date header field. In this case, the rules | a Date header field. In this case, the rules in section 14.18.1 | |||
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 [28], to synchronize its | |||
clock with a reliable external standard. | 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 represent | time subsequent to the generation of the message. It SHOULD | |||
the best available approximation of the date and time of message | represent the best available approximation of the date and time of | |||
generation, unless the implementation has no means of generating a | message generation, unless the implementation has no means of | |||
reasonably accurate date and time. In theory, the date ought to | generating a reasonably accurate date and time. In theory, the date | |||
represent the moment just before the entity is generated. In | ought to represent the moment just before the entity is generated. | |||
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 tag | tags are described in sections 14.24, 14.26 and 14.44. The entity | |||
MAY be used for comparison with other entities from the same resource | tag MAY be used for comparison with other entities from the same | |||
(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 | |||
skipping to change at page 127, line 19 | skipping to change at page 136, line 21 | |||
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 be | response is considered stale. A stale cache entry may not normally | |||
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 section | intermediate cache that has a fresh copy of the entity). See | |||
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 RFC 1123 date format: | |||
Expires = "Expires" ":" HTTP-date | Expires = "Expires" ":" HTTP-date | |||
skipping to change at page 128, line 28 | skipping to change at page 137, line 28 | |||
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 RFC 822 [9] as updated by RFC 1123 [8]: | |||
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 NOT | identifying the source of invalid or unwanted requests. It SHOULD | |||
be used as an insecure form of access protection. The interpretation | NOT be used as an insecure form of access protection. The | |||
of this field is that the request is being performed on behalf of the | interpretation of this field is that the request is being performed | |||
person given, who accepts responsibility for the method performed. In | on behalf of the person given, who accepts responsibility for the | |||
particular, robot agents SHOULD include this header so that the | method performed. In particular, robot agents SHOULD include this | |||
person responsible for running the robot can be contacted if problems | header so that the person responsible for running the robot can be | |||
occur on the receiving end. | contacted if problems occur on the receiving end. | |||
The Internet e-mail address in this field MAY be separate from the | The Internet e-mail address in this field MAY be separate from the | |||
Internet host which issued the request. For example, when a request | Internet host which issued the request. For example, when a request | |||
is passed through a proxy the original issuer's address SHOULD be | is passed through a proxy the original issuer's address SHOULD be | |||
used. | used. | |||
The client SHOULD NOT send the From header field without the user's | The client SHOULD NOT send the From header field without the user's | |||
approval, as it might conflict with the user's privacy interests or | approval, as it might conflict with the user's privacy interests or | |||
their site's security policy. It is strongly recommended that the | their site's security policy. It is strongly recommended that the | |||
user be able to disable, enable, and modify the value of this field | user be able to disable, enable, and modify the value of this field | |||
skipping to change at page 129, line 30 | skipping to change at page 138, line 30 | |||
A client MUST include a Host header field in all HTTP/1.1 request | A client MUST include a Host header field in all HTTP/1.1 request | |||
messages . If the requested URI does not include an Internet host | messages . If the requested URI does not include an Internet host | |||
name for the service being requested, then the Host header field MUST | name for the service being requested, then the Host header field MUST | |||
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any | |||
request message it forwards does contain an appropriate Host header | request message it forwards does contain an appropriate Host header | |||
field that identifies the service being requested by the proxy. All | field that identifies the service being requested by the proxy. All | |||
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) | |||
status code to any HTTP/1.1 request message which lacks a Host header | status code to any HTTP/1.1 request message which lacks a Host header | |||
field. | field. | |||
See sections 5.2 and 19.6.1.1 for other requirements relating to | See sections 5.2 and F.1.1 for other requirements relating to Host. | |||
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 also | information with a minimum amount of transaction overhead. It is | |||
used, on updating requests, to prevent inadvertent modification of | also used, on updating requests, to prevent inadvertent modification | |||
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. | |||
skipping to change at page 131, line 4 | skipping to change at page 139, line 50 | |||
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: | |||
a) If the request would normally result in anything other than a | 1. If the request would normally result in anything other than a 200 | |||
200 (OK) status, or if the passed If-Modified-Since date is | (OK) status, or if the passed If-Modified-Since date is invalid, | |||
invalid, the response is exactly the same as for a normal GET. | the response is exactly the same as for a normal GET. A date | |||
A date which is later than the server's current time is | which is later than the server's current time is invalid. | |||
invalid. | ||||
b) If the variant has been modified since the If-Modified-Since | 2. If the variant has been modified since the If-Modified-Since | |||
date, the response is exactly the same as for a normal GET. | date, the response is exactly the same as for a normal GET. | |||
c) If the variant has not been modified since a valid If- | 3. If the variant has not been modified since a valid If-Modified- | |||
Modified-Since date, the server SHOULD return a 304 (Not | Since date, the server SHOULD return a 304 (Not Modified) | |||
Modified) response. | response. | |||
The purpose of this feature is to allow efficient updates of cached | The purpose of this feature is to allow efficient updates of cached | |||
information with a minimum amount of transaction overhead. | information with a minimum amount of transaction overhead. | |||
Note: The Range request-header field modifies the meaning of If- | Note: The Range request-header field modifies the meaning of If- | |||
Modified-Since; see section 14.35 for full details. | Modified-Since; see section 14.35 for full details. | |||
Note: If-Modified-Since times are interpreted by the server, whose | Note: If-Modified-Since times are interpreted by the server, whose | |||
clock might not be synchronized with the client. | clock might not be synchronized with the client. | |||
skipping to change at page 132, line 22 | skipping to change at page 141, line 19 | |||
undefined by this specification. | undefined by this specification. | |||
14.26 If-None-Match | 14.26 If-None-Match | |||
The If-None-Match request-header field is used with a method to make | The If-None-Match request-header field is used with a method to make | |||
it conditional. A client that has one or more entities previously | it conditional. A client that has one or more entities previously | |||
obtained from the resource can verify that none of those entities is | obtained from the resource can verify that none 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-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. PUT) | transaction overhead. It is also used to prevent a method (e.g. | |||
from inadvertently modifying an existing resource when the client | PUT) from inadvertently modifying an existing resource when the | |||
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- | |||
related header fields (particularly ETag) of one of the entities that | related header fields (particularly ETag) of one of the entities that | |||
matched. For all other request methods, the server MUST respond with | matched. For all other request methods, the server MUST respond with | |||
a status of 412 (Precondition Failed). | a status of 412 (Precondition Failed). | |||
See section 13.3.3 for rules on how to determine if two entities tags | See section 13.3.3 for rules on how to determine if two entities tags | |||
match. The weak comparison function can only be used with GET or HEAD | match. The weak comparison function can only be used with GET or | |||
requests. | HEAD requests. | |||
If none of the entity tags match, then the server MAY perform the | If none of the entity tags match, then the server MAY perform the | |||
requested method as if the If-None-Match header field did not exist, | requested method as if the If-None-Match header field did not exist, | |||
but MUST also ignore any If-Modified-Since header field(s) in the | but MUST also ignore any If-Modified-Since header field(s) in the | |||
request. That is, if no entity tags match, then the server MUST NOT | request. That is, if no entity tags match, then the server MUST NOT | |||
return a 304 (Not Modified) response. | return a 304 (Not Modified) response. | |||
If the request would, without the If-None-Match header field, result | If the request would, without the If-None-Match header field, result | |||
in anything other than a 2xx or 304 status, then the If-None-Match | in anything other than a 2xx or 304 status, then the If-None-Match | |||
header MUST be ignored. (See section 13.3.4 for a discussion of | header MUST be ignored. (See section 13.3.4 for a discussion of | |||
skipping to change at page 133, line 47 | skipping to change at page 142, line 39 | |||
If a client has a partial copy of an entity in its cache, and wishes | If a client has a partial copy of an entity in its cache, and wishes | |||
to have an up-to-date copy of the entire entity in its cache, it | to have an up-to-date copy of the entire entity in its cache, it | |||
could use the Range request-header with a conditional GET (using | could use the Range request-header with a conditional GET (using | |||
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, send | request. Informally, its meaning is `if the entity is unchanged, | |||
me the part(s) that I am missing; otherwise, send me the entire new | send me the part(s) that I am missing; otherwise, send me the entire | |||
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 | |||
skipping to change at page 135, line 4 | skipping to change at page 143, line 45 | |||
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 database | of the set of last-modify times for its component parts. For | |||
gateways, it may be the last-update time stamp of the record. For | database gateways, it may be the last-update time stamp of the | |||
virtual objects, it may be the last time the internal state changed. | record. For virtual objects, it may be the last time the internal | |||
state changed. | ||||
An origin server MUST NOT send a Last-Modified date which is later | An origin server MUST NOT send a Last-Modified date which is later | |||
than the server's time of message origination. In such cases, where | than the server's time of message origination. In such cases, where | |||
the resource's last modification would indicate some time in the | the resource's last modification would indicate some time in the | |||
future, the server MUST replace that date with the message | future, the server MUST replace that date with the message | |||
origination date. | origination date. | |||
An origin server SHOULD obtain the Last-Modified value of the entity | An origin server SHOULD obtain the Last-Modified value of the entity | |||
as close as possible to the time that it generates the Date value of | as close as possible to the time that it generates the Date value of | |||
its response. This allows a recipient to make an accurate assessment | its response. This allows a recipient to make an accurate assessment | |||
skipping to change at page 135, line 37 | skipping to change at page 144, line 31 | |||
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. | HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. | |||
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. The | server's preferred URI for automatic redirection to the resource. | |||
field value consists of a single absolute URI. | The field value consists of a single absolute URI. | |||
Location = "Location" ":" absoluteURI | Location = "Location" ":" absoluteURI | |||
An example is: | An example is: | |||
Location: http://www.w3.org/pub/WWW/People.html | Location: http://www.w3.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. | |||
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 attempting | next inbound server. This can be useful when the client is | |||
to trace a request chain which appears to be failing or looping in | attempting to trace a request chain which appears to be failing or | |||
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 is | respond as the final recipient. If the received Max-Forwards value | |||
greater than zero, then the forwarded message MUST contain an updated | is greater than zero, then the forwarded message MUST contain an | |||
Max-Forwards field with a value decremented by one (1). | updated Max-Forwards field with a value decremented by one (1). | |||
The Max-Forwards header field MAY be ignored for all other methods | The Max-Forwards header field MAY be ignored for all other methods | |||
defined by this specification and for any extension methods for which | defined by this specification and for any extension methods for which | |||
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 | |||
skipping to change at page 139, line 8 | skipping to change at page 147, line 50 | |||
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 | A suffix-byte-range-spec is used to specify the suffix of the entity- | |||
entity-body, of a length given by the suffix-length value. (That is, | body, of a length given by the suffix-length value. (That is, this | |||
this form specifies the last N bytes of an entity-body.) If the | form specifies the last N bytes of an entity-body.) If the entity is | |||
entity is shorter than the specified suffix-length, the entire | shorter than the specified suffix-length, the entire entity-body is | |||
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- | |||
zero suffix-length, then the byte-range-set is satisfiable. | zero suffix-length, then the byte-range-set is satisfiable. | |||
Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set | Otherwise, the byte-range-set is unsatisfiable. If the byte-range- | |||
is unsatisfiable, the server SHOULD return a response with a status | set is unsatisfiable, the server SHOULD return a response with a | |||
of 416 (Requested range not satisfiable). Otherwise, the server | status of 416 (Requested range not satisfiable). Otherwise, the | |||
SHOULD return a response with a status of 206 (Partial Content) | server SHOULD return a response with a status of 206 (Partial | |||
containing the satisfiable ranges of the entity-body. | Content) containing the satisfiable ranges of the entity-body. | |||
Examples of byte-ranges-specifier values (assuming an entity-body of | Examples of byte-ranges-specifier values (assuming an entity-body of | |||
length 10000): | length 10000): | |||
- The first 500 bytes (byte offsets 0-499, inclusive): bytes=0- | o The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499 | |||
499 | ||||
- The second 500 bytes (byte offsets 500-999, inclusive): | o The second 500 bytes (byte offsets 500-999, inclusive): bytes=500- | |||
bytes=500-999 | 999 | |||
- The final 500 bytes (byte offsets 9500-9999, inclusive): | o The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=- | |||
bytes=-500 | 500 | |||
- Or bytes=9500- | o Or bytes=9500- | |||
- 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 | |||
- 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: | |||
skipping to change at page 140, line 4 | skipping to change at page 148, line 45 | |||
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: | |||
- The presence of a Range header in an unconditional GET modifies | o The presence of a Range header in an unconditional GET modifies | |||
what is returned if the GET is otherwise successful. In other | what is returned if the GET is otherwise successful. In other | |||
words, the response carries a status code of 206 (Partial | words, the response carries a status code of 206 (Partial Content) | |||
Content) instead of 200 (OK). | instead of 200 (OK). | |||
- The presence of a Range header in a conditional GET (a request | o The presence of a Range header in a conditional GET (a request | |||
using one or both of If-Modified-Since and If-None-Match, or | using one or both of If-Modified-Since and If-None-Match, or one | |||
one or both of If-Unmodified-Since and If-Match) modifies what | or both of If-Unmodified-Since and If-Match) modifies what is | |||
is returned if the GET is otherwise successful and the | returned if the GET is otherwise successful and the condition is | |||
condition is true. It does not affect the 304 (Not Modified) | true. It does not affect the 304 (Not Modified) response returned | |||
response returned if the conditional is false. | if the conditional is false. | |||
In some cases, it might be more appropriate to use the If-Range | In some cases, it might be more appropriate to use the If-Range | |||
header (see section 14.27) in addition to the Range header. | header (see section 14.27) in addition to the Range header. | |||
If a proxy that supports ranges receives a Range request, forwards | If a proxy that supports ranges receives a Range request, forwards | |||
the request to an inbound server, and receives an entire entity in | the request to an inbound server, and receives an entire entity in | |||
reply, it SHOULD only return the requested range to its client. It | reply, it SHOULD only return the requested range to its client. It | |||
SHOULD store the entire received response in its cache if that is | SHOULD store the entire received response in its cache if that is | |||
consistent with its cache allocation policies. | consistent with its cache allocation policies. | |||
skipping to change at page 141, line 4 | skipping to change at page 149, line 46 | |||
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.w3.org/hypertext/DataSources/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. See | relative to the Request-URI. The URI MUST NOT include a fragment. | |||
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. | |||
skipping to change at page 142, line 40 | skipping to change at page 151, line 40 | |||
Therefore, the keyword MUST be supplied within a Connection header | Therefore, the keyword MUST be supplied within a Connection header | |||
field (section 14.10) whenever TE is present in an HTTP/1.1 message. | field (section 14.10) whenever TE is present in an HTTP/1.1 message. | |||
A server tests whether a transfer-coding is acceptable, according to | A server tests whether a transfer-coding is acceptable, according to | |||
a TE field, using these rules: | a TE field, using these rules: | |||
1. The "chunked" transfer-coding is always acceptable. If the | 1. The "chunked" transfer-coding is always acceptable. If the | |||
keyword "trailers" is listed, the client indicates that it is | keyword "trailers" is listed, the client indicates that it is | |||
willing to accept trailer fields in the chunked response on | willing to accept trailer fields in the chunked response on | |||
behalf of itself and any downstream clients. The implication is | behalf of itself and any downstream clients. The implication is | |||
that, if given, the client is stating that either all | that, if given, the client is stating that either all downstream | |||
downstream clients are willing to accept trailer fields in the | clients are willing to accept trailer fields in the forwarded | |||
forwarded response, or that it will attempt to buffer the | response, or that it will attempt to buffer the response on | |||
response on behalf of downstream recipients. | behalf of downstream recipients. | |||
Note: HTTP/1.1 does not define any means to limit the size of a | Note: HTTP/1.1 does not define any means to limit the size of a | |||
chunked response such that a client can be assured of buffering | chunked response such that a client can be assured of buffering | |||
the entire response. | the entire response. | |||
2. If the transfer-coding being tested is one of the transfer- | 2. If the transfer-coding being tested is one of the transfer- | |||
codings listed in the TE field, then it is acceptable unless it | codings listed in the TE field, then it is acceptable unless it | |||
is accompanied by a qvalue of 0. (As defined in section 3.9, a | is accompanied by a qvalue of 0. (As defined in section 3.9, a | |||
qvalue of 0 means "not acceptable.") | qvalue of 0 means "not acceptable.") | |||
3. If multiple transfer-codings are acceptable, then the | ||||
acceptable transfer-coding with the highest non-zero qvalue is | 3. If multiple transfer-codings are acceptable, then the acceptable | |||
preferred. The "chunked" transfer-coding always has a qvalue | transfer-coding with the highest non-zero qvalue is preferred. | |||
of 1. | The "chunked" transfer-coding always has a qvalue of 1. | |||
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. Doing | message using chunked transfer-coding with a non-empty trailer. | |||
so allows the recipient to know which header fields to expect in the | Doing so allows the recipient to know which header fields to expect | |||
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. | |||
Message header fields listed in the Trailer header field MUST NOT | Message header fields listed in the Trailer header field MUST NOT | |||
include the following header fields: | include the following header fields: | |||
. Transfer-Encoding | o Transfer-Encoding | |||
. Content-Length | o Content-Length | |||
. Trailer | o Trailer | |||
14.41 Transfer-Encoding | 14.41 Transfer-Encoding | |||
The Transfer-Encoding general-header field indicates what (if any) | The Transfer-Encoding general-header field indicates what (if any) | |||
type of transformation has been applied to the message body in order | type of transformation has been applied to the message body in order | |||
to safely transfer it between the sender and the recipient. This | to safely transfer it between the sender and the recipient. This | |||
differs from the content-coding in that the transfer-coding is a | differs from the content-coding in that the transfer-coding is a | |||
property of the message, not of the entity. | property of the message, not of the entity. | |||
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding | Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding | |||
skipping to change at page 144, line 27 | skipping to change at page 153, line 30 | |||
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. It | for transition from HTTP/1.1 to some other, incompatible protocol. | |||
does so by allowing the client to advertise its desire to use another | It does so by allowing the client to advertise its desire to use | |||
protocol, such as a later version of HTTP with a higher major version | another protocol, such as a later version of HTTP with a higher major | |||
number, even though the current request has been made using HTTP/1.1. | version number, even though the current request has been made using | |||
This eases the difficult transition between incompatible protocols by | HTTP/1.1. This eases the difficult transition between incompatible | |||
allowing the client to initiate a request in the more commonly | protocols by allowing the client to initiate a request in the more | |||
supported protocol while indicating to the server that it would like | commonly supported protocol while indicating to the server that it | |||
to use a "better" protocol if available (where "better" is determined | would like to use a "better" protocol if available (where "better" is | |||
by the server, possibly according to the nature of the method and/or | determined by the server, possibly according to the nature of the | |||
resource being requested). | method and/or resource being requested). | |||
The Upgrade header field only applies to switching application-layer | The Upgrade header field only applies to switching application-layer | |||
protocols upon the existing transport-layer connection. Upgrade | protocols upon the existing transport-layer connection. Upgrade | |||
cannot be used to insist on a protocol change; its acceptance and use | cannot be used to insist on a protocol change; its acceptance and use | |||
by the server is optional. The capabilities and nature of the | by the server is optional. The capabilities and nature of the | |||
application-layer communication after the protocol change is entirely | application-layer communication after the protocol change is entirely | |||
dependent upon the new protocol chosen, although the first action | dependent upon the new protocol chosen, although the first action | |||
after changing the protocol MUST be a response to the initial HTTP | after changing the protocol MUST be a response to the initial HTTP | |||
request containing the Upgrade header field. | request containing the Upgrade header field. | |||
skipping to change at page 145, line 19 | skipping to change at page 154, line 20 | |||
This specification only defines the protocol name "HTTP" for use by | This specification only defines the protocol name "HTTP" for use by | |||
the family of Hypertext Transfer Protocols, as defined by the HTTP | the family of Hypertext Transfer Protocols, as defined by the HTTP | |||
version rules of section 3.1 and future updates to this | version rules of section 3.1 and future updates to this | |||
specification. Any token can be used as a protocol name; however, it | specification. Any token can be used as a protocol name; however, it | |||
will only be useful if both the client and server associate the name | will only be useful if both the client and server associate the name | |||
with the same protocol. | with the same protocol. | |||
14.43 User-Agent | 14.43 User-Agent | |||
The User-Agent request-header field contains information about the | The User-Agent request-header field contains information about the | |||
user agent originating the request. This is for statistical purposes, | user agent originating the request. This is for statistical | |||
the tracing of protocol violations, and automated recognition of user | purposes, the tracing of protocol violations, and automated | |||
agents for the sake of tailoring responses to avoid particular user | recognition of user agents for the sake of tailoring responses to | |||
agent limitations. User agents SHOULD include this field with | avoid particular user agent limitations. User agents SHOULD include | |||
requests. The field can contain multiple product tokens (section 3.8) | this field with requests. The field can contain multiple product | |||
and comments identifying the agent and any subproducts which form a | tokens (section 3.8) and comments identifying the agent and any | |||
significant part of the user agent. By convention, the product tokens | subproducts which form a significant part of the user agent. By | |||
are listed in order of their significance for identifying the | convention, the product tokens are listed in order of their | |||
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 | |||
skipping to change at page 146, line 18 | skipping to change at page 155, line 21 | |||
response. | response. | |||
A Vary field value consisting of a list of field-names signals that | A Vary field value consisting of a list of field-names signals that | |||
the representation selected for the response is based on a selection | the representation selected for the response is based on a selection | |||
algorithm which considers ONLY the listed request-header field values | algorithm which considers ONLY the listed request-header field values | |||
in selecting the most appropriate representation. A cache MAY assume | in selecting the most appropriate representation. A cache MAY assume | |||
that the same selection will be made for future requests with the | that the same selection will be made for future requests with the | |||
same values for the listed field names, for the duration of time for | same values for the listed field names, for the duration of time for | |||
which the response is fresh. | which the response is fresh. | |||
The field-names given are not limited to the set of standard | The field-names given are not limited to the set of standard request- | |||
request-header fields defined by this specification. Field names are | header fields defined by this specification. Field names are case- | |||
case-insensitive. | insensitive. | |||
A Vary field value of "*" signals that unspecified parameters not | A Vary field value of "*" signals that unspecified parameters not | |||
limited to the request-headers (e.g., the network address of the | limited to the request-headers (e.g., the network address of the | |||
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 | |||
skipping to change at page 146, line 46 | skipping to change at page 155, line 49 | |||
all senders along the request/response chain. | all senders along the request/response chain. | |||
Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
received-by = ( host [ ":" port ] ) | pseudonym | received-by = ( host [ ":" port ] ) | pseudonym | |||
pseudonym = token | pseudonym = token | |||
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 | received by the server or client along each segment of the request/ | |||
request/response chain. The received-protocol version is appended to | response chain. The received-protocol version is appended to the Via | |||
the Via field value when the message is forwarded so that information | field value when the message is forwarded so that information about | |||
about the protocol capabilities of upstream applications remains | the protocol capabilities of upstream applications remains visible to | |||
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 | |||
recipient server or client that subsequently forwarded the message. | recipient server or client that subsequently forwarded the message. | |||
However, if the real host is considered to be sensitive information, | However, if the real host is considered to be sensitive information, | |||
it MAY be replaced by a pseudonym. If the port is not given, it MAY | it MAY be replaced by a pseudonym. If the port is not given, it MAY | |||
be assumed to be the default port of the received-protocol. | be assumed to be the default port of the received-protocol. | |||
Multiple Via field values represents each proxy or gateway that has | Multiple Via field values represents each proxy or gateway that has | |||
forwarded the message. Each recipient MUST append its information | forwarded the message. Each recipient MUST append its information | |||
skipping to change at page 148, line 36 | skipping to change at page 157, line 35 | |||
warn-agent = ( host [ ":" port ] ) | pseudonym | warn-agent = ( 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 = <"> HTTP-date <"> | |||
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, such | response. This decision MAY be based on any available knowledge, | |||
as the location of the cache or user, the Accept-Language field in a | such as the location of the cache or user, the Accept-Language field | |||
request, the Content-Language field in a response, etc. The default | in a request, the Content-Language field in a response, etc. The | |||
language is English and the default character set is ISO-8859-1. | default language is English and the default character set is ISO- | |||
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 RFC 2047 [14]. | |||
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 received | specific Warning codes. It MUST then add any Warning headers | |||
in the validating response. In other words, Warning headers are those | received in the validating response. In other words, Warning headers | |||
that would be attached to the most recent relevant response. | are those that would be attached to the most recent relevant | |||
response. | ||||
When multiple Warning headers are attached to a response, the user | When multiple Warning headers are attached to a response, the user | |||
agent ought to inform the user of as many of them as possible, in the | agent ought to inform the user of as many of them as possible, in the | |||
order that they appear in the response. If it is not possible to | order that they appear in the response. If it is not possible to | |||
inform the user of all of the warnings, the user agent SHOULD follow | inform the user of all of the warnings, the user agent SHOULD follow | |||
these heuristics: | these heuristics: | |||
- Warnings that appear early in the response take priority over | o Warnings that appear early in the response take priority over | |||
those appearing later in the response. | those appearing later in the response. | |||
- Warnings in the user's preferred character set take priority | o Warnings in the user's preferred character set take priority over | |||
over warnings in other character sets but with identical warn- | warnings in other character sets but with identical warn-codes and | |||
codes and warn-agents. | warn-agents. | |||
Systems that generate multiple Warning headers SHOULD order them with | Systems that generate multiple Warning headers SHOULD order them with | |||
this user agent behavior in mind. | this user agent behavior in mind. | |||
Requirements for the behavior of caches with respect to Warnings are | Requirements for the behavior of caches with respect to Warnings are | |||
stated in section 13.1.2. | stated in section 13.1.2. | |||
This is a list of the currently-defined warn-codes, each with a | This is a list of the currently-defined warn-codes, each with a | |||
recommended warn-text in English, and a description of its meaning. | recommended warn-text in English, and a description of its meaning. | |||
skipping to change at page 150, line 6 | skipping to change at page 159, line 10 | |||
lifetime greater than 24 hours and the response's age is greater | lifetime greater than 24 hours and the response's age is greater | |||
than 24 hours. | than 24 hours. | |||
199 Miscellaneous warning | 199 Miscellaneous warning | |||
The warning text MAY include arbitrary information to be presented | The warning text MAY include arbitrary information to be presented | |||
to a human user, or logged. A system receiving this warning MUST | to a human user, or logged. A system receiving this warning MUST | |||
NOT take any automated action, besides presenting the warning to | NOT take any automated action, besides presenting the warning to | |||
the user. | the user. | |||
214 Transformation applied | 214 Transformation applied | |||
MUST be added by an intermediate cache or proxy if it applies any | MUST be added by an intermediate cache or proxy if it applies any | |||
transformation changing the content-coding (as specified in the | transformation changing the content-coding (as specified in the | |||
Content-Encoding header) or media-type (as specified in the | Content-Encoding header) or media-type (as specified in the | |||
Content-Type header) of the response, or the entity-body of the | Content-Type header) of the response, or the entity-body of the | |||
response, unless this Warning code already appears in the response. | response, unless this Warning code already appears in the | |||
response. | ||||
299 Miscellaneous persistent warning | 299 Miscellaneous persistent warning | |||
The warning text MAY include arbitrary information to be presented | The warning text MAY include arbitrary information to be presented | |||
to a human user, or logged. A system receiving this warning MUST | to a human user, or logged. A system receiving this warning MUST | |||
NOT take any automated action. | NOT take any automated action. | |||
If an implementation sends a message with one or more Warning headers | If an implementation sends a message with one or more Warning headers | |||
whose version is HTTP/1.0 or lower, then the sender MUST include in | whose version is HTTP/1.0 or lower, then the sender MUST include in | |||
each warning-value a warn-date that matches the date in the response. | each warning-value a warn-date that matches the date in the response. | |||
If an implementation receives a message with a warning-value that | If an implementation receives a message with a warning-value that | |||
includes a warn-date, and that warn-date is different from the Date | includes a warn-date, and that warn-date is different from the Date | |||
skipping to change at page 151, line 23 | skipping to change at page 160, line 31 | |||
designers and implementors be particularly careful in this area. | designers and implementors be particularly careful in this area. | |||
History shows that errors in this area often create serious security | History shows that errors in this area often create serious security | |||
and/or privacy problems and generate highly adverse publicity for the | and/or privacy problems and generate highly adverse publicity for the | |||
implementor's company. | implementor's company. | |||
15.1.1 Abuse of Server Log Information | 15.1.1 Abuse of Server Log Information | |||
A server is in the position to save personal data about a user's | A server is in the position to save personal data about a user's | |||
requests which might identify their reading patterns or subjects of | requests which might identify their reading patterns or subjects of | |||
interest. This information is clearly confidential in nature and its | interest. This information is clearly confidential in nature and its | |||
handling can be constrained by law in certain countries. People using | handling can be constrained by law in certain countries. People | |||
the HTTP protocol to provide data are responsible for ensuring that | using the HTTP protocol to provide data are responsible for ensuring | |||
such material is not distributed without the permission of any | that such material is not distributed without the permission of any | |||
individuals that are identifiable by the published results. | individuals that are identifiable by the published results. | |||
15.1.2 Transfer of Sensitive Information | 15.1.2 Transfer of Sensitive Information | |||
Like any generic data transfer protocol, HTTP cannot regulate the | Like any generic data transfer protocol, HTTP cannot regulate the | |||
content of the data that is transferred, nor is there any a priori | content of the data that is transferred, nor is there any a priori | |||
method of determining the sensitivity of any particular piece of | method of determining the sensitivity of any particular piece of | |||
information within the context of any given request. Therefore, | information within the context of any given request. Therefore, | |||
applications SHOULD supply as much control over this information as | applications SHOULD supply as much control over this information as | |||
possible to the provider of that information. Four header fields are | possible to the provider of that information. Four header fields are | |||
worth special mention in this context: Server, Via, Referer and From. | worth special mention in this context: Server, Via, Referer and From. | |||
Revealing the specific software version of the server might allow the | Revealing the specific software version of the server might allow the | |||
server machine to become more vulnerable to attacks against software | server machine to become more vulnerable to attacks against software | |||
that is known to contain security holes. Implementors SHOULD make the | that is known to contain security holes. Implementors SHOULD make | |||
Server header field a configurable option. | the Server header field a configurable option. | |||
Proxies which serve as a portal through a network firewall SHOULD | Proxies which serve as a portal through a network firewall SHOULD | |||
take special precautions regarding the transfer of header information | take special precautions regarding the transfer of header information | |||
that identifies the hosts behind the firewall. In particular, they | that identifies the hosts behind the firewall. In particular, they | |||
SHOULD remove, or replace with sanitized versions, any Via fields | SHOULD remove, or replace with sanitized versions, any Via fields | |||
generated behind the firewall. | generated behind the firewall. | |||
The Referer header allows reading patterns to be studied and reverse | The Referer header allows reading patterns to be studied and reverse | |||
links drawn. Although it can be very useful, its power can be abused | links drawn. Although it can be very useful, its power can be abused | |||
if user details are not separated from the information contained in | if user details are not separated from the information contained in | |||
the Referer. Even when the personal information has been removed, the | the Referer. Even when the personal information has been removed, | |||
Referer header might indicate a private document's URI whose | the Referer header might indicate a private document's URI whose | |||
publication would be inappropriate. | publication would be inappropriate. | |||
The information sent in the From field might conflict with the user's | The information sent in the From field might conflict with the user's | |||
privacy interests or their site's security policy, and hence it | privacy interests or their site's security policy, and hence it | |||
SHOULD NOT be transmitted without the user being able to disable, | SHOULD NOT be transmitted without the user being able to disable, | |||
enable, and modify the contents of the field. The user MUST be able | enable, and modify the contents of the field. The user MUST be able | |||
to set the contents of this field within a user preference or | to set the contents of this field within a user preference or | |||
application defaults configuration. | application defaults configuration. | |||
We suggest, though do not require, that a convenient toggle interface | We suggest, though do not require, that a convenient toggle interface | |||
skipping to change at page 153, line 49 | skipping to change at page 163, line 7 | |||
special care not to serve files that were not intended to be | special care not to serve files that were not intended to be | |||
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and | |||
other operating systems use ".." as a path component to indicate a | other operating systems use ".." as a path component to indicate a | |||
directory level above the current one. On such a system, an HTTP | directory level above the current one. On such a system, an HTTP | |||
server MUST disallow any such construct in the Request-URI if it | server MUST disallow any such construct in the Request-URI if it | |||
would otherwise allow access to a resource outside those intended to | would otherwise allow access to a resource outside those intended to | |||
be accessible via the HTTP server. Similarly, files intended for | be accessible via the HTTP server. Similarly, files intended for | |||
reference only internally to the server (such as access control | reference only internally to the server (such as access control | |||
files, configuration files, and script code) MUST be protected from | files, configuration files, and script code) MUST be protected from | |||
inappropriate retrieval, since they might contain sensitive | inappropriate retrieval, since they might contain sensitive | |||
information. Experience has shown that minor bugs in such HTTP server | information. Experience has shown that minor bugs in such HTTP | |||
implementations have turned into security risks. | server implementations have turned into security risks. | |||
15.3 DNS Spoofing | 15.3 DNS Spoofing | |||
Clients using HTTP rely heavily on the Domain Name Service, and are | Clients using HTTP rely heavily on the Domain Name Service, and are | |||
thus generally prone to security attacks based on the deliberate | thus generally prone to security attacks based on the deliberate mis- | |||
mis-association of IP addresses and DNS names. Clients need to be | association of IP addresses and DNS names. Clients need to be | |||
cautious in assuming the continuing validity of an IP number/DNS name | cautious in assuming the continuing validity of an IP number/DNS name | |||
association. | association. | |||
In particular, HTTP clients SHOULD rely on their name resolver for | In particular, HTTP clients SHOULD rely on their name resolver for | |||
confirmation of an IP number/DNS name association, rather than | confirmation of an IP number/DNS name association, rather than | |||
caching the result of previous host name lookups. Many platforms | caching the result of previous host name lookups. Many platforms | |||
already can cache host name lookups locally when appropriate, and | already can cache host name lookups locally when appropriate, and | |||
they SHOULD be configured to do so. It is proper for these lookups to | they SHOULD be configured to do so. It is proper for these lookups | |||
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 [24], the | |||
skipping to change at page 154, line 48 | skipping to change at page 164, line 8 | |||
If a single server supports multiple organizations that do not trust | If a single server supports multiple organizations that do not trust | |||
one another, then it MUST check the values of Location and Content- | one another, then it MUST check the values of Location and Content- | |||
Location headers in responses that are generated under control of | Location headers in responses that are generated under control of | |||
said organizations to make sure that they do not attempt to | said organizations to make sure that they do not attempt to | |||
invalidate resources over which they have no authority. | invalidate resources over which they have no authority. | |||
15.5 Content-Disposition Issues | 15.5 Content-Disposition Issues | |||
RFC 1806 [35], from which the often implemented Content-Disposition | RFC 1806 [35], from which the often implemented Content-Disposition | |||
(see section 19.5.1) header in HTTP is derived, has a number of very | (see appendix E.1) header in HTTP is derived, has a number of very | |||
serious security considerations. Content-Disposition is not part of | serious security considerations. Content-Disposition is not part of | |||
the HTTP standard, but since it is widely implemented, we are | the HTTP standard, but since it is widely implemented, we are | |||
documenting its use and risks for implementors. See RFC 2183 [49] | documenting its use and risks for implementors. See RFC 2183 [49] | |||
(which updates RFC 1806) for details. | (which updates RFC 1806) for details. | |||
15.6 Authentication Credentials and Idle Clients | 15.6 Authentication Credentials and Idle Clients | |||
Existing HTTP clients and user agents typically retain authentication | Existing HTTP clients and user agents typically retain authentication | |||
information indefinitely. HTTP/1.1. does not provide a method for a | information indefinitely. HTTP/1.1. does not provide a method for a | |||
server to direct clients to discard these cached credentials. This is | server to direct clients to discard these cached credentials. This | |||
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: | |||
- 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. | |||
- Applications which include a session termination indication | o Applications which include a session termination indication (such | |||
(such as a `logout' or `commit' button on a page) after which | as a `logout' or `commit' button on a page) after which the server | |||
the server side of the application `knows' that there is no | side of the application `knows' that there is no further reason | |||
further reason for the client to retain the credentials. | for the client to retain the credentials. | |||
This is currently under separate study. There are a number of work- | This is currently under separate study. There are a number of work- | |||
arounds to parts of this problem, and we encourage the use of | arounds to parts of this problem, and we encourage the use of | |||
password protection in screen savers, idle time-outs, and other | password protection in screen savers, idle time-outs, and other | |||
methods which mitigate the security problems inherent in this | methods which mitigate the security problems inherent in this | |||
problem. In particular, user agents which cache credentials are | problem. In particular, user agents which cache credentials are | |||
encouraged to provide a readily accessible mechanism for discarding | encouraged to provide a readily accessible mechanism for discarding | |||
cached credentials under user control. | cached credentials under user control. | |||
15.7 Proxies and Caching | 15.7 Proxies and Caching | |||
By their very nature, HTTP proxies are men-in-the-middle, and | By their very nature, HTTP proxies are men-in-the-middle, and | |||
represent an opportunity for man-in-the-middle attacks. Compromise of | represent an opportunity for man-in-the-middle attacks. Compromise | |||
the systems on which the proxies run can result in serious security | of the systems on which the proxies run can result in serious | |||
and privacy problems. Proxies have access to security-related | security and privacy problems. Proxies have access to security- | |||
information, personal information about individual users and | related information, personal information about individual users and | |||
organizations, and proprietary information belonging to users and | organizations, and proprietary information belonging to users and | |||
content providers. A compromised proxy, or a proxy implemented or | content providers. A compromised proxy, or a proxy implemented or | |||
configured without regard to security and privacy considerations, | configured without regard to security and privacy considerations, | |||
might be used in the commission of a wide range of potential attacks. | might be used in the commission of a wide range of potential attacks. | |||
Proxy operators should protect the systems on which proxies run as | Proxy operators should protect the systems on which proxies run as | |||
they would protect any system that contains or transports sensitive | they would protect any system that contains or transports sensitive | |||
information. In particular, log information gathered at proxies often | information. In particular, log information gathered at proxies | |||
contains highly sensitive personal information, and/or information | often contains highly sensitive personal information, and/or | |||
about organizations. Log information should be carefully guarded, and | information about organizations. Log information should be carefully | |||
appropriate guidelines for use developed and followed. (Section | guarded, and appropriate guidelines for use developed and followed. | |||
15.1.1). | (section 15.1.1). | |||
Caching proxies provide additional potential vulnerabilities, since | Caching proxies provide additional potential vulnerabilities, since | |||
the contents of the cache represent an attractive target for | the contents of the cache represent an attractive target for | |||
malicious exploitation. Because cache contents persist after an HTTP | malicious exploitation. Because cache contents persist after an HTTP | |||
request is complete, an attack on the cache can reveal information | request is complete, an attack on the cache can reveal information | |||
long after a user believes that the information has been removed from | long after a user believes that the information has been removed from | |||
the network. Therefore, cache contents should be protected as | the network. Therefore, cache contents should be protected as | |||
sensitive information. | sensitive information. | |||
Proxy implementors should consider the privacy and security | Proxy implementors should consider the privacy and security | |||
skipping to change at page 156, line 32 | skipping to change at page 166, line 7 | |||
protect against a broad range of security and privacy attacks. Such | protect against a broad range of security and privacy attacks. Such | |||
cryptography is beyond the scope of the HTTP/1.1 specification. | cryptography is beyond the scope of the HTTP/1.1 specification. | |||
15.7.1 Denial of Service Attacks on Proxies | 15.7.1 Denial of Service Attacks on Proxies | |||
They exist. They are hard to defend against. Research continues. | They exist. They are hard to defend against. Research continues. | |||
Beware. | Beware. | |||
16 Acknowledgments | 16 Acknowledgments | |||
16.1 (RFC2616) | ||||
This specification makes heavy use of the augmented BNF and generic | This specification makes heavy use of the augmented BNF and generic | |||
constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it | constructs defined by David H. Crocker for RFC 822 [9]. Similarly, | |||
reuses many of the definitions provided by Nathaniel Borenstein and | it reuses many of the definitions provided by Nathaniel Borenstein | |||
Ned Freed for MIME [7]. We hope that their inclusion in this | and Ned Freed for MIME [7]. We hope that their inclusion in this | |||
specification will help reduce past confusion over the relationship | specification will help reduce past confusion over the relationship | |||
between HTTP and Internet mail message formats. | between HTTP and Internet mail message formats. | |||
The HTTP protocol has evolved considerably over the years. It has | The HTTP protocol has evolved considerably over the years. It has | |||
benefited from a large and active developer community--the many | benefited from a large and active developer community--the many | |||
people who have participated on the www-talk mailing list--and it is | people who have participated on the www-talk mailing list--and it is | |||
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 mentioned, | participating in the HTTP-WG. In addition to those already | |||
the following individuals have contributed to this specification: | mentioned, the following individuals have contributed to this | |||
specification: | ||||
Gary Adams Ross Patterson | Gary Adams Ross Patterson | |||
Harald Tveit Alvestrand Albert Lunde | Harald Tveit Alvestrand Albert Lunde | |||
Keith Ball John C. Mallery | Keith Ball John C. Mallery | |||
Brian Behlendorf Jean-Philippe Martin-Flatin | Brian Behlendorf Jean-Philippe Martin-Flatin | |||
Paul Burchard Mitra | Paul Burchard Mitra | |||
Maurizio Codogno David Morris | Maurizio Codogno David Morris | |||
Mike Cowlishaw Gavin Nicol | Mike Cowlishaw Gavin Nicol | |||
Roman Czyborra Bill Perry | Roman Czyborra Bill Perry | |||
Michael A. Dolan Jeffrey Perry | Michael A. Dolan Jeffrey Perry | |||
skipping to change at page 158, line 10 | skipping to change at page 168, line 5 | |||
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen | |||
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and | |||
Larry Masinter for their help. And thanks go particularly to Jeff | Larry Masinter for their help. And thanks go particularly to Jeff | |||
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. | Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. | |||
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik | |||
Frystyk implemented RFC 2068 early, and we wish to thank them for the | Frystyk implemented RFC 2068 early, and we wish to thank them for the | |||
discovery of many of the problems that this document attempts to | discovery of many of the problems that this document attempts to | |||
rectify. | rectify. | |||
17 References | 16.2 (This Document) | |||
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC | This document is based on [50], which was authored by Roy T. | |||
1766, March 1995. | Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, | |||
Larry Masinter, Paul J. Leach and Tim Berners-Lee. | ||||
17. References | ||||
17.1. References | ||||
[1] Alvestrand, H., "Tags for the Identification of Languages", | ||||
RFC 1766, March 1995. | ||||
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, | |||
D. and B. Alberti, "The Internet Gopher Protocol (a distributed | D., and B. Alberti, "The Internet Gopher Protocol (a | |||
document search and retrieval protocol)", RFC 1436, March 1993. | distributed document search and retrieval protocol)", RFC 1436, | |||
March 1993. | ||||
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC | [3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A | |||
1630, June 1994. | Unifying Syntax for the Expression of Names and Addresses of | |||
Objects on the Network as used in the World-Wide Web", | ||||
RFC 1630, June 1994. | ||||
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource | [4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform | |||
Locators (URL)", RFC 1738, December 1994. | Resource Locators (URL)", RFC 1738, December 1994. | |||
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - | [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - | |||
2.0", RFC 1866, November 1995. | 2.0", RFC 1866, November 1995. | |||
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer | [6] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Protocol -- HTTP/1.0", RFC 1945, May 1996. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message Bodies", | Extensions (MIME) Part One: Format of Internet Message Bodies", | |||
RFC 2045, November 1996. | RFC 2045, November 1996. | |||
[8] Braden, R., "Requirements for Internet Hosts -- Communication | [8] Braden, R., "Requirements for Internet Hosts - Application and | |||
Layers", STD 3, RFC 1123, October 1989. | Support", STD 3, RFC 1123, October 1989. | |||
[9] Crocker, D., "Standard for The Format of ARPA Internet Text | [9] Crocker, D., "Standard for the format of ARPA Internet text | |||
Messages", STD 11, RFC 822, August 1982. | messages", STD 11, RFC 822, August 1982. | |||
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., | [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, | |||
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype | R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol | |||
Functional Specification," (v1.5), Thinking Machines | Prototype Functional Specification (v1.5)", Thinking Machines | |||
Corporation, April 1990. | Corporation, April 1990. | |||
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, | [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, | |||
June 1995. | June 1995. | |||
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET | [12] Horton, M. and R. Adams, "Standard for interchange of USENET | |||
Messages", RFC 1036, December 1987. | messages", RFC 1036, December 1987. | |||
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC | [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", | |||
977, February 1986. | RFC 977, February 1986. | |||
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part | |||
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | Three: Message Header Extensions for Non-ASCII Text", RFC 2047, | |||
November 1996. | November 1996. | |||
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC | [15] Masinter, L. and E. Nebel, "Form-based File Upload in HTML", | |||
1867, November 1995. | RFC 1867, November 1995. | |||
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, | |||
August 1982. | August 1982. | |||
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, | [17] Postel, J., "Media Type Registration Procedure", RFC 1590, | |||
November 1996. | March 1994. | |||
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC | [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, | |||
959, October 1985. | RFC 959, October 1985. | |||
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, | [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, | |||
October 1994. | RFC 1700, October 1994. | |||
[20] Sollins, K. and L. Masinter, "Functional Requirements for | [20] Masinter, L. and K. Sollins, "Functional Requirements for | |||
Uniform Resource Names", RFC 1737, December 1994. | Uniform Resource Names", RFC 1737, December 1994. | |||
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for | [21] American National Standards Institute, "Coded Character Set -- | |||
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. | 7-bit American Standard Code for Information Interchange", | |||
ANSI X3.4, 1986. | ||||
[22] ISO-8859. International Standard -- Information Processing -- | [22] International Organization for Standardization, "Information | |||
8-bit Single-Byte Coded Graphic Character Sets -- | technology - 8-bit single byte coded graphic - character sets", | |||
Part 1: Latin alphabet No. 1, ISO-8859-1:1987. | 1987-1990. | |||
Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. | ||||
Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. | ||||
Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. | ||||
Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. | ||||
Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. | ||||
Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. | ||||
Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. | ||||
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. | ||||
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin | |||
1864, October 1995. | alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. | |||
3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, | ||||
1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part | ||||
6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/ | ||||
Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew | ||||
alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO- | ||||
8859-9, 1990. | ||||
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC | [23] Myers, J. and M. Rose, "The Content-MD5 Header Field", | |||
1900, February 1996. | RFC 1864, October 1995. | |||
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC | [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", | |||
1952, May 1996. | RFC 1900, February 1996. | |||
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP | [25] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. | |||
Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, | ||||
Dec. 1995. Slightly revised version of paper in Proc. 2nd | ||||
International WWW Conference '94: Mosaic and the Web, Oct. 1994, | ||||
which is available at | ||||
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat | ||||
ency.html. | ||||
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP | Randers-Pehrson, "GZIP file format specification version 4.3", | |||
Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, | RFC 1952, May 1996. | |||
ISI Research Report ISI/RR-98-463, (original report dated Aug. | ||||
1996), USC/Information Sciences Institute, August 1998. | [26] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", | |||
Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995. | ||||
Slightly revised version of paper in Proc. 2nd 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>. | ||||
[27] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of HTTP | ||||
Performance", ISI Research Report ISI/RR-98-463 (original | ||||
report dated Aug.1996), Aug 1998, | ||||
<http://www.isi.edu/touch/pubs/http-perf96/>. | ||||
[28] Mills, D., "Network Time Protocol (Version 3) Specification, | [28] Mills, D., "Network Time Protocol (Version 3) Specification, | |||
Implementation and Analysis", RFC 1305, March 1992. | Implementation", RFC 1305, March 1992. | |||
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification | [29] Deutsch, P., "DEFLATE Compressed Data Format Specification | |||
version 1.3", RFC 1951, May 1996. | version 1.3", RFC 1951, May 1996. | |||
[30] S. Spero, "Analysis of HTTP Performance Problems," | [30] Spero, S., "Analysis of HTTP Performance Problems", | |||
http://sunsite.unc.edu/mdma-release/http-prob.html. | <http://sunsite.unc.edu/mdma-release/http-prob.html>. | |||
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format | [31] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format | |||
Specification version 3.3", RFC 1950, May 1996. | Specification version 3.3", RFC 1950, May 1996. | |||
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |||
Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: | Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : | |||
Digest Access Authentication", RFC 2069, January 1997. | Digest Access Authentication", RFC 2069, January 1997. | |||
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. | [33] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", | |||
2068, January 1997. | RFC 2068, January 1997. | |||
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[35] Troost, R. and Dorner, S., "Communicating Presentation | [35] Troost, R. and S. Dorner, "Communicating Presentation | |||
Information in Internet Messages: The Content-Disposition | Information in Internet Messages: The Content-Disposition | |||
Header", RFC 1806, June 1995. | Header", RFC 1806, June 1995. | |||
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and | [36] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use and | |||
Interpretation of HTTP Version Numbers", RFC 2145, May 1997. | Interpretation of HTTP Version Numbers", RFC 2145, May 1997. | |||
[jg639] | ||||
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February | [37] Palme, J., "Common Internet Message Headers", RFC 2076, | |||
1997. [jg640] | February 1997. | |||
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and | ||||
ISO-10646", RFC 2279, January 1998. [jg641] | ||||
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., | [38] Yergeau, F., "UTF-8, a transformation format of ISO 10646", | |||
Lie, H., and C. Lilley. "Network Performance Effects of | RFC 2279, January 1998. | |||
HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes | ||||
France, September 1997.[jg642] | [39] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. | |||
Lilley, "Network Performance Effects of HTTP/1.1, CSS1, and | ||||
PNG", Proceedings of ACM SIGCOMM '97, Cannes France , Sep 1997. | ||||
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Two: Media Types", RFC 2046, November | Extensions (MIME) Part Two: Media Types", RFC 2046, | |||
1996. [jg643] | November 1996. | |||
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", | [41] Alvestrand, H., "IETF Policy on Character Sets and Languages", | |||
BCP 18, RFC 2277, January 1998. [jg644] | BCP 18, RFC 2277, January 1998. | |||
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource | [42] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Identifiers (URI): Generic Syntax and Semantics", RFC 2396, | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |||
August 1998. [jg645] | August 1998. | |||
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., | |||
Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP | Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: | |||
Authentication: Basic and Digest Access Authentication", RFC | Basic and Digest Access Authentication", RFC 2617, June 1999. | |||
2617, June 1999. [jg646] | ||||
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy | [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy | |||
servers," Work in Progress. [jg647] | servers", Work in Progress. | |||
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of | |||
Aggregate Documents, such as HTML (MHTML)", RFC 2110, March | Aggregate Documents, such as HTML (MHTML)", RFC 2110, | |||
1997. | March 1997. | |||
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP | [46] Bradner, S., "The Internet Standards Process -- Revision 3", | |||
9, RFC 2026, October 1996. | October 1996. | |||
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol | [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol | |||
(HTCPCP/1.0)", RFC 2324, 1 April 1998. | (HTCPCP/1.0)", RFC 2324, April 1998. | |||
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part Five: Conformance Criteria and Examples", | Extensions (MIME) Part Five: Conformance Criteria and | |||
RFC 2049, November 1996. | Examples", RFC 2049, November 1996. | |||
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation | ||||
Information in Internet Messages: The Content-Disposition Header | ||||
Field", RFC 2183, August 1997. | ||||
18 Authors' Addresses | ||||
Roy T. Fielding | ||||
Information and Computer Science | ||||
University of California, Irvine | ||||
Irvine, CA 92697-3425, USA | ||||
Fax: +1 (949) 824-1715 | ||||
EMail: fielding@ics.uci.edu | ||||
James Gettys | ||||
World Wide Web Consortium | ||||
MIT Laboratory for Computer Science | ||||
545 Technology Square | ||||
Cambridge, MA 02139, USA | ||||
Fax: +1 (617) 258 8682 | ||||
EMail: jg@w3.org | ||||
Jeffrey C. Mogul | ||||
Western Research Laboratory | ||||
Compaq Computer Corporation | ||||
250 University Avenue | ||||
Palo Alto, California, 94305, USA | ||||
EMail: mogul@wrl.dec.com | ||||
Henrik Frystyk Nielsen | ||||
World Wide Web Consortium | ||||
MIT Laboratory for Computer Science | ||||
545 Technology Square | ||||
Cambridge, MA 02139, USA | ||||
Fax: +1 (617) 258 8682 | ||||
EMail: frystyk@w3.org | ||||
Larry Masinter | [49] Troost, R., Dorner, S., and K. Moore, "Communicating | |||
Xerox Corporation | Presentation Information in Internet Messages: The Content- | |||
3333 Coyote Hill Road | Disposition Header Field", RFC 2183, August 1997. | |||
Palo Alto, CA 94034, USA | ||||
EMail: masinter@parc.xerox.com | 17.2. Normative References | |||
Paul J. Leach | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052, USA | ||||
EMail: paulle@microsoft.com | [50] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |||
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | ||||
HTTP/1.1", RFC 2616, June 1999. | ||||
Tim Berners-Lee | URIs | |||
Director, World Wide Web Consortium | ||||
MIT Laboratory for Computer Science | ||||
545 Technology Square | ||||
Cambridge, MA 02139, USA | ||||
Fax: +1 (617) 258 8682 | [51] <mailto:ietf-http-wg@w3.org> | |||
EMail: timbl@w3.org | ||||
19 Appendices | [52] <mailto:ietf-http-wg-request@w3.org?subject=subscribe> | |||
19.1 Internet Media Type message/http and application/http | Appendix A Internet Media Type message/http and application/http | |||
In addition to defining the HTTP/1.1 protocol, this document serves | In addition to defining the HTTP/1.1 protocol, this document serves | |||
as the specification for the Internet media type "message/http" and | as the specification for the Internet media type "message/http" and | |||
"application/http". The message/http type can be used to enclose a | "application/http". The message/http type can be used to enclose a | |||
single HTTP request or response message, provided that it obeys the | single HTTP request or response message, provided that it obeys the | |||
MIME restrictions for all "message" types regarding line length and | MIME restrictions for all "message" types regarding line length and | |||
encodings. The application/http type can be used to enclose a | encodings. The application/http type can be used to enclose a | |||
pipeline of one or more HTTP request or response messages (not | pipeline of one or more HTTP request or response messages (not | |||
intermixed). The following is to be registered with IANA [17]. | intermixed). The following is to be registered with IANA [17]. | |||
skipping to change at page 164, line 19 | skipping to change at page 174, line 17 | |||
In addition to defining the HTTP/1.1 protocol, this document serves | In addition to defining the HTTP/1.1 protocol, this document serves | |||
as the specification for the Internet media type "message/http" and | as the specification for the Internet media type "message/http" and | |||
"application/http". The message/http type can be used to enclose a | "application/http". The message/http type can be used to enclose a | |||
single HTTP request or response message, provided that it obeys the | single HTTP request or response message, provided that it obeys the | |||
MIME restrictions for all "message" types regarding line length and | MIME restrictions for all "message" types regarding line length and | |||
encodings. The application/http type can be used to enclose a | encodings. The application/http type can be used to enclose a | |||
pipeline of one or more HTTP request or response messages (not | pipeline of one or more HTTP request or response messages (not | |||
intermixed). The following is to be registered with IANA [17]. | intermixed). The following is to be registered with IANA [17]. | |||
Media Type name: message | Media Type name: message | |||
Media subtype name: http | Media subtype name: http | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed message | ||||
(e.g., "1.1"). If not present, the version can be | version: The HTTP-Version number of the enclosed message (e.g., | |||
determined from the first line of the body. | "1.1"). If not present, the version can be determined from the | |||
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 | present, the type can be determined from the first line of the | |||
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 | Media Type name: application | |||
Media subtype name: http | Media subtype name: http | |||
Required parameters: none | Required parameters: none | |||
Optional parameters: version, msgtype | Optional parameters: version, msgtype | |||
version: The HTTP-Version number of the enclosed messages | ||||
(e.g., "1.1"). If not present, the version can be | version: The HTTP-Version number of the enclosed messages (e.g., | |||
determined from the first line of the body. | "1.1"). If not present, the version can be determined from the | |||
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 | present, the type can be determined from the first line of the | |||
line of the body. | body. | |||
Encoding considerations: HTTP messages enclosed by this type | ||||
are in "binary" format; use of an appropriate | Encoding considerations: HTTP messages enclosed by this type are in | |||
Content-Transfer-Encoding is required when | "binary" format; use of an appropriate Content-Transfer-Encoding | |||
transmitted via E-mail. | is required when transmitted via E-mail. | |||
Security considerations: none | Security considerations: none | |||
19.2 Internet Media Type multipart/byteranges | Appendix B Internet Media Type multipart/byteranges | |||
When an HTTP 206 (Partial Content) response message includes the | When an HTTP 206 (Partial Content) response message includes the | |||
content of multiple ranges (a response to a request for multiple | content of multiple ranges (a response to a request for multiple non- | |||
non-overlapping ranges), these are transmitted as a multipart | overlapping ranges), these are transmitted as a multipart message- | |||
message-body. The media type for this purpose is called | body. The media type for this purpose is called "multipart/ | |||
"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 | Media Type name: multipart | |||
Media subtype name: byteranges | Media 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 | |||
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 | |||
skipping to change at page 165, line 47 | skipping to change at page 177, line 5 | |||
...the first range... | ...the first range... | |||
--THIS_STRING_SEPARATES | --THIS_STRING_SEPARATES | |||
Content-type: application/pdf | Content-type: application/pdf | |||
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 | 2. Although RFC 2046 [40] permits the boundary string to be quoted, | |||
quoted, some existing implementations handle a quoted boundary | some existing implementations handle a quoted boundary string | |||
string incorrectly. | incorrectly. | |||
3) A number of browsers and servers were coded to an early draft | 3. A number of browsers and servers were coded to an early draft of | |||
of the byteranges specification to use a media type of | the byteranges specification to use a media type of multipart/ | |||
multipart/x-byteranges, which is almost, but not quite | x-byteranges, which is almost, but not quite compatible with the | |||
compatible with the version documented in HTTP/1.1. | version documented in HTTP/1.1. | |||
19.3 Tolerant Applications | Appendix C Tolerant Applications | |||
Although this document specifies the requirements for the generation | Although this document specifies the requirements for the generation | |||
of HTTP/1.1 messages, not all applications will be correct in their | of HTTP/1.1 messages, not all applications will be correct in their | |||
implementation. We therefore recommend that operational applications | implementation. We therefore recommend that operational applications | |||
be tolerant of deviations whenever those deviations can be | be tolerant of deviations whenever those deviations can be | |||
interpreted unambiguously. | interpreted unambiguously. | |||
Clients SHOULD be tolerant in parsing the Status-Line and servers | Clients SHOULD be tolerant in parsing the Status-Line and servers | |||
tolerant when parsing the Request-Line. In particular, they SHOULD | tolerant when parsing the Request-Line. In particular, they SHOULD | |||
accept any amount of SP or HT characters between fields, even though | accept any amount of SP or HT characters between fields, even though | |||
skipping to change at page 166, line 40 | skipping to change at page 178, line 31 | |||
The character set of an entity-body SHOULD be labeled as the lowest | The character set of an entity-body SHOULD be labeled as the lowest | |||
common denominator of the character codes used within that body, with | common denominator of the character codes used within that body, with | |||
the exception that not labeling the entity is preferred over labeling | the exception that not labeling the entity is preferred over labeling | |||
the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 | the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 | |||
and 3.4.1. | and 3.4.1. | |||
Additional rules for requirements on parsing and encoding of dates | Additional rules for requirements on parsing and encoding of dates | |||
and other potential problems with date encodings include: | and other potential problems with date encodings include: | |||
- HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date | |||
which appears to be more than 50 years in the future is in fact | which appears to be more than 50 years in the future is in fact in | |||
in the past (this helps solve the "year 2000" problem). | the past (this helps solve the "year 2000" problem). | |||
- An HTTP/1.1 implementation MAY internally represent a parsed | o An HTTP/1.1 implementation MAY internally represent a parsed | |||
Expires date as earlier than the proper value, but MUST NOT | Expires date as earlier than the proper value, but MUST NOT | |||
internally represent a parsed Expires date as later than the | internally represent a parsed Expires date as later than the | |||
proper value. | proper value. | |||
- All expiration-related calculations MUST be done in GMT. The | o All expiration-related calculations MUST be done in GMT. The | |||
local time zone MUST NOT influence the calculation or comparison | local time zone MUST NOT influence the calculation or comparison | |||
of an age or expiration time. | of an age or expiration time. | |||
- If an HTTP header incorrectly carries a date value with a time | o If an HTTP header incorrectly carries a date value with a time | |||
zone other than GMT, it MUST be converted into GMT using the | zone other than GMT, it MUST be converted into GMT using the most | |||
most conservative possible conversion. | conservative possible conversion. | |||
19.4 Differences Between HTTP Entities and RFC 2045 Entities | Appendix D Differences Between HTTP Entities and RFC 2045 Entities | |||
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC | |||
822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to | |||
allow entities to be transmitted in an open variety of | allow entities to be transmitted in an open variety of | |||
representations and with extensible mechanisms. However, RFC 2045 | representations and with extensible mechanisms. However, RFC 2045 | |||
discusses mail, and HTTP has a few features that are different from | discusses mail, and HTTP has a few features that are different from | |||
those described in RFC 2045. These differences were carefully chosen | those described in RFC 2045. These differences were carefully chosen | |||
to optimize performance over binary connections, to allow greater | to optimize performance over binary connections, to allow greater | |||
freedom in the use of new media types, to make date comparisons | freedom in the use of new media types, to make date comparisons | |||
easier, and to acknowledge the practice of some early HTTP servers | easier, and to acknowledge the practice of some early HTTP servers | |||
and clients. | and clients. | |||
This appendix describes specific areas where HTTP differs from RFC | This appendix describes specific areas where HTTP differs from RFC | |||
2045. Proxies and gateways to strict MIME environments SHOULD be | 2045. Proxies and gateways to strict MIME environments SHOULD be | |||
aware of these differences and provide the appropriate conversions | aware of these differences and provide the appropriate conversions | |||
where necessary. Proxies and gateways from MIME environments to HTTP | where necessary. Proxies and gateways from MIME environments to HTTP | |||
also need to be aware of the differences because some conversions | also need to be aware of the differences because some conversions | |||
might be required. | might be required. | |||
19.4.1 MIME-Version | D.1 MIME-Version | |||
HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY | HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages | |||
include a single MIME-Version general-header field to indicate what | MAY include a single MIME-Version general-header field to indicate | |||
version of the MIME protocol was used to construct the message. Use | what version of the MIME protocol was used to construct the message. | |||
of the MIME-Version header field indicates that the message is in | Use of the MIME-Version header field indicates that the message is in | |||
full compliance with the MIME protocol (as defined in RFC 2045[7]). | full compliance with the MIME protocol (as defined in RFC 2045[7]). | |||
Proxies/gateways are responsible for ensuring full compliance (where | Proxies/gateways are responsible for ensuring full compliance (where | |||
possible) when exporting HTTP messages to strict MIME environments. | possible) when exporting HTTP messages to strict MIME environments. | |||
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT | |||
MIME version "1.0" is the default for use in HTTP/1.1. However, | MIME version "1.0" is the default for use in HTTP/1.1. However, | |||
HTTP/1.1 message parsing and semantics are defined by this document | HTTP/1.1 message parsing and semantics are defined by this document | |||
and not the MIME specification. | and not the MIME specification. | |||
19.4.2 Conversion to Canonical Form | D.2 Conversion to Canonical Form | |||
RFC 2045 [7] requires that an Internet mail entity be converted to | RFC 2045 [7] requires that an Internet mail entity be converted to | |||
canonical form prior to being transferred, as described in section 4 | canonical form prior to being transferred, as described in section 4 | |||
of RFC 2049 [48]. Section 3.7.1 of this document describes the forms | of RFC 2049 [48]. section 3.7.1 of this document describes the forms | |||
allowed for subtypes of the "text" media type when transmitted over | allowed for subtypes of the "text" media type when transmitted over | |||
HTTP. RFC 2046 requires that content with a type of "text" represent | HTTP. RFC 2046 requires that content with a type of "text" represent | |||
line breaks as CRLF and forbids the use of CR or LF outside of line | line breaks as CRLF and forbids the use of CR or LF outside of line | |||
break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a | break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate | |||
line break within text content when a message is transmitted over | a line break within text content when a message is transmitted over | |||
HTTP. | HTTP. | |||
Where it is possible, a proxy or gateway from HTTP to a strict MIME | Where it is possible, a proxy or gateway from HTTP to a strict MIME | |||
environment SHOULD translate all line breaks within the text media | environment SHOULD translate all line breaks within the text media | |||
types described in section 3.7.1 of this document to the RFC 2049 | types described in section 3.7.1 of this document to the RFC 2049 | |||
canonical form of CRLF. Note, however, that this might be complicated | canonical form of CRLF. Note, however, that this might be | |||
by the presence of a Content-Encoding and by the fact that HTTP | complicated by the presence of a Content-Encoding and by the fact | |||
allows the use of some character sets which do not use octets 13 and | that HTTP allows the use of some character sets which do not use | |||
10 to represent CR and LF, as is the case for some multi-byte | octets 13 and 10 to represent CR and LF, as is the case for some | |||
character sets. | multi-byte character sets. | |||
Implementors should note that conversion will break any cryptographic | Implementors should note that conversion will break any cryptographic | |||
checksums applied to the original content unless the original content | checksums applied to the original content unless the original content | |||
is already in canonical form. Therefore, the canonical form is | is already in canonical form. Therefore, the canonical form is | |||
recommended for any content that uses such checksums in HTTP. | recommended for any content that uses such checksums in HTTP. | |||
19.4.3 Conversion of Date Formats | D.3 Conversion of Date Formats | |||
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to | HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to | |||
simplify the process of date comparison. Proxies and gateways from | simplify the process of date comparison. Proxies and gateways from | |||
other protocols SHOULD ensure that any Date header field present in a | other protocols SHOULD ensure that any Date header field present in a | |||
message conforms to one of the HTTP/1.1 formats and rewrite the date | message conforms to one of the HTTP/1.1 formats and rewrite the date | |||
if necessary. | if necessary. | |||
19.4.4 Introduction of Content-Encoding | D.4 Introduction of Content-Encoding | |||
RFC 2045 does not include any concept equivalent to HTTP/1.1's | RFC 2045 does not include any concept equivalent to HTTP/1.1's | |||
Content-Encoding header field. Since this acts as a modifier on the | Content-Encoding header field. Since this acts as a modifier on the | |||
media type, proxies and gateways from HTTP to MIME-compliant | media type, proxies and gateways from HTTP to MIME-compliant | |||
protocols MUST either change the value of the Content-Type header | protocols MUST either change the value of the Content-Type header | |||
field or decode the entity-body before forwarding the message. (Some | field or decode the entity-body before forwarding the message. (Some | |||
experimental applications of Content-Type for Internet mail have used | experimental applications of Content-Type for Internet mail have used | |||
a media-type parameter of ";conversions=<content-coding>" to perform | a media-type parameter of ";conversions=<content-coding>" to perform | |||
a function equivalent to Content-Encoding. However, this parameter is | a function equivalent to Content-Encoding. However, this parameter | |||
not part of RFC 2045.) | is not part of RFC 2045). | |||
19.4.5 No Content-Transfer-Encoding | D.5 No Content-Transfer-Encoding | |||
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC | HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC | |||
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST | 2045. Proxies and gateways from MIME-compliant protocols to HTTP | |||
remove any non-identity CTE ("quoted-printable" or "base64") encoding | MUST remove any non-identity CTE ("quoted-printable" or "base64") | |||
prior to delivering the response message to an HTTP client. | encoding prior to delivering the response message to an HTTP client. | |||
Proxies and gateways from HTTP to MIME-compliant protocols are | Proxies and gateways from HTTP to MIME-compliant protocols are | |||
responsible for ensuring that the message is in the correct format | responsible for ensuring that the message is in the correct format | |||
and encoding for safe transport on that protocol, where "safe | and encoding for safe transport on that protocol, where "safe | |||
transport" is defined by the limitations of the protocol being used. | transport" is defined by the limitations of the protocol being used. | |||
Such a proxy or gateway SHOULD label the data with an appropriate | Such a proxy or gateway SHOULD label the data with an appropriate | |||
Content-Transfer-Encoding if doing so will improve the likelihood of | Content-Transfer-Encoding if doing so will improve the likelihood of | |||
safe transport over the destination protocol. | safe transport over the destination protocol. | |||
19.4.6 Introduction of Transfer-Encoding | D.6 Introduction of Transfer-Encoding | |||
HTTP/1.1 introduces the Transfer-Encoding header field (section | HTTP/1.1 introduces the Transfer-Encoding header field | |||
14.41). Proxies/gateways MUST remove any transfer-coding prior to | (section 14.41). Proxies/gateways MUST remove any transfer-coding | |||
forwarding a message via a MIME-compliant protocol. | prior to forwarding a message via a MIME-compliant protocol. | |||
A process for decoding the "chunked" transfer-coding (section 3.6) | A process for decoding the "chunked" transfer-coding (section 3.6) | |||
can be represented in pseudo-code as: | can be represented in pseudo-code as: | |||
length := 0 | length := 0 | |||
read chunk-size, chunk-extension (if any) and CRLF | read chunk-size, chunk-extension (if any) and CRLF | |||
while (chunk-size > 0) { | while (chunk-size > 0) { | |||
read chunk-data and CRLF | read chunk-data and CRLF | |||
append chunk-data to entity-body | append chunk-data to entity-body | |||
length := length + chunk-size | length := length + chunk-size | |||
read chunk-size and CRLF | read chunk-size and CRLF | |||
} | } | |||
read entity-header | read entity-header | |||
while (entity-header not empty) { | while (entity-header not empty) { | |||
append entity-header to existing header fields | append entity-header to existing header fields | |||
read entity-header | read entity-header | |||
} | } | |||
Content-Length := length | Content-Length := length | |||
Remove "chunked" from Transfer-Encoding | Remove "chunked" from Transfer-Encoding | |||
19.4.7 MHTML and Line Length Limitations | D.7 MHTML and Line Length Limitations | |||
HTTP implementations which share code with MHTML [45] implementations | HTTP implementations which share code with MHTML [45] implementations | |||
need to be aware of MIME line length limitations. Since HTTP does not | need to be aware of MIME line length limitations. Since HTTP does | |||
have this limitation, HTTP does not fold long lines. MHTML messages | not have this limitation, HTTP does not fold long lines. MHTML | |||
being transported by HTTP follow all conventions of MHTML, including | messages being transported by HTTP follow all conventions of MHTML, | |||
line length limitations and folding, canonicalization, etc., since | including line length limitations and folding, canonicalization, | |||
HTTP transports all message-bodies as payload (see section 3.7.2) and | etc., since HTTP transports all message-bodies as payload (see | |||
does not interpret the content or any MIME header lines that might be | section 3.7.2) and does not interpret the content or any MIME header | |||
contained therein. | lines that might be contained therein. | |||
19.5 Additional Features | Appendix E Additional Features | |||
RFC 1945 and RFC 2068 document protocol elements used by some | RFC 1945 and RFC 2068 document protocol elements used by some | |||
existing HTTP implementations, but not consistently and correctly | existing HTTP implementations, but not consistently and correctly | |||
across most HTTP/1.1 applications. Implementors are advised to be | across most HTTP/1.1 applications. Implementors are advised to be | |||
aware of these features, but cannot rely upon their presence in, or | aware of these features, but cannot rely upon their presence in, or | |||
interoperability with, other HTTP/1.1 applications. Some of these | interoperability with, other HTTP/1.1 applications. Some of these | |||
describe proposed experimental features, and some describe features | describe proposed experimental features, and some describe features | |||
that experimental deployment found lacking that are now addressed in | that experimental deployment found lacking that are now addressed in | |||
the base HTTP/1.1 specification. | the base HTTP/1.1 specification. | |||
A number of other headers, such as Content-Disposition and Title, | A number of other headers, such as Content-Disposition and Title, | |||
from SMTP and MIME are also often implemented (see RFC 2076 [37]). | from SMTP and MIME are also often implemented (see RFC 2076 [37]). | |||
19.5.1 Content-Disposition | E.1 Content-Disposition | |||
The Content-Disposition response-header field has been proposed as a | The Content-Disposition response-header field has been proposed as a | |||
means for the origin server to suggest a default filename if the user | means for the origin server to suggest a default filename if the user | |||
requests that the content is saved to a file. This usage is derived | requests that the content is saved to a file. This usage is derived | |||
from the definition of Content-Disposition in RFC 1806 [35]. | from the definition of Content-Disposition in RFC 1806 [35]. | |||
content-disposition = "Content-Disposition" ":" | content-disposition = "Content-Disposition" ":" | |||
disposition-type *( ";" disposition-parm ) | disposition-type *( ";" disposition-parm ) | |||
disposition-type = "attachment" | disp-extension-token | disposition-type = "attachment" | disp-extension-token | |||
disposition-parm = filename-parm | disp-extension-parm | disposition-parm = filename-parm | disp-extension-parm | |||
filename-parm = "filename" "=" quoted-string | filename-parm = "filename" "=" quoted-string | |||
disp-extension-token = token | disp-extension-token = token | |||
disp-extension-parm = token "=" ( token | quoted-string ) | disp-extension-parm = token "=" ( token | quoted-string ) | |||
An example is | An example is | |||
Content-Disposition: attachment; filename="fname.ext" | Content-Disposition: attachment; filename="fname.ext" | |||
The receiving user agent SHOULD NOT respect any directory path | The receiving user agent SHOULD NOT respect any directory path | |||
information present in the filename-parm parameter, which is the only | information present in the filename-parm parameter, which is the only | |||
parameter believed to apply to HTTP implementations at this time. The | parameter believed to apply to HTTP implementations at this time. | |||
filename SHOULD be treated as a terminal component only. | The filename SHOULD be treated as a terminal component only. | |||
If this header is used in a response with the application/octet- | If this header is used in a response with the application/ | |||
stream content-type, the implied suggestion is that the user agent | octet-stream content-type, the implied suggestion is that the user | |||
should not display the response, but directly enter a `save response | agent should not display the response, but directly enter a `save | |||
as...' dialog. | response as...' dialog. | |||
See section 15.5 for Content-Disposition security issues. | See section 15.5 for Content-Disposition security issues. | |||
19.6 Compatibility with Previous Versions | Appendix F Compatibility with Previous Versions | |||
It is beyond the scope of a protocol specification to mandate | It is beyond the scope of a protocol specification to mandate | |||
compliance with previous versions. HTTP/1.1 was deliberately | compliance with previous versions. HTTP/1.1 was deliberately | |||
designed, however, to make supporting previous versions easy. It is | designed, however, to make supporting previous versions easy. It is | |||
worth noting that, at the time of composing this specification | worth noting that, at the time of composing this specification | |||
(1996), we would expect commercial HTTP/1.1 servers to: | (1996), we would expect commercial HTTP/1.1 servers to: | |||
- recognize the format of the Request-Line for HTTP/0.9, 1.0, and | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and | |||
1.1 requests; | 1.1 requests; | |||
- understand any valid request in the format of HTTP/0.9, 1.0, or | ||||
o understand any valid request in the format of HTTP/0.9, 1.0, or | ||||
1.1; | 1.1; | |||
- respond appropriately with a message in the same major version | o respond appropriately with a message in the same major version | |||
used by the client. | used by the client. | |||
And we would expect HTTP/1.1 clients to: | And we would expect HTTP/1.1 clients to: | |||
- recognize the format of the Status-Line for HTTP/1.0 and 1.1 | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 | |||
responses; | responses; | |||
- understand any valid response in the format of HTTP/0.9, 1.0, or | o understand any valid response in the format of HTTP/0.9, 1.0, or | |||
1.1. | 1.1. | |||
For most implementations of HTTP/1.0, each connection is established | For most implementations of HTTP/1.0, each connection is established | |||
by the client prior to the request and closed by the server after | by the client prior to the request and closed by the server after | |||
sending the response. Some implementations implement the Keep-Alive | sending the response. Some implementations implement the Keep-Alive | |||
version of persistent connections described in section 19.7.1 of RFC | version of persistent connections described in section 19.7.1 of RFC | |||
2068 [33]. | 2068 [33]. | |||
19.6.1 Changes from HTTP/1.0 | F.1 Changes from HTTP/1.0 | |||
This section summarizes major differences between versions HTTP/1.0 | This section summarizes major differences between versions HTTP/1.0 | |||
and HTTP/1.1. | and HTTP/1.1. | |||
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP | F.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP | |||
Addresses | Addresses | |||
The requirements that clients and servers support the Host request- | The requirements that clients and servers support the Host request- | |||
header, report an error if the Host request-header (section 14.23) is | header, report an error if the Host request-header (section 14.23) is | |||
missing from an HTTP/1.1 request, and accept absolute URIs (section | missing from an HTTP/1.1 request, and accept absolute URIs (section | |||
5.1.2) are among the most important changes defined by this | 5.1.2) are among the most important changes defined by this | |||
specification. | specification. | |||
Older HTTP/1.0 clients assumed a one-to-one relationship of IP | Older HTTP/1.0 clients assumed a one-to-one relationship of IP | |||
addresses and servers; there was no other established mechanism for | addresses and servers; there was no other established mechanism for | |||
distinguishing the intended server of a request than the IP address | distinguishing the intended server of a request than the IP address | |||
to which that request was directed. The changes outlined above will | to which that request was directed. The changes outlined above will | |||
allow the Internet, once older HTTP clients are no longer common, to | allow the Internet, once older HTTP clients are no longer common, to | |||
support multiple Web sites from a single IP address, greatly | support multiple Web sites from a single IP address, greatly | |||
simplifying large operational Web servers, where allocation of many | simplifying large operational Web servers, where allocation of many | |||
IP addresses to a single host has created serious problems. The | IP addresses to a single host has created serious problems. The | |||
Internet will also be able to recover the IP addresses that have been | Internet will also be able to recover the IP addresses that have been | |||
allocated for the sole purpose of allowing special-purpose domain | allocated for the sole purpose of allowing special-purpose domain | |||
names to be used in root-level HTTP URLs. Given the rate of growth of | names to be used in root-level HTTP URLs. Given the rate of growth | |||
the Web, and the number of servers already deployed, it is extremely | of the Web, and the number of servers already deployed, it is | |||
important that all implementations of HTTP (including updates to | extremely important that all implementations of HTTP (including | |||
existing HTTP/1.0 applications) correctly implement these | updates to existing HTTP/1.0 applications) correctly implement these | |||
requirements: | requirements: | |||
- Both clients and servers MUST support the Host request-header. | o Both clients and servers MUST support the Host request-header. | |||
- A client that sends an HTTP/1.1 request MUST send a Host header. | o A client that sends an HTTP/1.1 request MUST send a Host header. | |||
- Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 | |||
request does not include a Host request-header. | request does not include a Host request-header. | |||
- Servers MUST accept absolute URIs. | o Servers MUST accept absolute URIs. | |||
19.6.2 Compatibility with HTTP/1.0 Persistent Connections | F.2 Compatibility with HTTP/1.0 Persistent Connections | |||
Some clients and servers might wish to be compatible with some | Some clients and servers might wish to be compatible with some | |||
previous implementations of persistent connections in HTTP/1.0 | previous implementations of persistent connections in HTTP/1.0 | |||
clients and servers. Persistent connections in HTTP/1.0 are | clients and servers. Persistent connections in HTTP/1.0 are | |||
explicitly negotiated as they are not the default behavior. HTTP/1.0 | explicitly negotiated as they are not the default behavior. HTTP/1.0 | |||
experimental implementations of persistent connections are faulty, | experimental implementations of persistent connections are faulty, | |||
and the new facilities in HTTP/1.1 are designed to rectify these | and the new facilities in HTTP/1.1 are designed to rectify these | |||
problems. The problem was that some existing 1.0 clients may be | problems. The problem was that some existing 1.0 clients may be | |||
sending Keep-Alive to a proxy server that doesn't understand | sending Keep-Alive to a proxy server that doesn't understand | |||
Connection, which would then erroneously forward it to the next | Connection, which would then erroneously forward it to the next | |||
skipping to change at page 172, line 44 | skipping to change at page 185, line 5 | |||
connections, so that prohibition is clearly unacceptable. Therefore, | connections, so that prohibition is clearly unacceptable. Therefore, | |||
we need some other mechanism for indicating a persistent connection | we need some other mechanism for indicating a persistent connection | |||
is desired, which is safe to use even when talking to an old proxy | is desired, which is safe to use even when talking to an old proxy | |||
that ignores Connection. Persistent connections are the default for | that ignores Connection. Persistent connections are the default for | |||
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for | |||
declaring non-persistence. See section 14.10. | declaring non-persistence. See section 14.10. | |||
The original HTTP/1.0 form of persistent connections (the Connection: | The original HTTP/1.0 form of persistent connections (the Connection: | |||
Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] | Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] | |||
19.6.3 Changes from RFC 2068 | F.3 Changes from RFC 2068 | |||
This specification has been carefully audited to correct and | This specification has been carefully audited to correct and | |||
disambiguate key word usage; RFC 2068 had many problems in respect to | disambiguate key word usage; RFC 2068 had many problems in respect to | |||
the conventions laid out in RFC 2119 [34]. | the conventions laid out in RFC 2119 [34]. | |||
Clarified which error code should be used for inbound server failures | Clarified which error code should be used for inbound server failures | |||
(e.g. DNS failures). (Section 10.5.5). | (e.g. DNS failures). (section 10.5.5). | |||
CREATE had a race that required an Etag be sent when a resource is | CREATE had a race that required an Etag be sent when a resource is | |||
first created. (Section 10.2.2). | first created. (section 10.2.2). | |||
Content-Base was deleted from the specification: it was not | Content-Base was deleted from the specification: it was not | |||
implemented widely, and there is no simple, safe way to introduce it | implemented widely, and there is no simple, safe way to introduce it | |||
without a robust extension mechanism. In addition, it is used in a | without a robust extension mechanism. In addition, it is used in a | |||
similar, but not identical fashion in MHTML [45]. | similar, but not identical fashion in MHTML [45]. | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. (Sections | to straighten out exactly how message lengths are computed. | |||
3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16) | |||
A content-coding of "identity" was introduced, to solve problems | A content-coding of "identity" was introduced, to solve problems | |||
discovered in caching. (section 3.5) | discovered in caching. (section 3.5) | |||
Quality Values of zero should indicate that "I don't want something" | Quality Values of zero should indicate that "I don't want something" | |||
to allow clients to refuse a representation. (Section 3.9) | to allow clients to refuse a representation. (section 3.9) | |||
The use and interpretation of HTTP version numbers has been clarified | The use and interpretation of HTTP version numbers has been clarified | |||
by RFC 2145. Require proxies to upgrade requests to highest protocol | by RFC 2145. Require proxies to upgrade requests to highest protocol | |||
version they support to deal with problems discovered in HTTP/1.0 | version they support to deal with problems discovered in HTTP/1.0 | |||
implementations (Section 3.1) | implementations (section 3.1) | |||
Charset wildcarding is introduced to avoid explosion of character set | Charset wildcarding is introduced to avoid explosion of character set | |||
names in accept headers. (Section 14.2) | names in accept headers. (section 14.2) | |||
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage | A case was missed in the Cache-Control model of HTTP/1.1; s-maxage | |||
was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, | was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, | |||
14.9.3) | 14.9.3) | |||
The Cache-Control: max-age directive was not properly defined for | The Cache-Control: max-age directive was not properly defined for | |||
responses. (Section 14.9.3) | responses. (section 14.9.3) | |||
There are situations where a server (especially a proxy) does not | There are situations where a server (especially a proxy) does not | |||
know the full length of a response but is capable of serving a | know the full length of a response but is capable of serving a | |||
byterange request. We therefore need a mechanism to allow byteranges | byterange request. We therefore need a mechanism to allow byteranges | |||
with a content-range not indicating the full length of the message. | with a content-range not indicating the full length of the message. | |||
(Section 14.16) | ||||
(section 14.16) | ||||
Range request responses would become very verbose if all meta-data | Range request responses would become very verbose if all meta-data | |||
were always returned; by allowing the server to only send needed | were always returned; by allowing the server to only send needed | |||
headers in a 206 response, this problem can be avoided. (Section | headers in a 206 response, this problem can be avoided. (Section | |||
10.2.7, 13.5.3, and 14.27) | 10.2.7, 13.5.3, and 14.27) | |||
Fix problem with unsatisfiable range requests; there are two cases: | Fix problem with unsatisfiable range requests; there are two cases: | |||
syntactic problems, and range doesn't exist in the document. The 416 | syntactic problems, and range doesn't exist in the document. The 416 | |||
status code was needed to resolve this ambiguity needed to indicate | status code was needed to resolve this ambiguity needed to indicate | |||
an error for a byte range request that falls outside of the actual | an error for a byte range request that falls outside of the actual | |||
contents of a document. (Section 10.4.17, 14.16) | contents of a document. (Section 10.4.17, 14.16) | |||
Rewrite of message transmission requirements to make it much harder | Rewrite of message transmission requirements to make it much harder | |||
for implementors to get it wrong, as the consequences of errors here | for implementors to get it wrong, as the consequences of errors here | |||
can have significant impact on the Internet, and to deal with the | can have significant impact on the Internet, and to deal with the | |||
following problems: | following problems: | |||
skipping to change at page 174, line 16 | skipping to change at page 186, line 24 | |||
status code was needed to resolve this ambiguity needed to indicate | status code was needed to resolve this ambiguity needed to indicate | |||
an error for a byte range request that falls outside of the actual | an error for a byte range request that falls outside of the actual | |||
contents of a document. (Section 10.4.17, 14.16) | contents of a document. (Section 10.4.17, 14.16) | |||
Rewrite of message transmission requirements to make it much harder | Rewrite of message transmission requirements to make it much harder | |||
for implementors to get it wrong, as the consequences of errors here | for implementors to get it wrong, as the consequences of errors here | |||
can have significant impact on the Internet, and to deal with the | can have significant impact on the Internet, and to deal with the | |||
following problems: | following problems: | |||
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where | 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where | |||
this was incorrectly placing a requirement on the behavior of | this was incorrectly placing a requirement on the behavior of an | |||
an implementation of a future version of HTTP/1.x | implementation of a future version of HTTP/1.x | |||
2. Made it clear that user-agents should retry requests, not | 2. Made it clear that user-agents should retry requests, not | |||
"clients" in general. | "clients" in general. | |||
3. Converted requirements for clients to ignore unexpected 100 | 3. Converted requirements for clients to ignore unexpected 100 | |||
(Continue) responses, and for proxies to forward 100 responses, | (Continue) responses, and for proxies to forward 100 responses, | |||
into a general requirement for 1xx responses. | into a general requirement for 1xx responses. | |||
4. Modified some TCP-specific language, to make it clearer that | 4. Modified some TCP-specific language, to make it clearer that non- | |||
non-TCP transports are possible for HTTP. | TCP transports are possible for HTTP. | |||
5. Require that the origin server MUST NOT wait for the request | 5. Require that the origin server MUST NOT wait for the request body | |||
body before it sends a required 100 (Continue) response. | before it sends a required 100 (Continue) response. | |||
6. Allow, rather than require, a server to omit 100 (Continue) if | 6. Allow, rather than require, a server to omit 100 (Continue) if it | |||
it has already seen some of the request body. | has already seen some of the request body. | |||
7. Allow servers to defend against denial-of-service attacks and | 7. Allow servers to defend against denial-of-service attacks and | |||
broken clients. | broken clients. | |||
This change adds the Expect header and 417 status code. The message | This change adds the Expect header and 417 status code. The message | |||
transmission requirements fixes are in sections 8.2, 10.4.18, | transmission requirements fixes are in sections 8.2, 10.4.18, | |||
8.1.2.2, 13.11, and 14.20. | 8.1.2.2, 13.11, and 14.20. | |||
Proxies should be able to add Content-Length when appropriate. | Proxies should be able to add Content-Length when appropriate. | |||
(Section 13.5.2) | (section 13.5.2) | |||
Clean up confusion between 403 and 404 responses. (Section 10.4.4, | Clean up confusion between 403 and 404 responses. (Section 10.4.4, | |||
10.4.5, and 10.4.11) | 10.4.5, and 10.4.11) | |||
Warnings could be cached incorrectly, or not updated appropriately. | Warnings could be cached incorrectly, or not updated appropriately. | |||
(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning | |||
also needed to be a general header, as PUT or other methods may have | also needed to be a general header, as PUT or other methods may have | |||
need for it in requests. | need for it in requests. | |||
Transfer-coding had significant problems, particularly with | Transfer-coding had significant problems, particularly with | |||
interactions with chunked encoding. The solution is that transfer- | interactions with chunked encoding. The solution is that transfer- | |||
skipping to change at page 175, line 24 | skipping to change at page 188, line 5 | |||
clients.(Section 3.6, 3.6.1, and 14.39) | clients.(Section 3.6, 3.6.1, and 14.39) | |||
The PATCH, LINK, UNLINK methods were defined but not commonly | The PATCH, LINK, UNLINK methods were defined but not commonly | |||
implemented in previous versions of this specification. See RFC 2068 | implemented in previous versions of this specification. See RFC 2068 | |||
[33]. | [33]. | |||
The Alternates, Content-Version, Derived-From, Link, URI, Public and | The Alternates, Content-Version, Derived-From, Link, URI, Public and | |||
Content-Base header fields were defined in previous versions of this | Content-Base header fields were defined in previous versions of this | |||
specification, but not commonly implemented. See RFC 2068 [33]. | specification, but not commonly implemented. See RFC 2068 [33]. | |||
20 Index | Appendix G Change Log (to be removed by RFC Editor before publication) | |||
Please see the PostScript version of this RFC for the INDEX. | G.1 Since RFC2616 | |||
21. Full Copyright Statement | Update Authors. Add Editorial Note and Acknowledgements (containing | |||
the original RFC2616 authors). Add "Normative References", | ||||
containing just RFC2616 for now. | ||||
Copyright (C) The Internet Society (1999). All Rights Reserved. | Appendix H Open issues (to be removed by RFC Editor prior to | |||
publication) | ||||
This document and translations of it may be copied and furnished to | H.1 rfc2616bis | |||
others, and derivative works that comment on or otherwise explain it | ||||
or assist in its implementation may be prepared, copied, published | ||||
and distributed, in whole or in part, without restriction of any | ||||
kind, provided that the above copyright notice and this paragraph are | ||||
included on all such copies and derivative works. However, this | ||||
document itself may not be modified in any way, such as by removing | ||||
the copyright notice or references to the Internet Society or other | ||||
Internet organizations, except as needed for the purpose of | ||||
developing Internet standards in which case the procedures for | ||||
copyrights defined in the Internet Standards process must be | ||||
followed, or as required to translate it into languages other than | ||||
English. | ||||
The limited permissions granted above are perpetual and will not be | Type: edit | |||
revoked by the Internet Society or its successors or assigns. | ||||
This document and the information contained herein is provided on an | julian.reschke@greenbytes.de (2006-10-10): Umbrella issue for changes | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | with respect to the revision process itself. | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Acknowledgement | H.2 edit | |||
Funding for the RFC Editor function is currently provided by the | Type: edit | |||
Internet Society. | ||||
julian.reschke@greenbytes.de (2006-08-10): Umbrella issue for | ||||
editorial fixes/enhancements. | ||||
Index | ||||
1 | ||||
100 Continue (status code) 65 | ||||
101 Switching Protocols (status code) 65 | ||||
2 | ||||
200 OK (status code) 66 | ||||
201 Created (status code) 66 | ||||
202 Accepted (status code) 66 | ||||
203 Non-Authoritative Information (status code) 67 | ||||
204 No Content (status code) 67 | ||||
205 Reset Content (status code) 67 | ||||
206 Partial Content (status code) 68 | ||||
3 | ||||
300 Multiple Choices (status code) 69 | ||||
301 Moved Permanently (status code) 69 | ||||
302 Found (status code) 70 | ||||
303 See Other (status code) 70 | ||||
304 Not Modified (status code) 71 | ||||
305 Use Proxy (status code) 71 | ||||
306 (Unused) (status code) 72 | ||||
307 Temporary Redirect (status code) 72 | ||||
4 | ||||
400 Bad Request (status code) 73 | ||||
401 Unauthorized (status code) 73 | ||||
402 Payment Required (status code) 73 | ||||
403 Forbidden (status code) 73 | ||||
404 Not Found (status code) 73 | ||||
405 Method Not Allowed (status code) 74 | ||||
406 Not Acceptable (status code) 74 | ||||
407 Proxy Authentication Required (status code) 74 | ||||
408 Request Timeout (status code) 75 | ||||
409 Conflict (status code) 75 | ||||
410 Gone (status code) 75 | ||||
411 Length Required (status code) 76 | ||||
412 Precondition Failed (status code) 76 | ||||
413 Request Entity Too Large (status code) 76 | ||||
414 Request-URI Too Long (status code) 76 | ||||
415 Unsupported Media Type (status code) 76 | ||||
416 Requested Range Not Satisfiable (status code) 76 | ||||
417 Expectation Failed (status code) 77 | ||||
5 | ||||
500 Internal Server Error (status code) 77 | ||||
501 Not Implemented (status code) 77 | ||||
502 Bad Gateway (status code) 77 | ||||
503 Service Unavailable (status code) 78 | ||||
504 Gateway Timeout (status code) 78 | ||||
505 HTTP Version Not Supported (status code) 78 | ||||
A | ||||
Accept header 109 | ||||
Accept-Charset header 111 | ||||
Accept-Encoding header 111 | ||||
Accept-Language header 113 | ||||
Accept-Ranges header 114 | ||||
Age header 114 | ||||
age 14 | ||||
Allow header 115 | ||||
Authorization header 116 | ||||
C | ||||
Cache Directives | ||||
max-age 121, 123 | ||||
max-stale 121 | ||||
min-fresh 121 | ||||
must-revalidate 123 | ||||
no-cache 119 | ||||
no-store 119 | ||||
no-transform 125 | ||||
only-if-cached 123 | ||||
private 118 | ||||
proxy-revalidate 124 | ||||
public 118 | ||||
s-maxage 120 | ||||
cache 13 | ||||
Cache-Control header 116 | ||||
cacheable 13 | ||||
client 12 | ||||
compress 27 | ||||
CONNECT method 64 | ||||
Connection header 126 | ||||
connection 11 | ||||
content negotiation 12 | ||||
Content-Encoding header 127 | ||||
Content-Language header 128 | ||||
Content-Length header 128 | ||||
Content-Location header 129 | ||||
Content-MD5 header 130 | ||||
Content-Range header 131 | ||||
Content-Type header 133 | ||||
D | ||||
Date header 133 | ||||
deflate 28 | ||||
DELETE method 63 | ||||
downstream 15 | ||||
E | ||||
entity 11 | ||||
ETag header 135 | ||||
Expect header 135 | ||||
Expires header 136 | ||||
explicit expiration time 14 | ||||
F | ||||
first-hand 13 | ||||
fresh 14 | ||||
freshness lifetime 14 | ||||
From header 137 | ||||
G | ||||
gateway 13 | ||||
GET method 60 | ||||
Grammar | ||||
Accept 109 | ||||
Accept-Charset 111 | ||||
Accept-Encoding 111 | ||||
accept-extension 109 | ||||
Accept-Language 113 | ||||
accept-params 109 | ||||
Accept-Ranges 114 | ||||
acceptable-ranges 114 | ||||
Age 115 | ||||
age-value 115 | ||||
Allow 115 | ||||
ALPHA 20 | ||||
asctime-date 25 | ||||
attribute 28 | ||||
Authorization 116 | ||||
byte-content-range-spec 131 | ||||
byte-range-resp-spec 131 | ||||
byte-range-set 147 | ||||
byte-range-spec 147 | ||||
byte-ranges-specifier 147 | ||||
bytes-unit 35 | ||||
Cache-Control 117 | ||||
cache-directive 117 | ||||
cache-extension 117 | ||||
cache-request-directive 117 | ||||
cache-response-directive 117 | ||||
CHAR 20 | ||||
charset 26 | ||||
chunk 29 | ||||
chunk-data 29 | ||||
chunk-ext-name 29 | ||||
chunk-ext-val 29 | ||||
chunk-extension 29 | ||||
chunk-size 29 | ||||
Chunked-Body 29 | ||||
codings 111 | ||||
comment 21 | ||||
Connection 126 | ||||
connection-token 126 | ||||
content-coding 27 | ||||
content-disposition 182 | ||||
Content-Encoding 127 | ||||
Content-Language 128 | ||||
Content-Length 128 | ||||
Content-Location 129 | ||||
Content-MD5 130 | ||||
Content-Range 131 | ||||
content-range-spec 131 | ||||
Content-Type 133 | ||||
CR 20 | ||||
CRLF 20 | ||||
ctext 21 | ||||
CTL 20 | ||||
Date 133 | ||||
date1 25 | ||||
date2 25 | ||||
date3 25 | ||||
delta-seconds 26 | ||||
DIGIT 20 | ||||
disp-extension-parm 182 | ||||
disp-extension-token 182 | ||||
disposition-parm 182 | ||||
disposition-type 182 | ||||
entity-body 49 | ||||
entity-header 49 | ||||
entity-tag 34 | ||||
ETag 135 | ||||
Expect 135 | ||||
expect-params 135 | ||||
expectation 135 | ||||
expectation-extension 135 | ||||
Expires 136 | ||||
extension-code 46 | ||||
extension-header 49 | ||||
extension-method 41 | ||||
extension-pragma 145 | ||||
field-content 36 | ||||
field-name 36 | ||||
field-value 36 | ||||
filename-parm 182 | ||||
first-byte-pos 147 | ||||
From 137 | ||||
general-header 39 | ||||
generic-message 36 | ||||
HEX 21 | ||||
Host 138 | ||||
HT 20 | ||||
HTTP-date 25 | ||||
HTTP-message 36 | ||||
HTTP-Version 22 | ||||
http_URL 23 | ||||
If-Match 138 | ||||
If-Modified-Since 139 | ||||
If-None-Match 141 | ||||
If-Range 142 | ||||
If-Unmodified-Since 143 | ||||
instance-length 131 | ||||
language-range 113 | ||||
language-tag 34 | ||||
last-byte-pos 147 | ||||
last-chunk 29 | ||||
Last-Modified 143 | ||||
LF 20 | ||||
LOALPHA 20 | ||||
Location 144 | ||||
LWS 20 | ||||
Max-Forwards 145 | ||||
md5-digest 130 | ||||
media-range 109 | ||||
media-type 31 | ||||
message-body 37 | ||||
message-header 36 | ||||
Method 41 | ||||
MIME-Version 179 | ||||
month 25 | ||||
OCTET 20 | ||||
opaque-tag 34 | ||||
other-range-unit 35 | ||||
parameter 28 | ||||
Pragma 145 | ||||
pragma-directive 145 | ||||
primary-tag 34 | ||||
product 33 | ||||
product-version 33 | ||||
protocol-name 155 | ||||
protocol-version 155 | ||||
Proxy-Authenticate 146 | ||||
Proxy-Authorization 146 | ||||
pseudonym 155 | ||||
qdtext 21 | ||||
quoted-pair 21 | ||||
quoted-string 21 | ||||
qvalue 33 | ||||
Range 148 | ||||
range-unit 35 | ||||
ranges-specifier 147 | ||||
Reason-Phrase 46 | ||||
received-by 155 | ||||
received-protocol 155 | ||||
Referer 149 | ||||
Request 41 | ||||
request-header 44 | ||||
Request-Line 41 | ||||
Request-URI 42 | ||||
Response 45 | ||||
response-header 48 | ||||
Retry-After 150 | ||||
rfc850-date 25 | ||||
rfc1123-date 25 | ||||
separators 21 | ||||
Server 150 | ||||
SP 20 | ||||
start-line 36 | ||||
Status-Code 46 | ||||
Status-Line 45 | ||||
subtag 34 | ||||
subtype 31 | ||||
suffix-byte-range-spec 147 | ||||
suffix-length 147 | ||||
t-codings 151 | ||||
TE 151 | ||||
TEXT 20 | ||||
time 25 | ||||
token 21 | ||||
Trailer 152 | ||||
trailer 29 | ||||
transfer-coding 28 | ||||
Transfer-Encoding 152 | ||||
transfer-extension 28 | ||||
type 31 | ||||
UPALPHA 20 | ||||
Upgrade 153 | ||||
User-Agent 154 | ||||
value 28 | ||||
Vary 154 | ||||
Via 155 | ||||
warn-agent 157 | ||||
warn-code 157 | ||||
warn-date 157 | ||||
warn-text 157 | ||||
Warning 157 | ||||
warning-value 157 | ||||
weak 34 | ||||
weekday 25 | ||||
wkday 25 | ||||
WWW-Authenticate 159 | ||||
gzip 27 | ||||
H | ||||
HEAD method 60 | ||||
Headers | ||||
Accept 109 | ||||
Accept-Charset 111 | ||||
Accept-Encoding 111 | ||||
Accept-Language 113 | ||||
Accept-Ranges 114 | ||||
Age 114 | ||||
Allow 115 | ||||
Authorization 116 | ||||
Cache-Control 116 | ||||
Connection 126 | ||||
Content-Encoding 127 | ||||
Content-Language 128 | ||||
Content-Length 128 | ||||
Content-Location 129 | ||||
Content-MD5 130 | ||||
Content-Range 131 | ||||
Content-Type 133 | ||||
Date 133 | ||||
ETag 135 | ||||
Expect 135 | ||||
Expires 136 | ||||
From 137 | ||||
Host 137 | ||||
If-Match 138 | ||||
If-Modified-Since 139 | ||||
If-None-Match 141 | ||||
If-Range 142 | ||||
If-Unmodified-Since 143 | ||||
Last-Modified 143 | ||||
Location 144 | ||||
Max-Forwards 144 | ||||
Pragma 145 | ||||
Proxy-Authenticate 146 | ||||
Proxy-Authorization 146 | ||||
Range 147 | ||||
Referer 149 | ||||
Retry-After 150 | ||||
Server 150 | ||||
TE 151 | ||||
Trailer 152 | ||||
Transfer-Encoding 152 | ||||
Upgrade 153 | ||||
User-Agent 154 | ||||
Vary 154 | ||||
Via 155 | ||||
Warning 157 | ||||
WWW-Authenticate 159 | ||||
heuristic expiration time 14 | ||||
Host header 137 | ||||
I | ||||
identity 28 | ||||
If-Match header 138 | ||||
If-Modified-Since header 139 | ||||
If-None-Match header 141 | ||||
If-Range header 142 | ||||
If-Unmodified-Since header 143 | ||||
inbound 15 | ||||
L | ||||
Last-Modified header 143 | ||||
Location header 144 | ||||
M | ||||
max-age | ||||
Cache Directive 121, 123 | ||||
Max-Forwards header 144 | ||||
max-stale | ||||
Cache Directive 121 | ||||
message 11 | ||||
Methods | ||||
CONNECT 64 | ||||
DELETE 63 | ||||
GET 60 | ||||
HEAD 60 | ||||
OPTIONS 59 | ||||
POST 61 | ||||
PUT 62 | ||||
TRACE 63 | ||||
min-fresh | ||||
Cache Directive 121 | ||||
must-revalidate | ||||
Cache Directive 123 | ||||
N | ||||
no-cache | ||||
Cache Directive 119 | ||||
no-store | ||||
Cache Directive 119 | ||||
no-transform | ||||
Cache Directive 125 | ||||
O | ||||
only-if-cached | ||||
Cache Directive 123 | ||||
OPTIONS method 59 | ||||
origin server 12 | ||||
outbound 15 | ||||
P | ||||
POST method 61 | ||||
Pragma header 145 | ||||
private | ||||
Cache Directive 118 | ||||
proxy 12 | ||||
Proxy-Authenticate header 146 | ||||
Proxy-Authorization header 146 | ||||
proxy-revalidate | ||||
Cache Directive 124 | ||||
public | ||||
Cache Directive 118 | ||||
PUT method 62 | ||||
R | ||||
Range header 147 | ||||
Referer header 149 | ||||
representation 11 | ||||
request 11 | ||||
resource 11 | ||||
response 11 | ||||
Retry-After header 150 | ||||
S | ||||
s-maxage | ||||
Cache Directive 120 | ||||
semantically transparent 14 | ||||
Server header 150 | ||||
server 12 | ||||
stale 14 | ||||
Status Codes | ||||
100 Continue 65 | ||||
101 Switching Protocols 65 | ||||
200 OK 66 | ||||
201 Created 66 | ||||
202 Accepted 66 | ||||
203 Non-Authoritative Information 67 | ||||
204 No Content 67 | ||||
205 Reset Content 67 | ||||
206 Partial Content 68 | ||||
300 Multiple Choices 69 | ||||
301 Moved Permanently 69 | ||||
302 Found 70 | ||||
303 See Other 70 | ||||
304 Not Modified 71 | ||||
305 Use Proxy 71 | ||||
306 (Unused) 72 | ||||
307 Temporary Redirect 72 | ||||
400 Bad Request 73 | ||||
401 Unauthorized 73 | ||||
402 Payment Required 73 | ||||
403 Forbidden 73 | ||||
404 Not Found 73 | ||||
405 Method Not Allowed 74 | ||||
406 Not Acceptable 74 | ||||
407 Proxy Authentication Required 74 | ||||
408 Request Timeout 75 | ||||
409 Conflict 75 | ||||
410 Gone 75 | ||||
411 Length Required 76 | ||||
412 Precondition Failed 76 | ||||
413 Request Entity Too Large 76 | ||||
414 Request-URI Too Long 76 | ||||
415 Unsupported Media Type 76 | ||||
416 Requested Range Not Satisfiable 76 | ||||
417 Expectation Failed 77 | ||||
500 Internal Server Error 77 | ||||
501 Not Implemented 77 | ||||
502 Bad Gateway 77 | ||||
503 Service Unavailable 78 | ||||
504 Gateway Timeout 78 | ||||
505 HTTP Version Not Supported 78 | ||||
T | ||||
TE header 151 | ||||
TRACE method 63 | ||||
Trailer header 152 | ||||
Transfer-Encoding header 152 | ||||
tunnel 13 | ||||
U | ||||
Upgrade header 153 | ||||
upstream 15 | ||||
user agent 12 | ||||
User-Agent header 154 | ||||
V | ||||
validator 14 | ||||
variant 12 | ||||
Vary header 154 | ||||
Via header 155 | ||||
W | ||||
Warning header 157 | ||||
WWW-Authenticate header 159 | ||||
Authors' Addresses | ||||
Yves Lafon | ||||
World Wide Web Consortium | ||||
2004, Route des Lucioles | ||||
Sophia Antipolis 06902 | ||||
France | ||||
Phone: +33 492387943 | ||||
Fax: +33 492387822 | ||||
Email: ylafon@w3.org | ||||
URI: http://www.w3.org/ | ||||
Julian F. Reschke | ||||
greenbytes GmbH | ||||
Hafenweg 16 | ||||
Muenster, NW 48155 | ||||
Germany | ||||
Phone: +49 251 2807760 | ||||
Fax: +49 251 2807761 | ||||
Email: julian.reschke@greenbytes.de | ||||
URI: http://greenbytes.de/tech/webdav/ | ||||
Full Copyright Statement | ||||
Copyright (C) The Internet Society (2006). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |