draft-ietf-httpbis-p2-semantics-11.txt   draft-ietf-httpbis-p2-semantics-12.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) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: February 5, 2011 HP Expires: April 28, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 4, 2010 October 25, 2010
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-11 draft-ietf-httpbis-p2-semantics-12
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods, the semantics of HTTP messages as expressed by request methods,
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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/3> and related at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.12. The changes in this draft are summarized in Appendix C.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
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
2.1.1. Considerations for New Methods . . . . . . . . . . . . 9
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 4.1.1. Considerations for New Status Codes . . . . . . . . . 12
5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13
6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Representation . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Identifying the Resource Associated with a 6.1. Identifying the Resource Associated with a
Representation . . . . . . . . . . . . . . . . . . . . . . 13 Representation . . . . . . . . . . . . . . . . . . . . . . 14
7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 15
7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 15
7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15
7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20
8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 21
8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 22
8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22
8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 22 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 23
8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 23
8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23
8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 23 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 24
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 23 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 24
8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24
8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 24 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 25
8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25
8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 25 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 26
8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26
8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 26 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 27
8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 26 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 27
8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 26 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 27
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 27 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 28
8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 27 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 28
8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 27 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 28
8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 27 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 28
8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28
8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28
8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28
8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 28 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 29
8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29
8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29
8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 29 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 30
8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30
8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30
8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30
8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 30 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 31
8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 30 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 31
8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 30 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 31
8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31
8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 31 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 32
8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 31 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 32
8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 31 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 32
8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 31 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 32
8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32
8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 32 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 33
9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 35 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 36
9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 36 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 37
9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 38 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 39
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 38 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 39
10.3. Header Field Registration . . . . . . . . . . . . . . . . 39 10.3. Header Field Registration . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 40 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 41
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 41 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 42
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 42 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 43
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 43 Appendix A. 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 RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 48
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 50 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 51 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52
C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 51 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 52
C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 51 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 53
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
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
the various response messages that might be expected as a result of the various response messages that might be expected as a result of
applying that method to the target resource. applying that method to the target resource.
This document is currently disorganized in order to minimize the This document is currently disorganized in order to minimize the
changes between drafts and enable reviewers to see the smaller errata changes between drafts and enable reviewers to see the smaller errata
changes. The next draft will reorganize the sections to better changes. A future draft will reorganize the sections to better
reflect the content. In particular, the sections will be ordered reflect the content. In particular, the sections will be ordered
according to the typical processing of an HTTP request message (after according to the typical processing of an HTTP request message (after
message parsing): resource mapping, general header fields, methods, message parsing): resource mapping, general header fields, methods,
request modifiers, response status, and resource metadata. The request modifiers, response status, and resource metadata. The
current mess reflects how widely dispersed these topics and current mess reflects how widely dispersed these topics and
associated requirements had become in [RFC2616]. associated requirements had become in [RFC2616].
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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-Unmodified-Since = If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 6.5> <If-Unmodified-Since, defined in [Part4], Section 6.5>
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
If-Range = <If-Range, defined in [Part5], Section 5.3> If-Range = <If-Range, defined in [Part5], Section 5.3>
Range = <Range, defined in [Part5], Section 5.4> Range = <Range, defined in [Part5], Section 5.4>
Age = <Age, defined in [Part6], Section 3.1> Age = <Age, defined in [Part6], Section 3.1>
Vary = <Vary, defined in [Part6], Section 3.5> Vary = <Vary, defined in [Part6], Section 3.5>
Authorization = <Authorization, defined in [Part7], Section 3.1> Authorization = <Authorization, defined in [Part7], Section 4.1>
Proxy-Authenticate = Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 3.2> <Proxy-Authenticate, defined in [Part7], Section 4.2>
Proxy-Authorization = Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 3.3> <Proxy-Authorization, defined in [Part7], Section 4.3>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 3.4> <WWW-Authenticate, defined in [Part7], Section 4.4>
2. Method 2. Method
The Method token indicates the method to be performed on the target The Method token indicates the method to be performed on the target
resource (Section 4.3 of [Part1]). The method is case-sensitive. resource (Section 4.3 of [Part1]). The method is case-sensitive.
Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2
/ %x47.45.54 ; "GET", Section 7.3 / %x47.45.54 ; "GET", Section 7.3
/ %x48.45.41.44 ; "HEAD", Section 7.4 / %x48.45.41.44 ; "HEAD", Section 7.4
/ %x50.4F.53.54 ; "POST", Section 7.5 / %x50.4F.53.54 ; "POST", Section 7.5
skipping to change at page 9, line 17 skipping to change at page 9, line 17
o Safe ("yes" or "no", see Section 7.1.1) o Safe ("yes" or "no", see Section 7.1.1)
o Pointer to specification text o Pointer to specification text
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). ([RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-methods>. <http://www.iana.org/assignments/http-methods>.
2.1.1. Considerations for New Methods
When it is necessary to express new semantics for a HTTP request that
aren't specific to a single application or media type, and currently
defined methods are inadequate, it may be appropriate to register a
new method.
HTTP methods are generic; that is, they are potentially applicable to
any resource, not just one particular media type, "type" of resource,
or application. As such, it is preferred that new HTTP methods be
registered in a document that isn't specific to a single application,
so that this is clear.
Due to the parsing rules defined in Section 3.3 of [Part1],
definitions of HTTP methods cannot prohibit the presence of a
message-body on either the request or the response message (with
responses to HEAD requests being the single exception). Definitions
of new methods cannot change this rule, but they can specify that
only zero-length bodies (as opposed to absent bodies) are allowed.
New method definitions need to indicate whether they are safe
(Section 7.1.1) and whether they are idempotent (Section 7.1.2).
They also need to state whether they can be cached ([Part6]); in
particular what conditions a cache may store the response, and under
what conditions such a stored response may be used to satisfy a
subsequent request.
3. Request Header Fields 3. Request Header Fields
The request-header fields allow the client to pass additional The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
invocation. invocation.
request-header = Accept ; [Part3], Section 6.1 request-header = Accept ; [Part3], Section 6.1
/ Accept-Charset ; [Part3], Section 6.2 / Accept-Charset ; [Part3], Section 6.2
/ Accept-Encoding ; [Part3], Section 6.3 / Accept-Encoding ; [Part3], Section 6.3
/ Accept-Language ; [Part3], Section 6.4 / Accept-Language ; [Part3], Section 6.4
/ Authorization ; [Part7], Section 3.1 / Authorization ; [Part7], Section 4.1
/ Expect ; Section 9.2 / Expect ; Section 9.2
/ From ; Section 9.3 / From ; Section 9.3
/ Host ; [Part1], Section 9.4 / Host ; [Part1], Section 9.4
/ If-Match ; [Part4], Section 6.2 / If-Match ; [Part4], Section 6.2
/ If-Modified-Since ; [Part4], Section 6.3 / If-Modified-Since ; [Part4], Section 6.3
/ If-None-Match ; [Part4], Section 6.4 / If-None-Match ; [Part4], Section 6.4
/ If-Range ; [Part5], Section 5.3 / If-Range ; [Part5], Section 5.3
/ If-Unmodified-Since ; [Part4], Section 6.5 / If-Unmodified-Since ; [Part4], Section 6.5
/ Max-Forwards ; Section 9.5 / Max-Forwards ; Section 9.5
/ Proxy-Authorization ; [Part7], Section 3.3 / Proxy-Authorization ; [Part7], Section 4.3
/ Range ; [Part5], Section 5.4 / Range ; [Part5], Section 5.4
/ Referer ; Section 9.6 / Referer ; Section 9.6
/ TE ; [Part1], Section 9.5 / TE ; [Part1], Section 9.5
/ User-Agent ; Section 9.9 / User-Agent ; Section 9.9
Request-header field names can be extended reliably only in Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request- experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be request-header fields. be request-header fields.
4. Status Code and Reason Phrase 4. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. The status codes attempt to understand and satisfy the request. The status codes
listed below are defined in Section 8, Section 3 of [Part4], Section listed below are defined in Section 8, Section 3 of [Part4], Section
3 of [Part5], and Section 2 of [Part7]. 3 of [Part5], and Section 3 of [Part7].
The Reason-Phrase is intended to give a short textual description of The Reason-Phrase is intended to give a short textual description of
the Status-Code. The Status-Code is intended for use by automata and the Status-Code. The Status-Code is intended for use by automata and
the Reason-Phrase is intended for the human user. The client is not the Reason-Phrase is intended for the human user. The client is not
required to examine or display the Reason-Phrase. required to examine or display the Reason-Phrase.
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase values, HTTP/1.1, and an example set of corresponding Reason-Phrase values,
are presented below. The reason phrases listed here are only are presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without recommendations -- they MAY be replaced by local equivalents without
skipping to change at page 11, line 23 skipping to change at page 11, line 23
/ "205" ; Section 8.2.6: Reset Content / "205" ; Section 8.2.6: Reset Content
/ "206" ; [Part5], Section 3.1: Partial Content / "206" ; [Part5], Section 3.1: Partial Content
/ "300" ; Section 8.3.1: Multiple Choices / "300" ; Section 8.3.1: Multiple Choices
/ "301" ; Section 8.3.2: Moved Permanently / "301" ; Section 8.3.2: Moved Permanently
/ "302" ; Section 8.3.3: Found / "302" ; Section 8.3.3: Found
/ "303" ; Section 8.3.4: See Other / "303" ; Section 8.3.4: See Other
/ "304" ; [Part4], Section 3.1: Not Modified / "304" ; [Part4], Section 3.1: Not Modified
/ "305" ; Section 8.3.6: Use Proxy / "305" ; Section 8.3.6: Use Proxy
/ "307" ; Section 8.3.8: Temporary Redirect / "307" ; Section 8.3.8: Temporary Redirect
/ "400" ; Section 8.4.1: Bad Request / "400" ; Section 8.4.1: Bad Request
/ "401" ; [Part7], Section 2.1: Unauthorized / "401" ; [Part7], Section 3.1: Unauthorized
/ "402" ; Section 8.4.3: Payment Required / "402" ; Section 8.4.3: Payment Required
/ "403" ; Section 8.4.4: Forbidden / "403" ; Section 8.4.4: Forbidden
/ "404" ; Section 8.4.5: Not Found / "404" ; Section 8.4.5: Not Found
/ "405" ; Section 8.4.6: Method Not Allowed / "405" ; Section 8.4.6: Method Not Allowed
/ "406" ; Section 8.4.7: Not Acceptable / "406" ; Section 8.4.7: Not Acceptable
/ "407" ; [Part7], Section 2.2: Proxy Authentication Required / "407" ; [Part7], Section 3.2: Proxy Authentication Required
/ "408" ; Section 8.4.9: Request Time-out / "408" ; Section 8.4.9: Request Time-out
/ "409" ; Section 8.4.10: Conflict / "409" ; Section 8.4.10: Conflict
/ "410" ; Section 8.4.11: Gone / "410" ; Section 8.4.11: Gone
/ "411" ; Section 8.4.12: Length Required / "411" ; Section 8.4.12: Length Required
/ "412" ; [Part4], Section 3.2: Precondition Failed / "412" ; [Part4], Section 3.2: Precondition Failed
/ "413" ; Section 8.4.14: Request Entity Too Large / "413" ; Section 8.4.14: Request Entity Too Large
/ "414" ; Section 8.4.15: URI Too Long / "414" ; Section 8.4.15: URI Too Long
/ "415" ; Section 8.4.16: Unsupported Media Type / "415" ; Section 8.4.16: Unsupported Media Type
/ "416" ; [Part5], Section 3.2: Requested range not satisfiable / "416" ; [Part5], Section 3.2: Requested range not satisfiable
/ "417" ; Section 8.4.18: Expectation Failed / "417" ; Section 8.4.18: Expectation Failed
skipping to change at page 12, line 28 skipping to change at page 12, line 28
The HTTP Status Code Registry defines the name space for the Status- The HTTP Status Code Registry defines the name space for the Status-
Code token in the Status-Line of an HTTP response. Code token in the Status-Line of an HTTP response.
Values to be added to this name space are subject to IETF review Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). ([RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
4.1.1. Considerations for New Status Codes
When it is necessary to express new semantics for a HTTP response
that aren't specific to a single application or media type, and
currently defined status codes are inadequate, a new status code can
be registered.
HTTP status codes are generic; that is, they are potentially
applicable to any resource, not just one particular media type,
"type" of resource, or application. As such, it is preferred that
new HTTP status codes be registered in a document that isn't specific
to a single application, so that this is clear.
Definitions of new HTTP status codes typically explain the request
conditions that produce a response containing the status code (e.g.,
combinations of request headers and/or method(s)), along with any
interactions with response headers (e.g., those that are required,
those that modify the semantics of the response).
New HTTP status codes are required to fall under one of the
categories defined in Section 8. To allow existing parsers to
properly handle them, new status codes cannot disallow a response
body, although they can mandate a zero-length response body. They
can require the presence of one or more particular HTTP response
header(s).
Likewise, their definitions can specify that caches are allowed to
use heuristics to determine their freshness (see [Part6]; by default,
it is not allowed), and can define how to determine the resource
which they carry a representation for (see Section 6.1; by default,
it is anonymous).
5. Response Header Fields 5. Response Header Fields
The response-header fields allow the server to pass additional The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and Line. These header fields give information about the server and
about further access to the target resource (Section 4.3 of [Part1]). about further access to the target resource (Section 4.3 of [Part1]).
response-header = Accept-Ranges ; [Part5], Section 5.1 response-header = Accept-Ranges ; [Part5], Section 5.1
/ Age ; [Part6], Section 3.1 / Age ; [Part6], Section 3.1
/ Allow ; Section 9.1 / Allow ; Section 9.1
/ ETag ; [Part4], Section 6.1 / ETag ; [Part4], Section 6.1
/ Location ; Section 9.4 / Location ; Section 9.4
/ Proxy-Authenticate ; [Part7], Section 3.2 / Proxy-Authenticate ; [Part7], Section 4.2
/ Retry-After ; Section 9.7 / Retry-After ; Section 9.7
/ Server ; Section 9.8 / Server ; Section 9.8
/ Vary ; [Part6], Section 3.5 / Vary ; [Part6], Section 3.5
/ WWW-Authenticate ; [Part7], Section 3.4 / WWW-Authenticate ; [Part7], Section 4.4
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response- experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be response-header fields. be response-header fields.
6. Representation 6. Representation
Request and Response messages MAY transfer a representation if not Request and Response messages MAY transfer a representation if not
skipping to change at page 13, line 43 skipping to change at page 14, line 27
applicable one being selected): applicable one being selected):
1. If the response status code is 200 or 203 and the request method 1. If the response status code is 200 or 203 and the request method
was GET, the response payload is a representation of the target was GET, the response payload is a representation of the target
resource. resource.
2. If the response status code is 204, 206, or 304 and the request 2. If the response status code is 204, 206, or 304 and the request
method was GET or HEAD, the response payload is a partial method was GET or HEAD, the response payload is a partial
representation of the target (see Section 2.8 of [Part6]). representation of the target (see Section 2.8 of [Part6]).
3. If the response has a Content-Location header, and that URI is 3. If the response has a Content-Location header field, and that URI
the same as the effective request URI, the response payload is a is the same as the effective request URI, the response payload is
representation of the target resource. a representation of the target resource.
4. If the response has a Content-Location header, and that URI is 4. If the response has a Content-Location header field, and that URI
not the same as the effective request URI, then the response is not the same as the effective request URI, then the response
asserts that its payload is a representation of the resource asserts that its payload is a representation of the resource
identified by the Content-Location URI. However, such an identified by the Content-Location URI. However, such an
assertion cannot be trusted unless it can be verified by other assertion cannot be trusted unless it can be verified by other
means (not defined by HTTP). means (not defined by HTTP).
5. Otherwise, the response is a representation of an anonymous 5. Otherwise, the response is a representation of an anonymous
(i.e., unidentified) resource. (i.e., unidentified) resource.
[[TODO-req-uri: The comparison function is going to have to be [[TODO-req-uri: The comparison function is going to have to be
defined somewhere, because we already need to compare URIs for things defined somewhere, because we already need to compare URIs for things
skipping to change at page 16, line 42 skipping to change at page 17, line 24
The response to a GET request is cacheable and MAY be used to satisfy The response to a GET request is cacheable and MAY be used to satisfy
subsequent GET and HEAD requests (see [Part6]). subsequent GET and HEAD requests (see [Part6]).
See Section 11.2 for security considerations when used for forms. See Section 11.2 for security considerations when used for forms.
7.4. HEAD 7.4. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metadata contained in the return a message-body in the response. The metadata contained in the
HTTP headers in response to a HEAD request SHOULD be identical to the HTTP header fields in response to a HEAD request SHOULD be identical
information sent in response to a GET request. This method can be to the information sent in response to a GET request. This method
used for obtaining metadata about the representation implied by the can be used for obtaining metadata about the representation implied
request without transferring the representation body. This method is by the request without transferring the representation body. This
often used for testing hypertext links for validity, accessibility, method is often used for testing hypertext links for validity,
and recent modification. accessibility, and recent modification.
The response to a HEAD request is cacheable and MAY be used to The response to a HEAD request is cacheable and MAY be used to
satisfy a subsequent HEAD request; see [Part6]. It also MAY be used satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
to update a previously cached representation from that resource; if to update a previously cached representation from that resource; if
the new field values indicate that the cached representation differs the new field values indicate that the cached representation differs
from the current representation (as would be indicated by a change in from the current representation (as would be indicated by a change in
Content-Length, Content-MD5, ETag or Last-Modified), then the cache Content-Length, Content-MD5, ETag or Last-Modified), then the cache
MUST treat the cache entry as stale. MUST treat the cache entry as stale.
7.5. POST 7.5. POST
skipping to change at page 17, line 37 skipping to change at page 18, line 22
The action performed by the POST method might not result in a The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200 resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status code, (OK) or 204 (No Content) is the appropriate response status code,
depending on whether or not the response includes a representation depending on whether or not the response includes a representation
that describes the result. that describes the result.
If a resource has been created on the origin server, the response If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain a representation which describes SHOULD be 201 (Created) and contain a representation which describes
the status of the request and refers to the new resource, and a the status of the request and refers to the new resource, and a
Location header (see Section 9.4). Location header field (see Section 9.4).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 2.3.1 of [Part6]). A explicit freshness information (see Section 2.3.1 of [Part6]). A
cached POST response with a Content-Location header (see Section 6.7 cached POST response with a Content-Location header field (see
of [Part3]) whose value is the effective Request URI MAY be used to Section 6.7 of [Part3]) whose value is the effective Request URI MAY
satisfy subsequent GET and HEAD requests. be used to satisfy subsequent GET and HEAD requests.
Note that POST caching is not widely implemented. However, the 303 Note that POST caching is not widely implemented. However, the 303
(See Other) response can be used to direct the user agent to retrieve (See Other) response can be used to direct the user agent to retrieve
a cacheable resource. a cacheable resource.
7.6. PUT 7.6. PUT
The PUT method requests that the enclosed representation be stored at The PUT method requests that the enclosed representation be stored at
the effective request URI. If the effective request URI refers to an the effective request URI. If the effective request URI refers to an
already existing resource, the enclosed representation SHOULD be already existing resource, the enclosed representation SHOULD be
skipping to change at page 18, line 25 skipping to change at page 19, line 5
If a new resource is created at the effective request URI, the origin If a new resource is created at the effective request URI, the origin
server MUST inform the user agent via the 201 (Created) response. If server MUST inform the user agent via the 201 (Created) response. If
an existing resource is modified, either the 200 (OK) or 204 (No an existing resource is modified, either the 200 (OK) or 204 (No
Content) response codes SHOULD be sent to indicate successful Content) response codes SHOULD be sent to indicate successful
completion of the request. completion of the request.
If the target resource could not be created or modified, an If the target resource could not be created or modified, an
appropriate error response SHOULD be given that reflects the nature appropriate error response SHOULD be given that reflects the nature
of the problem. The recipient of the representation MUST NOT ignore of the problem. The recipient of the representation MUST NOT ignore
any Content-* headers (headers starting with the prefix "Content-") any Content-* header fields (headers starting with the prefix
that it does not understand or implement and MUST return a 501 (Not "Content-") that it does not understand or implement and MUST return
Implemented) response in such cases. a 501 (Not Implemented) response in such cases.
If the request passes through a cache that has one or more stored If the request passes through a cache that has one or more stored
responses for the effective request URI, those stored responses responses for the effective request URI, those stored responses
SHOULD be marked as stale if the response to the PUT request has a SHOULD be marked as stale if the response to the PUT request has a
success status code. Responses to the PUT method are not cacheable. success status code. Responses to the PUT method are not cacheable.
The fundamental difference between the POST and PUT requests is The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the effective request URI. The reflected in the different meaning of the effective request URI. The
URI in a POST request identifies the resource that will handle the URI in a POST request identifies the resource that will handle the
enclosed representation. That resource might be a data-accepting enclosed representation. That resource might be a data-accepting
skipping to change at page 20, line 21 skipping to change at page 20, line 52
tunneling [RFC2817]). tunneling [RFC2817]).
8. Status Code Definitions 8. Status Code Definitions
Each Status-Code is described below, including any metadata required Each Status-Code is described below, including any metadata required
in the response. in the response.
8.1. Informational 1xx 8.1. Informational 1xx
This class of status code indicates a provisional response, This class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is consisting only of the Status-Line and optional header fields, and is
terminated by an empty line. There are no required headers for this terminated by an empty line. There are no required header fields for
class of status code. Since HTTP/1.0 did not define any 1xx status this class of status code. Since HTTP/1.0 did not define any 1xx
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
except under experimental conditions. client except under experimental conditions.
A client MUST be prepared to accept one or more 1xx status responses A client MUST be prepared to accept one or more 1xx status responses
prior to a regular response, even if the client does not expect a 100 prior to a regular response, even if the client does not expect a 100
(Continue) status message. Unexpected 1xx status responses MAY be (Continue) status message. Unexpected 1xx status responses MAY be
ignored by a user agent. ignored by a user agent.
Proxies MUST forward 1xx responses, unless the connection between the Proxies MUST forward 1xx responses, unless the connection between the
proxy and its client has been closed, or unless the proxy itself proxy and its client has been closed, or unless the proxy itself
requested the generation of the 1xx response. (For example, if a requested the generation of the 1xx response. (For example, if a
proxy adds a "Expect: 100-continue" field when it forwards a request, proxy adds a "Expect: 100-continue" field when it forwards a request,
skipping to change at page 24, line 7 skipping to change at page 24, line 33
detect infinite redirection loops, since such loops generate network detect infinite redirection loops, since such loops generate network
traffic for each redirection. traffic for each redirection.
Note: An earlier version of this specification recommended a Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content maximum of five redirections ([RFC2068], Section 10.3). Content
developers need to be aware that some clients might implement such developers need to be aware that some clients might implement such
a fixed limitation. a fixed limitation.
8.3.1. 300 Multiple Choices 8.3.1. 300 Multiple Choices
The target resource more than one representation, each with its own The target resource has more than one representation, each with its
specific location, and agent-driven negotiation information (Section own specific location, and agent-driven negotiation information
5 of [Part3]) is being provided so that the user (or user agent) can (Section 5 of [Part3]) is being provided so that the user (or user
select a preferred representation by redirecting its request to that agent) can select a preferred representation by redirecting its
location. request to that location.
Unless it was a HEAD request, the response SHOULD include a Unless it was a HEAD request, the response SHOULD include a
representation containing a list of representation metadata and representation containing a list of representation metadata and
location(s) from which the user or user agent can choose the one most location(s) from which the user or user agent can choose the one most
appropriate. The data format is specified by the media type given in appropriate. The data format is specified by the media type given in
the Content-Type header field. Depending upon the format and the the Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate capabilities of the user agent, selection of the most appropriate
choice MAY be performed automatically. However, this specification choice MAY be performed automatically. However, this specification
does not define any standard for such automatic selection. does not define any standard for such automatic selection.
skipping to change at page 26, line 45 skipping to change at page 27, line 24
8.3.8. 307 Temporary Redirect 8.3.8. 307 Temporary Redirect
The target resource resides temporarily under a different URI. Since The target resource resides temporarily under a different URI. Since
the redirection can change over time, the client SHOULD continue to the redirection can change over time, the client SHOULD continue to
use the effective request URI for future requests. use the effective request URI for future requests.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the representation of response. Unless the request method was HEAD, the representation of
the response SHOULD contain a short hypertext note with a hyperlink the response SHOULD contain a short hypertext note with a hyperlink
to the new URI(s) , since many pre-HTTP/1.1 user agents do not to the new URI(s), since many pre-HTTP/1.1 user agents do not
understand the 307 status code. Therefore, the note SHOULD contain understand the 307 status code. Therefore, the note SHOULD contain
the information necessary for a user to repeat the original request the information necessary for a user to repeat the original request
on the new URI. on the new URI.
If the 307 status code is received in response to a request method If the 307 status code is received in response to a request method
that is known to be "safe", as defined in Section 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.
skipping to change at page 27, line 36 skipping to change at page 28, line 14
application. 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 Section 2.1 of The request requires user authentication (see Section 3.1 of
[Part7]). [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.
skipping to change at page 28, line 19 skipping to change at page 28, line 45
permanent. The 410 (Gone) status code SHOULD be used if the server permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address. resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other reveal exactly why the request has been refused, or when no other
response is applicable. response is applicable.
8.4.6. 405 Method Not Allowed 8.4.6. 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the The method specified in the Request-Line is not allowed for the
target resource. The response MUST include an Allow header target resource. The response MUST include an Allow header field
containing a list of valid methods for the requested resource. containing a list of valid methods for the requested resource.
8.4.7. 406 Not Acceptable 8.4.7. 406 Not Acceptable
The resource identified by the request is only capable of generating The resource identified by the request is only capable of generating
response representations which have content characteristics not response representations which have content characteristics not
acceptable according to the accept headers sent in the request. acceptable according to the accept header fields sent in the request.
Unless it was a HEAD request, the response SHOULD include a Unless it was a HEAD request, the response SHOULD include a
representation containing a list of available representation representation containing a list of available representation
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The data format is specified by the choose the one most appropriate. The data format is specified by the
media type given in the Content-Type header field. Depending upon media type given in the Content-Type header field. Depending upon
the format and the capabilities of the user agent, selection of the the format and the capabilities of the user agent, selection of the
most appropriate choice MAY be performed automatically. However, most appropriate choice MAY be performed automatically. However,
this specification does not define any standard for such automatic this specification does not define any standard for such automatic
selection. selection.
Note: HTTP/1.1 servers are allowed to return responses which are Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the not acceptable according to the accept header fields sent in the
request. In some cases, this might even be preferable to sending request. In some cases, this might even be preferable to sending
a 406 response. User agents are encouraged to inspect the headers a 406 response. User agents are encouraged to inspect the header
of an incoming response to determine if it is acceptable. fields 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 Section 2.2 client must first authenticate itself with the proxy (see Section 3.2
of [Part7]). 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
skipping to change at page 31, line 46 skipping to change at page 32, line 29
The server, while acting as a gateway or proxy, received an invalid The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to response from the upstream server it accessed in attempting to
fulfill the request. fulfill the request.
8.5.4. 503 Service Unavailable 8.5.4. 503 Service Unavailable
The server is currently unable to handle the request due to a The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay MAY be indicated in a some delay. If known, the length of the delay MAY be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD Retry-After header field. If no Retry-After is given, the client
handle the response as it would for a 500 response. SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers might server must use it when becoming overloaded. Some servers might
wish to simply refuse the connection. wish to simply refuse the connection.
8.5.5. 504 Gateway Timeout 8.5.5. 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a The server, while acting as a gateway or proxy, did not receive a
timely response from the upstream server specified by the URI (e.g., timely response from the upstream server specified by the URI (e.g.,
HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
skipping to change at page 33, line 37 skipping to change at page 34, line 17
Expect field that includes an expectation-extension that it does not Expect field that includes an expectation-extension that it does not
support, it MUST respond with a 417 (Expectation Failed) status code. support, it MUST respond with a 417 (Expectation Failed) status code.
Comparison of expectation values is case-insensitive for unquoted Comparison of expectation values is case-insensitive for unquoted
tokens (including the 100-continue token), and is case-sensitive for tokens (including the 100-continue token), and is case-sensitive for
quoted-string expectation-extensions. quoted-string expectation-extensions.
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
return a 417 (Expectation Failed) status code if it receives a return a 417 (Expectation Failed) status code if it receives a
request with an expectation that it cannot meet. However, the Expect request with an expectation that it cannot meet. However, the Expect
request-header itself is end-to-end; it MUST be forwarded if the request-header field itself is end-to-end; it MUST be forwarded if
request is forwarded. the request is forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header. Expect header field.
See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status
code. code.
9.3. From 9.3. From
The "From" request-header field, 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]:
skipping to change at page 34, line 20 skipping to change at page 34, line 48
An example is: An example is:
From: webmaster@example.org From: webmaster@example.org
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
NOT be used as an insecure form of access protection. The NOT be used as an insecure form of access protection. The
interpretation of this field is that the request is being performed interpretation of this field is that the request is being performed
on behalf of the person given, who accepts responsibility for the on behalf of the person given, who accepts responsibility for the
method performed. In particular, robot agents SHOULD include this method performed. In particular, robot agents SHOULD include this
header so that the person responsible for running the robot can be header field so that the person responsible for running the robot can
contacted if problems occur on the receiving end. be contacted if problems occur on the receiving end.
The Internet e-mail address in this field MAY be separate from the The Internet e-mail address in this field MAY be separate from the
Internet host which issued the request. For example, when a request Internet host which issued the request. For example, when a request
is passed through a proxy the original issuer's address SHOULD be is passed through a proxy the original issuer's address SHOULD be
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
skipping to change at page 35, line 15 skipping to change at page 35, line 42
Examples are: Examples are:
Location: http://www.example.org/pub/WWW/People.html#tim Location: http://www.example.org/pub/WWW/People.html#tim
Location: /index.html Location: /index.html
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
URI would not be appropriate: URI would not be appropriate:
o With a 201 Created response, because in this usage the Location o With a 201 Created response, because in this usage the Location
header specifies the URI for the entire created resource. header field specifies the URI for the entire created resource.
o With 305 Use Proxy. o With 305 Use Proxy.
Note: This specification does not define precedence rules for the Note: This specification does not define precedence rules for the
case where the original URI, as navigated to by the user agent, case where the original URI, as navigated to by the user agent,
and the Location header field value both contain fragment and the Location header field value both contain fragment
identifiers. identifiers.
Note: The Content-Location header field (Section 6.7 of [Part3]) Note: The Content-Location header field (Section 6.7 of [Part3])
differs from Location in that the Content-Location identifies the differs from Location in that the Content-Location identifies the
skipping to change at page 36, line 13 skipping to change at page 36, line 43
The Max-Forwards header field MAY be ignored for all other methods The Max-Forwards header field MAY be ignored for all other methods
defined by this specification and for any extension methods for which defined by this specification and for any extension methods for which
it is not explicitly referred to as part of that method definition. it is not explicitly referred to as part of that method definition.
9.6. Referer 9.6. Referer
The "Referer" [sic] request-header field allows the client to specify The "Referer" [sic] request-header field allows the client to specify
the URI of the resource from which the effective request URI was the URI of the resource from which the effective request URI was
obtained (the "referrer", although the header field is misspelled.). obtained (the "referrer", although the header field is misspelled.).
The Referer header allows servers to generate lists of back-links to The Referer header field allows servers to generate lists of back-
resources for interest, logging, optimized caching, etc. It also links to resources for interest, logging, optimized caching, etc. It
allows obsolete or mistyped links to be traced for maintenance. Some also allows obsolete or mistyped links to be traced for maintenance.
servers use Referer as a means of controlling where they allow links Some servers use Referer as a means of controlling where they allow
from (so-called "deep linking"), but legitimate requests do not links from (so-called "deep linking"), but legitimate requests do not
always contain a Referer header field. always contain a Referer header field.
If the effective request URI was obtained from a source that does not If the effective request URI was obtained from a source that does not
have its own URI (e.g., input from the user keyboard), the Referer have its own URI (e.g., input from the user keyboard), the Referer
field MUST either be sent with the value "about:blank", or not be field MUST either be sent with the value "about:blank", or not be
sent at all. Note that this requirement does not apply to sources sent at all. Note that this requirement does not apply to sources
with non-HTTP URIs (e.g., FTP). with non-HTTP URIs (e.g., FTP).
Referer = "Referer" ":" OWS Referer-v Referer = "Referer" ":" OWS Referer-v
Referer-v = absolute-URI / partial-URI Referer-v = absolute-URI / partial-URI
skipping to change at page 37, line 36 skipping to change at page 38, line 16
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 field.
MUST include a Via field (as described in Section 9.9 of [Part1]). Instead, it 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 "User-Agent" request-header field 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. User agents SHOULD include this
purposes, the tracing of protocol violations, and automated field with requests.
recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations.
User agents SHOULD include this field with requests. The field can Typically, it is used for statistical purposes, the tracing of
contain multiple product tokens (Section 6.3 of [Part1]) and comments protocol violations, and tailoring responses to avoid particular user
(Section 3.2 of [Part1]) identifying the agent and any subproducts agent limitations.
which form a significant part of the user agent. By convention, the
product tokens are listed in order of their significance for The field can contain multiple product tokens (Section 6.3 of
identifying the application. [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
and its significant subproducts. By convention, the product tokens
are listed in order of their significance for identifying the
application.
Because this field is usually sent on every request a user agent
makes, implementations are encouraged not to include needlessly fine-
grained detail, and to limit (or even prohibit) the addition of
subproducts by third parties. Overly long and detailed User-Agent
field values make requests larger and can also be used to identify
("fingerprint") the user against their wishes.
Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. Finally,
they are encouraged not to use comments to identify products; doing
so makes the field value more difficult to parse.
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 40, line 51 skipping to change at page 41, line 51
server machine to become more vulnerable to attacks against software server machine to become more vulnerable to attacks against software
that is known to contain security holes. Implementors SHOULD make that is known to contain security holes. Implementors SHOULD make
the Server header field a configurable option. the Server header field a configurable option.
Proxies which serve as a portal through a network firewall SHOULD Proxies which serve as a portal through a network firewall SHOULD
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that identifies the hosts behind the firewall. In particular, they that identifies the hosts behind the firewall. In particular, they
SHOULD remove, or replace with sanitized versions, any Via fields SHOULD remove, or replace with sanitized versions, any Via fields
generated behind the firewall. generated behind the firewall.
The Referer header allows reading patterns to be studied and reverse The Referer header field allows reading patterns to be studied and
links drawn. Although it can be very useful, its power can be abused reverse links drawn. Although it can be very useful, its power can
if user details are not separated from the information contained in be abused if user details are not separated from the information
the Referer. Even when the personal information has been removed, contained in the Referer. Even when the personal information has
the Referer header might indicate a private document's URI whose been removed, the Referer header field might indicate a private
publication would be inappropriate. document's URI whose publication would be inappropriate.
The information sent in the From field might conflict with the user's The information sent in the From field might conflict with the user's
privacy interests or their site's security policy, and hence it privacy interests or their site's security policy, and hence it
SHOULD NOT be transmitted without the user being able to disable, SHOULD NOT be transmitted without the user being able to disable,
enable, and modify the contents of the field. The user MUST be able enable, and modify the contents of the field. The user MUST be able
to set the contents of this field within a user preference or to set the contents of this field within a user preference or
application defaults configuration. application defaults configuration.
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.
Furthermore, the User-Agent header field may contain enough entropy
to be used, possibly in conjunction with other material, to uniquely
identify the user.
Some methods, like TRACE (Section 7.8), expose information that was Some methods, like TRACE (Section 7.8), expose information that was
sent in request headers within the body of their response. Clients sent in request header fields within the body of their response.
SHOULD be careful with sensitive information, like Cookies, Clients SHOULD be careful with sensitive information, like Cookies,
Authorization credentials and other headers that might be used to Authorization credentials and other header fields that might be used
collect data from the client. 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 42, line 9 skipping to change at page 43, line 13
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
target. Many existing servers, proxies, and user agents log or target. Many existing servers, proxies, and user agents log or
display the request-target in places where it might be visible to display the request-target in places where it might be visible to
third parties. Such services can use POST-based form submission third parties. Such services can use POST-based form submission
instead. instead.
11.3. Location Headers and Spoofing 11.3. Location Headers and Spoofing
If a single server supports multiple organizations that do not trust If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content- one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of Location header fields in responses that are generated under control
said organizations to make sure that they do not attempt to of said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
12. Acknowledgments 12. Acknowledgments
13. References 13. References
13.1. Normative References 13.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-11 and Message Parsing", draft-ietf-httpbis-p1-messaging-12
(work in progress), August 2010. (work in progress), October 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-11 and Content Negotiation", draft-ietf-httpbis-p3-payload-12
(work in progress), August 2010. (work in progress), October 2010.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-11 (work in Requests", draft-ietf-httpbis-p4-conditional-12 (work in
progress), August 2010. progress), October 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-11 (work Partial Responses", draft-ietf-httpbis-p5-range-12 (work
in progress), August 2010. in progress), October 2010.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-11 (work in 6: Caching", draft-ietf-httpbis-p6-cache-12 (work in
progress), August 2010. progress), October 2010.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-11 (work in progress), draft-ietf-httpbis-p7-auth-12 (work in progress),
August 2010. October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66,
STD 66, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References 13.2. Informative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
skipping to change at page 44, line 13 skipping to change at page 45, line 17
safe to automatically redirect, and further that the user agent is safe to automatically redirect, and further that the user agent is
able to make that determination based on the request method able to make that determination based on the request method
semantics. (Sections 8.3.2, 8.3.3 and 8.3.8) semantics. (Sections 8.3.2, 8.3.3 and 8.3.8)
Deprecate 305 Use Proxy status code, because user agents did not Deprecate 305 Use Proxy status code, because user agents did not
implement it. It used to indicate that the target resource must be implement it. It used to indicate that the target resource must be
accessed through the proxy given by the Location field. The Location accessed through the proxy given by the Location field. The Location
field gave the URI of the proxy. The recipient was expected to field gave the URI of the proxy. The recipient was expected to
repeat this single request via the proxy. (Section 8.3.6) repeat this single request via the proxy. (Section 8.3.6)
Reclassify Allow header as response header, removing the option to Reclassify "Allow" as response header field, removing the option to
specify it in a PUT request. Relax the server requirement on the specify it in a PUT request. Relax the server requirement on the
contents of the Allow header and remove requirement on clients to contents of the Allow header field and remove requirement on clients
always trust the header value. (Section 9.1) to always trust the header field value. (Section 9.1)
Correct syntax of Location header to allow URI references (including Correct syntax of Location header field to allow URI references
relative references and fragments), as referred symbol "absoluteURI" (including relative references and fragments), as referred symbol
wasn't what was expected, and add some clarifications as to when use "absoluteURI" wasn't what was expected, and add some clarifications
of fragments would not be appropriate. (Section 9.4) as to when use of fragments would not be appropriate. (Section 9.4)
Allow Referer value of "about:blank" as alternative to not specifying Allow Referer field value of "about:blank" as alternative to not
it. (Section 9.6) specifying it. (Section 9.6)
In the description of the Server header, the Via field was described In the description of the Server header field, the Via field was
as a SHOULD. The requirement was and is stated correctly in the described as a SHOULD. The requirement was and is stated correctly
description of the Via header in Section 9.9 of [Part1]. in the description of the Via header field 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 6.1> Accept = <Accept, defined in [Part3], Section 6.1>
Accept-Charset = <Accept-Charset, defined in [Part3], Section 6.2> Accept-Charset = <Accept-Charset, defined in [Part3], Section 6.2>
Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3> Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3>
Accept-Language = <Accept-Language, defined in [Part3], Section 6.4> Accept-Language = <Accept-Language, defined in [Part3], Section 6.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 4.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> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
Host = <Host, defined in [Part1], Section 2.6> Host = <Host, defined in [Part1], Section 2.6>
skipping to change at page 45, line 30 skipping to change at page 46, line 35
/ %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
/ %x43.4F.4E.4E.45.43.54 ; CONNECT / %x43.4F.4E.4E.45.43.54 ; CONNECT
/ extension-method / extension-method
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Proxy-Authenticate = Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 3.2> <Proxy-Authenticate, defined in [Part7], Section 4.2>
Proxy-Authorization = Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 3.3> <Proxy-Authorization, defined in [Part7], Section 4.3>
RWS = <RWS, defined in [Part1], Section 1.2.2> RWS = <RWS, defined in [Part1], Section 1.2.2>
Range = <Range, defined in [Part5], Section 5.4> Range = <Range, defined in [Part5], Section 5.4>
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Referer = "Referer:" OWS Referer-v Referer = "Referer:" OWS Referer-v
Referer-v = absolute-URI / partial-URI Referer-v = absolute-URI / partial-URI
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
Server = "Server:" OWS Server-v Server = "Server:" OWS Server-v
skipping to change at page 46, line 4 skipping to change at page 47, line 12
Server = "Server:" OWS Server-v Server = "Server:" OWS Server-v
Server-v = product *( RWS ( product / comment ) ) Server-v = product *( RWS ( product / comment ) )
Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" /
"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / "205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / "307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / "407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / "415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
"505" / extension-code "505" / extension-code
TE = <TE, defined in [Part1], Section 9.5> TE = <TE, defined in [Part1], Section 9.5>
URI-reference = <URI-reference, defined in [Part1], Section 2.6> URI-reference = <URI-reference, defined in [Part1], Section 2.6>
User-Agent = "User-Agent:" OWS User-Agent-v User-Agent = "User-Agent:" OWS User-Agent-v
User-Agent-v = product *( RWS ( product / comment ) ) User-Agent-v = product *( RWS ( product / comment ) )
Vary = <Vary, defined in [Part6], Section 3.5> Vary = <Vary, defined in [Part6], Section 3.5>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 3.4> <WWW-Authenticate, defined in [Part7], Section 4.4>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
comment = <comment, defined in [Part1], Section 3.2> comment = <comment, defined in [Part1], Section 3.2>
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 )
skipping to change at page 47, line 7 skipping to change at page 48, line 16
ABNF diagnostics: ABNF diagnostics:
; Reason-Phrase defined but not used ; Reason-Phrase defined but not used
; Status-Code defined but not used ; Status-Code defined but not used
; request-header defined but not used ; request-header defined but not used
; response-header defined but not used ; response-header defined but not used
Appendix C. Change Log (to be removed by RFC Editor before publication) Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC2616 C.1. Since RFC 2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
C.2. Since draft-ietf-httpbis-p2-semantics-00 C.2. Since draft-ietf-httpbis-p2-semantics-00
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
(<http://purl.org/NET/http-errata#via-must>) (<http://purl.org/NET/http-errata#via-must>)
skipping to change at page 48, line 12 skipping to change at page 49, line 21
o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
effects" effects"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
header requirements" header requirements"
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header field.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Copy definition of delta-seconds from Part6 instead of referencing o Copy definition of delta-seconds from Part6 instead of referencing
it. it.
C.4. Since draft-ietf-httpbis-p2-semantics-02 C.4. Since draft-ietf-httpbis-p2-semantics-02
Closed issues: Closed issues:
skipping to change at page 48, line 44 skipping to change at page 50, line 5
of 303 response" of 303 response"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy" o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
"Classification for Allow header" "Classification for Allow header"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
under' vs 'store at'" under' vs 'store at'"
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Field Registration
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header field registrations for
defined in this document. headers defined in this document.
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive o Replace string literals when the string really is case-sensitive
(method). (method).
C.5. Since draft-ietf-httpbis-p2-semantics-03 C.5. Since draft-ietf-httpbis-p2-semantics-03
Closed issues: Closed issues:
skipping to change at page 49, line 46 skipping to change at page 51, line 6
Ongoing work on ABNF conversion Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives. o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS"). whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions. field value format definitions.
C.7. Since draft-ietf-httpbis-p2-semantics-05 C.7. Since draft-ietf-httpbis-p2-semantics-05
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
BNF" BNF"
Final work on ABNF conversion Final work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
skipping to change at page 52, line 11 skipping to change at page 53, line 17
o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs o <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs
Max-Forwards" Max-Forwards"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes
and caching" and caching"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
removing the 'changes from 2068' sections" removing the 'changes from 2068' sections"
C.13. Since draft-ietf-httpbis-p2-semantics-11
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>:
"Considerations for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>:
"Considerations for new methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent
guidelines" (relating to the 'User-Agent' header field)
Index Index
1 1
100 Continue (status code) 20 100 Continue (status code) 21
101 Switching Protocols (status code) 21 101 Switching Protocols (status code) 21
2 2
200 OK (status code) 21 200 OK (status code) 22
201 Created (status code) 21 201 Created (status code) 22
202 Accepted (status code) 22 202 Accepted (status code) 22
203 Non-Authoritative Information (status code) 22 203 Non-Authoritative Information (status code) 23
204 No Content (status code) 22 204 No Content (status code) 23
205 Reset Content (status code) 23 205 Reset Content (status code) 23
206 Partial Content (status code) 23 206 Partial Content (status code) 24
3 3
300 Multiple Choices (status code) 24 300 Multiple Choices (status code) 24
301 Moved Permanently (status code) 24 301 Moved Permanently (status code) 25
302 Found (status code) 25 302 Found (status code) 25
303 See Other (status code) 25 303 See Other (status code) 26
304 Not Modified (status code) 26 304 Not Modified (status code) 26
305 Use Proxy (status code) 26 305 Use Proxy (status code) 27
306 (Unused) (status code) 26 306 (Unused) (status code) 27
307 Temporary Redirect (status code) 26 307 Temporary Redirect (status code) 27
4 4
400 Bad Request (status code) 27 400 Bad Request (status code) 28
401 Unauthorized (status code) 27 401 Unauthorized (status code) 28
402 Payment Required (status code) 27 402 Payment Required (status code) 28
403 Forbidden (status code) 27 403 Forbidden (status code) 28
404 Not Found (status code) 28 404 Not Found (status code) 28
405 Method Not Allowed (status code) 28 405 Method Not Allowed (status code) 28
406 Not Acceptable (status code) 28 406 Not Acceptable (status code) 28
407 Proxy Authentication Required (status code) 28 407 Proxy Authentication Required (status code) 29
408 Request Timeout (status code) 29 408 Request Timeout (status code) 29
409 Conflict (status code) 29 409 Conflict (status code) 29
410 Gone (status code) 29 410 Gone (status code) 30
411 Length Required (status code) 30 411 Length Required (status code) 30
412 Precondition Failed (status code) 30 412 Precondition Failed (status code) 30
413 Request Entity Too Large (status code) 30 413 Request Entity Too Large (status code) 30
414 URI Too Long (status code) 30 414 URI Too Long (status code) 31
415 Unsupported Media Type (status code) 30 415 Unsupported Media Type (status code) 31
416 Requested Range Not Satisfiable (status code) 30 416 Requested Range Not Satisfiable (status code) 31
417 Expectation Failed (status code) 31 417 Expectation Failed (status code) 31
5 5
500 Internal Server Error (status code) 31 500 Internal Server Error (status code) 32
501 Not Implemented (status code) 31 501 Not Implemented (status code) 32
502 Bad Gateway (status code) 31 502 Bad Gateway (status code) 32
503 Service Unavailable (status code) 31 503 Service Unavailable (status code) 32
504 Gateway Timeout (status code) 32 504 Gateway Timeout (status code) 32
505 HTTP Version Not Supported (status code) 32 505 HTTP Version Not Supported (status code) 32
A A
Allow header 32 Allow header 33
C C
CONNECT method 20 CONNECT method 20
D D
DELETE method 19 DELETE method 19
E E
Expect header 33 Expect header 33
F F
From header 33 From header 34
G G
GET method 16 GET method 16
Grammar Grammar
Allow 32 Allow 33
Allow-v 32 Allow-v 33
delta-seconds 37 delta-seconds 37
Expect 33 Expect 33
expect-params 33 expect-params 33
Expect-v 33 Expect-v 33
expectation 33 expectation 33
expectation-extension 33 expectation-extension 33
extension-code 11 extension-code 11
extension-method 8 extension-method 8
From 34 From 34
From-v 34 From-v 34
Location 34 Location 35
Location-v 34 Location-v 35
Max-Forwards 35 Max-Forwards 36
Max-Forwards-v 35 Max-Forwards-v 36
Method 8 Method 8
Reason-Phrase 11 Reason-Phrase 11
Referer 36 Referer 37
Referer-v 36 Referer-v 37
request-header 9 request-header 10
response-header 12 response-header 13
Retry-After 36 Retry-After 37
Retry-After-v 36 Retry-After-v 37
Server 37 Server 38
Server-v 37 Server-v 38
Status-Code 11 Status-Code 11
User-Agent 38 User-Agent 39
User-Agent-v 38 User-Agent-v 39
H H
HEAD method 16 HEAD method 17
Headers Headers
Allow 32 Allow 33
Expect 33 Expect 33
From 33 From 34
Location 34 Location 35
Max-Forwards 35 Max-Forwards 36
Referer 36 Referer 36
Retry-After 36 Retry-After 37
Server 37 Server 37
User-Agent 37 User-Agent 38
I I
Idempotent Methods 14 Idempotent Methods 15
L L
Location header 34 Location header 35
M M
Max-Forwards header 35 Max-Forwards header 36
Methods Methods
CONNECT 20 CONNECT 20
DELETE 19 DELETE 19
GET 16 GET 16
HEAD 16 HEAD 17
OPTIONS 15 OPTIONS 15
POST 17 POST 17
PUT 18 PUT 18
TRACE 19 TRACE 20
O O
OPTIONS method 15 OPTIONS method 15
P P
POST method 17 POST method 17
PUT method 18 PUT method 18
R R
Referer header 36 Referer header 36
Retry-After header 36 Retry-After header 37
S S
Safe Methods 14 Safe Methods 15
Server header 37 Server header 37
Status Codes Status Codes
100 Continue 20 100 Continue 21
101 Switching Protocols 21 101 Switching Protocols 21
200 OK 21 200 OK 22
201 Created 21 201 Created 22
202 Accepted 22 202 Accepted 22
203 Non-Authoritative Information 22 203 Non-Authoritative Information 23
204 No Content 22 204 No Content 23
205 Reset Content 23 205 Reset Content 23
206 Partial Content 23 206 Partial Content 24
300 Multiple Choices 24 300 Multiple Choices 24
301 Moved Permanently 24 301 Moved Permanently 25
302 Found 25 302 Found 25
303 See Other 25 303 See Other 26
304 Not Modified 26 304 Not Modified 26
305 Use Proxy 26 305 Use Proxy 27
306 (Unused) 26 306 (Unused) 27
307 Temporary Redirect 26 307 Temporary Redirect 27
400 Bad Request 27 400 Bad Request 28
401 Unauthorized 27 401 Unauthorized 28
402 Payment Required 27 402 Payment Required 28
403 Forbidden 27 403 Forbidden 28
404 Not Found 28 404 Not Found 28
405 Method Not Allowed 28 405 Method Not Allowed 28
406 Not Acceptable 28 406 Not Acceptable 28
407 Proxy Authentication Required 28 407 Proxy Authentication Required 29
408 Request Timeout 29 408 Request Timeout 29
409 Conflict 29 409 Conflict 29
410 Gone 29 410 Gone 30
411 Length Required 30 411 Length Required 30
412 Precondition Failed 30 412 Precondition Failed 30
413 Request Entity Too Large 30 413 Request Entity Too Large 30
414 URI Too Long 30 414 URI Too Long 31
415 Unsupported Media Type 30 415 Unsupported Media Type 31
416 Requested Range Not Satisfiable 30 416 Requested Range Not Satisfiable 31
417 Expectation Failed 31 417 Expectation Failed 31
500 Internal Server Error 31 500 Internal Server Error 32
501 Not Implemented 31 501 Not Implemented 32
502 Bad Gateway 31 502 Bad Gateway 32
503 Service Unavailable 31 503 Service Unavailable 32
504 Gateway Timeout 32 504 Gateway Timeout 32
505 HTTP Version Not Supported 32 505 HTTP Version Not Supported 32
T T
TRACE method 19 TRACE method 20
U U
User-Agent header 37 User-Agent header 38
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. 136 change blocks. 
276 lines changed or deleted 370 lines changed or added

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