draft-ietf-httpbis-p2-semantics-07.txt   draft-ietf-httpbis-p2-semantics-08.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) One Laptop per Child Updates: 2817 (if approved) One Laptop per Child
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: January 14, 2010 HP Expires: April 29, 2010 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
July 13, 2009 October 26, 2009
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-07 draft-ietf-httpbis-p2-semantics-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 43 skipping to change at page 2, line 43
fields. fields.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.8. The changes in this draft are summarized in Appendix C.9.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9
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
7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Identifying the Resource Associated with a
7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 Representation . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14
7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14
7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14
7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21
8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22
8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 22
8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22
8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23
8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 23
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 23
8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23
8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 24
8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24
8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 25
8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25
8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 26
8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 26
8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 26
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 27
8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 27
8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 27
8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 27
8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27
8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27
8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28
8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 28
8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28
8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28
8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29
8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29
8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29
8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29
8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 29 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 30
8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 30
8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 30
8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30
8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 31
8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 31
8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 31
8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . 31 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32
9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35
9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36
9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38
10.3. Message Header Registration . . . . . . . . . . . . . . . 39 10.3. Message Header Registration . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . . 42 13.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Compatibility with Previous Versions . . . . . . . . 42 Appendix A. Compatibility with Previous Versions . . . . . . . . 43
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 43
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 44
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 47 publication) . . . . . . . . . . . . . . . . . . . . 48
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 48 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 50 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 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 7, line 11 skipping to change at page 7, line 11
[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), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), VCHAR (any visible USASCII character),
and WSP (whitespace). and WSP (whitespace).
1.2.1. Core Rules 1.2.1. Core Rules
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in Section 1.2.2 of [Part1]:
comment = <comment, defined in [Part1], Section 1.2.2>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, 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>
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
fragment = <fragment, defined in [Part1], Section 2.1> comment = <comment, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 2.1> Host = <Host, defined in [Part1], Section 2.6>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
partial-URI = <partial-URI, defined in [Part1], Section 2.1> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
product = <product, defined in [Part1], Section 3.4> product = <product, defined in [Part1], Section 6.3>
TE = <TE, defined in [Part1], Section 8.8> TE = <TE, defined in [Part1], Section 9.8>
URI = <URI, 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 9, line 32 skipping to change at page 9, line 32
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
invocation. invocation.
request-header = Accept ; [Part3], Section 5.1 request-header = Accept ; [Part3], Section 5.1
/ Accept-Charset ; [Part3], Section 5.2 / Accept-Charset ; [Part3], Section 5.2
/ Accept-Encoding ; [Part3], Section 5.3 / Accept-Encoding ; [Part3], Section 5.3
/ Accept-Language ; [Part3], Section 5.4 / Accept-Language ; [Part3], Section 5.4
/ Authorization ; [Part7], Section 3.1 / Authorization ; [Part7], Section 3.1
/ Expect ; Section 9.2 / Expect ; Section 9.2
/ From ; Section 9.3 / From ; Section 9.3
/ Host ; [Part1], Section 8.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 8.8 / TE ; [Part1], Section 9.8
/ 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
skipping to change at page 11, line 14 skipping to change at page 11, line 14
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" ; Section 8.2.7: 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" ; Section 8.3.5: 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" ; Section 8.4.2: 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" ; Section 8.4.8: 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" ; Section 8.4.13: 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" ; Section 8.4.17: Requested range not satisfiable / "416" ; status-416;: 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
skipping to change at page 13, line 15 skipping to change at page 13, line 15
6. Entity 6. Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. HTTP entity-body and responses will only include the entity-headers. HTTP entity-body and
entity-header fields are defined in [Part3]. entity-header fields are defined in [Part3].
An entity-body is only present in a message when a message-body is An entity-body is only present in a message when a message-body is
present, as described in Section 4.3 of [Part1]. The entity-body is present, as described in Section 3.3 of [Part1]. The entity-body is
obtained from the message-body by decoding any Transfer-Encoding that obtained from the message-body by decoding any Transfer-Encoding that
might have been applied to ensure safe and proper transfer of the might have been applied to ensure safe and proper transfer of the
message. message.
6.1. Identifying the Resource Associated with a Representation
It is sometimes necessary to determine the identity of the resource
associated with a representation.
An HTTP request representation, when present, is always associated
with an anonymous (i.e., unidentified) resource.
In the common case, an HTTP response is a representation of the
resource located at the request-URI. However, this is not always the
case. To determine the URI of the resource a response is associated
with, the following rules are used (first match winning):
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
request-URI.
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
resource at the request-URI (see Section 2.7 of [Part6]).
3. If the response has a Content-Location header, and that URI is
the same as the request-URI [[anchor1: (see [ref])]], the
response is a representation of the resource at the request-URI.
4. If the response has a Content-Location header, and that URI is
not the same as the request-URI, the response asserts that it is
a representation of the resource at the Content-Location URI (but
it may not be).
5. Otherwise, the response is a representation of an anonymous
(i.e., unidentified) resource.
[[TODO-req-uri: Note that 'request-URI' is used here; however, we
need to come up with a term to denote "the URI that can be inferred
from examining the request-target and the Host header." (see
<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
Implementors should be aware that the software represents the user in Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others. unexpected significance to themselves or others.
In particular, the convention has been established that the GET and In particular, the convention has been established that the GET,
HEAD methods SHOULD NOT have the significance of taking an action HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance of
other than retrieval. These methods ought to be considered "safe". taking an action other than retrieval. These methods ought to be
This allows user agents to represent other methods, such as POST, PUT considered "safe". This allows user agents to represent other
and DELETE, in a special way, so that the user is made aware of the methods, such as POST, PUT and DELETE, in a special way, so that the
fact that a possibly unsafe action is being requested. user is made aware of the fact that a possibly unsafe action is being
requested.
Naturally, it is not possible to ensure that the server does not Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, distinction here is that the user did not request the side-effects,
so therefore cannot be held accountable for them. so therefore cannot be held accountable for them.
7.1.2. Idempotent Methods 7.1.2. Idempotent Methods
Methods can also have the property of "idempotence" in that (aside Methods can also have the property of "idempotence" in that, aside
from error or expiration issues) the side-effects of N > 0 identical from error or expiration issues, the intended effect of multiple
requests is the same as for a single request. The methods GET, HEAD, identical requests is the same as for a single request. The methods
PUT and DELETE share this property. Also, the methods OPTIONS and PUT, DELETE, and all safe methods are idempotent. It is important to
TRACE SHOULD NOT have side effects, and so are inherently idempotent. 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
However, it is possible that a sequence of several requests is non- purpose of tracking those requests, versioning of results, etc.
idempotent, even if all of the methods executed in that sequence are
idempotent. (A sequence is idempotent if a single execution of the
entire sequence always yields a result that is not changed by a
reexecution of all, or part, of that sequence.) For example, a
sequence is non-idempotent if its result depends on a value that is
later modified in the same sequence.
A sequence that never has side effects is idempotent, by definition
(provided that no concurrent operations are being executed on the
same set of resources).
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 request-target. This method allows the client to
determine the options and/or requirements associated with a resource, determine the options and/or requirements associated with a resource,
or the capabilities of a server, without implying a resource action or the capabilities of a server, without implying a resource action
or initiating a resource retrieval. or initiating a resource retrieval.
skipping to change at page 19, line 8 skipping to change at page 19, line 41
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
origin server or the first proxy or gateway to receive a Max-Forwards origin server or the first proxy or gateway to receive a Max-Forwards
value of zero (0) in the request (see Section 9.5). A TRACE request value of zero (0) in the request (see Section 9.5). A TRACE request
MUST NOT include an entity. MUST NOT include an entity.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 8.9 of information. The value of the Via header field (Section 9.9 of
[Part1]) is of particular interest, since it acts as a trace of the [Part1]) is of particular interest, since it acts as a trace of the
request chain. Use of the Max-Forwards header field allows the request chain. Use of the Max-Forwards header field allows the
client to limit the length of the request chain, which is useful for client to limit the length of the request chain, which is useful for
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
If the request is valid, the response SHOULD contain the entire If the request is valid, the response SHOULD contain the entire
request message in the entity-body, with a Content-Type of "message/ request message in the entity-body, with a Content-Type of "message/
http" (see Section 9.3.1 of [Part1]). Responses to this method MUST http" (see Section 10.3.1 of [Part1]). Responses to this method MUST
NOT be cached. NOT be cached.
7.9. CONNECT 7.9. CONNECT
This specification reserves the method name CONNECT for use with a This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [RFC2817]). tunneling [RFC2817]).
8. Status Code Definitions 8. Status Code Definitions
skipping to change at page 22, line 35 skipping to change at page 23, line 17
The server has fulfilled the request and the user agent SHOULD reset The server has fulfilled the request and the user agent SHOULD reset
the document view which caused the request to be sent. This response the document view which caused the request to be sent. This response
is primarily intended to allow input for actions to take place via is primarily intended to allow input for actions to take place via
user input, followed by a clearing of the form in which the input is user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The given so that the user can easily initiate another input action. The
response MUST NOT include an entity. response MUST NOT include an entity.
8.2.7. 206 Partial Content 8.2.7. 206 Partial Content
The server has fulfilled the partial GET request for the resource and The server has fulfilled the partial GET request for the resource and
the enclosed entity is a partial representation as defined in the enclosed entity is a partial representation as defined in Section
[Part5]. 3.1 of [Part5].
8.3. Redirection 3xx 8.3. Redirection 3xx
This class of status code indicates that further action needs to be This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request is with the user if and only if the method used in the second request is
GET or HEAD. A client SHOULD detect infinite redirection loops, GET or HEAD. A client SHOULD detect infinite redirection loops,
since such loops generate network traffic for each redirection. since such loops generate network traffic for each redirection.
Note: previous versions of this specification recommended a Note: an earlier version of this specification recommended a
maximum of five redirections. Content developers should be aware maximum of five redirections ([RFC2068], Section 10.3). Content
that there might be clients that implement such a fixed developers should be aware that there might be clients that
limitation. implement such a fixed limitation.
8.3.1. 300 Multiple Choices 8.3.1. 300 Multiple Choices
The requested resource corresponds to any one of a set of The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent- representations, each with its own specific location, and agent-
driven negotiation information (Section 4 of [Part3]) is being driven negotiation information (Section 4 of [Part3]) is being
provided so that the user (or user agent) can select a preferred provided so that the user (or user agent) can select a preferred
representation and redirect its request to that location. representation and redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity Unless it was a HEAD request, the response SHOULD include an entity
skipping to change at page 24, line 25 skipping to change at page 25, line 5
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
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: [RFC1945] and [RFC2068] specify that the client is not Note: HTTP/1.0 ([RFC1945], Section 9.3) and the first version of
allowed to change the method on the redirected request. However, HTTP/1.1 ([RFC2068], Section 10.3.3) specify that the client is
most existing user agent implementations treat 302 as if it were a not allowed to change the method on the redirected request.
303 response, performing a GET on the Location field-value However, most existing user agent implementations treat 302 as if
regardless of the original request method. The status codes 303 it were a 303 response, performing a GET on the Location field-
and 307 have been added for servers that wish to make value regardless of the original request method. Therefore, a
unambiguously clear which kind of reaction is expected of the previous version of this specification ([RFC2616], Section 10.3.3)
has added the status codes 303 and 307 for servers that wish to
make unambiguously clear which kind of reaction is expected of the
client. client.
8.3.4. 303 See Other 8.3.4. 303 See Other
The server directs the user agent to a different resource, indicated The server directs the user agent to a different resource, indicated
by a URI in the Location header field, that provides an indirect by a URI in the Location header field, that provides an indirect
response to the original request. The user agent MAY perform a GET response to the original request. The user agent MAY perform a GET
request on the URI in the Location field in order to obtain a request on the URI in the Location field in order to obtain a
representation corresponding to the response, be redirected again, or representation corresponding to the response, be redirected again, or
end with an error status. The Location URI is not a substitute end with an error status. The Location URI is not a substitute
skipping to change at page 25, line 21 skipping to change at page 25, line 52
A 303 response SHOULD NOT be cached unless it is indicated as A 303 response SHOULD NOT be cached unless it is indicated as
cacheable by Cache-Control or Expires header fields. Except for cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI. contain a short hypertext note with a hyperlink to the Location URI.
8.3.5. 304 Not Modified 8.3.5. 304 Not Modified
The response to the request has not been modified since the The response to the request has not been modified since the
conditions indicated by the client's conditional GET request, as conditions indicated by the client's conditional GET request, as
defined in [Part4]. defined in Section 3.1 of [Part4].
8.3.6. 305 Use Proxy 8.3.6. 305 Use Proxy
The 305 status was defined in a previous version of this The 305 status was defined in a previous version of this
specification (see Appendix A.2), and is now deprecated. specification (see Appendix A.2), and is now deprecated.
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.
skipping to change at page 26, line 34 skipping to change at page 27, line 15
before they can be read and interpreted by the HTTP application. before they can be read and interpreted by the HTTP application.
8.4.1. 400 Bad Request 8.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications. modifications.
8.4.2. 401 Unauthorized 8.4.2. 401 Unauthorized
The request requires user authentication (see [Part7]). The request requires user authentication (see Section 2.1 of
[Part7]).
8.4.3. 402 Payment Required 8.4.3. 402 Payment Required
This code is reserved for future use. This code is reserved for future use.
8.4.4. 403 Forbidden 8.4.4. 403 Forbidden
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
skipping to change at page 27, line 51 skipping to change at page 28, line 33
406 response. User agents are encouraged to inspect the headers 406 response. User agents are encouraged to inspect the headers
of an incoming response to determine if it is acceptable. of an incoming response to determine if it is acceptable.
If the response could be unacceptable, a user agent SHOULD If the response could be unacceptable, a user agent SHOULD
temporarily stop receipt of more data and query the user for a temporarily stop receipt of more data and query the user for a
decision on further actions. decision on further actions.
8.4.8. 407 Proxy Authentication Required 8.4.8. 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the This code is similar to 401 (Unauthorized), but indicates that the
client must first authenticate itself with the proxy (see [Part7]). client must first authenticate itself with the proxy (see Section 2.2
of [Part7]).
8.4.9. 408 Request Timeout 8.4.9. 408 Request Timeout
The client did not produce a request within the time that the server The client did not produce a request within the time that the server
was prepared to wait. The client MAY repeat the request without was prepared to wait. The client MAY repeat the request without
modifications at any later time. modifications at any later time.
8.4.10. 409 Conflict 8.4.10. 409 Conflict
The request could not be completed due to a conflict with the current The request could not be completed due to a conflict with the current
skipping to change at page 29, line 16 skipping to change at page 29, line 45
The server refuses to accept the request without a defined Content- The server refuses to accept the request without a defined Content-
Length. The client MAY repeat the request if it adds a valid Length. The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the message-body Content-Length header field containing the length of the message-body
in the request message. in the request message.
8.4.13. 412 Precondition Failed 8.4.13. 412 Precondition Failed
The precondition given in one or more of the request-header fields The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server, as defined in evaluated to false when it was tested on the server, as defined in
[Part4]. Section 3.2 of [Part4].
8.4.14. 413 Request Entity Too Large 8.4.14. 413 Request Entity Too Large
The server is refusing to process a request because the request The server is refusing to process a request because the request
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
skipping to change at page 29, line 51 skipping to change at page 30, line 31
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
[Part5]) and none of the range-specifier values in this field overlap [Part5]) and none of the range-specifier values in this field overlap
the current extent of the selected resource. the current extent of the selected resource. See Section 3.2 of
[Part5]
8.4.18. 417 Expectation Failed 8.4.18. 417 Expectation Failed
The expectation given in an Expect request-header field (see The expectation given in an Expect request-header field (see
Section 9.2) could not be met by this server, or, if the server is a Section 9.2) could not be met by this server, or, if the server is a
proxy, the server has unambiguous evidence that the request could not proxy, the server has unambiguous evidence that the request could not
be met by the next-hop server. be met by the next-hop server.
8.5. Server Error 5xx 8.5. Server Error 5xx
skipping to change at page 31, line 21 skipping to change at page 31, line 52
Note: Note to implementors: some deployed proxies are known to Note: Note to implementors: some deployed proxies are known to
return 400 or 500 when DNS lookups time out. return 400 or 500 when DNS lookups time out.
8.5.6. 505 HTTP Version Not Supported 8.5.6. 505 HTTP Version Not Supported
The server does not support, or refuses to support, the protocol The server does not support, or refuses to support, the protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in Section using the same major version as the client, as described in Section
3.1 of [Part1], other than with this error message. The response 2.5 of [Part1], other than with this error message. The response
SHOULD contain an entity describing why that version is not supported SHOULD contain an entity describing why that version is not supported
and what other protocols are supported by that server. and what other protocols are supported by that server.
9. Header Field Definitions 9. Header Field Definitions
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 response-header field "Allow" 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 request-target. The
purpose of this field is strictly to inform the recipient of valid purpose of this field is strictly to inform the recipient of valid
methods associated with the resource. An Allow header field MUST be methods associated with the resource.
present in a 405 (Method Not Allowed) response.
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.
A proxy MUST NOT modify the Allow header field even if it does not A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent might have understand all the methods specified, since the user agent might have
other means of communicating with the origin server. other means of communicating with the origin server.
9.2. Expect 9.2. Expect
The request-header field "Expect" is used to indicate that particular The "Expect" request-header field is used to indicate that particular
server behaviors are required by the client. server behaviors are required by the client.
Expect = "Expect" ":" OWS Expect-v Expect = "Expect" ":" OWS Expect-v
Expect-v = 1#expectation Expect-v = 1#expectation
expectation = "100-continue" / expectation-extension expectation = "100-continue" / expectation-extension
expectation-extension = token [ "=" ( token / quoted-string ) expectation-extension = token [ "=" ( token / quoted-string )
*expect-params ] *expect-params ]
expect-params = ";" token [ "=" ( token / quoted-string ) ] expect-params = ";" token [ "=" ( token / quoted-string ) ]
skipping to change at page 33, line 7 skipping to change at page 33, line 33
request is forwarded. request is forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header. Expect header.
See Section 7.2.3 of [Part1] for the use of the 100 (Continue) See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
status. status.
9.3. From 9.3. From
The request-header field "From", if given, SHOULD contain an Internet The "From" request-header field, if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in Section 3.4 of [RFC5322]: in Section 3.4 of [RFC5322]:
From = "From" ":" OWS From-v From = "From" ":" OWS From-v
From-v = mailbox From-v = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
An example is: An example is:
skipping to change at page 33, line 43 skipping to change at page 34, line 21
used. used.
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
9.4. Location 9.4. Location
The response-header field "Location" is used for the identification The "Location" response-header field is used to identify a newly
of a new resource or to redirect the recipient to a location other created resource, or to redirect the recipient to a different
than the request-target for completion of the request. For 201 location for completion of the request.
(Created) responses, the Location is that of the new resource which
was created by the request. For 3xx responses, the location SHOULD For 201 (Created) responses, the Location is the URI of the new
indicate the server's preferred URI for automatic redirection to the resource which was created by the request. For 3xx responses, the
resource. The field value consists of a single absolute URI. location SHOULD indicate the server's preferred URI for automatic
redirection to the resource.
The field value consists of a single URI.
Location = "Location" ":" OWS Location-v Location = "Location" ":" OWS Location-v
Location-v = absolute-URI [ "#" fragment ] Location-v = URI
An example is: An example is:
Location: http://www.example.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html
Note: The Content-Location header field (Section 5.7 of [Part3])
differs from Location in that the Content-Location identifies the
original location of the entity enclosed in the response. It is
therefore possible for a response to contain header fields for
both Location and Content-Location.
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
URL 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 URL for the entire created resource. header specifies the URI for the entire created resource.
o With a 300 Multiple Choices, since the choice decision is intended
to be made on resource characteristics and not fragment
characteristics.
o With 305 Use Proxy. o With 305 Use Proxy.
Note: The Content-Location header field (Section 5.7 of [Part3])
differs from Location in that the Content-Location identifies the
original location of the entity enclosed in the response. It is
therefore possible for a response to contain header fields for
both Location and Content-Location.
9.5. Max-Forwards 9.5. Max-Forwards
The request-header "Max-Forwards" 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
number of proxies or gateways that can forward the request to the number of times that the request is forwarded by proxies or gateways.
next inbound server. This can be useful when the client is This can be useful when the client is attempting to trace a request
attempting to trace a request chain which appears to be failing or which appears to be failing or looping in mid-chain.
looping in mid-chain.
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
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message may be forwarded. number of times this request message may be forwarded.
Each proxy or gateway recipient of a TRACE or OPTIONS request Each proxy or gateway recipient of a TRACE or OPTIONS request
containing a Max-Forwards header field MUST check and update its containing a Max-Forwards header field MUST check and update its
value prior to forwarding the request. If the received value is zero value prior to forwarding the request. If the received value is zero
skipping to change at page 35, line 7 skipping to change at page 35, line 33
respond as the final recipient. If the received Max-Forwards value respond as the final recipient. If the received Max-Forwards value
is greater than zero, then the forwarded message MUST contain an is greater than zero, then the forwarded message MUST contain an
updated Max-Forwards field with a value decremented by one (1). updated Max-Forwards field with a value decremented by one (1).
The Max-Forwards header field MAY be ignored for all other methods The Max-Forwards header field MAY be ignored for all other methods
defined by this specification and for any extension methods for which defined by this specification and for any extension methods for which
it is not explicitly referred to as part of that method definition. it is not explicitly referred to as part of that method definition.
9.6. Referer 9.6. Referer
The request-header field "Referer" [sic] allows the client to The "Referer" [sic] request-header field allows the client to specify
specify, for the server's benefit, the address (URI) of the resource the URI of the resource from which the request-target was obtained
from which the request-target was obtained (the "referrer", although (the "referrer", although the header field is misspelled.).
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 request-target was obtained from a source that does not have
skipping to change at page 35, line 44 skipping to change at page 36, line 19
relative to the request-target. The URI MUST NOT include a fragment. relative to the request-target. The URI MUST NOT include a fragment.
See Section 11.2 for security considerations. 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. The value of this field can be either an HTTP- redirected request.
date or an integer number of seconds (in decimal) after the time of
the response. The value of this field can be either an HTTP-date or an integer
number of seconds (in decimal) after the time of the response.
Retry-After = "Retry-After" ":" OWS Retry-After-v Retry-After = "Retry-After" ":" OWS Retry-After-v
Retry-After-v = HTTP-date / delta-seconds Retry-After-v = HTTP-date / delta-seconds
Time spans are non-negative decimal integers, representing time in Time spans are non-negative decimal integers, representing time in
seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
9.8. Server 9.8. Server
The response-header field "Server" contains information about the The "Server" response-header field contains information about the
software used by the origin server to handle the request. The field software used by the origin server to handle the request.
can contain multiple product tokens (Section 3.4 of [Part1]) and
comments identifying the server and any significant subproducts. The The field can contain multiple product tokens (Section 6.3 of
product tokens are listed in order of their significance for [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
identifying the application. and any significant subproducts. The product tokens are listed in
order of their significance for identifying the application.
Server = "Server" ":" OWS Server-v Server = "Server" ":" OWS Server-v
Server-v = product Server-v = product
*( RWS ( product / comment ) ) *( RWS ( product / comment ) )
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
MUST include a Via field (as described in Section 8.9 of [Part1]). MUST include a Via field (as described in Section 9.9 of [Part1]).
Note: Revealing the specific software version of the server might Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable implementors are encouraged to make this field a configurable
option. option.
9.9. User-Agent 9.9. User-Agent
The request-header field "User-Agent" contains information about the The "User-Agent" request-header field contains information about the
user agent originating the request. This is for statistical user agent originating the request. This is for statistical
purposes, the tracing of protocol violations, and automated purposes, the tracing of protocol violations, and automated
recognition of user agents for the sake of tailoring responses to recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include avoid particular user agent limitations.
this field with requests. The field can contain multiple product
tokens (Section 3.4 of [Part1]) and comments identifying the agent User agents SHOULD include this field with requests. The field can
and any subproducts which form a significant part of the user agent. contain multiple product tokens (Section 6.3 of [Part1]) and comments
By convention, the product tokens are listed in order of their (Section 3.2 of [Part1]) identifying the agent and any subproducts
significance for identifying the application. which form a significant part of the user agent. By convention, the
product tokens are listed in order of their significance for
identifying the application.
User-Agent = "User-Agent" ":" OWS User-Agent-v User-Agent = "User-Agent" ":" OWS User-Agent-v
User-Agent-v = product User-Agent-v = product
*( RWS ( product / comment ) ) *( RWS ( product / comment ) )
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
10. IANA Considerations 10. IANA Considerations
skipping to change at page 38, line 5 skipping to change at page 39, line 5
10.2. Status Code Registry 10.2. Status Code Registry
The registration procedure for HTTP Status Codes -- previously The registration procedure for HTTP Status Codes -- previously
defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1
of this document. of this document.
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> should be updated <http://www.iana.org/assignments/http-status-codes> should be updated
with the registrations below: with the registrations below:
+-------+---------------------------------+----------------+ +-------+-------------------------------+----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------------+----------------+ +-------+-------------------------------+----------------+
| 100 | Continue | Section 8.1.1 | | 100 | Continue | Section 8.1.1 |
| 101 | Switching Protocols | Section 8.1.2 | | 101 | Switching Protocols | Section 8.1.2 |
| 200 | OK | Section 8.2.1 | | 200 | OK | Section 8.2.1 |
| 201 | Created | Section 8.2.2 | | 201 | Created | Section 8.2.2 |
| 202 | Accepted | Section 8.2.3 | | 202 | Accepted | Section 8.2.3 |
| 203 | Non-Authoritative Information | Section 8.2.4 | | 203 | Non-Authoritative Information | Section 8.2.4 |
| 204 | No Content | Section 8.2.5 | | 204 | No Content | Section 8.2.5 |
| 205 | Reset Content | Section 8.2.6 | | 205 | Reset Content | Section 8.2.6 |
| 206 | Partial Content | Section 8.2.7 |
| 300 | Multiple Choices | Section 8.3.1 | | 300 | Multiple Choices | Section 8.3.1 |
| 301 | Moved Permanently | Section 8.3.2 | | 301 | Moved Permanently | Section 8.3.2 |
| 302 | Found | Section 8.3.3 | | 302 | Found | Section 8.3.3 |
| 303 | See Other | Section 8.3.4 | | 303 | See Other | Section 8.3.4 |
| 304 | Not Modified | Section 8.3.5 |
| 305 | Use Proxy | Section 8.3.6 | | 305 | Use Proxy | Section 8.3.6 |
| 306 | (Unused) | Section 8.3.7 | | 306 | (Unused) | Section 8.3.7 |
| 307 | Temporary Redirect | Section 8.3.8 | | 307 | Temporary Redirect | Section 8.3.8 |
| 400 | Bad Request | Section 8.4.1 | | 400 | Bad Request | Section 8.4.1 |
| 401 | Unauthorized | Section 8.4.2 |
| 402 | Payment Required | Section 8.4.3 | | 402 | Payment Required | Section 8.4.3 |
| 403 | Forbidden | Section 8.4.4 | | 403 | Forbidden | Section 8.4.4 |
| 404 | Not Found | Section 8.4.5 | | 404 | Not Found | Section 8.4.5 |
| 405 | Method Not Allowed | Section 8.4.6 | | 405 | Method Not Allowed | Section 8.4.6 |
| 406 | Not Acceptable | Section 8.4.7 | | 406 | Not Acceptable | Section 8.4.7 |
| 407 | Proxy Authentication Required | Section 8.4.8 | | 407 | Proxy Authentication Required | Section 8.4.8 |
| 408 | Request Timeout | Section 8.4.9 | | 408 | Request Timeout | Section 8.4.9 |
| 409 | Conflict | Section 8.4.10 | | 409 | Conflict | Section 8.4.10 |
| 410 | Gone | Section 8.4.11 | | 410 | Gone | Section 8.4.11 |
| 411 | Length Required | Section 8.4.12 | | 411 | Length Required | Section 8.4.12 |
| 412 | Precondition Failed | Section 8.4.13 |
| 413 | Request Entity Too Large | Section 8.4.14 | | 413 | Request Entity Too Large | Section 8.4.14 |
| 414 | URI Too Long | Section 8.4.15 | | 414 | URI Too Long | Section 8.4.15 |
| 415 | Unsupported Media Type | Section 8.4.16 | | 415 | Unsupported Media Type | Section 8.4.16 |
| 416 | Requested Range Not Satisfiable | Section 8.4.17 |
| 417 | Expectation Failed | Section 8.4.18 | | 417 | Expectation Failed | Section 8.4.18 |
| 500 | Internal Server Error | Section 8.5.1 | | 500 | Internal Server Error | Section 8.5.1 |
| 501 | Not Implemented | Section 8.5.2 | | 501 | Not Implemented | Section 8.5.2 |
| 502 | Bad Gateway | Section 8.5.3 | | 502 | Bad Gateway | Section 8.5.3 |
| 503 | Service Unavailable | Section 8.5.4 | | 503 | Service Unavailable | Section 8.5.4 |
| 504 | Gateway Timeout | Section 8.5.5 | | 504 | Gateway Timeout | Section 8.5.5 |
| 505 | HTTP Version Not Supported | Section 8.5.6 | | 505 | HTTP Version Not Supported | Section 8.5.6 |
+-------+---------------------------------+----------------+ +-------+-------------------------------+----------------+
10.3. Message Header Registration 10.3. Message Header Registration
The Message Header Registry located at <http://www.iana.org/ The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
skipping to change at page 40, line 33 skipping to change at page 41, line 27
We suggest, though do not require, that a convenient toggle interface We suggest, though do not require, that a convenient toggle interface
be provided for the user to enable or disable the sending of From and be provided for the user to enable or disable the sending of From and
Referer information. Referer information.
The User-Agent (Section 9.9) or Server (Section 9.8) header fields The User-Agent (Section 9.9) or Server (Section 9.8) header fields
can sometimes be used to determine that a specific client or server can sometimes be used to determine that a specific client or server
have a particular security hole which might be exploited. have a particular security hole which might be exploited.
Unfortunately, this same information is often used for other valuable Unfortunately, this same information is often used for other valuable
purposes for which HTTP currently has no better mechanism. purposes for which HTTP currently has no better mechanism.
Some methods, like TRACE (Section 7.8) may expose information sent in
request headers in the response entity. Clients SHOULD be careful
with sensitive information, like Cookies, Authorization credentials
and other headers that might be used to collect data from the client.
11.2. Encoding Sensitive Information in URIs 11.2. Encoding Sensitive Information in URIs
Because the source of a link might be private information or might Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the recommended that the user be able to select whether or not the
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.
skipping to change at page 41, line 23 skipping to change at page 42, line 22
12. Acknowledgments 12. Acknowledgments
13. References 13. References
13.1. Normative References 13.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-07 and Message Parsing", draft-ietf-httpbis-p1-messaging-08
(work in progress), July 2009. (work in progress), October 2009.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-07 and Content Negotiation", draft-ietf-httpbis-p3-payload-08
(work in progress), July 2009. (work in progress), October 2009.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-07 (work in Requests", draft-ietf-httpbis-p4-conditional-08 (work in
progress), July 2009. progress), October 2009.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-07 (work Partial Responses", draft-ietf-httpbis-p5-range-08 (work
in progress), July 2009. in progress), October 2009.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
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-07 (work in 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in
progress), July 2009. progress), October 2009.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-07 (work in progress), draft-ietf-httpbis-p7-auth-08 (work in progress),
July 2009. October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References 13.2. Informative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
skipping to change at page 43, line 6 skipping to change at page 44, line 5
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
A.1. Changes from RFC 2068 A.1. Changes from RFC 2068
Clarified which error code should be used for inbound server failures Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 8.5.5). (e.g. DNS failures). (Section 8.5.5).
201 (Created) had a race that required an Etag be sent when a 201 (Created) had a race that required an Etag be sent when a
resource is first created. (Section 8.2.2). resource is first created. (Section 8.2.2).
303 (See Also) and 307 (Temporary Redirect) added to address user
agent failure to implement status code 302 properly. (Section 8.3.4
and 8.3.8)
Rewrite of message transmission requirements to make it much harder Rewrite of message transmission requirements to make it much harder
for implementors to get it wrong, as the consequences of errors here for implementors to get it wrong, as the consequences of errors here
can have significant impact on the Internet, and to deal with the can have significant impact on the Internet, and to deal with the
following problems: following problems:
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
this was incorrectly placing a requirement on the behavior of an this was incorrectly placing a requirement on the behavior of an
implementation of a future version of HTTP/1.x implementation of a future version of HTTP/1.x
2. Made it clear that user-agents should retry requests, not 2. Made it clear that user-agents should retry requests, not
skipping to change at page 44, line 27 skipping to change at page 45, line 29
Correct syntax of Location header to allow fragment, as referred Correct syntax of Location header to allow fragment, as referred
symbol wasn't what was expected, and add some clarifications as to symbol wasn't what was expected, and add some clarifications as to
when it would not be appropriate. (Section 9.4) when it would not be appropriate. (Section 9.4)
Allow Referer value of "about:blank" as alternative to not specifying 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 8.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
Accept = <Accept, defined in [Part3], Section 5.1> Accept = <Accept, defined in [Part3], Section 5.1>
Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2> Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>
Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3> Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>
Accept-Language = <Accept-Language, defined in [Part3], Section 5.4> Accept-Language = <Accept-Language, defined in [Part3], Section 5.4>
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
Age = <Age, defined in [Part6], Section 3.1> Age = <Age, defined in [Part6], Section 3.1>
Allow = "Allow:" OWS Allow-v Allow = "Allow:" OWS Allow-v
Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
Authorization = <Authorization, defined in [Part7], Section 3.1> Authorization = <Authorization, defined in [Part7], Section 3.1>
ETag = <ETag, defined in [Part4], Section 6.1> ETag = <ETag, defined in [Part4], Section 6.1>
Expect = "Expect:" OWS Expect-v Expect = "Expect:" OWS Expect-v
Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
From = "From:" OWS From-v From = "From:" OWS From-v
From-v = mailbox From-v = mailbox
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
Host = <Host, defined in [Part1], Section 2.6>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 2.1>
If-Match = <If-Match, defined in [Part4], Section 6.2> If-Match = <If-Match, defined in [Part4], Section 6.2>
If-Modified-Since = If-Modified-Since =
<If-Modified-Since, defined in [Part4], Section 6.3> <If-Modified-Since, defined in [Part4], Section 6.3>
If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
If-Range = <If-Range, defined in [Part5], Section 5.3> If-Range = <If-Range, defined in [Part5], Section 5.3>
If-Unmodified-Since = If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 6.5> <If-Unmodified-Since, defined in [Part4], Section 6.5>
Location = "Location:" OWS Location-v Location = "Location:" OWS Location-v
Location-v = absolute-URI [ "#" fragment ] Location-v = URI
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 45, line 51 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 8.8> TE = <TE, defined in [Part1], Section 9.8>
URI = <URI, 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.1> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
comment = <comment, defined in [Part1], Section 1.2.2> comment = <comment, defined in [Part1], Section 3.2>
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
expect-params = ";" token [ "=" ( token / quoted-string ) ] expect-params = ";" token [ "=" ( token / quoted-string ) ]
expectation = "100-continue" / expectation-extension expectation = "100-continue" / expectation-extension
expectation-extension = token [ "=" ( token / quoted-string ) expectation-extension = token [ "=" ( token / quoted-string )
*expect-params ] *expect-params ]
extension-code = 3DIGIT extension-code = 3DIGIT
extension-method = token extension-method = token
fragment = <fragment, defined in [Part1], Section 2.1>
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
obs-text = <obs-text, defined in [Part1], Section 1.2.2> obs-text = <obs-text, defined in [Part1], Section 1.2.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.1> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
product = <product, defined in [Part1], Section 3.4> product = <product, defined in [Part1], Section 6.3>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
request-header = Accept / Accept-Charset / Accept-Encoding / request-header = Accept / Accept-Charset / Accept-Encoding /
Accept-Language / Authorization / Expect / From / Host / If-Match / Accept-Language / Authorization / Expect / From / Host / If-Match /
If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since /
Max-Forwards / Proxy-Authorization / Range / Referer / TE / Max-Forwards / Proxy-Authorization / Range / Referer / TE /
User-Agent User-Agent
response-header = Accept-Ranges / Age / Allow / ETag / Location / response-header = Accept-Ranges / Age / Allow / ETag / Location /
Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate
skipping to change at page 50, line 32 skipping to change at page 51, line 35
o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
Referer is sent" Referer is sent"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
vs methods" vs methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
require "updates" relation for specs that register status codes or require "updates" relation for specs that register status codes or
method names" method names"
C.9. Since draft-ietf-httpbis-p2-semantics-07
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security
considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
for determining what entities a response carries"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note
citing RFC 1945 and 2068"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note
about redirect limit"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location
header ABNF should use 'URI'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in
Location vs status 303"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
registrations for optional status codes"
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
and TRACE safe?"
Index Index
1 1
100 Continue (status code) 20 100 Continue (status code) 20
101 Switching Protocols (status code) 20 101 Switching Protocols (status code) 20
2 2
200 OK (status code) 20 200 OK (status code) 21
201 Created (status code) 21 201 Created (status code) 21
202 Accepted (status code) 21 202 Accepted (status code) 22
203 Non-Authoritative Information (status code) 21 203 Non-Authoritative Information (status code) 22
204 No Content (status code) 22 204 No Content (status code) 22
205 Reset Content (status code) 22 205 Reset Content (status code) 23
206 Partial Content (status code) 22 206 Partial Content (status code) 23
3 3
300 Multiple Choices (status code) 23 300 Multiple Choices (status code) 23
301 Moved Permanently (status code) 23 301 Moved Permanently (status code) 24
302 Found (status code) 24 302 Found (status code) 24
303 See Other (status code) 24 303 See Other (status code) 25
304 Not Modified (status code) 25 304 Not Modified (status code) 25
305 Use Proxy (status code) 25 305 Use Proxy (status code) 26
306 (Unused) (status code) 25 306 (Unused) (status code) 26
307 Temporary Redirect (status code) 25 307 Temporary Redirect (status code) 26
4 4
400 Bad Request (status code) 26 400 Bad Request (status code) 27
401 Unauthorized (status code) 26 401 Unauthorized (status code) 27
402 Payment Required (status code) 26 402 Payment Required (status code) 27
403 Forbidden (status code) 26 403 Forbidden (status code) 27
404 Not Found (status code) 27 404 Not Found (status code) 27
405 Method Not Allowed (status code) 27 405 Method Not Allowed (status code) 27
406 Not Acceptable (status code) 27 406 Not Acceptable (status code) 28
407 Proxy Authentication Required (status code) 27 407 Proxy Authentication Required (status code) 28
408 Request Timeout (status code) 28 408 Request Timeout (status code) 28
409 Conflict (status code) 28 409 Conflict (status code) 28
410 Gone (status code) 28 410 Gone (status code) 29
411 Length Required (status code) 29 411 Length Required (status code) 29
412 Precondition Failed (status code) 29 412 Precondition Failed (status code) 29
413 Request Entity Too Large (status code) 29 413 Request Entity Too Large (status code) 29
414 URI Too Long (status code) 29 414 URI Too Long (status code) 30
415 Unsupported Media Type (status code) 29 415 Unsupported Media Type (status code) 30
416 Requested Range Not Satisfiable (status code) 29 416 Requested Range Not Satisfiable (status code) 30
417 Expectation Failed (status code) 30 417 Expectation Failed (status code) 30
5 5
500 Internal Server Error (status code) 30 500 Internal Server Error (status code) 31
501 Not Implemented (status code) 30 501 Not Implemented (status code) 31
502 Bad Gateway (status code) 30 502 Bad Gateway (status code) 31
503 Service Unavailable (status code) 30 503 Service Unavailable (status code) 31
504 Gateway Timeout (status code) 31 504 Gateway Timeout (status code) 31
505 HTTP Version Not Supported (status code) 31 505 HTTP Version Not Supported (status code) 31
A A
Allow header 31 Allow header 32
C C
CONNECT method 19 CONNECT method 20
D D
DELETE method 18 DELETE method 19
E E
Expect header 32 Expect header 32
F F
From header 33 From header 33
G G
GET method 15 GET method 16
Grammar Grammar
Allow 31 Allow 32
Allow-v 31 Allow-v 32
delta-seconds 36 delta-seconds 36
Expect 32 Expect 32
expect-params 32 expect-params 32
Expect-v 32 Expect-v 32
expectation 32 expectation 32
expectation-extension 32 expectation-extension 32
extension-code 11 extension-code 11
extension-method 8 extension-method 8
From 33 From 33
From-v 33 From-v 33
Location 33 Location 34
Location-v 33 Location-v 34
Max-Forwards 34 Max-Forwards 35
Max-Forwards-v 34 Max-Forwards-v 35
Method 8 Method 8
Reason-Phrase 11 Reason-Phrase 11
Referer 35 Referer 35
Referer-v 35 Referer-v 35
request-header 9 request-header 9
response-header 12 response-header 12
Retry-After 35 Retry-After 36
Retry-After-v 35 Retry-After-v 36
Server 36 Server 36
Server-v 36 Server-v 36
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 31 Allow 32
Expect 32 Expect 32
From 33 From 33
Location 33 Location 34
Max-Forwards 34 Max-Forwards 35
Referer 35 Referer 35
Retry-After 35 Retry-After 36
Server 36 Server 36
User-Agent 36 User-Agent 37
I I
Idempotent Methods 14 Idempotent Methods 14
L L
LINK method 43 LINK method 44
Location header 33 Location header 34
M M
Max-Forwards header 34 Max-Forwards header 35
Methods Methods
CONNECT 19 CONNECT 20
DELETE 18 DELETE 19
GET 15 GET 16
HEAD 16 HEAD 16
LINK 43 LINK 44
OPTIONS 14 OPTIONS 15
PATCH 43 PATCH 44
POST 16 POST 17
PUT 17 PUT 18
TRACE 18 TRACE 19
UNLINK 43 UNLINK 44
O O
OPTIONS method 14 OPTIONS method 15
P P
PATCH method 43 PATCH method 44
POST method 16 POST method 17
PUT method 17 PUT method 18
R R
Referer header 35 Referer header 35
Retry-After header 35 Retry-After header 36
S S
Safe Methods 13 Safe Methods 14
Server header 36 Server header 36
Status Codes Status Codes
100 Continue 20 100 Continue 20
101 Switching Protocols 20 101 Switching Protocols 20
200 OK 20 200 OK 21
201 Created 21 201 Created 21
202 Accepted 21 202 Accepted 22
203 Non-Authoritative Information 21 203 Non-Authoritative Information 22
204 No Content 22 204 No Content 22
205 Reset Content 22 205 Reset Content 23
206 Partial Content 22 206 Partial Content 23
300 Multiple Choices 23 300 Multiple Choices 23
301 Moved Permanently 23 301 Moved Permanently 24
302 Found 24 302 Found 24
303 See Other 24 303 See Other 25
304 Not Modified 25 304 Not Modified 25
305 Use Proxy 25 305 Use Proxy 26
306 (Unused) 25 306 (Unused) 26
307 Temporary Redirect 25 307 Temporary Redirect 26
400 Bad Request 26 400 Bad Request 27
401 Unauthorized 26 401 Unauthorized 27
402 Payment Required 26 402 Payment Required 27
403 Forbidden 26 403 Forbidden 27
404 Not Found 27 404 Not Found 27
405 Method Not Allowed 27 405 Method Not Allowed 27
406 Not Acceptable 27 406 Not Acceptable 28
407 Proxy Authentication Required 27 407 Proxy Authentication Required 28
408 Request Timeout 28 408 Request Timeout 28
409 Conflict 28 409 Conflict 28
410 Gone 28 410 Gone 29
411 Length Required 29 411 Length Required 29
412 Precondition Failed 29 412 Precondition Failed 29
413 Request Entity Too Large 29 413 Request Entity Too Large 29
414 URI Too Long 29 414 URI Too Long 30
415 Unsupported Media Type 29 415 Unsupported Media Type 30
416 Requested Range Not Satisfiable 29 416 Requested Range Not Satisfiable 30
417 Expectation Failed 30 417 Expectation Failed 30
500 Internal Server Error 30 500 Internal Server Error 31
501 Not Implemented 30 501 Not Implemented 31
502 Bad Gateway 30 502 Bad Gateway 31
503 Service Unavailable 30 503 Service Unavailable 31
504 Gateway Timeout 31 504 Gateway Timeout 31
505 HTTP Version Not Supported 31 505 HTTP Version Not Supported 31
T T
TRACE method 18 TRACE method 19
U U
UNLINK method 43 UNLINK method 44
User-Agent header 36 User-Agent header 37
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
 End of changes. 140 change blocks. 
304 lines changed or deleted 380 lines changed or added

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