draft-ietf-httpbis-p2-semantics-09.txt   draft-ietf-httpbis-p2-semantics-10.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) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: September 9, 2010 HP Expires: January 13, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 8, 2010 July 12, 2010
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-09 draft-ietf-httpbis-p2-semantics-10
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://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10. The changes in this draft are summarized in Appendix C.11.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 26 skipping to change at page 3, line 19
4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10
4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12
5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12
6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Identifying the Resource Associated with a 6.1. Identifying the Resource Associated with a
Representation . . . . . . . . . . . . . . . . . . . . . . 13 Representation . . . . . . . . . . . . . . . . . . . . . . 13
7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14
7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14
7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14
7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20
8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20
8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 40 skipping to change at page 4, line 34
8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31
8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32
9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35
9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36
9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38
10.3. Message Header Registration . . . . . . . . . . . . . . . 39 10.3. Message Header Registration . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . . 43
skipping to change at page 5, line 22 skipping to change at page 5, line 16
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 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
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
document defines the commonly agreed upon semantics of the HTTP document defines the commonly agreed upon semantics of the HTTP
uniform interface, the intentions defined by each request method, and uniform interface, the intentions defined by each request method, and
skipping to change at page 6, line 34 skipping to change at page 6, line 34
current mess reflects how widely dispersed these topics and current mess reflects how widely dispersed these topics and
associated requirements had become in [RFC2616]. associated requirements had become in [RFC2616].
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the "MUST" or
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".
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule rule). Appendix B shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
skipping to change at page 7, line 27 skipping to change at page 7, line 27
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
comment = <comment, defined in [Part1], Section 3.2> comment = <comment, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 2.6> Host = <Host, defined in [Part1], Section 2.6>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
product = <product, defined in [Part1], Section 6.3> product = <product, defined in [Part1], Section 6.3>
TE = <TE, defined in [Part1], Section 9.8> TE = <TE, defined in [Part1], Section 9.5>
URI = <URI, defined in [Part1], Section 2.6> URI-reference = <URI-reference, defined in [Part1], Section 2.6>
Accept = <Accept, defined in [Part3], Section 5.1> Accept = <Accept, defined in [Part3], Section 5.1>
Accept-Charset = Accept-Charset =
<Accept-Charset, defined in [Part3], Section 5.2> <Accept-Charset, defined in [Part3], Section 5.2>
Accept-Encoding = Accept-Encoding =
<Accept-Encoding, defined in [Part3], Section 5.3> <Accept-Encoding, defined in [Part3], Section 5.3>
Accept-Language = Accept-Language =
<Accept-Language, defined in [Part3], Section 5.4> <Accept-Language, defined in [Part3], Section 5.4>
ETag = <ETag, defined in [Part4], Section 6.1> ETag = <ETag, defined in [Part4], Section 6.1>
skipping to change at page 8, line 18 skipping to change at page 8, line 18
Proxy-Authenticate = Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 3.2> <Proxy-Authenticate, defined in [Part7], Section 3.2>
Proxy-Authorization = Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 3.3> <Proxy-Authorization, defined in [Part7], Section 3.3>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 3.4> <WWW-Authenticate, defined in [Part7], Section 3.4>
2. Method 2. 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-target. The method is case-sensitive. identified by the Effective Request URI (Section 4.3 of [Part1]).
The method is case-sensitive.
Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2
/ %x47.45.54 ; "GET", Section 7.3 / %x47.45.54 ; "GET", Section 7.3
/ %x48.45.41.44 ; "HEAD", Section 7.4 / %x48.45.41.44 ; "HEAD", Section 7.4
/ %x50.4F.53.54 ; "POST", Section 7.5 / %x50.4F.53.54 ; "POST", Section 7.5
/ %x50.55.54 ; "PUT", Section 7.6 / %x50.55.54 ; "PUT", Section 7.6
/ %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7
/ %x54.52.41.43.45 ; "TRACE", Section 7.8 / %x54.52.41.43.45 ; "TRACE", Section 7.8
/ %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9 / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9
/ extension-method / extension-method
skipping to change at page 9, line 42 skipping to change at page 9, line 42
/ Host ; [Part1], Section 9.4 / Host ; [Part1], Section 9.4
/ If-Match ; [Part4], Section 6.2 / If-Match ; [Part4], Section 6.2
/ If-Modified-Since ; [Part4], Section 6.3 / If-Modified-Since ; [Part4], Section 6.3
/ If-None-Match ; [Part4], Section 6.4 / If-None-Match ; [Part4], Section 6.4
/ If-Range ; [Part5], Section 5.3 / If-Range ; [Part5], Section 5.3
/ If-Unmodified-Since ; [Part4], Section 6.5 / If-Unmodified-Since ; [Part4], Section 6.5
/ Max-Forwards ; Section 9.5 / Max-Forwards ; Section 9.5
/ Proxy-Authorization ; [Part7], Section 3.3 / Proxy-Authorization ; [Part7], Section 3.3
/ Range ; [Part5], Section 5.4 / Range ; [Part5], Section 5.4
/ Referer ; Section 9.6 / Referer ; Section 9.6
/ TE ; [Part1], Section 9.8 / TE ; [Part1], Section 9.5
/ User-Agent ; Section 9.9 / User-Agent ; Section 9.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.
4. Status Code and Reason Phrase 4. Status Code and Reason Phrase
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, Section 3 of [Part4], Section
to give a short textual description of the Status-Code. The Status- 3 of [Part5], and Section 2 of [Part7].
Code is intended for use by automata and the Reason-Phrase is
intended for the human user. The client is not required to examine The Reason-Phrase is intended to give a short textual description of
or display the Reason-Phrase. the Status-Code. The Status-Code is intended for use by automata and
the Reason-Phrase is intended for the human user. The client is not
required to examine 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 values, HTTP/1.1, and an example set of corresponding Reason-Phrase values,
are 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
/ "204" ; Section 8.2.5: No Content / "204" ; Section 8.2.5: No Content
/ "205" ; Section 8.2.6: Reset Content / "205" ; Section 8.2.6: Reset Content
/ "206" ; [Part5], Section 3.1: Partial Content / "206" ; [Part5], Section 3.1: Partial Content
/ "300" ; Section 8.3.1: Multiple Choices / "300" ; Section 8.3.1: Multiple Choices
/ "301" ; Section 8.3.2: Moved Permanently / "301" ; Section 8.3.2: Moved Permanently
/ "302" ; Section 8.3.3: Found / "302" ; Section 8.3.3: Found
/ "303" ; Section 8.3.4: See Other / "303" ; Section 8.3.4: See Other
/ "304" ; [Part4], Section 3.1: Not Modified / "304" ; [Part4], Section 3.1: Not Modified
/ "305" ; Section 8.3.6: Use Proxy / "305" ; Section 8.3.6: Use Proxy
/ "307" ; Section 8.3.8: Temporary Redirect / "307" ; Section 8.3.8: Temporary Redirect
/ "400" ; Section 8.4.1: Bad Request / "400" ; Section 8.4.1: Bad Request
/ "401" ; [Part7], Section 2.1: Unauthorized / "401" ; [Part7], Section 2.1: Unauthorized
/ "402" ; Section 8.4.3: Payment Required / "402" ; Section 8.4.3: Payment Required
/ "403" ; Section 8.4.4: Forbidden / "403" ; Section 8.4.4: Forbidden
/ "404" ; Section 8.4.5: Not Found / "404" ; Section 8.4.5: Not Found
/ "405" ; Section 8.4.6: Method Not Allowed / "405" ; Section 8.4.6: Method Not Allowed
/ "406" ; Section 8.4.7: Not Acceptable / "406" ; Section 8.4.7: Not Acceptable
/ "407" ; [Part7], Section 2.2: Proxy Authentication Required / "407" ; [Part7], Section 2.2: Proxy Authentication Required
/ "408" ; Section 8.4.9: Request Time-out / "408" ; Section 8.4.9: Request Time-out
/ "409" ; Section 8.4.10: Conflict / "409" ; Section 8.4.10: Conflict
/ "410" ; Section 8.4.11: Gone / "410" ; Section 8.4.11: Gone
/ "411" ; Section 8.4.12: Length Required / "411" ; Section 8.4.12: Length Required
/ "412" ; [Part4], Section 3.2: Precondition Failed / "412" ; [Part4], Section 3.2: Precondition Failed
/ "413" ; Section 8.4.14: Request Entity Too Large / "413" ; Section 8.4.14: Request Entity Too Large
/ "414" ; Section 8.4.15: URI Too Long / "414" ; Section 8.4.15: URI Too Long
/ "415" ; Section 8.4.16: Unsupported Media Type / "415" ; Section 8.4.16: Unsupported Media Type
/ "416" ; status-416;: Requested range not satisfiable / "416" ; [Part5], Section 3.2: Requested range not satisfiable
/ "417" ; Section 8.4.18: Expectation Failed / "417" ; Section 8.4.18: Expectation Failed
/ "500" ; Section 8.5.1: Internal Server Error / "500" ; Section 8.5.1: Internal Server Error
/ "501" ; Section 8.5.2: Not Implemented / "501" ; Section 8.5.2: Not Implemented
/ "502" ; Section 8.5.3: Bad Gateway / "502" ; Section 8.5.3: Bad Gateway
/ "503" ; Section 8.5.4: Service Unavailable / "503" ; Section 8.5.4: Service Unavailable
/ "504" ; Section 8.5.5: Gateway Time-out / "504" ; Section 8.5.5: Gateway Time-out
/ "505" ; Section 8.5.6: HTTP Version not supported / "505" ; Section 8.5.6: HTTP Version not supported
/ extension-code / extension-code
extension-code = 3DIGIT extension-code = 3DIGIT
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
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 32 skipping to change at page 12, line 32
([RFC5226], Section 4.1). ([RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
5. Response Header Fields 5. Response Header Fields
The response-header fields allow the server to pass additional The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and Line. These header fields give information about the server and
about further access to the resource identified by the request- about further access to the resource identified by the Effective
target. Request URI (Section 4.3 of [Part1]).
response-header = Accept-Ranges ; [Part5], Section 5.1 response-header = Accept-Ranges ; [Part5], Section 5.1
/ Age ; [Part6], Section 3.1 / Age ; [Part6], Section 3.1
/ Allow ; Section 9.1 / Allow ; Section 9.1
/ ETag ; [Part4], Section 6.1 / ETag ; [Part4], Section 6.1
/ Location ; Section 9.4 / Location ; Section 9.4
/ Proxy-Authenticate ; [Part7], Section 3.2 / Proxy-Authenticate ; [Part7], Section 3.2
/ Retry-After ; Section 9.7 / Retry-After ; Section 9.7
/ Server ; Section 9.8 / Server ; Section 9.8
/ Vary ; [Part6], Section 3.5 / Vary ; [Part6], Section 3.5
skipping to change at page 13, line 29 skipping to change at page 13, line 28
6.1. Identifying the Resource Associated with a Representation 6.1. Identifying the Resource Associated with a Representation
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 Effective Request URI (see Section 4.3 of
case. To determine the URI of the resource a response is associated [Part1]). However, this is not always the case. To determine the
with, the following rules are used (with the first applicable one URI of the resource a response is associated with, the following
being selected): 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. Effective 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 Effective Request URI (see Section 2.8 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 [[TODO-missref-requri: (see [ref])]], the same as the Effective Request URI, the response is a
the response is a representation of the resource at the request- representation of the resource at the Effective Request URI.
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 Effective Request URI, the response asserts
a representation of the resource at the Content-Location URI (but that it is a representation of the resource at the Content-
it may not be). Location URI (but 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: The comparison function is going to have to be
need to come up with a term to denote "the URI that can be inferred defined somewhere, because we already need to compare URIs for things
from examining the request-target and the Host header." (see like cache invalidation.]]
<http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the
comparison function is going to have to be defined somewhere, because
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
share the same semantics for separately extended clients and servers. share the same semantics for separately extended clients and servers.
7.1. Safe and Idempotent Methods 7.1. Safe and Idempotent Methods
7.1.1. Safe Methods 7.1.1. Safe Methods
skipping to change at page 15, line 10 skipping to change at page 14, line 52
identical requests is the same as for a single request. The methods identical requests is the same as for a single request. The methods
PUT, DELETE, and all safe methods are idempotent. It is important to PUT, DELETE, and all safe methods are idempotent. It is important to
note that idempotence refers only to changes requested by the client: note that idempotence refers only to changes requested by the client:
a server is free to change its state due to multiple requests for the a server is free to change its state due to multiple requests for the
purpose of tracking those requests, versioning of results, etc. purpose of tracking those requests, versioning of results, etc.
7.2. OPTIONS 7.2. OPTIONS
The OPTIONS method represents a request for information about the The OPTIONS method represents a request for information about the
communication options available on the request/response chain communication options available on the request/response chain
identified by the request-target. This method allows the client to identified by the Effective Request URI. This method allows the
determine the options and/or requirements associated with a resource, client to determine the options and/or requirements associated with a
or the capabilities of a server, without implying a resource action resource, or the capabilities of a server, without implying a
or initiating a resource retrieval. resource action or initiating a resource retrieval.
Responses to this method are not cacheable. Responses to this method are not cacheable.
If the OPTIONS request includes an entity-body (as indicated by the If the OPTIONS request includes an entity-body (as indicated by the
presence of Content-Length or Transfer-Encoding), then the media type presence of Content-Length or Transfer-Encoding), then the media type
MUST be indicated by a Content-Type field. Although this MUST be indicated by a Content-Type field. Although this
specification does not define any use for such a body, future specification does not define any use for such a body, future
extensions to HTTP might use the OPTIONS body to make more detailed extensions to HTTP might use the OPTIONS body to make more detailed
queries on the server. queries on the server.
skipping to change at page 16, line 15 skipping to change at page 16, line 9
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) currently corresponds to the resource identified by the entity) currently corresponds to the resource identified by the
request-target. Effective Request URI.
If the request-target identifies a data-producing process, it is the If the Effective Request URI identifies a data-producing process, it
produced data which shall be returned as the entity in the response is the produced data which shall be returned as the entity in the
and not the source text of the process, unless that text happens to response and not the source text of the process, unless that text
be the output of the process. 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 17, line 18 skipping to change at page 17, line 11
previously cached entity from that resource. If the new field values previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as or Last-Modified), then the cache MUST treat the cache entry as
stale. stale.
7.5. POST 7.5. POST
The POST method is used to request that the origin server accept the The POST method is used to request that the origin server accept the
entity enclosed in the request as data to be processed by the entity enclosed in the request as data to be processed by the
resource identified by the request-target in the Request-Line. POST resource identified by the Effective Request URI. POST is designed
is designed to allow a uniform method to cover the following to allow a uniform method to cover the following functions:
functions:
o Annotation of existing resources; o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles; similar group of articles;
o Providing a block of data, such as the result of submitting a o Providing a block of data, such as the result of submitting a
form, to a data-handling process; form, to a data-handling process;
o Extending a database through an append operation. o Extending a database through an append operation.
The actual function performed by the POST method is determined by the The actual function performed by the POST method is determined by the
server and is usually dependent on the request-target. server and is usually dependent on the Effective Request URI.
The action performed by the POST method might not result in a The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200 resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status, (OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that depending on whether or not the response includes an entity that
describes the result. describes the result.
If a resource has been created on the origin server, the response If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location status of the request and refers to the new resource, and a Location
header (see Section 9.4). header (see Section 9.4).
Responses to this method are not cacheable, unless the response Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. includes appropriate Cache-Control or Expires header fields.
However, the 303 (See Other) response can be used to direct the user However, the 303 (See Other) response can be used to direct the user
agent to retrieve a cacheable resource. agent to retrieve a cacheable resource.
7.6. PUT 7.6. PUT
The PUT method requests that the enclosed entity be stored at the The PUT method requests that the enclosed entity be stored at the
supplied request-target. If the request-target refers to an already Effective Request URI. If the Effective Request URI refers to an
existing resource, the enclosed entity SHOULD be considered as a already existing resource, the enclosed entity SHOULD be considered
modified version of the one residing on the origin server. If the as a modified version of the one residing on the origin server.
request-target does not point to an existing resource, and that URI Otherwise, if the Effective Request URI does not point to an existing
is capable of being defined as a new resource by the requesting user resource, and that URI is capable of being defined as a new resource
agent, the origin server can create the resource with that URI. If a by the requesting user agent, the origin server can create the
new resource is created at the request-target, the origin server MUST resource with that URI.
inform the user agent via the 201 (Created) response. If an existing
resource is modified, either the 200 (OK) or 204 (No Content)
response codes SHOULD be sent to indicate successful completion of
the request. If the resource could not be created or modified with
the request-target, an appropriate error response SHOULD be given
that reflects the nature of the problem. The recipient of the entity
MUST NOT ignore any Content-* headers (headers starting with the
prefix "Content-") that it does not understand or implement and MUST
return a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the request-target If a new resource is created at the Effective Request URI, the origin
server MUST inform the user agent via the 201 (Created) response. If
an existing resource is modified, either the 200 (OK) or 204 (No
Content) response codes SHOULD be sent to indicate successful
completion of the request.
If the resource could not be created or modified with the Effective
Request URI, an appropriate error response SHOULD be given that
reflects the nature of the problem. The recipient of the entity MUST
NOT ignore any Content-* headers (headers starting with the prefix
"Content-") that it does not understand or implement and MUST return
a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Effective Request URI
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 Effective Request URI. The
a POST request identifies the resource that will handle the enclosed URI in a POST request identifies the resource that will handle the
entity. That resource might be a data-accepting process, a gateway enclosed entity. That resource might be a data-accepting process, a
to some other protocol, or a separate entity that accepts gateway to some other protocol, or a separate entity that accepts
annotations. In contrast, the URI in a PUT request identifies the annotations. In contrast, the URI in a PUT request identifies the
entity enclosed with the request -- the user agent knows what URI is entity enclosed with the request -- the user agent knows what URI is
intended and the server MUST NOT attempt to apply the request to some intended and the server MUST NOT attempt to apply the request to some
other resource. If the server desires that the request be applied to other resource. If the server desires that the request be applied to
a different URI, it MUST send a 301 (Moved Permanently) response; the a different URI, it MUST send a 301 (Moved Permanently) response; the
user agent MAY then make its own decision regarding whether or not to user agent MAY then make its own decision regarding whether or not to
redirect the request. redirect the request.
A single resource MAY be identified by many different URIs. For A single resource MAY be identified by many different URIs. For
example, an article might have a URI for identifying "the current example, an article might have a URI for identifying "the current
skipping to change at page 19, line 10 skipping to change at page 19, line 8
HTTP/1.1 does not define how a PUT method affects the state of an HTTP/1.1 does not define how a PUT method affects the state of an
origin server. origin server.
Unless otherwise specified for a particular entity-header, the Unless otherwise specified for a particular entity-header, the
entity-headers in the PUT request SHOULD be applied to the resource entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT. created or modified by the PUT.
7.7. DELETE 7.7. DELETE
The DELETE method requests that the origin server delete the resource The DELETE method requests that the origin server delete the resource
identified by the request-target. This method MAY be overridden by identified by the Effective Request URI. This method MAY be
human intervention (or other means) on the origin server. The client overridden by human intervention (or other means) on the origin
cannot be guaranteed that the operation has been carried out, even if server. The client cannot be guaranteed that the operation has been
the status code returned from the origin server indicates that the carried out, even if the status code returned from the origin server
action has been completed successfully. However, the server SHOULD indicates that the action has been completed successfully. However,
NOT indicate success unless, at the time the response is given, it the server SHOULD NOT indicate success unless, at the time the
intends to delete the resource or move it to an inaccessible response is given, it intends to delete the resource or move it to an
location. inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an A successful response SHOULD be 200 (OK) if the response includes an
entity describing the status, 202 (Accepted) if the action has not entity describing the status, 202 (Accepted) if the action has not
yet been enacted, or 204 (No Content) if the action has been enacted yet been enacted, or 204 (No Content) if the action has been enacted
but the response does not include an entity. but the response does not include an entity.
If the request passes through a cache and the request-target If the request passes through a cache and the Effective Request URI
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.
7.8. TRACE 7.8. TRACE
The TRACE method is used to invoke a remote, application-layer loop- The TRACE method is used to invoke a remote, application-layer loop-
back of the request message. The final recipient of the request back of the request message. The final recipient of the request
SHOULD reflect the message received back to the client as the entity- SHOULD reflect the message received back to the client as the entity-
body of a 200 (OK) response. The final recipient is either the body of a 200 (OK) response. The final recipient is either the
skipping to change at page 20, line 51 skipping to change at page 20, line 51
been received and has not yet been rejected by the server. The been received and has not yet been rejected by the server. The
client SHOULD continue by sending the remainder of the request or, if client SHOULD continue by sending the remainder of the request or, if
the request has already been completed, ignore this response. The the request has already been completed, ignore this response. The
server MUST send a final response after the request has been server MUST send a final response after the request has been
completed. See Section 7.2.3 of [Part1] for detailed discussion of completed. See Section 7.2.3 of [Part1] for detailed discussion of
the use and handling of this status code. the use and handling of this status code.
8.1.2. 101 Switching Protocols 8.1.2. 101 Switching Protocols
The server understands and is willing to comply with the client's The server understands and is willing to comply with the client's
request, via the Upgrade message header field (Section 5.4 of request, via the Upgrade message header field (Section 9.8 of
[Part1]), for a change in the application protocol being used on this
[Part5]), for a change in the application protocol being used on this
connection. The server will switch protocols to those defined by the connection. The server will switch protocols to those defined by the
response's Upgrade header field immediately after the empty line response's Upgrade header field immediately after the empty line
which terminates the 101 response. which terminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to do The protocol SHOULD be switched only when it is advantageous to do
so. For example, switching to a newer version of HTTP is so. For example, switching to a newer version of HTTP is
advantageous over older versions, and switching to a real-time, advantageous over older versions, and switching to a real-time,
synchronous protocol might be advantageous when delivering resources synchronous protocol might be advantageous when delivering resources
that use such features. that use such features.
skipping to change at page 24, line 13 skipping to change at page 24, line 13
If the server has a preferred choice of representation, it SHOULD If the server has a preferred choice of representation, it SHOULD
include the specific URI for that representation in the Location include the specific URI for that representation in the Location
field; user agents MAY use the Location field value for automatic field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise. redirection. This response is cacheable unless indicated otherwise.
8.3.2. 301 Moved Permanently 8.3.2. 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically URIs. Clients with link editing capabilities ought to automatically
re-link references to the request-target to one or more of the new re-link references to the Effective Request URI to one or more of the
references returned by the server, where possible. This response is new references returned by the server, where possible. This response
cacheable unless indicated otherwise. is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 301 status code is received in response to a request method If the 301 status code is received in response to a request method
that is known to be "safe", as defined in Section 7.1.1, then the that is known to be "safe", as defined in Section 7.1.1, then the
request MAY be automatically redirected by the user agent without request MAY be automatically redirected by the user agent without
confirmation. Otherwise, the user agent MUST NOT automatically confirmation. Otherwise, the user agent MUST NOT automatically
skipping to change at page 24, line 37 skipping to change at page 24, line 37
this might change the conditions under which the request was issued. this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request. will erroneously change it into a GET request.
8.3.3. 302 Found 8.3.3. 302 Found
The requested resource resides temporarily under a different URI. The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD Since the redirection might be altered on occasion, the client SHOULD
continue to use the request-target for future requests. This continue to use the Effectice Request URI for future requests. This
response is only cacheable if indicated by a Cache-Control or Expires response is only cacheable if indicated by a Cache-Control or Expires
header field. header field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 302 status code is received in response to a request method If the 302 status code is received in response to a request method
that is known to be "safe", as defined in Section 7.1.1, then the that is known to be "safe", as defined in Section 7.1.1, then the
skipping to change at page 26, line 19 skipping to change at page 26, line 19
8.3.7. 306 (Unused) 8.3.7. 306 (Unused)
The 306 status code was used in a previous version of the The 306 status code was used in a previous version of the
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
8.3.8. 307 Temporary Redirect 8.3.8. 307 Temporary Redirect
The requested resource resides temporarily under a different URI. The requested resource resides temporarily under a different URI.
Since the redirection MAY be altered on occasion, the client SHOULD Since the redirection MAY be altered on occasion, the client SHOULD
continue to use the request-target for future requests. This continue to use the Effective Request URI for future requests. This
response is only cacheable if indicated by a Cache-Control or Expires response is only cacheable if indicated by a Cache-Control or Expires
header field. header field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the understand the 307 status. Therefore, the note SHOULD contain the
information necessary for a user to repeat the original request on information necessary for a user to repeat the original request on
the new URI. the new URI.
skipping to change at page 27, line 34 skipping to change at page 27, line 34
The server understood the request, but is refusing to fulfill it. The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404 make this information available to the client, the status code 404
(Not Found) can be used instead. (Not Found) can be used instead.
8.4.5. 404 Not Found 8.4.5. 404 Not Found
The server has not found anything matching the request-target. No The server has not found anything matching the Effective Request URI.
indication is given of whether the condition is temporary or No indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address. resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other reveal exactly why the request has been refused, or when no other
response is applicable. response is applicable.
8.4.6. 405 Method Not Allowed 8.4.6. 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the The method specified in the Request-Line is not allowed for the
resource identified by the request-target. The response MUST include resource identified by the Effective Request URI. The response MUST
an Allow header containing a list of valid methods for the requested include an Allow header containing a list of valid methods for the
resource. requested resource.
8.4.7. 406 Not Acceptable 8.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable response entities which have content characteristics not acceptable
according to the accept headers sent in the request. according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s) containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most from which the user or user agent can choose the one most
skipping to change at page 29, line 19 skipping to change at page 29, line 19
to indicate that it can't complete the request. In this case, the to indicate that it can't complete the request. In this case, the
response entity would likely contain a list of the differences response entity would likely contain a list of the differences
between the two versions in a format defined by the response Content- between the two versions in a format defined by the response Content-
Type. Type.
8.4.11. 410 Gone 8.4.11. 410 Gone
The requested resource is no longer available at the server and no The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be forwarding address is known. This condition is expected to be
considered permanent. Clients with link editing capabilities SHOULD considered permanent. Clients with link editing capabilities SHOULD
delete references to the request-target after user approval. If the delete references to the Effective Request URI after user approval.
server does not know, or has no facility to determine, whether or not If the server does not know, or has no facility to determine, whether
the condition is permanent, the status code 404 (Not Found) SHOULD be or not the condition is permanent, the status code 404 (Not Found)
used instead. This response is cacheable unless indicated otherwise. SHOULD be used instead. This response is cacheable unless indicated
otherwise.
The 410 response is primarily intended to assist the task of web The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the to keep the mark for any length of time -- that is left to the
discretion of the server owner. discretion of the server owner.
skipping to change at page 30, line 11 skipping to change at page 30, line 12
entity is larger than the server is willing or able to process. The entity is larger than the server is willing or able to process. The
server MAY close the connection to prevent the client from continuing server MAY close the connection to prevent the client from continuing
the request. the request.
If the condition is temporary, the server SHOULD include a Retry- If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
time the client MAY try again. time the client MAY try again.
8.4.15. 414 URI Too Long 8.4.15. 414 URI Too Long
The server is refusing to service the request because the request- The server is refusing to service the request because the Effective
target is longer than the server is willing to interpret. This rare Request URI is longer than the server is willing to interpret. This
condition is only likely to occur when a client has improperly rare condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query converted a POST request to a GET request with long query
information, when the client has descended into a URI "black hole" of information, when the client has descended into a URI "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the request-target. buffers for reading or manipulating the Effective Request URI.
8.4.16. 415 Unsupported Media Type 8.4.16. 415 Unsupported Media Type
The server is refusing to service the request because the entity of The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource the request is in a format not supported by the requested resource
for the requested method. for the requested method.
8.4.17. 416 Requested Range Not Satisfiable 8.4.17. 416 Requested Range Not Satisfiable
The request included a Range request-header field (Section 5.4 of The request included a Range request-header field (Section 5.4 of
skipping to change at page 32, line 19 skipping to change at page 32, line 19
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.
9.1. Allow 9.1. Allow
The "Allow" response-header field lists the set of methods advertised The "Allow" response-header field lists the set of methods advertised
as supported by the resource identified by the request-target. The as supported by the resource identified by the Effective Request URI.
purpose of this field is strictly to inform the recipient of valid The purpose of this field is strictly to inform the recipient of
methods associated with the resource. valid methods associated with the resource.
Allow = "Allow" ":" OWS Allow-v Allow = "Allow" ":" OWS Allow-v
Allow-v = #Method 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.
skipping to change at page 34, line 30 skipping to change at page 34, line 29
The "Location" response-header field is used to identify a newly The "Location" response-header field is used to identify a newly
created resource, or to redirect the recipient to a different created resource, or to redirect the recipient to a different
location for completion of the request. location for completion of the request.
For 201 (Created) responses, the Location is the URI of the new For 201 (Created) responses, the Location is the URI of the new
resource which was created by the request. For 3xx responses, the resource which was created by the request. For 3xx responses, the
location SHOULD indicate the server's preferred URI for automatic location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. redirection to the resource.
The field value consists of a single URI. The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI
([RFC3986], Section 5).
Location = "Location" ":" OWS Location-v Location = "Location" ":" OWS Location-v
Location-v = URI Location-v = URI-reference
An example is: Examples are:
Location: http://www.example.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html#tim
Location: /index.html
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
URI would not be appropriate: URI would not be appropriate:
o With a 201 Created response, because in this usage the Location o With a 201 Created response, because in this usage the Location
header specifies the URI for the entire created resource. header specifies the URI for the entire created resource.
o With 305 Use Proxy. o With 305 Use Proxy.
Note: This specification does not define precedence rules for the
case where the original URI, as navigated to by the user agent,
and the Location header field value both contain fragment
identifiers.
Note: The Content-Location header field (Section 5.7 of [Part3]) Note: The Content-Location header field (Section 5.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.
9.5. Max-Forwards 9.5. Max-Forwards
The "Max-Forwards" request-header field provides a mechanism with the The "Max-Forwards" request-header field provides a mechanism with the
TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the
skipping to change at page 35, line 34 skipping to change at page 35, line 45
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.
9.6. Referer 9.6. Referer
The "Referer" [sic] request-header field allows the client to specify The "Referer" [sic] request-header field allows the client to specify
the URI of the resource from which the request-target was obtained the URI of the resource from which the Effective Request URI was
(the "referrer", although the header field is misspelled.). obtained (the "referrer", although the header field is misspelled.).
The Referer header allows servers to generate lists of back-links to The Referer header allows servers to generate lists of back-links to
resources for interest, logging, optimized caching, etc. It also resources for interest, logging, optimized caching, etc. It also
allows obsolete or mistyped links to be traced for maintenance. Some allows obsolete or mistyped links to be traced for maintenance. Some
servers use Referer as a means of controlling where they allow links servers use Referer as a means of controlling where they allow links
from (so-called "deep linking"), but it should be noted that from (so-called "deep linking"), but it should be noted that
legitimate requests are not required to contain a Referer header legitimate requests are not required to contain a Referer header
field. field.
If the request-target was obtained from a source that does not have If the Effective Request URI was obtained from a source that does not
its own URI (e.g., input from the user keyboard), the Referer field have its own URI (e.g., input from the user keyboard), the Referer
MUST either be sent with the value "about:blank", or not be sent at field MUST either be sent with the value "about:blank", or not be
all. Note that this requirement does not apply to sources with non- sent at all. Note that this requirement does not apply to sources
HTTP URIs (e.g., FTP). with non-HTTP URIs (e.g., FTP).
Referer = "Referer" ":" OWS Referer-v Referer = "Referer" ":" OWS Referer-v
Referer-v = absolute-URI / partial-URI Referer-v = absolute-URI / partial-URI
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the request-target. The URI MUST NOT include a fragment. relative to the Effective Request URI. The URI MUST NOT include a
See Section 11.2 for security considerations. fragment. See Section 11.2 for security considerations.
9.7. Retry-After 9.7. Retry-After
The response-header "Retry-After" field can be used with a 503 The response-header "Retry-After" field can be used with a 503
(Service Unavailable) response to indicate how long the service is (Service Unavailable) response to indicate how long the service is
expected to be unavailable to the requesting client. This field MAY expected to be unavailable to the requesting client. This field MAY
also be used with any 3xx (Redirection) response to indicate the also be used with any 3xx (Redirection) response to indicate the
minimum time the user-agent is asked wait before issuing the minimum time the user-agent is asked wait before issuing the
redirected request. redirected request.
skipping to change at page 37, line 49 skipping to change at page 38, line 14
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
10. IANA Considerations 10. IANA Considerations
10.1. Method Registry 10.1. Method Registry
The registration procedure for HTTP Methods is defined by Section 2.1 The registration procedure for HTTP Methods is defined by Section 2.1
of this document. of this document.
The HTTP Method Registry located at The HTTP Method Registry should be created at
<http://www.iana.org/assignments/http-methods> should be populated <http://www.iana.org/assignments/http-methods> and be populated with
with the registrations below: the registrations below:
+---------+------+-------------+ +---------+------+-------------+
| Method | Safe | Reference | | Method | Safe | Reference |
+---------+------+-------------+ +---------+------+-------------+
| CONNECT | no | Section 7.9 | | CONNECT | no | Section 7.9 |
| DELETE | no | Section 7.7 | | DELETE | no | Section 7.7 |
| GET | yes | Section 7.3 | | GET | yes | Section 7.3 |
| HEAD | yes | Section 7.4 | | HEAD | yes | Section 7.4 |
| OPTIONS | yes | Section 7.2 | | OPTIONS | yes | Section 7.2 |
| POST | no | Section 7.5 | | POST | no | Section 7.5 |
skipping to change at page 41, line 47 skipping to change at page 41, line 46
Referer field is sent. For example, a browser client could have a Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From respectively enable/disable the sending of Referer and From
information. information.
Clients SHOULD NOT include a Referer header field in a (non-secure) Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure HTTP request if the referring page was transferred with a secure
protocol. protocol.
Authors of services should not use GET-based forms for the submission Authors of services should not use GET-based forms for the submission
of sensitive data because that data will be encoded in the Request- of sensitive data because that data will be encoded in the request-
target. Many existing servers, proxies, and user agents log or target. Many existing servers, proxies, and user agents log or
display the Request-target in places where it might be visible to display the request-target in places where it might be visible to
third parties. Such services can use POST-based form submission third parties. Such services can use POST-based form submission
instead. instead.
11.3. Location Headers and Spoofing 11.3. Location Headers and Spoofing
If a single server supports multiple organizations that do not trust If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content- one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
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-09 and Message Parsing", draft-ietf-httpbis-p1-messaging-10
(work in progress), March 2010. (work in progress), July 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-09 and Content Negotiation", draft-ietf-httpbis-p3-payload-10
(work in progress), March 2010. (work in progress), July 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-09 (work in Requests", draft-ietf-httpbis-p4-conditional-10 (work in
progress), March 2010. progress), July 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-09 (work Partial Responses", draft-ietf-httpbis-p5-range-10 (work
in progress), March 2010. in progress), July 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-09 (work in 6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
progress), March 2010. progress), July 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-09 (work in progress), draft-ietf-httpbis-p7-auth-10 (work in progress),
March 2010. July 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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
STD 66, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
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
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",
skipping to change at page 45, line 20 skipping to change at page 45, line 20
implement it. It used to indicate that the requested resource must implement it. It used to indicate that the requested resource must
be accessed through the proxy given by the Location field. The be accessed through the proxy given by the Location field. The
Location field gave the URI of the proxy. The recipient was expected Location field gave the URI of the proxy. The recipient was expected
to repeat this single request via the proxy. (Section 8.3.6) to repeat this single request via the proxy. (Section 8.3.6)
Reclassify Allow header as response header, removing the option to Reclassify Allow header as response header, removing the option to
specify it in a PUT request. Relax the server requirement on the specify it in a PUT request. Relax the server requirement on the
contents of the Allow header and remove requirement on clients to contents of the Allow header and remove requirement on clients to
always trust the header value. (Section 9.1) always trust the header value. (Section 9.1)
Correct syntax of Location header to allow fragment, as referred Correct syntax of Location header to allow URI references (including
symbol wasn't what was expected, and add some clarifications as to relative references and fragments), as referred symbol "absoluteURI"
when it would not be appropriate. (Section 9.4) wasn't what was expected, and add some clarifications as to when use
of fragments would not be appropriate. (Section 9.4)
Allow Referer value of "about:blank" as alternative to not specifying Allow Referer value of "about:blank" as alternative to not specifying
it. (Section 9.6) it. (Section 9.6)
In the description of the Server header, the Via field was described In the description of the Server header, the Via field was described
as a SHOULD. The requirement was and is stated correctly in the as a SHOULD. The requirement was and is stated correctly in the
description of the Via header in Section 9.9 of [Part1]. description of the Via header in Section 9.9 of [Part1].
(Section 9.8) (Section 9.8)
Appendix B. Collected ABNF Appendix B. Collected ABNF
skipping to change at page 46, line 16 skipping to change at page 46, line 16
If-Match = <If-Match, defined in [Part4], Section 6.2> If-Match = <If-Match, defined in [Part4], Section 6.2>
If-Modified-Since = If-Modified-Since =
<If-Modified-Since, defined in [Part4], Section 6.3> <If-Modified-Since, defined in [Part4], Section 6.3>
If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
If-Range = <If-Range, defined in [Part5], Section 5.3> If-Range = <If-Range, defined in [Part5], Section 5.3>
If-Unmodified-Since = If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 6.5> <If-Unmodified-Since, defined in [Part4], Section 6.5>
Location = "Location:" OWS Location-v Location = "Location:" OWS Location-v
Location-v = URI Location-v = URI-reference
Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
Max-Forwards-v = 1*DIGIT Max-Forwards-v = 1*DIGIT
Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS
/ %x47.45.54 ; GET / %x47.45.54 ; GET
/ %x48.45.41.44 ; HEAD / %x48.45.41.44 ; HEAD
/ %x50.4F.53.54 ; POST / %x50.4F.53.54 ; POST
/ %x50.55.54 ; PUT / %x50.55.54 ; PUT
/ %x44.45.4C.45.54.45 ; DELETE / %x44.45.4C.45.54.45 ; DELETE
/ %x54.52.41.43.45 ; TRACE / %x54.52.41.43.45 ; TRACE
skipping to change at page 47, line 11 skipping to change at page 47, line 11
Server = "Server:" OWS Server-v Server = "Server:" OWS Server-v
Server-v = product *( RWS ( product / comment ) ) Server-v = product *( RWS ( product / comment ) )
Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /
"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
"505" / extension-code "505" / extension-code
TE = <TE, defined in [Part1], Section 9.8> TE = <TE, defined in [Part1], Section 9.5>
URI = <URI, defined in [Part1], Section 2.6> URI-reference = <URI-reference, defined in [Part1], Section 2.6>
User-Agent = "User-Agent:" OWS User-Agent-v User-Agent = "User-Agent:" OWS User-Agent-v
User-Agent-v = product *( RWS ( product / comment ) ) User-Agent-v = product *( RWS ( product / comment ) )
Vary = <Vary, defined in [Part6], Section 3.5> Vary = <Vary, defined in [Part6], Section 3.5>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 3.4> <WWW-Authenticate, defined in [Part7], Section 3.4>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
skipping to change at page 52, line 27 skipping to change at page 52, line 27
and TRACE safe?" and TRACE safe?"
C.10. Since draft-ietf-httpbis-p2-semantics-08 C.10. Since draft-ietf-httpbis-p2-semantics-08
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
vs Redirection" (we missed the introduction to the 3xx status vs Redirection" (we missed the introduction to the 3xx status
codes when fixing this previously) codes when fixing this previously)
C.11. Since draft-ietf-httpbis-p2-semantics-09
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
combination / precedence during redirects"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
header payload handling"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
requested resource's URI"
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
skipping to change at page 54, line 20 skipping to change at page 54, line 35
extension-code 11 extension-code 11
extension-method 8 extension-method 8
From 33 From 33
From-v 33 From-v 33
Location 34 Location 34
Location-v 34 Location-v 34
Max-Forwards 35 Max-Forwards 35
Max-Forwards-v 35 Max-Forwards-v 35
Method 8 Method 8
Reason-Phrase 11 Reason-Phrase 11
Referer 35 Referer 36
Referer-v 35 Referer-v 36
request-header 9 request-header 9
response-header 12 response-header 12
Retry-After 36 Retry-After 36
Retry-After-v 36 Retry-After-v 36
Server 36 Server 37
Server-v 36 Server-v 37
Status-Code 11 Status-Code 11
User-Agent 37 User-Agent 37
User-Agent-v 37 User-Agent-v 37
H H
HEAD method 16 HEAD method 16
Headers Headers
Allow 32 Allow 32
Expect 32 Expect 32
From 33 From 33
Location 34 Location 34
Max-Forwards 35 Max-Forwards 35
Referer 35 Referer 35
Retry-After 36 Retry-After 36
Server 36 Server 37
User-Agent 37 User-Agent 37
I I
Idempotent Methods 14 Idempotent Methods 14
L L
LINK method 44 LINK method 44
Location header 34 Location header 34
M M
Max-Forwards header 35 Max-Forwards header 35
Methods Methods
CONNECT 20 CONNECT 20
DELETE 19 DELETE 19
GET 16 GET 16
HEAD 16 HEAD 16
LINK 44 LINK 44
OPTIONS 15 OPTIONS 14
PATCH 44 PATCH 44
POST 17 POST 17
PUT 18 PUT 17
TRACE 19 TRACE 19
UNLINK 44 UNLINK 44
O O
OPTIONS method 15 OPTIONS method 14
P P
PATCH method 44 PATCH method 44
POST method 17 POST method 17
PUT method 18 PUT method 17
R R
Referer header 35 Referer header 35
Retry-After header 36 Retry-After header 36
S S
Safe Methods 14 Safe Methods 14
Server header 36 Server header 37
Status Codes Status Codes
100 Continue 20 100 Continue 20
101 Switching Protocols 20 101 Switching Protocols 20
200 OK 21 200 OK 21
201 Created 21 201 Created 21
202 Accepted 22 202 Accepted 22
203 Non-Authoritative Information 22 203 Non-Authoritative Information 22
204 No Content 22 204 No Content 22
205 Reset Content 23 205 Reset Content 23
206 Partial Content 23 206 Partial Content 23
skipping to change at page 56, line 46 skipping to change at page 57, line 15
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
Fax: +1-949-706-5305 Fax: +1-949-706-5305
Email: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
One Laptop per Child Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
Email: jg@laptop.org EMail: jg@freedesktop.org
URI: http://www.laptop.org/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Email: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems, Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
Email: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: paulle@microsoft.com EMail: paulle@microsoft.com
Tim Berners-Lee Tim Berners-Lee
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
Email: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 94 change blocks. 
227 lines changed or deleted 254 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/