| rfc2616.txt |  | rfc2616-symrefs.txt |
--- | --- | --- | --- | ---
| Network Working Group R. Fielding |  | Network Working Group R. Fielding |
| Request for Comments: 2616 UC Irvine |  | Internet-Draft UC Irvine |
| Obsoletes: 2068 J. Gettys |  | Obsoletes: 2068 (if approved) J. Gettys |
| Category: Standards Track Compaq/W3C |  | Intended status: Standards Track Compaq/W3C |
| J. Mogul |  | Expires: December 3, 1999 J. Mogul |
| Compaq |  | Compaq |
| H. Frystyk |  | H. Frystyk |
| W3C/MIT |  | W3C/MIT |
| L. Masinter |  | L. Masinter |
| Xerox |  | Xerox |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Hypertext Transfer Protocol -- HTTP/1.1 |  | Hypertext Transfer Protocol -- HTTP/1.1 |
|  |  | rfc2616-symrefs |
| 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 December 3, 1999. |
| Copyright Notice |  | Copyright Notice |
| Copyright (C) The Internet Society (1999). All Rights Reserved. |  | Copyright (C) The IETF Trust (1999). |
| Abstract |  | Abstract |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. It is a generic, stateless, protocol which can be used for |  | systems. It is a generic, stateless, protocol which can be used for |
| many tasks beyond its use for hypertext, such as name servers and |  | many tasks beyond its use for hypertext, such as name servers and |
| distributed object management systems, through extension of its |  | distributed object management systems, through extension of its |
| request methods, error codes and headers [47]. A feature of HTTP is |  | request methods, error codes and headers [RFC2324]. A feature of |
| the typing and negotiation of data representation, allowing systems |  | HTTP is the typing and negotiation of data representation, allowing |
| to be built independently of the data being transferred. |  | systems to be built independently of the data being transferred. |
| HTTP has been in use by the World-Wide Web global information |  | HTTP has been in use by the World-Wide Web global information |
| initiative since 1990. This specification defines the protocol |  | initiative since 1990. This specification defines the protocol |
| referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. |  | referred to as "HTTP/1.1", and is an update to RFC 2068 [RFC2068]. |
|  |  | Editorial Note (To be removed by RFC Editor) |
|  |  | This version of the HTTP specification contains only XML processing |
|  |  | changes from [RFC2616] in internet-draft form for use in creating |
|  |  | diffs. |
| Table of Contents |  | Table of Contents |
| 1 Introduction ...................................................7 |  | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 1.1 Purpose......................................................7 |  | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 9 |
| 1.2 Requirements .................................................8 |  | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 |
| 1.3 Terminology ..................................................8 |  | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 |
| 1.4 Overall Operation ...........................................12 |  | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . 14 |
| 2 Notational Conventions and Generic Grammar ....................14 |  | 2. Notational Conventions and Generic Grammar . . . . . . . . . 16 |
| 2.1 Augmented BNF ...............................................14 |  | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 16 |
| 2.2 Basic Rules .................................................15 |  | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 18 |
| 3 Protocol Parameters ...........................................17 |  | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.1 HTTP Version ................................................17 |  | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 20 |
| 3.2 Uniform Resource Identifiers ................................18 |  | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 |
| 3.2.1 General Syntax ...........................................19 |  | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . 21 |
| 3.2.2 http URL .................................................19 |  | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . 22 |
| 3.2.3 URI Comparison ...........................................20 |  | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . 22 |
| 3.3 Date/Time Formats ...........................................20 |  | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . 23 |
| 3.3.1 Full Date ................................................20 |  | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . 23 |
| 3.3.2 Delta Seconds ............................................21 |  | 3.3.2. Delta Seconds . . . . . . . . . . . . . . . . . . . 24 |
| 3.4 Character Sets ..............................................21 |  | 3.4. Character Sets . . . . . . . . . . . . . . . . . . . . . 24 |
| 3.4.1 Missing Charset ..........................................22 |  | 3.4.1. Missing Charset . . . . . . . . . . . . . . . . . . 25 |
| 3.5 Content Codings .............................................23 |  | 3.5. Content Codings . . . . . . . . . . . . . . . . . . . . 25 |
| 3.6 Transfer Codings ............................................24 |  | 3.6. Transfer Codings . . . . . . . . . . . . . . . . . . . . 27 |
| 3.6.1 Chunked Transfer Coding ..................................25 |  | 3.6.1. Chunked Transfer Coding . . . . . . . . . . . . . . 28 |
| 3.7 Media Types .................................................26 |  | 3.7. Media Types . . . . . . . . . . . . . . . . . . . . . . 29 |
| 3.7.1 Canonicalization and Text Defaults .......................27 |  | 3.7.1. Canonicalization and Text Defaults . . . . . . . . . 30 |
| 3.7.2 Multipart Types ..........................................27 |  | 3.7.2. Multipart Types . . . . . . . . . . . . . . . . . . 30 |
| 3.8 Product Tokens ..............................................28 |  | 3.8. Product Tokens . . . . . . . . . . . . . . . . . . . . . 31 |
| 3.9 Quality Values ..............................................29 |  | 3.9. Quality Values . . . . . . . . . . . . . . . . . . . . . 32 |
| 3.10 Language Tags ...............................................29 |  | 3.10. Language Tags . . . . . . . . . . . . . . . . . . . . . 32 |
| 3.11 Entity Tags .................................................30 |  | 3.11. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 33 |
| 3.12 Range Units .................................................30 |  | 3.12. Range Units . . . . . . . . . . . . . . . . . . . . . . 33 |
| 4 HTTP Message ..................................................31 |  | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 4.1 Message Types ...............................................31 |  | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 |
| 4.2 Message Headers .............................................31 |  | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 34 |
| 4.3 Message Body ................................................32 |  | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 |
| 4.4 Message Length ..............................................33 |  | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 |
| 4.5 General Header Fields .......................................34 |  | 4.5. General Header Fields . . . . . . . . . . . . . . . . . 37 |
| 5 Request .......................................................35 |  | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1 Request-Line ................................................35 |  | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1.1 Method ...................................................36 |  | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . 38 |
| 5.1.2 Request-URI ..............................................36 |  | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . 39 |
| 5.2 The Resource Identified by a Request ........................38 |  | 5.2. The Resource Identified by a Request . . . . . . . . . . 40 |
| 5.3 Request Header Fields .......................................38 |  | 5.3. Request Header Fields . . . . . . . . . . . . . . . . . 41 |
| 6 Response ......................................................39 |  | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 6.1 Status-Line .................................................39 |  | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 42 |
| 6.1.1 Status Code and Reason Phrase ............................39 |  | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 |
| 6.2 Response Header Fields ......................................41 |  | 6.2. Response Header Fields . . . . . . . . . . . . . . . . . 45 |
| 7 Entity ........................................................42 |  | 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 |
| 7.1 Entity Header Fields ........................................42 |  | 7.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 46 |
| 7.2 Entity Body .................................................43 |  | 7.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 46 |
| 7.2.1 Type .....................................................43 |  | 7.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 46 |
| 7.2.2 Entity Length ............................................43 |  | 7.2.2. Entity Length . . . . . . . . . . . . . . . . . . . 47 |
| 8 Connections ...................................................44 |  | 8. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 47 |
| 8.1 Persistent Connections ......................................44 |  | 8.1. Persistent Connections . . . . . . . . . . . . . . . . . 47 |
| 8.1.1 Purpose ..................................................44 |  | 8.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . 47 |
| 8.1.2 Overall Operation ........................................45 |  | 8.1.2. Overall Operation . . . . . . . . . . . . . . . . . 48 |
| 8.1.3 Proxy Servers ............................................46 |  | 8.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . 49 |
| 8.1.4 Practical Considerations .................................46 |  | 8.1.4. Practical Considerations . . . . . . . . . . . . . . 50 |
| 8.2 Message Transmission Requirements ...........................47 |  | 8.2. Message Transmission Requirements . . . . . . . . . . . 51 |
| 8.2.1 Persistent Connections and Flow Control ..................47 |  | 8.2.1. Persistent Connections and Flow Control . . . . . . 51 |
| 8.2.2 Monitoring Connections for Error Status Messages .........48 |  | 8.2.2. Monitoring Connections for Error Status Messages . . 51 |
| 8.2.3 Use of the 100 (Continue) Status .........................48 |  | 8.2.3. Use of the 100 (Continue) Status . . . . . . . . . . 51 |
| 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 . . . . . . . . . . . . . . . . . . . . . 53 |
| 9.1 Safe and Idempotent Methods .................................51 |  | 9. Method Definitions . . . . . . . . . . . . . . . . . . . . . 54 |
| 9.1.1 Safe Methods .............................................51 |  | 9.1. Safe and Idempotent Methods . . . . . . . . . . . . . . 54 |
| 9.1.2 Idempotent Methods .......................................51 |  | 9.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 54 |
| 9.2 OPTIONS .....................................................52 |  | 9.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . 54 |
| 9.3 GET .........................................................53 |  | 9.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 55 |
| 9.4 HEAD ........................................................54 |  | 9.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . 56 |
| 9.5 POST ........................................................54 |  | 9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.6 PUT .........................................................55 |  | 9.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 57 |
| 9.7 DELETE ......................................................56 |  | 9.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 9.8 TRACE .......................................................56 |  | 9.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 9.9 CONNECT .....................................................57 |  | 9.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . 59 |
| 10 Status Code Definitions ......................................57 |  | 9.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . 60 |
| 10.1 Informational 1xx ...........................................57 |  | 10. Status Code Definitions . . . . . . . . . . . . . . . . . . . 60 |
| 10.1.1 100 Continue .............................................58 |  | 10.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 60 |
| 10.1.2 101 Switching Protocols ..................................58 |  | 10.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 61 |
| 10.2 Successful 2xx ..............................................58 |  | 10.1.2. 101 Switching Protocols . . . . . . . . . . . . . . 61 |
| 10.2.1 200 OK ...................................................58 |  | 10.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 61 |
| 10.2.2 201 Created ..............................................59 |  | 10.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 61 |
| 10.2.3 202 Accepted .............................................59 |  | 10.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . 62 |
| 10.2.4 203 Non-Authoritative Information ........................59 |  | 10.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 62 |
| 10.2.5 204 No Content ...........................................60 |  | 10.2.4. 203 Non-Authoritative Information . . . . . . . . . 62 |
| 10.2.6 205 Reset Content ........................................60 |  | 10.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . 63 |
| 10.2.7 206 Partial Content ......................................60 |  | 10.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . 63 |
| 10.3 Redirection 3xx .............................................61 |  | 10.2.7. 206 Partial Content . . . . . . . . . . . . . . . . 63 |
| 10.3.1 300 Multiple Choices .....................................61 |  | 10.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 64 |
| 10.3.2 301 Moved Permanently ....................................62 |  | 10.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 64 |
| 10.3.3 302 Found ................................................62 |  | 10.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 65 |
| 10.3.4 303 See Other ............................................63 |  | 10.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 65 |
| 10.3.5 304 Not Modified .........................................63 |  | 10.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 66 |
| 10.3.6 305 Use Proxy ............................................64 |  | 10.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 66 |
| 10.3.7 306 (Unused) .............................................64 |  | 10.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 67 |
| 10.3.8 307 Temporary Redirect ...................................65 |  | 10.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 67 |
| 10.4 Client Error 4xx ............................................65 |  | 10.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . 67 |
| 10.4.1 400 Bad Request .........................................65 |  | 10.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 68 |
| 10.4.2 401 Unauthorized ........................................66 |  | 10.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 68 |
| 10.4.3 402 Payment Required ....................................66 |  | 10.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 68 |
| 10.4.4 403 Forbidden ...........................................66 |  | 10.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 69 |
| 10.4.5 404 Not Found ...........................................66 |  | 10.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 69 |
| 10.4.6 405 Method Not Allowed ..................................66 |  | 10.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 69 |
| 10.4.7 406 Not Acceptable ......................................67 |  | 10.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 69 |
| 10.4.8 407 Proxy Authentication Required .......................67 |  | 10.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 69 |
| 10.4.9 408 Request Timeout .....................................67 |  | 10.4.8. 407 Proxy Authentication Required . . . . . . . . . 70 |
| 10.4.10 409 Conflict ............................................67 |  | 10.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 70 |
| 10.4.11 410 Gone ................................................68 |  | 10.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . 70 |
| 10.4.12 411 Length Required .....................................68 |  | 10.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 71 |
| 10.4.13 412 Precondition Failed .................................68 |  | 10.4.12. 411 Length Required . . . . . . . . . . . . . . . . 71 |
| 10.4.14 413 Request Entity Too Large ............................69 |  | 10.4.13. 412 Precondition Failed . . . . . . . . . . . . . . 71 |
| 10.4.15 414 Request-URI Too Long ................................69 |  | 10.4.14. 413 Request Entity Too Large . . . . . . . . . . . . 71 |
| 10.4.16 415 Unsupported Media Type ..............................69 |  | 10.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . 72 |
| 10.4.17 416 Requested Range Not Satisfiable .....................69 |  | 10.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . 72 |
| 10.4.18 417 Expectation Failed ..................................70 |  | 10.4.17. 416 Requested Range Not Satisfiable . . . . . . . . 72 |
| 10.5 Server Error 5xx ............................................70 |  | 10.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . 72 |
| 10.5.1 500 Internal Server Error ................................70 |  | 10.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 72 |
| 10.5.2 501 Not Implemented ......................................70 |  | 10.5.1. 500 Internal Server Error . . . . . . . . . . . . . 73 |
| 10.5.3 502 Bad Gateway ..........................................70 |  | 10.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 73 |
| 10.5.4 503 Service Unavailable ..................................70 |  | 10.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 73 |
| 10.5.5 504 Gateway Timeout ......................................71 |  | 10.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 73 |
| 10.5.6 505 HTTP Version Not Supported ...........................71 |  | 10.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 73 |
| 11 Access Authentication ........................................71 |  | 10.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . 74 |
| 12 Content Negotiation ..........................................71 |  | 11. Access Authentication . . . . . . . . . . . . . . . . . . . . 74 |
| 12.1 Server-driven Negotiation ...................................72 |  | 12. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 74 |
| 12.2 Agent-driven Negotiation ....................................73 |  | 12.1. Server-driven Negotiation . . . . . . . . . . . . . . . 75 |
| 12.3 Transparent Negotiation .....................................74 |  | 12.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . 76 |
| 13 Caching in HTTP ..............................................74 |  | 12.3. Transparent Negotiation . . . . . . . . . . . . . . . . 76 |
| 13.1.1 Cache Correctness ........................................75 |  | 13. Caching in HTTP . . . . . . . . . . . . . . . . . . . . . . . 77 |
| 13.1.2 Warnings .................................................76 |  | 13.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 |
| 13.1.3 Cache-control Mechanisms .................................77 |  | 13.1.1. Cache Correctness . . . . . . . . . . . . . . . . . 78 |
| 13.1.4 Explicit User Agent Warnings .............................78 |  | 13.1.2. Warnings . . . . . . . . . . . . . . . . . . . . . . 79 |
| 13.1.5 Exceptions to the Rules and Warnings .....................78 |  | 13.1.3. Cache-control Mechanisms . . . . . . . . . . . . . . 80 |
| 13.1.6 Client-controlled Behavior ...............................79 |  | 13.1.4. Explicit User Agent Warnings . . . . . . . . . . . . 80 |
| 13.2 Expiration Model ............................................79 |  | 13.1.5. Exceptions to the Rules and Warnings . . . . . . . . 81 |
| 13.2.1 Server-Specified Expiration ..............................79 |  | 13.1.6. Client-controlled Behavior . . . . . . . . . . . . . 81 |
| 13.2.2 Heuristic Expiration .....................................80 |  | 13.2. Expiration Model . . . . . . . . . . . . . . . . . . . . 82 |
| 13.2.3 Age Calculations .........................................80 |  | 13.2.1. Server-Specified Expiration . . . . . . . . . . . . 82 |
| 13.2.4 Expiration Calculations ..................................83 |  | 13.2.2. Heuristic Expiration . . . . . . . . . . . . . . . . 83 |
| 13.2.5 Disambiguating Expiration Values .........................84 |  | 13.2.3. Age Calculations . . . . . . . . . . . . . . . . . . 83 |
| 13.2.6 Disambiguating Multiple Responses ........................84 |  | 13.2.4. Expiration Calculations . . . . . . . . . . . . . . 85 |
| 13.3 Validation Model ............................................85 |  | 13.2.5. Disambiguating Expiration Values . . . . . . . . . . 86 |
| 13.3.1 Last-Modified Dates ......................................86 |  | 13.2.6. Disambiguating Multiple Responses . . . . . . . . . 87 |
| 13.3.2 Entity Tag Cache Validators ..............................86 |  | 13.3. Validation Model . . . . . . . . . . . . . . . . . . . . 87 |
| 13.3.3 Weak and Strong Validators ...............................86 |  | 13.3.1. Last-Modified Dates . . . . . . . . . . . . . . . . 88 |
| 13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89 |  | 13.3.2. Entity Tag Cache Validators . . . . . . . . . . . . 88 |
| 13.3.5 Non-validating Conditionals ..............................90 |  | 13.3.3. Weak and Strong Validators . . . . . . . . . . . . . 89 |
| 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 . . . . . . . . . . . . . . . . 91 |
| 13.5.1 End-to-end and Hop-by-hop Headers ........................92 |  | 13.3.5. Non-validating Conditionals . . . . . . . . . . . . 93 |
| 13.5.2 Non-modifiable Headers ...................................92 |  | 13.4. Response Cacheability . . . . . . . . . . . . . . . . . 93 |
| 13.5.3 Combining Headers ........................................94 |  | 13.5. Constructing Responses From Caches . . . . . . . . . . . 94 |
| 13.5.4 Combining Byte Ranges ....................................95 |  | 13.5.1. End-to-end and Hop-by-hop Headers . . . . . . . . . 94 |
| 13.6 Caching Negotiated Responses ................................95 |  | 13.5.2. Non-modifiable Headers . . . . . . . . . . . . . . . 95 |
| 13.7 Shared and Non-Shared Caches ................................96 |  | 13.5.3. Combining Headers . . . . . . . . . . . . . . . . . 96 |
| 13.8 Errors or Incomplete Response Cache Behavior ................97 |  | 13.5.4. Combining Byte Ranges . . . . . . . . . . . . . . . 97 |
| 13.9 Side Effects of GET and HEAD ................................97 |  | 13.6. Caching Negotiated Responses . . . . . . . . . . . . . . 98 |
| 13.10 Invalidation After Updates or Deletions ...................97 |  | 13.7. Shared and Non-Shared Caches . . . . . . . . . . . . . . 99 |
| 13.11 Write-Through Mandatory ...................................98 |  | 13.8. Errors or Incomplete Response Cache Behavior . . . . . . 99 |
| 13.12 Cache Replacement .........................................99 |  | 13.9. Side Effects of GET and HEAD . . . . . . . . . . . . . . 100 |
| 13.13 History Lists .............................................99 |  | 13.10. Invalidation After Updates or Deletions . . . . . . . . 100 |
| 14 Header Field Definitions ....................................100 |  | 13.11. Write-Through Mandatory . . . . . . . . . . . . . . . . 101 |
| 14.1 Accept .....................................................100 |  | 13.12. Cache Replacement . . . . . . . . . . . . . . . . . . . 101 |
| 14.2 Accept-Charset .............................................102 |  | 13.13. History Lists . . . . . . . . . . . . . . . . . . . . . 102 |
| 14.3 Accept-Encoding ............................................102 |  | 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 102 |
| 14.4 Accept-Language ............................................104 |  | 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 102 |
| 14.5 Accept-Ranges ..............................................105 |  | 14.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . 104 |
| 14.6 Age ........................................................106 |  | 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 105 |
| 14.7 Allow ......................................................106 |  | 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 106 |
| 14.8 Authorization ..............................................107 |  | 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 108 |
| 14.9 Cache-Control ..............................................108 |  | 14.6. Age . . . . . . . . . . . . . . . . . . . . . . . . . . 108 |
| 14.9.1 What is Cacheable .......................................109 |  | 14.7. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 109 |
| 14.9.2 What May be Stored by Caches ............................110 |  | 14.8. Authorization . . . . . . . . . . . . . . . . . . . . . 109 |
| 14.9.3 Modifications of the Basic Expiration Mechanism .........111 |  | 14.9. Cache-Control . . . . . . . . . . . . . . . . . . . . . 110 |
| 14.9.4 Cache Revalidation and Reload Controls ..................113 |  | 14.9.1. What is Cacheable . . . . . . . . . . . . . . . . . 112 |
| 14.9.5 No-Transform Directive ..................................115 |  | 14.9.2. What May be Stored by Caches . . . . . . . . . . . . 113 |
| 14.9.6 Cache Control Extensions ................................116 |  | 14.9.3. Modifications of the Basic Expiration Mechanism . . 113 |
| 14.10 Connection ...............................................117 |  | 14.9.4. Cache Revalidation and Reload Controls . . . . . . . 115 |
| 14.11 Content-Encoding .........................................118 |  | 14.9.5. No-Transform Directive . . . . . . . . . . . . . . . 118 |
| 14.12 Content-Language .........................................118 |  | 14.9.6. Cache Control Extensions . . . . . . . . . . . . . . 119 |
| 14.13 Content-Length ...........................................119 |  | 14.10. Connection . . . . . . . . . . . . . . . . . . . . . . . 119 |
| 14.14 Content-Location .........................................120 |  | 14.11. Content-Encoding . . . . . . . . . . . . . . . . . . . . 120 |
| 14.15 Content-MD5 ..............................................121 |  | 14.12. Content-Language . . . . . . . . . . . . . . . . . . . . 121 |
| 14.16 Content-Range ............................................122 |  | 14.13. Content-Length . . . . . . . . . . . . . . . . . . . . . 122 |
| 14.17 Content-Type .............................................124 |  | 14.14. Content-Location . . . . . . . . . . . . . . . . . . . . 123 |
| 14.18 Date .....................................................124 |  | 14.15. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . 123 |
| 14.18.1 Clockless Origin Server Operation ......................125 |  | 14.16. Content-Range . . . . . . . . . . . . . . . . . . . . . 125 |
| 14.19 ETag .....................................................126 |  | 14.17. Content-Type . . . . . . . . . . . . . . . . . . . . . . 127 |
| 14.20 Expect ...................................................126 |  | 14.18. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 127 |
| 14.21 Expires ..................................................127 |  | 14.18.1. Clockless Origin Server Operation . . . . . . . . . 128 |
| 14.22 From .....................................................128 |  | 14.19. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 128 |
| 14.23 Host .....................................................128 |  | 14.20. Expect . . . . . . . . . . . . . . . . . . . . . . . . . 129 |
| 14.24 If-Match .................................................129 |  | 14.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 130 |
| 14.25 If-Modified-Since ........................................130 |  | 14.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 131 |
| 14.26 If-None-Match ............................................132 |  | 14.23. Host . . . . . . . . . . . . . . . . . . . . . . . . . . 131 |
| 14.27 If-Range .................................................133 |  | 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 132 |
| 14.28 If-Unmodified-Since ......................................134 |  | 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 133 |
| 14.29 Last-Modified ............................................134 |  | 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 135 |
| 14.30 Location .................................................135 |  | 14.27. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 136 |
| 14.31 Max-Forwards .............................................136 |  | 14.28. If-Unmodified-Since . . . . . . . . . . . . . . . . . . 137 |
| 14.32 Pragma ...................................................136 |  | 14.29. Last-Modified . . . . . . . . . . . . . . . . . . . . . 137 |
| 14.33 Proxy-Authenticate .......................................137 |  | 14.30. Location . . . . . . . . . . . . . . . . . . . . . . . . 138 |
| 14.34 Proxy-Authorization ......................................137 |  | 14.31. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . 138 |
| 14.35 Range ....................................................138 |  | 14.32. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 139 |
| 14.35.1 Byte Ranges ...........................................138 |  | 14.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 140 |
| 14.35.2 Range Retrieval Requests ..............................139 |  | 14.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 140 |
| 14.36 Referer ..................................................140 |  | 14.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140 |
| 14.37 Retry-After ..............................................141 |  | 14.35.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . 140 |
| 14.38 Server ...................................................141 |  | 14.35.2. Range Retrieval Requests . . . . . . . . . . . . . . 142 |
| 14.39 TE .......................................................142 |  | 14.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 143 |
| 14.40 Trailer ..................................................143 |  | 14.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 143 |
| 14.41 Transfer-Encoding..........................................143 |  | 14.38. Server . . . . . . . . . . . . . . . . . . . . . . . . . 144 |
| 14.42 Upgrade ..................................................144 |  | 14.39. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 |
| 14.43 User-Agent ...............................................145 |  | 14.40. Trailer . . . . . . . . . . . . . . . . . . . . . . . . 145 |
| 14.44 Vary .....................................................145 |  | 14.41. Transfer-Encoding . . . . . . . . . . . . . . . . . . . 146 |
| 14.45 Via ......................................................146 |  | 14.42. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . 146 |
| 14.46 Warning ..................................................148 |  | 14.43. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 148 |
| 14.47 WWW-Authenticate .........................................150 |  | 14.44. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 148 |
| 15 Security Considerations .......................................150 |  | 14.45. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 149 |
| 15.1 Personal Information....................................151 |  | 14.46. Warning . . . . . . . . . . . . . . . . . . . . . . . . 150 |
| 15.1.1 Abuse of Server Log Information .........................151 |  | 14.47. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 153 |
| 15.1.2 Transfer of Sensitive Information .......................151 |  | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 153 |
| 15.1.3 Encoding Sensitive Information in URI's .................152 |  | 15.1. Personal Information . . . . . . . . . . . . . . . . . . 153 |
| 15.1.4 Privacy Issues Connected to Accept Headers ..............152 |  | 15.1.1. Abuse of Server Log Information . . . . . . . . . . 154 |
| 15.2 Attacks Based On File and Path Names .......................153 |  | 15.1.2. Transfer of Sensitive Information . . . . . . . . . 154 |
| 15.3 DNS Spoofing ...............................................154 |  | 15.1.3. Encoding Sensitive Information in URI's . . . . . . 155 |
| 15.4 Location Headers and Spoofing ..............................154 |  | 15.1.4. Privacy Issues Connected to Accept Headers . . . . . 155 |
| 15.5 Content-Disposition Issues .................................154 |  | 15.2. Attacks Based On File and Path Names . . . . . . . . . . 156 |
| 15.6 Authentication Credentials and Idle Clients ................155 |  | 15.3. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . 156 |
| 15.7 Proxies and Caching ........................................155 |  | 15.4. Location Headers and Spoofing . . . . . . . . . . . . . 157 |
| 15.7.1 Denial of Service Attacks on Proxies....................156 |  | 15.5. Content-Disposition Issues . . . . . . . . . . . . . . . 157 |
| 16 Acknowledgments .............................................156 |  | 15.6. Authentication Credentials and Idle Clients . . . . . . 157 |
| 17 References ..................................................158 |  | 15.7. Proxies and Caching . . . . . . . . . . . . . . . . . . 158 |
| 18 Authors' Addresses ..........................................162 |  | 15.7.1. Denial of Service Attacks on Proxies . . . . . . . . 159 |
| 19 Appendices ..................................................164 |  | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 159 |
| 19.1 Internet Media Type message/http and application/http ......164 |  | 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 161 |
| 19.2 Internet Media Type multipart/byteranges ...................165 |  | Appendix A. Appendices . . . . . . . . . . . . . . . . . . . . . 165 |
| 19.3 Tolerant Applications ......................................166 |  | A.1. Internet Media Type message/http and application/http . 165 |
| 19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167 |  | A.2. Internet Media Type multipart/byteranges . . . . . . . . 166 |
| 19.4.1 MIME-Version ............................................167 |  | A.3. Tolerant Applications . . . . . . . . . . . . . . . . . 167 |
| 19.4.2 Conversion to Canonical Form ............................167 |  | A.4. Differences Between HTTP Entities and RFC 2045 |
| 19.4.3 Conversion of Date Formats ..............................168 |  | Entities . . . . . . . . . . . . . . . . . . . . . . . . 168 |
| 19.4.4 Introduction of Content-Encoding ........................168 |  | A.4.1. MIME-Version . . . . . . . . . . . . . . . . . . . . 169 |
| 19.4.5 No Content-Transfer-Encoding ............................168 |  | A.4.2. Conversion to Canonical Form . . . . . . . . . . . . 169 |
| 19.4.6 Introduction of Transfer-Encoding .......................169 |  | A.4.3. Conversion of Date Formats . . . . . . . . . . . . . 169 |
| 19.4.7 MHTML and Line Length Limitations .......................169 |  | A.4.4. Introduction of Content-Encoding . . . . . . . . . . 170 |
| 19.5 Additional Features ........................................169 |  | A.4.5. No Content-Transfer-Encoding . . . . . . . . . . . . 170 |
| 19.5.1 Content-Disposition .....................................170 |  | A.4.6. Introduction of Transfer-Encoding . . . . . . . . . 170 |
| 19.6 Compatibility with Previous Versions .......................170 |  | A.4.7. MHTML and Line Length Limitations . . . . . . . . . 171 |
| 19.6.1 Changes from HTTP/1.0 ...................................171 |  | A.5. Additional Features . . . . . . . . . . . . . . . . . . 171 |
| 19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172 |  | A.5.1. Content-Disposition . . . . . . . . . . . . . . . . 171 |
| 19.6.3 Changes from RFC 2068 ...................................172 |  | A.6. Compatibility with Previous Versions . . . . . . . . . . 172 |
| 20 Index .......................................................175 |  | A.6.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . 173 |
| 21 Full Copyright Statement ....................................176 |  | A.6.2. Compatibility with HTTP/1.0 Persistent Connections . 174 |
|  |  | A.6.3. Changes from RFC 2068 . . . . . . . . . . . . . . . 174 |
|  |  | Appendix B. Index . . . . . . . . . . . . . . . . . . . . . . . 177 |
|  |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 |
|  |  | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 188 |
|  |  | Intellectual Property and Copyright Statements . . . . . . . . . 190 |
| 1 Introduction |  | 1. Introduction |
| 1.1 Purpose |  | 1.1. Purpose |
| The Hypertext Transfer Protocol (HTTP) is an application-level |  | The Hypertext Transfer Protocol (HTTP) is an application-level |
| protocol for distributed, collaborative, hypermedia information |  | protocol for distributed, collaborative, hypermedia information |
| systems. HTTP has been in use by the World-Wide Web global |  | systems. HTTP has been in use by the World-Wide Web global |
| information initiative since 1990. The first version of HTTP, |  | information initiative since 1990. The first version of HTTP, |
| referred to as HTTP/0.9, was a simple protocol for raw data transfer |  | referred to as HTTP/0.9, was a simple protocol for raw data transfer |
| across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved |  | across the Internet. HTTP/1.0, as defined by RFC 1945 [RFC1945], |
| the protocol by allowing messages to be in the format of MIME-like |  | improved the protocol by allowing messages to be in the format of |
| messages, containing metainformation about the data transferred and |  | MIME-like messages, containing metainformation about the data |
| modifiers on the request/response semantics. However, HTTP/1.0 does |  | transferred and modifiers on the request/response semantics. |
| not sufficiently take into consideration the effects of hierarchical |  | However, HTTP/1.0 does not sufficiently take into consideration the |
| proxies, caching, the need for persistent connections, or virtual |  | effects of hierarchical proxies, caching, the need for persistent |
| hosts. In addition, the proliferation of incompletely-implemented |  | connections, or virtual hosts. In addition, the proliferation of |
| applications calling themselves "HTTP/1.0" has necessitated a |  | incompletely-implemented applications calling themselves "HTTP/1.0" |
| protocol version change in order for two communicating applications |  | has necessitated a protocol version change in order for two |
| to determine each other's true capabilities. |  | communicating applications to determine each other's true |
|  |  | capabilities. |
| This specification defines the protocol referred to as "HTTP/1.1". |  | This specification defines the protocol referred to as "HTTP/1.1". |
| This protocol includes more stringent requirements than HTTP/1.0 in |  | This protocol includes more stringent requirements than HTTP/1.0 in |
| order to ensure reliable implementation of its features. |  | order to ensure reliable implementation of its features. |
| Practical information systems require more functionality than simple |  | Practical information systems require more functionality than simple |
| retrieval, including search, front-end update, and annotation. HTTP |  | retrieval, including search, front-end update, and annotation. HTTP |
| allows an open-ended set of methods and headers that indicate the |  | allows an open-ended set of methods and headers that indicate the |
| purpose of a request [47]. It builds on the discipline of reference |  | purpose of a request [RFC2324]. It builds on the discipline of |
| provided by the Uniform Resource Identifier (URI) [3], as a location |  | reference provided by the Uniform Resource Identifier (URI) |
| (URL) [4] or name (URN) [20], for indicating the resource to which a |  | [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for |
| method is to be applied. Messages are passed in a format similar to |  | indicating the resource to which a method is to be applied. Messages |
| that used by Internet mail [9] as defined by the Multipurpose |  | are passed in a format similar to that used by Internet mail [RFC822] |
| Internet Mail Extensions (MIME) [7]. |  | as defined by the Multipurpose Internet Mail Extensions (MIME) |
|  |  | [RFC2045]. |
| HTTP is also used as a generic protocol for communication between |  | HTTP is also used as a generic protocol for communication between |
| user agents and proxies/gateways to other Internet systems, including |  | user agents and proxies/gateways to other Internet systems, including |
| those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], |  | those supported by the SMTP [RFC821], NNTP [RFC977], FTP [RFC959], |
| and WAIS [10] protocols. In this way, HTTP allows basic hypermedia |  | Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP |
| access to resources available from diverse applications. |  | allows basic hypermedia access to resources available from diverse |
|  |  | applications. |
| 1.2 Requirements |  | 1.2. Requirements |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |  | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |  | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in RFC 2119 [34]. |  | document are to be interpreted as described in RFC 2119 [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the MUST or REQUIRED level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or 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. |
| content negotiation |  | content negotiation |
| The mechanism for selecting the appropriate representation when |  | The mechanism for selecting the appropriate representation when |
| servicing a request, as described in section 12. The |  | servicing a request, as described in Section 12. The |
| representation of entities in any response can be negotiated |  | representation of entities in any response can be negotiated |
| (including error responses). |  | (including error responses). |
| variant |  | variant |
| A resource may have one, or more than one, representation(s) |  | A resource may have one, or more than one, representation(s) |
| associated with it at any given instant. Each of these |  | associated with it at any given instant. Each of these |
| representations is termed a `varriant'. Use of the term `variant' |  | representations is termed a `varriant'. Use of the term `variant' |
| does not necessarily imply that the resource is subject to content |  | does not necessarily imply that the resource is subject to content |
| negotiation. |  | negotiation. |
| client |  | client |
| A program that establishes connections for the purpose of sending |  | A program that establishes connections for the purpose of sending |
| requests. |  | requests. |
| user agent |  | user agent |
| The client which initiates a request. These are often browsers, |  | The client which initiates a request. These are often browsers, |
| editors, spiders (web-traversing robots), or other end user tools. |  | editors, spiders (web-traversing robots), or other end user tools. |
| server |  | server |
| 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 |
| skipping to change at page 10, line 6 |  | skipping to change at page 11, 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. |
| explicit expiration time |  | explicit expiration time |
| skipping to change at page 11, line 12 |  | skipping to change at page 13, line 10 |
| 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. |
| explicit expiration time |  | explicit expiration time |
| The time at which the origin server intends that an entity should |  | The time at which the origin server intends that an entity should |
| no longer be returned by a cache without further validation. |  | no longer be returned by a cache without further validation. |
| heuristic expiration time |  | heuristic expiration time |
| An expiration time assigned by a cache when no explicit expiration |  | An expiration time assigned by a cache when no explicit expiration |
| time is available. |  | time is available. |
| age |  | age |
| The age of a response is the time since it was sent by, or |  | The age of a response is the time since it was sent by, or |
| successfully validated with, the origin server. |  | successfully validated with, the origin server. |
| freshness lifetime |  | freshness lifetime |
| The length of time between the generation of a response and its |  | The length of time between the generation of a response and its |
| expiration time. |  | expiration time. |
| fresh |  | fresh |
| A response is fresh if its age has not yet exceeded its freshness |  | A response is fresh if its age has not yet exceeded its freshness |
| lifetime. |  | lifetime. |
| stale |  | stale |
| A response is stale if its age has passed its freshness lifetime. |  | A response is stale if its age has passed its freshness lifetime. |
| semantically transparent |  | semantically transparent |
| A cache behaves in a "semantically transparent" manner, with |  | A cache behaves in a "semantically transparent" manner, with |
| respect to a particular response, when its use affects neither the |  | respect to a particular response, when its use affects neither the |
| requesting client nor the origin server, except to improve |  | requesting client nor the origin server, except to improve |
| performance. When a cache is semantically transparent, the client |  | performance. When a cache is semantically transparent, the client |
| receives exactly the same response (except for hop-by-hop headers) |  | receives exactly the same response (except for hop-by-hop headers) |
| that it would have received had its request been handled directly |  | that it would have received had its request been handled directly |
| by the origin server. |  | by the origin server. |
| validator |  | validator |
| A protocol element (e.g., an entity tag or a Last-Modified time) |  | A protocol element (e.g., an entity tag or a Last-Modified time) |
| that is used to find out whether a cache entry is an equivalent |  | that is used to find out whether a cache entry is an equivalent |
| copy of an entity. |  | copy of an entity. |
| upstream/downstream |  | upstream/downstream |
| Upstream and downstream describe the flow of a message: all |  | Upstream and downstream describe the flow of a message: all |
| messages flow from upstream to downstream. |  | messages flow from upstream to downstream. |
| inbound/outbound |  | inbound/outbound |
| Inbound and outbound refer to the request and response paths for |  | Inbound and outbound refer to the request and response paths for |
| messages: "inbound" means "traveling toward the origin server", |  | messages: "inbound" means "traveling toward the origin server", |
| and "outbound" means "traveling toward the user agent" |  | and "outbound" means "traveling toward the user agent" |
| 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 A.4. |
| 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 15, 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 |
| contain modifiers which place special requirements on cache behavior. |  | contain modifiers which place special requirements on cache behavior. |
| HTTP requirements for cache behavior and cacheable responses are |  | HTTP requirements for cache behavior and cacheable responses are |
| defined in section 13. |  | defined in Section 13. |
| In fact, there are a wide variety of architectures and configurations |  | In fact, there are a wide variety of architectures and configurations |
| of caches and proxies currently being experimented with or deployed |  | of caches and proxies currently being experimented with or deployed |
| across the World Wide Web. These systems include national hierarchies |  | across the World Wide Web. These systems include national hierarchies |
| of proxy caches to save transoceanic bandwidth, systems that |  | of proxy caches to save transoceanic bandwidth, systems that |
| broadcast or multicast cache entries, organizations that distribute |  | broadcast or multicast cache entries, organizations that distribute |
| subsets of cached data via CD-ROM, and so on. HTTP systems are used |  | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
| in corporate intranets over high-bandwidth links, and for access via |  | in corporate intranets over high-bandwidth links, and for access via |
| PDAs with low-power radio links and intermittent connectivity. The |  | PDAs with low-power radio links and intermittent connectivity. The |
| goal of HTTP/1.1 is to support the wide diversity of configurations |  | goal of HTTP/1.1 is to support the wide diversity of configurations |
| already deployed while introducing protocol constructs that meet the |  | already deployed while introducing protocol constructs that meet the |
| needs of those who build web applications that require high |  | needs of those who build web applications that require high |
| reliability and, failing that, at least reliable indications of |  | reliability and, failing that, at least reliable indications of |
| failure. |  | failure. |
| HTTP communication usually takes place over TCP/IP connections. The |  | HTTP communication usually takes place over TCP/IP connections. The |
| default port is TCP 80 [19], but other ports can be used. This does |  | default port is TCP 80 [RFC1700], but other ports can be used. This |
| not preclude HTTP from being implemented on top of any other protocol |  | does not preclude HTTP from being implemented on top of any other |
| on the Internet, or on other networks. HTTP only presumes a reliable |  | protocol on the Internet, or on other networks. HTTP only presumes a |
| transport; any protocol that provides such guarantees can be used; |  | reliable transport; any protocol that provides such guarantees can be |
| the mapping of the HTTP/1.1 request and response structures onto the |  | used; the mapping of the HTTP/1.1 request and response structures |
| transport data units of the protocol in question is outside the scope |  | onto the transport data units of the protocol in question is outside |
| of this specification. |  | the scope of this specification. |
| In HTTP/1.0, most implementations used a new connection for each |  | In HTTP/1.0, most implementations used a new connection for each |
| request/response exchange. In HTTP/1.1, a connection may be used for |  | request/response exchange. In HTTP/1.1, a connection may be used for |
| one or more request/response exchanges, although connections may be |  | one or more request/response exchanges, although connections may be |
| closed for a variety of reasons (see section 8.1). |  | closed for a variety of reasons (see Section 8.1). |
| 2 Notational Conventions and Generic Grammar |  | 2. Notational Conventions and Generic Grammar |
| 2.1 Augmented BNF |  | 2.1. Augmented BNF |
| All of the mechanisms specified in this document are described in |  | All of the mechanisms specified in this document are described in |
| both prose and an augmented Backus-Naur Form (BNF) similar to that |  | both prose and an augmented Backus-Naur Form (BNF) similar to that |
| used by RFC 822 [9]. Implementors will need to be familiar with the |  | used by RFC 822 [RFC822]. Implementors will need to be familiar with |
| notation in order to understand this specification. The augmented BNF |  | the notation in order to understand this specification. The |
| includes the following constructs: |  | augmented 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 15, line 36 |  | skipping to change at page 18, line 10 |
| "1#element" requires at least one; and "1#2element" allows one or |  | "1#element" requires at least one; and "1#2element" allows one or |
| two. |  | two. |
| ; comment |  | ; comment |
| A semi-colon, set off some distance to the right of rule text, |  | A semi-colon, set off some distance to the right of rule text, |
| starts a comment that continues to the end of line. This is a |  | starts a comment that continues to the end of line. This is a |
| simple way of including useful notes in parallel with the |  | simple way of including useful notes in parallel with the |
| specifications. |  | specifications. |
| implied *LWS |  | implied *LWS |
| The grammar described by this specification is word-based. Except |  | The grammar described by this specification is word-based. Except |
| where noted otherwise, linear white space (LWS) can be included |  | where noted otherwise, linear white space (LWS) can be included |
| between any two adjacent words (token or quoted-string), and |  | between any two adjacent words (token or quoted-string), and |
| between adjacent words and separators, without changing the |  | between adjacent words and separators, without changing the |
| interpretation of a field. At least one delimiter (LWS and/or |  | interpretation of a field. At least one delimiter (LWS and/or |
| separators) MUST exist between any two tokens (for the definition |  | separators) MUST exist between any two tokens (for the definition |
| of "token" below), since they would otherwise be interpreted as a |  | of "token" below), since they would otherwise be interpreted as a |
| single token. |  | single token. |
| 2.2 Basic Rules |  | 2.2. Basic Rules |
| The following rules are used throughout this specification to |  | The following rules are used throughout this specification to |
| describe basic parsing constructs. The US-ASCII coded character set |  | describe basic parsing constructs. The US-ASCII coded character set |
| is defined by ANSI X3.4-1986 [21]. |  | is defined by ANSI X3.4-1986 [USASCII]. |
| OCTET = <any 8-bit sequence of data> |  | OCTET = <any 8-bit sequence of data> |
| CHAR = <any US-ASCII character (octets 0 - 127)> |  | CHAR = <any US-ASCII character (octets 0 - 127)> |
| UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |  | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
| LOALPHA = <any US-ASCII lowercase letter "a".."z"> |  | LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
| ALPHA = UPALPHA | LOALPHA |  | ALPHA = UPALPHA | LOALPHA |
| DIGIT = <any US-ASCII digit "0".."9"> |  | DIGIT = <any US-ASCII digit "0".."9"> |
| CTL = <any US-ASCII control character |  | CTL = <any US-ASCII control character |
| (octets 0 - 31) and DEL (127)> |  | (octets 0 - 31) and DEL (127)> |
| CR = <US-ASCII CR, carriage return (13)> |  | CR = <US-ASCII CR, carriage return (13)> |
| LF = <US-ASCII LF, linefeed (10)> |  | LF = <US-ASCII LF, linefeed (10)> |
| SP = <US-ASCII SP, space (32)> |  | SP = <US-ASCII SP, space (32)> |
| HT = <US-ASCII HT, horizontal-tab (9)> |  | HT = <US-ASCII HT, horizontal-tab (9)> |
| <"> = <US-ASCII double-quote mark (34)> |  | <"> = <US-ASCII double-quote mark (34)> |
| HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |  | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
| protocol elements except the entity-body (see appendix 19.3 for |  | protocol elements except the entity-body (see Appendix A.3 for |
| tolerant applications). The end-of-line marker within an entity-body |  | tolerant applications). The end-of-line marker within an entity-body |
| is defined by its associated media type, as described in section 3.7. |  | is defined by its associated media type, as described in Section 3.7. |
| CRLF = CR LF |  | CRLF = CR LF |
| HTTP/1.1 header field values can be folded onto multiple lines if the |  | HTTP/1.1 header field values can be folded onto multiple lines if the |
| continuation line begins with a space or horizontal tab. All linear |  | continuation line begins with a space or horizontal tab. All linear |
| white space, including folding, has the same semantics as SP. A |  | white space, including folding, has the same semantics as SP. A |
| recipient MAY replace any linear white space with a single SP before |  | recipient MAY replace any linear white space with a single SP before |
| interpreting the field value or forwarding the message downstream. |  | interpreting the field value or forwarding the message downstream. |
| LWS = [CRLF] 1*( SP | HT ) |  | LWS = [CRLF] 1*( SP | HT ) |
| The TEXT rule is only used for descriptive field contents and values |  | The TEXT rule is only used for descriptive field contents and values |
| that are not intended to be interpreted by the message parser. Words |  | that are not intended to be interpreted by the message parser. Words |
| of *TEXT MAY contain characters from character sets other than ISO- |  | of *TEXT MAY contain characters from character sets other than ISO- |
| 8859-1 [22] only when encoded according to the rules of RFC 2047 |  | 8859-1 [ISO-8859] only when encoded according to the rules of RFC |
| [14]. |  | 2047 [RFC2047]. |
| TEXT = <any OCTET except CTLs, |  | TEXT = <any OCTET except CTLs, |
| but including LWS> |  | but including LWS> |
| A CRLF is allowed in the definition of TEXT only as part of a header |  | A CRLF is allowed in the definition of TEXT only as part of a header |
| field continuation. It is expected that the folding LWS will be |  | field continuation. It is expected that the folding LWS will be |
| replaced with a single SP before interpretation of the TEXT value. |  | replaced with a single SP before interpretation of the TEXT value. |
| Hexadecimal numeric characters are used in several protocol elements. |  | Hexadecimal numeric characters are used in several protocol elements. |
| skipping to change at page 17, line 4 |  | skipping to change at page 19, line 24 |
| 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 17, line 35 |  | skipping to change at page 20, line 7 |
| double-quote marks. |  | double-quote marks. |
| quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) |  | quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) |
| qdtext = <any TEXT except <">> |  | qdtext = <any TEXT except <">> |
| The backslash character ("\") MAY be used as a single-character |  | The backslash character ("\") MAY be used as a single-character |
| quoting mechanism only within quoted-string and comment constructs. |  | quoting mechanism only within quoted-string and comment constructs. |
| quoted-pair = "\" CHAR |  | quoted-pair = "\" CHAR |
| 3 Protocol Parameters |  | 3. Protocol Parameters |
| 3.1 HTTP Version |  | 3.1. HTTP Version |
| HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |  | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
| of the protocol. The protocol versioning policy is intended to allow |  | of the protocol. The protocol versioning policy is intended to allow |
| the sender to indicate the format of a message and its capacity for |  | the sender to indicate the format of a message and its capacity for |
| understanding further HTTP communication, rather than the features |  | understanding further HTTP communication, rather than the features |
| obtained via that communication. No change is made to the version |  | obtained via that communication. No change is made to the version |
| number for the addition of message components which do not affect |  | number for the addition of message components which do not affect |
| communication behavior or which only add to extensible field values. |  | communication behavior or which only add to extensible field values. |
| The <minor> number is incremented when the changes made to the |  | The <minor> number is incremented when the changes made to the |
| protocol add features which do not change the general message parsing |  | protocol add features which do not change the general message parsing |
| algorithm, but which may add to the message semantics and imply |  | algorithm, but which may add to the message semantics and imply |
| additional capabilities of the sender. The <major> number is |  | additional capabilities of the sender. The <major> number is |
| incremented when the format of a message within the protocol is |  | incremented when the format of a message within the protocol is |
| changed. See RFC 2145 [36] for a fuller explanation. |  | changed. See RFC 2145 [RFC2145] for a fuller explanation. |
| The version of an HTTP message is indicated by an HTTP-Version field |  | The version of an HTTP message is indicated by an HTTP-Version field |
| in the first line of the message. |  | in the first line of the message. |
| HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |  | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
| Note that the major and minor numbers MUST be treated as separate |  | Note that the major and minor numbers MUST be treated as separate |
| integers and that each MAY be incremented higher than a single digit. |  | integers and that each MAY be incremented higher than a single digit. |
| Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |  | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
| lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 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 [RFC2145]. |
| The HTTP version of an application is the highest HTTP version for |  | The HTTP version of an application is the highest HTTP version for |
| which the application is at least conditionally compliant. |  | which the application is at least conditionally compliant. |
| Proxy and gateway applications need to be careful when forwarding |  | Proxy and gateway applications need to be careful when forwarding |
| messages in protocol versions different from that of the application. |  | messages in protocol versions different from that of the application. |
| Since the protocol version indicates the protocol capability of the |  | Since the protocol version indicates the protocol capability of the |
| sender, a proxy/gateway MUST NOT send a message with a version |  | sender, a proxy/gateway MUST NOT send a message with a version |
| indicator which is greater than its actual version. If a higher |  | indicator which is greater than its actual version. If a higher |
| version request is received, the proxy/gateway MUST either downgrade |  | version request is received, the proxy/gateway MUST either downgrade |
| the request version, or respond with an error, or switch to tunnel |  | the request version, or respond with an error, or switch to tunnel |
| behavior. |  | behavior. |
| Due to interoperability problems with HTTP/1.0 proxies discovered |  | Due to interoperability problems with HTTP/1.0 proxies discovered |
| since the publication of RFC 2068[33], caching proxies MUST, gateways |  | since the publication of RFC 2068 [RFC2068], 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 [RFC1630], and finally |
| combination of Uniform Resource Locators (URL) [4] and Names (URN) |  | the combination of Uniform Resource Locators (URL) [RFC1738] and |
| [20]. As far as HTTP is concerned, Uniform Resource Identifiers are |  | Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource |
| simply formatted strings which identify--via name, location, or any |  | Identifiers are simply formatted strings which identify--via name, |
| other characteristic--a resource. |  | location, or any other characteristic--a resource. |
| 3.2.1 General Syntax |  | 3.2.1. General Syntax |
| URIs in HTTP can be represented in absolute form or relative to some |  | URIs in HTTP can be represented in absolute form or relative to some |
| known base URI [11], depending upon the context of their use. The two |  | known base URI [RFC1808], depending upon the context of their use. |
| forms are differentiated by the fact that absolute URIs always begin |  | The two forms are differentiated by the fact that absolute URIs |
| with a scheme name followed by a colon. For definitive information on |  | always 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 [RFC2396] |
| 1738 [4] and RFC 1808 [11]). This specification adopts the |  | (which replaces RFCs 1738 [RFC1738] and RFC 1808 [RFC1808]). This |
| definitions of "URI-reference", "absoluteURI", "relativeURI", "port", |  | specification adopts the definitions of "URI-reference", |
| "host","abs_path", "rel_path", and "authority" from that |  | "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", |
| specification. |  | and "authority" 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 |
| implementations might not properly support these lengths. |  | implementations might not properly support these lengths. |
| 3.2.2 http URL |  | 3.2.2. http URL |
| The "http" scheme is used to locate network resources via the HTTP |  | The "http" scheme is used to locate network resources via the HTTP |
| protocol. This section defines the scheme-specific syntax and |  | protocol. This section defines the scheme-specific syntax and |
| semantics for http URLs. |  | semantics for http URLs. |
| http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] |  | http_URL = "http:" "//" 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 |  | [RFC1900]). If the abs_path is not present in the URL, it MUST be |
| used as a Request-URI for a resource (section 5.1.2). If a proxy |  | given as "/" when used as a Request-URI for a resource |
| receives a host name which is not a fully qualified domain name, it |  | (Section 5.1.2). If a proxy receives a host name which is not a |
| MAY add its domain to the host name it received. If a proxy receives |  | fully qualified domain name, it MAY add its domain to the host name |
| a fully qualified domain name, the proxy MUST NOT change the host |  | it received. If a proxy receives a fully qualified domain name, the |
| name. |  | proxy MUST NOT change the host name. |
| 3.2.3 URI Comparison |  | 3.2.3. URI Comparison |
| When comparing two URIs to decide if they match or not, a client |  | When comparing two URIs to decide if they match or not, a client |
| SHOULD use a case-sensitive octet-by-octet comparison of the entire |  | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
| URIs, with these exceptions: |  | URIs, with these exceptions: |
| - 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 [RFC2396]) are equivalent to their ""%" HEX HEX" encoding. |
| For example, the following three URIs are equivalent: |  | For example, the following three URIs are equivalent: |
| http://abc.com:80/~smith/home.html |  | http://abc.com:80/~smith/home.html |
| http://ABC.com/%7Esmith/home.html |  | http://ABC.com/%7Esmith/home.html |
| http://ABC.com:/%7esmith/home.html |  | http://ABC.com:/%7esmith/home.html |
| 3.3 Date/Time Formats |  | 3.3. Date/Time Formats |
| 3.3.1 Full Date |  | 3.3.1. Full Date |
| 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 [RFC1123] (an |
| RFC 822 [9]). The second format is in common use, but is based on the |  | update to RFC 822 [RFC822]). The second format is in common use, but |
| obsolete RFC 850 [12] date format and lacks a four-digit year. |  | is based on the obsolete RFC 850 [RFC1036] date format and lacks a |
| HTTP/1.1 clients and servers that parse the date value MUST accept |  | four-digit year. HTTP/1.1 clients and servers that parse the date |
| all three formats (for compatibility with HTTP/1.0), though they MUST |  | value MUST accept all three formats (for compatibility with |
| only generate the RFC 1123 format for representing HTTP-date values |  | HTTP/1.0), though they MUST only generate the RFC 1123 format for |
| in header fields. See section 19.3 for further information. |  | representing HTTP-date values in header fields. See Appendix A.3 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 24, line 25 |
| 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 |
| HTTP uses the same definition of the term "character set" as that |  | HTTP uses the same definition of the term "character set" as that |
| described for MIME: |  | described for MIME: |
| The term "character set" is used in this document to refer to a |  | The term "character set" is used in this document to refer to a |
| method used with one or more tables to convert a sequence of octets |  | method used with one or more tables to convert a sequence of octets |
| into a sequence of characters. Note that unconditional conversion in |  | into a sequence of characters. Note that unconditional conversion in |
| the other direction is not required, in that not all characters may |  | the other direction is not required, in that not all characters may |
| be available in a given character set and a character set may provide |  | be available in a given character set and a character set may provide |
| more than one sequence of octets to represent a particular character. |  | more than one sequence of octets to represent a particular character. |
| skipping to change at page 22, line 26 |  | skipping to change at page 25, line 15 |
| to characters. In particular, use of external profiling information |  | to characters. In particular, use of external profiling information |
| to determine the exact mapping is not permitted. |  | to determine the exact mapping is not permitted. |
| Note: This use of the term "character set" is more commonly |  | Note: This use of the term "character set" is more commonly |
| referred to as a "character encoding." However, since HTTP and |  | referred to as a "character encoding." However, since HTTP and |
| MIME share the same registry, it is important that the terminology |  | MIME share the same registry, it is important that the terminology |
| also be shared. |  | also be shared. |
| HTTP character sets are identified by case-insensitive tokens. The |  | HTTP character sets are identified by case-insensitive tokens. The |
| complete set of tokens is defined by the IANA Character Set registry |  | complete set of tokens is defined by the IANA Character Set registry |
| [19]. |  | [RFC1700]. |
| charset = token |  | charset = token |
| Although HTTP allows an arbitrary token to be used as a charset |  | Although HTTP allows an arbitrary token to be used as a charset |
| value, any token that has a predefined value within the IANA |  | value, any token that has a predefined value within the IANA |
| Character Set registry [19] MUST represent the character set defined |  | Character Set registry [RFC1700] MUST represent the character set |
| by that registry. Applications SHOULD limit their use of character |  | defined by that registry. Applications SHOULD limit their use of |
| sets to those defined by the IANA registry. |  | character sets to those defined by the IANA registry. |
| Implementors should be aware of IETF character set requirements [38] |  | Implementors should be aware of IETF character set requirements |
| [41]. |  | [RFC2279] [RFC2277]. |
| 3.4.1 Missing Charset |  | 3.4.1. Missing Charset |
| Some HTTP/1.0 software has interpreted a Content-Type header without |  | Some HTTP/1.0 software has interpreted a Content-Type header without |
| charset parameter incorrectly to mean "recipient should guess." |  | charset parameter incorrectly to mean "recipient should guess." |
| Senders wishing to defeat this behavior MAY include a charset |  | Senders wishing to defeat this behavior MAY include a charset |
| parameter even when the charset is ISO-8859-1 and SHOULD do so when |  | parameter even when the charset is ISO-8859-1 and SHOULD do so when |
| it is known that it will not confuse the recipient. |  | it is known that it will not confuse the recipient. |
| Unfortunately, some older HTTP/1.0 clients did not deal properly with |  | Unfortunately, some older HTTP/1.0 clients did not deal properly with |
| an explicit charset parameter. HTTP/1.1 recipients MUST respect the |  | an explicit charset parameter. HTTP/1.1 recipients MUST respect the |
| charset label provided by the sender; and those user agents that have |  | charset label provided by the sender; and those user agents that have |
| a provision to "guess" a charset MUST use the charset from the |  | a provision to "guess" a charset MUST use the charset from the |
| content-type field if they support that charset, rather than the |  | content-type field if they support that charset, rather than the |
| recipient's preference, when initially displaying a document. See |  | recipient's preference, when initially displaying a document. See |
| section 3.7.1. |  | Section 3.7.1. |
| 3.5 Content Codings |  | 3.5. Content Codings |
| Content coding values indicate an encoding transformation that has |  | Content coding values indicate an encoding transformation that has |
| been or can be applied to an entity. Content codings are primarily |  | been or can be applied to an entity. Content codings are primarily |
| used to allow a document to be compressed or otherwise usefully |  | used to allow a document to be compressed or otherwise usefully |
| transformed without losing the identity of its underlying media type |  | transformed without losing the identity of its underlying media type |
| and without loss of information. Frequently, the entity is stored in |  | and without loss of information. Frequently, the entity is stored in |
| coded form, transmitted directly, and only decoded by the recipient. |  | coded form, transmitted directly, and only decoded by the recipient. |
| content-coding = token |  | content-coding = token |
| All content-coding values are case-insensitive. HTTP/1.1 uses |  | All content-coding values are case-insensitive. HTTP/1.1 uses |
| content-coding values in the Accept-Encoding (section 14.3) and |  | content-coding values in the Accept-Encoding (Section 14.3) and |
| Content-Encoding (section 14.11) header fields. Although the value |  | Content-Encoding (Section 14.11) header fields. Although the value |
| describes the content-coding, what is more important is that it |  | describes the content-coding, what is more important is that it |
| indicates what decoding mechanism will be required to remove the |  | indicates what decoding mechanism will be required to remove the |
| encoding. |  | encoding. |
| The Internet Assigned Numbers Authority (IANA) acts as a registry for |  | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
| content-coding value tokens. Initially, the registry contains the |  | content-coding value tokens. Initially, the registry contains the |
| following tokens: |  | following tokens: |
| gzip An encoding format produced by the file compression program |  | gzip |
| "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a |  |  |
|  |  | An encoding format produced by the file compression program "gzip" |
|  |  | (GNU zip) as described in RFC 1952 [RFC1952]. This format is a |
| Lempel-Ziv coding (LZ77) with a 32 bit CRC. |  | 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 [RFC1950] in combination |
|  |  | with the "deflate" compression mechanism described in RFC 1951 |
|  |  | [RFC1951]. |
| identity |  | identity |
| The default (identity) encoding; the use of no transformation |  | The default (identity) encoding; the use of no transformation |
| whatsoever. This content-coding is used only in the Accept- |  | whatsoever. This content-coding is used only in the Accept- |
| Encoding header, and SHOULD NOT be used in the Content-Encoding |  | Encoding header, and SHOULD NOT be used in the Content-Encoding |
| header. |  | header. |
| New content-coding value tokens SHOULD be registered; to allow |  | New content-coding value tokens SHOULD be registered; to allow |
| interoperability between clients and servers, specifications of the |  | interoperability between clients and servers, specifications of the |
| content coding algorithms needed to implement a new value SHOULD be |  | content coding algorithms needed to implement a new value SHOULD be |
| publicly available and adequate for independent implementation, and |  | publicly available and adequate for independent implementation, and |
| conform to the purpose of content coding defined in this section. |  | conform to the purpose of content coding defined in this section. |
| skipping to change at page 24, line 17 |  | skipping to change at page 27, line 7 |
| whatsoever. This content-coding is used only in the Accept- |  | whatsoever. This content-coding is used only in the Accept- |
| Encoding header, and SHOULD NOT be used in the Content-Encoding |  | Encoding header, and SHOULD NOT be used in the Content-Encoding |
| header. |  | header. |
| New content-coding value tokens SHOULD be registered; to allow |  | New content-coding value tokens SHOULD be registered; to allow |
| interoperability between clients and servers, specifications of the |  | interoperability between clients and servers, specifications of the |
| content coding algorithms needed to implement a new value SHOULD be |  | content coding algorithms needed to implement a new value SHOULD be |
| publicly available and adequate for independent implementation, and |  | publicly available and adequate for independent implementation, and |
| conform to the purpose of content coding defined in this section. |  | conform to the purpose of content coding defined in this section. |
| 3.6 Transfer Codings |  | 3.6. Transfer Codings |
| Transfer-coding values are used to indicate an encoding |  | Transfer-coding values are used to indicate an encoding |
| transformation that has been, can be, or may need to be applied to an |  | transformation that has been, can be, or may need to be applied to an |
| entity-body in order to ensure "safe transport" through the network. |  | entity-body in order to ensure "safe transport" through the network. |
| This differs from a content coding in that the transfer-coding is a |  | This differs from a content coding in that the transfer-coding is a |
| property of the message, not of the original entity. |  | property of the message, not of the original entity. |
| transfer-coding = "chunked" | transfer-extension |  | transfer-coding = "chunked" | transfer-extension |
| transfer-extension = token *( ";" parameter ) |  | transfer-extension = token *( ";" parameter ) |
| Parameters are in the form of attribute/value pairs. |  | Parameters are in the form of attribute/value pairs. |
| parameter = attribute "=" value |  | parameter = attribute "=" value |
| attribute = token |  | attribute = token |
| value = token | quoted-string |  | value = token | quoted-string |
| All transfer-coding values are case-insensitive. HTTP/1.1 uses |  | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
| transfer-coding values in the TE header field (section 14.39) and in |  | transfer-coding values in the TE header field (Section 14.39) and in |
| the Transfer-Encoding header field (section 14.41). |  | the Transfer-Encoding header field (Section 14.41). |
| Whenever a transfer-coding is applied to a message-body, the set of |  | Whenever a transfer-coding is applied to a message-body, the set of |
| transfer-codings MUST include "chunked", unless the message is |  | transfer-codings MUST include "chunked", unless the message is |
| terminated by closing the connection. When the "chunked" transfer- |  | terminated by closing the connection. When the "chunked" transfer- |
| coding is used, it MUST be the last transfer-coding applied to the |  | coding is used, it MUST be the last transfer-coding applied to the |
| message-body. The "chunked" transfer-coding MUST NOT be applied more |  | message-body. The "chunked" transfer-coding MUST NOT be applied more |
| than once to a message-body. These rules allow the recipient to |  | than once to a message-body. These rules allow the recipient to |
| determine the transfer-length of the message (section 4.4). |  | determine the transfer-length of the message (Section 4.4). |
| Transfer-codings are analogous to the Content-Transfer-Encoding |  | Transfer-codings are analogous to the Content-Transfer-Encoding |
| values of MIME [7], which were designed to enable safe transport of |  | values of MIME [RFC2045], which were designed to enable safe |
| binary data over a 7-bit transport service. However, safe transport |  | transport of binary data over a 7-bit transport service. However, |
| has a different focus for an 8bit-clean transfer protocol. In HTTP, |  | safe transport has a different focus for an 8bit-clean transfer |
| the only unsafe characteristic of message-bodies is the difficulty in |  | protocol. In HTTP, the only unsafe characteristic of message-bodies |
| determining the exact body length (section 7.2.2), or the desire to |  | is the difficulty in determining the exact body length |
| encrypt data over a shared transport. |  | (Section 7.2.2), or the desire to encrypt data over a shared |
|  |  | transport. |
| The Internet Assigned Numbers Authority (IANA) acts as a registry for |  | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
| transfer-coding value tokens. Initially, the registry contains the |  | transfer-coding value tokens. Initially, the registry contains the |
| following tokens: "chunked" (section 3.6.1), "identity" (section |  | following tokens: "chunked" (Section 3.6.1), "identity" (section |
| 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" |  | 3.6.2), "gzip" (Section 3.5), "compress" (Section 3.5), and "deflate" |
| (section 3.5). |  | (Section 3.5). |
| New transfer-coding value tokens SHOULD be registered in the same way |  | New transfer-coding value tokens SHOULD be registered in the same way |
| as new content-coding value tokens (section 3.5). |  | as new content-coding value tokens (Section 3.5). |
| A server which receives an entity-body with a transfer-coding it does |  | A server which receives an entity-body with a transfer-coding it does |
| not understand SHOULD return 501 (Unimplemented), and close the |  | not understand SHOULD return 501 (Unimplemented), and close the |
| connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |  | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
| client. |  | client. |
| 3.6.1 Chunked Transfer Coding |  | 3.6.1. Chunked Transfer Coding |
| 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 25, line 51 |  | skipping to change at page 28, line 43 |
| chunk-data = chunk-size(OCTET) |  | chunk-data = chunk-size(OCTET) |
| trailer = *(entity-header CRLF) |  | trailer = *(entity-header CRLF) |
| The chunk-size field is a string of hex digits indicating the size of |  | The chunk-size field is a string of hex digits indicating the size of |
| the chunk. The chunked encoding is ended by any chunk whose size is |  | the chunk. The chunked encoding is ended by any chunk whose size is |
| zero, followed by the trailer, which is terminated by an empty line. |  | zero, followed by the trailer, which is terminated by an empty line. |
| The trailer allows the sender to include additional HTTP header |  | The trailer allows the sender to include additional HTTP header |
| fields at the end of the message. The Trailer header field can be |  | fields at the end of the message. The Trailer header field can be |
| used to indicate which header fields are included in a trailer (see |  | used to indicate which header fields are included in a trailer (see |
| section 14.40). |  | Section 14.40). |
| A server using chunked transfer-coding in a response MUST NOT use the |  | A server using chunked transfer-coding in a response MUST NOT use the |
| trailer for any header fields unless at least one of the following is |  | trailer for any header fields unless at least one of the following is |
| true: |  | true: |
| 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, |
|  |  | 2. the server is the origin server for the response, the trailer |
| b)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 A.4.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 [RFC1590] 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 [RFC1700]). The media type registration process is |
| outlined in RFC 1590 [17]. Use of non-registered media types is |  | outlined in RFC 1590 [RFC1590]. Use of non-registered media types is |
| discouraged. |  | discouraged. |
| 3.7.1 Canonicalization and Text Defaults |  | 3.7.1. Canonicalization and Text Defaults |
| Internet media types are registered with a canonical form. An |  | Internet media types are registered with a canonical form. An |
| entity-body transferred via HTTP messages MUST be represented in the |  | entity-body transferred via HTTP messages MUST be represented in the |
| appropriate canonical form prior to its transmission except for |  | appropriate canonical form prior to its transmission except for |
| "text" types, as defined in the next paragraph. |  | "text" types, as defined in the next paragraph. |
| When in canonical form, media subtypes of the "text" type use CRLF as |  | When in canonical form, media subtypes of the "text" type use CRLF as |
| the text line break. HTTP relaxes this requirement and allows the |  | the text line break. HTTP relaxes this requirement and allows the |
| transport of text media with plain CR or LF alone representing a line |  | transport of text media with plain CR or LF alone representing a line |
| break when it is done consistently for an entire entity-body. HTTP |  | break when it is done consistently for an entire entity-body. HTTP |
| skipping to change at page 27, line 41 |  | skipping to change at page 30, line 34 |
| sequences are defined by that character set to represent the |  | sequences are defined by that character set to represent the |
| equivalent of CR and LF for line breaks. This flexibility regarding |  | equivalent of CR and LF for line breaks. This flexibility regarding |
| line breaks applies only to text media in the entity-body; a bare CR |  | line breaks applies only to text media in the entity-body; a bare CR |
| or LF MUST NOT be substituted for CRLF within any of the HTTP control |  | or LF MUST NOT be substituted for CRLF within any of the HTTP control |
| structures (such as header fields and multipart boundaries). |  | structures (such as header fields and multipart boundaries). |
| If an entity-body is encoded with a content-coding, the underlying |  | If an entity-body is encoded with a content-coding, the underlying |
| data MUST be in a form defined above prior to being encoded. |  | data MUST be in a form defined above prior to being encoded. |
| The "charset" parameter is used with some media types to define the |  | The "charset" parameter is used with some media types to define the |
| character set (section 3.4) of the data. When no explicit charset |  | character set (Section 3.4) of the data. When no explicit charset |
| parameter is provided by the sender, media subtypes of the "text" |  | parameter is provided by the sender, media subtypes of the "text" |
| type are defined to have a default charset value of "ISO-8859-1" when |  | type are defined to have a default charset value of "ISO-8859-1" when |
| received via HTTP. Data in character sets other than "ISO-8859-1" or |  | received via HTTP. Data in character sets other than "ISO-8859-1" or |
| its subsets MUST be labeled with an appropriate charset value. See |  | its subsets MUST be labeled with an appropriate charset value. See |
| section 3.4.1 for compatibility problems. |  | Section 3.4.1 for compatibility problems. |
| 3.7.2 Multipart Types |  | 3.7.2. Multipart Types |
| MIME provides for a number of "multipart" types -- encapsulations of |  | MIME provides for a number of "multipart" types -- encapsulations of |
| one or more entities within a single message-body. All multipart |  | one or more entities within a single message-body. All multipart |
| types share a common syntax, as defined in section 5.1.1 of RFC 2046 |  | types share a common syntax, as defined in section 5.1.1 of RFC 2046 |
| [40], and MUST include a boundary parameter as part of the media type |  | [RFC2046], and MUST include a boundary parameter as part of the media |
| value. The message body is itself a protocol element and MUST |  | type value. The message body is itself a protocol element and MUST |
| therefore use only CRLF to represent line breaks between body-parts. |  | therefore use only CRLF to represent line breaks between body-parts. |
| Unlike in RFC 2046, the epilogue of any multipart message MUST be |  | Unlike in RFC 2046, the epilogue of any multipart message MUST be |
| empty; HTTP applications MUST NOT transmit the epilogue (even if the |  | empty; HTTP applications MUST NOT transmit the epilogue (even if the |
| original multipart contains an epilogue). These restrictions exist 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 A.2) when it appears in a 206 |
| (Partial Content) response, which will be interpreted by some HTTP |  | (Partial Content) response, which will be interpreted by some HTTP |
| caching mechanisms as described in sections 13.5.4 and 14.16. In all |  | caching mechanisms as described in sections 13.5.4 and 14.16. In all |
| other cases, an HTTP user agent SHOULD follow the same or similar |  | other cases, an HTTP user agent SHOULD follow the same or similar |
| behavior as a MIME user agent would upon receipt of a multipart type. |  | behavior as a MIME user agent would upon receipt of a multipart type. |
| The MIME header fields within each body-part of a multipart message- |  | The MIME header fields within each body-part of a multipart message- |
| body do not have any significance to HTTP beyond that defined by |  | body do not have any significance to HTTP beyond that defined by |
| their MIME semantics. |  | their MIME semantics. |
| In general, an HTTP user agent SHOULD follow the same or similar |  | In general, an HTTP user agent SHOULD follow the same or similar |
| behavior as a MIME user agent would upon receipt of a multipart type. |  | behavior as a MIME user agent would upon receipt of a multipart type. |
| If an application receives an unrecognized multipart subtype, the |  | If an application receives an unrecognized multipart subtype, the |
| application MUST treat it as being equivalent to "multipart/mixed". |  | application MUST treat it as being equivalent to "multipart/mixed". |
| Note: The "multipart/form-data" type has been specifically defined |  | Note: The "multipart/form-data" type has been specifically defined |
| for carrying form data suitable for processing via the POST |  | for carrying form data suitable for processing via the POST |
| request method, as described in RFC 1867 [15]. |  | request method, as described in RFC 1867 [RFC1867]. |
| 3.8 Product Tokens |  | 3.8. Product Tokens |
| Product tokens are used to allow communicating applications to |  | Product tokens are used to allow communicating applications to |
| identify themselves by software name and version. Most fields using |  | identify themselves by software name and version. Most fields using |
| product tokens also allow sub-products which form a significant part |  | product tokens also allow sub-products which form a significant part |
| of the application to be listed, separated by white space. By |  | of the application to be listed, separated by white space. By |
| convention, the products are listed in order of their significance |  | convention, the products are listed in order of their significance |
| for identifying the application. |  | for identifying the application. |
| product = token ["/" product-version] |  | product = token ["/" product-version] |
| product-version = token |  | product-version = token |
| skipping to change at page 29, line 4 |  | skipping to change at page 31, line 44 |
| 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 |
| decimal point. User configuration of these values SHOULD also be |  | decimal point. User configuration of these values SHOULD also be |
| limited in this fashion. |  | limited in this fashion. |
| qvalue = ( "0" [ "." 0*3DIGIT ] ) |  | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
| | ( "1" [ "." 0*3("0") ] ) |  | | ( "1" [ "." 0*3("0") ] ) |
| "Quality values" is a misnomer, since these values merely represent |  | "Quality values" is a misnomer, since these values merely represent |
| relative degradation in desired quality. |  | relative degradation in desired quality. |
| 3.10 Language Tags |  | 3.10. Language Tags |
| A language tag identifies a natural language spoken, written, or |  | A language tag identifies a natural language spoken, written, or |
| otherwise conveyed by human beings for communication of information |  | otherwise conveyed by human beings for communication of information |
| to other human beings. Computer languages are explicitly excluded. |  | to other human beings. Computer languages are explicitly excluded. |
| HTTP uses language tags within the Accept-Language and Content- |  | HTTP uses language tags within the Accept-Language and Content- |
| Language fields. |  | Language fields. |
| The syntax and registry of HTTP language tags is the same as that |  | The syntax and registry of HTTP language tags is the same as that |
| defined by RFC 1766 [1]. In summary, a language tag is composed of 1 |  | defined by RFC 1766 [RFC1766]. In summary, a language tag is |
| or more parts: A primary language tag and a possibly empty series of |  | composed of 1 or more parts: A primary language tag and a possibly |
| subtags: |  | empty series of subtags: |
| language-tag = primary-tag *( "-" subtag ) |  | language-tag = primary-tag *( "-" subtag ) |
| primary-tag = 1*8ALPHA |  | primary-tag = 1*8ALPHA |
| subtag = 1*8ALPHA |  | subtag = 1*8ALPHA |
| White space is not allowed within the tag and all tags are case- |  | White space is not allowed within the tag and all tags are case- |
| insensitive. The name space of language tags is administered by the |  | insensitive. The name space of language tags is administered by the |
| IANA. Example tags include: |  | IANA. Example tags include: |
| en, en-US, en-cockney, i-cherokee, x-pig-latin |  | en, en-US, en-cockney, i-cherokee, x-pig-latin |
| skipping to change at page 30, line 4 |  | skipping to change at page 32, line 45 |
| 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 |
| could be substituted for each other with no significant change in |  | could be substituted for each other with no significant change in |
| semantics. A weak entity tag can only be used for weak comparison. |  | semantics. A weak entity tag can only be used for weak comparison. |
| An entity tag MUST be unique across all versions of all entities |  | An entity tag MUST be unique across all versions of all entities |
| associated with a particular resource. A given entity tag value MAY |  | associated with a particular resource. A given entity tag value MAY |
| be used for entities obtained by requests on different URIs. The use |  | be used for entities obtained by requests on different URIs. The use |
| of the same entity tag value in conjunction with entities obtained by |  | of the same entity tag value in conjunction with entities obtained by |
| requests on different URIs does not imply the equivalence of those |  | requests on different URIs does not imply the equivalence of those |
| entities. |  | entities. |
| 3.12 Range Units |  | 3.12. Range Units |
| HTTP/1.1 allows a client to request that only part (a range of) the |  | HTTP/1.1 allows a client to request that only part (a range of) the |
| response entity be included within the response. HTTP/1.1 uses range |  | response entity be included within the response. HTTP/1.1 uses range |
| units in the Range (section 14.35) and Content-Range (section 14.16) |  | units in the Range (Section 14.35) and Content-Range (Section 14.16) |
| header fields. An entity can be broken down into subranges according |  | header fields. An entity can be broken down into subranges according |
| to various structural units. |  | to various structural units. |
| range-unit = bytes-unit | other-range-unit |  | range-unit = bytes-unit | other-range-unit |
| bytes-unit = "bytes" |  | bytes-unit = "bytes" |
| other-range-unit = token |  | other-range-unit = token |
| The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |  | The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 |
| implementations MAY ignore ranges specified using other units. |  | implementations MAY ignore ranges specified using other units. |
| HTTP/1.1 has been designed to allow implementations of applications |  | HTTP/1.1 has been designed to allow implementations of applications |
| that do not depend on knowledge of ranges. |  | that do not depend on knowledge of ranges. |
| 4 HTTP Message |  | 4. HTTP Message |
| 4.1 Message Types |  | 4.1. Message Types |
| HTTP messages consist of requests from client to server and responses |  | HTTP messages consist of requests from client to server and responses |
| from server to client. |  | from server to client. |
| HTTP-message = Request | Response ; HTTP/1.1 messages |  | HTTP-message = Request | Response ; HTTP/1.1 messages |
| Request (section 5) and Response (section 6) messages use the generic |  | Request (Section 5) and Response (Section 6) messages use the generic |
| message format of RFC 822 [9] for transferring entities (the payload |  | message format of RFC 822 [RFC822] for transferring entities (the |
| of the message). Both types of message consist of a start-line, zero |  | payload of the message). Both types of message consist of a start- |
| or more header fields (also known as "headers"), an empty line (i.e., |  | line, zero or more header fields (also known as "headers"), an empty |
| a line with nothing preceding the CRLF) indicating the end of the |  | line (i.e., a line with nothing preceding the CRLF) indicating the |
| header fields, and possibly a message-body. |  | end of the 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 [RFC822]. Each header field |
| of a name followed by a colon (":") and the field value. Field names |  | consists of a name followed by a colon (":") and the field value. |
| are case-insensitive. The field value MAY be preceded by any amount |  | Field names are case-insensitive. The field value MAY be preceded by |
| of LWS, though a single SP is preferred. Header fields can be |  | any amount of LWS, though a single SP is preferred. Header fields |
| extended over multiple lines by preceding each extra line with at |  | can be extended over multiple lines by preceding each extra line with |
| least one SP or HT. Applications ought to follow "common form", where |  | at 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 38 |  | skipping to change at page 35, line 37 |
| present in a message if and only if the entire field-value for that |  | present in a message if and only if the entire field-value for that |
| header field is defined as a comma-separated list [i.e., #(values)]. |  | header field is defined as a comma-separated list [i.e., #(values)]. |
| It MUST be possible to combine the multiple header fields into one |  | It MUST be possible to combine the multiple header fields into one |
| "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 |
| "chunked" transfer-coding (section 3.6), thus allowing this mechanism |  | "chunked" transfer-coding (Section 3.6), thus allowing this mechanism |
| to be used for messages when the message length cannot be determined |  | to be used for messages when the message length cannot be determined |
| in advance. |  | in advance. |
| Messages MUST NOT include both a Content-Length header field and a |  | Messages MUST NOT include both a Content-Length header field and a |
| non-identity transfer-coding. If the message does include a non- |  | non-identity transfer-coding. If the message does include a non- |
| identity transfer-coding, the Content-Length MUST be ignored. |  | identity transfer-coding, the Content-Length MUST be ignored. |
| When a Content-Length is given in a message where a message-body is |  | When a Content-Length is given in a message where a message-body is |
| allowed, its field value MUST exactly match the number of OCTETs in |  | allowed, its field value MUST exactly match the number of OCTETs in |
| the message-body. HTTP/1.1 user agents MUST notify the user when an |  | the message-body. HTTP/1.1 user agents MUST notify the user when an |
| invalid length is received and detected. |  | invalid length is received and detected. |
| 4.5 General Header Fields |  | 4.5. General Header Fields |
| There are a few header fields which have general applicability for |  | There are a few header fields which have general applicability for |
| both request and response messages, but which do not apply to the |  | both request and response messages, but which do not apply to the |
| entity being transferred. These header fields apply only to the |  | entity being transferred. These header fields apply only to the |
| message being transmitted. |  | message being transmitted. |
| general-header = Cache-Control ; Section 14.9 |  | general-header = Cache-Control ; Section 14.9 |
| | Connection ; Section 14.10 |  | | Connection ; Section 14.10 |
| | Date ; Section 14.18 |  | | Date ; Section 14.18 |
| | Pragma ; Section 14.32 |  | | Pragma ; Section 14.32 |
| skipping to change at page 35, line 23 |  | skipping to change at page 38, line 22 |
| | Via ; Section 14.45 |  | | Via ; Section 14.45 |
| | Warning ; Section 14.46 |  | | Warning ; Section 14.46 |
| General-header field names can be extended reliably only in |  | General-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields may be given the semantics of general |  | experimental header fields may be given the semantics of general |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be general-header fields. Unrecognized header fields are treated as |  | be general-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 5 Request |  | 5. Request |
| A request message from a client to a server includes, within the |  | A request message from a client to a server includes, within the |
| first line of that message, the method to be applied to the resource, |  | first line of that message, the method to be applied to the resource, |
| the identifier of the resource, and the protocol version in use. |  | the identifier of the resource, and the protocol version in use. |
| Request = Request-Line ; Section 5.1 |  | Request = Request-Line ; Section 5.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 4.5 |
| | request-header ; Section 5.3 |  | | request-header ; Section 5.3 |
| | entity-header ) CRLF) ; Section 7.1 |  | | entity-header ) CRLF) ; Section 7.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 4.3 |  | [ message-body ] ; Section 4.3 |
| 5.1 Request-Line |  | 5.1. Request-Line |
| The Request-Line begins with a method token, followed by the |  | 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 |
| particular resource, but to the server itself, and is only allowed |  | particular resource, but to the server itself, and is only allowed |
| when the method used does not necessarily apply to a resource. One |  | when the method used does not necessarily apply to a resource. One |
| example would be |  | example would be |
| OPTIONS * HTTP/1.1 |  | OPTIONS * HTTP/1.1 |
| The absoluteURI form is REQUIRED when the request is being made to a |  | The absoluteURI form is REQUIRED when the request is being made to a |
| proxy. The proxy is requested to forward the request or service it |  | proxy. The proxy is requested to forward the request or service it |
| from a valid cache, and return the response. Note that the proxy MAY |  | from a valid cache, and return the response. Note that the proxy MAY |
| forward the request on to another proxy or directly to the server |  | forward the request on to another proxy or directly to the server |
| specified by the absoluteURI. In order to avoid request loops, a |  | specified by the absoluteURI. In order to avoid request loops, a |
| proxy MUST be able to recognize all of its server names, including |  | proxy MUST be able to recognize all of its server names, including |
| any aliases, local variations, and the numeric IP address. An 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). |
| The most common form of Request-URI is that used to identify a |  | The most common form of Request-URI is that used to identify a |
| resource on an origin server or gateway. In this case the absolute |  | resource on an origin server or gateway. In this case the absolute |
| path of the URI MUST be transmitted (see section 3.2.1, abs_path) as |  | path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as |
| the Request-URI, and the network location of the URI (authority) MUST |  | the Request-URI, and the network location of the URI (authority) MUST |
| be transmitted in a Host header field. For example, a client wishing |  | be transmitted in a Host header field. For example, a client wishing |
| to retrieve the resource above directly from the origin server would |  | to retrieve the resource above directly from the origin server would |
| create a TCP connection to port 80 of the host "www.w3.org" and send |  | create a TCP connection to port 80 of the host "www.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 path |  | followed by the remainder of the Request. Note that the absolute |
| cannot be empty; if none is present in the original URI, it MUST be |  | path cannot be empty; if none is present in the original URI, it MUST |
| given as "/" (the server root). |  | be given as "/" (the server root). |
| The Request-URI is transmitted in the format specified in section |  | The Request-URI is transmitted in the format specified in |
| 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding |  | Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" |
| [42], the origin server MUST decode the Request-URI in order to |  | encoding [RFC2396], the origin server MUST decode the Request-URI in |
| properly interpret the request. Servers SHOULD respond to invalid |  | order to properly interpret the request. Servers SHOULD respond to |
| Request-URIs with an appropriate status code. |  | invalid Request-URIs with an appropriate status code. |
| A transparent proxy MUST NOT rewrite the "abs_path" part of the |  | A transparent proxy MUST NOT rewrite the "abs_path" part of the |
| received Request-URI when forwarding it to the next inbound server, |  | received Request-URI when forwarding it to the next inbound server, |
| except as noted above to replace a null abs_path with "/". |  | except as noted above to replace a null abs_path with "/". |
| Note: The "no rewrite" rule prevents the proxy from changing the |  | Note: The "no rewrite" rule prevents the proxy from changing the |
| meaning of the request when the origin server is improperly using |  | meaning of the request when the origin server is improperly using |
| a non-reserved URI character for a reserved purpose. Implementors |  | a non-reserved URI character for a reserved purpose. Implementors |
| should be aware that some pre-HTTP/1.1 proxies have been known to |  | should be aware that some pre-HTTP/1.1 proxies have been known to |
| rewrite the Request-URI. |  | rewrite the Request-URI. |
| 5.2 The Resource Identified by a Request |  | 5.2. The Resource Identified by a Request |
| The exact resource identified by an Internet request is determined by |  | The exact resource identified by an Internet request is determined by |
| examining both the Request-URI and the Host header field. |  | examining both the Request-URI and the Host header field. |
| An origin server that does not allow resources to differ by the |  | An origin server that does not allow resources to differ by the |
| requested host MAY ignore the Host header field value when |  | requested host MAY ignore the Host header field value when |
| determining the resource identified by an HTTP/1.1 request. (But see |  | determining the resource identified by an HTTP/1.1 request. (But see |
| section 19.6.1.1 for other requirements on Host support in HTTP/1.1.) |  | Appendix A.6.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 |
| server. These fields act as request modifiers, with semantics |  | server. These fields act as request modifiers, with semantics |
| equivalent to the parameters on a programming language method |  | equivalent to the parameters on a programming language method |
| invocation. |  | invocation. |
| request-header = Accept ; Section 14.1 |  | request-header = Accept ; Section 14.1 |
| | Accept-Charset ; Section 14.2 |  | | Accept-Charset ; Section 14.2 |
| | Accept-Encoding ; Section 14.3 |  | | Accept-Encoding ; Section 14.3 |
| skipping to change at page 39, line 22 |  | skipping to change at page 42, line 32 |
| | TE ; Section 14.39 |  | | TE ; Section 14.39 |
| | User-Agent ; Section 14.43 |  | | User-Agent ; Section 14.43 |
| Request-header field names can be extended reliably only in |  | Request-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of request- |  | experimental header fields MAY be given the semantics of request- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be request-header fields. Unrecognized header fields are treated as |  | be request-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 6 Response |  | 6. Response |
| After receiving and interpreting a request message, a server responds |  | After receiving and interpreting a request message, a server responds |
| with an HTTP response message. |  | with an HTTP response message. |
| Response = Status-Line ; Section 6.1 |  | Response = Status-Line ; Section 6.1 |
| *(( general-header ; Section 4.5 |  | *(( general-header ; Section 4.5 |
| | response-header ; Section 6.2 |  | | response-header ; Section 6.2 |
| | entity-header ) CRLF) ; Section 7.1 |  | | entity-header ) CRLF) ; Section 7.1 |
| CRLF |  | CRLF |
| [ message-body ] ; Section 7.2 |  | [ message-body ] ; Section 7.2 |
| 6.1 Status-Line |  | 6.1. Status-Line |
| The first line of a Response message is the Status-Line, consisting |  | The first line of a Response message is the Status-Line, consisting |
| of the protocol version followed by a numeric status code and its |  | of the protocol version followed by a numeric status code and its |
| associated textual phrase, with each element separated by SP |  | associated textual phrase, with each element separated by SP |
| characters. No CR or LF is allowed except in the final CRLF 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 |
| - 5xx: Server Error - The server failed to fulfill an apparently |  | o 5xx: Server Error - The server failed to fulfill an apparently |
| valid request |  | valid request |
| The individual values of the numeric status codes defined for |  | The individual values of the numeric status codes defined for |
| HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |  | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are |
| presented below. The reason phrases listed here are only |  | presented below. The reason phrases listed here are only |
| recommendations -- they MAY be replaced by local equivalents without |  | recommendations -- they MAY be replaced by local equivalents without |
| affecting the protocol. |  | affecting the protocol. |
| Status-Code = |  | Status-Code = |
| "100" ; Section 10.1.1: Continue |  | "100" ; Section 10.1.1: Continue |
| skipping to change at page 41, line 40 |  | skipping to change at page 45, line 16 |
| digit, and treat any unrecognized response as being equivalent to the |  | digit, and treat any unrecognized response as being equivalent to the |
| x00 status code of that class, with the exception that an |  | x00 status code of that class, with the exception that an |
| unrecognized response MUST NOT be cached. For example, if an |  | unrecognized response MUST NOT be cached. For example, if an |
| unrecognized status code of 431 is received by the client, it can |  | unrecognized status code of 431 is received by the client, it can |
| safely assume that there was something wrong with its request and |  | safely assume that there was something wrong with its request and |
| 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 |
| Response-header field names can be extended reliably only in |  | Response-header field names can be extended reliably only in |
| combination with a change in the protocol version. However, new or |  | combination with a change in the protocol version. However, new or |
| experimental header fields MAY be given the semantics of response- |  | experimental header fields MAY be given the semantics of response- |
| header fields if all parties in the communication recognize them to |  | header fields if all parties in the communication recognize them to |
| be response-header fields. Unrecognized header fields are treated as |  | be response-header fields. Unrecognized header fields are treated as |
| entity-header fields. |  | entity-header fields. |
| 7 Entity |  | 7. Entity |
| Request and Response messages MAY transfer an entity if not otherwise |  | Request and Response messages MAY transfer an entity if not otherwise |
| restricted by the request method or response status code. An entity |  | restricted by the request method or response status code. An entity |
| consists of entity-header fields and an entity-body, although some |  | consists of entity-header fields and an entity-body, although some |
| responses will only include the entity-headers. |  | responses will only include the entity-headers. |
| In this section, both sender and recipient refer to either the client |  | In this section, both sender and recipient refer to either the client |
| or the server, depending on who sends and who receives the entity. |  | or the server, depending on who sends and who receives the entity. |
| 7.1 Entity Header Fields |  | 7.1. Entity Header Fields |
| Entity-header fields define metainformation about the entity-body or, |  | Entity-header fields define metainformation about the entity-body or, |
| if no body is present, about the resource identified by the request. |  | if no body is present, about the resource identified by the request. |
| Some of this metainformation is OPTIONAL; some might be REQUIRED by |  | Some of this metainformation is OPTIONAL; some might be REQUIRED by |
| portions of this specification. |  | portions of this specification. |
| entity-header = Allow ; Section 14.7 |  | entity-header = Allow ; Section 14.7 |
| | Content-Encoding ; Section 14.11 |  | | Content-Encoding ; Section 14.11 |
| | Content-Language ; Section 14.12 |  | | Content-Language ; Section 14.12 |
| | Content-Length ; Section 14.13 |  | | Content-Length ; Section 14.13 |
| skipping to change at page 43, line 5 |  | skipping to change at page 46, line 32 |
| | extension-header |  | | extension-header |
| extension-header = message-header |  | extension-header = message-header |
| The extension-header mechanism allows additional entity-header fields |  | The extension-header mechanism allows additional entity-header fields |
| to be defined without changing the protocol, but these fields cannot |  | to be defined without changing the protocol, but these fields cannot |
| be assumed to be recognizable by the recipient. Unrecognized header |  | be assumed to be recognizable by the recipient. Unrecognized header |
| fields SHOULD be ignored by the recipient and MUST be forwarded by |  | fields SHOULD be ignored by the recipient and MUST be forwarded by |
| transparent proxies. |  | transparent proxies. |
| 7.2 Entity Body |  | 7.2. Entity Body |
| The entity-body (if any) sent with an HTTP request or response is in |  | The entity-body (if any) sent with an HTTP request or response is in |
| a format and encoding defined by the entity-header fields. |  | a format and encoding defined by the entity-header fields. |
| entity-body = *OCTET |  | entity-body = *OCTET |
| An entity-body is only present in a message when a message-body is |  | An entity-body is only present in a message when a message-body is |
| present, as described in section 4.3. The entity-body is obtained |  | present, as described in Section 4.3. The entity-body is obtained |
| from the message-body by decoding any Transfer-Encoding that might |  | from the message-body by decoding any Transfer-Encoding that might |
| have been applied to ensure safe and proper transfer of the message. |  | have been applied to ensure safe and proper transfer of the message. |
| 7.2.1 Type |  | 7.2.1. Type |
| When an entity-body is included with a message, the data type of that |  | When an entity-body is included with a message, the data type of that |
| body is determined via the header fields Content-Type and Content- |  | body is determined via the header fields Content-Type and Content- |
| Encoding. These define a two-layer, ordered encoding model: |  | Encoding. These define a two-layer, ordered encoding model: |
| entity-body := Content-Encoding( Content-Type( data ) ) |  | entity-body := Content-Encoding( Content-Type( data ) ) |
| Content-Type specifies the media type of the underlying data. |  | Content-Type specifies the media type of the underlying data. |
| Content-Encoding may be used to indicate any additional content |  | Content-Encoding may be used to indicate any additional content |
| codings applied to the data, usually for the purpose of data |  | codings applied to the data, usually for the purpose of data |
| compression, that are a property of the requested resource. There is |  | compression, that are a property of the requested resource. There is |
| no default encoding. |  | no default encoding. |
| Any HTTP/1.1 message containing an entity-body SHOULD include a |  | Any HTTP/1.1 message containing an entity-body SHOULD include a |
| 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 |
| skipping to change at page 43, line 39 |  | skipping to change at page 47, line 18 |
| no default encoding. |  | no default encoding. |
| Any HTTP/1.1 message containing an entity-body SHOULD include a |  | Any HTTP/1.1 message containing an entity-body SHOULD include a |
| 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 [Pad1995] [Spe]. Implementation |
| measurements of actual HTTP/1.1 (RFC 2068) implementations show good |  | experience and measurements of actual HTTP/1.1 (RFC 2068) |
| results [39]. Alternatives have also been explored, for example, |  | implementations show good results [Nie1997]. Alternatives have also |
| T/TCP [27]. |  | been explored, for example, T/TCP [Tou1998]. |
| Persistent HTTP connections have a number of advantages: |  | Persistent HTTP connections have a number of advantages: |
| - 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 A.6.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 [RFC2068] for information |
| discussion of the problems with the Keep-Alive header implemented by |  | and discussion of the problems with the Keep-Alive header implemented |
| many HTTP/1.0 clients). |  | by many HTTP/1.0 clients). |
| 8.1.4 Practical Considerations |  | 8.1.4. Practical Considerations |
| Servers will usually have some time-out value beyond which they will |  | Servers will usually have some time-out value beyond which they will |
| no longer maintain an inactive connection. Proxy servers might make |  | no longer maintain an inactive connection. Proxy servers might make |
| this a higher value since it is likely that the client will be making |  | this a higher value since it is likely that the client will be making |
| more connections through the same server. The use of persistent |  | more connections through the same server. The use of persistent |
| connections places no requirements on the length (or existence) of |  | connections places no requirements on the length (or existence) of |
| this time-out for either the client or the server. |  | this time-out for either the client or the server. |
| When a client or server wishes to time-out it SHOULD issue a graceful |  | When a client or server wishes to time-out it SHOULD issue a graceful |
| close on the transport connection. Clients and servers SHOULD both |  | close on the transport connection. Clients and servers SHOULD both |
| skipping to change at page 47, line 23 |  | skipping to change at page 50, line 32 |
| time. For example, a client might have started to send a new request |  | time. For example, a client might have started to send a new request |
| at the same time that the server has decided to close the "idle" |  | at the same time that the server has decided to close the "idle" |
| 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 |
| single-user client SHOULD NOT maintain more than 2 connections with |  | single-user client SHOULD NOT maintain more than 2 connections with |
| any server or proxy. A proxy SHOULD use up to 2*N connections to |  | any server or proxy. A proxy SHOULD use up to 2*N connections to |
| another server or proxy, where N is the number of simultaneously |  | another server or proxy, where N is the number of simultaneously |
| active users. These guidelines are intended to improve HTTP response |  | active users. These guidelines are intended to improve HTTP response |
| times and avoid congestion. |  | times and avoid congestion. |
| 8.2 Message Transmission Requirements |  | 8.2. Message Transmission Requirements |
| 8.2.1 Persistent Connections and Flow Control |  | 8.2.1. Persistent Connections and Flow Control |
| HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |  | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
| flow control mechanisms to resolve temporary overloads, rather than |  | flow control mechanisms to resolve temporary overloads, rather than |
| terminating connections with the expectation that clients will retry. |  | terminating connections with the expectation that clients will retry. |
| The latter technique can exacerbate network congestion. |  | The latter technique can exacerbate network congestion. |
| 8.2.2 Monitoring Connections for Error Status Messages |  | 8.2.2. Monitoring Connections for Error Status Messages |
| An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |  | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
| the network connection for an error status while it is transmitting |  | the network connection for an error status while it is transmitting |
| the request. If the client sees an error status, it SHOULD |  | the request. If the client sees an error status, it SHOULD |
| immediately cease transmitting the body. If the body is being sent |  | immediately cease transmitting the body. If the body is being sent |
| using a "chunked" encoding (section 3.6), a zero length chunk and |  | using a "chunked" encoding (Section 3.6), a zero length chunk and |
| empty trailer MAY be used to prematurely mark the end of the message. |  | empty trailer MAY be used to prematurely mark the end of the message. |
| If the body was preceded by a Content-Length header, the client MUST |  | If the body was preceded by a Content-Length header, the client MUST |
| close the connection. |  | close the connection. |
| 8.2.3 Use of the 100 (Continue) Status |  | 8.2.3. Use of the 100 (Continue) Status |
| 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" |
| algorithm to be assured of obtaining a reliable response: |  | algorithm to be assured of obtaining a reliable response: |
| 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 |
| unexpected significance to themselves or others. |  | unexpected significance to themselves or others. |
| In particular, the convention has been established that the GET and |  | In particular, the convention has been established that the GET and |
| HEAD methods SHOULD NOT have the significance of taking an action |  | HEAD methods SHOULD NOT have the significance of taking an action |
| other than retrieval. These methods ought to be considered "safe". |  | other than retrieval. These methods ought to be considered "safe". |
| This allows user agents to represent other methods, such as POST, PUT |  | This allows user agents to represent other methods, such as POST, PUT |
| and DELETE, in a special way, so that the user is made aware of the |  | and DELETE, in a special way, so that the user is made aware of the |
| fact that a possibly unsafe action is being requested. |  | fact that a possibly unsafe action is being requested. |
| Naturally, it is not possible to ensure that the server does not |  | Naturally, it is not possible to ensure that the server does not |
| generate side-effects as a result of performing a GET request; in |  | generate side-effects as a result of performing a GET request; in |
| fact, some dynamic resources consider that a feature. The important |  | fact, some dynamic resources consider that a feature. The important |
| distinction here is that the user did not request the side-effects, |  | distinction here is that the user did not request the side-effects, |
| so therefore cannot be held accountable for them. |  | so therefore cannot be held accountable for them. |
| 9.1.2 Idempotent Methods |  | 9.1.2. Idempotent Methods |
| Methods can also have the property of "idempotence" in that (aside |  | Methods can also have the property of "idempotence" in that (aside |
| from error or expiration issues) the side-effects of N > 0 identical |  | from error or expiration issues) the side-effects of N > 0 identical |
| requests is the same as for a single request. The methods GET, HEAD, |  | requests is the same as for a single request. The methods GET, HEAD, |
| PUT and DELETE share this property. Also, the methods OPTIONS and |  | PUT and DELETE share this property. Also, the methods OPTIONS and |
| TRACE SHOULD NOT have side effects, and so are inherently idempotent. |  | TRACE SHOULD NOT have side effects, and so are inherently idempotent. |
| However, it is possible that a sequence of several requests is non- |  | However, it is possible that a sequence of several requests is non- |
| idempotent, even if all of the methods executed in that sequence are |  | idempotent, even if all of the methods executed in that sequence are |
| idempotent. (A sequence is idempotent if a single execution of the |  | idempotent. (A sequence is idempotent if a single execution of the |
| entire sequence always yields a result that is not changed by a |  | entire sequence always yields a result that is not changed by a |
| reexecution of all, or part, of that sequence.) For example, a |  | reexecution of all, or part, of that sequence.) For example, a |
| sequence is non-idempotent if its result depends on a value that is |  | sequence is non-idempotent if its result depends on a value that is |
| later modified in the same sequence. |  | later modified in the same sequence. |
| A sequence that never has side effects is idempotent, by definition |  | A sequence that never has side effects is idempotent, by definition |
| (provided that no concurrent operations are being executed on the |  | (provided that no concurrent operations are being executed on the |
| same set of resources). |  | same set of resources). |
| 9.2 OPTIONS |  | 9.2. OPTIONS |
| The OPTIONS method represents a request for information about the |  | The OPTIONS method represents a request for information about the |
| communication options available on the request/response chain |  | communication options available on the request/response chain |
| identified by the Request-URI. This method allows the client to |  | identified by the Request-URI. This method allows the client to |
| determine the options and/or requirements associated with a resource, |  | determine the options and/or requirements associated with a resource, |
| or the capabilities of a server, without implying a resource action |  | or the capabilities of a server, without implying a resource action |
| or initiating a resource retrieval. |  | or initiating a resource retrieval. |
| Responses to this method are not cacheable. |  | Responses to this method are not cacheable. |
| skipping to change at page 52, line 41 |  | skipping to change at page 55, line 43 |
| 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 |
| existing resource, the enclosed entity SHOULD be considered as a |  | existing resource, the enclosed entity SHOULD be considered as a |
| modified version of the one residing on the origin server. If the |  | modified version of the one residing on the origin server. If the |
| Request-URI does not point to an existing resource, and that URI is |  | Request-URI does not point to an existing resource, and that URI is |
| capable of being defined as a new resource by the requesting user |  | capable of being defined as a new resource by the requesting user |
| agent, the origin server can create the resource with that URI. If a |  | agent, the origin server can create the resource with that URI. If a |
| new resource is created, the origin server MUST inform the user agent |  | new resource is created, the origin server MUST inform the user agent |
| 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 [Luo1998]). |
| 10 Status Code Definitions |  | 10. Status Code Definitions |
| Each Status-Code is described below, including a description of which |  | Each Status-Code is described below, including a description of which |
| method(s) it can follow and any metainformation required in the |  | method(s) it can follow and any metainformation required in the |
| response. |  | response. |
| 10.1 Informational 1xx |  | 10.1. Informational 1xx |
| This class of status code indicates a provisional response, |  | This class of status code indicates a provisional response, |
| consisting only of the Status-Line and optional headers, and is |  | consisting only of the Status-Line and optional headers, and is |
| terminated by an empty line. There are no required headers for this |  | terminated by an empty line. There are no required headers for this |
| class of status code. Since HTTP/1.0 did not define any 1xx status |  | class of status code. Since HTTP/1.0 did not define any 1xx status |
| codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client |  | codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client |
| except under experimental conditions. |  | except under experimental conditions. |
| A client MUST be prepared to accept one or more 1xx status responses |  | A client MUST be prepared to accept one or more 1xx status responses |
| prior to a regular response, even if the client does not expect a 100 |  | prior to a regular response, even if the client does not expect a 100 |
| (Continue) status message. Unexpected 1xx status responses MAY be |  | (Continue) status message. Unexpected 1xx status responses MAY be |
| ignored by a user agent. |  | ignored by a user agent. |
| 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 |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The entity format is specified by |  | choose the one most appropriate. The entity format is specified by |
| the media type given in the Content-Type header field. The origin |  | the media type given in the Content-Type header field. The origin |
| server MUST create the resource before returning the 201 status code. |  | server MUST create the resource before returning the 201 status code. |
| If the action cannot be carried out immediately, the server SHOULD |  | If the action cannot be carried out immediately, the server SHOULD |
| respond with 202 (Accepted) response instead. |  | respond with 202 (Accepted) response instead. |
| A 201 response MAY contain an ETag response header field indicating |  | A 201 response MAY contain an ETag response header field indicating |
| the current value of the entity tag for the requested variant just |  | the current value of the entity tag for the requested variant just |
| created, see section 14.19. |  | created, see Section 14.19. |
| 10.2.3 202 Accepted |  | 10.2.3. 202 Accepted |
| The request has been accepted for processing, but the processing has |  | The request has been accepted for processing, but the processing has |
| not been completed. The request might or might not eventually be |  | not been completed. The request might or might not eventually be |
| acted upon, as it might be disallowed when processing actually takes |  | acted upon, as it might be disallowed when processing actually takes |
| place. There is no facility for re-sending a status code from an |  | place. There is no facility for re-sending a status code from an |
| asynchronous operation such as this. |  | asynchronous operation such as this. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| allow a server to accept a request for some other process (perhaps a |  | allow a server to accept a request for some other process (perhaps a |
| batch-oriented process that is only run once per day) without |  | batch-oriented process that is only run once per day) without |
| 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. |
| If the client is a user agent, it SHOULD NOT change its document view |  | If the client is a user agent, it SHOULD NOT change its document view |
| from that which caused the request to be sent. This response is |  | from that which caused the request to be sent. This response is |
| primarily intended to allow input for actions to take place without |  | primarily intended to allow input for actions to take place without |
| causing a change to the user agent's active document view, although |  | causing a change to the user agent's active document view, although |
| any new or updated metainformation SHOULD be applied to the document |  | any new or updated metainformation SHOULD be applied to the document |
| currently in the user agent's active view. |  | currently in the user agent's active view. |
| The 204 response MUST NOT include a message-body, and thus is always |  | The 204 response MUST NOT include a message-body, and thus is always |
| terminated by the first empty line after the header fields. |  | terminated by the first empty line after the header fields. |
| 10.2.6 205 Reset Content |  | 10.2.6. 205 Reset Content |
| The server has fulfilled the request and the user agent SHOULD reset |  | The server has fulfilled the request and the user agent SHOULD reset |
| the document view which caused the request to be sent. This response |  | the document view which caused the request to be sent. This response |
| is primarily intended to allow input for actions to take place via |  | is primarily intended to allow input for actions to take place via |
| user input, followed by a clearing of the form in which the input is |  | user input, followed by a clearing of the form in which the input is |
| given so that the user can easily initiate another input action. The |  | given so that the user can easily initiate another input action. The |
| response MUST NOT include an entity. |  | response MUST NOT include an entity. |
| 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 |  |  |
| - ETag and/or Content-Location, if the header would have been sent |  | o Date |
|  |  | 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 |
| with a 200 (OK) response to the same request. |  | with a 200 (OK) response to the same request. |
| A cache MUST NOT combine a 206 response with other previously cached |  | A cache MUST NOT combine a 206 response with other previously cached |
| content if the ETag or Last-Modified headers do not match exactly, |  | content if the ETag or Last-Modified headers do not match exactly, |
| see 13.5.4. |  | see 13.5.4. |
| A cache that does not support the Range and Content-Range headers |  | A cache that does not support the Range and Content-Range headers |
| MUST NOT cache 206 (Partial) responses. |  | MUST NOT cache 206 (Partial) responses. |
| 10.3 Redirection 3xx |  | 10.3. Redirection 3xx |
| 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- |  |  |
| Type header field. Depending upon the format and the capabilities of |  | The entity format is specified by the media type given in the |
| the user agent, selection of the most appropriate choice MAY be |  | Content-Type header field. Depending upon the format and the |
| performed automatically. However, this specification does not define |  | capabilities of the user agent, selection of the most appropriate |
| any standard for such automatic selection. |  | choice MAY be performed automatically. However, this specification |
|  |  | 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 |
| URIs. Clients with link editing capabilities ought to automatically |  | URIs. Clients with link editing capabilities ought to automatically |
| re-link references to the Request-URI to one or more of the new |  | re-link references to the Request-URI to one or more of the new |
| references returned by the server, where possible. This response is |  | references returned by the server, where possible. This response is |
| cacheable unless indicated otherwise. |  | cacheable unless indicated otherwise. |
| The new permanent URI SHOULD be given by the Location field in the |  | The new permanent URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| skipping to change at page 62, line 36 |  | skipping to change at page 65, line 39 |
| If the 301 status code is received in response to a request other |  | If the 301 status code is received in response to a request 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. |
| Note: When automatically redirecting a POST request after |  | Note: When automatically redirecting a POST request after |
| receiving a 301 status code, some existing HTTP/1.0 user agents |  | receiving a 301 status code, some existing HTTP/1.0 user agents |
| will erroneously change it into a GET request. |  | will erroneously change it into a GET request. |
| 10.3.3 302 Found |  | 10.3.3. 302 Found |
| The requested resource resides temporarily under a different URI. |  | The requested resource resides temporarily under a different URI. |
| Since the redirection might be altered on occasion, the client SHOULD |  | Since the redirection might be altered on occasion, the client SHOULD |
| continue to use the Request-URI for future requests. This response |  | continue to use the Request-URI for future requests. This response |
| is only cacheable if indicated by a Cache-Control or Expires header |  | is only cacheable if indicated by a Cache-Control or Expires header |
| field. |  | field. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| skipping to change at page 63, line 18 |  | skipping to change at page 66, line 16 |
| change the conditions under which the request was issued. |  | change the conditions under which the request was issued. |
| Note: RFC 1945 and RFC 2068 specify that the client is not allowed |  | Note: RFC 1945 and RFC 2068 specify that the client is not allowed |
| to change the method on the redirected request. However, most |  | to change the method on the redirected request. However, most |
| existing user agent implementations treat 302 as if it were a 303 |  | existing user agent implementations treat 302 as if it were a 303 |
| response, performing a GET on the Location field-value regardless |  | response, performing a GET on the Location field-value regardless |
| of the original request method. The status codes 303 and 307 have |  | of the original request method. The status codes 303 and 307 have |
| been added for servers that wish to make unambiguously clear which |  | been added for servers that wish to make unambiguously clear which |
| kind of reaction is expected of the client. |  | kind of reaction is expected of the client. |
| 10.3.4 303 See Other |  | 10.3.4. 303 See Other |
| The response to the request can be found under a different URI and |  | The response to the request can be found under a different URI and |
| SHOULD be retrieved using a GET method on that resource. This method |  | SHOULD be retrieved using a GET method on that resource. This method |
| exists primarily to allow the output of a POST-activated script to |  | exists primarily to allow the output of a POST-activated script to |
| redirect the user agent to a selected resource. The new URI is not a |  | redirect the user agent to a selected resource. The new URI is not a |
| substitute reference for the originally requested resource. The 303 |  | substitute reference for the originally requested resource. The 303 |
| response MUST NOT be cached, but the response to the second |  | response MUST NOT be cached, but the response to the second |
| (redirected) request might be cacheable. |  | (redirected) request might be cacheable. |
| The different URI SHOULD be given by the Location field in the |  | The different URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s). |  | the new URI(s). |
| Note: Many pre-HTTP/1.1 user agents do not understand the 303 |  | Note: Many pre-HTTP/1.1 user agents do not understand the 303 |
| status. When interoperability with such clients is a concern, the |  | status. When interoperability with such clients is a concern, the |
| 302 status code may be used instead, since most user agents react |  | 302 status code may be used instead, since most user agents react |
| to a 302 response as described here for 303. |  | to a 302 response as described here for 303. |
| 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 |
| The requested resource MUST be accessed through the proxy given by |  | The requested resource MUST be accessed through the proxy given by |
| the Location field. The Location field gives the URI of the proxy. |  | the Location field. The Location field gives the URI of the proxy. |
| The recipient is expected to repeat this single request via the |  | The recipient is expected to repeat this single request via the |
| proxy. 305 responses MUST only be generated by origin servers. |  | proxy. 305 responses MUST only be generated by origin servers. |
| Note: RFC 2068 was not clear that 305 was intended to redirect a |  | Note: RFC 2068 was not clear that 305 was intended to redirect a |
| single request, and to be generated by origin servers only. Not |  | single request, and to be generated by origin servers only. Not |
| observing these limitations has significant security consequences. |  | observing these limitations has significant security consequences. |
| 10.3.7 306 (Unused) |  | 10.3.7. 306 (Unused) |
| The 306 status code was used in a previous version of the |  | The 306 status code was used in a previous version of the |
| specification, is no longer used, and the code is reserved. |  | specification, is no longer used, and the code is reserved. |
| 10.3.8 307 Temporary Redirect |  | 10.3.8. 307 Temporary Redirect |
| The requested resource resides temporarily under a different URI. |  | The requested resource resides temporarily under a different URI. |
| Since the redirection MAY be altered on occasion, the client SHOULD |  | Since the redirection MAY be altered on occasion, the client SHOULD |
| continue to use the Request-URI for future requests. This response |  | continue to use the Request-URI for future requests. This response |
| is only cacheable if indicated by a Cache-Control or Expires header |  | is only cacheable if indicated by a Cache-Control or Expires header |
| field. |  | field. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s) , since many pre-HTTP/1.1 user agents do not |  | the new URI(s) , since many pre-HTTP/1.1 user agents do not |
| understand the 307 status. Therefore, the note SHOULD contain the |  | understand the 307 status. Therefore, the note SHOULD contain the |
| information necessary for a user to repeat the original request on |  | information necessary for a user to repeat the original request on |
| the new URI. |  | the new URI. |
| If the 307 status code is received in response to a request other |  | If the 307 status code is received in response to a request 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" [RFC2617]. |
| 10.4.3 402 Payment Required |  | 10.4.3. 402 Payment Required |
| This code is reserved for future use. |  | This code is reserved for future use. |
| 10.4.4 403 Forbidden |  | 10.4.4. 403 Forbidden |
| The server understood the request, but is refusing to fulfill it. |  | The server understood the request, but is refusing to fulfill it. |
| Authorization will not help and the request SHOULD NOT be repeated. |  | Authorization will not help and the request SHOULD NOT be repeated. |
| If the request method was not HEAD and the server wishes to make |  | If the request method was not HEAD and the server wishes to make |
| public why the request has not been fulfilled, it SHOULD describe the |  | public why the request has not been fulfilled, it SHOULD describe the |
| reason for the refusal in the entity. If the server does not wish to |  | reason for the refusal in the entity. If the server does not wish to |
| make this information available to the client, the status code 404 |  | make this information available to the client, the status code 404 |
| (Not Found) can be used instead. |  | (Not Found) can be used instead. |
| 10.4.5 404 Not Found |  | 10.4.5. 404 Not Found |
| The server has not found anything matching the Request-URI. No |  | The server has not found anything matching the Request-URI. No |
| indication is given of whether the condition is temporary or |  | indication is given of whether the condition is temporary or |
| permanent. The 410 (Gone) status code SHOULD be used if the server |  | permanent. The 410 (Gone) status code SHOULD be used if the server |
| knows, through some internally configurable mechanism, that an old |  | knows, through some internally configurable mechanism, that an old |
| resource is permanently unavailable and has no forwarding address. |  | resource is permanently unavailable and has no forwarding address. |
| This status code is commonly used when the server does not wish to |  | This status code is commonly used when the server does not wish to |
| reveal exactly why the request has been refused, or when no other |  | reveal exactly why the request has been refused, or when no other |
| response is applicable. |  | response is applicable. |
| 10.4.6 405 Method Not Allowed |  | 10.4.6. 405 Method Not Allowed |
| The method specified in the Request-Line is not allowed for the |  | The method specified in the Request-Line is not allowed for the |
| resource identified by the Request-URI. The response MUST include an |  | resource identified by the Request-URI. The response MUST include an |
| Allow header containing a list of valid methods for the requested |  | Allow header containing a list of valid methods for the requested |
| resource. |  | resource. |
| 10.4.7 406 Not Acceptable |  | 10.4.7. 406 Not Acceptable |
| The resource identified by the request is only capable of generating |  | The resource identified by the request is only capable of generating |
| response entities which have content characteristics not acceptable |  | response entities which have content characteristics not acceptable |
| according to the accept headers sent in the request. |  | according to the accept headers sent in the request. |
| 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 available entity characteristics and location(s) |  | containing a list of available entity characteristics and location(s) |
| 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" [RFC2617]. |
| 10.4.9 408 Request Timeout |  | 10.4.9. 408 Request Timeout |
| The client did not produce a request within the time that the server |  | The client did not produce a request within the time that the server |
| was prepared to wait. The client MAY repeat the request without |  | was prepared to wait. The client MAY repeat the request without |
| modifications at any later time. |  | modifications at any later time. |
| 10.4.10 409 Conflict |  | 10.4.10. 409 Conflict |
| The request could not be completed due to a conflict with the current |  | The request could not be completed due to a conflict with the current |
| state of the resource. This code is only allowed in situations where |  | state of the resource. This code is only allowed in situations where |
| it is expected that the user might be able to resolve the conflict |  | it is expected that the user might be able to resolve the conflict |
| and resubmit the request. The response body SHOULD include enough |  | and resubmit the request. The response body SHOULD include enough |
| information for the user to recognize the source of the conflict. |  | information for the user to recognize the source of the conflict. |
| 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 |
| in the request message. |  | in the request message. |
| 10.4.13 412 Precondition Failed |  | 10.4.13. 412 Precondition Failed |
| The precondition given in one or more of the request-header fields |  | The precondition given in one or more of the request-header fields |
| evaluated to false when it was tested on the server. This response |  | evaluated to false when it was tested on the server. This response |
| code allows the client to place preconditions on the current resource |  | code allows the client to place preconditions on the current resource |
| metainformation (header field data) and thus prevent the requested |  | metainformation (header field data) and thus prevent the requested |
| method from being applied to a resource other than the one intended. |  | method from being applied to a resource other than the one intended. |
| 10.4.14 413 Request Entity Too Large |  | 10.4.14. 413 Request Entity Too Large |
| The server is refusing to process a request because the request |  | The server is refusing to process a request because the request |
| entity is larger than the server is willing or able to process. The |  | entity is larger than the server is willing or able to process. The |
| server MAY close the connection to prevent the client from continuing |  | server MAY close the connection to prevent the client from continuing |
| the request. |  | the request. |
| If the condition is temporary, the server SHOULD include a Retry- |  | If the condition is temporary, the server SHOULD include a Retry- |
| After header field to indicate that it is temporary and after what |  | After header field to indicate that it is temporary and after what |
| time the client MAY try again. |  | time the client MAY try again. |
| 10.4.15 414 Request-URI Too Long |  | 10.4.15. 414 Request-URI Too Long |
| The server is refusing to service the request because the Request-URI |  | The server is refusing to service the request because the Request-URI |
| is longer than the server is willing to interpret. This rare |  | is longer than the server is willing to interpret. This rare |
| condition is only likely to occur when a client has improperly |  | condition is only likely to occur when a client has improperly |
| converted a POST request to a GET request with long query |  | converted a POST request to a GET request with long query |
| information, when the client has descended into a URI "black hole" of |  | information, when the client has descended into a URI "black hole" of |
| redirection (e.g., a redirected URI prefix that points to a suffix of |  | redirection (e.g., a redirected URI prefix that points to a suffix of |
| itself), or when the server is under attack by a client attempting to |  | itself), or when the server is under attack by a client attempting to |
| exploit security holes present in some servers using fixed-length |  | exploit security holes present in some servers using fixed-length |
| buffers for reading or manipulating the Request-URI. |  | buffers for reading or manipulating the Request-URI. |
| 10.4.16 415 Unsupported Media Type |  | 10.4.16. 415 Unsupported Media Type |
| The server is refusing to service the request because the entity of |  | The server is refusing to service the request because the entity of |
| the request is in a format not supported by the requested resource |  | the request is in a format not supported by the requested resource |
| for the requested method. |  | for the requested method. |
| 10.4.17 416 Requested Range Not Satisfiable |  | 10.4.17. 416 Requested Range Not Satisfiable |
| 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 |
| The server does not support the functionality required to fulfill the |  | The server does not support the functionality required to fulfill the |
| request. This is the appropriate response when the server does not |  | request. This is the appropriate response when the server does not |
| recognize the request method and is not capable of supporting it for |  | recognize the request method and is not capable of supporting it for |
| any resource. |  | any resource. |
| 10.5.3 502 Bad Gateway |  | 10.5.3. 502 Bad Gateway |
| The server, while acting as a gateway or proxy, received an invalid |  | The server, while acting as a gateway or proxy, received an invalid |
| response from the upstream server it accessed in attempting to |  | response from the upstream server it accessed in attempting to |
| fulfill the request. |  | fulfill the request. |
| 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" [RFC2617]. |
| specification adopts the definitions of "challenge" and "credentials" |  | This specification adopts the definitions of "challenge" and |
| from that specification. |  | "credentials" from that specification. |
| 12 Content Negotiation |  | 12. Content Negotiation |
| Most HTTP responses include an entity which contains information for |  | Most HTTP responses include an entity which contains information for |
| interpretation by a human user. Naturally, it is desirable to supply |  | interpretation by a human user. Naturally, it is desirable to supply |
| the user with the "best available" entity corresponding to the |  | the user with the "best available" entity corresponding to the |
| request. Unfortunately for servers and caches, not all users have 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 10 |  | skipping to change at page 76, line 45 |
| this specification does not define any mechanism for supporting |  | this specification does not define any mechanism for supporting |
| automatic selection, though it also does not prevent any such |  | automatic selection, though it also does not prevent any such |
| mechanism from being developed as an extension and used within |  | mechanism from being developed as an extension and used within |
| 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. |
| 13 Caching in HTTP |  | 13. Caching in HTTP |
| 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. |
| 3. Protocol features that allow a cache to attach warnings to |  | 3. Protocol features that allow a cache to attach warnings to |
| responses that do not preserve the requested approximation of |  | responses that do not preserve the requested approximation of |
| skipping to change at page 75, line 38 |  | skipping to change at page 78, line 26 |
| 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.1 Cache Correctness |  | 13.1. |
|  |  | 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 |
| Warning (but without removing any existing Warning headers). A cache |  | Warning (but without removing any existing Warning headers). A cache |
| SHOULD NOT attempt to revalidate a response simply because that |  | SHOULD NOT attempt to revalidate a response simply because that |
| response became stale in transit; this might lead to an infinite |  | response became stale in transit; this might lead to an infinite |
| loop. A user agent that receives a stale response without a Warning |  | loop. A user agent that receives a stale response without a Warning |
| MAY display a warning indication to the user. |  | MAY display a warning indication to the user. |
| 13.1.2 Warnings |  | 13.1.2. Warnings |
| Whenever a cache returns a response that is neither first-hand nor |  | Whenever a cache returns a response that is neither first-hand nor |
| "fresh enough" (in the sense of condition 2 in section 13.1.1), it |  | "fresh enough" (in the sense of condition 2 in Section 13.1.1), it |
| MUST attach a warning to that effect, using a Warning general-header. |  | MUST attach a warning to that effect, using a Warning general-header. |
| The Warning header and the currently defined warnings are described |  | The Warning header and the currently defined warnings are described |
| in section 14.46. The warning allows clients to take appropriate |  | in Section 14.46. The warning allows clients to take appropriate |
| action. |  | action. |
| Warnings MAY be used for other purposes, both cache-related and |  | Warnings MAY be used for other purposes, both cache-related and |
| otherwise. The use of a warning, rather than an error status code, |  | otherwise. The use of a warning, rather than an error status code, |
| distinguish these responses from true failures. |  | distinguish these responses from true failures. |
| Warnings are assigned three digit warn-codes. The first digit |  | Warnings are assigned three digit warn-codes. The first digit |
| indicates whether the Warning MUST or MUST NOT be deleted from a |  | indicates whether the Warning MUST or MUST NOT be deleted from a |
| stored cache entry after a successful revalidation: |  | stored cache entry after a successful revalidation: |
| 1xx Warnings that describe the freshness or revalidation status of |  | 1xx Warnings that describe the freshness or revalidation status of |
| the response, and so MUST be deleted after a successful |  | the response, and so MUST be deleted after a successful |
| revalidation. 1XX warn-codes MAY be generated by a cache only when |  | revalidation. 1XX warn-codes MAY be generated by a cache only when |
| validating a cached entry. It MUST NOT be generated by clients. |  | validating a cached entry. It MUST NOT be generated by clients. |
| 2xx Warnings that describe some aspect of the entity body or entity |  | 2xx Warnings that describe some aspect of the entity body or entity |
| headers that is not rectified by a revalidation (for example, a |  | headers that is not rectified by a revalidation (for example, a |
| lossy compression of the entity bodies) and which MUST NOT be |  | lossy compression of the entity bodies) and which MUST NOT be |
| deleted after a successful revalidation. |  | deleted after a successful revalidation. |
| See section 14.46 for the definitions of the codes themselves. |  | See Section 14.46 for the definitions of the codes themselves. |
| HTTP/1.0 caches will cache all Warnings in responses, without |  | HTTP/1.0 caches will cache all Warnings in responses, without |
| deleting the ones in the first category. Warnings in responses that |  | deleting the ones in the first category. Warnings in responses that |
| are passed to HTTP/1.0 caches carry an extra warning-date field, |  | are passed to HTTP/1.0 caches carry an extra warning-date field, |
| which prevents a future HTTP/1.1 recipient from believing an |  | which prevents a future HTTP/1.1 recipient from believing an |
| erroneously cached Warning. |  | erroneously cached Warning. |
| Warnings also carry a warning text. The text MAY be in any |  | Warnings also carry a warning text. The text MAY be in any |
| appropriate natural language (perhaps based on the client's Accept |  | appropriate natural language (perhaps based on the client's Accept |
| headers), and include an OPTIONAL indication of what character set is |  | headers), and include an OPTIONAL indication of what character set is |
| skipping to change at page 77, line 39 |  | skipping to change at page 80, line 25 |
| server or by a cache), including multiple warnings with the same code |  | server or by a cache), including multiple warnings with the same code |
| number. For example, a server might provide the same warning with |  | number. For example, a server might provide the same warning with |
| texts in both English and Basque. |  | texts in both English and Basque. |
| When multiple warnings are attached to a response, it might not be |  | When multiple warnings are attached to a response, it might not be |
| 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"). |
| The cache-control directives are described in detail in section 14.9. |  | The cache-control directives are described in detail in Section 14.9. |
| 13.1.4 Explicit User Agent Warnings |  | 13.1.4. Explicit User Agent Warnings |
| Many user agents make it possible for users to override the basic |  | Many user agents make it possible for users to override the basic |
| caching mechanisms. For example, the user agent might allow the user |  | caching mechanisms. For example, the user agent might allow the user |
| to specify that cached entities (even explicitly stale ones) are |  | to specify that cached entities (even explicitly stale ones) are |
| 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 |
| In some cases, the operator of a cache MAY choose to configure it to |  | In some cases, the operator of a cache MAY choose to configure it to |
| return stale responses even when not requested by clients. This |  | return stale responses even when not requested by clients. This |
| decision ought not be made lightly, but may be necessary for reasons |  | decision ought not be made lightly, but may be necessary for reasons |
| of availability or performance, especially when the cache is poorly |  | of availability or performance, especially when the cache is poorly |
| connected to the origin server. Whenever a cache returns a stale |  | connected to the origin server. Whenever a cache returns a stale |
| response, it MUST mark it as such (using a Warning header) enabling |  | response, it MUST mark it as such (using a Warning header) enabling |
| the client software to alert the user that there might be a potential |  | the client software to alert the user that there might be a potential |
| problem. |  | problem. |
| It also allows the user agent to take steps to obtain a first-hand or |  | It also allows the user agent to take steps to obtain a first-hand or |
| fresh response. For this reason, a cache SHOULD NOT return a stale |  | fresh response. For this reason, a cache SHOULD NOT return a stale |
| response if the client explicitly requests a first-hand or fresh one, |  | response if the client explicitly requests a first-hand or fresh one, |
| unless it is impossible to comply for technical or policy reasons. |  | unless it is impossible to comply for technical or policy reasons. |
| 13.1.6 Client-controlled Behavior |  | 13.1.6. Client-controlled Behavior |
| While the origin server (and to a lesser extent, intermediate caches, |  | While the origin server (and to a lesser extent, intermediate caches, |
| by their contribution to the age of a response) are the primary |  | by their contribution to the age of a response) are the primary |
| source of expiration information, in some cases the client might need |  | source of expiration information, in some cases the client might need |
| to control a cache's decision about whether to return a cached |  | to control a cache's decision about whether to return a cached |
| response without validating it. Clients do this using several |  | response without validating it. Clients do this using several |
| 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 |
| requests is for an origin server to provide an explicit expiration |  | requests is for an origin server to provide an explicit expiration |
| time in the future, indicating that a response MAY be used to satisfy |  | time in the future, indicating that a response MAY be used to satisfy |
| subsequent requests. In other words, a cache can return a fresh |  | subsequent requests. In other words, a cache can return a fresh |
| response without first contacting the server. |  | response without first contacting the server. |
| Our expectation is that servers will assign future explicit |  | Our expectation is that servers will assign future explicit |
| expiration times to responses in the belief that the entity is not |  | expiration times to responses in the belief that the entity is not |
| skipping to change at page 80, line 11 |  | skipping to change at page 82, line 40 |
| 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 |
| mechanisms, and such mechanisms need only check a resource's |  | mechanisms, and such mechanisms need only check a resource's |
| expiration status when a new request for that resource is initiated. |  | expiration status when a new request for that resource is initiated. |
| See section 13.13 for an explanation of the difference between caches |  | See Section 13.13 for an explanation of the difference between caches |
| and history mechanisms. |  | and history mechanisms. |
| 13.2.2 Heuristic Expiration |  | 13.2.2. Heuristic Expiration |
| Since origin servers do not always provide explicit expiration times, |  | Since origin servers do not always provide explicit expiration times, |
| HTTP caches typically assign heuristic expiration times, employing |  | HTTP caches typically assign heuristic expiration times, employing |
| algorithms that use other header values (such as the Last-Modified |  | algorithms that use other header values (such as the Last-Modified |
| time) to estimate a plausible expiration time. The HTTP/1.1 |  | time) to estimate a plausible expiration time. The HTTP/1.1 |
| specification does not provide specific algorithms, but does impose |  | specification does not provide specific algorithms, but does impose |
| worst-case constraints on their results. Since heuristic expiration |  | worst-case constraints on their results. Since heuristic expiration |
| times might compromise semantic transparency, they ought to used |  | times might compromise semantic transparency, they ought to used |
| cautiously, and we encourage origin servers to provide explicit |  | cautiously, and we encourage origin servers to provide explicit |
| expiration times as much as possible. |  | expiration times as much as possible. |
| 13.2.3 Age Calculations |  | 13.2.3. Age Calculations |
| In order to know if a cached entry is fresh, a cache needs to know if |  | In order to know if a cached entry is fresh, a cache needs to know if |
| its age exceeds its freshness lifetime. We discuss how to calculate |  | its age exceeds its freshness lifetime. We discuss how to calculate |
| the latter in section 13.2.4; this section describes how to calculate |  | the latter in Section 13.2.4; this section describes how to calculate |
| the age of a response or cache entry. |  | the age of a response or cache entry. |
| In this discussion, we use the term "now" to mean "the current value |  | In this discussion, we use the term "now" to mean "the current value |
| of the clock at the host performing the calculation." Hosts that use |  | of the clock at the host performing the calculation." Hosts that use |
| HTTP, but especially hosts running origin servers and caches, SHOULD |  | HTTP, but especially hosts running origin servers and caches, SHOULD |
| use NTP [28] or some similar protocol to synchronize their clocks to |  | use NTP [RFC1305] or some similar protocol to synchronize their |
| a globally accurate time standard. |  | clocks to a globally accurate time standard. |
| HTTP/1.1 requires origin servers to send a Date header, if possible, |  | HTTP/1.1 requires origin servers to send a Date header, if possible, |
| with every response, giving the time at which the response was |  | with every response, giving the time at which the response was |
| generated (see section 14.18). We use the term "date_value" to 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 8 |  | skipping to change at page 85, line 42 |
| header field in the response with a value equal to the cache entry's |  | header field in the response with a value equal to the cache entry's |
| current_age. |  | current_age. |
| The presence of an Age header field in a response implies that a |  | The presence of an Age header field in a response implies that a |
| response is not first-hand. However, the converse is not true, since |  | response is not first-hand. However, the converse is not true, since |
| the lack of an Age header field in a response does not imply that the |  | the lack of an Age header field in a response does not imply that the |
| response is first-hand unless all caches along the request path are |  | response is first-hand unless all caches along the request path are |
| compliant with HTTP/1.1 (i.e., older HTTP caches did not implement |  | compliant with HTTP/1.1 (i.e., older HTTP caches did not implement |
| the Age header field). |  | the Age header field). |
| 13.2.4 Expiration Calculations |  | 13.2.4. Expiration Calculations |
| In order to decide whether a response is fresh or stale, we need to |  | In order to decide whether a response is fresh or stale, we need to |
| compare its freshness lifetime to its age. The age is calculated as |  | compare its freshness lifetime to its age. The age is calculated as |
| described in section 13.2.3; this section describes how to calculate |  | described in Section 13.2.3; this section describes how to calculate |
| the freshness lifetime, and to determine if a response has expired. |  | the freshness lifetime, and to determine if a response has expired. |
| In the discussion below, the values can be represented in any form |  | In the discussion below, the values can be represented in any form |
| appropriate for arithmetic operations. |  | appropriate for arithmetic operations. |
| We use the term "expires_value" to denote the value of the Expires |  | We use the term "expires_value" to denote the value of the Expires |
| header. We use the term "max_age_value" to denote an appropriate |  | header. We use the term "max_age_value" to denote an appropriate |
| value of the number of seconds carried by the "max-age" directive of |  | value of the number of seconds carried by the "max-age" directive of |
| the Cache-Control header in a response (see section 14.9.3). |  | the Cache-Control header in a response (see Section 14.9.3). |
| The max-age directive takes priority over Expires, so if max-age is |  | The max-age directive takes priority over Expires, so if max-age is |
| present in a response, the calculation is simply: |  | present in a response, the calculation is simply: |
| 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) |
| 13.2.5 Disambiguating Expiration Values |  | 13.2.5. Disambiguating Expiration Values |
| Because expiration values are assigned optimistically, it is possible |  | Because expiration values are assigned optimistically, it is possible |
| for two caches to contain fresh values for the same resource that are |  | for two caches to contain fresh values for the same resource that are |
| different. |  | different. |
| If a client performing a retrieval receives a non-first-hand response |  | If a client performing a retrieval receives a non-first-hand response |
| for a request that was already fresh in its own cache, and the Date |  | for a request that was already fresh in its own cache, and the Date |
| header in its existing cache entry is newer than the Date on the new |  | header in its existing cache entry is newer than the Date on the new |
| response, then the client MAY ignore the response. If so, it MAY |  | response, then the client MAY ignore the response. If so, it MAY |
| retry the request with a "Cache-Control: max-age=0" directive (see |  | retry the request with a "Cache-Control: max-age=0" directive (see |
| section 14.9), to force a check with the origin server. |  | Section 14.9), to force a check with the origin server. |
| If a cache has two fresh responses for the same representation with |  | If a cache has two fresh responses for the same representation with |
| different validators, it MUST use the one with the more recent Date |  | different validators, it MUST use the one with the more recent Date |
| header. This situation might arise because the cache is pooling |  | header. This situation might arise because the cache is pooling |
| responses from other caches, or because a client has asked for a |  | responses from other caches, or because a client has asked for a |
| reload or a revalidation of an apparently fresh cache entry. |  | reload or a revalidation of an apparently fresh cache entry. |
| 13.2.6 Disambiguating Multiple Responses |  | 13.2.6. Disambiguating Multiple Responses |
| 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 11 |  | skipping to change at page 87, line 42 |
| to force any intermediate caches to obtain a new copy from the origin |  | to force any intermediate caches to obtain a new copy from the origin |
| server. |  | server. |
| If the Date values are equal, then the client MAY use either response |  | If the Date values are equal, then the client MAY use either response |
| (or MAY, if it is being extremely prudent, request a new response). |  | (or MAY, if it is being extremely prudent, request a new response). |
| Servers MUST NOT depend on clients being able to choose |  | Servers MUST NOT depend on clients being able to choose |
| deterministically between responses generated during the same second, |  | deterministically between responses generated during the same second, |
| if their expiration times overlap. |  | if their expiration times overlap. |
| 13.3 Validation Model |  | 13.3. Validation Model |
| When a cache has a stale entry that it would like to use as a |  | When a cache has a stale entry that it would like to use as a |
| response to a client's request, it first has to check with the origin |  | response to a client's request, it first has to check with the origin |
| server (or possibly an intermediate cache with a fresh response) to |  | server (or possibly an intermediate cache with a fresh response) to |
| see if its cached entry is still usable. We call this "validating" |  | see if its cached entry is still usable. We call this "validating" |
| the cache entry. Since we do not want to have to pay the overhead of |  | the cache entry. Since we do not want to have to pay the overhead of |
| retransmitting the full response if the cached entry is good, and we |  | retransmitting the full response if the cached entry is good, and we |
| do not want to pay the overhead of an extra round trip if the cached |  | do not want to pay the overhead of an extra round trip if the cached |
| entry is invalid, the HTTP/1.1 protocol supports the use of |  | entry is invalid, the HTTP/1.1 protocol supports the use of |
| conditional methods. |  | conditional methods. |
| The key protocol features for supporting conditional methods are |  | The key protocol features for supporting conditional methods are |
| those concerned with "cache validators." When an origin server |  | those concerned with "cache validators." When an origin server |
| generates a full response, it attaches some sort of validator to it, |  | generates a full response, it attaches some sort of validator to it, |
| which is kept with the cache entry. When a client (user agent or |  | which is kept with the cache entry. When a client (user agent or |
| proxy cache) makes a conditional request for a resource for which it |  | proxy cache) makes a conditional request for a resource for which it |
| has a cache entry, it includes the associated validator in the |  | has a cache entry, it includes the associated validator in the |
| request. |  | request. |
| The server then checks that validator against the current validator |  | The server then checks that validator against the current validator |
| for the entity, and, if they match (see section 13.3.3), it responds |  | for the entity, and, if they match (see Section 13.3.3), it responds |
| with a special status code (usually, 304 (Not Modified)) and no |  | with a special status code (usually, 304 (Not Modified)) and no |
| entity-body. Otherwise, it returns a full response (including |  | entity-body. Otherwise, it returns a full response (including |
| 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 |
| validator. In simple terms, a cache entry is considered to be valid |  | validator. In simple terms, a cache entry is considered to be valid |
| if the entity has not been modified since the Last-Modified value. |  | if the entity has not been modified since the Last-Modified value. |
| 13.3.2 Entity Tag Cache Validators |  | 13.3.2. Entity Tag Cache Validators |
| The ETag response-header field value, an entity tag, provides for an |  | The ETag response-header field value, an entity tag, provides for an |
| "opaque" cache validator. This might allow more reliable validation |  | "opaque" cache validator. This might allow more reliable validation |
| in situations where it is inconvenient to store modification dates, |  | in situations where it is inconvenient to store modification dates, |
| where the one-second resolution of HTTP date values is not |  | where the one-second resolution of HTTP date values is not |
| sufficient, or where the origin server wishes to avoid certain |  | sufficient, or where the origin server wishes to avoid certain |
| paradoxes that might arise from the use of modification dates. |  | paradoxes that might arise from the use of modification dates. |
| Entity Tags are described in section 3.11. The headers used with |  | Entity Tags are described in Section 3.11. The headers used with |
| entity tags are described in sections 14.19, 14.24, 14.26 and 14.44. |  | entity tags are described in sections 14.19, 14.24, 14.26 and 14.44. |
| 13.3.3 Weak and Strong Validators |  | 13.3.3. Weak and Strong Validators |
| Since both origin servers and caches will compare two validators to |  | Since both origin servers and caches will compare two validators to |
| decide if they represent the same or different entities, one normally |  | decide if they represent the same or different entities, one normally |
| would expect that if the entity (the entity-body or any entity- |  | would expect that if the entity (the entity-body or any entity- |
| headers) changes in any way, then the associated validator would |  | headers) changes in any way, then the associated validator would |
| change as well. If this is true, then we call this validator a |  | change as well. If this is true, then we call this validator a |
| "strong validator." |  | "strong validator." |
| 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 6 |  | skipping to change at page 91, line 36 |
| described here. |  | described here. |
| A cache or origin server receiving a conditional request, other than |  | A cache or origin server receiving a conditional request, other than |
| a full-body GET request, MUST use the strong comparison function to |  | a full-body GET request, MUST use the strong comparison function to |
| evaluate the condition. |  | evaluate the condition. |
| These rules allow HTTP/1.1 caches and clients to safely perform sub- |  | These rules allow HTTP/1.1 caches and clients to safely perform sub- |
| range retrievals on values that have been obtained from HTTP/1.0 |  | range retrievals on values that have been obtained from HTTP/1.0 |
| 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 90, line 43 |  | skipping to change at page 93, line 26 |
| conservative assumptions about the validators they receive. |  | conservative assumptions about the validators they receive. |
| HTTP/1.0 clients and caches will ignore entity tags. Generally, |  | HTTP/1.0 clients and caches will ignore entity tags. Generally, |
| last-modified values received or used by these systems will |  | last-modified values received or used by these systems will |
| support transparent and efficient caching, and so HTTP/1.1 origin |  | support transparent and efficient caching, and so HTTP/1.1 origin |
| servers should provide Last-Modified values. In those rare cases |  | servers should provide Last-Modified values. In those rare cases |
| where the use of a Last-Modified value as a validator by an |  | where the use of a Last-Modified value as a validator by an |
| HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |  | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 |
| origin servers should not provide one. |  | origin servers should not provide one. |
| 13.3.5 Non-validating Conditionals |  | 13.3.5. Non-validating Conditionals |
| The principle behind entity tags is that only the service author |  | The principle behind entity tags is that only the service author |
| knows the semantics of a resource well enough to select an |  | knows the semantics of a resource well enough to select an |
| appropriate cache validation mechanism, and the specification of any |  | appropriate cache validation mechanism, and the specification of any |
| validator comparison function more complex than byte-equality would |  | validator comparison function more complex than byte-equality would |
| open up a can of worms. Thus, comparisons of any other headers |  | open up a can of worms. Thus, comparisons of any other headers |
| (except Last-Modified, for compatibility with HTTP/1.0) are never |  | (except Last-Modified, for compatibility with HTTP/1.0) are never |
| used for purposes of validating a cache entry. |  | used for purposes of validating a cache entry. |
| 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 |
| resource entities, or portions thereof, are not to be cached |  | resource entities, or portions thereof, are not to be cached |
| regardless of other considerations. |  | regardless of other considerations. |
| Note that section 14.8 normally prevents a shared cache from saving |  | Note that Section 14.8 normally prevents a shared cache from saving |
| and returning a response to a previous request if that request |  | and returning a response to a previous request if that request |
| included an Authorization header. |  | included an Authorization header. |
| A response received with a status code of 200, 203, 206, 300, 301 or |  | A response received with a status code of 200, 203, 206, 300, 301 or |
| 410 MAY be stored by a cache and used in reply to a subsequent |  | 410 MAY be stored by a cache and used in reply to a subsequent |
| request, subject to the expiration mechanism, unless a cache-control |  | request, subject to the expiration mechanism, unless a cache-control |
| directive prohibits caching. However, a cache that does not support |  | directive prohibits caching. However, a cache that does not support |
| the Range and Content-Range headers MUST NOT cache 206 (Partial |  | the Range and Content-Range headers MUST NOT cache 206 (Partial |
| Content) responses. |  | Content) responses. |
| A response received with any other status code (e.g. status codes 302 |  | A response received with any other status code (e.g. status codes 302 |
| and 307) MUST NOT be returned in a reply to a subsequent request |  | and 307) MUST NOT be returned in a reply to a subsequent request |
| unless there are cache-control directives or another header(s) that |  | unless there are cache-control directives or another header(s) that |
| explicitly allow it. For example, these include the following: an |  | explicitly allow it. For example, these include the following: an |
| Expires header (section 14.21); a "max-age", "s-maxage", "must- |  | Expires header (Section 14.21); a "max-age", "s-maxage", "must- |
| revalidate", "proxy-revalidate", "public" or "private" cache-control |  | revalidate", "proxy-revalidate", "public" or "private" cache-control |
| directive (section 14.9). |  | directive (Section 14.9). |
| 13.5 Constructing Responses From Caches |  | 13.5. Constructing Responses From Caches |
| The purpose of an HTTP cache is to store information received in |  | The purpose of an HTTP cache is to store information received in |
| response to requests for use in responding to future requests. In |  | response to requests for use in responding to future requests. In |
| 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 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 |
| by the presence of a Vary header field in a response, alters the |  | by the presence of a Vary header field in a response, alters the |
| conditions and procedure by which a cache can use the response for |  | conditions and procedure by which a cache can use the response for |
| subsequent requests. See section 14.44 for use of the Vary header |  | subsequent requests. See Section 14.44 for use of the Vary header |
| field by servers. |  | field by servers. |
| A server SHOULD use the Vary header field to inform a cache of what |  | A server SHOULD use the Vary header field to inform a cache of what |
| request-header fields were used to select among multiple |  | request-header fields were used to select among multiple |
| representations of a cacheable response subject to server-driven |  | representations of a cacheable response subject to server-driven |
| negotiation. The set of header fields named by the Vary field value |  | negotiation. The set of header fields named by the Vary field value |
| is known as the "selecting" request-headers. |  | is known as the "selecting" request-headers. |
| When the cache receives a subsequent request whose Request-URI |  | When the cache receives a subsequent request whose Request-URI |
| specifies one or more cache entries including a Vary header field, |  | specifies one or more cache entries including a Vary header field, |
| skipping to change at page 96, line 7 |  | skipping to change at page 98, line 40 |
| the new request unless all of the selecting request-headers present |  | the new request unless all of the selecting request-headers present |
| in the new request match the corresponding stored request-headers in |  | in the new request match the corresponding stored request-headers in |
| the original request. |  | the original request. |
| The selecting request-headers from two requests are defined to match |  | The selecting request-headers from two requests are defined to match |
| if and only if the selecting request-headers in the first request can |  | if and only if the selecting request-headers in the first request can |
| be transformed to the selecting request-headers in the second request |  | be transformed to the selecting request-headers in the second request |
| by adding or removing linear white space (LWS) at places where this |  | by adding or removing linear white space (LWS) at places where this |
| is allowed by the corresponding BNF, and/or combining multiple |  | is allowed by the corresponding BNF, and/or combining multiple |
| message-header fields with the same field name following the rules |  | message-header fields with the same field name following the rules |
| about message headers in section 4.2. |  | about message headers in Section 4.2. |
| A Vary header field-value of "*" always fails to match and subsequent |  | A Vary header field-value of "*" always fails to match and subsequent |
| requests on that resource can only be properly interpreted by the |  | requests on that resource can only be properly interpreted by the |
| origin server. |  | origin server. |
| If the selecting request header fields for the cached entry do not |  | If the selecting request header fields for the cached entry do not |
| match the selecting request header fields of the new request, then |  | match the selecting request header fields of the new request, then |
| the cache MUST NOT use a cached entry to satisfy the request unless |  | the cache MUST NOT use a cached entry to satisfy the request unless |
| it first relays the new request to the origin server in a conditional |  | it first relays the new request to the origin server in a conditional |
| request and the server responds with 304 (Not Modified), including an |  | request and the server responds with 304 (Not Modified), including an |
| skipping to change at page 96, line 38 |  | skipping to change at page 99, 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. |
| We note one exception to this rule: since some applications have |  | We note one exception to this rule: since some applications have |
| traditionally used GETs and HEADs with query URLs (those containing a |  | traditionally used GETs and HEADs with query URLs (those containing a |
| "?" in the rel_path part) to perform operations with significant side |  | "?" in the rel_path part) to perform operations with significant side |
| effects, caches MUST NOT treat responses to such URIs as fresh unless |  | effects, caches MUST NOT treat responses to such URIs as fresh unless |
| the server provides an explicit expiration time. This specifically |  | the server provides an explicit expiration time. This specifically |
| means that responses from HTTP/1.0 servers for such URIs SHOULD NOT |  | means that responses from HTTP/1.0 servers for such URIs SHOULD NOT |
| be taken from a cache. See section 9.1.1 for related information. |  | be taken from a cache. See Section 9.1.1 for related information. |
| 13.10 Invalidation After Updates or Deletions |  | 13.10. Invalidation After Updates or Deletions |
| The effect of certain methods performed on a resource at the origin |  | The effect of certain methods performed on a resource at the origin |
| server might cause one or more existing cache entries to become non- |  | server might cause one or more existing cache entries to become non- |
| transparently invalid. That is, although they might continue to be |  | transparently invalid. That is, although they might continue to be |
| "fresh," they do not accurately reflect what the origin server would |  | "fresh," they do not accurately reflect what the origin server would |
| return for a new request on that resource. |  | return for a new request on that resource. |
| There is no way for the HTTP protocol to guarantee that all such |  | There is no way for the HTTP protocol to guarantee that all such |
| cache entries are marked invalid. For example, the request that |  | cache entries are marked invalid. For example, the request that |
| 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 |
| the same resource are cached, the cache SHOULD use the new response |  | the same resource are cached, the cache SHOULD use the new response |
| to reply to the current request. It MAY insert it into cache storage |  | to reply to the current request. It MAY insert it into cache storage |
| and MAY, if it meets all other requirements, use it to respond to any |  | and MAY, if it meets all other requirements, use it to respond to any |
| future requests that would previously have caused the old response to |  | future requests that would previously have caused the old response to |
| be returned. If it inserts the new response into cache storage the |  | be returned. If it inserts the new response into cache storage the |
| rules in section 13.5.3 apply. |  | rules in Section 13.5.3 apply. |
| Note: a new response that has an older Date header value than |  | Note: a new response that has an older Date header value than |
| existing cached responses is not cacheable. |  | existing cached responses is not cacheable. |
| 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 100, line 5 |  | skipping to change at page 102, line 38 |
| they would otherwise like to. Service authors may consider it |  | they would otherwise like to. Service authors may consider it |
| important that users not be presented with error messages or |  | important that users not be presented with error messages or |
| warning messages when they use navigation controls (such as BACK) |  | warning messages when they use navigation controls (such as BACK) |
| to view previously fetched resources. Even though sometimes such |  | to view previously fetched resources. Even though sometimes such |
| resources ought not to cached, or ought to expire quickly, user |  | resources ought not to cached, or ought to expire quickly, user |
| interface considerations may force service authors to resort to |  | interface considerations may force service authors to resort to |
| other means of preventing caching (e.g. "once-only" URLs) in order |  | other means of preventing caching (e.g. "once-only" URLs) in order |
| not to suffer the effects of improperly functioning history |  | not to suffer the effects of improperly functioning history |
| mechanisms. |  | mechanisms. |
| 14 Header Field Definitions |  | 14. Header Field Definitions |
| This section defines the syntax and semantics of all standard |  | This section defines the syntax and semantics of all standard |
| HTTP/1.1 header fields. For entity-header fields, both sender and |  | HTTP/1.1 header fields. For entity-header fields, both sender and |
| recipient refer to either the client or the server, depending on who |  | recipient refer to either the client or the server, depending on who |
| sends and who receives the entity. |  | sends and who receives the entity. |
| 14.1 Accept |  | 14.1. Accept |
| The Accept request-header field can be used to specify certain media |  | The Accept request-header field can be used to specify certain media |
| types which are acceptable for the response. Accept headers can be |  | types which are acceptable for the response. Accept headers can be |
| used to indicate that the request is specifically limited to a small |  | used to indicate that the request is specifically limited to a small |
| set of desired types, as in the case of a request for an in-line |  | set of desired types, as in the case of a request for an in-line |
| image. |  | image. |
| Accept = "Accept" ":" |  | Accept = "Accept" ":" |
| #( media-range [ accept-params ] ) |  | #( media-range [ accept-params ] ) |
| skipping to change at page 100, line 40 |  | skipping to change at page 103, line 25 |
| The asterisk "*" character is used to group media types into ranges, |  | The asterisk "*" character is used to group media types into ranges, |
| with "*/*" indicating all media types and "type/*" indicating all |  | with "*/*" indicating all media types and "type/*" indicating all |
| subtypes of that type. The media-range MAY include media type |  | subtypes of that type. The media-range MAY include media type |
| parameters that are applicable to that range. |  | parameters that are applicable to that range. |
| Each media-range MAY be followed by one or more accept-params, |  | Each media-range MAY be followed by one or more accept-params, |
| beginning with the "q" parameter for indicating a relative quality |  | beginning with the "q" parameter for indicating a relative quality |
| factor. The first "q" parameter (if any) separates the media-range |  | factor. The first "q" parameter (if any) separates the media-range |
| parameter(s) from the accept-params. Quality factors allow the user |  | parameter(s) from the accept-params. Quality factors allow the user |
| or user agent to indicate the relative degree of preference for that |  | or user agent to indicate the relative degree of preference for that |
| media-range, using the qvalue scale from 0 to 1 (section 3.9). The |  | media-range, using the qvalue scale from 0 to 1 (Section 3.9). The |
| default value is q=1. |  | default value is q=1. |
| 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 104, line 41 |
| 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 |
| The Accept-Encoding request-header field is similar to Accept, but |  | The Accept-Encoding request-header field is similar to Accept, but |
| restricts the content-codings (section 3.5) that are acceptable in |  | restricts the content-codings (Section 3.5) that are acceptable in |
| the response. |  | the response. |
| Accept-Encoding = "Accept-Encoding" ":" |  | Accept-Encoding = "Accept-Encoding" ":" |
| 1#( codings [ ";" "q" "=" qvalue ] ) |  | 1#( codings [ ";" "q" "=" qvalue ] ) |
| codings = ( content-coding | "*" ) |  | codings = ( content-coding | "*" ) |
| Examples of its use are: |  | Examples of its use are: |
| Accept-Encoding: compress, gzip |  | Accept-Encoding: compress, gzip |
| Accept-Encoding: |  | Accept-Encoding: |
| Accept-Encoding: * |  | Accept-Encoding: * |
| Accept-Encoding: compress;q=0.5, gzip;q=1.0 |  | Accept-Encoding: compress;q=0.5, gzip;q=1.0 |
| Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |  | Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 |
| A server tests whether a content-coding is acceptable, according to |  | A server tests whether a content-coding is acceptable, according to |
| 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. |
| 4. The "identity" content-coding is always acceptable, unless |  | 4. The "identity" content-coding is always acceptable, unless |
| skipping to change at page 103, line 50 |  | skipping to change at page 106, line 33 |
| 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 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 107, line 28 |
| 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 |
| recommended that client applications make the choice of linguistic |  | recommended that client applications make the choice of linguistic |
| preference available to the user. If the choice is not made |  | preference available to the user. If the choice is not made |
| available, then the Accept-Language header field MUST NOT be given in |  | available, then the Accept-Language header field MUST NOT be given in |
| the request. |  | the request. |
| Note: When making the choice of linguistic preference available to |  | Note: When making the choice of linguistic preference available to |
| 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" [RFC2617]. 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. |
| Cache-Control = "Cache-Control" ":" 1#cache-directive |  | Cache-Control = "Cache-Control" ":" 1#cache-directive |
| cache-directive = cache-request-directive |  | cache-directive = cache-request-directive |
| skipping to change at page 109, line 15 |  | skipping to change at page 111, line 45 |
| 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 |
| for cacheability. The following Cache-Control response directives |  | defaults for cacheability. The following Cache-Control response |
| allow an origin server to override the default cacheability of a |  | directives allow an origin server to override the default |
| response: |  | cacheability of a 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 110, line 31 |  | skipping to change at page 113, line 12 |
| 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 |
| subsequent request without successful revalidation with the origin |  | subsequent request without successful revalidation with the origin |
| server. This allows an origin server to prevent the re-use of |  | server. This allows an origin server to prevent the re-use of |
| certain header fields in a response, while still allowing caching |  | certain header fields in a response, while still allowing caching |
| of the rest of the response. |  | of the rest of the response. |
| Note: Most HTTP/1.0 caches will not recognize or obey this |  | Note: Most HTTP/1.0 caches will not recognize or obey this |
| directive. |  | directive. |
| 14.9.2 What May be Stored by Caches |  | 14.9.2. What May be Stored by Caches |
| no-store |  | no-store |
| The purpose of the no-store directive is to prevent the |  | The purpose of the no-store directive is to prevent the |
| inadvertent release or retention of sensitive information (for |  | inadvertent release or retention of sensitive information (for |
| example, on backup tapes). The no-store directive applies to the |  | example, on backup tapes). The no-store directive applies to the |
| entire message, and MAY be sent either in a response or in a |  | entire message, and MAY be sent either in a response or in a |
| request. If sent in a request, a cache MUST NOT store any part of |  | request. If sent in a request, a cache MUST NOT store any part of |
| either this request or any response to it. If sent in a response, |  | either this request or any response to it. If sent in a response, |
| a cache MUST NOT store any part of either this response or the |  | a cache MUST NOT store any part of either this response or the |
| request that elicited it. This directive applies to both non- |  | request that elicited it. This directive applies to both non- |
| shared and shared caches. "MUST NOT store" in this context means |  | shared and shared caches. "MUST NOT store" in this context means |
| that the cache MUST NOT intentionally store the information in |  | that the cache MUST NOT intentionally store the information in |
| skipping to change at page 111, line 15 |  | skipping to change at page 113, line 45 |
| The purpose of this directive is to meet the stated requirements |  | The purpose of this directive is to meet the stated requirements |
| of certain users and service authors who are concerned about |  | of certain users and service authors who are concerned about |
| accidental releases of information via unanticipated accesses to |  | accidental releases of information via unanticipated accesses to |
| cache data structures. While the use of this directive might |  | cache data structures. While the use of this directive might |
| improve privacy in some cases, we caution that it is NOT in any |  | improve privacy in some cases, we caution that it is NOT in any |
| way a reliable or sufficient mechanism for ensuring privacy. In |  | way a reliable or sufficient mechanism for ensuring privacy. In |
| particular, malicious or compromised caches might not recognize or |  | particular, malicious or compromised caches might not recognize or |
| obey this directive, and communications networks might be |  | obey this directive, and communications networks might be |
| vulnerable to eavesdropping. |  | vulnerable to eavesdropping. |
| 14.9.3 Modifications of the Basic Expiration Mechanism |  | 14.9.3. Modifications of the Basic Expiration Mechanism |
| The expiration time of an entity MAY be specified by the origin |  | The expiration time of an entity MAY be specified by the origin |
| server using the Expires header (see section 14.21). Alternatively, |  | server using the Expires header (see Section 14.21). Alternatively, |
| 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 6 |  | skipping to change at page 114, line 33 |
| 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 |
| network including older caches that do not understand that |  | network including older caches that do not understand that |
| feature. The origin server will need to combine the new feature |  | feature. The origin server will need to combine the new feature |
| with an Expires field whose value is less than or equal to the |  | with an Expires field whose value is less than or equal to the |
| Date value. This will prevent older caches from improperly |  | Date value. This will prevent older caches from improperly |
| 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 113, line 14 |  | skipping to change at page 115, line 47 |
| A cache MAY be configured to return stale responses without |  | A cache MAY be configured to return stale responses without |
| validation, but only if this does not conflict with any "MUST"-level |  | validation, but only if this does not conflict with any "MUST"-level |
| requirements concerning cache validation (e.g., a "must-revalidate" |  | requirements concerning cache validation (e.g., a "must-revalidate" |
| cache-control directive). |  | cache-control directive). |
| If both the new request and the cached entry include "max-age" |  | If both the new request and the cached entry include "max-age" |
| directives, then the lesser of the two values is used for determining |  | directives, then the lesser of the two values is used for determining |
| the freshness of the cached entry for that request. |  | the freshness of the cached entry for that request. |
| 14.9.4 Cache Revalidation and Reload Controls |  | 14.9.4. Cache Revalidation and Reload Controls |
| Sometimes a user agent might want or need to insist that a cache |  | Sometimes a user agent might want or need to insist that a cache |
| revalidate its cache entry with the origin server (and not just with |  | revalidate its cache entry with the origin server (and not just with |
| the next cache along the path to the origin server), or to reload its |  | the next cache along the path to the origin server), or to reload its |
| cache entry from the origin server. End-to-end revalidation might be |  | cache entry from the origin server. End-to-end revalidation might be |
| necessary if either the cache or the origin server has overestimated |  | necessary if either the cache or the origin server has overestimated |
| the expiration time of the cached response. End-to-end reload may be |  | the expiration time of the cached response. End-to-end reload may be |
| necessary if the cache entry has become corrupted for some reason. |  | necessary if the cache entry has become corrupted for some reason. |
| End-to-end revalidation may be requested either when the client does |  | End-to-end revalidation may be requested either when the client does |
| skipping to change at page 114, line 20 |  | skipping to change at page 117, line 9 |
| 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 115, line 40 |  | skipping to change at page 118, line 31 |
| revalidate directive, except that it does not apply to non-shared |  | revalidate directive, except that it does not apply to non-shared |
| user agent caches. It can be used on a response to an |  | user agent caches. It can be used on a response to an |
| authenticated request to permit the user's cache to store and |  | authenticated request to permit the user's cache to store and |
| later return the response without needing to revalidate it (since |  | later return the response without needing to revalidate it (since |
| it has already been authenticated once by that user), while still |  | it has already been authenticated once by that user), while still |
| requiring proxies that service many users to revalidate each time |  | requiring proxies that service many users to revalidate each time |
| (in order to make sure that each user has been authenticated). |  | (in order to make sure that each user has been authenticated). |
| Note that such authenticated responses also need the public cache |  | Note that such authenticated responses also need the public cache |
| control directive in order to allow them to be cached at all. |  | control directive in order to allow them to be cached at all. |
| 14.9.5 No-Transform Directive |  | 14.9.5. No-Transform Directive |
| no-transform |  | no-transform |
| Implementors of intermediate caches (proxies) have found it useful |  | Implementors of intermediate caches (proxies) have found it useful |
| to convert the media type of certain entity bodies. A non- |  | to convert the media type of certain entity bodies. A non- |
| transparent proxy might, for example, convert between image |  | transparent proxy might, for example, convert between image |
| formats in order to save cache space or to reduce the amount of |  | formats in order to save cache space or to reduce the amount of |
| traffic on a slow link. |  | traffic on a slow link. |
| Serious operational problems occur, however, when these |  | Serious operational problems occur, however, when these |
| transformations are applied to entity bodies intended for certain |  | transformations are applied to entity bodies intended for certain |
| kinds of applications. For example, applications for medical |  | kinds of applications. For example, applications for medical |
| imaging, scientific data analysis and those using end-to-end |  | imaging, scientific data analysis and those using end-to-end |
| skipping to change at page 116, line 10 |  | skipping to change at page 118, line 50 |
| Serious operational problems occur, however, when these |  | Serious operational problems occur, however, when these |
| transformations are applied to entity bodies intended for certain |  | transformations are applied to entity bodies intended for certain |
| kinds of applications. For example, applications for medical |  | kinds of applications. For example, applications for medical |
| imaging, scientific data analysis and those using end-to-end |  | imaging, scientific data analysis and those using end-to-end |
| authentication, all depend on receiving an entity body that is bit |  | authentication, all depend on receiving an entity body that is bit |
| for bit identical to the original entity-body. |  | for bit identical to the original entity-body. |
| Therefore, if a message includes the no-transform directive, an |  | Therefore, if a message includes the no-transform directive, an |
| intermediate cache or proxy MUST NOT change those headers that are |  | intermediate cache or proxy MUST NOT change those headers that are |
| listed in section 13.5.2 as being subject to the no-transform |  | listed in Section 13.5.2 as being subject to the no-transform |
| directive. This implies that the cache or proxy MUST NOT change |  | directive. This implies that the cache or proxy MUST NOT change |
| any aspect of the entity-body that is specified by these headers, |  | any aspect of the entity-body that is specified by these headers, |
| including the value of the entity-body itself. |  | including the value of the entity-body itself. |
| 14.9.6 Cache Control Extensions |  | 14.9.6. Cache Control Extensions |
| The Cache-Control header field can be extended through the use of one |  | The Cache-Control header field can be extended through the use of one |
| or more cache-extension tokens, each with an optional assigned value. |  | or more cache-extension tokens, each with an optional assigned value. |
| Informational extensions (those which do not require a change in |  | Informational extensions (those which do not require a change in |
| cache behavior) MAY be added without changing the semantics of other |  | cache behavior) MAY be added without changing the semantics of other |
| directives. Behavioral extensions are designed to work by acting as |  | directives. Behavioral extensions are designed to work by acting as |
| modifiers to the existing base of cache directives. Both the new |  | modifiers to the existing base of cache directives. Both the new |
| directive and the standard directive are supplied, such that |  | directive and the standard directive are supplied, such that |
| applications which do not understand the new directive will default |  | applications which do not understand the new directive will default |
| to the behavior specified by the standard directive, and those that |  | to the behavior specified by the standard directive, and those that |
| skipping to change at page 117, line 11 |  | skipping to change at page 119, line 48 |
| does not understand the community cache-extension, since it will also |  | does not understand the community cache-extension, since it will also |
| see and understand the private directive and thus default to the safe |  | see and understand the private directive and thus default to the safe |
| behavior. |  | behavior. |
| Unrecognized cache-directives MUST be ignored; it is assumed that any |  | Unrecognized cache-directives MUST be ignored; it is assumed that any |
| cache-directive likely to be unrecognized by an HTTP/1.1 cache will |  | cache-directive likely to be unrecognized by an HTTP/1.1 cache will |
| be combined with standard directives (or the response's default |  | be combined with standard directives (or the response's default |
| cacheability) such that the cache behavior will remain minimally |  | cacheability) such that the cache behavior will remain minimally |
| correct even if the cache does not understand the extension(s). |  | correct even if the cache does not understand the extension(s). |
| 14.10 Connection |  | 14.10. Connection |
| The Connection general-header field allows the sender to specify |  | The Connection general-header field allows the sender to specify |
| options that are desired for that particular connection and MUST NOT |  | options that are desired for that particular connection and MUST NOT |
| be communicated by proxies over further connections. |  | be communicated by proxies over further connections. |
| The Connection header has the following grammar: |  | The Connection header has the following grammar: |
| Connection = "Connection" ":" 1#(connection-token) |  | Connection = "Connection" ":" 1#(connection-token) |
| connection-token = token |  | connection-token = token |
| HTTP/1.1 proxies MUST parse the Connection header field before a |  | HTTP/1.1 proxies MUST parse the Connection header field before a |
| message is forwarded and, for each connection-token in this field, |  | message is forwarded and, for each connection-token in this field, |
| remove any header field(s) from the message with the same name as the |  | remove any header field(s) from the message with the same name as the |
| connection-token. Connection options are signaled by the presence of |  | connection-token. Connection options are signaled by the presence of |
| a connection-token in the Connection header field, not by any |  | a connection-token in the Connection header field, not by any |
| corresponding additional header field(s), since the additional header |  | corresponding additional header field(s), since the additional header |
| field may not be sent if there are no parameters associated with that |  | field may not be sent if there are no parameters associated with that |
| connection option. |  | connection option. |
| 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 A.6.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. |
| 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. |
| 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 |
| The Content-Location entity-header field MAY be used to supply the |  | The Content-Location entity-header field MAY be used to supply the |
| resource location for the entity enclosed in the message when that |  | resource location for the entity enclosed in the message when that |
| entity is accessible from a location separate from the requested |  | entity is accessible from a location separate from the requested |
| resource's URI. A server SHOULD provide a Content-Location for the |  | resource's URI. A server SHOULD provide a Content-Location for the |
| variant corresponding to the response entity; especially in the case |  | variant corresponding to the response entity; especially in the case |
| where a resource has multiple entities associated with it, and those |  | where a resource has multiple entities associated with it, and those |
| entities actually have separate locations by which they might be |  | entities actually have separate locations by which they might be |
| individually accessed, the server SHOULD provide a Content-Location |  | individually accessed, the server SHOULD provide a Content-Location |
| for the particular variant which is returned. |  | for the particular variant which is returned. |
| skipping to change at page 120, line 45 |  | skipping to change at page 123, line 34 |
| 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 |
| an MD5 digest of the entity-body for the purpose of providing an |  | [RFC1864], is an MD5 digest of the entity-body for the purpose of |
| end-to-end message integrity check (MIC) of the entity-body. (Note: a |  | providing an end-to-end message integrity check (MIC) of the entity- |
| MIC is good for detecting accidental modification of the entity-body |  | body. (Note: a MIC is good for detecting accidental modification of |
| in transit, but is not proof against malicious attacks.) |  | the entity-body 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 |
| value as an end-to-end integrity check. Any recipient of the entity- |  | value as an end-to-end integrity check. Any recipient of the entity- |
| body, including gateways and proxies, MAY check that the digest value |  | body, including gateways and proxies, MAY check that the digest value |
| skipping to change at page 121, line 39 |  | skipping to change at page 124, line 29 |
| 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 |
| HTTP, unlike MIME, does not use Content-Transfer-Encoding, and |  | HTTP, unlike MIME, does not use Content-Transfer-Encoding, and |
| does use Transfer-Encoding and Content-Encoding. Another is that |  | does use Transfer-Encoding and Content-Encoding. Another is that |
| HTTP more frequently uses binary content types than MIME, so it is |  | HTTP more frequently uses binary content types than MIME, so it is |
| worth noting that, in such cases, the byte order used to compute |  | worth noting that, in such cases, the byte order used to compute |
| the digest is the transmission byte order defined for the type. |  | the digest is the transmission byte order defined for the type. |
| Lastly, HTTP allows transmission of text types with any of several |  | Lastly, HTTP allows transmission of text types with any of several |
| line break conventions and not just the canonical form using CRLF. |  | line break conventions and not just the canonical form using CRLF. |
| 14.16 Content-Range |  | 14.16. Content-Range |
| The Content-Range entity-header is sent with a partial entity-body to |  | The Content-Range entity-header is sent with a partial entity-body to |
| specify where in the full entity-body the partial body should be |  | specify where in the full entity-body the partial body should be |
| applied. Range units are defined in section 3.12. |  | applied. Range units are defined in Section 3.12. |
| Content-Range = "Content-Range" ":" content-range-spec |  | Content-Range = "Content-Range" ":" content-range-spec |
| content-range-spec = byte-content-range-spec |  | content-range-spec = byte-content-range-spec |
| byte-content-range-spec = bytes-unit SP |  | byte-content-range-spec = bytes-unit SP |
| byte-range-resp-spec "/" |  | byte-range-resp-spec "/" |
| ( instance-length | "*" ) |  | ( instance-length | "*" ) |
| byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |  | byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) |
| | "*" |  | | "*" |
| instance-length = 1*DIGIT |  | instance-length = 1*DIGIT |
| The header SHOULD indicate the total length of the full entity-body, |  | The header SHOULD indicate the total length of the full entity-body, |
| unless this length is unknown or difficult to determine. The 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: |  | o The first 500 bytes: |
| bytes 0-499/1234 |  | bytes 0-499/1234 |
| . The second 500 bytes: |  | o The second 500 bytes: |
| bytes 500-999/1234 |  | bytes 500-999/1234 |
| . All except for the first 500 bytes: |  | o All except for the first 500 bytes: |
| bytes 500-1233/1234 |  | bytes 500-1233/1234 |
| . The last 500 bytes: |  | o The last 500 bytes: |
| bytes 734-1233/1234 |  | bytes 734-1233/1234 |
| When an HTTP message includes the content of a single range (for |  | When an HTTP message includes the content of a single range (for |
| example, a response to a request for a single range, or to a request |  | example, a response to a request for a single range, or to a request |
| for a set of ranges that overlap without any holes), this content is |  | for a set of ranges that overlap without any holes), this content is |
| transmitted with a Content-Range header, and a Content-Length header |  | transmitted with a Content-Range header, and a Content-Length header |
| showing the number of bytes actually transferred. For example, |  | showing the number of bytes actually transferred. For example, |
| HTTP/1.1 206 Partial content |  | HTTP/1.1 206 Partial content |
| Date: Wed, 15 Nov 1995 06:25:24 GMT |  | Date: Wed, 15 Nov 1995 06:25:24 GMT |
| Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |  | Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT |
| Content-Range: bytes 21010-47021/47022 |  | Content-Range: bytes 21010-47021/47022 |
| Content-Length: 26012 |  | Content-Length: 26012 |
| Content-Type: image/gif |  | Content-Type: image/gif |
| When an HTTP message includes the content of multiple ranges (for |  | When an HTTP message includes the content of multiple ranges (for |
| example, a response to a request for multiple non-overlapping |  | example, a response to a request for multiple non-overlapping |
| ranges), these are transmitted as a multipart message. The multipart |  | ranges), these are transmitted as a multipart message. The multipart |
| media type used for this purpose is "multipart/byteranges" as defined |  | media type used for this purpose is "multipart/byteranges" as defined |
| in appendix 19.2. See appendix 19.6.3 for a compatibility issue. |  | in Appendix A.2. See Appendix A.6.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). |
| If the server receives a request (other than one including an If- |  | If the server receives a request (other than one including an If- |
| Range request-header field) with an unsatisfiable Range request- |  | Range request-header field) with an unsatisfiable Range request- |
| header field (that is, all of whose byte-range-spec values have a |  | header field (that is, all of whose byte-range-spec values have a |
| first-byte-pos value greater than the current length of the selected |  | first-byte-pos value greater than the current length of the selected |
| resource), it SHOULD return a response code of 416 (Requested range |  | resource), it SHOULD return a response code of 416 (Requested range |
| not satisfiable) (section 10.4.17). |  | not satisfiable) (Section 10.4.17). |
| Note: clients cannot depend on servers to send a 416 (Requested |  | Note: clients cannot depend on servers to send a 416 (Requested |
| range not satisfiable) response instead of a 200 (OK) response for |  | range not satisfiable) response instead of a 200 (OK) response for |
| an unsatisfiable Range request-header, since not all servers |  | an unsatisfiable Range request-header, since not all servers |
| implement this request-header. |  | implement this request-header. |
| 14.17 Content-Type |  | 14.17. Content-Type |
| The Content-Type entity-header field indicates the media type of the |  | The Content-Type entity-header field indicates the media type of the |
| entity-body sent to the recipient or, in the case of the HEAD method, |  | entity-body sent to the recipient or, in the case of the HEAD method, |
| the media type that would have been sent had the request been a GET. |  | the media type that would have been sent had the request been a GET. |
| Content-Type = "Content-Type" ":" media-type |  | Content-Type = "Content-Type" ":" media-type |
| Media types are defined in section 3.7. An example of the field is |  | Media types are defined in Section 3.7. An example of the field is |
| Content-Type: text/html; charset=ISO-8859-4 |  | Content-Type: text/html; charset=ISO-8859-4 |
| Further discussion of methods for identifying the media type of an |  | Further discussion of methods for identifying the media type of an |
| entity is provided in section 7.2.1. |  | entity is provided in Section 7.2.1. |
| 14.18 Date |  | 14.18. Date |
| The Date general-header field represents the date and time at which |  | The Date general-header field represents the date and time at which |
| the message was originated, having the same semantics as orig-date in |  | the message was originated, having the same semantics as orig-date in |
| RFC 822. The field value is an HTTP-date, as described in 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 [RFC1123]-date format. |
| Date = "Date" ":" HTTP-date |  | Date = "Date" ":" HTTP-date |
| An example is |  | An example is |
| Date: Tue, 15 Nov 1994 08:12:31 GMT |  | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Origin servers MUST include a Date header field in all responses, |  | Origin servers MUST include a Date header field in all responses, |
| except in these cases: |  | except in these cases: |
| 1. If the response status code is 100 (Continue) or 101 (Switching |  | 1. If the response status code is 100 (Continue) or 101 (Switching |
| Protocols), the response MAY include a Date header field, at |  | 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 [RFC1305], to synchronize |
| clock with a reliable external standard. |  | its clock with a reliable external standard. |
| Clients SHOULD only send a Date header field in messages that include |  | Clients SHOULD only send a Date header field in messages that include |
| an entity-body, as in the case of the PUT and POST requests, and even |  | an entity-body, as in the case of the PUT and POST requests, and even |
| then it is optional. A client without a clock MUST NOT send a Date |  | then it is optional. A client without a clock MUST NOT send a Date |
| header field in a request. |  | header field in a request. |
| The HTTP-date sent in a Date header SHOULD NOT represent a date and |  | The HTTP-date sent in a Date header SHOULD NOT represent a date and |
| time subsequent to the generation of the message. It SHOULD 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 |
| The Expect request-header field is used to indicate that particular |  | The Expect request-header field is used to indicate that particular |
| server behaviors are required by the client. |  | server behaviors are required by the client. |
| Expect = "Expect" ":" 1#expectation |  | Expect = "Expect" ":" 1#expectation |
| expectation = "100-continue" | expectation-extension |  | expectation = "100-continue" | expectation-extension |
| expectation-extension = token [ "=" ( token | quoted-string ) |  | expectation-extension = token [ "=" ( token | quoted-string ) |
| *expect-params ] |  | *expect-params ] |
| expect-params = ";" token [ "=" ( token | quoted-string ) ] |  | expect-params = ";" token [ "=" ( token | quoted-string ) ] |
| skipping to change at page 127, line 14 |  | skipping to change at page 130, line 5 |
| The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |  | The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST |
| return a 417 (Expectation Failed) status if it receives a request |  | return a 417 (Expectation Failed) status if it receives a request |
| with an expectation that it cannot meet. However, the Expect |  | with an expectation that it cannot meet. However, the Expect |
| request-header itself is end-to-end; it MUST be forwarded if the |  | request-header itself is end-to-end; it MUST be forwarded if the |
| request is forwarded. |  | request is forwarded. |
| Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |  | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the |
| Expect header. |  | Expect header. |
| See section 8.2.3 for the use of the 100 (continue) status. |  | See Section 8.2.3 for the use of the 100 (continue) status. |
| 14.21 Expires |  | 14.21. Expires |
| The Expires entity-header field gives the date/time after which the |  | The Expires entity-header field gives the date/time after which the |
| response is considered stale. A stale cache entry may not normally 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 |
| An example of its use is |  | An example of its use is |
| Expires: Thu, 01 Dec 1994 16:00:00 GMT |  | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
| Note: if a response includes a Cache-Control field with the max- |  | Note: if a response includes a Cache-Control field with the max- |
| age directive (see section 14.9.3), that directive overrides the |  | age directive (see Section 14.9.3), that directive overrides the |
| Expires field. |  | Expires field. |
| HTTP/1.1 clients and caches MUST treat other invalid date formats, |  | HTTP/1.1 clients and caches MUST treat other invalid date formats, |
| especially including the value "0", as in the past (i.e., "already |  | especially including the value "0", as in the past (i.e., "already |
| expired"). |  | expired"). |
| To mark a response as "already expired," an origin server sends an |  | To mark a response as "already expired," an origin server sends an |
| Expires date that is equal to the Date header value. (See the rules |  | Expires date that is equal to the Date header value. (See the rules |
| for expiration calculations in section 13.2.4.) |  | for expiration calculations in Section 13.2.4.) |
| To mark a response as "never expires," an origin server sends an |  | To mark a response as "never expires," an origin server sends an |
| Expires date approximately one year from the time the response is |  | Expires date approximately one year from the time the response is |
| sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one |  | sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one |
| year in the future. |  | year in the future. |
| The presence of an Expires header field with a date value of some |  | The presence of an Expires header field with a date value of some |
| time in the future on a response that otherwise would by default be |  | time in the future on a response that otherwise would by default be |
| non-cacheable indicates that the response is cacheable, unless |  | non-cacheable indicates that the response is cacheable, unless |
| indicated otherwise by a Cache-Control header field (section 14.9). |  | indicated otherwise by a Cache-Control header field (Section 14.9). |
| 14.22 From |  | 14.22. From |
| The From request-header field, if given, SHOULD contain an Internet |  | The From request-header field, if given, SHOULD contain an Internet |
| e-mail address for the human user who controls the requesting user |  | e-mail address for the human user who controls the requesting user |
| agent. The address SHOULD be machine-usable, as defined by "mailbox" |  | agent. The address SHOULD be machine-usable, as defined by "mailbox" |
| in RFC 822 [9] as updated by RFC 1123 [8]: |  | in RFC 822 [RFC822] as updated by RFC 1123 [RFC1123]: |
| From = "From" ":" mailbox |  | From = "From" ":" mailbox |
| An example is: |  | An example is: |
| From: webmaster@w3.org |  | From: webmaster@w3.org |
| This header field MAY be used for logging purposes and as a means for |  | This header field MAY be used for logging purposes and as a means for |
| identifying the source of invalid or unwanted requests. It SHOULD 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 |
| at any time prior to a request. |  | at any time prior to a request. |
| 14.23 Host |  | 14.23. Host |
| The Host request-header field specifies the Internet host and port |  | The Host request-header field specifies the Internet host and port |
| number of the resource being requested, as obtained from the original |  | number of the resource being requested, as obtained from the original |
| URI given by the user or referring resource (generally an HTTP URL, |  | URI given by the user or referring resource (generally an HTTP URL, |
| as described in section 3.2.2). The Host field value MUST represent |  | as described in Section 3.2.2). The Host field value MUST represent |
| the naming authority of the origin server or gateway given by the |  | the naming authority of the origin server or gateway given by the |
| original URL. This allows the origin server or gateway to |  | original URL. This allows the origin server or gateway to |
| differentiate between internally-ambiguous URLs, such as the root "/" |  | differentiate between internally-ambiguous URLs, such as the root "/" |
| URL of a server for multiple host names on a single IP address. |  | URL of a server for multiple host names on a single IP address. |
| Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |  | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |
| A "host" without any trailing port information implies the default |  | A "host" without any trailing port information implies the default |
| port for the service requested (e.g., "80" for an HTTP URL). For |  | port for the service requested (e.g., "80" for an HTTP URL). For |
| example, a request on the origin server for |  | example, a request on the origin server for |
| skipping to change at page 129, line 30 |  | skipping to change at page 132, line 20 |
| 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 A.6.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. |
| A server MUST use the strong comparison function (see section 13.3.3) |  | A server MUST use the strong comparison function (see Section 13.3.3) |
| to compare the entity tags in If-Match. |  | to compare the entity tags in If-Match. |
| If none of the entity tags match, or if "*" is given and no current |  | If none of the entity tags match, or if "*" is given and no current |
| entity exists, the server MUST NOT perform the requested method, and |  | entity exists, the server MUST NOT perform the requested method, and |
| MUST return a 412 (Precondition Failed) response. This behavior is |  | MUST return a 412 (Precondition Failed) response. This behavior is |
| most useful when the client wants to prevent an updating method, such |  | most useful when the client wants to prevent an updating method, such |
| as PUT, from modifying a resource that has changed since the client |  | as PUT, from modifying a resource that has changed since the client |
| last retrieved it. |  | last retrieved it. |
| If the request would, without the If-Match header field, result in |  | If the request would, without the If-Match header field, result in |
| anything other than a 2xx or 412 status, then the If-Match header |  | anything other than a 2xx or 412 status, then the If-Match header |
| MUST be ignored. |  | MUST be ignored. |
| The meaning of "If-Match: *" is that the method SHOULD be performed |  | The meaning of "If-Match: *" is that the method SHOULD be performed |
| if the representation selected by the origin server (or by a cache, |  | if the representation selected by the origin server (or by a cache, |
| possibly using the Vary mechanism, see section 14.44) exists, and |  | possibly using the Vary mechanism, see Section 14.44) exists, and |
| MUST NOT be performed if the representation does not exist. |  | MUST NOT be performed if the representation does not exist. |
| A request intended to update a resource (e.g., a PUT) MAY include an |  | A request intended to update a resource (e.g., a PUT) MAY include an |
| If-Match header field to signal that the request method MUST NOT be |  | If-Match header field to signal that the request method MUST NOT be |
| applied if the entity corresponding to the If-Match value (a single |  | applied if the entity corresponding to the If-Match value (a single |
| entity tag) is no longer a representation of that resource. This |  | entity tag) is no longer a representation of that resource. This |
| allows the user to indicate that they do not wish the request to be |  | allows the user to indicate that they do not wish the request to be |
| successful if the resource has been changed without their knowledge. |  | successful if the resource has been changed without their knowledge. |
| Examples: |  | Examples: |
| If-Match: "xyzzy" |  | If-Match: "xyzzy" |
| If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| If-Match: * |  | If-Match: * |
| The result of a request having both an If-Match header field and |  | The result of a request having both an If-Match header field and |
| either an If-None-Match or an If-Modified-Since header fields is |  | either an If-None-Match or an If-Modified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 14.25 If-Modified-Since |  | 14.25. If-Modified-Since |
| The If-Modified-Since request-header field is used with a method to |  | The If-Modified-Since request-header field is used with a method to |
| make it conditional: if the requested variant has not been modified |  | make it conditional: if the requested variant has not been modified |
| since the time specified in this field, an entity will not be |  | since the time specified in this field, an entity will not be |
| returned from the server; instead, a 304 (not modified) response will |  | returned from the server; instead, a 304 (not modified) response will |
| be returned without any message-body. |  | be returned without any message-body. |
| If-Modified-Since = "If-Modified-Since" ":" HTTP-date |  | If-Modified-Since = "If-Modified-Since" ":" HTTP-date |
| An example of the field is: |  | An example of the field is: |
| If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |  | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
| A GET method with an If-Modified-Since header and no Range header |  | A GET method with an If-Modified-Since header and no Range header |
| requests that the identified entity be transferred only if it has |  | requests that the identified entity be transferred only if it has |
| been modified since the date given by the If-Modified-Since header. |  | been modified since the date given by the If-Modified-Since header. |
| The algorithm for determining this includes the following cases: |  | The algorithm for determining this includes the following cases: |
| 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. |
| Note: When handling an If-Modified-Since header field, some |  | Note: When handling an If-Modified-Since header field, some |
| servers will use an exact date comparison function, rather than a |  | servers will use an exact date comparison function, rather than a |
| less-than function, for deciding whether to send a 304 (Not |  | less-than function, for deciding whether to send a 304 (Not |
| Modified) response. To get best results when sending an If- |  | Modified) response. To get best results when sending an If- |
| Modified-Since header field for cache validation, clients are |  | Modified-Since header field for cache validation, clients are |
| advised to use the exact date string received in a previous Last- |  | advised to use the exact date string received in a previous Last- |
| skipping to change at page 132, line 14 |  | skipping to change at page 135, line 5 |
| possibility of clock-skew-related problems if the If-Modified- |  | possibility of clock-skew-related problems if the If-Modified- |
| Since date is derived from the client's clock without correction |  | Since date is derived from the client's clock without correction |
| to the server's clock. Corrections for different time bases |  | to the server's clock. Corrections for different time bases |
| between client and server are at best approximate due to network |  | between client and server are at best approximate due to network |
| latency. |  | latency. |
| The result of a request having both an If-Modified-Since header field |  | The result of a request having both an If-Modified-Since header field |
| and either an If-Match or an If-Unmodified-Since header fields is |  | and either an If-Match or an If-Unmodified-Since header fields is |
| 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 |
| server behavior when both If-Modified-Since and If-None-Match appear |  | server behavior when both If-Modified-Since and If-None-Match appear |
| in the same request.) |  | in the same request.) |
| The meaning of "If-None-Match: *" is that the method MUST NOT be |  | The meaning of "If-None-Match: *" is that the method MUST NOT be |
| performed if the representation selected by the origin server (or by |  | performed if the representation selected by the origin server (or by |
| a cache, possibly using the Vary mechanism, see section 14.44) |  | a cache, possibly using the Vary mechanism, see Section 14.44) |
| exists, and SHOULD be performed if the representation does not exist. |  | exists, and SHOULD be performed if the representation does not exist. |
| This feature is intended to be useful in preventing races between PUT |  | This feature is intended to be useful in preventing races between PUT |
| operations. |  | operations. |
| Examples: |  | Examples: |
| If-None-Match: "xyzzy" |  | If-None-Match: "xyzzy" |
| If-None-Match: W/"xyzzy" |  | If-None-Match: W/"xyzzy" |
| If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |  | If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" |
| If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |  | If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" |
| If-None-Match: * |  | If-None-Match: * |
| The result of a request having both an If-None-Match header field and |  | The result of a request having both an If-None-Match header field and |
| either an If-Match or an If-Unmodified-Since header fields is |  | either an If-Match or an If-Unmodified-Since header fields is |
| undefined by this specification. |  | undefined by this specification. |
| 14.27 If-Range |  | 14.27. If-Range |
| 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 134, line 18 |  | skipping to change at page 137, line 5 |
| header SHOULD only be used together with a Range header, and MUST be |  | header SHOULD only be used together with a Range header, and MUST be |
| ignored if the request does not include a Range header, or if the |  | ignored if the request does not include a Range header, or if the |
| server does not support the sub-range operation. |  | server does not support the sub-range operation. |
| If the entity tag given in the If-Range header matches the current |  | If the entity tag given in the If-Range header matches the current |
| entity tag for the entity, then the server SHOULD provide the |  | entity tag for the entity, then the server SHOULD provide the |
| specified sub-range of the entity using a 206 (Partial content) |  | specified sub-range of the entity using a 206 (Partial content) |
| response. If the entity tag does not match, then the server SHOULD |  | response. If the entity tag does not match, then the server SHOULD |
| return the entire entity using a 200 (OK) response. |  | return the entire entity using a 200 (OK) response. |
| 14.28 If-Unmodified-Since |  | 14.28. If-Unmodified-Since |
| The If-Unmodified-Since request-header field is used with a method to |  | The If-Unmodified-Since request-header field is used with a method to |
| make it conditional. If the requested resource has not been modified |  | make it conditional. If the requested resource has not been modified |
| since the time specified in this field, the server SHOULD perform the |  | since the time specified in this field, the server SHOULD perform the |
| requested operation as if the If-Unmodified-Since header were not |  | requested operation as if the If-Unmodified-Since header were not |
| present. |  | present. |
| If the requested variant has been modified since the specified time, |  | If the requested variant has been modified since the specified time, |
| the server MUST NOT perform the requested operation, and MUST return |  | the server MUST NOT perform the requested operation, and MUST return |
| a 412 (Precondition Failed). |  | a 412 (Precondition Failed). |
| skipping to change at page 134, line 46 |  | skipping to change at page 137, line 33 |
| If the request normally (i.e., without the If-Unmodified-Since |  | If the request normally (i.e., without the If-Unmodified-Since |
| header) would result in anything other than a 2xx or 412 status, the |  | header) would result in anything other than a 2xx or 412 status, the |
| If-Unmodified-Since header SHOULD be ignored. |  | If-Unmodified-Since header SHOULD be ignored. |
| If the specified date is invalid, the header is ignored. |  | If the specified date is invalid, the header is ignored. |
| The result of a request having both an If-Unmodified-Since header |  | The result of a request having both an If-Unmodified-Since header |
| field and either an If-None-Match or an If-Modified-Since header |  | field and either an If-None-Match or an If-Modified-Since header |
| fields is undefined by this specification. |  | fields is undefined by this specification. |
| 14.29 Last-Modified |  | 14.29. Last-Modified |
| The Last-Modified entity-header field indicates the date and time at |  | The Last-Modified entity-header field indicates the date and time at |
| which the origin server believes the variant was last modified. |  | which the origin server believes the variant was last modified. |
| Last-Modified = "Last-Modified" ":" HTTP-date |  | Last-Modified = "Last-Modified" ":" HTTP-date |
| An example of its use is |  | An example of its use is |
| Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |  | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
| The exact meaning of this header field depends on the implementation |  | The exact meaning of this header field depends on the implementation |
| of the origin server and the nature of the original resource. For |  | of the origin server and the nature of the original resource. For |
| files, it may be just the file system last-modified time. For |  | files, it may be just the file system last-modified time. For |
| entities with dynamically included parts, it may be the most recent |  | entities with dynamically included parts, it may be the most recent |
| of the set of last-modify times for its component parts. For 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 |
| of the entity's modification time, especially if the entity changes |  | of the entity's modification time, especially if the entity changes |
| near the time that the response is generated. |  | near the time that the response is generated. |
| 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 |
| behavior from the viewpoint of the protocol; however, some systems |  | behavior from the viewpoint of the protocol; however, some systems |
| MAY require that behavior be consistent with the directives. |  | MAY require that behavior be consistent with the directives. |
| Pragma = "Pragma" ":" 1#pragma-directive |  | Pragma = "Pragma" ":" 1#pragma-directive |
| pragma-directive = "no-cache" | extension-pragma |  | pragma-directive = "no-cache" | extension-pragma |
| extension-pragma = token [ "=" ( token | quoted-string ) ] |  | extension-pragma = token [ "=" ( token | quoted-string ) ] |
| When the no-cache directive is present in a request message, an |  | When the no-cache directive is present in a request message, an |
| application SHOULD forward the request toward the origin server even |  | application SHOULD forward the request toward the origin server even |
| if it has a cached copy of what is being requested. This pragma |  | if it has a cached copy of what is being requested. This pragma |
| directive has the same semantics as the no-cache cache-directive (see |  | directive has the same semantics as the no-cache cache-directive (see |
| section 14.9) and is defined here for backward compatibility with |  | Section 14.9) and is defined here for backward compatibility with |
| HTTP/1.0. Clients SHOULD include both header fields when a no-cache |  | HTTP/1.0. Clients SHOULD include both header fields when a no-cache |
| request is sent to a server not known to be HTTP/1.1 compliant. |  | request is sent to a server not known to be HTTP/1.1 compliant. |
| Pragma directives MUST be passed through by a proxy or gateway |  | Pragma directives MUST be passed through by a proxy or gateway |
| 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 pragma for a |  | request/response chain. It is not possible to specify a pragma for a |
| specific recipient; however, any pragma directive not relevant to a |  | specific recipient; however, any pragma directive not relevant to a |
| recipient SHOULD be ignored by that recipient. |  | recipient SHOULD be ignored by that recipient. |
| HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had |  | HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had |
| sent "Cache-Control: no-cache". No new Pragma directives will be |  | sent "Cache-Control: no-cache". No new Pragma directives will be |
| defined in HTTP. |  | defined in HTTP. |
| Note: because the meaning of "Pragma: no-cache as a response |  | Note: because the meaning of "Pragma: no-cache as a response |
| header field is not actually specified, it does not provide a |  | header field is not actually specified, it does not provide a |
| reliable replacement for "Cache-Control: no-cache" in a response |  | reliable replacement for "Cache-Control: no-cache" in a response |
| 14.33 Proxy-Authenticate |  | 14.33. Proxy-Authenticate |
| The Proxy-Authenticate response-header field MUST be included as part |  | The Proxy-Authenticate response-header field MUST be included as part |
| of a 407 (Proxy Authentication Required) response. The field value |  | of a 407 (Proxy Authentication Required) response. The field value |
| consists of a challenge that indicates the authentication scheme and |  | consists of a challenge that indicates the authentication scheme and |
| parameters applicable to the proxy for this Request-URI. |  | parameters applicable to the proxy for this Request-URI. |
| Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge |  | Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge |
| The HTTP access authentication process is described in "HTTP |  | The HTTP access authentication process is described in "HTTP |
| Authentication: Basic and Digest Access Authentication" [43]. Unlike |  | Authentication: Basic and Digest Access Authentication" [RFC2617]. |
| WWW-Authenticate, the Proxy-Authenticate header field applies only to |  | Unlike WWW-Authenticate, the Proxy-Authenticate header field applies |
| the current connection and SHOULD NOT be passed on to downstream |  | only to the current connection and SHOULD NOT be passed on to |
| clients. However, an intermediate proxy might need to obtain its own |  | downstream clients. However, an intermediate proxy might need to |
| credentials by requesting them from the downstream client, which in |  | obtain its own credentials by requesting them from the downstream |
| some circumstances will appear as if the proxy is forwarding the |  | client, which in some circumstances will appear as if the proxy is |
| Proxy-Authenticate header field. |  | forwarding the Proxy-Authenticate header field. |
| 14.34 Proxy-Authorization |  | 14.34. Proxy-Authorization |
| The Proxy-Authorization request-header field allows the client to |  | The Proxy-Authorization request-header field allows the client to |
| identify itself (or its user) to a proxy which requires |  | identify itself (or its user) to a proxy which requires |
| authentication. The Proxy-Authorization field value consists of |  | authentication. The Proxy-Authorization field value consists of |
| credentials containing the authentication information of the user |  | credentials containing the authentication information of the user |
| agent for the proxy and/or realm of the resource being requested. |  | agent for the proxy and/or realm of the resource being requested. |
| Proxy-Authorization = "Proxy-Authorization" ":" credentials |  | Proxy-Authorization = "Proxy-Authorization" ":" credentials |
| The HTTP access authentication process is described in "HTTP |  | The HTTP access authentication process is described in "HTTP |
| Authentication: Basic and Digest Access Authentication" [43] . Unlike |  | Authentication: Basic and Digest Access Authentication" [RFC2617]. |
| Authorization, the Proxy-Authorization header field applies only to |  | Unlike Authorization, the Proxy-Authorization header field applies |
| the next outbound proxy that demanded authentication using the Proxy- |  | only to the next outbound proxy that demanded authentication using |
| Authenticate field. When multiple proxies are used in a chain, the |  | the Proxy-Authenticate field. When multiple proxies are used in a |
| Proxy-Authorization header field is consumed by the first outbound |  | chain, the Proxy-Authorization header field is consumed by the first |
| proxy that was expecting to receive credentials. A proxy MAY relay |  | outbound proxy that was expecting to receive credentials. A proxy |
| the credentials from the client request to the next proxy if that is |  | MAY relay the credentials from the client request to the next proxy |
| the mechanism by which the proxies cooperatively authenticate a given |  | if that is the mechanism by which the proxies cooperatively |
| request. |  | authenticate a given request. |
| 14.35 Range |  | 14.35. Range |
| 14.35.1 Byte Ranges |  | 14.35.1. Byte Ranges |
| Since all HTTP entities are represented in HTTP messages as sequences |  | Since all HTTP entities are represented in HTTP messages as sequences |
| of bytes, the concept of a byte range is meaningful for any HTTP |  | of bytes, the concept of a byte range is meaningful for any HTTP |
| entity. (However, not all clients and servers need to support byte- |  | entity. (However, not all clients and servers need to support byte- |
| range operations.) |  | range operations.) |
| Byte range specifications in HTTP apply to the sequence of bytes in |  | Byte range specifications in HTTP apply to the sequence of bytes in |
| the entity-body (not necessarily the same as the message-body). |  | the entity-body (not necessarily the same as the message-body). |
| A byte range operation MAY specify a single range of bytes, or a set |  | A byte range operation MAY specify a single range of bytes, or a set |
| skipping to change at page 139, line 8 |  | skipping to change at page 141, line 42 |
| 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 |  |  |
| is unsatisfiable, the server SHOULD return a response with a status |  | Otherwise, the byte-range-set is unsatisfiable. If the byte-range- |
| of 416 (Requested range not satisfiable). Otherwise, the server |  | set is unsatisfiable, the server SHOULD return a response with a |
| SHOULD return a response with a status of 206 (Partial Content) |  | status of 416 (Requested range not satisfiable). Otherwise, the |
| containing the satisfiable ranges of the entity-body. |  | server SHOULD return a response with a status of 206 (Partial |
|  |  | 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: |
| 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. |
| 14.36 Referer |  | 14.36. Referer |
| The Referer[sic] request-header field allows the client to specify, |  | The Referer[sic] request-header field allows the client to specify, |
| for the server's benefit, the address (URI) of the resource from |  | for the server's benefit, the address (URI) of the resource from |
| which the Request-URI was obtained (the "referrer", although the |  | which the Request-URI was obtained (the "referrer", although the |
| header field is misspelled.) The Referer request-header allows a |  | header field is misspelled.) The Referer request-header allows a |
| server to generate lists of back-links to resources for interest, |  | server to generate lists of back-links to resources for interest, |
| logging, optimized caching, etc. It also allows obsolete or mistyped |  | logging, optimized caching, etc. It also allows obsolete or mistyped |
| links to be traced for maintenance. The Referer field MUST NOT be |  | links to be traced for maintenance. The Referer field MUST NOT be |
| sent if the Request-URI was obtained from a source that does not have |  | sent if the Request-URI was obtained from a source that does not have |
| its own URI, such as input from the user keyboard. |  | its own URI, such as input from the user keyboard. |
| skipping to change at page 141, line 4 |  | skipping to change at page 143, line 38 |
| 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. |
| Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |  | Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) |
| Two examples of its use are |  | Two examples of its use are |
| Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |  | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT |
| Retry-After: 120 |  | Retry-After: 120 |
| In the latter example, the delay is 2 minutes. |  | In the latter example, the delay is 2 minutes. |
| 14.38 Server |  | 14.38. Server |
| The Server response-header field contains information about the |  | The Server response-header field contains information about the |
| software used by the origin server to handle the request. The field |  | software used by the origin server to handle the request. The field |
| can contain multiple product tokens (section 3.8) and comments |  | can contain multiple product tokens (Section 3.8) and comments |
| identifying the server and any significant subproducts. The product |  | identifying the server and any significant subproducts. The product |
| tokens are listed in order of their significance for identifying the |  | tokens are listed in order of their significance for identifying the |
| application. |  | application. |
| Server = "Server" ":" 1*( product | comment ) |  | Server = "Server" ":" 1*( product | comment ) |
| Example: |  | Example: |
| Server: CERN/3.0 libwww/2.17 |  | Server: CERN/3.0 libwww/2.17 |
| If the response is being forwarded through a proxy, the proxy |  | If the response is being forwarded through a proxy, the proxy |
| application MUST NOT modify the Server response-header. Instead, it |  | application MUST NOT modify the Server response-header. Instead, it |
| SHOULD include a Via field (as described in section 14.45). |  | SHOULD include a Via field (as described in Section 14.45). |
| Note: Revealing the specific software version of the server might |  | Note: Revealing the specific software version of the server might |
| allow the server machine to become more vulnerable to attacks |  | allow the server machine to become more vulnerable to attacks |
| against software that is known to contain security holes. Server |  | against software that is known to contain security holes. Server |
| implementors are encouraged to make this field a configurable |  | implementors are encouraged to make this field a configurable |
| option. |  | option. |
| 14.39 TE |  | 14.39. TE |
| The TE request-header field indicates what extension transfer-codings |  | The TE request-header field indicates what extension transfer-codings |
| it is willing to accept in the response and whether or not it is |  | it is willing to accept in the response and whether or not it is |
| willing to accept trailer fields in a chunked transfer-coding. Its |  | willing to accept trailer fields in a chunked transfer-coding. Its |
| value may consist of the keyword "trailers" and/or a comma-separated |  | value may consist of the keyword "trailers" and/or a comma-separated |
| list of extension transfer-coding names with optional accept |  | list of extension transfer-coding names with optional accept |
| parameters (as described in section 3.6). |  | parameters (as described in Section 3.6). |
| TE = "TE" ":" #( t-codings ) |  | TE = "TE" ":" #( t-codings ) |
| t-codings = "trailers" | ( transfer-extension [ accept-params ] ) |  | t-codings = "trailers" | ( transfer-extension [ accept-params ] ) |
| The presence of the keyword "trailers" indicates that the client is |  | The presence of the keyword "trailers" indicates that the client is |
| willing to accept trailer fields in a chunked transfer-coding, as |  | willing to accept trailer fields in a chunked transfer-coding, as |
| defined in section 3.6.1. This keyword is reserved for use with |  | defined in Section 3.6.1. This keyword is reserved for use with |
| transfer-coding values even though it does not itself represent a |  | transfer-coding values even though it does not itself represent a |
| transfer-coding. |  | transfer-coding. |
| Examples of its use are: |  | Examples of its use are: |
| TE: deflate |  | TE: deflate |
| TE: |  | TE: |
| TE: trailers, deflate;q=0.5 |  | TE: trailers, deflate;q=0.5 |
| The TE header field only applies to the immediate connection. |  | The TE header field only applies to the immediate connection. |
| 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 |
| Transfer-codings are defined in section 3.6. An example is: |  | Transfer-codings are defined in Section 3.6. An example is: |
| Transfer-Encoding: chunked |  | Transfer-Encoding: chunked |
| If multiple encodings have been applied to an entity, the transfer- |  | If multiple encodings have been applied to an entity, the transfer- |
| 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. |
| Many older HTTP/1.0 applications do not understand the Transfer- |  | Many older HTTP/1.0 applications do not understand the Transfer- |
| Encoding header. |  | Encoding header. |
| 14.42 Upgrade |  | 14.42. Upgrade |
| The Upgrade general-header allows the client to specify what |  | The Upgrade general-header allows the client to specify what |
| additional communication protocols it supports and would like to use |  | additional communication protocols it supports and would like to use |
| if the server finds it appropriate to switch protocols. The server |  | if the server finds it appropriate to switch protocols. The server |
| MUST use the Upgrade header field within a 101 (Switching Protocols) |  | MUST use the Upgrade header field within a 101 (Switching Protocols) |
| response to indicate which protocol(s) are being switched. |  | response to indicate which protocol(s) are being switched. |
| Upgrade = "Upgrade" ":" 1#product |  | Upgrade = "Upgrade" ":" 1#product |
| For example, |  | For example, |
| Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |  | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| The Upgrade header field is intended to provide a simple mechanism |  | The Upgrade header field is intended to provide a simple mechanism |
| for transition from HTTP/1.1 to some other, incompatible protocol. 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. |
| The Upgrade header field only applies to the immediate connection. |  | The Upgrade header field only applies to the immediate connection. |
| Therefore, the upgrade keyword MUST be supplied within a Connection |  | Therefore, the upgrade keyword MUST be supplied within a Connection |
| header field (section 14.10) whenever Upgrade is present in an |  | header field (Section 14.10) whenever Upgrade is present in an |
| HTTP/1.1 message. |  | HTTP/1.1 message. |
| The Upgrade header field cannot be used to indicate a switch to a |  | The Upgrade header field cannot be used to indicate a switch to a |
| protocol on a different connection. For that purpose, it is more |  | protocol on a different connection. For that purpose, it is more |
| appropriate to use a 301, 302, 303, or 305 redirection response. |  | appropriate to use a 301, 302, 303, or 305 redirection response. |
| 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 |
| fully determines, while the response is fresh, whether a cache is |  | fully determines, while the response is fresh, whether a cache is |
| permitted to use the response to reply to a subsequent request |  | permitted to use the response to reply to a subsequent request |
| without revalidation. For uncacheable or stale responses, the Vary |  | without revalidation. For uncacheable or stale responses, the Vary |
| field value advises the user agent about the criteria that were used |  | field value advises the user agent about the criteria that were used |
| to select the representation. A Vary field value of "*" implies that |  | to select the representation. A Vary field value of "*" implies that |
| a cache cannot determine from the request headers of a subsequent |  | a cache cannot determine from the request headers of a subsequent |
| request whether this response is the appropriate representation. See |  | request whether this response is the appropriate representation. See |
| section 13.6 for use of the Vary header field by caches. |  | Section 13.6 for use of the Vary header field by caches. |
| Vary = "Vary" ":" ( "*" | 1#field-name ) |  | Vary = "Vary" ":" ( "*" | 1#field-name ) |
| An HTTP/1.1 server SHOULD include a Vary header field with any |  | An HTTP/1.1 server SHOULD include a Vary header field with any |
| cacheable response that is subject to server-driven negotiation. |  | cacheable response that is subject to server-driven negotiation. |
| Doing so allows a cache to properly interpret future requests on that |  | Doing so allows a cache to properly interpret future requests on that |
| resource and informs the user agent about the presence of negotiation |  | resource and informs the user agent about the presence of negotiation |
| on that resource. A server MAY include a Vary header field with a |  | on that resource. A server MAY include a Vary header field with a |
| non-cacheable response that is subject to server-driven negotiation, |  | non-cacheable response that is subject to server-driven negotiation, |
| since this might provide the user agent with useful information about |  | since this might provide the user agent with useful information about |
| skipping to change at page 146, line 18 |  | skipping to change at page 149, line 7 |
| 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 |
| indicate the intermediate protocols and recipients between the user |  | indicate the intermediate protocols and recipients between the user |
| agent and the server on requests, and between the origin server and |  | agent and the server on requests, and between the origin server and |
| the client on responses. It is analogous to the "Received" field of |  | the client on responses. It is analogous to the "Received" field of |
| RFC 822 [9] and is intended to be used for tracking message forwards, |  | RFC 822 [RFC822] and is intended to be used for tracking message |
| avoiding request loops, and identifying the protocol capabilities of |  | forwards, avoiding request loops, and identifying the protocol |
| all senders along the request/response chain. |  | capabilities of 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 4 |  | skipping to change at page 150, line 37 |
| For organizations that have strong privacy requirements for hiding |  | For organizations that have strong privacy requirements for hiding |
| internal structures, a proxy MAY combine an ordered subsequence of |  | internal structures, a proxy MAY combine an ordered subsequence of |
| Via header field entries with identical received-protocol values into |  | Via header field entries with identical received-protocol values into |
| a single such entry. For example, |  | a single such entry. For example, |
| Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |  | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
| could be collapsed to |  | could be collapsed to |
| Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |  | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
| Applications SHOULD NOT combine multiple entries unless they are all |  | Applications SHOULD NOT combine multiple entries unless they are all |
| under the same organizational control and the hosts have already been |  | under the same organizational control and the hosts have already been |
| replaced by pseudonyms. Applications MUST NOT combine entries which |  | replaced by pseudonyms. Applications MUST NOT combine entries which |
| have different received-protocol values. |  | have different received-protocol values. |
| 14.46 Warning |  | 14.46. Warning |
| The Warning general-header field is used to carry additional |  | The Warning general-header field is used to carry additional |
| information about the status or transformation of a message which |  | information about the status or transformation of a message which |
| might not be reflected in the message. This information is typically |  | might not be reflected in the message. This information is typically |
| used to warn about a possible lack of semantic transparency from |  | used to warn about a possible lack of semantic transparency from |
| caching operations or transformations applied to the entity body of |  | caching operations or transformations applied to the entity body of |
| the message. |  | the message. |
| Warning headers are sent with responses using: |  | Warning headers are sent with responses using: |
| skipping to change at page 148, line 36 |  | skipping to change at page 151, line 21 |
| 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 [RFC2047]. |
| Warning headers can in general be applied to any message, however |  | Warning headers can in general be applied to any message, however |
| some specific warn-codes are specific to caches and can only be |  | some specific warn-codes are specific to caches and can only be |
| applied to response messages. New Warning headers SHOULD be added |  | applied to response messages. New Warning headers SHOULD be added |
| after any existing Warning headers. A cache MUST NOT delete any |  | after any existing Warning headers. A cache MUST NOT delete any |
| Warning header that it received with a message. However, if a cache |  | Warning header that it received with a message. However, if a cache |
| successfully validates a cache entry, it SHOULD remove any Warning |  | successfully validates a cache entry, it SHOULD remove any Warning |
| headers previously attached to that entry except as specified for |  | headers previously attached to that entry except as specified for |
| specific Warning codes. It MUST then add any Warning headers 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. |
| 110 Response is stale |  | 110 Response is stale |
| MUST be included whenever the returned response is stale. |  | MUST be included whenever the returned response is stale. |
| 111 Revalidation failed |  | 111 Revalidation failed |
| MUST be included if a cache returns a stale response because an |  | MUST be included if a cache returns a stale response because an |
| attempt to revalidate the response failed, due to an inability to |  | attempt to revalidate the response failed, due to an inability to |
| reach the server. |  | reach the server. |
| 112 Disconnected operation |  | 112 Disconnected operation |
| SHOULD be included if the cache is intentionally disconnected from |  | SHOULD be included if the cache is intentionally disconnected from |
| the rest of the network for a period of time. |  | the rest of the network for a period of time. |
| 113 Heuristic expiration |  | 113 Heuristic expiration |
| MUST be included if the cache heuristically chose a freshness |  | MUST be included if the cache heuristically chose a freshness |
| 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 150, line 29 |  | skipping to change at page 153, line 23 |
| 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 |
| value in the response, then that warning-value MUST be deleted from |  | value in the response, then that warning-value MUST be deleted from |
| the message before storing, forwarding, or using it. (This prevents |  | the message before storing, forwarding, or using it. (This prevents |
| bad consequences of naive caching of Warning header fields.) If all |  | bad consequences of naive caching of Warning header fields.) If all |
| of the warning-values are deleted for this reason, the Warning header |  | of the warning-values are deleted for this reason, the Warning header |
| MUST be deleted as well. |  | MUST be deleted as well. |
| 14.47 WWW-Authenticate |  | 14.47. WWW-Authenticate |
| The WWW-Authenticate response-header field MUST be included in 401 |  | The WWW-Authenticate response-header field MUST be included in 401 |
| (Unauthorized) response messages. The field value consists of at |  | (Unauthorized) response messages. The field value consists of at |
| least one challenge that indicates the authentication scheme(s) and |  | least one challenge that indicates the authentication scheme(s) and |
| parameters applicable to the Request-URI. |  | parameters applicable to the Request-URI. |
| WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |  | WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge |
| The HTTP access authentication process is described in "HTTP |  | The HTTP access authentication process is described in "HTTP |
| Authentication: Basic and Digest Access Authentication" [43]. User |  | Authentication: Basic and Digest Access Authentication" [RFC2617]. |
| agents are advised to take special care in parsing the WWW- |  | User agents are advised to take special care in parsing the WWW- |
| Authenticate field value as it might contain more than one challenge, |  | Authenticate field value as it might contain more than one challenge, |
| or if more than one WWW-Authenticate header field is provided, the |  | or if more than one WWW-Authenticate header field is provided, the |
| contents of a challenge itself can contain a comma-separated list of |  | contents of a challenge itself can contain a comma-separated list of |
| authentication parameters. |  | authentication parameters. |
| 15 Security Considerations |  | 15. Security Considerations |
| This section is meant to inform application developers, information |  | This section is meant to inform application developers, information |
| providers, and users of the security limitations in HTTP/1.1 as |  | providers, and users of the security limitations in HTTP/1.1 as |
| described by this document. The discussion does not include |  | described by this document. The discussion does not include |
| definitive solutions to the problems revealed, though it does make |  | definitive solutions to the problems revealed, though it does make |
| some suggestions for reducing security risks. |  | some suggestions for reducing security risks. |
| 15.1 Personal Information |  | 15.1. Personal Information |
| HTTP clients are often privy to large amounts of personal information |  | HTTP clients are often privy to large amounts of personal information |
| (e.g. the user's name, location, mail address, passwords, encryption |  | (e.g. the user's name, location, mail address, passwords, encryption |
| keys, etc.), and SHOULD be very careful to prevent unintentional |  | keys, etc.), and SHOULD be very careful to prevent unintentional |
| leakage of this information via the HTTP protocol to other sources. |  | leakage of this information via the HTTP protocol to other sources. |
| We very strongly recommend that a convenient interface be provided |  | We very strongly recommend that a convenient interface be provided |
| for the user to control dissemination of such information, and that |  | for the user to control dissemination of such information, and that |
| 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 |
| be provided for the user to enable or disable the sending of From and |  | be provided for the user to enable or disable the sending of From and |
| Referer information. |  | Referer information. |
| The User-Agent (section 14.43) or Server (section 14.38) header |  | The User-Agent (Section 14.43) or Server (Section 14.38) header |
| fields can sometimes be used to determine that a specific client or |  | fields can sometimes be used to determine that a specific client or |
| server have a particular security hole which might be exploited. |  | server have a particular security hole which might be exploited. |
| Unfortunately, this same information is often used for other valuable |  | Unfortunately, this same information is often used for other valuable |
| purposes for which HTTP currently has no better mechanism. |  | purposes for which HTTP currently has no better mechanism. |
| 15.1.3 Encoding Sensitive Information in URI's |  | 15.1.3. Encoding Sensitive Information in URI's |
| Because the source of a link might be private information or might |  | Because the source of a link might be private information or might |
| reveal an otherwise private information source, it is strongly |  | reveal an otherwise private information source, it is strongly |
| recommended that the user be able to select whether or not the |  | recommended that the user be able to select whether or not the |
| Referer field is sent. For example, a browser client could have a |  | Referer field is sent. For example, a browser client could have a |
| toggle switch for browsing openly/anonymously, which would |  | toggle switch for browsing openly/anonymously, which would |
| respectively enable/disable the sending of Referer and From |  | respectively enable/disable the sending of Referer and From |
| information. |  | information. |
| Clients SHOULD NOT include a Referer header field in a (non-secure) |  | Clients SHOULD NOT include a Referer header field in a (non-secure) |
| HTTP request if the referring page was transferred with a secure |  | HTTP request if the referring page was transferred with a secure |
| protocol. |  | protocol. |
| Authors of services which use the HTTP protocol SHOULD NOT use GET |  | Authors of services which use the HTTP protocol SHOULD NOT use GET |
| based forms for the submission of sensitive data, because this will |  | based forms for the submission of sensitive data, because this will |
| cause this data to be encoded in the Request-URI. Many existing |  | cause this data to be encoded in the Request-URI. Many existing |
| servers, proxies, and user agents will log the request URI in some |  | servers, proxies, and user agents will log the request URI in some |
| place where it might be visible to third parties. Servers can use |  | place where it might be visible to third parties. Servers can use |
| POST-based form submission instead |  | POST-based form submission instead |
| 15.1.4 Privacy Issues Connected to Accept Headers |  | 15.1.4. Privacy Issues Connected to Accept Headers |
| Accept request-headers can reveal information about the user to all |  | Accept request-headers can reveal information about the user to all |
| servers which are accessed. The Accept-Language header in particular |  | servers which are accessed. The Accept-Language header in particular |
| can reveal information the user would consider to be of a private |  | can reveal information the user would consider to be of a private |
| nature, because the understanding of particular languages is often |  | nature, because the understanding of particular languages is often |
| strongly correlated to the membership of a particular ethnic group. |  | strongly correlated to the membership of a particular ethnic group. |
| User agents which offer the option to configure the contents of an |  | User agents which offer the option to configure the contents of an |
| Accept-Language header to be sent in every request are strongly |  | Accept-Language header to be sent in every request are strongly |
| encouraged to let the configuration process include a message which |  | encouraged to let the configuration process include a message which |
| makes the user aware of the loss of privacy involved. |  | makes the user aware of the loss of privacy involved. |
| skipping to change at page 153, line 33 |  | skipping to change at page 156, line 28 |
| many users not behind a proxy, the network address of the host |  | many users not behind a proxy, the network address of the host |
| running the user agent will also serve as a long-lived user |  | running the user agent will also serve as a long-lived user |
| identifier. In environments where proxies are used to enhance |  | identifier. In environments where proxies are used to enhance |
| privacy, user agents ought to be conservative in offering accept |  | privacy, user agents ought to be conservative in offering accept |
| header configuration options to end users. As an extreme privacy |  | header configuration options to end users. As an extreme privacy |
| measure, proxies could filter the accept headers in relayed requests. |  | measure, proxies could filter the accept headers in relayed requests. |
| General purpose user agents which provide a high degree of header |  | General purpose user agents which provide a high degree of header |
| configurability SHOULD warn users about the loss of privacy which can |  | configurability SHOULD warn users about the loss of privacy which can |
| be involved. |  | be involved. |
| 15.2 Attacks Based On File and Path Names |  | 15.2. Attacks Based On File and Path Names |
| Implementations of HTTP origin servers SHOULD be careful to restrict |  | Implementations of HTTP origin servers SHOULD be careful to restrict |
| the documents returned by HTTP requests to be only those that were |  | the documents returned by HTTP requests to be only those that were |
| intended by the server administrators. If an HTTP server translates |  | intended by the server administrators. If an HTTP server translates |
| HTTP URIs directly into file system calls, the server MUST take |  | HTTP URIs directly into file system calls, the server MUST take |
| 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 [RFC1900], the |
| possibility of this form of attack will grow. Observing this |  | possibility of this form of attack will grow. Observing this |
| requirement thus reduces this potential security vulnerability. |  | requirement thus reduces this potential security vulnerability. |
| This requirement also improves the load-balancing behavior of clients |  | This requirement also improves the load-balancing behavior of clients |
| for replicated servers using the same DNS name and reduces the |  | for replicated servers using the same DNS name and reduces the |
| likelihood of a user's experiencing failure in accessing sites which |  | likelihood of a user's experiencing failure in accessing sites which |
| use that strategy. |  | use that strategy. |
| 15.4 Location Headers and Spoofing |  | 15.4. Location Headers and Spoofing |
| If a single server supports multiple organizations that do not trust |  | If a single server supports multiple organizations that do not trust |
| one another, then it MUST check the values of Location and Content- |  | one another, then it MUST check the values of Location and Content- |
| Location headers in responses that are generated under control of |  | Location headers in responses that are generated under control of |
| said organizations to make sure that they do not attempt to |  | said organizations to make sure that they do not attempt to |
| invalidate resources over which they have no authority. |  | invalidate resources over which they have no authority. |
| 15.5 Content-Disposition Issues |  | 15.5. Content-Disposition Issues |
| RFC 1806 [35], from which the often implemented Content-Disposition |  | RFC 1806 [RFC1806], from which the often implemented Content- |
| (see section 19.5.1) header in HTTP is derived, has a number of very |  | Disposition (see Appendix A.5.1) header in HTTP is derived, has a |
| serious security considerations. Content-Disposition is not part of |  | number of very serious security considerations. Content-Disposition |
| the HTTP standard, but since it is widely implemented, we are |  | is not part of the HTTP standard, but since it is widely implemented, |
| documenting its use and risks for implementors. See RFC 2183 [49] |  | we are documenting its use and risks for implementors. See RFC 2183 |
| (which updates RFC 1806) for details. |  | [RFC2183] (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 25 |  | skipping to change at page 159, line 17 |
| configuration options they provide to proxy operators (especially the |  | configuration options they provide to proxy operators (especially the |
| default configuration). |  | default configuration). |
| Users of a proxy need to be aware that they are no trustworthier than |  | Users of a proxy need to be aware that they are no trustworthier than |
| the people who run the proxy; HTTP itself cannot solve this problem. |  | the people who run the proxy; HTTP itself cannot solve this problem. |
| The judicious use of cryptography, when appropriate, may suffice to |  | The judicious use of cryptography, when appropriate, may suffice to |
| 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 |
| 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 [RFC822]. |
| reuses many of the definitions provided by Nathaniel Borenstein and |  | Similarly, it reuses many of the definitions provided by Nathaniel |
| Ned Freed for MIME [7]. We hope that their inclusion in this |  | Borenstein and Ned Freed for MIME [RFC2045]. We hope that their |
| specification will help reduce past confusion over the relationship |  | inclusion in this specification will help reduce past confusion over |
| between HTTP and Internet mail message formats. |  | the relationship between HTTP and Internet mail message formats. |
| The HTTP protocol has evolved considerably over the years. It has |  | The HTTP protocol has evolved considerably over the years. It has |
| benefited from a large and active developer community--the many |  | benefited from a large and active developer community--the many |
| people who have participated on the www-talk mailing list--and it is |  | people who have participated on the www-talk mailing list--and it is |
| that community which has been most responsible for the success of |  | that community which has been most responsible for the success of |
| HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |  | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
| Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |  | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
| Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |  | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
| McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |  | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
| VanHeyningen deserve special recognition for their efforts in |  | VanHeyningen deserve special recognition for their efforts in |
| defining early aspects of the protocol. |  | defining early aspects of the protocol. |
| This document has benefited greatly from the comments of all those |  | This document has benefited greatly from the comments of all those |
| participating in the HTTP-WG. In addition to those already 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 161, 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 |  | 17. References |
| [1] Alvestrand, H., "Tags for the Identification of Languages", RFC |  |  |
| 1766, March 1995. |  |  |
| [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, |  |  |
| D. and B. Alberti, "The Internet Gopher Protocol (a distributed |  |  |
| document search and retrieval protocol)", RFC 1436, March 1993. |  |  |
| [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC |  |  |
| 1630, June 1994. |  |  |
| [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource |  |  |
| Locators (URL)", RFC 1738, December 1994. |  |  |
| [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - |  |  |
| 2.0", RFC 1866, November 1995. |  |  |
| [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer |  |  |
| Protocol -- HTTP/1.0", RFC 1945, May 1996. |  |  |
| [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [ISO-8859] |
| Extensions (MIME) Part One: Format of Internet Message Bodies", |  | International Organization for Standardization, |
| RFC 2045, November 1996. |  | "Information technology - 8-bit single byte coded graphic |
|  |  | - character sets", 1987-1990. |
| [8] Braden, R., "Requirements for Internet Hosts -- Communication |  | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: |
| Layers", STD 3, RFC 1123, October 1989. |  | 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. |
| [9] Crocker, D., "Standard for The Format of ARPA Internet Text |  | [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web |
| Messages", STD 11, RFC 822, August 1982. |  | proxy servers", Work in Progress. |
| [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., |  | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
| Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype |  | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
| Functional Specification," (v1.5), Thinking Machines |  | and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , |
| Corporation, April 1990. |  | Sep 1997. |
| [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, |  | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
| June 1995. |  | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
|  |  | Dec 1995. |
| [12] Horton, M. and R. Adams, "Standard for Interchange of USENET |  | Slightly revised version of paper in Proc. 2nd |
| Messages", RFC 1036, December 1987. |  | 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>. |
| [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC |  | [RFC1036] Horton, M. and R. Adams, "Standard for interchange of |
| 977, February 1986. |  | USENET messages", RFC 1036, December 1987. |
| [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part |  | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |
| Three: Message Header Extensions for Non-ASCII Text", RFC 2047, |  | and Support", STD 3, RFC 1123, October 1989. |
| November 1996. |  |  |
| [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC |  | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
| 1867, November 1995. |  | Specification, Implementation", RFC 1305, March 1992. |
| [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, |  | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |
| August 1982. |  | Torrey, D., and B. Alberti, "The Internet Gopher Protocol |
|  |  | (a distributed document search and retrieval protocol)", |
|  |  | RFC 1436, March 1993. |
| [17] Postel, J., "Media Type Registration Procedure", RFC 1590, |  | [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, |
| November 1996. |  | November 1996. |
| [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC |  | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A |
| 959, October 1985. |  | 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. |
| [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, |  | [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, |
| October 1994. |  | RFC 1700, October 1994. |
| [20] Sollins, K. and L. Masinter, "Functional Requirements for |  | [RFC1737] 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 |  | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform |
| Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986. |  | Resource Locators (URL)", RFC 1738, December 1994. |
| [22] ISO-8859. International Standard -- Information Processing -- |  |  |
| 8-bit Single-Byte Coded Graphic Character Sets -- |  |  |
| Part 1: Latin alphabet No. 1, ISO-8859-1:1987. |  |  |
| 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 |  | [RFC1766] Alvestrand, H., "Tags for the Identification of |
| 1864, October 1995. |  | Languages", RFC 1766, March 1995. |
| [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC |  | [RFC1806] Troost, R. and S. Dorner, "Communicating Presentation |
| 1900, February 1996. |  | Information in Internet Messages: The Content-Disposition |
|  |  | Header", RFC 1806, June 1995. |
| [25] Deutsch, P., "GZIP file format specification version 4.3", RFC |  | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", |
| 1952, May 1996. |  | RFC 1808, June 1995. |
| [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP |  | [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", |
| Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, |  | RFC 1864, October 1995. |
| 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 |  | [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup |
| Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, |  | Language - 2.0", RFC 1866, November 1995. |
| ISI Research Report ISI/RR-98-463, (original report dated Aug. |  |  |
| 1996), USC/Information Sciences Institute, August 1998. |  |  |
| [28] Mills, D., "Network Time Protocol (Version 3) Specification, |  | [RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in |
| Implementation and Analysis", RFC 1305, March 1992. |  | HTML", RFC 1867, November 1995. |
| [29] Deutsch, P., "DEFLATE Compressed Data Format Specification |  | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
| version 1.3", RFC 1951, May 1996. |  | RFC 1900, February 1996. |
| [30] S. Spero, "Analysis of HTTP Performance Problems," |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| http://sunsite.unc.edu/mdma-release/http-prob.html. |  | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format |  | [RFC1950] 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., |  | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification |
| Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: |  | version 1.3", RFC 1951, May 1996. |
| Digest Access Authentication", RFC 2069, January 1997. |  |  |
| [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. |  |  |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC |  |  |
| 2068, January 1997. |  |  |
| [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement |  |  |
| Levels", BCP 14, RFC 2119, March 1997. |  |  |
| [35] Troost, R. and Dorner, S., "Communicating Presentation |  |  |
| Information in Internet Messages: The Content-Disposition |  |  |
| Header", RFC 1806, June 1995. |  |  |
| [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and |  | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. |
| Interpretation of HTTP Version Numbers", RFC 2145, May 1997. |  |  |
| [jg639] |  |  |
| [37] Palme, J., "Common Internet Message Headers", RFC 2076, February |  | Randers-Pehrson, "GZIP file format specification version |
| 1997. [jg640] |  | 4.3", RFC 1952, May 1996. |
| [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., |  | [RFC2026] Bradner, S., "The Internet Standards Process -- Revision |
| Lie, H., and C. Lilley. "Network Performance Effects of |  | 3", BCP 9, RFC 2026, October 1996. |
| HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes |  |  |
| France, September 1997.[jg642] |  |  |
| [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Extensions (MIME) Part Two: Media Types", RFC 2046, November |  | Extensions (MIME) Part One: Format of Internet Message |
| 1996. [jg643] |  | Bodies", RFC 2045, November 1996. |
| [41] Alvestrand, H., "IETF Policy on Character Sets and Languages", |  | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| BCP 18, RFC 2277, January 1998. [jg644] |  | Extensions (MIME) Part Two: Media Types", RFC 2046, |
|  |  | November 1996. |
| [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource |  | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
| Identifiers (URI): Generic Syntax and Semantics", RFC 2396, |  | Part Three: Message Header Extensions for Non-ASCII Text", |
| August 1998. [jg645] |  | RFC 2047, November 1996. |
| [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |  | [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP |  | Extensions (MIME) Part Five: Conformance Criteria and |
| Authentication: Basic and Digest Access Authentication", RFC |  | Examples", RFC 2049, November 1996. |
| 2617, June 1999. [jg646] |  |  |
| [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| servers," Work in Progress. [jg647] |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
|  |  | RFC 2068, January 1997. |
| [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of |  | [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., |
| Aggregate Documents, such as HTML (MHTML)", RFC 2110, March |  | Luotonen, A., Sink, E., and L. Stewart, "An Extension to |
| 1997. |  | HTTP : Digest Access Authentication", RFC 2069, |
|  |  | January 1997. |
| [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP |  | [RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, |
| 9, RFC 2026, October 1996. |  | February 1997. |
| [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol |  | [RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of |
| (HTCPCP/1.0)", RFC 2324, 1 April 1998. |  | Aggregate Documents, such as HTML (MHTML)", RFC 2110, |
|  |  | March 1997. |
| [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Extensions (MIME) Part Five: Conformance Criteria and Examples", |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| RFC 2049, November 1996. |  |  |
| [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation |  | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
| Information in Internet Messages: The Content-Disposition Header |  | and Interpretation of HTTP Version Numbers", RFC 2145, |
| Field", RFC 2183, August 1997. |  | May 1997. |
| 18 Authors' Addresses |  | [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating |
|  |  | Presentation Information in Internet Messages: The |
|  |  | Content-Disposition Header Field", RFC 2183, August 1997. |
| Roy T. Fielding |  | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and |
| Information and Computer Science |  | Languages", BCP 18, RFC 2277, January 1998. |
| University of California, Irvine |  |  |
| Irvine, CA 92697-3425, USA |  |  |
| Fax: +1 (949) 824-1715 |  | [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO |
| EMail: fielding@ics.uci.edu |  | 10646", RFC 2279, January 1998. |
| James Gettys |  | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol |
| World Wide Web Consortium |  | (HTCPCP/1.0)", RFC 2324, April 1998. |
| MIT Laboratory for Computer Science |  |  |
| 545 Technology Square |  |  |
| Cambridge, MA 02139, USA |  |  |
| Fax: +1 (617) 258 8682 |  | [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| EMail: jg@w3.org |  | Resource Identifiers (URI): Generic Syntax", RFC 2396, |
|  |  | August 1998. |
| Jeffrey C. Mogul |  | [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., |
| Western Research Laboratory |  | Leach, P., Luotonen, A., and L. Stewart, "HTTP |
| Compaq Computer Corporation |  | Authentication: Basic and Digest Access Authentication", |
| 250 University Avenue |  | RFC 2617, June 1999. |
| Palo Alto, California, 94305, USA |  |  |
| EMail: mogul@wrl.dec.com |  | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, |
|  |  | RFC 821, August 1982. |
| Henrik Frystyk Nielsen |  | [RFC822] Crocker, D., "Standard for the format of ARPA Internet |
| World Wide Web Consortium |  | text messages", STD 11, RFC 822, August 1982. |
| MIT Laboratory for Computer Science |  |  |
| 545 Technology Square |  |  |
| Cambridge, MA 02139, USA |  |  |
| Fax: +1 (617) 258 8682 |  | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |
| EMail: frystyk@w3.org |  | STD 9, RFC 959, October 1985. |
| Larry Masinter |  | [RFC977] Kantor, B. and P. Lapsley, "Network News Transfer |
| Xerox Corporation |  | Protocol", RFC 977, February 1986. |
| 3333 Coyote Hill Road |  |  |
| Palo Alto, CA 94034, USA |  |  |
| EMail: masinter@parc.xerox.com |  | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
| Paul J. Leach |  | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
| Microsoft Corporation |  |  |
| 1 Microsoft Way |  |  |
| Redmond, WA 98052, USA |  |  |
| EMail: paulle@microsoft.com |  | [Tou1998] 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/>. |
| Tim Berners-Lee |  | [USASCII] American National Standards Institute, "Coded Character |
| Director, World Wide Web Consortium |  | Set -- 7-bit American Standard Code for Information |
| MIT Laboratory for Computer Science |  | Interchange", ANSI X3.4, 1986. |
| 545 Technology Square |  |  |
| Cambridge, MA 02139, USA |  |  |
| Fax: +1 (617) 258 8682 |  | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |
| EMail: timbl@w3.org |  | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |
|  |  | Protocol Prototype Functional Specification (v1.5)", |
|  |  | Thinking Machines Corporation , April 1990. |
| 19 Appendices |  | Appendix A. Appendices |
| 19.1 Internet Media Type message/http and application/http |  | A.1. Internet Media Type message/http and application/http |
| In addition to defining the HTTP/1.1 protocol, this document serves |  | In addition to defining the HTTP/1.1 protocol, this document serves |
| as the specification for the Internet media type "message/http" and |  | as the specification for the Internet media type "message/http" and |
| "application/http". The message/http type can be used to enclose a |  | "application/http". The message/http type can be used to enclose a |
| single HTTP request or response message, provided that it obeys the |  | single HTTP request or response message, provided that it obeys the |
| MIME restrictions for all "message" types regarding line length and |  | MIME restrictions for all "message" types regarding line length and |
| encodings. The application/http type can be used to enclose a |  | encodings. The application/http type can be used to enclose a |
| pipeline of one or more HTTP request or response messages (not |  | pipeline of one or more HTTP request or response messages (not |
| intermixed). The following is to be registered with IANA [17]. |  | intermixed). The following is to be registered with IANA [RFC1590]. |
| Media Type name: message |  | Media Type name: message |
| Media subtype name: http |  | Media subtype name: http |
| Required parameters: none |  | Required parameters: none |
| Optional parameters: version, msgtype |  | Optional parameters: version, msgtype |
| version: The HTTP-Version number of the enclosed message |  |  |
| (e.g., "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 |  | A.2. 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 |
| Content-type: application/pdf |  | Content-type: application/pdf |
| Content-range: bytes 500-999/8000 |  | Content-range: bytes 500-999/8000 |
| skipping to change at page 165, line 47 |  | skipping to change at page 167, line 25 |
| ...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 [RFC2046] permits the boundary string to be |
| quoted, some existing implementations handle a quoted boundary |  | quoted, some existing implementations handle a quoted boundary |
| string incorrectly. |  | string 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 |  | A.3. 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 168, line 15 |
| 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 |  | A.4. 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 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME |
| allow entities to be transmitted in an open variety of |  | [RFC2045]) to allow entities to be transmitted in an open variety of |
| representations and with extensible mechanisms. However, RFC 2045 |  | representations and with extensible mechanisms. However, RFC 2045 |
| discusses mail, and HTTP has a few features that are different from |  | discusses mail, and HTTP has a few features that are different from |
| those described in RFC 2045. These differences were carefully chosen |  | those described in RFC 2045. These differences were carefully chosen |
| to optimize performance over binary connections, to allow greater |  | to optimize performance over binary connections, to allow greater |
| freedom in the use of new media types, to make date comparisons |  | freedom in the use of new media types, to make date comparisons |
| easier, and to acknowledge the practice of some early HTTP servers |  | easier, and to acknowledge the practice of some early HTTP servers |
| and clients. |  | and clients. |
| This appendix describes specific areas where HTTP differs from RFC |  | This appendix describes specific areas where HTTP differs from RFC |
| 2045. Proxies and gateways to strict MIME environments SHOULD be |  | 2045. Proxies and gateways to strict MIME environments SHOULD be |
| aware of these differences and provide the appropriate conversions |  | aware of these differences and provide the appropriate conversions |
| where necessary. Proxies and gateways from MIME environments to HTTP |  | where necessary. Proxies and gateways from MIME environments to HTTP |
| also need to be aware of the differences because some conversions |  | also need to be aware of the differences because some conversions |
| might be required. |  | might be required. |
| 19.4.1 MIME-Version |  | A.4.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 |
| Proxies/gateways are responsible for ensuring full compliance (where |  | 2045[RFC2045]). Proxies/gateways are responsible for ensuring full |
| possible) when exporting HTTP messages to strict MIME environments. |  | compliance (where 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 |  | A.4.2. Conversion to Canonical Form |
| RFC 2045 [7] requires that an Internet mail entity be converted to |  | RFC 2045 [RFC2045] requires that an Internet mail entity be converted |
| canonical form prior to being transferred, as described in section 4 |  | to canonical form prior to being transferred, as described in section |
| of RFC 2049 [48]. Section 3.7.1 of this document describes the forms |  | 4 of RFC 2049 [RFC2049]. Section 3.7.1 of this document describes |
| allowed for subtypes of the "text" media type when transmitted over |  | the forms allowed for subtypes of the "text" media type when |
| HTTP. RFC 2046 requires that content with a type of "text" represent |  | transmitted over HTTP. RFC 2046 requires that content with a type of |
| line breaks as CRLF and forbids the use of CR or LF outside of line |  | "text" represent line breaks as CRLF and forbids the use of CR or LF |
| break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a |  | outside of line break sequences. HTTP allows CRLF, bare CR, and bare |
| line break within text content when a message is transmitted over |  | LF to indicate a line break within text content when a message is |
| HTTP. |  | transmitted over 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 |  | A.4.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 |  | A.4.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 |  | A.4.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 |  | A.4.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 |  | A.4.7. MHTML and Line Length Limitations |
| HTTP implementations which share code with MHTML [45] implementations |  | HTTP implementations which share code with MHTML [RFC2110] |
| need to be aware of MIME line length limitations. Since HTTP does not |  | implementations need to be aware of MIME line length limitations. |
| have this limitation, HTTP does not fold long lines. MHTML messages |  | Since HTTP does not have this limitation, HTTP does not fold long |
| being transported by HTTP follow all conventions of MHTML, including |  | lines. MHTML messages being transported by HTTP follow all |
| line length limitations and folding, canonicalization, etc., since |  | conventions of MHTML, including line length limitations and folding, |
| HTTP transports all message-bodies as payload (see section 3.7.2) and |  | canonicalization, etc., since HTTP transports all message-bodies as |
| does not interpret the content or any MIME header lines that might be |  | payload (see Section 3.7.2) and does not interpret the content or any |
| contained therein. |  | MIME header lines that might be contained therein. |
| 19.5 Additional Features |  | A.5. 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 |
|  |  | [RFC2076]). |
| 19.5.1 Content-Disposition |  | A.5.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 [RFC1806]. |
| content-disposition = "Content-Disposition" ":" |  | content-disposition = "Content-Disposition" ":" |
| disposition-type *( ";" disposition-parm ) |  | disposition-type *( ";" disposition-parm ) |
| disposition-type = "attachment" | disp-extension-token |  | disposition-type = "attachment" | disp-extension-token |
| disposition-parm = filename-parm | disp-extension-parm |  | disposition-parm = filename-parm | disp-extension-parm |
| filename-parm = "filename" "=" quoted-string |  | filename-parm = "filename" "=" quoted-string |
| disp-extension-token = token |  | disp-extension-token = token |
| disp-extension-parm = token "=" ( token | quoted-string ) |  | disp-extension-parm = token "=" ( token | quoted-string ) |
| An example is |  | An example is |
| 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 |  | A.6. 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 [RFC2068]. |
| 19.6.1 Changes from HTTP/1.0 |  | A.6.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 |  | A.6.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
| Addresses |  | Addresses |
| The requirements that clients and servers support the Host request- |  | The requirements that clients and servers support the Host request- |
| header, report an error if the Host request-header (section 14.23) is |  | header, report an error if the Host request-header (Section 14.23) is |
| missing from an HTTP/1.1 request, and accept absolute URIs (section |  | missing from an HTTP/1.1 request, and accept absolute URIs |
| 5.1.2) are among the most important changes defined by this |  | (Section 5.1.2) are among the most important changes defined by this |
| specification. |  | specification. |
| Older HTTP/1.0 clients assumed a one-to-one relationship of IP |  | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
| addresses and servers; there was no other established mechanism for |  | addresses and servers; there was no other established mechanism for |
| distinguishing the intended server of a request than the IP address |  | distinguishing the intended server of a request than the IP address |
| to which that request was directed. The changes outlined above will |  | to which that request was directed. The changes outlined above will |
| allow the Internet, once older HTTP clients are no longer common, to |  | allow the Internet, once older HTTP clients are no longer common, to |
| support multiple Web sites from a single IP address, greatly |  | support multiple Web sites from a single IP address, greatly |
| simplifying large operational Web servers, where allocation of many |  | simplifying large operational Web servers, where allocation of many |
| IP addresses to a single host has created serious problems. The |  | IP addresses to a single host has created serious problems. The |
| 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 |  | A.6.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 39 |  | skipping to change at page 174, line 27 |
| result in a hung HTTP/1.0 proxy waiting for the close on the |  | result in a hung HTTP/1.0 proxy waiting for the close on the |
| response. The result is that HTTP/1.0 clients must be prevented from |  | response. The result is that HTTP/1.0 clients must be prevented from |
| using Keep-Alive when talking to proxies. |  | using Keep-Alive when talking to proxies. |
| However, talking to proxies is the most important use of persistent |  | However, talking to proxies is the most important use of persistent |
| connections, so that prohibition is clearly unacceptable. Therefore, |  | connections, so that prohibition is clearly unacceptable. Therefore, |
| we need some other mechanism for indicating a persistent connection |  | we need some other mechanism for indicating a persistent connection |
| is desired, which is safe to use even when talking to an old proxy |  | is desired, which is safe to use even when talking to an old proxy |
| that ignores Connection. Persistent connections are the default for |  | that ignores Connection. Persistent connections are the default for |
| HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |  | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
| declaring non-persistence. See section 14.10. |  | declaring non-persistence. See Section 14.10. |
| The original HTTP/1.0 form of persistent connections (the Connection: |  | The original HTTP/1.0 form of persistent connections (the Connection: |
| Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33] |  | Keep-Alive and Keep-Alive header) is documented in RFC 2068. |
|  |  | [RFC2068] |
| 19.6.3 Changes from RFC 2068 |  | A.6.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 [RFC2119]. |
| Clarified which error code should be used for inbound server failures |  | Clarified which error code should be used for inbound server failures |
| (e.g. DNS failures). (Section 10.5.5). |  | (e.g. DNS failures). (Section 10.5.5). |
| CREATE had a race that required an Etag be sent when a resource is |  | CREATE had a race that required an Etag be sent when a resource is |
| first created. (Section 10.2.2). |  | first created. (Section 10.2.2). |
| Content-Base was deleted from the specification: it was not |  | Content-Base was deleted from the specification: it was not |
| implemented widely, and there is no simple, safe way to introduce it |  | implemented widely, and there is no simple, safe way to introduce it |
| without a robust extension mechanism. In addition, it is used in a |  | without a robust extension mechanism. In addition, it is used in a |
| similar, but not identical fashion in MHTML [45]. |  | similar, but not identical fashion in MHTML [RFC2110]. |
| Transfer-coding and message lengths all interact in ways that |  | Transfer-coding and message lengths all interact in ways that |
| required fixing exactly when chunked encoding is used (to allow for |  | required fixing exactly when chunked encoding is used (to allow for |
| transfer encoding that may not be self delimiting); it was important |  | transfer encoding that may not be self delimiting); it was important |
| to straighten out exactly how message lengths are computed. (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 |
| skipping to change at page 174, line 16 |  | skipping to change at page 175, line 51 |
| 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) |
| skipping to change at page 175, line 11 |  | skipping to change at page 176, line 46 |
| (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning |  | (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning |
| also needed to be a general header, as PUT or other methods may have |  | also needed to be a general header, as PUT or other methods may have |
| need for it in requests. |  | need for it in requests. |
| Transfer-coding had significant problems, particularly with |  | Transfer-coding had significant problems, particularly with |
| interactions with chunked encoding. The solution is that transfer- |  | interactions with chunked encoding. The solution is that transfer- |
| codings become as full fledged as content-codings. This involves |  | codings become as full fledged as content-codings. This involves |
| adding an IANA registry for transfer-codings (separate from content |  | adding an IANA registry for transfer-codings (separate from content |
| codings), a new header field (TE) and enabling trailer headers in the |  | codings), a new header field (TE) and enabling trailer headers in the |
| future. Transfer encoding is a major performance benefit, so it was |  | future. Transfer encoding is a major performance benefit, so it was |
| worth fixing [39]. TE also solves another, obscure, downward |  | worth fixing [Nie1997]. TE also solves another, obscure, downward |
| interoperability problem that could have occurred due to interactions |  | interoperability problem that could have occurred due to interactions |
| between authentication trailers, chunked encoding and HTTP/1.0 |  | between authentication trailers, chunked encoding and HTTP/1.0 |
| clients.(Section 3.6, 3.6.1, and 14.39) |  | clients.(Section 3.6, 3.6.1, and 14.39) |
| The PATCH, LINK, UNLINK methods were defined but not commonly |  | The PATCH, LINK, UNLINK methods were defined but not commonly |
| implemented in previous versions of this specification. See RFC 2068 |  | implemented in previous versions of this specification. See RFC 2068 |
| [33]. |  | [RFC2068]. |
| The Alternates, Content-Version, Derived-From, Link, URI, Public and |  | The Alternates, Content-Version, Derived-From, Link, URI, Public and |
| Content-Base header fields were defined in previous versions of this |  | Content-Base header fields were defined in previous versions of this |
| specification, but not commonly implemented. See RFC 2068 [33]. |  | specification, but not commonly implemented. See RFC 2068 [RFC2068]. |
| 20 Index |  | Appendix B. Index |
| Please see the PostScript version of this RFC for the INDEX. |  | Please see the PostScript version of this RFC for the INDEX. |
| 21. Full Copyright Statement |  | Index |
| Copyright (C) The Internet Society (1999). All Rights Reserved. |  | 1 |
|  |  | 100 Continue (status code) 61 |
|  |  | 101 Switching Protocols (status code) 61 |
| This document and translations of it may be copied and furnished to |  | 2 |
| others, and derivative works that comment on or otherwise explain it |  | 200 OK (status code) 61 |
| or assist in its implementation may be prepared, copied, published |  | 201 Created (status code) 62 |
| and distributed, in whole or in part, without restriction of any |  | 202 Accepted (status code) 62 |
| kind, provided that the above copyright notice and this paragraph are |  | 203 Non-Authoritative Information (status code) 62 |
| included on all such copies and derivative works. However, this |  | 204 No Content (status code) 63 |
| document itself may not be modified in any way, such as by removing |  | 205 Reset Content (status code) 63 |
| the copyright notice or references to the Internet Society or other |  | 206 Partial Content (status code) 63 |
| 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 |  | 3 |
| revoked by the Internet Society or its successors or assigns. |  | 300 Multiple Choices (status code) 64 |
|  |  | 301 Moved Permanently (status code) 65 |
|  |  | 302 Found (status code) 65 |
|  |  | 303 See Other (status code) 66 |
|  |  | 304 Not Modified (status code) 66 |
|  |  | 305 Use Proxy (status code) 67 |
|  |  | 306 (Unused) (status code) 67 |
|  |  | 307 Temporary Redirect (status code) 67 |
| This document and the information contained herein is provided on an |  | 4 |
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |  | 400 Bad Request (status code) 68 |
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |  | 401 Unauthorized (status code) 68 |
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |  | 402 Payment Required (status code) 69 |
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |  | 403 Forbidden (status code) 69 |
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |  | 404 Not Found (status code) 69 |
|  |  | 405 Method Not Allowed (status code) 69 |
|  |  | 406 Not Acceptable (status code) 69 |
|  |  | 407 Proxy Authentication Required (status code) 70 |
|  |  | 408 Request Timeout (status code) 70 |
|  |  | 409 Conflict (status code) 70 |
|  |  | 410 Gone (status code) 71 |
|  |  | 411 Length Required (status code) 71 |
|  |  | 412 Precondition Failed (status code) 71 |
|  |  | 413 Request Entity Too Large (status code) 71 |
|  |  | 414 Request-URI Too Long (status code) 72 |
|  |  | 415 Unsupported Media Type (status code) 72 |
|  |  | 416 Requested Range Not Satisfiable (status code) 72 |
|  |  | 417 Expectation Failed (status code) 72 |
| Acknowledgement |  | 5 |
|  |  | 500 Internal Server Error (status code) 73 |
|  |  | 501 Not Implemented (status code) 73 |
|  |  | 502 Bad Gateway (status code) 73 |
|  |  | 503 Service Unavailable (status code) 73 |
|  |  | 504 Gateway Timeout (status code) 73 |
|  |  | 505 HTTP Version Not Supported (status code) 74 |
| Funding for the RFC Editor function is currently provided by the |  | A |
| Internet Society. |  | Accept header 102 |
|  |  | Accept-Charset header 104 |
|  |  | Accept-Encoding header 105 |
|  |  | Accept-Language header 106 |
|  |  | Accept-Ranges header 108 |
|  |  | age 13 |
|  |  | Age header 108 |
|  |  | Allow header 109 |
|  |  | Alternates header 177 |
|  |  | application/http Media Type 165 |
|  |  | Authorization header 109 |
|  |  | C |
|  |  | cache 12 |
|  |  | Cache Directives |
|  |  | max-age 115 |
|  |  | max-age 116 |
|  |  | max-stale 115 |
|  |  | min-fresh 115 |
|  |  | must-revalidate 117 |
|  |  | no-cache 112 |
|  |  | no-store 113 |
|  |  | no-transform 118 |
|  |  | only-if-cached 117 |
|  |  | private 112 |
|  |  | proxy-revalidate 118 |
|  |  | public 112 |
|  |  | s-maxage 114 |
|  |  | Cache-Control header 110 |
|  |  | cacheable 12 |
|  |  | client 11 |
|  |  | compress 26 |
|  |  | CONNECT method 60 |
|  |  | connection 10 |
|  |  | Connection header 119 |
|  |  | content negotiation 11 |
|  |  | Content-Base header 177 |
|  |  | Content-Disposition header 171 |
|  |  | Content-Encoding header 120 |
|  |  | Content-Language header 121 |
|  |  | Content-Length header 122 |
|  |  | Content-Location header 123 |
|  |  | Content-MD5 header 123 |
|  |  | Content-Range header 125 |
|  |  | Content-Type header 127 |
|  |  | Content-Version header 177 |
|  |  | D |
|  |  | Date header 127 |
|  |  | deflate 26 |
|  |  | DELETE method 59 |
|  |  | Derived-From header 177 |
|  |  | downstream 14 |
|  |  | E |
|  |  | entity 10 |
|  |  | ETag header 128 |
|  |  | Expect header 129 |
|  |  | Expires header 130 |
|  |  | explicit expiration time 13 |
|  |  | F |
|  |  | first-hand 12 |
|  |  | fresh 13 |
|  |  | freshness lifetime 13 |
|  |  | From header 131 |
|  |  | G |
|  |  | gateway 12 |
|  |  | GET method 56 |
|  |  | Grammar |
|  |  | Accept 103 |
|  |  | Accept-Charset 105 |
|  |  | Accept-Encoding 105 |
|  |  | accept-extension 103 |
|  |  | Accept-Language 106 |
|  |  | accept-params 103 |
|  |  | Accept-Ranges 108 |
|  |  | acceptable-ranges 108 |
|  |  | Age 108 |
|  |  | age-value 108 |
|  |  | Allow 109 |
|  |  | ALPHA 18 |
|  |  | asctime-date 24 |
|  |  | attribute 27 |
|  |  | Authorization 109 |
|  |  | byte-content-range-spec 125 |
|  |  | byte-range-resp-spec 125 |
|  |  | byte-range-set 141 |
|  |  | byte-range-spec 141 |
|  |  | byte-ranges-specifier 141 |
|  |  | bytes-unit 33 |
|  |  | Cache-Control 111 |
|  |  | cache-directive 111 |
|  |  | cache-extension 111 |
|  |  | cache-request-directive 111 |
|  |  | cache-response-directive 111 |
|  |  | CHAR 18 |
|  |  | charset 25 |
|  |  | chunk 28 |
|  |  | chunk-data 28 |
|  |  | chunk-ext-name 28 |
|  |  | chunk-ext-val 28 |
|  |  | chunk-extension 28 |
|  |  | chunk-size 28 |
|  |  | Chunked-Body 28 |
|  |  | codings 105 |
|  |  | comment 19 |
|  |  | Connection 120 |
|  |  | connection-token 120 |
|  |  | content-coding 26 |
|  |  | content-disposition 172 |
|  |  | Content-Encoding 121 |
|  |  | Content-Language 121 |
|  |  | Content-Length 122 |
|  |  | Content-Location 123 |
|  |  | Content-MD5 123 |
|  |  | Content-Range 125 |
|  |  | content-range-spec 125 |
|  |  | Content-Type 127 |
|  |  | CR 18 |
|  |  | CRLF 18 |
|  |  | ctext 19 |
|  |  | CTL 18 |
|  |  | Date 127 |
|  |  | date1 24 |
|  |  | date2 24 |
|  |  | date3 24 |
|  |  | delta-seconds 24 |
|  |  | DIGIT 18 |
|  |  | disp-extension-parm 172 |
|  |  | disp-extension-token 172 |
|  |  | disposition-parm 172 |
|  |  | disposition-type 172 |
|  |  | entity-body 46 |
|  |  | entity-header 46 |
|  |  | entity-tag 33 |
|  |  | ETag 129 |
|  |  | Expect 129 |
|  |  | expect-params 129 |
|  |  | expectation 129 |
|  |  | expectation-extension 129 |
|  |  | Expires 130 |
|  |  | extension-code 44 |
|  |  | extension-header 46 |
|  |  | extension-method 39 |
|  |  | extension-pragma 139 |
|  |  | field-content 35 |
|  |  | field-name 35 |
|  |  | field-value 35 |
|  |  | filename-parm 172 |
|  |  | first-byte-pos 141 |
|  |  | From 131 |
|  |  | general-header 38 |
|  |  | generic-message 34 |
|  |  | HEX 19 |
|  |  | Host 131 |
|  |  | HT 18 |
|  |  | HTTP-date 24 |
|  |  | HTTP-message 34 |
|  |  | HTTP-Version 20 |
|  |  | http_URL 22 |
|  |  | If-Match 132 |
|  |  | If-Modified-Since 133 |
|  |  | If-None-Match 135 |
|  |  | If-Range 136 |
|  |  | If-Unmodified-Since 137 |
|  |  | instance-length 125 |
|  |  | language-range 106 |
|  |  | language-tag 32 |
|  |  | last-byte-pos 141 |
|  |  | last-chunk 28 |
|  |  | Last-Modified 137 |
|  |  | LF 18 |
|  |  | LOALPHA 18 |
|  |  | Location 138 |
|  |  | LWS 19 |
|  |  | Max-Forwards 138 |
|  |  | md5-digest 123 |
|  |  | media-range 103 |
|  |  | media-type 29 |
|  |  | message-body 35 |
|  |  | message-header 35 |
|  |  | Method 39 |
|  |  | MIME-Version 169 |
|  |  | month 24 |
|  |  | OCTET 18 |
|  |  | opaque-tag 33 |
|  |  | other-range-unit 33 |
|  |  | parameter 27 |
|  |  | Pragma 139 |
|  |  | pragma-directive 139 |
|  |  | primary-tag 32 |
|  |  | product 31 |
|  |  | product-version 31 |
|  |  | protocol-name 149 |
|  |  | protocol-version 149 |
|  |  | Proxy-Authenticate 140 |
|  |  | Proxy-Authorization 140 |
|  |  | pseudonym 149 |
|  |  | qdtext 19 |
|  |  | quoted-pair 20 |
|  |  | quoted-string 19 |
|  |  | qvalue 32 |
|  |  | Range 142 |
|  |  | range-unit 33 |
|  |  | ranges-specifier 141 |
|  |  | Reason-Phrase 44 |
|  |  | received-by 149 |
|  |  | received-protocol 149 |
|  |  | Referer 143 |
|  |  | Request 38 |
|  |  | request-header 42 |
|  |  | Request-Line 38 |
|  |  | Request-URI 39 |
|  |  | Response 42 |
|  |  | response-header 45 |
|  |  | Retry-After 143 |
|  |  | rfc850-date 24 |
|  |  | rfc1123-date 24 |
|  |  | separators 19 |
|  |  | Server 144 |
|  |  | SP 18 |
|  |  | start-line 34 |
|  |  | Status-Code 44 |
|  |  | Status-Line 42 |
|  |  | subtag 32 |
|  |  | subtype 29 |
|  |  | suffix-byte-range-spec 141 |
|  |  | suffix-length 141 |
|  |  | t-codings 144 |
|  |  | TE 144 |
|  |  | TEXT 19 |
|  |  | time 24 |
|  |  | token 19 |
|  |  | Trailer 146 |
|  |  | trailer 28 |
|  |  | transfer-coding 27 |
|  |  | Transfer-Encoding 146 |
|  |  | transfer-extension 27 |
|  |  | type 29 |
|  |  | UPALPHA 18 |
|  |  | Upgrade 147 |
|  |  | User-Agent 148 |
|  |  | value 27 |
|  |  | Vary 148 |
|  |  | Via 149 |
|  |  | warn-agent 151 |
|  |  | warn-code 151 |
|  |  | warn-date 151 |
|  |  | warn-text 151 |
|  |  | Warning 151 |
|  |  | warning-value 151 |
|  |  | weak 33 |
|  |  | weekday 24 |
|  |  | wkday 24 |
|  |  | WWW-Authenticate 153 |
|  |  | gzip 26 |
|  |  | H |
|  |  | HEAD method 57 |
|  |  | Headers |
|  |  | Accept 102 |
|  |  | Accept-Charset 104 |
|  |  | Accept-Encoding 105 |
|  |  | Accept-Language 106 |
|  |  | Accept-Ranges 108 |
|  |  | Age 108 |
|  |  | Allow 109 |
|  |  | Alternate 177 |
|  |  | Authorization 109 |
|  |  | Cache-Control 110 |
|  |  | Connection 119 |
|  |  | Content-Base 177 |
|  |  | Content-Disposition 171 |
|  |  | Content-Encoding 120 |
|  |  | Content-Language 121 |
|  |  | Content-Length 122 |
|  |  | Content-Location 123 |
|  |  | Content-MD5 123 |
|  |  | Content-Range 125 |
|  |  | Content-Type 127 |
|  |  | Content-Version 177 |
|  |  | Date 127 |
|  |  | Derived-From 177 |
|  |  | ETag 128 |
|  |  | Expect 129 |
|  |  | Expires 130 |
|  |  | From 131 |
|  |  | Host 131 |
|  |  | If-Match 132 |
|  |  | If-Modified-Since 133 |
|  |  | If-None-Match 135 |
|  |  | If-Range 136 |
|  |  | If-Unmodified-Since 137 |
|  |  | Last-Modified 137 |
|  |  | Link 177 |
|  |  | Location 138 |
|  |  | Max-Forwards 138 |
|  |  | Pragma 139 |
|  |  | Proxy-Authenticate 140 |
|  |  | Proxy-Authorization 140 |
|  |  | Public 177 |
|  |  | Range 140 |
|  |  | Referer 143 |
|  |  | Retry-After 143 |
|  |  | Server 144 |
|  |  | TE 144 |
|  |  | Trailer 145 |
|  |  | Transfer-Encoding 146 |
|  |  | Upgrade 146 |
|  |  | URI 177 |
|  |  | User-Agent 148 |
|  |  | Vary 148 |
|  |  | Via 149 |
|  |  | Warning 150 |
|  |  | WWW-Authenticate 153 |
|  |  | heuristic expiration time 13 |
|  |  | Host header 131 |
|  |  | I |
|  |  | identity 26 |
|  |  | If-Match header 132 |
|  |  | If-Modified-Since header 133 |
|  |  | If-None-Match header 135 |
|  |  | If-Range header 136 |
|  |  | If-Unmodified-Since header 137 |
|  |  | inbound 14 |
|  |  | L |
|  |  | Last-Modified header 137 |
|  |  | Link header 177 |
|  |  | LINK method 176 |
|  |  | Location header 138 |
|  |  | M |
|  |  | max-age |
|  |  | Cache Directive 115 |
|  |  | Cache Directive 116 |
|  |  | Max-Forwards header 138 |
|  |  | max-stale |
|  |  | Cache Directive 115 |
|  |  | Media Type |
|  |  | application/http 165 |
|  |  | message/http 165 |
|  |  | multipart/byteranges 166 |
|  |  | multipart/x-byteranges 167 |
|  |  | message 10 |
|  |  | message/http Media Type 165 |
|  |  | Methods |
|  |  | CONNECT 60 |
|  |  | DELETE 59 |
|  |  | GET 56 |
|  |  | HEAD 57 |
|  |  | LINK 176 |
|  |  | OPTIONS 55 |
|  |  | PATCH 176 |
|  |  | POST 57 |
|  |  | PUT 58 |
|  |  | TRACE 59 |
|  |  | UNLINK 176 |
|  |  | min-fresh |
|  |  | Cache Directive 115 |
|  |  | multipart/byteranges Media Type 166 |
|  |  | multipart/x-byteranges Media Type 167 |
|  |  | must-revalidate |
|  |  | Cache Directive 117 |
|  |  | N |
|  |  | no-cache |
|  |  | Cache Directive 112 |
|  |  | no-store |
|  |  | Cache Directive 113 |
|  |  | no-transform |
|  |  | Cache Directive 118 |
|  |  | O |
|  |  | only-if-cached |
|  |  | Cache Directive 117 |
|  |  | OPTIONS method 55 |
|  |  | origin server 11 |
|  |  | outbound 14 |
|  |  | P |
|  |  | PATCH method 176 |
|  |  | POST method 57 |
|  |  | Pragma header 139 |
|  |  | private |
|  |  | Cache Directive 112 |
|  |  | proxy 11 |
|  |  | Proxy-Authenticate header 140 |
|  |  | Proxy-Authorization header 140 |
|  |  | proxy-revalidate |
|  |  | Cache Directive 118 |
|  |  | public |
|  |  | Cache Directive 112 |
|  |  | Public header 177 |
|  |  | PUT method 58 |
|  |  | R |
|  |  | Range header 140 |
|  |  | Referer header 143 |
|  |  | representation 10 |
|  |  | request 10 |
|  |  | resource 10 |
|  |  | response 10 |
|  |  | Retry-After header 143 |
|  |  | S |
|  |  | s-maxage |
|  |  | Cache Directive 114 |
|  |  | semantically transparent 13 |
|  |  | server 11 |
|  |  | Server header 144 |
|  |  | stale 13 |
|  |  | Status Codes |
|  |  | 100 Continue 61 |
|  |  | 101 Switching Protocols 61 |
|  |  | 200 OK 61 |
|  |  | 201 Created 62 |
|  |  | 202 Accepted 62 |
|  |  | 203 Non-Authoritative Information 62 |
|  |  | 204 No Content 63 |
|  |  | 205 Reset Content 63 |
|  |  | 206 Partial Content 63 |
|  |  | 300 Multiple Choices 64 |
|  |  | 301 Moved Permanently 65 |
|  |  | 302 Found 65 |
|  |  | 303 See Other 66 |
|  |  | 304 Not Modified 66 |
|  |  | 305 Use Proxy 67 |
|  |  | 306 (Unused) 67 |
|  |  | 307 Temporary Redirect 67 |
|  |  | 400 Bad Request 68 |
|  |  | 401 Unauthorized 68 |
|  |  | 402 Payment Required 69 |
|  |  | 403 Forbidden 69 |
|  |  | 404 Not Found 69 |
|  |  | 405 Method Not Allowed 69 |
|  |  | 406 Not Acceptable 69 |
|  |  | 407 Proxy Authentication Required 70 |
|  |  | 408 Request Timeout 70 |
|  |  | 409 Conflict 70 |
|  |  | 410 Gone 71 |
|  |  | 411 Length Required 71 |
|  |  | 412 Precondition Failed 71 |
|  |  | 413 Request Entity Too Large 71 |
|  |  | 414 Request-URI Too Long 72 |
|  |  | 415 Unsupported Media Type 72 |
|  |  | 416 Requested Range Not Satisfiable 72 |
|  |  | 417 Expectation Failed 72 |
|  |  | 500 Internal Server Error 73 |
|  |  | 501 Not Implemented 73 |
|  |  | 502 Bad Gateway 73 |
|  |  | 503 Service Unavailable 73 |
|  |  | 504 Gateway Timeout 73 |
|  |  | 505 HTTP Version Not Supported 74 |
|  |  | T |
|  |  | TE header 144 |
|  |  | TRACE method 59 |
|  |  | Trailer header 145 |
|  |  | Transfer-Encoding header 146 |
|  |  | tunnel 12 |
|  |  | U |
|  |  | UNLINK method 176 |
|  |  | Upgrade header 146 |
|  |  | upstream 14 |
|  |  | URI header 177 |
|  |  | user agent 11 |
|  |  | User-Agent header 148 |
|  |  | V |
|  |  | validator 13 |
|  |  | variant 11 |
|  |  | Vary header 148 |
|  |  | Via header 149 |
|  |  | W |
|  |  | Warning header 150 |
|  |  | WWW-Authenticate header 153 |
|  |  | Authors' Addresses |
|  |  | Roy T. Fielding |
|  |  | Department of Information and Computer Science |
|  |  | University of California, Irvine |
|  |  | Irvine, CA 92697-3425 |
|  |  | Fax: +1(949)824-1715 |
|  |  | Email: fielding@ics.uci.edu |
|  |  | James Gettys |
|  |  | World Wide Web Consortium |
|  |  | MIT Laboratory for Computer Science, NE43-356 |
|  |  | 545 Technology Square |
|  |  | Cambridge, MA 02139 |
|  |  | Fax: +1(617)258-8682 |
|  |  | Email: jg@w3.org |
|  |  | Jeffrey C. Mogul |
|  |  | Compaq Computer Corporation |
|  |  | Western Research Laboratory |
|  |  | 250 University Avenue |
|  |  | Palo Alto, CA 94305 |
|  |  | Email: mogul@wrl.dec.com |
|  |  | Henrik Frystyk Nielsen |
|  |  | World Wide Web Consortium |
|  |  | MIT Laboratory for Computer Science, NE43-356 |
|  |  | 545 Technology Square |
|  |  | Cambridge, MA 02139 |
|  |  | Fax: +1(617)258-8682 |
|  |  | Email: frystyk@w3.org |
|  |  | Larry Masinter |
|  |  | Xerox Corporation |
|  |  | MIT Laboratory for Computer Science, NE43-356 |
|  |  | 3333 Coyote Hill Road |
|  |  | Palo Alto, CA 94034 |
|  |  | Email: masinter@parc.xerox.com |
|  |  | Paul J. Leach |
|  |  | Microsoft Corporation |
|  |  | 1 Microsoft Way |
|  |  | Redmond, WA 98052 |
|  |  | Email: paulle@microsoft.com |
|  |  | Tim Berners-Lee |
|  |  | World Wide Web Consortium |
|  |  | MIT Laboratory for Computer Science, NE43-356 |
|  |  | 545 Technology Square |
|  |  | Cambridge, MA 02139 |
|  |  | Fax: +1(617)258-8682 |
|  |  | Email: timbl@w3.org |
|  |  | Full Copyright Statement |
|  |  | Copyright (C) The IETF Trust (1999). |
|  |  | 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, THE IETF TRUST 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. 934 change blocks.
| 2066 lines changed or deleted |  | 2180 lines changed or added |
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/