| draft-ietf-httpbis-p2-semantics-09.txt | draft-ietf-httpbis-p2-semantics-latest.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) One Laptop per Child | |||
| Intended status: Standards Track J. Mogul | Intended status: Standards Track J. Mogul | |||
| Expires: September 9, 2010 HP | Expires: September 12, 2010 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 | March 11, 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-latest | |||
| 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, | |||
| skipping to change at page 1, line 46 | skipping to change at page 1, line 46 | |||
| 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/11> 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 to IETF 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), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 2, line 23 | skipping to change at page 2, line 23 | |||
| 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 | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on September 9, 2010. | This Internet-Draft will expire on September 12, 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 | |||
| skipping to change at page 4, line 40 | skipping to change at page 4, line 40 | |||
| 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 | |||
| Appendix A. Compatibility with Previous Versions . . . . . . . . 43 | Appendix A. Compatibility with Previous Versions . . . . . . . . 43 | |||
| A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 43 | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44 | |||
| A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 44 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45 | |||
| Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 | |||
| Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Change Log (to be removed by RFC Editor before | |||
| publication) . . . . . . . . . . . . . . . . . . . . 48 | publication) . . . . . . . . . . . . . . . . . . . . 48 | |||
| 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 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 | |||
| 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 7, line 28 | skipping to change at page 7, line 28 | |||
| 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.8> | |||
| 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 34, line 30 | skipping to change at page 34, line 30 | |||
| 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 42, line 22 | skipping to change at page 42, line 22 | |||
| 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", | |||
| (work in progress), March 2010. | draft-ietf-httpbis-p1-messaging-latest (work in progress), | |||
| March 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", | |||
| (work in progress), March 2010. | draft-ietf-httpbis-p3-payload-latest (work in progress), | |||
| March 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-latest (work | |||
| progress), March 2010. | in progress), March 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-latest | |||
| in progress), March 2010. | (work in progress), March 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-latest (work in | |||
| progress), March 2010. | progress), March 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-latest (work in progress), | |||
| March 2010. | March 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 28 | |||
| 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 23 | |||
| 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 13 | skipping to change at page 47, line 15 | |||
| 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.8> | |||
| 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 33 | |||
| 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" | ||||
| 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 38 | |||
| 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 | |||
| skipping to change at page 55, line 34 | skipping to change at page 55, line 50 | |||
| PATCH method 44 | PATCH method 44 | |||
| POST method 17 | POST method 17 | |||
| PUT method 18 | PUT method 18 | |||
| 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 | |||
| End of changes. 31 change blocks. | ||||
| 37 lines changed or deleted | 67 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/ | ||||