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/