| draft-ietf-httpbis-p2-semantics-09.txt |  | draft-ietf-httpbis-p2-semantics-10.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Day Software |  | Internet-Draft Day Software |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) One Laptop per Child |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: September 9, 2010 HP |  | Expires: January 13, 2011 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe Systems |  | Adobe Systems |
| P. Leach |  | P. Leach |
| Microsoft |  | Microsoft |
| T. Berners-Lee |  | T. Berners-Lee |
| W3C/MIT |  | W3C/MIT |
| Y. Lafon, Ed. |  | Y. Lafon, Ed. |
| W3C |  | W3C |
| J. Reschke, Ed. |  | J. Reschke, Ed. |
| greenbytes |  | greenbytes |
| March 8, 2010 |  | July 12, 2010 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-09 |  | draft-ietf-httpbis-p2-semantics-10 |
| 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. 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. This document is Part 2 of the |  | information initiative since 1990. This document is Part 2 of the |
| seven-part specification that defines the protocol referred to as |  | seven-part specification that defines the protocol referred to as |
| "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |  | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines |
| the semantics of HTTP messages as expressed by request methods, |  | the semantics of HTTP messages as expressed by request methods, |
| request-header fields, response status codes, and response-header |  | request-header fields, response status codes, and response-header |
| fields. |  | fields. |
| Editorial Note (To be removed by RFC Editor) |  | Editorial Note (To be removed by RFC Editor) |
| Discussion of this draft should take place on the HTTPBIS working |  | Discussion of this draft should take place on the HTTPBIS working |
| group mailing list (ietf-http-wg@w3.org). The current issues list is |  | group mailing list (ietf-http-wg@w3.org). The current issues list is |
| at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related |  | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
| documents (including fancy diffs) can be found at |  | documents (including fancy diffs) can be found at |
| <http://tools.ietf.org/wg/httpbis/>. |  | <http://tools.ietf.org/wg/httpbis/>. |
| The changes in this draft are summarized in Appendix C.10. |  | The changes in this draft are summarized in Appendix C.11. |
| Status of this Memo |  | Status of This Memo |
| This Internet-Draft is submitted to IETF in full conformance with the |  | This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |  | provisions of BCP 78 and BCP 79. |
| Internet-Drafts are working documents of the Internet Engineering |  | Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF), its areas, and its working groups. Note that |  | Task Force (IETF). Note that other groups may also distribute |
| other groups may also distribute working documents as Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts. |  | Drafts is at http://datatracker.ietf.org/drafts/current/. |
| Internet-Drafts are draft documents valid for a maximum of six months |  | Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |  | and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |  | time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |  | material or to cite them other than as "work in progress." |
| The list of current Internet-Drafts can be accessed at |  | This Internet-Draft will expire on January 13, 2011. |
| 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 September 9, 2010. |  |  |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2010 IETF Trust and the persons identified as the |  | Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |  | document authors. All rights reserved. |
| This document is subject to BCP 78 and the IETF Trust's Legal |  | This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |  | Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |  | (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |  | publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |  | carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |  | to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |  | include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |  | the Trust Legal Provisions and are provided without warranty as |
| described in the BSD License. |  | described in the Simplified BSD License. |
| This document may contain material from IETF Documents or IETF |  | This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |  | Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |  | 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |  | material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |  | modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |  | Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |  | the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |  | outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |  | not be created outside the IETF Standards Process, except to format |
| skipping to change at page 3, line 26 |  | skipping to change at page 3, line 19 |
| 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |  | 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 |
| 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |  | 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 |
| 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 |  | 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 |
| 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |  | 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 |
| 6.1. Identifying the Resource Associated with a |  | 6.1. Identifying the Resource Associated with a |
| Representation . . . . . . . . . . . . . . . . . . . . . . 13 |  | Representation . . . . . . . . . . . . . . . . . . . . . . 13 |
| 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |  | 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 |  | 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 |
| 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 |  | 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 |  | 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 |
| 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 |  | 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 |
| 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |  | 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |  | 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 |  | 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
| 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |  | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 |
| 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 |  | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 |
| 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 |  | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 |
| 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 |
| 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 |  | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 |
| 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 |  | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 |
| 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 |  | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 |
| skipping to change at page 4, line 40 |  | skipping to change at page 4, line 34 |
| 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 |  | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 |
| 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 |  | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 |
| 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 |  | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 |
| 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |  | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 |
| 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |  | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 |
| 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 |  | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 |
| 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 |  | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 |
| 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 |
| 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 |  | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 |  | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 |
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 |  | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 |
| 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 |  | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38 |
| 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 |  | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 |
| 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 |  | 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 |  | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 |
| 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 |  | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 |
| 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 |  | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 |
| 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 |  | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 |
| 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |  | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 |  | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 |
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 |  | 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 |
| skipping to change at page 5, line 22 |  | skipping to change at page 5, line 16 |
| C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48 |  | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48 |
| C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 |  | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 |
| C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 |  | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 |
| C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 |  | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 |
| C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 |  | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 |
| C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 |  | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 |
|  |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 |  |  |
| 1. Introduction |  | 1. Introduction |
| This document defines HTTP/1.1 request and response semantics. Each |  | This document defines HTTP/1.1 request and response semantics. Each |
| HTTP message, as defined in [Part1], is in the form of either a |  | HTTP message, as defined in [Part1], is in the form of either a |
| request or a response. An HTTP server listens on a connection for |  | request or a response. An HTTP server listens on a connection for |
| HTTP requests and responds to each request, in the order received on |  | HTTP requests and responds to each request, in the order received on |
| that connection, with one or more HTTP response messages. This |  | that connection, with one or more HTTP response messages. This |
| document defines the commonly agreed upon semantics of the HTTP |  | document defines the commonly agreed upon semantics of the HTTP |
| uniform interface, the intentions defined by each request method, and |  | uniform interface, the intentions defined by each request method, and |
| skipping to change at page 6, line 34 |  | skipping to change at page 6, line 34 |
| current mess reflects how widely dispersed these topics and |  | current mess reflects how widely dispersed these topics and |
| associated requirements had become in [RFC2616]. |  | associated requirements had become in [RFC2616]. |
| 1.1. Requirements |  | 1.1. 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 [RFC2119]. |  | document are to be interpreted as described in [RFC2119]. |
| An implementation is not compliant if it fails to satisfy one or more |  | An implementation is not compliant if it fails to satisfy one or more |
| of the MUST or REQUIRED level requirements for the protocols it |  | of the "MUST" or "REQUIRED" level requirements for the protocols it |
| implements. An implementation that satisfies all the MUST or |  | implements. An implementation that satisfies all the "MUST" or |
| REQUIRED level and all the SHOULD level requirements for its |  | "REQUIRED" level and all the "SHOULD" level requirements for its |
| protocols is said to be "unconditionally compliant"; one that |  | protocols is said to be "unconditionally compliant"; one that |
| satisfies all the MUST level requirements but not all the SHOULD |  | satisfies all the "MUST" level requirements but not all the "SHOULD" |
| level requirements for its protocols is said to be "conditionally |  | level requirements for its protocols is said to be "conditionally |
| compliant." |  | compliant". |
| 1.2. Syntax Notation |  | 1.2. Syntax Notation |
| This specification uses the ABNF syntax defined in Section 1.2 of |  | This specification uses the ABNF syntax defined in Section 1.2 of |
| [Part1] (which extends the syntax defined in [RFC5234] with a list |  | [Part1] (which extends the syntax defined in [RFC5234] with a list |
| rule). Appendix B shows the collected ABNF, with the list rule |  | rule). Appendix B shows the collected ABNF, with the list rule |
| expanded. |  | expanded. |
| The following core rules are included by reference, as defined in |  | The following core rules are included by reference, as defined in |
| [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |  | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
| skipping to change at page 7, line 27 |  | skipping to change at page 7, line 27 |
| 1.2.2. ABNF Rules defined in other Parts of the Specification |  | 1.2.2. ABNF Rules defined in other Parts of the Specification |
| The ABNF rules below are defined in other parts: |  | The ABNF rules below are defined in other parts: |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| comment = <comment, defined in [Part1], Section 3.2> |  | comment = <comment, defined in [Part1], Section 3.2> |
| Host = <Host, defined in [Part1], Section 2.6> |  | Host = <Host, defined in [Part1], Section 2.6> |
| HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |  | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.6> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.6> |
| product = <product, defined in [Part1], Section 6.3> |  | product = <product, defined in [Part1], Section 6.3> |
| TE = <TE, defined in [Part1], Section 9.8> |  | TE = <TE, defined in [Part1], Section 9.5> |
| URI = <URI, defined in [Part1], Section 2.6> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.6> |
| Accept = <Accept, defined in [Part3], Section 5.1> |  | Accept = <Accept, defined in [Part3], Section 5.1> |
| Accept-Charset = |  | Accept-Charset = |
| <Accept-Charset, defined in [Part3], Section 5.2> |  | <Accept-Charset, defined in [Part3], Section 5.2> |
| Accept-Encoding = |  | Accept-Encoding = |
| <Accept-Encoding, defined in [Part3], Section 5.3> |  | <Accept-Encoding, defined in [Part3], Section 5.3> |
| Accept-Language = |  | Accept-Language = |
| <Accept-Language, defined in [Part3], Section 5.4> |  | <Accept-Language, defined in [Part3], Section 5.4> |
| ETag = <ETag, defined in [Part4], Section 6.1> |  | ETag = <ETag, defined in [Part4], Section 6.1> |
| skipping to change at page 8, line 18 |  | skipping to change at page 8, line 18 |
| Proxy-Authenticate = |  | Proxy-Authenticate = |
| <Proxy-Authenticate, defined in [Part7], Section 3.2> |  | <Proxy-Authenticate, defined in [Part7], Section 3.2> |
| Proxy-Authorization = |  | Proxy-Authorization = |
| <Proxy-Authorization, defined in [Part7], Section 3.3> |  | <Proxy-Authorization, defined in [Part7], Section 3.3> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 3.4> |  | <WWW-Authenticate, defined in [Part7], Section 3.4> |
| 2. Method |  | 2. Method |
| The Method token indicates the method to be performed on the resource |  | The Method token indicates the method to be performed on the resource |
| identified by the request-target. The method is case-sensitive. |  | identified by the Effective Request URI (Section 4.3 of [Part1]). |
|  |  | The method is case-sensitive. |
| Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |  | Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 |
| / %x47.45.54 ; "GET", Section 7.3 |  | / %x47.45.54 ; "GET", Section 7.3 |
| / %x48.45.41.44 ; "HEAD", Section 7.4 |  | / %x48.45.41.44 ; "HEAD", Section 7.4 |
| / %x50.4F.53.54 ; "POST", Section 7.5 |  | / %x50.4F.53.54 ; "POST", Section 7.5 |
| / %x50.55.54 ; "PUT", Section 7.6 |  | / %x50.55.54 ; "PUT", Section 7.6 |
| / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 |  | / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 |
| / %x54.52.41.43.45 ; "TRACE", Section 7.8 |  | / %x54.52.41.43.45 ; "TRACE", Section 7.8 |
| / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 |  | / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 |
| / extension-method |  | / extension-method |
| skipping to change at page 9, line 42 |  | skipping to change at page 9, line 42 |
| / Host ; [Part1], Section 9.4 |  | / Host ; [Part1], Section 9.4 |
| / If-Match ; [Part4], Section 6.2 |  | / If-Match ; [Part4], Section 6.2 |
| / If-Modified-Since ; [Part4], Section 6.3 |  | / If-Modified-Since ; [Part4], Section 6.3 |
| / If-None-Match ; [Part4], Section 6.4 |  | / If-None-Match ; [Part4], Section 6.4 |
| / If-Range ; [Part5], Section 5.3 |  | / If-Range ; [Part5], Section 5.3 |
| / If-Unmodified-Since ; [Part4], Section 6.5 |  | / If-Unmodified-Since ; [Part4], Section 6.5 |
| / Max-Forwards ; Section 9.5 |  | / Max-Forwards ; Section 9.5 |
| / Proxy-Authorization ; [Part7], Section 3.3 |  | / Proxy-Authorization ; [Part7], Section 3.3 |
| / Range ; [Part5], Section 5.4 |  | / Range ; [Part5], Section 5.4 |
| / Referer ; Section 9.6 |  | / Referer ; Section 9.6 |
| / TE ; [Part1], Section 9.8 |  | / TE ; [Part1], Section 9.5 |
| / User-Agent ; Section 9.9 |  | / User-Agent ; Section 9.9 |
| 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. |
| 4. Status Code and Reason Phrase |  | 4. 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. The status codes |  | attempt to understand and satisfy the request. The status codes |
| listed below are defined in Section 8. The Reason-Phrase is intended |  | listed below are defined in Section 8, Section 3 of [Part4], Section |
| to give a short textual description of the Status-Code. The Status- |  | 3 of [Part5], and Section 2 of [Part7]. |
| Code is intended for use by automata and the Reason-Phrase is |  |  |
| intended for the human user. The client is not required to examine |  | The Reason-Phrase is intended to give a short textual description of |
| or display the Reason-Phrase. |  | the Status-Code. The Status-Code is intended 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-Phrase. |
| 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 values, |  | HTTP/1.1, and an example set of corresponding Reason-Phrase values, |
| are presented below. The reason phrases listed here are only |  | are 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 8.1.1: Continue |  | "100" ; Section 8.1.1: Continue |
| / "101" ; Section 8.1.2: Switching Protocols |  | / "101" ; Section 8.1.2: Switching Protocols |
| / "200" ; Section 8.2.1: OK |  | / "200" ; Section 8.2.1: OK |
| / "201" ; Section 8.2.2: Created |  | / "201" ; Section 8.2.2: Created |
| / "202" ; Section 8.2.3: Accepted |  | / "202" ; Section 8.2.3: Accepted |
| / "203" ; Section 8.2.4: Non-Authoritative Information |  | / "203" ; Section 8.2.4: Non-Authoritative Information |
| / "204" ; Section 8.2.5: No Content |  | / "204" ; Section 8.2.5: No Content |
| / "205" ; Section 8.2.6: Reset Content |  | / "205" ; Section 8.2.6: Reset Content |
| / "206" ; [Part5], Section 3.1: Partial Content |  | / "206" ; [Part5], Section 3.1: Partial Content |
| / "300" ; Section 8.3.1: Multiple Choices |  | / "300" ; Section 8.3.1: Multiple Choices |
| / "301" ; Section 8.3.2: Moved Permanently |  | / "301" ; Section 8.3.2: Moved Permanently |
| / "302" ; Section 8.3.3: Found |  | / "302" ; Section 8.3.3: Found |
| / "303" ; Section 8.3.4: See Other |  | / "303" ; Section 8.3.4: See Other |
| / "304" ; [Part4], Section 3.1: Not Modified |  | / "304" ; [Part4], Section 3.1: Not Modified |
| / "305" ; Section 8.3.6: Use Proxy |  | / "305" ; Section 8.3.6: Use Proxy |
| / "307" ; Section 8.3.8: Temporary Redirect |  | / "307" ; Section 8.3.8: Temporary Redirect |
| / "400" ; Section 8.4.1: Bad Request |  | / "400" ; Section 8.4.1: Bad Request |
| / "401" ; [Part7], Section 2.1: Unauthorized |  | / "401" ; [Part7], Section 2.1: Unauthorized |
| / "402" ; Section 8.4.3: Payment Required |  | / "402" ; Section 8.4.3: Payment Required |
| / "403" ; Section 8.4.4: Forbidden |  | / "403" ; Section 8.4.4: Forbidden |
| / "404" ; Section 8.4.5: Not Found |  | / "404" ; Section 8.4.5: Not Found |
| / "405" ; Section 8.4.6: Method Not Allowed |  | / "405" ; Section 8.4.6: Method Not Allowed |
| / "406" ; Section 8.4.7: Not Acceptable |  | / "406" ; Section 8.4.7: Not Acceptable |
| / "407" ; [Part7], Section 2.2: Proxy Authentication Required |  | / "407" ; [Part7], Section 2.2: Proxy Authentication Required |
| / "408" ; Section 8.4.9: Request Time-out |  | / "408" ; Section 8.4.9: Request Time-out |
| / "409" ; Section 8.4.10: Conflict |  | / "409" ; Section 8.4.10: Conflict |
| / "410" ; Section 8.4.11: Gone |  | / "410" ; Section 8.4.11: Gone |
| / "411" ; Section 8.4.12: Length Required |  | / "411" ; Section 8.4.12: Length Required |
| / "412" ; [Part4], Section 3.2: Precondition Failed |  | / "412" ; [Part4], Section 3.2: Precondition Failed |
| / "413" ; Section 8.4.14: Request Entity Too Large |  | / "413" ; Section 8.4.14: Request Entity Too Large |
| / "414" ; Section 8.4.15: URI Too Long |  | / "414" ; Section 8.4.15: URI Too Long |
| / "415" ; Section 8.4.16: Unsupported Media Type |  | / "415" ; Section 8.4.16: Unsupported Media Type |
| / "416" ; status-416;: Requested range not satisfiable |  | / "416" ; [Part5], Section 3.2: Requested range not satisfiable |
| / "417" ; Section 8.4.18: Expectation Failed |  | / "417" ; Section 8.4.18: Expectation Failed |
| / "500" ; Section 8.5.1: Internal Server Error |  | / "500" ; Section 8.5.1: Internal Server Error |
| / "501" ; Section 8.5.2: Not Implemented |  | / "501" ; Section 8.5.2: Not Implemented |
| / "502" ; Section 8.5.3: Bad Gateway |  | / "502" ; Section 8.5.3: Bad Gateway |
| / "503" ; Section 8.5.4: Service Unavailable |  | / "503" ; Section 8.5.4: Service Unavailable |
| / "504" ; Section 8.5.5: Gateway Time-out |  | / "504" ; Section 8.5.5: Gateway Time-out |
| / "505" ; Section 8.5.6: HTTP Version not supported |  | / "505" ; Section 8.5.6: HTTP Version not supported |
| / extension-code |  | / extension-code |
| extension-code = 3DIGIT |  | extension-code = 3DIGIT |
| Reason-Phrase = *( WSP / VCHAR / obs-text ) |  | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
| HTTP status codes are extensible. HTTP applications are not required |  | HTTP status codes are extensible. HTTP applications are not required |
| to understand the meaning of all registered status codes, though such |  | to understand the meaning of all registered status codes, though such |
| understanding is obviously desirable. However, applications MUST |  | understanding is obviously desirable. However, applications MUST |
| understand the class of any status code, as indicated by the first |  | understand the class of any status code, as indicated by the first |
| digit, and treat any unrecognized response as being equivalent to the |  | digit, and treat any unrecognized response as being equivalent to the |
| x00 status code of that class, with the exception that an |  | x00 status code of that class, with the exception that an |
| skipping to change at page 12, line 32 |  | skipping to change at page 12, line 32 |
| ([RFC5226], Section 4.1). |  | ([RFC5226], Section 4.1). |
| The registry itself is maintained at |  | The registry itself is maintained at |
| <http://www.iana.org/assignments/http-status-codes>. |  | <http://www.iana.org/assignments/http-status-codes>. |
| 5. Response Header Fields |  | 5. Response Header Fields |
| The response-header fields allow the server to pass additional |  | The response-header fields allow the server to pass additional |
| information about the response which cannot be placed in the Status- |  | information about the response which cannot be placed in the Status- |
| Line. These header fields give information about the server and |  | Line. These header fields give information about the server and |
| about further access to the resource identified by the request- |  | about further access to the resource identified by the Effective |
| target. |  | Request URI (Section 4.3 of [Part1]). |
| response-header = Accept-Ranges ; [Part5], Section 5.1 |  | response-header = Accept-Ranges ; [Part5], Section 5.1 |
| / Age ; [Part6], Section 3.1 |  | / Age ; [Part6], Section 3.1 |
| / Allow ; Section 9.1 |  | / Allow ; Section 9.1 |
| / ETag ; [Part4], Section 6.1 |  | / ETag ; [Part4], Section 6.1 |
| / Location ; Section 9.4 |  | / Location ; Section 9.4 |
| / Proxy-Authenticate ; [Part7], Section 3.2 |  | / Proxy-Authenticate ; [Part7], Section 3.2 |
| / Retry-After ; Section 9.7 |  | / Retry-After ; Section 9.7 |
| / Server ; Section 9.8 |  | / Server ; Section 9.8 |
| / Vary ; [Part6], Section 3.5 |  | / Vary ; [Part6], Section 3.5 |
| skipping to change at page 13, line 29 |  | skipping to change at page 13, line 28 |
| 6.1. Identifying the Resource Associated with a Representation |  | 6.1. Identifying the Resource Associated with a Representation |
| It is sometimes necessary to determine the identity of the resource |  | It is sometimes necessary to determine the identity of the resource |
| associated with a representation. |  | associated with a representation. |
| An HTTP request representation, when present, is always associated |  | An HTTP request representation, when present, is always associated |
| with an anonymous (i.e., unidentified) resource. |  | with an anonymous (i.e., unidentified) resource. |
| In the common case, an HTTP response is a representation of the |  | In the common case, an HTTP response is a representation of the |
| resource located at the request-URI. However, this is not always the |  | resource located at the Effective Request URI (see Section 4.3 of |
| case. To determine the URI of the resource a response is associated |  | [Part1]). However, this is not always the case. To determine the |
| with, the following rules are used (with the first applicable one |  | URI of the resource a response is associated with, the following |
| being selected): |  | rules are used (with the first applicable one being selected): |
| 1. If the response status code is 200 or 203 and the request method |  | 1. If the response status code is 200 or 203 and the request method |
| was GET, the response is a representation of the resource at the |  | was GET, the response is a representation of the resource at the |
| request-URI. |  | Effective Request URI. |
| 2. If the response status is 204, 206, or 304 and the request method |  | 2. If the response status is 204, 206, or 304 and the request method |
| was GET or HEAD, the response is a partial representation of the |  | was GET or HEAD, the response is a partial representation of the |
| resource at the request-URI (see Section 2.7 of [Part6]). |  | resource at the Effective Request URI (see Section 2.8 of |
|  |  | [Part6]). |
| 3. If the response has a Content-Location header, and that URI is |  | 3. If the response has a Content-Location header, and that URI is |
| the same as the request-URI [[TODO-missref-requri: (see [ref])]], |  | the same as the Effective Request URI, the response is a |
| the response is a representation of the resource at the request- |  | representation of the resource at the Effective Request URI. |
| URI. |  |  |
| 4. If the response has a Content-Location header, and that URI is |  | 4. If the response has a Content-Location header, and that URI is |
| not the same as the request-URI, the response asserts that it is |  | not the same as the Effective Request URI, the response asserts |
| a representation of the resource at the Content-Location URI (but |  | that it is a representation of the resource at the Content- |
| it may not be). |  | Location URI (but it may not be). |
| 5. Otherwise, the response is a representation of an anonymous |  | 5. Otherwise, the response is a representation of an anonymous |
| (i.e., unidentified) resource. |  | (i.e., unidentified) resource. |
| [[TODO-req-uri: Note that "request-URI" is used here; however, we |  | [[TODO-req-uri: The comparison function is going to have to be |
| need to come up with a term to denote "the URI that can be inferred |  | defined somewhere, because we already need to compare URIs for things |
| from examining the request-target and the Host header." (see |  | like cache invalidation.]] |
| <http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the |  |  |
| comparison function is going to have to be defined somewhere, because |  |  |
| we already need to compare URIs for things like cache invalidation.]] |  |  |
| 7. Method Definitions |  | 7. 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. |
| 7.1. Safe and Idempotent Methods |  | 7.1. Safe and Idempotent Methods |
| 7.1.1. Safe Methods |  | 7.1.1. Safe Methods |
| skipping to change at page 15, line 10 |  | skipping to change at page 14, line 52 |
| identical requests is the same as for a single request. The methods |  | identical requests is the same as for a single request. The methods |
| PUT, DELETE, and all safe methods are idempotent. It is important to |  | PUT, DELETE, and all safe methods are idempotent. It is important to |
| note that idempotence refers only to changes requested by the client: |  | note that idempotence refers only to changes requested by the client: |
| a server is free to change its state due to multiple requests for the |  | a server is free to change its state due to multiple requests for the |
| purpose of tracking those requests, versioning of results, etc. |  | purpose of tracking those requests, versioning of results, etc. |
| 7.2. OPTIONS |  | 7.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-target. This method allows the client to |  | identified by the Effective Request URI. This method allows the |
| determine the options and/or requirements associated with a resource, |  | client to determine the options and/or requirements associated with a |
| or the capabilities of a server, without implying a resource action |  | resource, or the capabilities of a server, without implying a |
| or initiating a resource retrieval. |  | resource action or initiating a resource retrieval. |
| Responses to this method are not cacheable. |  | Responses to this method are not cacheable. |
| If the OPTIONS request includes an entity-body (as indicated by the |  | If the OPTIONS request includes an entity-body (as indicated by the |
| presence of Content-Length or Transfer-Encoding), then the media type |  | presence of Content-Length or Transfer-Encoding), then the media type |
| MUST be indicated by a Content-Type field. Although this |  | MUST be indicated by a Content-Type field. Although this |
| 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. |  | queries on the server. |
| skipping to change at page 16, line 15 |  | skipping to change at page 16, line 9 |
| communication options. If the Max-Forwards field-value is an integer |  | communication options. If the Max-Forwards field-value is an integer |
| greater than zero, the proxy MUST decrement the field-value when it |  | greater than zero, the proxy MUST decrement the field-value when it |
| forwards the request. If no Max-Forwards field is present in the |  | forwards the request. If no Max-Forwards field is present in the |
| request, then the forwarded request MUST NOT include a Max-Forwards |  | request, then the forwarded request MUST NOT include a Max-Forwards |
| field. |  | field. |
| 7.3. GET |  | 7.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) currently corresponds to the resource identified by the |  | entity) currently corresponds to the resource identified by the |
| request-target. |  | Effective Request URI. |
| If the request-target identifies a data-producing process, it is the |  | If the Effective Request URI identifies a data-producing process, it |
| produced data which shall be returned as the entity in the response |  | is the produced data which shall be returned as the entity in the |
| and not the source text of the process, unless that text happens to |  | response and not the source text of the process, unless that text |
| be the output of the process. |  | 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. |
| skipping to change at page 17, line 18 |  | skipping to change at page 17, line 11 |
| 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. |
| 7.5. POST |  | 7.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 data to be processed by the |  | entity enclosed in the request as data to be processed by the |
| resource identified by the request-target in the Request-Line. POST |  | resource identified by the Effective Request URI. POST is designed |
| is designed to allow a uniform method to cover the following |  | to allow a uniform method to cover the following functions: |
| functions: |  |  |
| o Annotation of existing resources; |  | o Annotation of existing resources; |
| o Posting a message to a bulletin board, newsgroup, mailing list, or |  | o Posting a message to a bulletin board, newsgroup, mailing list, or |
| similar group of articles; |  | similar group of articles; |
| o Providing a block of data, such as the result of submitting a |  | o Providing a block of data, such as the result of submitting a |
| form, to a data-handling process; |  | form, to a data-handling process; |
| o Extending a database through an append operation. |  | o Extending a database through an append operation. |
| The actual function performed by the POST method is determined by the |  | The actual function performed by the POST method is determined by the |
| server and is usually dependent on the request-target. |  | server and is usually dependent on the Effective Request URI. |
| 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 9.4). |  | header (see Section 9.4). |
| Responses to this method are not cacheable, unless the response |  | Responses to this method are not cacheable, unless the response |
| includes appropriate Cache-Control or Expires header fields. |  | includes appropriate Cache-Control or Expires header fields. |
| However, the 303 (See Other) response can be used to direct the user |  | However, the 303 (See Other) response can be used to direct the user |
| agent to retrieve a cacheable resource. |  | agent to retrieve a cacheable resource. |
| 7.6. PUT |  | 7.6. PUT |
| The PUT method requests that the enclosed entity be stored at the |  | The PUT method requests that the enclosed entity be stored at the |
| supplied request-target. If the request-target refers to an already |  | Effective Request URI. If the Effective Request URI refers to an |
| existing resource, the enclosed entity SHOULD be considered as a |  | already existing resource, the enclosed entity SHOULD be considered |
| modified version of the one residing on the origin server. If the |  | as a modified version of the one residing on the origin server. |
| request-target does not point to an existing resource, and that URI |  | Otherwise, if the Effective Request URI does not point to an existing |
| is capable of being defined as a new resource by the requesting user |  | resource, and that URI is capable of being defined as a new resource |
| agent, the origin server can create the resource with that URI. If a |  | by the requesting user agent, the origin server can create the |
| new resource is created at the request-target, the origin server MUST |  | resource with that URI. |
| inform the user agent via the 201 (Created) response. If an existing |  |  |
| resource is modified, either the 200 (OK) or 204 (No Content) |  |  |
| response codes SHOULD be sent to indicate successful completion of |  |  |
| the request. If the resource could not be created or modified with |  |  |
| the request-target, an appropriate error response SHOULD be given |  |  |
| that reflects the nature of the problem. The recipient of the entity |  |  |
| MUST NOT ignore any Content-* headers (headers starting with the |  |  |
| prefix "Content-") that it does not understand or implement and MUST |  |  |
| return a 501 (Not Implemented) response in such cases. |  |  |
| If the request passes through a cache and the request-target |  | If a new resource is created at the Effective Request URI, the origin |
|  |  | server MUST inform the user agent via the 201 (Created) response. If |
|  |  | an existing resource is modified, either the 200 (OK) or 204 (No |
|  |  | Content) response codes SHOULD be sent to indicate successful |
|  |  | completion of the request. |
|  |  | If the resource could not be created or modified with the Effective |
|  |  | Request URI, an appropriate error response SHOULD be given that |
|  |  | reflects the nature of the problem. The recipient of the entity MUST |
|  |  | NOT ignore any Content-* headers (headers starting with the prefix |
|  |  | "Content-") that it does not understand or implement and MUST return |
|  |  | a 501 (Not Implemented) response in such cases. |
|  |  | If the request passes through a cache and the Effective Request URI |
| identifies one or more currently cached entities, those entries |  | identifies one or more currently cached entities, those entries |
| SHOULD be treated as stale. Responses to this method are not |  | SHOULD be treated as stale. Responses to this method are not |
| cacheable. |  | 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-target. The URI in |  | reflected in the different meaning of the Effective Request URI. The |
| a POST request identifies the resource that will handle the enclosed |  | URI in a POST request identifies the resource that will handle the |
| entity. That resource might be a data-accepting process, a gateway |  | enclosed entity. That resource might be a data-accepting process, a |
| to some other protocol, or a separate entity that accepts |  | gateway to some other protocol, or a separate entity that accepts |
| annotations. In contrast, the URI in a PUT request identifies the |  | annotations. In contrast, the URI in a PUT request identifies the |
| entity enclosed with the request -- the user agent knows what URI is |  | entity enclosed with the request -- the user agent knows what URI is |
| intended and the server MUST NOT attempt to apply the request to some |  | intended and the server MUST NOT attempt to apply the request to some |
| other resource. If the server desires that the request be applied to |  | other resource. If the server desires that the request be applied to |
| a different URI, it MUST send a 301 (Moved Permanently) response; the |  | a different URI, it MUST send a 301 (Moved Permanently) response; the |
| user agent MAY then make its own decision regarding whether or not to |  | user agent MAY then make its own decision regarding whether or not to |
| redirect the 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 |
| skipping to change at page 19, line 10 |  | skipping to change at page 19, line 8 |
| 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. |
| 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. |
| 7.7. DELETE |  | 7.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-target. This method MAY be overridden by |  | identified by the Effective Request URI. This method MAY be |
| human intervention (or other means) on the origin server. The client |  | overridden by human intervention (or other means) on the origin |
| cannot be guaranteed that the operation has been carried out, even if |  | server. The client cannot be guaranteed that the operation has been |
| the status code returned from the origin server indicates that the |  | carried out, even if the status code returned from the origin server |
| action has been completed successfully. However, the server SHOULD |  | indicates that the action has been completed successfully. However, |
| NOT indicate success unless, at the time the response is given, it |  | the server SHOULD NOT indicate success unless, at the time the |
| intends to delete the resource or move it to an inaccessible |  | response is given, it intends to delete the resource or move it to an |
| location. |  | inaccessible 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-target |  | If the request passes through a cache and the Effective Request URI |
| identifies one or more currently cached entities, those entries |  | identifies one or more currently cached entities, those entries |
| SHOULD be treated as stale. Responses to this method are not |  | SHOULD be treated as stale. Responses to this method are not |
| cacheable. |  | cacheable. |
| 7.8. TRACE |  | 7.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 entity- |  | SHOULD reflect the message received back to the client as the 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 |
| skipping to change at page 20, line 51 |  | skipping to change at page 20, line 51 |
| been received and has not yet been rejected by the server. The |  | been received and has not yet been rejected by the server. The |
| client SHOULD continue by sending the remainder of the request or, if |  | client SHOULD continue by sending the remainder of the request or, if |
| the request has already been completed, ignore this response. The |  | the request has already been completed, ignore this response. The |
| server MUST send a final response after the request has been |  | server MUST send a final response after the request has been |
| completed. See Section 7.2.3 of [Part1] for detailed discussion of |  | completed. See Section 7.2.3 of [Part1] for detailed discussion of |
| the use and handling of this status code. |  | the use and handling of this status code. |
| 8.1.2. 101 Switching Protocols |  | 8.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 5.4 of |  | request, via the Upgrade message header field (Section 9.8 of |
|  |  | [Part1]), for a change in the application protocol being used on this |
| [Part5]), for a change in the application protocol being used on this |  |  |
| connection. The server will switch protocols to those defined by the |  | connection. The server will switch protocols to those defined by the |
| response's Upgrade header field immediately after the empty line |  | response's Upgrade header field immediately after the empty line |
| which terminates the 101 response. |  | which 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 |  | so. For example, switching to a newer version of HTTP is |
| advantageous over older versions, and switching to a real-time, |  | advantageous over older versions, and switching to a real-time, |
| synchronous protocol might be advantageous when delivering resources |  | synchronous protocol might be advantageous when delivering resources |
| that use such features. |  | that use such features. |
| skipping to change at page 24, line 13 |  | skipping to change at page 24, line 13 |
| 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. |
| 8.3.2. 301 Moved Permanently |  | 8.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-target to one or more of the new |  | re-link references to the Effective Request URI to one or more of the |
| references returned by the server, where possible. This response is |  | new references returned by the server, where possible. This response |
| cacheable unless indicated otherwise. |  | is cacheable unless indicated otherwise. |
| The new permanent URI SHOULD be given by the Location field in the |  | The new permanent URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s). |  | the new URI(s). |
| If the 301 status code is received in response to a request method |  | If the 301 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 7.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| request MAY be automatically redirected by the user agent without |  | request MAY be automatically redirected by the user agent without |
| confirmation. Otherwise, the user agent MUST NOT automatically |  | confirmation. Otherwise, the user agent MUST NOT automatically |
| skipping to change at page 24, line 37 |  | skipping to change at page 24, line 37 |
| this might change the conditions under which the request was issued. |  | this might change the conditions under which the request was issued. |
| Note: When automatically redirecting a POST request after |  | Note: When automatically redirecting a POST request after |
| receiving a 301 status code, some existing HTTP/1.0 user agents |  | receiving a 301 status code, some existing HTTP/1.0 user agents |
| will erroneously change it into a GET request. |  | will erroneously change it into a GET request. |
| 8.3.3. 302 Found |  | 8.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-target for future requests. This |  | continue to use the Effectice Request URI for future requests. This |
| response is only cacheable if indicated by a Cache-Control or Expires |  | response is only cacheable if indicated by a Cache-Control or Expires |
| header field. |  | header field. |
| The temporary URI SHOULD be given by the Location field in the |  | The temporary URI SHOULD be given by the Location field in the |
| response. Unless the request method was HEAD, the entity of the |  | response. Unless the request method was HEAD, the entity of the |
| response SHOULD contain a short hypertext note with a hyperlink to |  | response SHOULD contain a short hypertext note with a hyperlink to |
| the new URI(s). |  | the new URI(s). |
| If the 302 status code is received in response to a request method |  | If the 302 status code is received in response to a request method |
| that is known to be "safe", as defined in Section 7.1.1, then the |  | that is known to be "safe", as defined in Section 7.1.1, then the |
| skipping to change at page 26, line 19 |  | skipping to change at page 26, line 19 |
| 8.3.7. 306 (Unused) |  | 8.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. |
| 8.3.8. 307 Temporary Redirect |  | 8.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-target for future requests. This |  | continue to use the Effective Request URI for future requests. This |
| response is only cacheable if indicated by a Cache-Control or Expires |  | response is only cacheable if indicated by a Cache-Control or Expires |
| header field. |  | header 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. |
| skipping to change at page 27, line 34 |  | skipping to change at page 27, line 34 |
| 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. |
| 8.4.5. 404 Not Found |  | 8.4.5. 404 Not Found |
| The server has not found anything matching the request-target. No |  | The server has not found anything matching the Effective Request URI. |
| indication is given of whether the condition is temporary or |  | No 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. |
| 8.4.6. 405 Method Not Allowed |  | 8.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-target. The response MUST include |  | resource identified by the Effective Request URI. The response MUST |
| an Allow header containing a list of valid methods for the requested |  | include an Allow header containing a list of valid methods for the |
| resource. |  | requested resource. |
| 8.4.7. 406 Not Acceptable |  | 8.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 |
| skipping to change at page 29, line 19 |  | skipping to change at page 29, line 19 |
| 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 Content- |  | between the two versions in a format defined by the response Content- |
| Type. |  | Type. |
| 8.4.11. 410 Gone |  | 8.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-target after user approval. If the |  | delete references to the Effective Request URI after user approval. |
| server does not know, or has no facility to determine, whether or not |  | If the server does not know, or has no facility to determine, whether |
| the condition is permanent, the status code 404 (Not Found) SHOULD be |  | or not the condition is permanent, the status code 404 (Not Found) |
| used instead. This response is cacheable unless indicated otherwise. |  | SHOULD be 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 |  | remote links to that resource be removed. Such an event is common |
| for 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. |
| skipping to change at page 30, line 11 |  | skipping to change at page 30, line 12 |
| 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. |
| 8.4.15. 414 URI Too Long |  | 8.4.15. 414 URI Too Long |
| The server is refusing to service the request because the request- |  | The server is refusing to service the request because the Effective |
| target is longer than the server is willing to interpret. This rare |  | Request URI is longer than the server is willing to interpret. This |
| condition is only likely to occur when a client has improperly |  | rare 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-target. |  | buffers for reading or manipulating the Effective Request URI. |
| 8.4.16. 415 Unsupported Media Type |  | 8.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. |
| 8.4.17. 416 Requested Range Not Satisfiable |  | 8.4.17. 416 Requested Range Not Satisfiable |
| The request included a Range request-header field (Section 5.4 of |  | The request included a Range request-header field (Section 5.4 of |
| skipping to change at page 32, line 19 |  | skipping to change at page 32, line 19 |
| This section defines the syntax and semantics of HTTP/1.1 header |  | This section defines the syntax and semantics of HTTP/1.1 header |
| fields related to request and response semantics. |  | fields related to request and response semantics. |
| For entity-header fields, both sender and recipient refer to either |  | For entity-header fields, both sender and recipient refer to either |
| the client or the server, depending on who sends and who receives the |  | the client or the server, depending on who sends and who receives the |
| entity. |  | entity. |
| 9.1. Allow |  | 9.1. Allow |
| The "Allow" response-header field lists the set of methods advertised |  | The "Allow" response-header field lists the set of methods advertised |
| as supported by the resource identified by the request-target. The |  | as supported by the resource identified by the Effective Request URI. |
| purpose of this field is strictly to inform the recipient of valid |  | The purpose of this field is strictly to inform the recipient of |
| methods associated with the resource. |  | valid methods associated with the resource. |
| Allow = "Allow" ":" OWS Allow-v |  | Allow = "Allow" ":" OWS Allow-v |
| Allow-v = #Method |  | Allow-v = #Method |
| Example of use: |  | Example of use: |
| Allow: GET, HEAD, PUT |  | Allow: GET, HEAD, PUT |
| The actual set of allowed methods is defined by the origin server at |  | The actual set of allowed methods is defined by the origin server at |
| the time of each request. |  | the time of each request. |
| skipping to change at page 34, line 30 |  | skipping to change at page 34, line 29 |
| The "Location" response-header field is used to identify a newly |  | The "Location" response-header field is used to identify a newly |
| created resource, or to redirect the recipient to a different |  | created resource, or to redirect the recipient to a different |
| location for completion of the request. |  | location for completion of the request. |
| For 201 (Created) responses, the Location is the URI of the new |  | For 201 (Created) responses, the Location is the URI of the new |
| resource which was created by the request. For 3xx responses, the |  | resource which was created by the request. For 3xx responses, the |
| location SHOULD indicate the server's preferred URI for automatic |  | location SHOULD indicate the server's preferred URI for automatic |
| redirection to the resource. |  | redirection to the resource. |
| The field value consists of a single URI. |  | The field value consists of a single URI-reference. When it has the |
|  |  | form of a relative reference ([RFC3986], Section 4.2), the final |
|  |  | value is computed by resolving it against the effective request URI |
|  |  | ([RFC3986], Section 5). |
| Location = "Location" ":" OWS Location-v |  | Location = "Location" ":" OWS Location-v |
| Location-v = URI |  | Location-v = URI-reference |
| An example is: |  | Examples are: |
| Location: http://www.example.org/pub/WWW/People.html |  | Location: http://www.example.org/pub/WWW/People.html#tim |
|  |  | Location: /index.html |
| There are circumstances in which a fragment identifier in a Location |  | There are circumstances in which a fragment identifier in a Location |
| URI would not be appropriate: |  | URI would not be appropriate: |
| o With a 201 Created response, because in this usage the Location |  | o With a 201 Created response, because in this usage the Location |
| header specifies the URI for the entire created resource. |  | header specifies the URI for the entire created resource. |
| o With 305 Use Proxy. |  | o With 305 Use Proxy. |
|  |  | Note: This specification does not define precedence rules for the |
|  |  | case where the original URI, as navigated to by the user agent, |
|  |  | and the Location header field value both contain fragment |
|  |  | identifiers. |
| Note: The Content-Location header field (Section 5.7 of [Part3]) |  | Note: The Content-Location header field (Section 5.7 of [Part3]) |
| differs from Location in that the Content-Location identifies the |  | differs from Location in that the Content-Location identifies the |
| original location of the entity enclosed in the response. It is |  | original location of the entity enclosed in the response. It is |
| therefore possible for a response to contain header fields for |  | therefore possible for a response to contain header fields for |
| both Location and Content-Location. |  | both Location and Content-Location. |
| 9.5. Max-Forwards |  | 9.5. 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 7.8) and OPTIONS (Section 7.2) methods to limit the |  | TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the |
| skipping to change at page 35, line 34 |  | skipping to change at page 35, line 45 |
| is greater than zero, then the forwarded message MUST contain an |  | is greater than zero, then the forwarded message MUST contain an |
| updated 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. |
| 9.6. Referer |  | 9.6. Referer |
| The "Referer" [sic] request-header field allows the client to specify |  | The "Referer" [sic] request-header field allows the client to specify |
| the URI of the resource from which the request-target was obtained |  | the URI of the resource from which the Effective Request URI was |
| (the "referrer", although the header field is misspelled.). |  | obtained (the "referrer", although the header field is misspelled.). |
| The Referer header allows servers to generate lists of back-links to |  | The Referer header allows servers to generate lists of back-links to |
| resources for interest, logging, optimized caching, etc. It also |  | resources for interest, logging, optimized caching, etc. It also |
| allows obsolete or mistyped links to be traced for maintenance. Some |  | allows obsolete or mistyped links to be traced for maintenance. Some |
| servers use Referer as a means of controlling where they allow links |  | servers use Referer as a means of controlling where they allow links |
| from (so-called "deep linking"), but it should be noted that |  | from (so-called "deep linking"), but it should be noted that |
| legitimate requests are not required to contain a Referer header |  | legitimate requests are not required to contain a Referer header |
| field. |  | field. |
| If the request-target was obtained from a source that does not have |  | If the Effective Request URI was obtained from a source that does not |
| its own URI (e.g., input from the user keyboard), the Referer field |  | have its own URI (e.g., input from the user keyboard), the Referer |
| MUST either be sent with the value "about:blank", or not be sent at |  | field MUST either be sent with the value "about:blank", or not be |
| all. Note that this requirement does not apply to sources with non- |  | sent at all. Note that this requirement does not apply to sources |
| HTTP URIs (e.g., FTP). |  | with non-HTTP URIs (e.g., FTP). |
| Referer = "Referer" ":" OWS Referer-v |  | Referer = "Referer" ":" OWS Referer-v |
| Referer-v = absolute-URI / partial-URI |  | Referer-v = absolute-URI / partial-URI |
| Example: |  | Example: |
| Referer: http://www.example.org/hypertext/Overview.html |  | Referer: http://www.example.org/hypertext/Overview.html |
| If the field value is a relative URI, it SHOULD be interpreted |  | If the field value is a relative URI, it SHOULD be interpreted |
| relative to the request-target. The URI MUST NOT include a fragment. |  | relative to the Effective Request URI. The URI MUST NOT include a |
| See Section 11.2 for security considerations. |  | fragment. See Section 11.2 for security considerations. |
| 9.7. Retry-After |  | 9.7. Retry-After |
| The response-header "Retry-After" field can be used with a 503 |  | The response-header "Retry-After" field can be used with a 503 |
| (Service Unavailable) response to indicate how long the service is |  | (Service Unavailable) response to indicate how long the service is |
| expected to be unavailable to the requesting client. This field MAY |  | expected to be unavailable to the requesting client. This field MAY |
| also be used with any 3xx (Redirection) response to indicate the |  | also be used with any 3xx (Redirection) response to indicate the |
| minimum time the user-agent is asked wait before issuing the |  | minimum time the user-agent is asked wait before issuing the |
| redirected request. |  | redirected request. |
| skipping to change at page 37, line 49 |  | skipping to change at page 38, line 14 |
| User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |  | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
| 10. IANA Considerations |  | 10. IANA Considerations |
| 10.1. Method Registry |  | 10.1. Method Registry |
| The registration procedure for HTTP Methods is defined by Section 2.1 |  | The registration procedure for HTTP Methods is defined by Section 2.1 |
| of this document. |  | of this document. |
| The HTTP Method Registry located at |  | The HTTP Method Registry should be created at |
| <http://www.iana.org/assignments/http-methods> should be populated |  | <http://www.iana.org/assignments/http-methods> and be populated with |
| with the registrations below: |  | the registrations below: |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | Method | Safe | Reference | |  | | Method | Safe | Reference | |
| +---------+------+-------------+ |  | +---------+------+-------------+ |
| | CONNECT | no | Section 7.9 | |  | | CONNECT | no | Section 7.9 | |
| | DELETE | no | Section 7.7 | |  | | DELETE | no | Section 7.7 | |
| | GET | yes | Section 7.3 | |  | | GET | yes | Section 7.3 | |
| | HEAD | yes | Section 7.4 | |  | | HEAD | yes | Section 7.4 | |
| | OPTIONS | yes | Section 7.2 | |  | | OPTIONS | yes | Section 7.2 | |
| | POST | no | Section 7.5 | |  | | POST | no | Section 7.5 | |
| skipping to change at page 41, line 47 |  | skipping to change at page 41, line 46 |
| 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 should not use GET-based forms for the submission |  | Authors of services should not use GET-based forms for the submission |
| of sensitive data because that data will be encoded in the Request- |  | of sensitive data because that data will be encoded in the request- |
| target. Many existing servers, proxies, and user agents log or |  | target. Many existing servers, proxies, and user agents log or |
| display the Request-target in places where it might be visible to |  | display the request-target in places where it might be visible to |
| third parties. Such services can use POST-based form submission |  | third parties. Such services can use POST-based form submission |
| instead. |  | instead. |
| 11.3. Location Headers and Spoofing |  | 11.3. 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. |
| 12. Acknowledgments |  | 12. Acknowledgments |
| 13. References |  | 13. References |
| 13.1. Normative References |  | 13.1. Normative References |
| [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |  | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
| and Message Parsing", draft-ietf-httpbis-p1-messaging-09 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-10 |
| (work in progress), March 2010. |  | (work in progress), July 2010. |
| [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |  | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload |
| and Content Negotiation", draft-ietf-httpbis-p3-payload-09 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-10 |
| (work in progress), March 2010. |  | (work in progress), July 2010. |
| [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |  | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
| Requests", draft-ietf-httpbis-p4-conditional-09 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |  | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
| Partial Responses", draft-ietf-httpbis-p5-range-09 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-10 (work |
| in progress), March 2010. |  | in progress), July 2010. |
| [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |  | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part |
| 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in |
| progress), March 2010. |  | progress), July 2010. |
| [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |  | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
| Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |  | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
| and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |  | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |
| draft-ietf-httpbis-p7-auth-09 (work in progress), |  | draft-ietf-httpbis-p7-auth-10 (work in progress), |
| March 2010. |  | July 2010. |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |  | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |  | Requirement Levels", BCP 14, RFC 2119, March 1997. |
|  |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
|  |  | Resource Identifier (URI): Generic Syntax", RFC 3986, |
|  |  | STD 66, January 2005. |
| [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |  | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
| Specifications: ABNF", STD 68, RFC 5234, January 2008. |  | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 13.2. Informative References |  | 13.2. Informative References |
| [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |  | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
| Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |  | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
| [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |  | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
| Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |  | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
| skipping to change at page 45, line 20 |  | skipping to change at page 45, line 20 |
| implement it. It used to indicate that the requested resource must |  | implement it. It used to indicate that the requested resource must |
| be accessed through the proxy given by the Location field. The |  | be accessed through the proxy given by the Location field. The |
| Location field gave the URI of the proxy. The recipient was expected |  | Location field gave the URI of the proxy. The recipient was expected |
| to repeat this single request via the proxy. (Section 8.3.6) |  | to repeat this single request via the proxy. (Section 8.3.6) |
| Reclassify Allow header as response header, removing the option to |  | Reclassify Allow header as response header, removing the option to |
| specify it in a PUT request. Relax the server requirement on the |  | specify it in a PUT request. Relax the server requirement on the |
| contents of the Allow header and remove requirement on clients to |  | contents of the Allow header and remove requirement on clients to |
| always trust the header value. (Section 9.1) |  | always trust the header value. (Section 9.1) |
| Correct syntax of Location header to allow fragment, as referred |  | Correct syntax of Location header to allow URI references (including |
| symbol wasn't what was expected, and add some clarifications as to |  | relative references and fragments), as referred symbol "absoluteURI" |
| when it would not be appropriate. (Section 9.4) |  | wasn't what was expected, and add some clarifications as to when use |
|  |  | of fragments would not be appropriate. (Section 9.4) |
| Allow Referer value of "about:blank" as alternative to not specifying |  | Allow Referer value of "about:blank" as alternative to not specifying |
| it. (Section 9.6) |  | it. (Section 9.6) |
| In the description of the Server header, the Via field was described |  | In the description of the Server header, the Via field was described |
| as a SHOULD. The requirement was and is stated correctly in the |  | as a SHOULD. The requirement was and is stated correctly in the |
| description of the Via header in Section 9.9 of [Part1]. |  | description of the Via header in Section 9.9 of [Part1]. |
| (Section 9.8) |  | (Section 9.8) |
| Appendix B. Collected ABNF |  | Appendix B. Collected ABNF |
| skipping to change at page 46, line 16 |  | skipping to change at page 46, line 16 |
| If-Match = <If-Match, defined in [Part4], Section 6.2> |  | If-Match = <If-Match, defined in [Part4], Section 6.2> |
| If-Modified-Since = |  | If-Modified-Since = |
| <If-Modified-Since, defined in [Part4], Section 6.3> |  | <If-Modified-Since, defined in [Part4], Section 6.3> |
| If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |  | If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> |
| If-Range = <If-Range, defined in [Part5], Section 5.3> |  | If-Range = <If-Range, defined in [Part5], Section 5.3> |
| If-Unmodified-Since = |  | If-Unmodified-Since = |
| <If-Unmodified-Since, defined in [Part4], Section 6.5> |  | <If-Unmodified-Since, defined in [Part4], Section 6.5> |
| Location = "Location:" OWS Location-v |  | Location = "Location:" OWS Location-v |
| Location-v = URI |  | Location-v = URI-reference |
| Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v |  | Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v |
| Max-Forwards-v = 1*DIGIT |  | Max-Forwards-v = 1*DIGIT |
| Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS |  | Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS |
| / %x47.45.54 ; GET |  | / %x47.45.54 ; GET |
| / %x48.45.41.44 ; HEAD |  | / %x48.45.41.44 ; HEAD |
| / %x50.4F.53.54 ; POST |  | / %x50.4F.53.54 ; POST |
| / %x50.55.54 ; PUT |  | / %x50.55.54 ; PUT |
| / %x44.45.4C.45.54.45 ; DELETE |  | / %x44.45.4C.45.54.45 ; DELETE |
| / %x54.52.41.43.45 ; TRACE |  | / %x54.52.41.43.45 ; TRACE |
| skipping to change at page 47, line 11 |  | skipping to change at page 47, line 11 |
| Server = "Server:" OWS Server-v |  | Server = "Server:" OWS Server-v |
| Server-v = product *( RWS ( product / comment ) ) |  | Server-v = product *( RWS ( product / comment ) ) |
| Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |  | Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / |
| "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |  | "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / |
| "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |  | "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / |
| "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |  | "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / |
| "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |  | "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / |
| "505" / extension-code |  | "505" / extension-code |
| TE = <TE, defined in [Part1], Section 9.8> |  | TE = <TE, defined in [Part1], Section 9.5> |
| URI = <URI, defined in [Part1], Section 2.6> |  | URI-reference = <URI-reference, defined in [Part1], Section 2.6> |
| User-Agent = "User-Agent:" OWS User-Agent-v |  | User-Agent = "User-Agent:" OWS User-Agent-v |
| User-Agent-v = product *( RWS ( product / comment ) ) |  | User-Agent-v = product *( RWS ( product / comment ) ) |
| Vary = <Vary, defined in [Part6], Section 3.5> |  | Vary = <Vary, defined in [Part6], Section 3.5> |
| WWW-Authenticate = |  | WWW-Authenticate = |
| <WWW-Authenticate, defined in [Part7], Section 3.4> |  | <WWW-Authenticate, defined in [Part7], Section 3.4> |
| absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> |
| skipping to change at page 52, line 27 |  | skipping to change at page 52, line 27 |
| and TRACE safe?" |  | and TRACE safe?" |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 |
| Closed issues: |  | Closed issues: |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods |
| vs Redirection" (we missed the introduction to the 3xx status |  | vs Redirection" (we missed the introduction to the 3xx status |
| codes when fixing this previously) |  | codes when fixing this previously) |
|  |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment |
|  |  | combination / precedence during redirects" |
|  |  | Partly resolved issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location |
|  |  | header payload handling" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
|  |  | requested resource's URI" |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 20 |  | 100 Continue (status code) 20 |
| 101 Switching Protocols (status code) 20 |  | 101 Switching Protocols (status code) 20 |
| 2 |  | 2 |
| 200 OK (status code) 21 |  | 200 OK (status code) 21 |
| 201 Created (status code) 21 |  | 201 Created (status code) 21 |
| 202 Accepted (status code) 22 |  | 202 Accepted (status code) 22 |
| skipping to change at page 54, line 20 |  | skipping to change at page 54, line 35 |
| extension-code 11 |  | extension-code 11 |
| extension-method 8 |  | extension-method 8 |
| From 33 |  | From 33 |
| From-v 33 |  | From-v 33 |
| Location 34 |  | Location 34 |
| Location-v 34 |  | Location-v 34 |
| Max-Forwards 35 |  | Max-Forwards 35 |
| Max-Forwards-v 35 |  | Max-Forwards-v 35 |
| Method 8 |  | Method 8 |
| Reason-Phrase 11 |  | Reason-Phrase 11 |
| Referer 35 |  | Referer 36 |
| Referer-v 35 |  | Referer-v 36 |
| request-header 9 |  | request-header 9 |
| response-header 12 |  | response-header 12 |
| Retry-After 36 |  | Retry-After 36 |
| Retry-After-v 36 |  | Retry-After-v 36 |
| Server 36 |  | Server 37 |
| Server-v 36 |  | Server-v 37 |
| Status-Code 11 |  | Status-Code 11 |
| User-Agent 37 |  | User-Agent 37 |
| User-Agent-v 37 |  | User-Agent-v 37 |
| H |  | H |
| HEAD method 16 |  | HEAD method 16 |
| Headers |  | Headers |
| Allow 32 |  | Allow 32 |
| Expect 32 |  | Expect 32 |
| From 33 |  | From 33 |
| Location 34 |  | Location 34 |
| Max-Forwards 35 |  | Max-Forwards 35 |
| Referer 35 |  | Referer 35 |
| Retry-After 36 |  | Retry-After 36 |
| Server 36 |  | Server 37 |
| User-Agent 37 |  | User-Agent 37 |
| I |  | I |
| Idempotent Methods 14 |  | Idempotent Methods 14 |
| L |  | L |
| LINK method 44 |  | LINK method 44 |
| Location header 34 |  | Location header 34 |
| M |  | M |
| Max-Forwards header 35 |  | Max-Forwards header 35 |
| Methods |  | Methods |
| CONNECT 20 |  | CONNECT 20 |
| DELETE 19 |  | DELETE 19 |
| GET 16 |  | GET 16 |
| HEAD 16 |  | HEAD 16 |
| LINK 44 |  | LINK 44 |
| OPTIONS 15 |  | OPTIONS 14 |
| PATCH 44 |  | PATCH 44 |
| POST 17 |  | POST 17 |
| PUT 18 |  | PUT 17 |
| TRACE 19 |  | TRACE 19 |
| UNLINK 44 |  | UNLINK 44 |
| O |  | O |
| OPTIONS method 15 |  | OPTIONS method 14 |
| P |  | P |
| PATCH method 44 |  | PATCH method 44 |
| POST method 17 |  | POST method 17 |
| PUT method 18 |  | PUT method 17 |
| R |  | R |
| Referer header 35 |  | Referer header 35 |
| Retry-After header 36 |  | Retry-After header 36 |
| S |  | S |
| Safe Methods 14 |  | Safe Methods 14 |
| Server header 36 |  | Server header 37 |
| Status Codes |  | Status Codes |
| 100 Continue 20 |  | 100 Continue 20 |
| 101 Switching Protocols 20 |  | 101 Switching Protocols 20 |
| 200 OK 21 |  | 200 OK 21 |
| 201 Created 21 |  | 201 Created 21 |
| 202 Accepted 22 |  | 202 Accepted 22 |
| 203 Non-Authoritative Information 22 |  | 203 Non-Authoritative Information 22 |
| 204 No Content 22 |  | 204 No Content 22 |
| 205 Reset Content 23 |  | 205 Reset Content 23 |
| 206 Partial Content 23 |  | 206 Partial Content 23 |
| skipping to change at page 56, line 46 |  | skipping to change at page 57, line 15 |
| Authors' Addresses |  | Authors' Addresses |
| Roy T. Fielding (editor) |  | Roy T. Fielding (editor) |
| Day Software |  | Day Software |
| 23 Corporate Plaza DR, Suite 280 |  | 23 Corporate Plaza DR, Suite 280 |
| Newport Beach, CA 92660 |  | Newport Beach, CA 92660 |
| USA |  | USA |
| Phone: +1-949-706-5300 |  | Phone: +1-949-706-5300 |
| Fax: +1-949-706-5305 |  | Fax: +1-949-706-5305 |
| Email: fielding@gbiv.com |  | EMail: fielding@gbiv.com |
| URI: http://roy.gbiv.com/ |  | URI: http://roy.gbiv.com/ |
| Jim Gettys |  | Jim Gettys |
| One Laptop per Child |  | Alcatel-Lucent Bell Labs |
| 21 Oak Knoll Road |  | 21 Oak Knoll Road |
| Carlisle, MA 01741 |  | Carlisle, MA 01741 |
| USA |  | USA |
| Email: jg@laptop.org |  | EMail: jg@freedesktop.org |
| URI: http://www.laptop.org/ |  | URI: http://gettys.wordpress.com/ |
| Jeffrey C. Mogul |  | Jeffrey C. Mogul |
| Hewlett-Packard Company |  | Hewlett-Packard Company |
| HP Labs, Large Scale Systems Group |  | HP Labs, Large Scale Systems Group |
| 1501 Page Mill Road, MS 1177 |  | 1501 Page Mill Road, MS 1177 |
| Palo Alto, CA 94304 |  | Palo Alto, CA 94304 |
| USA |  | USA |
| Email: JeffMogul@acm.org |  | EMail: JeffMogul@acm.org |
| Henrik Frystyk Nielsen |  | Henrik Frystyk Nielsen |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| USA |  | USA |
| Email: henrikn@microsoft.com |  | EMail: henrikn@microsoft.com |
| Larry Masinter |  | Larry Masinter |
| Adobe Systems, Incorporated |  | Adobe Systems, Incorporated |
| 345 Park Ave |  | 345 Park Ave |
| San Jose, CA 95110 |  | San Jose, CA 95110 |
| USA |  | USA |
| Email: LMM@acm.org |  | EMail: LMM@acm.org |
| URI: http://larry.masinter.net/ |  | URI: http://larry.masinter.net/ |
| Paul J. Leach |  | Paul J. Leach |
| Microsoft Corporation |  | Microsoft Corporation |
| 1 Microsoft Way |  | 1 Microsoft Way |
| Redmond, WA 98052 |  | Redmond, WA 98052 |
| Email: paulle@microsoft.com |  | EMail: paulle@microsoft.com |
| Tim Berners-Lee |  | Tim Berners-Lee |
| World Wide Web Consortium |  | World Wide Web Consortium |
| MIT Computer Science and Artificial Intelligence Laboratory |  | MIT Computer Science and Artificial Intelligence Laboratory |
| The Stata Center, Building 32 |  | The Stata Center, Building 32 |
| 32 Vassar Street |  | 32 Vassar Street |
| Cambridge, MA 02139 |  | Cambridge, MA 02139 |
| USA |  | USA |
| Email: timbl@w3.org |  | EMail: timbl@w3.org |
| URI: http://www.w3.org/People/Berners-Lee/ |  | URI: http://www.w3.org/People/Berners-Lee/ |
| Yves Lafon (editor) |  | Yves Lafon (editor) |
| World Wide Web Consortium |  | World Wide Web Consortium |
| W3C / ERCIM |  | W3C / ERCIM |
| 2004, rte des Lucioles |  | 2004, rte des Lucioles |
| Sophia-Antipolis, AM 06902 |  | Sophia-Antipolis, AM 06902 |
| France |  | France |
| Email: ylafon@w3.org |  | EMail: ylafon@w3.org |
| URI: http://www.raubacapeu.net/people/yves/ |  | URI: http://www.raubacapeu.net/people/yves/ |
| Julian F. Reschke (editor) |  | Julian F. Reschke (editor) |
| greenbytes GmbH |  | greenbytes GmbH |
| Hafenweg 16 |  | Hafenweg 16 |
| Muenster, NW 48155 |  | Muenster, NW 48155 |
| Germany |  | Germany |
| Phone: +49 251 2807760 |  | Phone: +49 251 2807760 |
| Fax: +49 251 2807761 |  | Fax: +49 251 2807761 |
| Email: julian.reschke@greenbytes.de |  | EMail: julian.reschke@greenbytes.de |
| URI: http://greenbytes.de/tech/webdav/ |  | URI: http://greenbytes.de/tech/webdav/ |
End of changes. 94 change blocks.
| 227 lines changed or deleted |  | 254 lines changed or added |
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/