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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |