draft-ietf-httpbis-p2-semantics-17.txt   draft-ietf-httpbis-p2-semantics-18.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: May 3, 2012 HP Expires: July 7, 2012 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 31, 2011 January 4, 2012
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-17 draft-ietf-httpbis-p2-semantics-18
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.18. The changes in this draft are summarized in Appendix C.19.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on July 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Considerations for New Methods . . . . . . . . . . . . 9 2.2.1. Considerations for New Methods . . . . . . . . . . . . 9
3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Considerations for Creating Header Fields . . . . . . . . 9 3.1. Considerations for Creating Header Fields . . . . . . . . 9
3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11 3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11
3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12 3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12
4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 13
4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13
4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15
4.2.1. Considerations for New Status Codes . . . . . . . . . 15 4.2.1. Considerations for New Status Codes . . . . . . . . . 15
5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Identifying the Resource Associated with a 5.1. Identifying the Resource Associated with a
Representation . . . . . . . . . . . . . . . . . . . . . . 16 Representation . . . . . . . . . . . . . . . . . . . . . . 16
6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17 6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17 6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17
6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17 6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17 6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17
skipping to change at page 4, line 19 skipping to change at page 4, line 19
7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33 7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33 7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34 7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34
7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34 7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34
7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34 7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34
7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34 7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34
7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34 7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34
7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35 7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35
7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35 7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35
7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35 7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35
7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 35 7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 36
7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36 7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36
7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36 7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36
7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36 7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36
7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37 7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37
7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37 7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37
7.4.14. 413 Request Representation Too Large . . . . . . . . . 37 7.4.14. 413 Request Representation Too Large . . . . . . . . . 37
7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37 7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37
7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37 7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37
7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38 7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38
7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38 7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38
skipping to change at page 5, line 4 skipping to change at page 5, line 4
9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45 9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46 9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46
9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47 9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47
9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48 9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 49 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50
10.3. Header Field Registration . . . . . . . . . . . . . . . . 51 10.3. Header Field Registration . . . . . . . . . . . . . . . . 51
11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 52
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 54
11.4. Security Considerations for CONNECT . . . . . . . . . . . 53 11.4. Security Considerations for CONNECT . . . . . . . . . . . 54
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 53 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 56
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 59 publication) . . . . . . . . . . . . . . . . . . . . 60
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 59 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 61 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63
C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63
C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64
C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64
C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64
C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65
C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65
C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 65 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66
C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66 C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67
C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66 C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67
C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66 C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
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 7, line 26 skipping to change at page 7, line 26
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
visible US-ASCII character). visible US-ASCII character).
1.2.1. Core Rules 1.2.1. Core Rules
The core rules below are defined in [Part1]: The core rules below are defined in [Part1]:
BWS = <BWS, defined in [Part1], Section 1.2.2>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
RWS = <RWS, defined in [Part1], Section 1.2.2> RWS = <RWS, defined in [Part1], Section 1.2.2>
obs-text = <obs-text, defined in [Part1], Section 1.2.2> obs-text = <obs-text, defined in [Part1], Section 1.2.2>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
skipping to change at page 10, line 22 skipping to change at page 10, line 24
comma are protected with double-quotes using the quoted-string ABNF comma are protected with double-quotes using the quoted-string ABNF
production (Section 3.2.3 of [Part1]). production (Section 3.2.3 of [Part1]).
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double
quotes will likely cause unnecessary confusion.
Many header fields use a format including (case-insensitively) named Many header fields use a format including (case-insensitively) named
parameters (for instance, Content-Type, defined in Section 6.8 of parameters (for instance, Content-Type, defined in Section 6.8 of
[Part3]). Allowing both unquoted (token) and quoted (quoted-string) [Part3]). Allowing both unquoted (token) and quoted (quoted-string)
syntax for the parameter value enables recipients to use existing syntax for the parameter value enables recipients to use existing
parser components. When allowing both forms, the meaning of a parser components. When allowing both forms, the meaning of a
parameter value ought to be independent of the syntax used for it parameter value ought to be independent of the syntax used for it
(for an example, see the notes on parameter handling for media types (for an example, see the notes on parameter handling for media types
in Section 2.3 of [Part3]). in Section 2.3 of [Part3]).
Authors of specifications defining new header fields are advised to Authors of specifications defining new header fields are advised to
skipping to change at page 30, line 36 skipping to change at page 30, line 36
type of redirect with the status code 303 (See Other) ([RFC2068], type of redirect with the status code 303 (See Other) ([RFC2068],
Section 10.3.4). As user agents did not change their behavior to Section 10.3.4). As user agents did not change their behavior to
maintain backwards compatibility, the first revision of HTTP/1.1 maintain backwards compatibility, the first revision of HTTP/1.1
added yet another status code, 307 (Temporary Redirect), for which added yet another status code, 307 (Temporary Redirect), for which
the backwards compatibility problems did not apply ([RFC2616], the backwards compatibility problems did not apply ([RFC2616],
Section 10.3.8). Over 10 years later, most user agents still do Section 10.3.8). Over 10 years later, most user agents still do
method rewriting for status codes 301 and 302, therefore this method rewriting for status codes 301 and 302, therefore this
specification makes that behavior compliant in case the original specification makes that behavior compliant in case the original
request was POST. request was POST.
A Location header field on a 3xx response indicates that a client MAY
automatically redirect to the URI provided; see Section 9.5.
Clients SHOULD detect and intervene in cyclical redirections (i.e., Clients SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
Note: An earlier version of this specification recommended a Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content maximum of five redirections ([RFC2068], Section 10.3). Content
developers need to be aware that some clients might implement such developers need to be aware that some clients might implement such
a fixed limitation. a fixed limitation.
7.3.1. 300 Multiple Choices 7.3.1. 300 Multiple Choices
skipping to change at page 34, line 5 skipping to change at page 34, line 5
the information necessary for a user to repeat the original request the information necessary for a user to repeat the original request
on the new URI. on the new URI.
If the 307 status code is received in response to a request method If the 307 status code is received in response to a request method
that is known to be "safe", as defined in Section 6.1.1, then the that is known to be "safe", as defined in Section 6.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
redirect the request unless it can be confirmed by the user, since redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued. this might change the conditions under which the request was issued.
Note: This status code is similar to 302 Found, except that it
does not allow rewriting the request method from POST to GET.
This specification defines no equivalent counterpart for 301 Moved
Permanently.
7.4. Client Error 4xx 7.4. Client Error 4xx
The 4xx class of status code is intended for cases in which the The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD client seems to have erred. Except when responding to a HEAD
request, the server SHOULD include a representation containing an request, the server SHOULD include a representation containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included request method. User agents SHOULD display any included
representation to the user. representation to the user.
skipping to change at page 39, line 20 skipping to change at page 39, line 20
any resource. any resource.
7.5.3. 502 Bad Gateway 7.5.3. 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to response from the upstream server it accessed in attempting to
fulfill the request. fulfill the request.
7.5.4. 503 Service Unavailable 7.5.4. 503 Service Unavailable
The server is currently unable or unwilling to handle the request due The server is currently unable to handle the request due to a
to reasons such as temporary overloading, maintenance of the server, temporary overloading or maintenance of the server.
or rate limiting of the client.
The implication is that this is a temporary condition which will be The implication is that this is a temporary condition which will be
alleviated after some delay. If known, the length of the delay MAY alleviated after some delay. If known, the length of the delay MAY
be indicated in a Retry-After header field (Section 9.8). If no be indicated in a Retry-After header field (Section 9.8). If no
Retry-After is given, the client SHOULD handle the response as it Retry-After is given, the client SHOULD handle the response as it
would for a 500 response. would for a 500 response.
Note: The existence of the 503 status code does not imply that a Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers might server must use it when becoming overloaded. Some servers might
wish to simply refuse the connection. wish to simply refuse the connection.
skipping to change at page 44, line 15 skipping to change at page 44, line 15
In practice, the date can be generated at any time during the message In practice, the date can be generated at any time during the message
origination without affecting its semantic value. origination without affecting its semantic value.
9.3. Expect 9.3. Expect
The "Expect" header field is used to indicate that particular server The "Expect" header field is used to indicate that particular server
behaviors are required by the client. behaviors are required by the client.
Expect = 1#expectation Expect = 1#expectation
expectation = "100-continue" / expectation-extension expectation = expect-name [ BWS "=" BWS expect-value ]
expectation-extension = token [ "=" ( token / quoted-string ) *( OWS ";" [ OWS expect-param ] )
*expect-params ] expect-param = expect-name [ BWS "=" BWS expect-value ]
expect-params = ";" token [ "=" ( token / quoted-string ) ]
A server that does not understand or is unable to comply with any of expect-name = token
the expectation values in the Expect field of a request MUST respond expect-value = token / quoted-string
with appropriate error status code. The server MUST respond with a
417 (Expectation Failed) status code if any of the expectations
cannot be met or, if there are other problems with the request, some
other 4xx status code.
This header field is defined with extensible syntax to allow for If all received Expect header field(s) are syntactically valid but
future extensions. If a server receives a request containing an contain an expectation that the recipient does not understand or
Expect field that includes an expectation-extension that it does not cannot comply with, the recipient MUST respond with a 417
support, it MUST respond with a 417 (Expectation Failed) status code. (Expectation Failed) status code. A recipient of a syntactically
invalid Expectation header field MUST respond with a 4xx status code
other than 417.
Comparison of expectation values is case-insensitive for unquoted The only expectation defined by this specification is:
tokens (including the 100-continue token), and is case-sensitive for
quoted-string expectation-extensions.
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST 100-continue
return a 417 (Expectation Failed) status code if it receives a
request with an expectation that it cannot meet. However, the Expect The "100-continue" expectation is defined Section 6.2.3 of
header field itself is end-to-end; it MUST be forwarded if the [Part1]. It does not support any expect-params.
request is forwarded.
Comparison is case-insensitive for names (expect-name), and case-
sensitive for values (expect-value).
The Expect mechanism is hop-by-hop: the above requirements apply to
any server, including proxies. However, the Expect header field
itself is end-to-end; it MUST be forwarded if the request is
forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header field. Expect header field.
See Section 6.2.3 of [Part1] for the use of the 100 (Continue) status
code.
9.4. From 9.4. From
The "From" header field, if given, SHOULD contain an Internet e-mail The "From" header field, if given, SHOULD contain an Internet e-mail
address for the human user who controls the requesting user agent. address for the human user who controls the requesting user agent.
The address SHOULD be machine-usable, as defined by "mailbox" in The address SHOULD be machine-usable, as defined by "mailbox" in
Section 3.4 of [RFC5322]: Section 3.4 of [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
skipping to change at page 46, line 11 skipping to change at page 46, line 11
([RFC3986], Section 5). ([RFC3986], Section 5).
Location = URI-reference Location = URI-reference
Examples are: Examples are:
Location: http://www.example.org/pub/WWW/People.html#tim Location: http://www.example.org/pub/WWW/People.html#tim
Location: /index.html Location: /index.html
Note: Some recipients attempt to recover from Location fields that
are not valid URI references. This specification does not mandate
or define such processing, but does allow it (see Section 1.1).
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. For instance, when it appears in a 201 URI would not be appropriate. For instance, when it appears in a 201
Created response, where the Location header field specifies the URI Created response, where the Location header field specifies the URI
for the entire created resource. for the entire created resource.
Note: This specification does not define precedence rules for the Note: This specification does not define precedence rules for the
case where the original URI, as navigated to by the user agent, case where the original URI, as navigated to by the user agent,
and the Location header field value both contain fragment and the Location header field value both contain fragment
identifiers. Thus be aware that including fragment identifiers identifiers. Thus be aware that including fragment identifiers
might inconvenience anyone relying on the semantics of the might inconvenience anyone relying on the semantics of the
skipping to change at page 53, line 43 skipping to change at page 54, line 37
See Section 11 of [Part1]. See Section 11 of [Part1].
13. References 13. References
13.1. Normative References 13.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-17 and Message Parsing", draft-ietf-httpbis-p1-messaging-18
(work in progress), October 2011. (work in progress), January 2012.
[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-17 and Content Negotiation", draft-ietf-httpbis-p3-payload-18
(work in progress), October 2011. (work in progress), January 2012.
[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-17 (work in Requests", draft-ietf-httpbis-p4-conditional-18 (work in
progress), October 2011. progress), January 2012.
[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-17 (work Partial Responses", draft-ietf-httpbis-p5-range-18 (work
in progress), October 2011. in progress), January 2012.
[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-17 (work in 6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
progress), October 2011. progress), January 2012.
[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-17 (work in progress), draft-ietf-httpbis-p7-auth-18 (work in progress),
October 2011. January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 56, line 4 skipping to change at page 56, line 48
able to make that determination based on the request method able to make that determination based on the request method
semantics. Furthermore, allow user agents to rewrite the method from semantics. Furthermore, allow user agents to rewrite the method from
POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
7.3.8) 7.3.8)
Deprecate 305 Use Proxy status code, because user agents did not Deprecate 305 Use Proxy status code, because user agents did not
implement it. It used to indicate that the target resource must be implement it. It used to indicate that the target resource must be
accessed through the proxy given by the Location field. The Location accessed through the proxy given by the Location field. The Location
field gave the URI of the proxy. The recipient was expected to field gave the URI of the proxy. The recipient was expected to
repeat this single request via the proxy. (Section 7.3.6) repeat this single request via the proxy. (Section 7.3.6)
Define status 426 (Upgrade Required) (this was incorporated from Define status 426 (Upgrade Required) (this was incorporated from
[RFC2817]). (Section 7.4.19) [RFC2817]). (Section 7.4.19)
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 9) value. (Section 9)
Reclassify "Allow" as response header field, removing the option to Reclassify "Allow" as response header field, 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 field and remove requirement on clients contents of the Allow header field and remove requirement on clients
to always trust the header field value. (Section 9.1) to always trust the header field value. (Section 9.1)
The ABNF for the Expect header field has been both fixed (allowing
parameters for value-less expectations as well) and simplified
(allowing trailing semicolons after "100-continue" when they were
invalid before). (Section 9.3)
Correct syntax of Location header field to allow URI references Correct syntax of Location header field to allow URI references
(including relative references and fragments), as referred symbol (including relative references and fragments), as referred symbol
"absoluteURI" wasn't what was expected, and add some clarifications "absoluteURI" wasn't what was expected, and add some clarifications
as to when use of fragments would not be appropriate. (Section 9.5) as to when use of fragments would not be appropriate. (Section 9.5)
Restrict Max-Forwards header field to OPTIONS and TRACE (previously, Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
extension methods could have used it as well). (Section 9.6) extension methods could have used it as well). (Section 9.6)
Allow Referer field value of "about:blank" as alternative to not Allow Referer field value of "about:blank" as alternative to not
specifying it. (Section 9.7) specifying it. (Section 9.7)
In the description of the Server header field, the Via field was In the description of the Server header field, the Via field was
described as a SHOULD. The requirement was and is stated correctly described as a SHOULD. The requirement was and is stated correctly
in the description of the Via header field in Section 8.8 of [Part1]. in the description of the Via header field in Section 8.8 of [Part1].
(Section 9.9) (Section 9.9)
Appendix B. Collected ABNF Appendix B. Collected ABNF
Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
BWS = <BWS, defined in [Part1], Section 1.2.2>
Date = HTTP-date Date = HTTP-date
Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
From = mailbox From = mailbox
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-date = rfc1123-date / obs-date HTTP-date = rfc1123-date / obs-date
skipping to change at page 57, line 40 skipping to change at page 58, line 44
/ %x53.75.6E ; Sun / %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday / %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
expect-params = ";" token [ "=" ( token / quoted-string ) ] expect-name = token
expectation = "100-continue" / expectation-extension expect-param = expect-name [ BWS "=" BWS expect-value ]
expectation-extension = token [ "=" ( token / quoted-string ) expect-value = token / quoted-string
*expect-params ] expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
OWS expect-param ] )
hour = 2DIGIT hour = 2DIGIT
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
minute = 2DIGIT minute = 2DIGIT
month = %x4A.61.6E ; Jan month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb / %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar / %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr / %x41.70.72 ; Apr
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
skipping to change at page 66, line 47 skipping to change at page 67, line 47
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy" HTTP's error-handling philosophy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:
"Considerations for new headers" "Considerations for new headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303 o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303
redirect on HEAD" redirect on HEAD"
C.19. Since draft-ietf-httpbis-p2-semantics-17
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
header payload handling"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
status code for rate limiting" (change backed out because a new
status code is being defined for this purpose)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
be a permanent variant of 307"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
Location's semantics triggered?"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
grammar missing OWS"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
considerations: quoted-string vs use of double quotes"
Index Index
1 1
100 Continue (status code) 26 100 Continue (status code) 26
100-continue (expect value) 44
101 Switching Protocols (status code) 26 101 Switching Protocols (status code) 26
2 2
200 OK (status code) 27 200 OK (status code) 27
201 Created (status code) 27 201 Created (status code) 27
202 Accepted (status code) 28 202 Accepted (status code) 28
203 Non-Authoritative Information (status code) 28 203 Non-Authoritative Information (status code) 28
204 No Content (status code) 28 204 No Content (status code) 28
205 Reset Content (status code) 29 205 Reset Content (status code) 29
206 Partial Content (status code) 29 206 Partial Content (status code) 29
skipping to change at page 67, line 32 skipping to change at page 69, line 6
307 Temporary Redirect (status code) 33 307 Temporary Redirect (status code) 33
4 4
400 Bad Request (status code) 34 400 Bad Request (status code) 34
401 Unauthorized (status code) 34 401 Unauthorized (status code) 34
402 Payment Required (status code) 34 402 Payment Required (status code) 34
403 Forbidden (status code) 34 403 Forbidden (status code) 34
404 Not Found (status code) 35 404 Not Found (status code) 35
405 Method Not Allowed (status code) 35 405 Method Not Allowed (status code) 35
406 Not Acceptable (status code) 35 406 Not Acceptable (status code) 35
407 Proxy Authentication Required (status code) 35 407 Proxy Authentication Required (status code) 36
408 Request Timeout (status code) 36 408 Request Timeout (status code) 36
409 Conflict (status code) 36 409 Conflict (status code) 36
410 Gone (status code) 36 410 Gone (status code) 36
411 Length Required (status code) 37 411 Length Required (status code) 37
412 Precondition Failed (status code) 37 412 Precondition Failed (status code) 37
413 Request Representation Too Large (status code) 37 413 Request Representation Too Large (status code) 37
414 URI Too Long (status code) 37 414 URI Too Long (status code) 37
415 Unsupported Media Type (status code) 37 415 Unsupported Media Type (status code) 37
416 Requested Range Not Satisfiable (status code) 38 416 Requested Range Not Satisfiable (status code) 38
417 Expectation Failed (status code) 38 417 Expectation Failed (status code) 38
skipping to change at page 68, line 17 skipping to change at page 69, line 39
C C
CONNECT method 24 CONNECT method 24
D D
Date header field 43 Date header field 43
DELETE method 23 DELETE method 23
E E
Expect header field 44 Expect header field 44
Expect Values
100-continue 44
F F
From header field 44 From header field 44
G G
GET method 19 GET method 19
Grammar Grammar
Allow 42 Allow 42
asctime-date 42 asctime-date 42
Date 43 Date 43
date1 41 date1 41
day 41 day 41
day-name 41 day-name 41
day-name-l 41 day-name-l 41
delta-seconds 47 delta-seconds 47
Expect 44 Expect 44
expect-params 44 expect-name 44
expect-param 44
expect-value 44
expectation 44 expectation 44
expectation-extension 44 extension-code 13
extension-code 12
From 45 From 45
GMT 41 GMT 41
hour 41 hour 41
HTTP-date 40 HTTP-date 40
Location 45 Location 45
Max-Forwards 46 Max-Forwards 46
Method 7 Method 7
minute 41 minute 41
month 41 month 41
obs-date 41 obs-date 41
Reason-Phrase 12 Reason-Phrase 13
Referer 47 Referer 47
Retry-After 47 Retry-After 47
rfc850-date 42 rfc850-date 42
rfc1123-date 41 rfc1123-date 41
second 41 second 41
Server 48 Server 48
Status-Code 12 Status-Code 13
time-of-day 41 time-of-day 41
User-Agent 49 User-Agent 49
year 41 year 41
H H
HEAD method 19 HEAD method 19
Header Fields Header Fields
Allow 42 Allow 42
Date 43 Date 43
Expect 44 Expect 44
skipping to change at page 70, line 33 skipping to change at page 72, line 10
305 Use Proxy 33 305 Use Proxy 33
306 (Unused) 33 306 (Unused) 33
307 Temporary Redirect 33 307 Temporary Redirect 33
400 Bad Request 34 400 Bad Request 34
401 Unauthorized 34 401 Unauthorized 34
402 Payment Required 34 402 Payment Required 34
403 Forbidden 34 403 Forbidden 34
404 Not Found 35 404 Not Found 35
405 Method Not Allowed 35 405 Method Not Allowed 35
406 Not Acceptable 35 406 Not Acceptable 35
407 Proxy Authentication Required 35 407 Proxy Authentication Required 36
408 Request Timeout 36 408 Request Timeout 36
409 Conflict 36 409 Conflict 36
410 Gone 36 410 Gone 36
411 Length Required 37 411 Length Required 37
412 Precondition Failed 37 412 Precondition Failed 37
413 Request Representation Too Large 37 413 Request Representation Too Large 37
414 URI Too Long 37 414 URI Too Long 37
415 Unsupported Media Type 37 415 Unsupported Media Type 37
416 Requested Range Not Satisfiable 38 416 Requested Range Not Satisfiable 38
417 Expectation Failed 38 417 Expectation Failed 38
 End of changes. 44 change blocks. 
93 lines changed or deleted 143 lines changed or added

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