draft-ietf-httpbis-p2-semantics-06.txt   draft-ietf-httpbis-p2-semantics-07.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 10, 2009 HP Expires: January 14, 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 9, 2009 July 13, 2009
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-06 draft-ietf-httpbis-p2-semantics-07
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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 10, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
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.7. The changes in this draft are summarized in Appendix C.8.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 5, line 12 skipping to change at page 5, line 12
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
13.2. Informative References . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Compatibility with Previous Versions . . . . . . . . 42 Appendix A. Compatibility with Previous Versions . . . . . . . . 42
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 47 publication) . . . . . . . . . . . . . . . . . . . . 47
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 48
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 50
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
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
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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>
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.1> absolute-URI = <absolute-URI, defined in [Part1], Section 2.1>
fragment = <fragment, defined in [Part1], Section 2.1> fragment = <fragment, defined in [Part1], Section 2.1>
Host = <Host, defined in [Part1], Section 2.1> Host = <Host, defined in [Part1], Section 2.1>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.1> partial-URI = <partial-URI, defined in [Part1], Section 2.1>
product = <product, defined in [Part1], Section 3.4> product = <product, defined in [Part1], Section 3.4>
TE = <TE, defined in [Part1], Section 8.8> TE = <TE, defined in [Part1], Section 8.8>
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 =
skipping to change at page 9, line 12 skipping to change at page 9, line 12
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Method Name (see Section 2) o Method Name (see Section 2)
o Safe ("yes" or "no", see Section 7.1.1) o Safe ("yes" or "no", see Section 7.1.1)
o Pointer to specification text o Pointer to specification text
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). Any document registering new method names ([RFC5226], Section 4.1).
should be traceable through statuses of either 'Obsoletes' or
'Updates' to this document.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-methods>. <http://www.iana.org/assignments/http-methods>.
3. Request Header Fields 3. Request Header Fields
The request-header fields allow the client to pass additional The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
skipping to change at page 12, line 22 skipping to change at page 12, line 22
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
4.1. Status Code Registry 4.1. Status Code Registry
The HTTP Status Code Registry defines the name space for the Status- The HTTP Status Code Registry defines the name space for the Status-
Code token in the Status line of an HTTP response. Code token in the Status line of an HTTP response.
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). Any document registering new status codes ([RFC5226], Section 4.1).
should be traceable through statuses of either 'Obsoletes' or
'Updates' to this document.
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
5. Response Header Fields 5. Response Header Fields
The response-header fields allow the server to pass additional The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and Line. These header fields give information about the server and
about further access to the resource identified by the request- about further access to the resource identified by the request-
skipping to change at page 19, line 27 skipping to change at page 19, line 27
NOT be cached. NOT be cached.
7.9. CONNECT 7.9. CONNECT
This specification reserves the method name CONNECT for use with a This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [RFC2817]). tunneling [RFC2817]).
8. Status Code Definitions 8. Status Code Definitions
Each Status-Code is described below, including a description of which Each Status-Code is described below, including any metainformation
method(s) it can follow and any metainformation required in the required in the response.
response.
8.1. Informational 1xx 8.1. Informational 1xx
This class of status code indicates a provisional response, This class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is consisting only of the Status-Line and optional headers, and is
terminated by an empty line. There are no required headers for this terminated by an empty line. There are no required headers for this
class of status code. Since HTTP/1.0 did not define any 1xx status class of status code. Since HTTP/1.0 did not define any 1xx status
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
except under experimental conditions. except under experimental conditions.
skipping to change at page 25, line 10 skipping to change at page 25, line 10
original request. original request.
A 303 response to a GET request indicates that the requested resource A 303 response to a GET request indicates that the requested resource
does not have a representation of its own that can be transferred by does not have a representation of its own that can be transferred by
the server over HTTP. The Location URI indicates a resource that is the server over HTTP. The Location URI indicates a resource that is
descriptive of the requested resource such that the follow-on descriptive of the requested resource such that the follow-on
representation may be useful without implying that it adequately representation may be useful without implying that it adequately
represents the previously requested resource. Note that answers to represents the previously requested resource. Note that answers to
the questions of what can be represented, what representations are the questions of what can be represented, what representations are
adequate, and what might be a useful description are outside the adequate, and what might be a useful description are outside the
scope of HTTP and thus entirely determined by the resource owner(s). scope of HTTP and thus entirely determined by the URI owner(s).
A 303 response SHOULD NOT be cached unless it is indicated as A 303 response SHOULD NOT be cached unless it is indicated as
cacheable by Cache-Control or Expires header fields. Except for cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI. contain a short hypertext note with a hyperlink to the Location URI.
8.3.5. 304 Not Modified 8.3.5. 304 Not Modified
The response to the request has not been modified since the The response to the request has not been modified since the
conditions indicated by the client's conditional GET request, as conditions indicated by the client's conditional GET request, as
skipping to change at page 35, line 10 skipping to change at page 35, line 10
The Max-Forwards header field MAY be ignored for all other methods The Max-Forwards header field MAY be ignored for all other methods
defined by this specification and for any extension methods for which defined by this specification and for any extension methods for which
it is not explicitly referred to as part of that method definition. it is not explicitly referred to as part of that method definition.
9.6. Referer 9.6. Referer
The request-header field "Referer" [sic] allows the client to The request-header field "Referer" [sic] allows the client to
specify, for the server's benefit, the address (URI) of the resource specify, for the server's benefit, the address (URI) of the resource
from which the request-target was obtained (the "referrer", although from which the request-target was obtained (the "referrer", although
the header field is misspelled.) The Referer request-header allows a the header field is misspelled.).
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped The Referer header allows servers to generate lists of back-links to
links to be traced for maintenance. The Referer field MUST NOT be resources for interest, logging, optimized caching, etc. It also
sent if the request-target was obtained from a source that does not allows obsolete or mistyped links to be traced for maintenance. Some
have its own URI, such as input from the user keyboard. servers use Referer as a means of controlling where they allow links
from (so-called "deep linking"), but it should be noted that
legitimate requests are not required to contain a Referer header
field.
If the request-target was obtained from a source that does not have
its own URI (e.g., input from the user keyboard), the Referer field
MUST either be sent with the value "about:blank", or not be sent at
all. Note that this requirement does not apply to sources with non-
HTTP URIs (e.g., FTP).
Referer = "Referer" ":" OWS Referer-v Referer = "Referer" ":" OWS Referer-v
Referer-v = absolute-URI / partial-URI Referer-v = absolute-URI / partial-URI
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the request-target. The URI MUST NOT include a fragment. relative to the request-target. The URI MUST NOT include a fragment.
skipping to change at page 41, line 23 skipping to change at page 41, line 23
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-06 and Message Parsing", draft-ietf-httpbis-p1-messaging-07
(work in progress), March 2009. (work in progress), July 2009.
[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-06 and Content Negotiation", draft-ietf-httpbis-p3-payload-07
(work in progress), March 2009. (work in progress), July 2009.
[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-06 (work in Requests", draft-ietf-httpbis-p4-conditional-07 (work in
progress), March 2009. progress), July 2009.
[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-06 (work Partial Responses", draft-ietf-httpbis-p5-range-07 (work
in progress), March 2009. in progress), July 2009.
[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.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
draft-ietf-httpbis-p6-cache-06 (work in progress), 6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
March 2009. progress), July 2009.
[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-06 (work in progress), draft-ietf-httpbis-p7-auth-07 (work in progress),
March 2009. July 2009.
[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.
[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
skipping to change at page 44, line 22 skipping to change at page 44, line 22
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 fragment, as referred
symbol wasn't what was expected, and add some clarifications as to symbol wasn't what was expected, and add some clarifications as to
when it would not be appropriate. (Section 9.4) when it would not be appropriate. (Section 9.4)
Allow Referer value of "about:blank" as alternative to not specifying
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 8.9 of [Part1]. description of the Via header in Section 8.9 of [Part1].
(Section 9.8) (Section 9.8)
Appendix B. Collected ABNF Appendix B. Collected ABNF
Accept = <Accept, defined in [Part3], Section 5.1> Accept = <Accept, defined in [Part3], Section 5.1>
Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2> Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>
Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3> Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>
skipping to change at page 44, line 46 skipping to change at page 44, line 49
Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
Authorization = <Authorization, defined in [Part7], Section 3.1> Authorization = <Authorization, defined in [Part7], Section 3.1>
ETag = <ETag, defined in [Part4], Section 6.1> ETag = <ETag, defined in [Part4], Section 6.1>
Expect = "Expect:" OWS Expect-v Expect = "Expect:" OWS Expect-v
Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
From = "From:" OWS From-v From = "From:" OWS From-v
From-v = mailbox From-v = mailbox
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 2.1> Host = <Host, defined in [Part1], Section 2.1>
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 = absolute-URI [ "#" fragment ] Location-v = absolute-URI [ "#" fragment ]
skipping to change at page 45, line 16 skipping to change at page 45, line 17
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 = absolute-URI [ "#" fragment ] Location-v = absolute-URI [ "#" fragment ]
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 / %x47.45.54 / %x48.45.41.44 / Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS
%x50.4F.54 / %x50.55.54 / %x44.45.4C.45.54.45 / %x54.52.41.43.45 / / %x47.45.54 ; GET
%x43.4E.4E.45.43.54 / extension-method / %x48.45.41.44 ; HEAD
/ %x50.4F.53.54 ; POST
/ %x50.55.54 ; PUT
/ %x44.45.4C.45.54.45 ; DELETE
/ %x54.52.41.43.45 ; TRACE
/ %x43.4F.4E.4E.45.43.54 ; CONNECT
/ extension-method
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Proxy-Authenticate = Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 3.2> <Proxy-Authenticate, defined in [Part7], Section 3.2>
Proxy-Authorization = Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 3.3> <Proxy-Authorization, defined in [Part7], Section 3.3>
RWS = <RWS, defined in [Part1], Section 1.2.2> RWS = <RWS, defined in [Part1], Section 1.2.2>
Range = <Range, defined in [Part5], Section 5.4> Range = <Range, defined in [Part5], Section 5.4>
skipping to change at page 50, line 14 skipping to change at page 50, line 18
o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
BNF" BNF"
Final work on ABNF conversion Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Add appendix containing collected and expanded ABNF, reorganize o Add appendix containing collected and expanded ABNF, reorganize
ABNF introduction. ABNF introduction.
C.8. Since draft-ietf-httpbis-p2-semantics-06
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
Referer is sent"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
vs methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
require "updates" relation for specs that register status codes or
method names"
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) 20 200 OK (status code) 20
201 Created (status code) 21 201 Created (status code) 21
202 Accepted (status code) 21 202 Accepted (status code) 21
skipping to change at page 51, line 33 skipping to change at page 52, line 4
CONNECT method 19 CONNECT method 19
D D
DELETE method 18 DELETE method 18
E E
Expect header 32 Expect header 32
F F
From header 33 From header 33
G G
GET method 15 GET method 15
Grammar Grammar
Allow 31 Allow 31
Allow-v 31 Allow-v 31
delta-seconds 35 delta-seconds 36
Expect 32 Expect 32
expect-params 32 expect-params 32
Expect-v 32 Expect-v 32
expectation 32 expectation 32
expectation-extension 32 expectation-extension 32
extension-code 11 extension-code 11
extension-method 8 extension-method 8
From 33 From 33
From-v 33 From-v 33
Location 33 Location 33
skipping to change at page 52, line 16 skipping to change at page 52, line 34
Reason-Phrase 11 Reason-Phrase 11
Referer 35 Referer 35
Referer-v 35 Referer-v 35
request-header 9 request-header 9
response-header 12 response-header 12
Retry-After 35 Retry-After 35
Retry-After-v 35 Retry-After-v 35
Server 36 Server 36
Server-v 36 Server-v 36
Status-Code 11 Status-Code 11
User-Agent 36 User-Agent 37
User-Agent-v 36 User-Agent-v 37
H H
HEAD method 16 HEAD method 16
Headers Headers
Allow 31 Allow 31
Expect 32 Expect 32
From 33 From 33
Location 33 Location 33
Max-Forwards 34 Max-Forwards 34
Referer 35 Referer 35
 End of changes. 27 change blocks. 
46 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/