draft-ietf-httpbis-p2-semantics-08.txt   draft-ietf-httpbis-p2-semantics-09.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: April 29, 2010 HP Expires: September 9, 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
October 26, 2009 March 8, 2010
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-08 draft-ietf-httpbis-p2-semantics-09
Status of this Memo Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header
fields.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
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
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10.
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.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
skipping to change at page 2, line 4 skipping to change at page 2, line 16
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header
fields.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working
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
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 21 skipping to change at page 5, line 21
publication) . . . . . . . . . . . . . . . . . . . . 48 publication) . . . . . . . . . . . . . . . . . . . . 48
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
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 10, line 16 skipping to change at page 10, line 16
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. The status codes attempt to understand and satisfy the request. The status codes
listed below are defined in Section 8. The Reason-Phrase is intended listed below are defined in Section 8. The Reason-Phrase is intended
to give a short textual description of the Status-Code. The Status- to give a short textual description of the Status-Code. The Status-
Code is intended for use by automata and the Reason-Phrase is Code is intended for use by automata and the Reason-Phrase is
intended for the human user. The client is not required to examine intended for the human user. The client is not required to examine
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 values,
presented below. The reason phrases listed here are only are 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 8.1.1: Continue "100" ; Section 8.1.1: Continue
/ "101" ; Section 8.1.2: Switching Protocols / "101" ; Section 8.1.2: Switching Protocols
/ "200" ; Section 8.2.1: OK / "200" ; Section 8.2.1: OK
/ "201" ; Section 8.2.2: Created / "201" ; Section 8.2.2: Created
/ "202" ; Section 8.2.3: Accepted / "202" ; Section 8.2.3: Accepted
/ "203" ; Section 8.2.4: Non-Authoritative Information / "203" ; Section 8.2.4: Non-Authoritative Information
skipping to change at page 13, line 31 skipping to change at page 13, line 31
It is sometimes necessary to determine the identity of the resource It is sometimes necessary to determine the identity of the resource
associated with a representation. associated with a representation.
An HTTP request representation, when present, is always associated An HTTP request representation, when present, is always associated
with an anonymous (i.e., unidentified) resource. with an anonymous (i.e., unidentified) resource.
In the common case, an HTTP response is a representation of the In the common case, an HTTP response is a representation of the
resource located at the request-URI. However, this is not always the resource located at the request-URI. However, this is not always the
case. To determine the URI of the resource a response is associated case. To determine the URI of the resource a response is associated
with, the following rules are used (first match winning): with, the following rules are used (with the first applicable one
being selected):
1. If the response status code is 200 or 203 and the request method 1. If the response status code is 200 or 203 and the request method
was GET, the response is a representation of the resource at the was GET, the response is a representation of the resource at the
request-URI. request-URI.
2. If the response status is 204, 206, or 304 and the request method 2. If the response status is 204, 206, or 304 and the request method
was GET or HEAD, the response is a partial representation of the was GET or HEAD, the response is a partial representation of the
resource at the request-URI (see Section 2.7 of [Part6]). resource at the request-URI (see Section 2.7 of [Part6]).
3. If the response has a Content-Location header, and that URI is 3. If the response has a Content-Location header, and that URI is
the same as the request-URI [[anchor1: (see [ref])]], the the same as the request-URI [[TODO-missref-requri: (see [ref])]],
response is a representation of the resource at the request-URI. the response is a representation of the resource at the request-
URI.
4. If the response has a Content-Location header, and that URI is 4. If the response has a Content-Location header, and that URI is
not the same as the request-URI, the response asserts that it is not the same as the request-URI, the response asserts that it is
a representation of the resource at the Content-Location URI (but a representation of the resource at the Content-Location URI (but
it may not be). it may not be).
5. Otherwise, the response is a representation of an anonymous 5. Otherwise, the response is a representation of an anonymous
(i.e., unidentified) resource. (i.e., unidentified) resource.
[[TODO-req-uri: Note that 'request-URI' is used here; however, we [[TODO-req-uri: Note that "request-URI" is used here; however, we
need to come up with a term to denote "the URI that can be inferred need to come up with a term to denote "the URI that can be inferred
from examining the request-target and the Host header." (see from examining the request-target and the Host header." (see
<http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the <http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the
comparison function is going to have to be defined somewhere, because comparison function is going to have to be defined somewhere, because
we already need to compare URIs for things like cache invalidation.]] we already need to compare URIs for things like cache invalidation.]]
7. Method Definitions 7. Method Definitions
The set of common methods for HTTP/1.1 is defined below. Although The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to this set can be expanded, additional methods cannot be assumed to
skipping to change at page 16, line 14 skipping to change at page 16, line 14
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.
7.3. GET 7.3. GET
The GET method means retrieve whatever information (in the form of an The GET method means retrieve whatever information (in the form of an
entity) is identified by the request-target. If the request-target entity) currently corresponds to the resource identified by the
refers to a data-producing process, it is the produced data which request-target.
shall be returned as the entity in the response and not the source
text of the process, unless that text happens to be the output of the If the request-target identifies a data-producing process, it is the
process. produced data which shall be returned as the entity in the response
and not the source text of the process, unless that text happens to
be the output of the process.
The semantics of the GET method change to a "conditional GET" if the The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since, request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network conditional GET method is intended to reduce unnecessary network
usage by allowing cached entities to be refreshed without requiring usage by allowing cached entities to be refreshed without requiring
multiple requests or transferring data already held by the client. multiple requests or transferring data already held by the client.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
is capable of being defined as a new resource by the requesting user is 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-target, the origin server MUST new resource is created at the request-target, 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-target, an appropriate error response SHOULD be given the request-target, an appropriate error response SHOULD be given
that reflects the nature of the problem. The recipient of the entity that reflects the nature of the problem. The recipient of the entity
MUST NOT ignore any Content-* headers (headers starting with the MUST NOT ignore any Content-* headers (headers starting with the
prefix 'Content-') that it does not understand or implement and MUST prefix "Content-") that it does not understand or implement and MUST
return a 501 (Not Implemented) response in such cases. return a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the request-target If the request passes through a cache and the request-target
identifies one or more currently cached entities, those entries identifies one or more currently cached entities, those entries
SHOULD be treated as stale. Responses to this method are not SHOULD be treated as stale. Responses to this method are not
cacheable. 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-target. The URI in reflected in the different meaning of the request-target. The URI in
a POST request identifies the resource that will handle the enclosed a POST request identifies the resource that will handle the enclosed
skipping to change at page 20, line 8 skipping to change at page 20, line 8
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
If the request is valid, the response SHOULD contain the entire If the request is valid, the response SHOULD contain the entire
request message in the entity-body, with a Content-Type of "message/ request message in the entity-body, with a Content-Type of "message/
http" (see Section 10.3.1 of [Part1]). Responses to this method MUST http" (see Section 10.3.1 of [Part1]). Responses to this method MUST
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 any metainformation Each Status-Code is described below, including any metainformation
required in the response. required in the 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,
skipping to change at page 21, line 39 skipping to change at page 21, line 39
HEAD the entity-header fields corresponding to the requested HEAD the entity-header fields corresponding to the requested
resource are sent in the response without any message-body; resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action; POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the TRACE an entity containing the request message as received by the
end server. end server.
8.2.2. 201 Created 8.2.2. 201 Created
The request has been fulfilled and resulted in a new resource being The request has been fulfilled and has resulted in a new resource
created. The newly created resource can be referenced by the URI(s) being created. The newly created resource can be referenced by the
returned in the entity of the response, with the most specific URI URI(s) returned in the entity of the response, with the most specific
for the resource given by a Location header field. The response URI for the resource given by a Location header field. The response
SHOULD include an entity containing a list of resource SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The entity format is specified by choose the one most appropriate. The entity format is specified by
the media type given in the Content-Type header field. The origin the media type given in the Content-Type header field. The origin
server MUST create the resource before returning the 201 status code. server MUST create the resource before returning the 201 status code.
If the action cannot be carried out immediately, the server SHOULD If the action cannot be carried out immediately, the server SHOULD
respond with 202 (Accepted) response instead. respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag for the requested variant just the current value of the entity tag for the requested variant just
skipping to change at page 23, line 26 skipping to change at page 23, line 26
The server has fulfilled the partial GET request for the resource and The server has fulfilled the partial GET request for the resource and
the enclosed entity is a partial representation as defined in Section the enclosed entity is a partial representation as defined in Section
3.1 of [Part5]. 3.1 of [Part5].
8.3. Redirection 3xx 8.3. Redirection 3xx
This class of status code indicates that further action needs to be This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request is with the user if and only if the method used in the second request is
GET or HEAD. A client SHOULD detect infinite redirection loops, known to be "safe", as defined in Section 7.1.1. A client SHOULD
since such loops generate network traffic for each redirection. detect infinite redirection loops, since such loops generate network
traffic for each redirection.
Note: an earlier version of this specification recommended a Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content maximum of five redirections ([RFC2068], Section 10.3). Content
developers should be aware that there might be clients that developers should be aware that there might be clients that
implement such a fixed limitation. implement such a fixed limitation.
8.3.1. 300 Multiple Choices 8.3.1. 300 Multiple Choices
The requested resource corresponds to any one of a set of The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent- representations, each with its own specific location, and agent-
driven negotiation information (Section 4 of [Part3]) is being driven negotiation information (Section 4 of [Part3]) is being
provided so that the user (or user agent) can select a preferred provided so that the user (or user agent) can select a preferred
skipping to change at page 31, line 39 skipping to change at page 31, line 39
Retry-After header. If no Retry-After is given, the client SHOULD Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response. handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may server must use it when becoming overloaded. Some servers may
wish to simply refuse the connection. wish to simply refuse the connection.
8.5.5. 504 Gateway Timeout 8.5.5. 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a The server, while acting as a gateway or proxy, did not receive a
timely response from the upstream server specified by the URI (e.g. timely response from the upstream server specified by the URI (e.g.,
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
to access in attempting to complete the request. to access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to Note to implementors: some deployed proxies are known to return
return 400 or 500 when DNS lookups time out. 400 or 500 when DNS lookups time out.
8.5.6. 505 HTTP Version Not Supported 8.5.6. 505 HTTP Version Not Supported
The server does not support, or refuses to support, the protocol The server does not support, or refuses to support, the protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in Section using the same major version as the client, as described in Section
2.5 of [Part1], other than with this error message. The response 2.5 of [Part1], other than with this error message. The response
SHOULD contain an entity describing why that version is not supported SHOULD contain an entity describing why that version is not supported
and what other protocols are supported by that server. and what other protocols are supported by that server.
skipping to change at page 42, line 22 skipping to change at page 42, line 22
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-08 and Message Parsing", draft-ietf-httpbis-p1-messaging-09
(work in progress), October 2009. (work in progress), March 2010.
[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-08 and Content Negotiation", draft-ietf-httpbis-p3-payload-09
(work in progress), October 2009. (work in progress), March 2010.
[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-08 (work in Requests", draft-ietf-httpbis-p4-conditional-09 (work in
progress), October 2009. progress), March 2010.
[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-08 (work Partial Responses", draft-ietf-httpbis-p5-range-09 (work
in progress), October 2009. in progress), March 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
progress), October 2009. progress), March 2010.
[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-08 (work in progress), draft-ietf-httpbis-p7-auth-09 (work in progress),
October 2009. March 2010.
[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 43, line 46 skipping to change at page 43, line 46
May 2008. May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. 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 8.5.5). (e.g., DNS failures). (Section 8.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 8.2.2). resource is first created. (Section 8.2.2).
303 (See Also) and 307 (Temporary Redirect) added to address user 303 (See Also) and 307 (Temporary Redirect) added to address user
agent failure to implement status code 302 properly. (Section 8.3.4 agent failure to implement status code 302 properly. (Section 8.3.4
and 8.3.8) and 8.3.8)
Rewrite of message transmission requirements to make it much harder Rewrite of message transmission requirements to make it much harder
for implementors to get it wrong, as the consequences of errors here for implementors to get it wrong, as the consequences of errors here
skipping to change at page 52, line 19 skipping to change at page 52, line 19
Location vs status 303" Location vs status 303"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes" registrations for optional status codes"
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
and TRACE safe?" and TRACE safe?"
C.10. Since draft-ietf-httpbis-p2-semantics-08
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
vs Redirection" (we missed the introduction to the 3xx status
codes when fixing this previously)
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) 21 200 OK (status code) 21
201 Created (status code) 21 201 Created (status code) 21
202 Accepted (status code) 22 202 Accepted (status code) 22
 End of changes. 32 change blocks. 
79 lines changed or deleted 99 lines changed or added

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