draft-ietf-httpbis-p2-semantics-12.txt   draft-ietf-httpbis-p2-semantics-13.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: April 28, 2011 HP Expires: September 15, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 25, 2010 March 14, 2011
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-12 draft-ietf-httpbis-p2-semantics-13
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods, the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header request header fields, response status codes, and response header
fields. fields.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/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.13. The changes in this draft are summarized in Appendix C.14.
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 April 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 6 skipping to change at page 3, line 6
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2. ABNF Rules defined in other Parts of the 1.2.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
2.1.1. Considerations for New Methods . . . . . . . . . . . . 9 2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Considerations for New Methods . . . . . . . . . . . . 8
3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9
4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10
4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 10
4.1.1. Considerations for New Status Codes . . . . . . . . . 12 4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 12
4.2.1. Considerations for New Status Codes . . . . . . . . . 12
5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 14 Representation . . . . . . . . . . . . . . . . . . . . . . 13
7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 15 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 14
7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 15 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 14
7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 20 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 20 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 22
8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 21 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 22
8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 21 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 21 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 23
8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 22 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 22 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24
8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 23 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 24
8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 23 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25
8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 23 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25
8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 24 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 25
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 24 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26
8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 24 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26
8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 25 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 26
8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 25 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27
8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 26 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 27
8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 26 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28
8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 27 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 28
8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 27 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29
8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 27 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 27 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 28 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 29
8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 28 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30
8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 28 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30
8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 28 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30
8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 28 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30
8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 28 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 30
8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 28 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 30
8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 29 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 30
8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 29 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 31
8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 29 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 31
8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 30 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 31
8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 30 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32
8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 30 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 32
8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 30 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 32
8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 31 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 32
8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 31 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33
8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 31 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33
8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 31 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 33
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 31 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 33
8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 32 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 33
8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 32 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34
8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 32 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34
8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 32 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 34
8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 32 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 34
8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 32 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 34
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 33 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35
9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35
9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 35
9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 36 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 37 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 38
9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 38 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 39 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 40
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10.3. Header Field Registration . . . . . . . . . . . . . . . . 40 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 41 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 43 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46
13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 48 publication) . . . . . . . . . . . . . . . . . . . . 50
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 48 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 50
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 50
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 51
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 52
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 53
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 53
C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54
C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 54
C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 52 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55
C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 52 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55
C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 53 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 55
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
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. A future 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, methods, request modifying header
request modifiers, response status, and resource metadata. The fields, response status, status modifying header fields, and resource
current mess reflects how widely dispersed these topics and metadata. The current mess reflects how widely dispersed these
associated requirements had become in [RFC2616]. topics and associated requirements had become in [RFC2616].
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the "MUST" or "REQUIRED" level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the "MUST" or implements. An implementation that satisfies all the "MUST" or
skipping to change at page 7, line 23 skipping to change at page 7, line 23
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
RWS = <RWS, defined in [Part1], Section 1.2.2> RWS = <RWS, defined in [Part1], Section 1.2.2>
obs-text = <obs-text, defined in [Part1], Section 1.2.2> obs-text = <obs-text, defined in [Part1], Section 1.2.2>
1.2.2. ABNF Rules defined in other Parts of the Specification 1.2.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
absolute-URI = <absolute-URI, defined in [Part1], Section 2.6> absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
comment = <comment, defined in [Part1], Section 3.2> comment = <comment, defined in [Part1], Section 3.2>
Host = <Host, defined in [Part1], Section 2.6>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
product = <product, defined in [Part1], Section 6.3> product = <product, defined in [Part1], Section 6.3>
TE = <TE, defined in [Part1], Section 9.5>
URI-reference = <URI-reference, defined in [Part1], Section 2.6> URI-reference = <URI-reference, defined in [Part1], Section 2.6>
Accept = <Accept, defined in [Part3], Section 6.1>
Accept-Charset =
<Accept-Charset, defined in [Part3], Section 6.2>
Accept-Encoding =
<Accept-Encoding, defined in [Part3], Section 6.3>
Accept-Language =
<Accept-Language, defined in [Part3], Section 6.4>
ETag = <ETag, defined in [Part4], Section 6.1>
If-Match = <If-Match, defined in [Part4], Section 6.2>
If-Modified-Since =
<If-Modified-Since, defined in [Part4], Section 6.3>
If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 6.5>
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1>
If-Range = <If-Range, defined in [Part5], Section 5.3>
Range = <Range, defined in [Part5], Section 5.4>
Age = <Age, defined in [Part6], Section 3.1>
Vary = <Vary, defined in [Part6], Section 3.5>
Authorization = <Authorization, defined in [Part7], Section 4.1>
Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 4.2>
Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 4.3>
WWW-Authenticate =
<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 request method to be performed on the
resource (Section 4.3 of [Part1]). The method is case-sensitive. target resource (Section 4.3 of [Part1]). The method is case-
sensitive.
Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 Method = token
/ %x47.45.54 ; "GET", Section 7.3
/ %x48.45.41.44 ; "HEAD", Section 7.4
/ %x50.4F.53.54 ; "POST", Section 7.5
/ %x50.55.54 ; "PUT", Section 7.6
/ %x44.45.4C.45.54.45 ; "DELETE", Section 7.7
/ %x54.52.41.43.45 ; "TRACE", Section 7.8
/ %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.9
/ extension-method
extension-method = token
The list of methods allowed by a resource can be specified in an The list of methods allowed by a resource can be specified in an
Allow header field (Section 9.1). The status code of the response Allow header field (Section 9.1). The status code of the response
always notifies the client whether a method is currently allowed on a always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically. resource, since the set of allowed methods can change dynamically.
An origin server SHOULD respond with the status code 405 (Method Not An origin server SHOULD respond with the status code 405 (Method Not
Allowed) if the method is known by the origin server but not allowed Allowed) if the method is known by the origin server but not allowed
for the resource, and 501 (Not Implemented) if the method is for the resource, and 501 (Not Implemented) if the method is
unrecognized or not implemented by the origin server. The methods unrecognized or not implemented by the origin server. The methods
GET and HEAD MUST be supported by all general-purpose servers. All GET and HEAD MUST be supported by all general-purpose servers. All
other methods are OPTIONAL; however, if the above methods are other methods are OPTIONAL; however, if the above methods are
implemented, they MUST be implemented with the same semantics as implemented, they MUST be implemented with the same semantics as
those specified in Section 7. those specified in Section 7.
2.1. Method Registry 2.1. Overview of Methods
The methods listed below are defined in Section 7.
+-------------+---------------+
| Method Name | Defined in... |
+-------------+---------------+
| OPTIONS | Section 7.2 |
| GET | Section 7.3 |
| HEAD | Section 7.4 |
| POST | Section 7.5 |
| PUT | Section 7.6 |
| DELETE | Section 7.7 |
| TRACE | Section 7.8 |
| CONNECT | Section 7.9 |
+-------------+---------------+
Note that this list is not exhaustive -- it does not include request
methods defined in other specifications.
2.2. Method Registry
The HTTP Method Registry defines the name space for the Method token The HTTP Method Registry defines the name space for the Method token
in the Request line of an HTTP request. in the Request line of an HTTP request.
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Method Name (see Section 2) o Method Name (see Section 2)
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 2.2.1. Considerations for New Methods
When it is necessary to express new semantics for a HTTP request that 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 aren't specific to a single application or media type, and currently
defined methods are inadequate, it may be appropriate to register a defined methods are inadequate, it may be appropriate to register a
new method. new method.
HTTP methods are generic; that is, they are potentially applicable to HTTP methods are generic; that is, they are potentially applicable to
any resource, not just one particular media type, "type" of resource, any resource, not just one particular media type, "type" of resource,
or application. As such, it is preferred that new HTTP methods be or application. As such, it is preferred that new HTTP methods be
registered in a document that isn't specific to a single application, registered in a document that isn't specific to a single application,
skipping to change at page 9, line 46 skipping to change at page 9, line 24
New method definitions need to indicate whether they are safe New method definitions need to indicate whether they are safe
(Section 7.1.1) and whether they are idempotent (Section 7.1.2). (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 They also need to state whether they can be cached ([Part6]); in
particular what conditions a cache may store the response, and under particular what conditions a cache may store the response, and under
what conditions such a stored response may be used to satisfy a what conditions such a stored response may be used to satisfy a
subsequent request. 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 +---------------------+------------------------+
/ Accept-Charset ; [Part3], Section 6.2 | Header Field Name | Defined in... |
/ Accept-Encoding ; [Part3], Section 6.3 +---------------------+------------------------+
/ Accept-Language ; [Part3], Section 6.4 | Accept | Section 6.1 of [Part3] |
/ Authorization ; [Part7], Section 4.1 | Accept-Charset | Section 6.2 of [Part3] |
/ Expect ; Section 9.2 | Accept-Encoding | Section 6.3 of [Part3] |
/ From ; Section 9.3 | Accept-Language | Section 6.4 of [Part3] |
/ Host ; [Part1], Section 9.4 | Authorization | Section 4.1 of [Part7] |
/ If-Match ; [Part4], Section 6.2 | Expect | Section 9.2 |
/ If-Modified-Since ; [Part4], Section 6.3 | From | Section 9.3 |
/ If-None-Match ; [Part4], Section 6.4 | Host | Section 9.4 of [Part1] |
/ If-Range ; [Part5], Section 5.3 | If-Match | Section 6.2 of [Part4] |
/ If-Unmodified-Since ; [Part4], Section 6.5 | If-Modified-Since | Section 6.3 of [Part4] |
/ Max-Forwards ; Section 9.5 | If-None-Match | Section 6.4 of [Part4] |
/ Proxy-Authorization ; [Part7], Section 4.3 | If-Range | Section 5.3 of [Part5] |
/ Range ; [Part5], Section 5.4 | If-Unmodified-Since | Section 6.5 of [Part4] |
/ Referer ; Section 9.6 | Max-Forwards | Section 9.5 |
/ TE ; [Part1], Section 9.5 | Proxy-Authorization | Section 4.3 of [Part7] |
/ User-Agent ; Section 9.9 | Range | Section 5.4 of [Part5] |
| Referer | Section 9.6 |
Request-header field names can be extended reliably only in | TE | Section 9.5 of [Part1] |
combination with a change in the protocol version. However, new or | User-Agent | Section 9.9 |
experimental header fields MAY be given the semantics of request- +---------------------+------------------------+
header fields if all parties in the communication recognize them to
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.
listed below are defined in Section 8, Section 3 of [Part4], Section
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 and is intended for a human user. The client does
the Reason-Phrase is intended for the human user. The client is not not need 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
HTTP/1.1, and an example set of corresponding Reason-Phrase values,
are presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
Status-Code =
"100" ; Section 8.1.1: Continue
/ "101" ; Section 8.1.2: Switching Protocols
/ "200" ; Section 8.2.1: OK
/ "201" ; Section 8.2.2: Created
/ "202" ; Section 8.2.3: Accepted
/ "203" ; Section 8.2.4: Non-Authoritative Information
/ "204" ; Section 8.2.5: No Content
/ "205" ; Section 8.2.6: Reset Content
/ "206" ; [Part5], Section 3.1: Partial Content
/ "300" ; Section 8.3.1: Multiple Choices
/ "301" ; Section 8.3.2: Moved Permanently
/ "302" ; Section 8.3.3: Found
/ "303" ; Section 8.3.4: See Other
/ "304" ; [Part4], Section 3.1: Not Modified
/ "305" ; Section 8.3.6: Use Proxy
/ "307" ; Section 8.3.8: Temporary Redirect
/ "400" ; Section 8.4.1: Bad Request
/ "401" ; [Part7], Section 3.1: Unauthorized
/ "402" ; Section 8.4.3: Payment Required
/ "403" ; Section 8.4.4: Forbidden
/ "404" ; Section 8.4.5: Not Found
/ "405" ; Section 8.4.6: Method Not Allowed
/ "406" ; Section 8.4.7: Not Acceptable
/ "407" ; [Part7], Section 3.2: Proxy Authentication Required
/ "408" ; Section 8.4.9: Request Time-out
/ "409" ; Section 8.4.10: Conflict
/ "410" ; Section 8.4.11: Gone
/ "411" ; Section 8.4.12: Length Required
/ "412" ; [Part4], Section 3.2: Precondition Failed
/ "413" ; Section 8.4.14: Request Entity Too Large
/ "414" ; Section 8.4.15: URI Too Long
/ "415" ; Section 8.4.16: Unsupported Media Type
/ "416" ; [Part5], Section 3.2: Requested range not satisfiable
/ "417" ; Section 8.4.18: Expectation Failed
/ "500" ; Section 8.5.1: Internal Server Error
/ "501" ; Section 8.5.2: Not Implemented
/ "502" ; Section 8.5.3: Bad Gateway
/ "503" ; Section 8.5.4: Service Unavailable
/ "504" ; Section 8.5.5: Gateway Time-out
/ "505" ; Section 8.5.6: HTTP Version not supported
/ extension-code
extension-code = 3DIGIT Status-Code = 3DIGIT
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
HTTP status codes are extensible. HTTP applications are not required HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the representation cases, user agents SHOULD present to the user the representation
enclosed with the response, since that representation is likely to enclosed with the response, since that representation is likely to
include human-readable information which will explain the unusual include human-readable information which will explain the unusual
status. status.
4.1. Status Code Registry 4.1. Overview of Status Codes
The status codes listed below are defined in Section 8 of this
specification, Section 3 of [Part4], Section 3 of [Part5], and
Section 3 of [Part7]. The reason phrases listed here are only
recommendations -- they can be replaced by local equivalents without
affecting the protocol.
+-------------+------------------------------+----------------------+
| Status-Code | Reason-Phrase | Defined in... |
+-------------+------------------------------+----------------------+
| 100 | Continue | Section 8.1.1 |
| 101 | Switching Protocols | Section 8.1.2 |
| 200 | OK | Section 8.2.1 |
| 201 | Created | Section 8.2.2 |
| 202 | Accepted | Section 8.2.3 |
| 203 | Non-Authoritative | Section 8.2.4 |
| | Information | |
| 204 | No Content | Section 8.2.5 |
| 205 | Reset Content | Section 8.2.6 |
| 206 | Partial Content | Section 3.1 of |
| | | [Part5] |
| 300 | Multiple Choices | Section 8.3.1 |
| 301 | Moved Permanently | Section 8.3.2 |
| 302 | Found | Section 8.3.3 |
| 303 | See Other | Section 8.3.4 |
| 304 | Not Modified | Section 3.1 of |
| | | [Part4] |
| 305 | Use Proxy | Section 8.3.6 |
| 307 | Temporary Redirect | Section 8.3.8 |
| 400 | Bad Request | Section 8.4.1 |
| 401 | Unauthorized | Section 3.1 of |
| | | [Part7] |
| 402 | Payment Required | Section 8.4.3 |
| 403 | Forbidden | Section 8.4.4 |
| 404 | Not Found | Section 8.4.5 |
| 405 | Method Not Allowed | Section 8.4.6 |
| 406 | Not Acceptable | Section 8.4.7 |
| 407 | Proxy Authentication | Section 3.2 of |
| | Required | [Part7] |
| 408 | Request Time-out | Section 8.4.9 |
| 409 | Conflict | Section 8.4.10 |
| 410 | Gone | Section 8.4.11 |
| 411 | Length Required | Section 8.4.12 |
| 412 | Precondition Failed | Section 3.2 of |
| | | [Part4] |
| 413 | Request Entity Too Large | Section 8.4.14 |
| 414 | URI Too Long | Section 8.4.15 |
| 415 | Unsupported Media Type | Section 8.4.16 |
| 416 | Requested range not | Section 3.2 of |
| | satisfiable | [Part5] |
| 417 | Expectation Failed | Section 8.4.18 |
| 426 | Upgrade Required | Section 8.4.19 |
| 500 | Internal Server Error | Section 8.5.1 |
| 501 | Not Implemented | Section 8.5.2 |
| 502 | Bad Gateway | Section 8.5.3 |
| 503 | Service Unavailable | Section 8.5.4 |
| 504 | Gateway Time-out | Section 8.5.5 |
| 505 | HTTP Version not supported | Section 8.5.6 |
+-------------+------------------------------+----------------------+
Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications.
4.2. Status Code Registry
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 4.2.1. Considerations for New Status Codes
When it is necessary to express new semantics for a HTTP response When it is necessary to express new semantics for a HTTP response
that aren't specific to a single application or media type, and that aren't specific to a single application or media type, and
currently defined status codes are inadequate, a new status code can currently defined status codes are inadequate, a new status code can
be registered. be registered.
HTTP status codes are generic; that is, they are potentially HTTP status codes are generic; that is, they are potentially
applicable to any resource, not just one particular media type, applicable to any resource, not just one particular media type,
"type" of resource, or application. As such, it is preferred that "type" of resource, or application. As such, it is preferred that
new HTTP status codes be registered in a document that isn't specific new HTTP status codes be registered in a document that isn't specific
skipping to change at page 13, line 14 skipping to change at page 13, line 9
header(s). header(s).
Likewise, their definitions can specify that caches are allowed to Likewise, their definitions can specify that caches are allowed to
use heuristics to determine their freshness (see [Part6]; by default, use heuristics to determine their freshness (see [Part6]; by default,
it is not allowed), and can define how to determine the resource it is not allowed), and can define how to determine the resource
which they carry a representation for (see Section 6.1; by default, which they carry a representation for (see Section 6.1; by default,
it is anonymous). 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 +--------------------+------------------------+
/ Age ; [Part6], Section 3.1 | Header Field Name | Defined in... |
/ Allow ; Section 9.1 +--------------------+------------------------+
/ ETag ; [Part4], Section 6.1 | Accept-Ranges | Section 5.1 of [Part5] |
/ Location ; Section 9.4 | Age | Section 3.1 of [Part6] |
/ Proxy-Authenticate ; [Part7], Section 4.2 | Allow | Section 9.1 |
/ Retry-After ; Section 9.7 | ETag | Section 6.1 of [Part4] |
/ Server ; Section 9.8 | Location | Section 9.4 |
/ Vary ; [Part6], Section 3.5 | Proxy-Authenticate | Section 4.2 of [Part7] |
/ WWW-Authenticate ; [Part7], Section 4.4 | Retry-After | Section 9.7 |
| Server | Section 9.8 |
Response-header field names can be extended reliably only in | Vary | Section 3.5 of [Part6] |
combination with a change in the protocol version. However, new or | WWW-Authenticate | Section 4.4 of [Part7] |
experimental header fields MAY be given the semantics of response- +--------------------+------------------------+
header fields if all parties in the communication recognize them to
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
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
A representation consists of metadata (representation header fields) A representation consists of metadata (representation header fields)
and data (representation body). When a complete or partial and data (representation body). When a complete or partial
representation is enclosed in an HTTP message, it is referred to as representation is enclosed in an HTTP message, it is referred to as
the payload of the message. HTTP representations are defined in the payload of the message. HTTP representations are defined in
[Part3]. [Part3].
skipping to change at page 14, line 25 skipping to change at page 14, line 17
always the case. To determine the URI of the resource a response is always the case. To determine the URI of the resource a response is
associated with, the following rules are used (with the first associated with, the following rules are used (with the first
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 resource (see Section 2.8 of
[Part6]).
3. If the response has a Content-Location header field, and that URI 3. If the response has a Content-Location header field, and that URI
is the same as the effective request URI, the response payload is is the same as the effective request URI, the response payload is
a representation of the target resource. a representation of the target resource.
4. If the response has a Content-Location header field, and that URI 4. If the response has a Content-Location header field, and that URI
is 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
skipping to change at page 14, line 47 skipping to change at page 14, line 40
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
like cache invalidation.]] like cache invalidation.]]
7. Method Definitions 7. Method Definitions
The set of common methods for HTTP/1.1 is defined below. Although The set of common request methods for HTTP/1.1 is defined below.
this set can be expanded, additional methods cannot be assumed to Although this set can be expanded, additional methods cannot be
share the same semantics for separately extended clients and servers. assumed to share the same semantics for separately extended clients
and servers.
7.1. Safe and Idempotent Methods 7.1. Safe and Idempotent Methods
7.1.1. Safe Methods 7.1.1. Safe Methods
Implementors need to be aware that the software represents the user Implementors need to be aware that the software represents the user
in their interactions over the Internet, and need to allow the user in their interactions over the Internet, and need to allow the user
to be aware of any actions they take which might have an unexpected to be aware of any actions they take which might have an unexpected
significance to themselves or others. significance to themselves or others.
In particular, the convention has been established that the GET, In particular, the convention has been established that the GET,
HEAD, OPTIONS, and TRACE methods SHOULD NOT have the significance of HEAD, OPTIONS, and TRACE request methods SHOULD NOT have the
taking an action other than retrieval. These methods ought to be significance of taking an action other than retrieval. These request
considered "safe". This allows user agents to represent other methods ought to be considered "safe". This allows user agents to
methods, such as POST, PUT and DELETE, in a special way, so that the represent other methods, such as POST, PUT and DELETE, in a special
user is made aware of the fact that a possibly unsafe action is being way, so that the user is made aware of the fact that a possibly
requested. unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not Naturally, it is not possible to ensure that the server does not
generate side-effects as a result of performing a GET request; in generate side-effects as a result of performing a GET request; in
fact, some dynamic resources consider that a feature. The important fact, some dynamic resources consider that a feature. The important
distinction here is that the user did not request the side-effects, distinction here is that the user did not request the side-effects,
so therefore cannot be held accountable for them. so therefore cannot be held accountable for them.
7.1.2. Idempotent Methods 7.1.2. Idempotent Methods
Methods can also have the property of "idempotence" in that, aside Request methods can also have the property of "idempotence" in that,
from error or expiration issues, the intended effect of multiple aside from error or expiration issues, the intended effect of
identical requests is the same as for a single request. The methods multiple identical requests is the same as for a single request.
PUT, DELETE, and all safe methods are idempotent. It is important to PUT, DELETE, and all safe request methods are idempotent. It is
note that idempotence refers only to changes requested by the client: important to note that idempotence refers only to changes requested
a server is free to change its state due to multiple requests for the by the client: a server is free to change its state due to multiple
purpose of tracking those requests, versioning of results, etc. requests for the purpose of tracking those requests, versioning of
results, etc.
7.2. OPTIONS 7.2. OPTIONS
The OPTIONS method represents a request for information about the The OPTIONS method requests information about the communication
communication options available on the request/response chain options available on the request/response chain identified by the
identified by the effective request URI. This method allows the effective request URI. This method allows a client to determine the
client to determine the options and/or requirements associated with a options and/or requirements associated with a resource, or the
resource, or the capabilities of a server, without implying a capabilities of a server, without implying a resource action or
resource action or initiating a resource retrieval. initiating a resource retrieval.
Responses to this method are not cacheable. Responses to the OPTIONS method are not cacheable.
If the OPTIONS request includes a message-body (as indicated by the If the OPTIONS request includes a message-body (as indicated by the
presence of Content-Length or Transfer-Encoding), then the media type presence of Content-Length or Transfer-Encoding), then the media type
MUST be indicated by a Content-Type field. Although this MUST be indicated by a Content-Type field. Although this
specification does not define any use for such a body, future specification does not define any use for such a body, future
extensions to HTTP might use the OPTIONS body to make more detailed extensions to HTTP might use the OPTIONS body to make more detailed
queries on the server. queries on the server.
If the request-target is an asterisk ("*"), the OPTIONS request is If the request-target is an asterisk ("*"), the OPTIONS request is
intended to apply to the server in general rather than to a specific intended to apply to the server in general rather than to a specific
skipping to change at page 16, line 30 skipping to change at page 16, line 22
optional features implemented by the server and applicable to that optional features implemented by the server and applicable to that
resource (e.g., Allow), possibly including extensions not defined by resource (e.g., Allow), possibly including extensions not defined by
this specification. The response body, if any, SHOULD also include this specification. The response body, if any, SHOULD also include
information about the communication options. The format for such a information about the communication options. The format for such a
body is not defined by this specification, but might be defined by body is not defined by this specification, but might be defined by
future extensions to HTTP. Content negotiation MAY be used to select future extensions to HTTP. Content negotiation MAY be used to select
the appropriate response format. If no response body is included, the appropriate response format. If no response body is included,
the response MUST include a Content-Length field with a field-value the response MUST include a Content-Length field with a field-value
of "0". of "0".
The Max-Forwards request-header field MAY be used to target a The Max-Forwards header field MAY be used to target a specific proxy
specific proxy in the request chain (see Section 9.5). If no Max- in the request chain (see Section 9.5). If no Max-Forwards field is
Forwards field is present in the request, then the forwarded request present in the request, then the forwarded request MUST NOT include a
MUST NOT include a Max-Forwards field. Max-Forwards field.
7.3. GET 7.3. GET
The GET method means retrieve whatever information (in the form of a The GET method requests transfer of a current representation of the
representation) currently corresponds to the target resource. target resource.
If the target resource is a data-producing process, it is the If the target resource is a data-producing process, it is the
produced data which shall be returned as the representation in the produced data which shall be returned as the representation in the
response and not the source text of the process, unless that text response and not the source text of the process, unless that text
happens to be the output of the process. happens to be the output of the process.
The semantics of the GET method change to a "conditional GET" if the The semantics of the GET method change to a "conditional GET" if the
request message includes an If-Modified-Since, If-Unmodified-Since, request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the representation be transferred only under the requests that the representation be transferred only under the
circumstances described by the conditional header field(s). The circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network conditional GET request is intended to reduce unnecessary network
usage by allowing cached representations to be refreshed without usage by allowing cached representations to be refreshed without
requiring multiple requests or transferring data already held by the requiring multiple requests or transferring data already held by the
client. client.
The semantics of the GET method change to a "partial GET" if the The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field. A partial GET request message includes a Range header field. A partial GET
requests that only part of the representation be transferred, as requests that only part of the representation be transferred, as
described in Section 5.4 of [Part5]. The partial GET method is described in Section 5.4 of [Part5]. The partial GET request is
intended to reduce unnecessary network usage by allowing partially- intended to reduce unnecessary network usage by allowing partially-
retrieved representations to be completed without transferring data retrieved representations to be completed without transferring data
already held by the client. already held by the client.
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
skipping to change at page 17, line 41 skipping to change at page 17, line 33
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
The POST method is used to request that the origin server accept the The POST method requests that the origin server accept the
representation enclosed in the request as data to be processed by the representation enclosed in the request as data to be processed by the
target resource. POST is designed to allow a uniform method to cover target resource. POST is designed to allow a uniform method to cover
the following functions: the following functions:
o Annotation of existing resources; o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles; similar group of articles;
o Providing a block of data, such as the result of submitting a o Providing a block of data, such as the result of submitting a
skipping to change at page 18, line 36 skipping to change at page 18, line 26
cached POST response with a Content-Location header field (see cached POST response with a Content-Location header field (see
Section 6.7 of [Part3]) whose value is the effective Request URI MAY Section 6.7 of [Part3]) whose value is the effective Request URI MAY
be used to 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 state of the target resource be
the effective request URI. If the effective request URI refers to an created or replaced with the state defined by the representation
already existing resource, the enclosed representation SHOULD be enclosed in the request message payload. A successful PUT of a given
considered a modified version of the one residing on the origin representation would suggest that a subsequent GET on that same
server. Otherwise, if the effective request URI does not point to an target resource will result in an equivalent representation being
existing resource, and that URI is capable of being defined as a new returned in a 200 (OK) response. However, there is no guarantee that
resource by the requesting user agent, the origin server can create such a state change will be observable, since the target resource
the resource with that URI. might be acted upon by other user agents in parallel, or might be
subject to dynamic processing by the origin server, before any
subsequent GET is received. A successful response only implies that
the user agent's intent was achieved at the time of its processing by
the origin server.
If a new resource is created at the effective request URI, the origin If the target resource does not have a current representation and the
server MUST inform the user agent via the 201 (Created) response. If PUT successfully creates one, then the origin server MUST inform the
an existing resource is modified, either the 200 (OK) or 204 (No user agent by sending a 201 (Created) response. If the target
Content) response codes SHOULD be sent to indicate successful resource does have a current representation and that representation
completion of the request. is successfully modified in accordance with the state of the enclosed
representation, then either a 200 (OK) or 204 (No Content) response
SHOULD be sent to indicate successful completion of the request.
If the target resource could not be created or modified, an Unrecognized header fields SHOULD be ignored (i.e., not saved as part
appropriate error response SHOULD be given that reflects the nature of the resource state).
of the problem. The recipient of the representation MUST NOT ignore
any Content-* header fields (headers starting with the prefix
"Content-") that it does not understand or implement and MUST return
a 501 (Not Implemented) response in such cases.
If the request passes through a cache that has one or more stored An origin server SHOULD verify that the PUT representation is
responses for the effective request URI, those stored responses consistent with any constraints which the server has for the target
SHOULD be marked as stale if the response to the PUT request has a resource that cannot or will not be changed by the PUT. This is
success status code. Responses to the PUT method are not cacheable. particularly important when the origin server uses internal
configuration information related to the URI in order to set the
values for representation metadata on GET responses. When a PUT
representation is inconsistent with the target resource, the origin
server SHOULD either make them consistent, by transforming the
representation or changing the resource configuration, or respond
with an appropriate error message containing sufficient information
to explain why the representation is unsuitable. The 409 (Conflict)
or 415 (Unsupported Media Type) status codes are suggested, with the
latter being specific to constraints on Content-Type values.
The fundamental difference between the POST and PUT requests is For example, if the target resource is configured to always have a
reflected in the different meaning of the effective request URI. The Content-Type of "text/html" and the representation being PUT has a
URI in a POST request identifies the resource that will handle the Content-Type of "image/jpeg", then the origin server SHOULD do one
enclosed representation. That resource might be a data-accepting of: (a) reconfigure the target resource to reflect the new media
process, a gateway to some other protocol, or a document that accepts type; (b) transform the PUT representation to a format consistent
annotations. In contrast, the URI in a PUT request identifies the with that of the resource before saving it as the new resource state;
resource for which enclosed representation is a new or replacement or, (c) reject the request with a 415 response indicating that the
value; the user agent knows what URI is intended and the server MUST target resource is limited to "text/html", perhaps including a link
NOT attempt to apply the request to some other resource. If the to a different resource that would be a suitable target for the new
server desires that the request be applied to a different URI, it representation.
MUST send a 301 (Moved Permanently) response; the user agent MAY then
make its own decision regarding whether or not to redirect the
request.
A single resource MAY be identified by many different URIs. For HTTP does not define exactly how a PUT method affects the state of an
example, an article might have a URI for identifying "the current origin server beyond what can be expressed by the intent of the user
version" which is separate from the URI identifying each particular agent request and the semantics of the origin server response. It
version. In this case, a PUT request on a general URI might result does not define what a resource might be, in any sense of that word,
in several other URIs being defined by the origin server. beyond the interface provided via HTTP. It does not define how
resource state is "stored", nor how such storage might change as a
result of a change in resource state, nor how the origin server
translates resource state into representations. Generally speaking,
all implementation details behind the resource interface are
intentionally hidden by the server.
HTTP/1.1 does not define how a PUT method affects the state of an The fundamental difference between the POST and PUT methods is
origin server. highlighted by the different intent for the target resource. The
target resource in a POST request is intended to handle the enclosed
representation as a data-accepting process, such as for a gateway to
some other protocol or a document that accepts annotations. In
contrast, the target resource in a PUT request is intended to take
the enclosed representation as a new or replacement value. Hence,
the intent of PUT is idempotent and visible to intermediaries, even
though the exact effect is only known by the origin server.
Header fields in a PUT request that are recognized as representation Proper interpretation of a PUT request presumes that the user agent
metadata SHOULD be applied to the resource created or modified by the knows what target resource is desired. A service that is intended to
PUT. Unrecognized header fields SHOULD be ignored. select a proper URI on behalf of the client, after receiving a state-
changing request, SHOULD be implemented using the POST method rather
than PUT. If the origin server will not make the requested PUT state
change to the target resource and instead wishes to have it applied
to a different resource, such as when the resource has been moved to
a different URI, then the origin server MUST send a 301 (Moved
Permanently) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request.
A PUT request applied to the target resource MAY have side-effects on
other resources. For example, an article might have a URI for
identifying "the current version" (a resource) which is separate from
the URIs identifying each particular version (different resources
that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be
added between the related resources.
An origin server SHOULD reject any PUT request that contains a
Content-Range header field, since it might be misinterpreted as
partial content (or might be partial content that is being mistakenly
PUT as a full representation). Partial content updates are possible
by targeting a separately identified resource with state that
overlaps a portion of the larger resource, or by using a different
method that has been specifically defined for partial updates (for
example, the PATCH method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a PUT request
passes through a cache that has one or more stored responses for the
effective request URI, those stored responses will be invalidated
(see Section 2.5 of [Part6]).
7.7. DELETE 7.7. DELETE
The DELETE method requests that the origin server delete the target The DELETE method requests that the origin server delete the target
resource. This method MAY be overridden by human intervention (or resource. This method MAY be overridden by human intervention (or
other means) on the origin server. The client cannot be guaranteed other means) on the origin server. The client cannot be guaranteed
that the operation has been carried out, even if the status code that the operation has been carried out, even if the status code
returned from the origin server indicates that the action has been returned from the origin server indicates that the action has been
completed successfully. However, the server SHOULD NOT indicate completed successfully. However, the server SHOULD NOT indicate
success unless, at the time the response is given, it intends to success unless, at the time the response is given, it intends to
delete the resource or move it to an inaccessible location. delete the resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an A successful response SHOULD be 200 (OK) if the response includes an
representation describing the status, 202 (Accepted) if the action representation describing the status, 202 (Accepted) if the action
has not yet been enacted, or 204 (No Content) if the action has been has not yet been enacted, or 204 (No Content) if the action has been
enacted but the response does not include a representation. enacted but the response does not include a representation.
If the request passes through a cache and the effective request URI Responses to the DELETE method are not cacheable. If a DELETE
identifies one or more currently cached representations, those request passes through a cache that has one or more stored responses
entries SHOULD be treated as stale. Responses to the DELETE method for the effective request URI, those stored responses will be
are not cacheable. invalidated (see Section 2.5 of [Part6]).
7.8. TRACE 7.8. TRACE
The TRACE method is used to invoke a remote, application-layer loop- The TRACE method requests a remote, application-layer loop-back of
back of the request message. The final recipient of the request the request message. The final recipient of the request SHOULD
SHOULD reflect the message received back to the client as the reflect the message received back to the client as the message-body
message-body of a 200 (OK) response. The final recipient is either of a 200 (OK) response. The final recipient is either the origin
the origin server or the first proxy or gateway to receive a Max- server or the first proxy to receive a Max-Forwards value of zero (0)
Forwards value of zero (0) in the request (see Section 9.5). A TRACE in the request (see Section 9.5). A TRACE request MUST NOT include a
request MUST NOT include a message-body. message-body.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 9.9 of information. The value of the Via header field (Section 9.9 of
[Part1]) is of particular interest, since it acts as a trace of the [Part1]) is of particular interest, since it acts as a trace of the
request chain. Use of the Max-Forwards header field allows the request chain. Use of the Max-Forwards header field allows the
client to limit the length of the request chain, which is useful for client to limit the length of the request chain, which is useful for
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
If the request is valid, the response SHOULD have a Content-Type of If the request is valid, the response SHOULD have a Content-Type of
"message/http" (see Section 10.3.1 of [Part1]) and contain a message- "message/http" (see Section 10.3.1 of [Part1]) and contain a message-
body that encloses a copy of the entire request message. Responses body that encloses a copy of the entire request message. Responses
to the TRACE method are not cacheable. to the TRACE method are not cacheable.
7.9. CONNECT 7.9. CONNECT
This specification reserves the method name CONNECT for use with a The CONNECT method requests that the proxy establish a tunnel to the
proxy that can dynamically switch to being a tunnel (e.g., SSL request-target and then restrict its behavior to blind forwarding of
tunneling [RFC2817]). packets until the connection is closed.
When using CONNECT, the request-target MUST use the authority form
(Section 4.1.2 of [Part1]); i.e., the request-target consists of only
the host name and port number of the tunnel destination, separated by
a colon. For example,
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Other HTTP mechanisms can be used normally with the CONNECT method --
except end-to-end protocol Upgrade requests, since the tunnel must be
established first.
For example, proxy authentication might be used to establish the
authority to create a tunnel:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
Like any other pipelined HTTP/1.1 request, data to be tunnel may be
sent immediately after the blank line. The usual caveats also apply:
data may be discarded if the eventual response is negative, and the
connection may be reset with no response if more than one TCP segment
is outstanding.
7.9.1. Establishing a Tunnel with CONNECT
Any successful (2xx) response to a CONNECT request indicates that the
proxy has established a connection to the requested host and port,
and has switched to tunneling the current connection to that server
connection.
It may be the case that the proxy itself can only reach the requested
origin server through another proxy. In this case, the first proxy
SHOULD make a CONNECT request of that next proxy, requesting a tunnel
to the authority. A proxy MUST NOT respond with any 2xx status code
unless it has either a direct or tunnel connection established to the
authority.
An origin server which receives a CONNECT request for itself MAY
respond with a 2xx status code to indicate that a connection is
established.
If at any point either one of the peers gets disconnected, any
outstanding data that came from that peer will be passed to the other
one, and after that also the other connection will be terminated by
the proxy. If there is outstanding data to that peer undelivered,
that data will be discarded.
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 header fields, and is consisting only of the Status-Line and optional header fields, and is
skipping to change at page 24, line 4 skipping to change at page 25, line 47
The 204 response MUST NOT include a message-body, and thus is always The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields. terminated by the first empty line after the header fields.
8.2.6. 205 Reset Content 8.2.6. 205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset The server has fulfilled the request and the user agent SHOULD reset
the document view which caused the request to be sent. This response the document view which caused the request to be sent. This response
is primarily intended to allow input for actions to take place via is primarily intended to allow input for actions to take place via
user input, followed by a clearing of the form in which the input is user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The given so that the user can easily initiate another input action.
response MUST NOT include a message-body.
The message-body included with the response MUST be empty. Note that
receivers still need to parse the response according to the algorithm
defined in Section 3.3 of [Part1].
8.2.7. 206 Partial Content 8.2.7. 206 Partial Content
The server has fulfilled the partial GET request for the resource and The server has fulfilled the partial GET request for the resource and
the enclosed payload is a partial representation as defined in the enclosed payload is a partial representation as defined in
Section 3.1 of [Part5]. Section 3.1 of [Part5].
Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
determine freshness for 206 responses. determine freshness for 206 responses.
skipping to change at page 30, line 42 skipping to change at page 32, line 42
8.4.12. 411 Length Required 8.4.12. 411 Length Required
The server refuses to accept the request without a defined Content- The server refuses to accept the request without a defined Content-
Length. The client MAY repeat the request if it adds a valid Length. The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the message-body Content-Length header field containing the length of the message-body
in the request message. in the request message.
8.4.13. 412 Precondition Failed 8.4.13. 412 Precondition Failed
The precondition given in one or more of the request-header fields The precondition given in one or more of the header fields evaluated
evaluated to false when it was tested on the server, as defined in to false when it was tested on the server, as defined in Section 3.2
Section 3.2 of [Part4]. of [Part4].
8.4.14. 413 Request Entity Too Large 8.4.14. 413 Request Entity Too Large
The server is refusing to process a request because the request The server is refusing to process a request because the request
representation is larger than the server is willing or able to representation is larger than the server is willing or able to
process. The server MAY close the connection to prevent the client process. The server MAY close the connection to prevent the client
from continuing the request. from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
skipping to change at page 31, line 23 skipping to change at page 33, line 23
rare condition is only likely to occur when a client has improperly rare condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query converted a POST request to a GET request with long query
information, when the client has descended into a URI "black hole" of information, when the client has descended into a URI "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the effective request URI. buffers for reading or manipulating the effective request URI.
8.4.16. 415 Unsupported Media Type 8.4.16. 415 Unsupported Media Type
The server is refusing to service the request because the The server is refusing to service the request because the request
representation of the request is in a format not supported by the payload is in a format not supported by this request method on the
target resource for the requested method. target resource.
8.4.17. 416 Requested Range Not Satisfiable 8.4.17. 416 Requested Range Not Satisfiable
The request included a Range request-header field (Section 5.4 of The request included a Range header field (Section 5.4 of [Part5])
[Part5]) and none of the range-specifier values in this field overlap and none of the range-specifier values in this field overlap the
the current extent of the selected resource. See Section 3.2 of current extent of the selected resource. See Section 3.2 of [Part5].
[Part5].
8.4.18. 417 Expectation Failed 8.4.18. 417 Expectation Failed
The expectation given in an Expect request-header field (see The expectation given in an Expect header field (see Section 9.2)
Section 9.2) could not be met by this server, or, if the server is a could not be met by this server, or, if the server is a proxy, the
proxy, the server has unambiguous evidence that the request could not server has unambiguous evidence that the request could not be met by
be met by the next-hop server. the next-hop server.
8.4.19. 426 Upgrade Required
The request can not be completed without a prior protocol upgrade.
This response MUST include an Upgrade header field (Section 9.8 of
[Part1]) specifying the required protocols.
Example:
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/2.0
Connection: Upgrade
The server SHOULD include a message body in the 426 response which
indicates in human readable form the reason for the error and
describes any alternative courses which may be available to the user.
8.5. Server Error 5xx 8.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of which the server is aware that it has erred or is incapable of
performing the request. Except when responding to a HEAD request, performing the request. Except when responding to a HEAD request,
the server SHOULD include a representation containing an explanation the server SHOULD include a representation containing an explanation
of the error situation, and whether it is a temporary or permanent of the error situation, and whether it is a temporary or permanent
condition. User agents SHOULD display any included representation to condition. User agents SHOULD display any included representation to
the user. These response codes are applicable to any request method. the user. These response codes are applicable to any request method.
skipping to change at page 33, line 14 skipping to change at page 35, line 32
SHOULD contain a representation describing why that version is not SHOULD contain a representation describing why that version is not
supported and what other protocols are supported by that server. supported and what other protocols are supported by that server.
9. Header Field Definitions 9. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to request and response semantics. fields related to request and response semantics.
9.1. Allow 9.1. Allow
The "Allow" response-header field lists the set of methods advertised The "Allow" header field lists the set of methods advertised as
as supported by the target resource. The purpose of this field is supported by the target resource. The purpose of this field is
strictly to inform the recipient of valid methods associated with the strictly to inform the recipient of valid request methods associated
resource. with the resource.
Allow = "Allow" ":" OWS Allow-v Allow = "Allow" ":" OWS Allow-v
Allow-v = #Method Allow-v = #Method
Example of use: Example of use:
Allow: GET, HEAD, PUT Allow: GET, HEAD, PUT
The actual set of allowed methods is defined by the origin server at The actual set of allowed methods is defined by the origin server at
the time of each request. the time of each request.
A proxy MUST NOT modify the Allow header field even if it does not A proxy MUST NOT modify the Allow header field -- it does not need to
understand all the methods specified, since the user agent might have understand all the methods specified in order to handle them
other means of communicating with the origin server. according to the generic message handling rules.
9.2. Expect 9.2. Expect
The "Expect" request-header field is used to indicate that particular The "Expect" header field is used to indicate that particular server
server behaviors are required by the client. behaviors are required by the client.
Expect = "Expect" ":" OWS Expect-v Expect = "Expect" ":" OWS Expect-v
Expect-v = 1#expectation Expect-v = 1#expectation
expectation = "100-continue" / expectation-extension expectation = "100-continue" / expectation-extension
expectation-extension = token [ "=" ( token / quoted-string ) expectation-extension = token [ "=" ( token / quoted-string )
*expect-params ] *expect-params ]
expect-params = ";" token [ "=" ( token / quoted-string ) ] expect-params = ";" token [ "=" ( token / quoted-string ) ]
A server that does not understand or is unable to comply with any of A server that does not understand or is unable to comply with any of
skipping to change at page 34, line 17 skipping to change at page 36, line 37
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 field itself is end-to-end; it MUST be forwarded if header field itself is end-to-end; it MUST be forwarded if the
the request is forwarded. request is forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header field. 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" header field, if given, SHOULD contain an Internet e-mail
e-mail address for the human user who controls the requesting user address for the human user who controls the requesting user agent.
agent. The address SHOULD be machine-usable, as defined by "mailbox" The address SHOULD be machine-usable, as defined by "mailbox" in
in Section 3.4 of [RFC5322]: Section 3.4 of [RFC5322]:
From = "From" ":" OWS From-v From = "From" ":" OWS From-v
From-v = mailbox From-v = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: webmaster@example.org
skipping to change at page 35, line 15 skipping to change at page 37, line 36
used. used.
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
9.4. Location 9.4. Location
The "Location" response-header field is used to identify a newly The "Location" header field is used to identify a newly created
created resource, or to redirect the recipient to a different resource, or to redirect the recipient to a different location for
location for completion of the request. completion of the request.
For 201 (Created) responses, the Location is the URI of the new For 201 (Created) responses, the Location is the URI of the new
resource which was created by the request. For 3xx responses, the resource which was created by the request. For 3xx responses, the
location SHOULD indicate the server's preferred URI for automatic location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. redirection to the resource.
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI value is computed by resolving it against the effective request URI
([RFC3986], Section 5). ([RFC3986], Section 5).
skipping to change at page 35, line 49 skipping to change at page 38, line 22
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 field 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. Thus be aware that including fragment identifiers
might inconvenience anyone relying on the semantics of the
original URI's fragment identifier.
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
most specific resource corresponding to the enclosed most specific resource corresponding to the enclosed
representation. It is therefore possible for a response to representation. It is therefore possible for a response to
contain header fields for both Location and Content-Location. contain header fields for both Location and Content-Location.
9.5. Max-Forwards 9.5. Max-Forwards
The "Max-Forwards" request-header field provides a mechanism with the The "Max-Forwards" header field provides a mechanism with the TRACE
TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number
number of times that the request is forwarded by proxies or gateways. of times that the request is forwarded by proxies. This can be
This can be useful when the client is attempting to trace a request useful when the client is attempting to trace a request which appears
which appears to be failing or looping in mid-chain. to be failing or looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v
Max-Forwards-v = 1*DIGIT Max-Forwards-v = 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message can be forwarded. number of times this request message can be forwarded.
Each proxy or gateway recipient of a TRACE or OPTIONS request Each recipient of a TRACE or OPTIONS request containing a Max-
containing a Max-Forwards header field MUST check and update its Forwards header field MUST check and update its value prior to
value prior to forwarding the request. If the received value is zero forwarding the request. If the received value is zero (0), the
(0), the recipient MUST NOT forward the request; instead, it MUST recipient MUST NOT forward the request; instead, it MUST respond as
respond as the final recipient. If the received Max-Forwards value the final recipient. If the received Max-Forwards value is greater
is greater than zero, then the forwarded message MUST contain an than zero, then the forwarded message MUST contain an updated Max-
updated Max-Forwards field with a value decremented by one (1). Forwards field with a value decremented by one (1).
The Max-Forwards header field MAY be ignored for all other methods The Max-Forwards header field MAY be ignored for all other request
defined by this specification and for any extension methods for which methods.
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] header field allows the client to specify the URI
the URI of the resource from which the effective request URI was of the resource from which the effective request URI was obtained
obtained (the "referrer", although the header field is misspelled.). (the "referrer", although the header field is misspelled.).
The Referer header field allows servers to generate lists of back- The Referer header field allows servers to generate lists of back-
links to resources for interest, logging, optimized caching, etc. It links to resources for interest, logging, optimized caching, etc. It
also allows obsolete or mistyped links to be traced for maintenance. also allows obsolete or mistyped links to be traced for maintenance.
Some servers use Referer as a means of controlling where they allow Some servers use Referer as a means of controlling where they allow
links 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
skipping to change at page 37, line 20 skipping to change at page 39, line 40
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the effective request URI. The URI MUST NOT include a relative to the effective request URI. The URI MUST NOT include a
fragment. See Section 11.2 for security considerations. fragment. See Section 11.2 for security considerations.
9.7. Retry-After 9.7. Retry-After
The response-header "Retry-After" field can be used with a 503 The header "Retry-After" field can be used with a 503 (Service
(Service Unavailable) response to indicate how long the service is Unavailable) response to indicate how long the service is expected to
expected to be unavailable to the requesting client. This field MAY be unavailable to the requesting client. This field MAY also be used
also be used with any 3xx (Redirection) response to indicate the with any 3xx (Redirection) response to indicate the minimum time the
minimum time the user-agent is asked wait before issuing the user-agent is asked wait before issuing the redirected request.
redirected request.
The value of this field can be either an HTTP-date or an integer The value of this field can be either an HTTP-date or an integer
number of seconds (in decimal) after the time of the response. number of seconds (in decimal) after the time of the response.
Retry-After = "Retry-After" ":" OWS Retry-After-v Retry-After = "Retry-After" ":" OWS Retry-After-v
Retry-After-v = HTTP-date / delta-seconds Retry-After-v = HTTP-date / delta-seconds
Time spans are non-negative decimal integers, representing time in Time spans are non-negative decimal integers, representing time in
seconds. seconds.
skipping to change at page 37, line 47 skipping to change at page 40, line 17
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
9.8. Server 9.8. Server
The "Server" response-header field contains information about the The "Server" header field contains information about the software
software used by the origin server to handle the request. used by the origin server to handle the request.
The field can contain multiple product tokens (Section 6.3 of The field can contain multiple product tokens (Section 6.3 of
[Part1]) and comments (Section 3.2 of [Part1]) identifying the server [Part1]) and comments (Section 3.2 of [Part1]) identifying the server
and any significant subproducts. The product tokens are listed in and any significant subproducts. The product tokens are listed in
order of their significance for identifying the application. order of their significance for identifying the application.
Server = "Server" ":" OWS Server-v Server = "Server" ":" OWS Server-v
Server-v = product Server-v = product
*( RWS ( product / comment ) ) *( RWS ( product / comment ) )
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header field. application MUST NOT modify the Server header field. Instead, it
Instead, it MUST include a Via field (as described in Section 9.9 of MUST include a Via field (as described in Section 9.9 of [Part1]).
[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" header field contains information about the user
user agent originating the request. User agents SHOULD include this agent originating the request. User agents SHOULD include this field
field with requests. with requests.
Typically, it is used for statistical purposes, the tracing of Typically, it is used for statistical purposes, the tracing of
protocol violations, and tailoring responses to avoid particular user protocol violations, and tailoring responses to avoid particular user
agent limitations. agent limitations.
The field can contain multiple product tokens (Section 6.3 of The field can contain multiple product tokens (Section 6.3 of
[Part1]) and comments (Section 3.2 of [Part1]) identifying the agent [Part1]) and comments (Section 3.2 of [Part1]) identifying the agent
and its significant subproducts. By convention, the product tokens and its significant subproducts. By convention, the product tokens
are listed in order of their significance for identifying the are listed in order of their significance for identifying the
application. application.
skipping to change at page 39, line 8 skipping to change at page 41, line 25
field values make requests larger and can also be used to identify field values make requests larger and can also be used to identify
("fingerprint") the user against their wishes. ("fingerprint") the user against their wishes.
Likewise, implementations are encouraged not to use the product Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. Finally, with them, as this circumvents the purpose of the field. Finally,
they are encouraged not to use comments to identify products; doing they are encouraged not to use comments to identify products; doing
so makes the field value more difficult to parse. 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
10.1. Method Registry 10.1. Method Registry
The registration procedure for HTTP Methods is defined by Section 2.1 The registration procedure for HTTP request methods is defined by
of this document. Section 2.2 of this document.
The HTTP Method Registry shall be created at The HTTP Method Registry shall be created at
<http://www.iana.org/assignments/http-methods> and be populated with <http://www.iana.org/assignments/http-methods> and be populated with
the registrations below: the registrations below:
+---------+------+-------------+ +---------+------+-------------+
| Method | Safe | Reference | | Method | Safe | Reference |
+---------+------+-------------+ +---------+------+-------------+
| CONNECT | no | Section 7.9 | | CONNECT | no | Section 7.9 |
| DELETE | no | Section 7.7 | | DELETE | no | Section 7.7 |
skipping to change at page 39, line 42 skipping to change at page 42, line 21
| HEAD | yes | Section 7.4 | | HEAD | yes | Section 7.4 |
| OPTIONS | yes | Section 7.2 | | OPTIONS | yes | Section 7.2 |
| POST | no | Section 7.5 | | POST | no | Section 7.5 |
| PUT | no | Section 7.6 | | PUT | no | Section 7.6 |
| TRACE | yes | Section 7.8 | | TRACE | yes | Section 7.8 |
+---------+------+-------------+ +---------+------+-------------+
10.2. Status Code Registry 10.2. Status Code Registry
The registration procedure for HTTP Status Codes -- previously The registration procedure for HTTP Status Codes -- previously
defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.2
of this document. of this document.
The HTTP Status Code Registry located at The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> shall be updated <http://www.iana.org/assignments/http-status-codes> shall be updated
with the registrations below: with the registrations below:
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| 100 | Continue | Section 8.1.1 | | 100 | Continue | Section 8.1.1 |
skipping to change at page 40, line 38 skipping to change at page 43, line 38
| 406 | Not Acceptable | Section 8.4.7 | | 406 | Not Acceptable | Section 8.4.7 |
| 407 | Proxy Authentication Required | Section 8.4.8 | | 407 | Proxy Authentication Required | Section 8.4.8 |
| 408 | Request Timeout | Section 8.4.9 | | 408 | Request Timeout | Section 8.4.9 |
| 409 | Conflict | Section 8.4.10 | | 409 | Conflict | Section 8.4.10 |
| 410 | Gone | Section 8.4.11 | | 410 | Gone | Section 8.4.11 |
| 411 | Length Required | Section 8.4.12 | | 411 | Length Required | Section 8.4.12 |
| 413 | Request Entity Too Large | Section 8.4.14 | | 413 | Request Entity Too Large | Section 8.4.14 |
| 414 | URI Too Long | Section 8.4.15 | | 414 | URI Too Long | Section 8.4.15 |
| 415 | Unsupported Media Type | Section 8.4.16 | | 415 | Unsupported Media Type | Section 8.4.16 |
| 417 | Expectation Failed | Section 8.4.18 | | 417 | Expectation Failed | Section 8.4.18 |
| 426 | Upgrade Required | Section 8.4.19 |
| 500 | Internal Server Error | Section 8.5.1 | | 500 | Internal Server Error | Section 8.5.1 |
| 501 | Not Implemented | Section 8.5.2 | | 501 | Not Implemented | Section 8.5.2 |
| 502 | Bad Gateway | Section 8.5.3 | | 502 | Bad Gateway | Section 8.5.3 |
| 503 | Service Unavailable | Section 8.5.4 | | 503 | Service Unavailable | Section 8.5.4 |
| 504 | Gateway Timeout | Section 8.5.5 | | 504 | Gateway Timeout | Section 8.5.5 |
| 505 | HTTP Version Not Supported | Section 8.5.6 | | 505 | HTTP Version Not Supported | Section 8.5.6 |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
10.3. Header Field Registration 10.3. Header Field Registration
skipping to change at page 42, line 30 skipping to change at page 45, line 30
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 Furthermore, the User-Agent header field may contain enough entropy
to be used, possibly in conjunction with other material, to uniquely to be used, possibly in conjunction with other material, to uniquely
identify the user. identify the user.
Some methods, like TRACE (Section 7.8), expose information that was Some request methods, like TRACE (Section 7.8), expose information
sent in request header fields within the body of their response. that was sent in request header fields within the body of their
Clients SHOULD be careful with sensitive information, like Cookies, response. Clients SHOULD be careful with sensitive information, like
Authorization credentials and other header fields that might be used Cookies, Authorization credentials, and other header fields that
to collect data from the client. might be used to collect data from the client.
11.2. Encoding Sensitive Information in URIs 11.2. Encoding Sensitive Information in URIs
Because the source of a link might be private information or might Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From respectively enable/disable the sending of Referer and From
information. information.
skipping to change at page 43, line 17 skipping to change at page 46, line 17
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 header fields in responses that are generated under control Location header fields in responses that are generated under control
of 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.
11.4. Security Considerations for CONNECT
Since tunneled data is opaque to the proxy, there are additional
risks to tunneling to other well-known or reserved ports. A HTTP
client CONNECTing to port 25 could relay spam via SMTP, for example.
As such, proxies SHOULD restrict CONNECT access to a small number of
known ports.
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-12 and Message Parsing", draft-ietf-httpbis-p1-messaging-13
(work in progress), October 2010. (work in progress), March 2011.
[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-12 and Content Negotiation", draft-ietf-httpbis-p3-payload-13
(work in progress), October 2010. (work in progress), March 2011.
[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-12 (work in Requests", draft-ietf-httpbis-p4-conditional-13 (work in
progress), October 2010. progress), March 2011.
[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-12 (work Partial Responses", draft-ietf-httpbis-p5-range-13 (work
in progress), October 2010. in progress), March 2011.
[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-12 (work in 6: Caching", draft-ietf-httpbis-p6-cache-13 (work in
progress), October 2010. progress), March 2011.
[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-12 (work in progress), draft-ietf-httpbis-p7-auth-13 (work in progress),
October 2010. March 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 44, line 48 skipping to change at page 48, line 8
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010.
Appendix A. Changes from RFC 2616 Appendix A. Changes from RFC 2616
This document takes over the Status Code Registry, previously defined This document takes over the Status Code Registry, previously defined
in Section 7.1 of [RFC2817]. (Section 4.1) in Section 7.1 of [RFC2817]. (Section 4.2)
Clarify definition of POST. (Section 7.5) Clarify definition of POST. (Section 7.5)
Remove requirement to handle all Content-* header fields; ban use of
Content-Range with PUT. (Section 7.6)
Take over definition of CONNECT method from [RFC2817]. (Section 7.9)
Failed to consider that there are many other request methods that are Failed to consider that there are many other request methods that are
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)
Define status 426 (Upgrade Required) (this was incorporated from
[RFC2817]). (Section 8.4.19)
Reclassify "Allow" as response header field, removing the option to Reclassify "Allow" as response header field, removing the option to
specify it in a PUT request. Relax the server requirement on the specify it in a PUT request. Relax the server requirement on the
contents of the Allow header field and remove requirement on clients contents of the Allow header field and remove requirement on clients
to always trust the header field value. (Section 9.1) to always trust the header field value. (Section 9.1)
Correct syntax of Location header field to allow URI references Correct syntax of Location header field to allow URI references
(including relative references and fragments), as referred symbol (including relative references and fragments), as referred symbol
"absoluteURI" wasn't what was expected, and add some clarifications "absoluteURI" wasn't what was expected, and add some clarifications
as to when use of fragments would not be appropriate. (Section 9.4) as to when use of fragments would not be appropriate. (Section 9.4)
Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
extension methods could have used it as well). (Section 9.5)
Allow Referer field value of "about:blank" as alternative to not Allow Referer field value of "about:blank" as alternative to not
specifying it. (Section 9.6) specifying it. (Section 9.6)
In the description of the Server header field, the Via field was In the description of the Server header field, the Via field was
described as a SHOULD. The requirement was and is stated correctly described as a SHOULD. The requirement was and is stated correctly
in the description of the Via header field in Section 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-Charset = <Accept-Charset, defined in [Part3], Section 6.2>
Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 6.3>
Accept-Language = <Accept-Language, defined in [Part3], Section 6.4>
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.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 4.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>
If-Match = <If-Match, defined in [Part4], Section 6.2>
If-Modified-Since =
<If-Modified-Since, defined in [Part4], Section 6.3>
If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
If-Range = <If-Range, defined in [Part5], Section 5.3>
If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 6.5>
Location = "Location:" OWS Location-v Location = "Location:" OWS Location-v
Location-v = URI-reference Location-v = URI-reference
Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
Max-Forwards-v = 1*DIGIT Max-Forwards-v = 1*DIGIT
Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS Method = token
/ %x47.45.54 ; GET
/ %x48.45.41.44 ; HEAD
/ %x50.4F.53.54 ; POST
/ %x50.55.54 ; PUT
/ %x44.45.4C.45.54.45 ; DELETE
/ %x54.52.41.43.45 ; TRACE
/ %x43.4F.4E.4E.45.43.54 ; CONNECT
/ extension-method
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 4.2>
Proxy-Authorization =
<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>
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
Server-v = product *( RWS ( product / comment ) ) Server-v = product *( RWS ( product / comment ) )
Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / Status-Code = 3DIGIT
"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" /
"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" /
"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" /
"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" /
"505" / extension-code
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>
WWW-Authenticate =
<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 )
*expect-params ] *expect-params ]
extension-code = 3DIGIT
extension-method = token
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
obs-text = <obs-text, defined in [Part1], Section 1.2.2> obs-text = <obs-text, defined in [Part1], Section 1.2.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.6> partial-URI = <partial-URI, defined in [Part1], Section 2.6>
product = <product, defined in [Part1], Section 6.3> product = <product, defined in [Part1], Section 6.3>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
request-header = Accept / Accept-Charset / Accept-Encoding /
Accept-Language / Authorization / Expect / From / Host / If-Match /
If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since /
Max-Forwards / Proxy-Authorization / Range / Referer / TE /
User-Agent
response-header = Accept-Ranges / Age / Allow / ETag / Location /
Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
ABNF diagnostics: ABNF diagnostics:
; Allow defined but not used
; Expect defined but not used
; From defined but not used
; Location defined but not used
; Max-Forwards defined but not used
; Reason-Phrase defined but not used ; Reason-Phrase defined but not used
; Referer defined but not used
; Retry-After defined but not used
; Server defined but not used
; Status-Code defined but not used ; Status-Code defined but not used
; request-header defined but not used ; User-Agent 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 RFC 2616 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:
skipping to change at page 53, line 30 skipping to change at page 56, line 8
o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/229>:
"Considerations for new status codes" "Considerations for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/230>:
"Considerations for new methods" "Considerations for new methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent o <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent
guidelines" (relating to the 'User-Agent' header field) guidelines" (relating to the 'User-Agent' header field)
C.14. Since draft-ietf-httpbis-p2-semantics-12
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
combination / precedence during redirects" (added warning about
having a fragid on the redirect may cause inconvenience in some
cases)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs.
PUT"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding
Content-* on non-PUT requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header type
defaulting"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
under' vs 'store at'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate
ABNF for Reason-Phrase"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special
status of Content-* prefix in header registration procedures"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards
vs extension methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the
value space of HTTP status codes?" (actually fixed in
draft-ietf-httpbis-p2-semantics-11)
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
Classification"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side
effect: invalidation or just stale?"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
supporting certain methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
CONNECT from RFC2817 to p2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
Upgrade details from RFC2817"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify
PUT semantics'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
ABNF for 'Method'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
Index Index
1 1
100 Continue (status code) 21 100 Continue (status code) 23
101 Switching Protocols (status code) 21 101 Switching Protocols (status code) 23
2 2
200 OK (status code) 22 200 OK (status code) 23
201 Created (status code) 22 201 Created (status code) 24
202 Accepted (status code) 22 202 Accepted (status code) 24
203 Non-Authoritative Information (status code) 23 203 Non-Authoritative Information (status code) 25
204 No Content (status code) 23 204 No Content (status code) 25
205 Reset Content (status code) 23 205 Reset Content (status code) 25
206 Partial Content (status code) 24 206 Partial Content (status code) 26
3 3
300 Multiple Choices (status code) 24 300 Multiple Choices (status code) 26
301 Moved Permanently (status code) 25 301 Moved Permanently (status code) 27
302 Found (status code) 25 302 Found (status code) 27
303 See Other (status code) 26 303 See Other (status code) 28
304 Not Modified (status code) 26 304 Not Modified (status code) 28
305 Use Proxy (status code) 27 305 Use Proxy (status code) 29
306 (Unused) (status code) 27 306 (Unused) (status code) 29
307 Temporary Redirect (status code) 27 307 Temporary Redirect (status code) 29
4 4
400 Bad Request (status code) 28 400 Bad Request (status code) 30
401 Unauthorized (status code) 28 401 Unauthorized (status code) 30
402 Payment Required (status code) 28 402 Payment Required (status code) 30
403 Forbidden (status code) 28 403 Forbidden (status code) 30
404 Not Found (status code) 28 404 Not Found (status code) 30
405 Method Not Allowed (status code) 28 405 Method Not Allowed (status code) 30
406 Not Acceptable (status code) 28 406 Not Acceptable (status code) 30
407 Proxy Authentication Required (status code) 29 407 Proxy Authentication Required (status code) 31
408 Request Timeout (status code) 29 408 Request Timeout (status code) 31
409 Conflict (status code) 29 409 Conflict (status code) 31
410 Gone (status code) 30 410 Gone (status code) 32
411 Length Required (status code) 30 411 Length Required (status code) 32
412 Precondition Failed (status code) 30 412 Precondition Failed (status code) 32
413 Request Entity Too Large (status code) 30 413 Request Entity Too Large (status code) 32
414 URI Too Long (status code) 31 414 URI Too Long (status code) 33
415 Unsupported Media Type (status code) 31 415 Unsupported Media Type (status code) 33
416 Requested Range Not Satisfiable (status code) 31 416 Requested Range Not Satisfiable (status code) 33
417 Expectation Failed (status code) 31 417 Expectation Failed (status code) 33
426 Upgrade Required (status code) 33
5 5
500 Internal Server Error (status code) 32 500 Internal Server Error (status code) 34
501 Not Implemented (status code) 32 501 Not Implemented (status code) 34
502 Bad Gateway (status code) 32 502 Bad Gateway (status code) 34
503 Service Unavailable (status code) 32 503 Service Unavailable (status code) 34
504 Gateway Timeout (status code) 32 504 Gateway Timeout (status code) 35
505 HTTP Version Not Supported (status code) 32 505 HTTP Version Not Supported (status code) 35
A A
Allow header 33 Allow header field 35
C C
CONNECT method 20 CONNECT method 21
D D
DELETE method 19 DELETE method 20
E E
Expect header 33 Expect header field 36
F F
From header 34 From header field 36
G G
GET method 16 GET method 16
Grammar Grammar
Allow 33 Allow 35
Allow-v 33 Allow-v 35
delta-seconds 37 delta-seconds 40
Expect 33 Expect 36
expect-params 33 expect-params 36
Expect-v 33 Expect-v 36
expectation 33 expectation 36
expectation-extension 33 expectation-extension 36
extension-code 11 extension-code 10
extension-method 8 From 37
From 34 From-v 37
From-v 34 Location 37
Location 35 Location-v 37
Location-v 35 Max-Forwards 38
Max-Forwards 36 Max-Forwards-v 38
Max-Forwards-v 36 Method 7
Method 8 Reason-Phrase 10
Reason-Phrase 11 Referer 39
Referer 37 Referer-v 39
Referer-v 37 Retry-After 39
request-header 10 Retry-After-v 39
response-header 13 Server 40
Retry-After 37 Server-v 40
Retry-After-v 37 Status-Code 10
Server 38 User-Agent 41
Server-v 38 User-Agent-v 41
Status-Code 11
User-Agent 39
User-Agent-v 39
H H
HEAD method 17 HEAD method 17
Headers Header Fields
Allow 33 Allow 35
Expect 33 Expect 36
From 34 From 36
Location 35 Location 37
Max-Forwards 36 Max-Forwards 38
Referer 36 Referer 39
Retry-After 37 Retry-After 39
Server 37 Server 40
User-Agent 38 User-Agent 40
I I
Idempotent Methods 15 Idempotent Methods 15
L L
Location header 35 Location header field 37
M M
Max-Forwards header 36 Max-Forwards header field 38
Methods Methods
CONNECT 20 CONNECT 21
DELETE 19 DELETE 20
GET 16 GET 16
HEAD 17 HEAD 17
OPTIONS 15 OPTIONS 15
POST 17 POST 17
PUT 18 PUT 18
TRACE 20 TRACE 21
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 field 39
Retry-After header 37 Retry-After header field 39
S S
Safe Methods 15 Safe Methods 14
Server header 37 Server header field 40
Status Codes Status Codes
100 Continue 21 100 Continue 23
101 Switching Protocols 21 101 Switching Protocols 23
200 OK 22 200 OK 23
201 Created 22 201 Created 24
202 Accepted 22 202 Accepted 24
203 Non-Authoritative Information 23 203 Non-Authoritative Information 25
204 No Content 23 204 No Content 25
205 Reset Content 23 205 Reset Content 25
206 Partial Content 24 206 Partial Content 26
300 Multiple Choices 24 300 Multiple Choices 26
301 Moved Permanently 25 301 Moved Permanently 27
302 Found 25 302 Found 27
303 See Other 26 303 See Other 28
304 Not Modified 26 304 Not Modified 28
305 Use Proxy 27 305 Use Proxy 29
306 (Unused) 27 306 (Unused) 29
307 Temporary Redirect 27 307 Temporary Redirect 29
400 Bad Request 28 400 Bad Request 30
401 Unauthorized 28 401 Unauthorized 30
402 Payment Required 28 402 Payment Required 30
403 Forbidden 28 403 Forbidden 30
404 Not Found 28 404 Not Found 30
405 Method Not Allowed 28 405 Method Not Allowed 30
406 Not Acceptable 28 406 Not Acceptable 30
407 Proxy Authentication Required 29 407 Proxy Authentication Required 31
408 Request Timeout 29 408 Request Timeout 31
409 Conflict 29 409 Conflict 31
410 Gone 30 410 Gone 32
411 Length Required 30 411 Length Required 32
412 Precondition Failed 30 412 Precondition Failed 32
413 Request Entity Too Large 30 413 Request Entity Too Large 32
414 URI Too Long 31 414 URI Too Long 33
415 Unsupported Media Type 31 415 Unsupported Media Type 33
416 Requested Range Not Satisfiable 31 416 Requested Range Not Satisfiable 33
417 Expectation Failed 31 417 Expectation Failed 33
500 Internal Server Error 32 426 Upgrade Required 33
501 Not Implemented 32 500 Internal Server Error 34
502 Bad Gateway 32 501 Not Implemented 34
503 Service Unavailable 32 502 Bad Gateway 34
504 Gateway Timeout 32 503 Service Unavailable 34
505 HTTP Version Not Supported 32 504 Gateway Timeout 35
505 HTTP Version Not Supported 35
T T
TRACE method 20 TRACE method 21
U U
User-Agent header 38 User-Agent header field 40
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Adobe Systems Incorporated
23 Corporate Plaza DR, Suite 280 345 Park Ave
Newport Beach, CA 92660 San Jose, CA 95110
USA USA
Phone: +1-949-706-5300
Fax: +1-949-706-5305
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys Jim Gettys
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
21 Oak Knoll Road 21 Oak Knoll Road
Carlisle, MA 01741 Carlisle, MA 01741
USA USA
EMail: jg@freedesktop.org EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/ URI: http://gettys.wordpress.com/
Jeffrey C. Mogul Jeffrey C. Mogul
Hewlett-Packard Company Hewlett-Packard Company
HP Labs, Large Scale Systems Group HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177 1501 Page Mill Road, MS 1177
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
EMail: JeffMogul@acm.org EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
skipping to change at page 58, line 31 skipping to change at page 62, line 22
Henrik Frystyk Nielsen Henrik Frystyk Nielsen
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
EMail: henrikn@microsoft.com EMail: henrikn@microsoft.com
Larry Masinter Larry Masinter
Adobe Systems, Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: LMM@acm.org EMail: LMM@acm.org
URI: http://larry.masinter.net/ URI: http://larry.masinter.net/
Paul J. Leach Paul J. Leach
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
 End of changes. 135 change blocks. 
644 lines changed or deleted 792 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/