| draft-ietf-httpbis-p2-semantics-15.txt |  | draft-ietf-httpbis-p2-semantics-16.txt |
--- | --- | --- | --- | ---
| HTTPbis Working Group R. Fielding, Ed. |  | HTTPbis Working Group R. Fielding, Ed. |
| Internet-Draft Adobe |  | Internet-Draft Adobe |
| Obsoletes: 2616 (if approved) J. Gettys |  | Obsoletes: 2616 (if approved) J. Gettys |
| Updates: 2817 (if approved) Alcatel-Lucent |  | Updates: 2817 (if approved) Alcatel-Lucent |
| Intended status: Standards Track J. Mogul |  | Intended status: Standards Track J. Mogul |
| Expires: January 12, 2012 HP |  | Expires: February 25, 2012 HP |
| H. Frystyk |  | H. Frystyk |
| Microsoft |  | Microsoft |
| L. Masinter |  | L. Masinter |
| Adobe |  | Adobe |
| 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 |
| July 11, 2011 |  | August 24, 2011 |
| HTTP/1.1, part 2: Message Semantics |  | HTTP/1.1, part 2: Message Semantics |
| draft-ietf-httpbis-p2-semantics-15 |  | draft-ietf-httpbis-p2-semantics-16 |
| 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, hypertext 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. |
| the semantics of HTTP messages as expressed by request methods, |  |  |
| request header fields, response status codes, and response header |  | Part 2 defines the semantics of HTTP messages as expressed by request |
| fields. |  | methods, request header fields, response status codes, and response |
|  |  | header 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), which is archived at |  | group mailing list (ietf-http-wg@w3.org), which is archived at |
| <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |  | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. |
| The current issues list is at |  | The current issues list is at |
| <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |  | <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.16. |  | The changes in this draft are summarized in Appendix C.17. |
| Status of This Memo |  | Status of This Memo |
| This Internet-Draft is submitted 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). Note that other groups may also distribute |  | Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |  | working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |  | 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." |
| This Internet-Draft will expire on January 12, 2012. |  | This Internet-Draft will expire on February 25, 2012. |
| Copyright Notice |  | Copyright Notice |
| Copyright (c) 2011 IETF Trust and the persons identified as the |  | Copyright (c) 2011 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 5, line 29 |  | skipping to change at page 5, line 31 |
| C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54 |  | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54 |
| C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54 |  | C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54 |
| C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 |  | C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 |
| C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55 |  | C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55 |
| C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 |  | C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 |
| C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 |  | C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 |
| C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56 |  | C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56 |
| C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 |  | C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 |
| C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58 |  | C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58 |
| C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 58 |  | C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 58 |
|  |  | C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 58 |
| Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |  | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
| 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 |
| skipping to change at page 7, line 9 |  | skipping to change at page 7, line 9 |
| 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 |
| (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |  | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
| HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |  | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
| sequence of data), SP (space), VCHAR (any visible USASCII character), |  | sequence of data), SP (space), VCHAR (any visible USASCII character), |
| and WSP (whitespace). |  | and WSP (whitespace). |
| 1.2.1. Core Rules |  | 1.2.1. Core Rules |
| The core rules below are defined in Section 1.2.2 of [Part1]: |  | The core rules below are defined in [Part1]: |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  |  |
| token = <token, defined in [Part1], Section 1.2.2> |  |  |
| OWS = <OWS, defined in [Part1], Section 1.2.2> |  | OWS = <OWS, defined in [Part1], Section 1.2.2> |
| RWS = <RWS, defined in [Part1], Section 1.2.2> |  | RWS = <RWS, defined in [Part1], Section 1.2.2> |
| obs-text = <obs-text, defined in [Part1], Section 1.2.2> |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
|  |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
|  |  | token = <token, defined in [Part1], Section 3.2.3> |
| 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.7> |  | absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> |
| comment = <comment, defined in [Part1], Section 3.2> |  | comment = <comment, defined in [Part1], Section 3.2> |
| 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.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| product = <product, defined in [Part1], Section 6.3> |  | product = <product, defined in [Part1], Section 6.3> |
| skipping to change at page 13, line 21 |  | skipping to change at page 13, line 21 |
| 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 target resource (Section 4.3 of [Part1]). |  | about further access to the target resource (Section 4.3 of [Part1]). |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | Header Field Name | Defined in... | |  | | Header Field Name | Defined in... | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| | Accept-Ranges | Section 5.1 of [Part5] | |  | | Accept-Ranges | Section 5.1 of [Part5] | |
| | Age | Section 3.1 of [Part6] | |  | | Age | Section 3.1 of [Part6] | |
| | Allow | Section 9.1 | |  | | Allow | Section 9.1 | |
| | ETag | Section 2.2 of [Part4] | |  | | ETag | Section 2.3 of [Part4] | |
| | Location | Section 9.4 | |  | | Location | Section 9.4 | |
| | Proxy-Authenticate | Section 4.2 of [Part7] | |  | | Proxy-Authenticate | Section 4.2 of [Part7] | |
| | Retry-After | Section 9.7 | |  | | Retry-After | Section 9.7 | |
| | Server | Section 9.8 | |  | | Server | Section 9.8 | |
| | Vary | Section 3.5 of [Part6] | |  | | Vary | Section 3.5 of [Part6] | |
| | WWW-Authenticate | Section 4.4 of [Part7] | |  | | WWW-Authenticate | Section 4.4 of [Part7] | |
| +--------------------+------------------------+ |  | +--------------------+------------------------+ |
| 6. Representation |  | 6. Representation |
| skipping to change at page 14, line 18 |  | skipping to change at page 14, line 18 |
| always the case. To determine the URI of the resource a response is |  | always the case. To determine the URI of the resource a response is |
| associated with, the following rules are used (with the first |  | associated with, the following rules are used (with the first |
| applicable one being selected): |  | 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 payload is a representation of the target |  | was GET, the response payload is a representation of the target |
| resource. |  | resource. |
| 2. If the response status code is 204, 206, or 304 and the request |  | 2. If the response status code is 204, 206, or 304 and the request |
| method was GET or HEAD, the response payload is a partial |  | method was GET or HEAD, the response payload is a partial |
| representation of the target resource (see Section 2.8 of |  | representation of the target resource. |
| [Part6]). |  |  |
| 3. If the response has a Content-Location header field, and that URI |  | 3. If the response has a Content-Location header field, and that URI |
| is the same as the effective request URI, the response payload is |  | is the same as the effective request URI, the response payload is |
| a representation of the target resource. |  | a representation of the target resource. |
| 4. If the response has a Content-Location header field, and that URI |  | 4. If the response has a Content-Location header field, and that URI |
| is not the same as the effective request URI, then the response |  | is not the same as the effective request URI, then the response |
| asserts that its payload is a representation of the resource |  | asserts that its payload is a representation of the resource |
| identified by the Content-Location URI. However, such an |  | identified by the Content-Location URI. However, such an |
| assertion cannot be trusted unless it can be verified by other |  | assertion cannot be trusted unless it can be verified by other |
| skipping to change at page 17, line 35 |  | skipping to change at page 17, line 34 |
| can be used for obtaining metadata about the representation implied |  | can be used for obtaining metadata about the representation implied |
| by the request without transferring the representation body. This |  | by the request without transferring the representation body. This |
| method is often used for testing hypertext links for validity, |  | method is often used for testing hypertext links for validity, |
| accessibility, and recent modification. |  | accessibility, and recent modification. |
| The response to a HEAD request is cacheable and MAY be used to |  | The response to a HEAD request is cacheable and MAY be used to |
| satisfy a subsequent HEAD request; see [Part6]. It also MAY be used |  | satisfy a subsequent HEAD request; see [Part6]. It also MAY be used |
| to update a previously cached representation from that resource; if |  | to update a previously cached representation from that resource; if |
| the new field values indicate that the cached representation differs |  | the new field values indicate that the cached representation differs |
| from the current representation (as would be indicated by a change in |  | from the current representation (as would be indicated by a change in |
| Content-Length, Content-MD5, ETag or Last-Modified), then the cache |  | Content-Length, ETag or Last-Modified), then the cache MUST treat the |
| MUST treat the cache entry as stale. |  | cache entry as stale. |
| Bodies on HEAD requests have no defined semantics. Note that sending |  | Bodies on HEAD requests have no defined semantics. Note that sending |
| a body on a HEAD request might cause some existing implementations to |  | a body on a HEAD request might cause some existing implementations to |
| reject the request. |  | reject the request. |
| 7.5. POST |  | 7.5. POST |
| The POST method requests that the origin server accept the |  | The POST method requests that the origin server accept the |
| representation enclosed in the request as data to be processed by the |  | representation enclosed in the request as data to be processed by the |
| target resource. POST is designed to allow a uniform method to cover |  | target resource. POST is designed to allow a uniform method to cover |
| skipping to change at page 25, line 7 |  | skipping to change at page 25, line 5 |
| response SHOULD include a payload containing a list of resource |  | response SHOULD include a payload containing a list of resource |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The payload format is specified by |  | choose the one most appropriate. The payload format is specified by |
| the media type given in the Content-Type header field. The origin |  | the media type given in the Content-Type header field. The origin |
| server MUST create the resource before returning the 201 status code. |  | server MUST create the resource before returning the 201 status code. |
| If the action cannot be carried out immediately, the server SHOULD |  | If the action cannot be carried out immediately, the server SHOULD |
| respond with 202 (Accepted) response instead. |  | respond with 202 (Accepted) response instead. |
| A 201 response MAY contain an ETag response header field indicating |  | A 201 response MAY contain an ETag response header field indicating |
| the current value of the entity-tag for the representation of the |  | the current value of the entity-tag for the representation of the |
| resource just created (see Section 2.2 of [Part4]). |  | resource just created (see Section 2.3 of [Part4]). |
| 8.2.3. 202 Accepted |  | 8.2.3. 202 Accepted |
| The request has been accepted for processing, but the processing has |  | The request has been accepted for processing, but the processing has |
| not been completed. The request might or might not eventually be |  | not been completed. The request might or might not eventually be |
| acted upon, as it might be disallowed when processing actually takes |  | acted upon, as it might be disallowed when processing actually takes |
| place. There is no facility for re-sending a status code from an |  | place. There is no facility for re-sending a status code from an |
| asynchronous operation such as this. |  | asynchronous operation such as this. |
| The 202 response is intentionally non-committal. Its purpose is to |  | The 202 response is intentionally non-committal. Its purpose is to |
| skipping to change at page 30, line 35 |  | skipping to change at page 30, line 35 |
| SHOULD be careful to ensure that the client acknowledges receipt of |  | SHOULD be careful to ensure that the client acknowledges receipt of |
| the packet(s) containing the response, before the server closes the |  | the packet(s) containing the response, before the server closes the |
| input connection. If the client continues sending data to the server |  | input connection. If the client continues sending data to the server |
| after the close, the server's TCP stack will send a reset packet to |  | after the close, the server's TCP stack will send a reset packet to |
| the client, which might erase the client's unacknowledged input |  | the client, which might erase the client's unacknowledged input |
| buffers before they can be read and interpreted by the HTTP |  | buffers before they can be read and interpreted by the HTTP |
| application. |  | application. |
| 8.4.1. 400 Bad Request |  | 8.4.1. 400 Bad Request |
| The request could not be understood by the server due to malformed |  | The server cannot or will not process the request, due to a client |
| syntax. The client SHOULD NOT repeat the request without |  | error (e.g., malformed syntax). |
| modifications. |  |  |
| 8.4.2. 401 Unauthorized |  | 8.4.2. 401 Unauthorized |
| The request requires user authentication (see Section 3.1 of |  | The request requires user authentication (see Section 3.1 of |
| [Part7]). |  | [Part7]). |
| 8.4.3. 402 Payment Required |  | 8.4.3. 402 Payment Required |
| This code is reserved for future use. |  | This code is reserved for future use. |
| skipping to change at page 31, line 35 |  | skipping to change at page 31, line 34 |
| 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 |
| target resource. The response MUST include an Allow header field |  | target resource. The response MUST include an Allow header field |
| containing a list of valid methods for the requested resource. |  | containing a list of valid methods for the 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 representations which have content characteristics not |  | response representations which have content characteristics not |
| acceptable according to the accept header fields sent in the request. |  | acceptable according to the Accept and Accept-* header fields sent in |
|  |  | the request (see Section 6 of [Part3]). |
| Unless it was a HEAD request, the response SHOULD include a |  | Unless it was a HEAD request, the response SHOULD include a |
| representation containing a list of available representation |  | representation containing a list of available representation |
| characteristics and location(s) from which the user or user agent can |  | characteristics and location(s) from which the user or user agent can |
| choose the one most appropriate. The data format is specified by the |  | choose the one most appropriate. The data format is specified by the |
| media type given in the Content-Type header field. Depending upon |  | media type given in the Content-Type header field. Depending upon |
| the format and the capabilities of the user agent, selection of the |  | the format and the capabilities of the user agent, selection of the |
| most appropriate choice MAY be performed automatically. However, |  | most appropriate choice MAY be performed automatically. However, |
| this specification does not define any standard for such automatic |  | this specification does not define any standard for such automatic |
| selection. |  | selection. |
| skipping to change at page 46, line 27 |  | skipping to change at page 46, line 27 |
| 11.4. Security Considerations for CONNECT |  | 11.4. Security Considerations for CONNECT |
| Since tunneled data is opaque to the proxy, there are additional |  | Since tunneled data is opaque to the proxy, there are additional |
| risks to tunneling to other well-known or reserved ports. A HTTP |  | risks to tunneling to other well-known or reserved ports. A HTTP |
| client CONNECTing to port 25 could relay spam via SMTP, for example. |  | client CONNECTing to port 25 could relay spam via SMTP, for example. |
| As such, proxies SHOULD restrict CONNECT access to a small number of |  | As such, proxies SHOULD restrict CONNECT access to a small number of |
| known ports. |  | known ports. |
| 12. Acknowledgments |  | 12. Acknowledgments |
|  |  | See Section 12 of [Part1]. |
| 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-15 |  | and Message Parsing", draft-ietf-httpbis-p1-messaging-16 |
| (work in progress), July 2011. |  | (work in progress), August 2011. |
| [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-15 |  | and Content Negotiation", draft-ietf-httpbis-p3-payload-16 |
| (work in progress), July 2011. |  | (work in progress), August 2011. |
| [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-15 (work in |  | Requests", draft-ietf-httpbis-p4-conditional-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [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-15 (work |  | Partial Responses", draft-ietf-httpbis-p5-range-16 (work |
| in progress), July 2011. |  | in progress), August 2011. |
| [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-15 (work in |  | 6: Caching", draft-ietf-httpbis-p6-cache-16 (work in |
| progress), July 2011. |  | progress), August 2011. |
| [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-15 (work in progress), |  | draft-ietf-httpbis-p7-auth-16 (work in progress), |
| July 2011. |  | August 2011. |
| [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 |  | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
| Resource Identifier (URI): Generic Syntax", STD 66, |  | Resource Identifier (URI): Generic Syntax", STD 66, |
| RFC 3986, January 2005. |  | RFC 3986, 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. |
| skipping to change at page 50, line 48 |  | skipping to change at page 50, line 48 |
| expectation-extension = token [ "=" ( token / quoted-string ) |  | expectation-extension = token [ "=" ( token / quoted-string ) |
| *expect-params ] |  | *expect-params ] |
| mailbox = <mailbox, defined in [RFC5322], Section 3.4> |  | mailbox = <mailbox, defined in [RFC5322], Section 3.4> |
| obs-text = <obs-text, defined in [Part1], Section 1.2.2> |  | obs-text = <obs-text, defined in [Part1], Section 1.2.2> |
| partial-URI = <partial-URI, defined in [Part1], Section 2.7> |  | partial-URI = <partial-URI, defined in [Part1], Section 2.7> |
| product = <product, defined in [Part1], Section 6.3> |  | product = <product, defined in [Part1], Section 6.3> |
| quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |  | quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> |
| token = <token, defined in [Part1], Section 1.2.2> |  | token = <token, defined in [Part1], Section 3.2.3> |
| ABNF diagnostics: |  | ABNF diagnostics: |
| ; Allow defined but not used |  | ; Allow defined but not used |
| ; Expect defined but not used |  | ; Expect defined but not used |
| ; From defined but not used |  | ; From defined but not used |
| ; Location defined but not used |  | ; Location defined but not used |
| ; Max-Forwards defined but not used |  | ; Max-Forwards defined but not used |
| ; Reason-Phrase defined but not used |  | ; Reason-Phrase defined but not used |
| ; Referer defined but not used |  | ; Referer defined but not used |
| ; Retry-After defined but not used |  | ; Retry-After defined but not used |
| skipping to change at page 58, line 31 |  | skipping to change at page 58, line 31 |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403 |
| forbidden" |  | forbidden" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203 |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203 |
| Non-Authoritative Information" |  | Non-Authoritative Information" |
| o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update |
| default reason phrase for 413" |  | default reason phrase for 413" |
|  |  | C.17. Since draft-ietf-httpbis-p2-semantics-15 |
|  |  | Closed issues: |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of |
|  |  | requirements on Accept re: 406" |
|  |  | o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response |
|  |  | isn't generic" |
| Index |  | Index |
| 1 |  | 1 |
| 100 Continue (status code) 23 |  | 100 Continue (status code) 23 |
| 101 Switching Protocols (status code) 23 |  | 101 Switching Protocols (status code) 23 |
| 2 |  | 2 |
| 200 OK (status code) 24 |  | 200 OK (status code) 24 |
| 201 Created (status code) 24 |  | 201 Created (status code) 24 |
| 202 Accepted (status code) 25 |  | 202 Accepted (status code) 25 |
End of changes. 27 change blocks.
| 37 lines changed or deleted |  | 50 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/