draft-ietf-httpbis-p2-semantics-04.txt   draft-ietf-httpbis-p2-semantics-05.txt 
Network Working Group R. Fielding, Ed. Network 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: March 2, 2009 HP Expires: May 20, 2009 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
August 29, 2008 November 16, 2008
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-04 draft-ietf-httpbis-p2-semantics-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 March 2, 2009. This Internet-Draft will expire on May 20, 2009.
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods, the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header request-header fields, response status codes, and response-header
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://www.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://www.tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix B.4. The changes in this draft are summarized in Appendix B.6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
2. Notational Conventions and Generic Grammar . . . . . . . . . . 6 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9
5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10
5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12
6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13
8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13
8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14
8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 44 publication) . . . . . . . . . . . . . . . . . . . . 44
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44
B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44 B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44
B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45 B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45
B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45 B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45
B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46 B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . . . . 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
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 6, line 46 skipping to change at page 6, line 46
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
2. Notational Conventions and Generic Grammar 2. Notational Conventions and Generic Grammar
This specification uses the ABNF syntax defined in Section 2.1 of This specification uses the ABNF syntax defined in Section 2.1 of
[Part1] and the core rules defined in Section 2.2 of [Part1]: [Part1] and the core rules defined in Section 2.2 of [Part1]:
[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
DIGIT = <DIGIT, defined in [Part1], Section 2.2> DIGIT = <DIGIT, defined in [Part1], Section 2.2>
comment = <comment, defined in [Part1], Section 2.2> comment = <comment, defined in [Part1], Section 2.2>
quoted-string = <quoted-string, defined in [Part1], Section 2.2> quoted-string = <quoted-string, defined in [Part1], Section 2.2>
token = <token, defined in [Part1], Section 2.2> token = <token, defined in [Part1], Section 2.2>
OWS = <OWS, defined in [Part1], Section 2.2>
RWS = <RWS, defined in [Part1], Section 2.2>
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1> absolute-URI = <absolute-URI, defined in [Part1], Section 3.2>
fragment = <fragment, defined in [Part1], Section 3.2.1> fragment = <fragment, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 8.4> Host = <Host, defined in [Part1], Section 3.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
product = <product, defined in [Part1], Section 3.5> product = <product, defined in [Part1], Section 3.5>
relativeURI = <relativeURI, defined in [Part1], Section 3.2.1> relativeURI = <relativeURI, defined in [Part1], Section 3.2>
TE = <TE, defined in [Part1], Section 8.8> TE = <TE, defined in [Part1], Section 8.8>
Accept = <Accept, defined in [Part3], Section 6.1> Accept = <Accept, defined in [Part3], Section 6.1>
Accept-Charset = Accept-Charset =
<Accept-Charset, defined in [Part3], Section 6.2> <Accept-Charset, defined in [Part3], Section 6.2>
Accept-Encoding = Accept-Encoding =
<Accept-Encoding, defined in [Part3], Section 6.3> <Accept-Encoding, defined in [Part3], Section 6.3>
Accept-Language = Accept-Language =
<Accept-Language, defined in [Part3], Section 6.4> <Accept-Language, defined in [Part3], Section 6.4>
skipping to change at page 8, line 12 skipping to change at page 8, line 18
<Proxy-Authorization, defined in [Part7], Section 4.3> <Proxy-Authorization, defined in [Part7], Section 4.3>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 4.4> <WWW-Authenticate, defined in [Part7], Section 4.4>
3. Method 3. Method
The Method token indicates the method to be performed on the resource The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. identified by the Request-URI. The method is case-sensitive.
Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2
| %x47.45.54 ; "GET", Section 8.3 / %x47.45.54 ; "GET", Section 8.3
| %x48.45.41.44 ; "HEAD", Section 8.4 / %x48.45.41.44 ; "HEAD", Section 8.4
| %x50.4F.53.54 ; "POST", Section 8.5 / %x50.4F.53.54 ; "POST", Section 8.5
| %x50.55.54 ; "PUT", Section 8.6 / %x50.55.54 ; "PUT", Section 8.6
| %x44.45.4C.45.54.45 ; "DELETE", Section 8.7 / %x44.45.4C.45.54.45 ; "DELETE", Section 8.7
| %x54.52.41.43.45 ; "TRACE", Section 8.8 / %x54.52.41.43.45 ; "TRACE", Section 8.8
| %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9 / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9
| extension-method / extension-method
extension-method = token extension-method = token
The list of methods allowed by a resource can be specified in an The list of methods allowed by a resource can be specified in an
Allow header field (Section 10.1). The return code of the response Allow header field (Section 10.1). The return code of the response
always notifies the client whether a method is currently allowed on a always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically. resource, since the set of allowed methods can change dynamically.
An origin server SHOULD return the status code 405 (Method Not An origin server SHOULD return the status code 405 (Method Not
Allowed) if the method is known by the origin server but not allowed Allowed) if the method is known by the origin server but not allowed
for the requested resource, and 501 (Not Implemented) if the method for the requested resource, and 501 (Not Implemented) if the method
is unrecognized or not implemented by the origin server. The methods is unrecognized or not implemented by the origin server. The methods
skipping to change at page 9, line 18 skipping to change at page 9, line 25
4. Request Header Fields 4. 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
invocation. invocation.
request-header = Accept ; [Part3], Section 6.1 request-header = Accept ; [Part3], Section 6.1
| Accept-Charset ; [Part3], Section 6.2 / Accept-Charset ; [Part3], Section 6.2
| Accept-Encoding ; [Part3], Section 6.3 / Accept-Encoding ; [Part3], Section 6.3
| Accept-Language ; [Part3], Section 6.4 / Accept-Language ; [Part3], Section 6.4
| Authorization ; [Part7], Section 4.1 / Authorization ; [Part7], Section 4.1
| Expect ; Section 10.2 / Expect ; Section 10.2
| From ; Section 10.3 / From ; Section 10.3
| Host ; [Part1], Section 8.4 / Host ; [Part1], Section 8.4
| If-Match ; [Part4], Section 7.2 / If-Match ; [Part4], Section 7.2
| If-Modified-Since ; [Part4], Section 7.3 / If-Modified-Since ; [Part4], Section 7.3
| If-None-Match ; [Part4], Section 7.4 / If-None-Match ; [Part4], Section 7.4
| If-Range ; [Part5], Section 6.3 / If-Range ; [Part5], Section 6.3
| If-Unmodified-Since ; [Part4], Section 7.5 / If-Unmodified-Since ; [Part4], Section 7.5
| Max-Forwards ; Section 10.5 / Max-Forwards ; Section 10.5
| Proxy-Authorization ; [Part7], Section 4.3 / Proxy-Authorization ; [Part7], Section 4.3
| Range ; [Part5], Section 6.4 / Range ; [Part5], Section 6.4
| Referer ; Section 10.6 / Referer ; Section 10.6
| TE ; [Part1], Section 8.8 / TE ; [Part1], Section 8.8
| User-Agent ; Section 10.9 / User-Agent ; Section 10.9
Request-header field names can be extended reliably only in Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request- experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as be request-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
5. Status Code and Reason Phrase 5. Status Code and Reason Phrase
skipping to change at page 11, line 7 skipping to change at page 11, line 7
or display the Reason-Phrase. or display the Reason-Phrase.
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without recommendations -- they MAY be replaced by local equivalents without
affecting the protocol. affecting the protocol.
Status-Code = Status-Code =
"100" ; Section 9.1.1: Continue "100" ; Section 9.1.1: Continue
| "101" ; Section 9.1.2: Switching Protocols / "101" ; Section 9.1.2: Switching Protocols
| "200" ; Section 9.2.1: OK / "200" ; Section 9.2.1: OK
| "201" ; Section 9.2.2: Created / "201" ; Section 9.2.2: Created
| "202" ; Section 9.2.3: Accepted / "202" ; Section 9.2.3: Accepted
| "203" ; Section 9.2.4: Non-Authoritative Information / "203" ; Section 9.2.4: Non-Authoritative Information
| "204" ; Section 9.2.5: No Content / "204" ; Section 9.2.5: No Content
| "205" ; Section 9.2.6: Reset Content / "205" ; Section 9.2.6: Reset Content
| "206" ; Section 9.2.7: Partial Content / "206" ; Section 9.2.7: Partial Content
| "300" ; Section 9.3.1: Multiple Choices / "300" ; Section 9.3.1: Multiple Choices
| "301" ; Section 9.3.2: Moved Permanently / "301" ; Section 9.3.2: Moved Permanently
| "302" ; Section 9.3.3: Found / "302" ; Section 9.3.3: Found
| "303" ; Section 9.3.4: See Other / "303" ; Section 9.3.4: See Other
| "304" ; Section 9.3.5: Not Modified / "304" ; Section 9.3.5: Not Modified
| "305" ; Section 9.3.6: Use Proxy / "305" ; Section 9.3.6: Use Proxy
| "307" ; Section 9.3.8: Temporary Redirect / "307" ; Section 9.3.8: Temporary Redirect
| "400" ; Section 9.4.1: Bad Request / "400" ; Section 9.4.1: Bad Request
| "401" ; Section 9.4.2: Unauthorized / "401" ; Section 9.4.2: Unauthorized
| "402" ; Section 9.4.3: Payment Required / "402" ; Section 9.4.3: Payment Required
| "403" ; Section 9.4.4: Forbidden / "403" ; Section 9.4.4: Forbidden
| "404" ; Section 9.4.5: Not Found / "404" ; Section 9.4.5: Not Found
| "405" ; Section 9.4.6: Method Not Allowed / "405" ; Section 9.4.6: Method Not Allowed
| "406" ; Section 9.4.7: Not Acceptable / "406" ; Section 9.4.7: Not Acceptable
| "407" ; Section 9.4.8: Proxy Authentication Required / "407" ; Section 9.4.8: Proxy Authentication Required
| "408" ; Section 9.4.9: Request Time-out / "408" ; Section 9.4.9: Request Time-out
| "409" ; Section 9.4.10: Conflict / "409" ; Section 9.4.10: Conflict
| "410" ; Section 9.4.11: Gone / "410" ; Section 9.4.11: Gone
| "411" ; Section 9.4.12: Length Required / "411" ; Section 9.4.12: Length Required
| "412" ; Section 9.4.13: Precondition Failed / "412" ; Section 9.4.13: Precondition Failed
| "413" ; Section 9.4.14: Request Entity Too Large / "413" ; Section 9.4.14: Request Entity Too Large
| "414" ; Section 9.4.15: Request-URI Too Large / "414" ; Section 9.4.15: Request-URI Too Large
| "415" ; Section 9.4.16: Unsupported Media Type / "415" ; Section 9.4.16: Unsupported Media Type
| "416" ; Section 9.4.17: Requested range not satisfiable / "416" ; Section 9.4.17: Requested range not satisfiable
| "417" ; Section 9.4.18: Expectation Failed / "417" ; Section 9.4.18: Expectation Failed
| "500" ; Section 9.5.1: Internal Server Error / "500" ; Section 9.5.1: Internal Server Error
| "501" ; Section 9.5.2: Not Implemented / "501" ; Section 9.5.2: Not Implemented
| "502" ; Section 9.5.3: Bad Gateway / "502" ; Section 9.5.3: Bad Gateway
| "503" ; Section 9.5.4: Service Unavailable / "503" ; Section 9.5.4: Service Unavailable
| "504" ; Section 9.5.5: Gateway Time-out / "504" ; Section 9.5.5: Gateway Time-out
| "505" ; Section 9.5.6: HTTP Version not supported / "505" ; Section 9.5.6: HTTP Version not supported
| extension-code / extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF> Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible. HTTP applications are not required HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
skipping to change at page 12, line 37 skipping to change at page 12, line 37
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
6. Response Header Fields 6. 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-URI. about further access to the resource identified by the Request-URI.
response-header = Accept-Ranges ; [Part5], Section 6.1 response-header = Accept-Ranges ; [Part5], Section 6.1
| Age ; [Part6], Section 16.1 / Age ; [Part6], Section 16.1
| Allow ; Section 10.1 / Allow ; Section 10.1
| ETag ; [Part4], Section 7.1 / ETag ; [Part4], Section 7.1
| Location ; Section 10.4 / Location ; Section 10.4
| Proxy-Authenticate ; [Part7], Section 4.2 / Proxy-Authenticate ; [Part7], Section 4.2
| Retry-After ; Section 10.7 / Retry-After ; Section 10.7
| Server ; Section 10.8 / Server ; Section 10.8
| Vary ; [Part6], Section 16.5 / Vary ; [Part6], Section 16.5
| WWW-Authenticate ; [Part7], Section 4.4 / WWW-Authenticate ; [Part7], Section 4.4
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response- experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as be response-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
7. Entity 7. Entity
skipping to change at page 15, line 19 skipping to change at page 15, line 19
this specification. The response body, if any, SHOULD also include this specification. The response body, if any, SHOULD also include
information about the communication options. The format for such a information about the communication options. The format for such a
body is not defined by this specification, but might be defined by body is not defined by this specification, but might be defined by
future extensions to HTTP. Content negotiation MAY be used to select future extensions to HTTP. Content negotiation MAY be used to select
the appropriate response format. If no response body is included, the appropriate response format. If no response body is included,
the response MUST include a Content-Length field with a field-value the response MUST include a Content-Length field with a field-value
of "0". of "0".
The Max-Forwards request-header field MAY be used to target a The Max-Forwards request-header field MAY be used to target a
specific proxy in the request chain. When a proxy receives an specific proxy in the request chain. When a proxy receives an
OPTIONS request on an absoluteURI for which request forwarding is OPTIONS request on an absolute-URI for which request forwarding is
permitted, the proxy MUST check for a Max-Forwards field. If the permitted, the proxy MUST check for a Max-Forwards field. If the
Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward
the message; instead, the proxy SHOULD respond with its own the message; instead, the proxy SHOULD respond with its own
communication options. If the Max-Forwards field-value is an integer communication options. If the Max-Forwards field-value is an integer
greater than zero, the proxy MUST decrement the field-value when it greater than zero, the proxy MUST decrement the field-value when it
forwards the request. If no Max-Forwards field is present in the forwards the request. If no Max-Forwards field is present in the
request, then the forwarded request MUST NOT include a Max-Forwards request, then the forwarded request MUST NOT include a Max-Forwards
field. field.
8.3. GET 8.3. GET
skipping to change at page 17, line 32 skipping to change at page 17, line 32
Request-URI does not point to an existing resource, and that URI is Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a agent, the origin server can create the resource with that URI. If a
new resource is created at the Request-URI, the origin server MUST new resource is created at the Request-URI, the origin server MUST
inform the user agent via the 201 (Created) response. If an existing inform the user agent via the 201 (Created) response. If an existing
resource is modified, either the 200 (OK) or 204 (No Content) resource is modified, either the 200 (OK) or 204 (No Content)
response codes SHOULD be sent to indicate successful completion of response codes SHOULD be sent to indicate successful completion of
the request. If the resource could not be created or modified with the request. If the resource could not be created or modified with
the Request-URI, an appropriate error response SHOULD be given that the Request-URI, an appropriate error response SHOULD be given that
reflects the nature of the problem. The recipient of the entity MUST reflects the nature of the problem. The recipient of the entity MUST
NOT ignore any Content-* (e.g. Content-Range) headers that it does NOT ignore any Content-* headers (headers starting with the prefix
not understand or implement and MUST return a 501 (Not Implemented) 'Content-') that it does not understand or implement and MUST return
response in such cases. a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Request-URI identifies If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be one or more currently cached entities, those entries SHOULD be
treated as stale. Responses to this method are not cacheable. treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway entity. That resource might be a data-accepting process, a gateway
to some other protocol, or a separate entity that accepts to some other protocol, or a separate entity that accepts
skipping to change at page 31, line 26 skipping to change at page 31, line 26
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to request and response semantics. fields related to request and response semantics.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
10.1. Allow 10.1. Allow
The Allow response-header field lists the set of methods advertised The response-header field "Allow" lists the set of methods advertised
as supported by the resource identified by the Request-URI. The as supported by the resource identified by the Request-URI. The
purpose of this field is strictly to inform the recipient of valid purpose of this field is strictly to inform the recipient of valid
methods associated with the resource. An Allow header field MUST be methods associated with the resource. An Allow header field MUST be
present in a 405 (Method Not Allowed) response. present in a 405 (Method Not Allowed) response.
Allow = "Allow" ":" #Method Allow = "Allow" ":" OWS Allow-v
Allow-v = #Method
Example of use: Example of use:
Allow: GET, HEAD, PUT Allow: GET, HEAD, PUT
The actual set of allowed methods is defined by the origin server at The actual set of allowed methods is defined by the origin server at
the time of each request. the time of each request.
A proxy MUST NOT modify the Allow header field even if it does not A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent might have understand all the methods specified, since the user agent might have
other means of communicating with the origin server. other means of communicating with the origin server.
10.2. Expect 10.2. Expect
The Expect request-header field is used to indicate that particular The request-header field "Expect" is used to indicate that particular
server behaviors are required by the client. server behaviors are required by the client.
Expect = "Expect" ":" 1#expectation Expect = "Expect" ":" OWS Expect-v
Expect-v = 1#expectation
expectation = "100-continue" | expectation-extension expectation = "100-continue" / expectation-extension
expectation-extension = token [ "=" ( token | quoted-string ) expectation-extension = token [ "=" ( token / quoted-string )
*expect-params ] *expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ] expect-params = ";" token [ "=" ( token / quoted-string ) ]
A server that does not understand or is unable to comply with any of A server that does not understand or is unable to comply with any of
the expectation values in the Expect field of a request MUST respond the expectation values in the Expect field of a request MUST respond
with appropriate error status. The server MUST respond with a 417 with appropriate error status. The server MUST respond with a 417
(Expectation Failed) status if any of the expectations cannot be met (Expectation Failed) status if any of the expectations cannot be met
or, if there are other problems with the request, some other 4xx or, if there are other problems with the request, some other 4xx
status. status.
This header field is defined with extensible syntax to allow for This header field is defined with extensible syntax to allow for
future extensions. If a server receives a request containing an future extensions. If a server receives a request containing an
skipping to change at page 32, line 42 skipping to change at page 32, line 43
request is forwarded. request is forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header. Expect header.
See Section 7.2.3 of [Part1] for the use of the 100 (Continue) See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
status. status.
10.3. From 10.3. From
The From request-header field, if given, SHOULD contain an Internet The request-header field "From", if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in Section 3.4 of [RFC2822]: in Section 3.4 of [RFC5322]:
From = "From" ":" mailbox
mailbox = <mailbox, defined in [RFC2822], Section 3.4> From = "From" ":" OWS From-v
From-v = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: webmaster@example.org
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
NOT be used as an insecure form of access protection. The NOT be used as an insecure form of access protection. The
interpretation of this field is that the request is being performed interpretation of this field is that the request is being performed
on behalf of the person given, who accepts responsibility for the on behalf of the person given, who accepts responsibility for the
method performed. In particular, robot agents SHOULD include this method performed. In particular, robot agents SHOULD include this
skipping to change at page 33, line 29 skipping to change at page 33, line 30
used. used.
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
10.4. Location 10.4. Location
The Location response-header field is used for the identification of The response-header field "Location" is used for the identification
a new resource or to redirect the recipient to a location other than of a new resource or to redirect the recipient to a location other
the Request-URI for completion of the request. For 201 (Created) than the Request-URI for completion of the request. For 201
responses, the Location is that of the new resource which was created (Created) responses, the Location is that of the new resource which
by the request. For 3xx responses, the location SHOULD indicate the was created by the request. For 3xx responses, the location SHOULD
server's preferred URI for automatic redirection to the resource. indicate the server's preferred URI for automatic redirection to the
The field value consists of a single absolute URI. resource. The field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI [ "#" fragment ] Location = "Location" ":" OWS Location-v
Location-v = absolute-URI [ "#" fragment ]
An example is: An example is:
Location: http://www.example.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html
Note: The Content-Location header field (Section 6.7 of [Part3]) Note: The Content-Location header field (Section 6.7 of [Part3])
differs from Location in that the Content-Location identifies the differs from Location in that the Content-Location identifies the
original location of the entity enclosed in the response. It is original location of the entity enclosed in the response. It is
therefore possible for a response to contain header fields for therefore possible for a response to contain header fields for
both Location and Content-Location. both Location and Content-Location.
skipping to change at page 34, line 16 skipping to change at page 34, line 17
header specifies the URL for the entire created resource. header specifies the URL for the entire created resource.
o With a 300 Multiple Choices, since the choice decision is intended o With a 300 Multiple Choices, since the choice decision is intended
to be made on resource characteristics and not fragment to be made on resource characteristics and not fragment
characteristics. characteristics.
o With 305 Use Proxy. o With 305 Use Proxy.
10.5. Max-Forwards 10.5. Max-Forwards
The Max-Forwards request-header field provides a mechanism with the The request-header "Max-Forwards" field provides a mechanism with the
TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
number of proxies or gateways that can forward the request to the number of proxies or gateways that can forward the request to the
next inbound server. This can be useful when the client is next inbound server. This can be useful when the client is
attempting to trace a request chain which appears to be failing or attempting to trace a request chain which appears to be failing or
looping in mid-chain. looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v
Max-Forwards-v = 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message may be forwarded. number of times this request message may be forwarded.
Each proxy or gateway recipient of a TRACE or OPTIONS request Each proxy or gateway recipient of a TRACE or OPTIONS request
containing a Max-Forwards header field MUST check and update its containing a Max-Forwards header field MUST check and update its
value prior to forwarding the request. If the received value is zero value prior to forwarding the request. If the received value is zero
(0), the recipient MUST NOT forward the request; instead, it MUST (0), the recipient MUST NOT forward the request; instead, it MUST
respond as the final recipient. If the received Max-Forwards value respond as the final recipient. If the received Max-Forwards value
is greater than zero, then the forwarded message MUST contain an is greater than zero, then the forwarded message MUST contain an
updated Max-Forwards field with a value decremented by one (1). updated Max-Forwards field with a value decremented by one (1).
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.
10.6. Referer 10.6. Referer
The Referer[sic] request-header field allows the client to specify, The request-header field "Referer" [sic] allows the client to
for the server's benefit, the address (URI) of the resource from specify, for the server's benefit, the address (URI) of the resource
which the Request-URI was obtained (the "referrer", although the from which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest, server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard. its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI ) Referer = "Referer" ":" OWS Referer-v
Referer-v = absolute-URI / relativeURI
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-URI. The URI MUST NOT include a fragment. relative to the Request-URI. The URI MUST NOT include a fragment.
See Section 12.2 for security considerations. See Section 12.2 for security considerations.
10.7. Retry-After 10.7. Retry-After
The Retry-After response-header field can be used with a 503 (Service The response-header "Retry-After" field can be used with a 503
Unavailable) response to indicate how long the service is expected to (Service Unavailable) response to indicate how long the service is
be unavailable to the requesting client. This field MAY also be used expected to be unavailable to the requesting client. This field MAY
with any 3xx (Redirection) response to indicate the minimum time the also be used with any 3xx (Redirection) response to indicate the
user-agent is asked wait before issuing the redirected request. The minimum time the user-agent is asked wait before issuing the
value of this field can be either an HTTP-date or an integer number redirected request. The value of this field can be either an HTTP-
of seconds (in decimal) after the time of the response. date or an integer number of seconds (in decimal) after the time of
the response.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) Retry-After = "Retry-After" ":" OWS Retry-After-v
Retry-After-v = HTTP-date / delta-seconds
Time spans are non-negative decimal integers, representing time in Time spans are non-negative decimal integers, representing time in
seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
10.8. Server 10.8. Server
The Server response-header field contains information about the The response-header field "Server" contains information about the
software used by the origin server to handle the request. The field software used by the origin server to handle the request. The field
can contain multiple product tokens (Section 3.5 of [Part1]) and can contain multiple product tokens (Section 3.5 of [Part1]) and
comments identifying the server and any significant subproducts. The comments identifying the server and any significant subproducts. The
product tokens are listed in order of their significance for product tokens are listed in order of their significance for
identifying the application. identifying the application.
Server = "Server" ":" 1*( product | comment ) Server = "Server" ":" OWS Server-v
Server-v = product
*( RWS ( product / comment ) )
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
MUST include a Via field (as described in Section 8.9 of [Part1]). MUST include a Via field (as described in Section 8.9 of [Part1]).
Note: Revealing the specific software version of the server might Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable implementors are encouraged to make this field a configurable
option. option.
10.9. User-Agent 10.9. User-Agent
The User-Agent request-header field contains information about the The request-header field "User-Agent" contains information about the
user agent originating the request. This is for statistical user agent originating the request. This is for statistical
purposes, the tracing of protocol violations, and automated purposes, the tracing of protocol violations, and automated
recognition of user agents for the sake of tailoring responses to recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include avoid particular user agent limitations. User agents SHOULD include
this field with requests. The field can contain multiple product this field with requests. The field can contain multiple product
tokens (Section 3.5 of [Part1]) and comments identifying the agent tokens (Section 3.5 of [Part1]) and comments identifying the agent
and any subproducts which form a significant part of the user agent. and any subproducts which form a significant part of the user agent.
By convention, the product tokens are listed in order of their By convention, the product tokens are listed in order of their
significance for identifying the application. significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment ) User-Agent = "User-Agent" ":" OWS User-Agent-v
User-Agent-v = product
*( RWS ( product / comment ) )
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
11. IANA Considerations 11. IANA Considerations
11.1. Method Registry 11.1. Method Registry
The registration procedure for HTTP Methods is defined by Section 3.1 The registration procedure for HTTP Methods is defined by Section 3.1
skipping to change at page 41, line 22 skipping to change at page 41, line 22
13. Acknowledgments 13. Acknowledgments
14. References 14. References
14.1. Normative References 14.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-04 and Message Parsing", draft-ietf-httpbis-p1-messaging-05
(work in progress), August 2008. (work in progress), November 2008.
[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-04 and Content Negotiation", draft-ietf-httpbis-p3-payload-05
(work in progress), August 2008. (work in progress), November 2008.
[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-04 (work in Requests", draft-ietf-httpbis-p4-conditional-05 (work in
progress), August 2008. progress), November 2008.
[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-04 (work Partial Responses", draft-ietf-httpbis-p5-range-05 (work
in progress), August 2008. in progress), November 2008.
[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", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-04 (work in progress), draft-ietf-httpbis-p6-cache-05 (work in progress),
August 2008. November 2008.
[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-04 (work in progress), draft-ietf-httpbis-p7-auth-05 (work in progress),
August 2008. November 2008.
[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.
14.2. Informative References 14.2. Informative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008.
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
A.1. Changes from RFC 2068 A.1. Changes from RFC 2068
Clarified which error code should be used for inbound server failures Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 9.5.5). (e.g. DNS failures). (Section 9.5.5).
201 (Created) had a race that required an Etag be sent when a 201 (Created) had a race that required an Etag be sent when a
resource is first created. (Section 9.2.2). resource is first created. (Section 9.2.2).
skipping to change at page 44, line 32 skipping to change at page 44, line 32
Appendix B. Change Log (to be removed by RFC Editor before publication) Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1. Since RFC2616 B.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
B.2. Since draft-ietf-httpbis-p2-semantics-00 B.2. Since draft-ietf-httpbis-p2-semantics-00
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
MUST" (<http://purl.org/NET/http-errata#via-must>) (<http://purl.org/NET/http-errata#via-must>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
allowed in Location" allowed in Location"
(<http://purl.org/NET/http-errata#location-fragments>) (<http://purl.org/NET/http-errata#location-fragments>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
Methods vs Redirection" vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
(<http://purl.org/NET/http-errata#saferedirect>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise o <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
description of the POST method" description of the POST method"
(<http://purl.org/NET/http-errata#post>) (<http://purl.org/NET/http-errata#post>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
and Informative references" Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
Compliance"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
"Informative references" Compliance"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
cross-references" cross-references"
Other changes: Other changes:
o Move definitions of 304 and 412 condition codes to [Part4] o Move definitions of 304 and 412 condition codes to [Part4]
B.3. Since draft-ietf-httpbis-p2-semantics-01 B.3. Since draft-ietf-httpbis-p2-semantics-01
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
effects" effects"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
Host header requirements" header requirements"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Copy definition of delta-seconds from Part6 instead of referencing o Copy definition of delta-seconds from Part6 instead of referencing
it. it.
B.4. Since draft-ietf-httpbis-p2-semantics-02 B.4. Since draft-ietf-httpbis-p2-semantics-02
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
Allow in 405 responses" Allow in 405 responses"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
Code Registry" Registry"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
"Redirection vs. Location" vs. Location"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>:
"Cacheability of 303 response"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use o <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
Proxy" of 303 response"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
"Classification for Allow header" "Classification for Allow header"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
'store under' vs 'store at'" under' vs 'store at'"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Registration
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header registrations for headers
defined in this document. defined in this document.
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(method). (method).
B.5. Since draft-ietf-httpbis-p2-semantics-03 B.5. Since draft-ietf-httpbis-p2-semantics-03
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
request bodies" request bodies"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/119>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
"Description of CONNECT should refer to RFC2817" of CONNECT should refer to RFC2817"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
Content-Location reference request/response mixup" Content-Location reference request/response mixup"
Ongoing work on Method Registry Ongoing work on Method Registry
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
o Added initial proposal for registration process, plus initial o Added initial proposal for registration process, plus initial
content (non-HTTP/1.1 methods to be added by a separate content (non-HTTP/1.1 methods to be added by a separate
specification). specification).
B.6. Since draft-ietf-httpbis-p2-semantics-04
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
updated by RFC 5322"
Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions.
Index Index
1 1
100 Continue (status code) 19 100 Continue (status code) 19
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) 20 201 Created (status code) 20
202 Accepted (status code) 21 202 Accepted (status code) 21
skipping to change at page 48, line 25 skipping to change at page 48, line 40
E E
Expect header 31 Expect header 31
F F
From header 32 From header 32
G G
GET method 15 GET method 15
Grammar Grammar
Allow 31 Allow 31
Allow-v 31
delta-seconds 35 delta-seconds 35
Expect 32 Expect 32
expect-params 32 expect-params 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 32 From 32
From-v 32
Location 33 Location 33
Location-v 33
Max-Forwards 34 Max-Forwards 34
Max-Forwards-v 34
Method 8 Method 8
Reason-Phrase 11 Reason-Phrase 11
Referer 34 Referer 35
Referer-v 35
request-header 9 request-header 9
response-header 12 response-header 12
Retry-After 35 Retry-After 35
Server 35 Retry-After-v 35
Server 36
Server-v 36
Status-Code 11 Status-Code 11
User-Agent 36 User-Agent 36
User-Agent-v 36
H H
HEAD method 16 HEAD method 16
Headers Headers
Allow 31 Allow 31
Expect 31 Expect 31
From 32 From 32
Location 33 Location 33
Max-Forwards 34 Max-Forwards 34
Referer 34 Referer 34
 End of changes. 80 change blocks. 
187 lines changed or deleted 226 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/