draft-ietf-httpbis-p2-semantics-13.txt   draft-ietf-httpbis-p2-semantics-14.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Updates: 2817 (if approved) Alcatel-Lucent Updates: 2817 (if approved) Alcatel-Lucent
Intended status: Standards Track J. Mogul Intended status: Standards Track J. Mogul
Expires: September 15, 2011 HP Expires: October 20, 2011 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 14, 2011 April 18, 2011
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-13 draft-ietf-httpbis-p2-semantics-14
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), which is archived at
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is 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.14. The changes in this draft are summarized in Appendix C.15.
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
skipping to change at page 2, line 17 skipping to change at page 2, line 20
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 September 15, 2011. This Internet-Draft will expire on October 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 32 skipping to change at page 3, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22 7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 22 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 23
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 22 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 23
8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23
8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 24
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24
8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 24 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 25
8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25
8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25
8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 25 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 26
8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26
8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 26 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 27
8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27
8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 27 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 28
8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28
8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 28 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 29
8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29
8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29
8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 29 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 30
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30
8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30
8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30
8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30
8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 30 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 31
8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 30 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 31
8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 30 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 31
8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 31 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 32
8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 31 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 32
8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 31 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 32
8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32
8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 32 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 33
8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 32 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 33
8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 32 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 33
8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33
8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33
8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 33 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 34
8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 33 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 34
8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 33 8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 34
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34
8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34
8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 34 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 35
8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 34 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 35
8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 34 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 35
8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35
8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35
9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 35 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36
9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 38 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 39
9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 39 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 40
9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 40 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41
10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42
10.3. Header Field Registration . . . . . . . . . . . . . . . . 43 10.3. Header Field Registration . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44
11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45
11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46
11.4. Security Considerations for CONNECT . . . . . . . . . . . 46 11.4. Security Considerations for CONNECT . . . . . . . . . . . 46
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
13.1. Normative References . . . . . . . . . . . . . . . . . . . 46 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . . 47 13.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49 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) . . . . . . . . . . . . . . . . . . . . 50 publication) . . . . . . . . . . . . . . . . . . . . 51
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 50 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 51
C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 50 C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 51
C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 51 C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 52
C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52 C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52
C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 52 C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 53
C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53 C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53
C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 53 C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54
C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 53 C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54
C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54 C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54
C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 54 C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55
C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55 C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55
C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55 C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55
C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 55 C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56
C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56 C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1. Introduction 1. Introduction
This document defines HTTP/1.1 request and response semantics. Each This document defines HTTP/1.1 request and response semantics. Each
HTTP message, as defined in [Part1], is in the form of either a HTTP message, as defined in [Part1], is in the form of either a
request or a response. An HTTP server listens on a connection for request or a response. An HTTP server listens on a connection for
HTTP requests and responds to each request, in the order received on HTTP requests and responds to each request, in the order received on
that connection, with one or more HTTP response messages. This that connection, with one or more HTTP response messages. This
document defines the commonly agreed upon semantics of the HTTP document defines the commonly agreed upon semantics of the HTTP
uniform interface, the intentions defined by each request method, and uniform interface, the intentions defined by each request method, and
skipping to change at page 9, line 16 skipping to change at page 9, line 16
so that this is clear. so that this is clear.
Due to the parsing rules defined in Section 3.3 of [Part1], Due to the parsing rules defined in Section 3.3 of [Part1],
definitions of HTTP methods cannot prohibit the presence of a definitions of HTTP methods cannot prohibit the presence of a
message-body on either the request or the response message (with message-body on either the request or the response message (with
responses to HEAD requests being the single exception). Definitions responses to HEAD requests being the single exception). Definitions
of new methods cannot change this rule, but they can specify that of new methods cannot change this rule, but they can specify that
only zero-length bodies (as opposed to absent bodies) are allowed. only zero-length bodies (as opposed to absent bodies) are allowed.
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), what semantics (if any) the request body has, and
They also need to state whether they can be cached ([Part6]); in whether they are idempotent (Section 7.1.2). They also need to state
particular what conditions a cache may store the response, and under whether they can be cached ([Part6]); in particular what conditions a
what conditions such a stored response may be used to satisfy a cache may store the response, and under what conditions such a stored
subsequent request. response may be used to satisfy a subsequent request.
3. Request Header Fields 3. Request Header Fields
The request header fields allow the client to pass additional The request header fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
invocation. invocation.
+---------------------+------------------------+ +---------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+------------------------+ +---------------------+------------------------+
| Accept | Section 6.1 of [Part3] | | Accept | Section 6.1 of [Part3] |
| Accept-Charset | Section 6.2 of [Part3] | | Accept-Charset | Section 6.2 of [Part3] |
| Accept-Encoding | Section 6.3 of [Part3] | | Accept-Encoding | Section 6.3 of [Part3] |
| Accept-Language | Section 6.4 of [Part3] | | Accept-Language | Section 6.4 of [Part3] |
| Authorization | Section 4.1 of [Part7] | | Authorization | Section 4.1 of [Part7] |
| Expect | Section 9.2 | | Expect | Section 9.2 |
| From | Section 9.3 | | From | Section 9.3 |
| Host | Section 9.4 of [Part1] | | Host | Section 9.4 of [Part1] |
| If-Match | Section 6.2 of [Part4] | | If-Match | Section 3.1 of [Part4] |
| If-Modified-Since | Section 6.3 of [Part4] | | If-Modified-Since | Section 3.3 of [Part4] |
| If-None-Match | Section 6.4 of [Part4] | | If-None-Match | Section 3.2 of [Part4] |
| If-Range | Section 5.3 of [Part5] | | If-Range | Section 5.3 of [Part5] |
| If-Unmodified-Since | Section 6.5 of [Part4] | | If-Unmodified-Since | Section 3.4 of [Part4] |
| Max-Forwards | Section 9.5 | | Max-Forwards | Section 9.5 |
| Proxy-Authorization | Section 4.3 of [Part7] | | Proxy-Authorization | Section 4.3 of [Part7] |
| Range | Section 5.4 of [Part5] | | Range | Section 5.4 of [Part5] |
| Referer | Section 9.6 | | Referer | Section 9.6 |
| TE | Section 9.5 of [Part1] | | TE | Section 9.5 of [Part1] |
| User-Agent | Section 9.9 | | User-Agent | Section 9.9 |
+---------------------+------------------------+ +---------------------+------------------------+
4. Status Code and Reason Phrase 4. Status Code and Reason Phrase
skipping to change at page 10, line 37 skipping to change at page 10, line 37
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. Overview of Status Codes 4.1. Overview of Status Codes
The status codes listed below are defined in Section 8 of this The status codes listed below are defined in Section 8 of this
specification, Section 3 of [Part4], Section 3 of [Part5], and specification, Section 4 of [Part4], Section 3 of [Part5], and
Section 3 of [Part7]. The reason phrases listed here are only Section 3 of [Part7]. The reason phrases listed here are only
recommendations -- they can be replaced by local equivalents without recommendations -- they can be replaced by local equivalents without
affecting the protocol. affecting the protocol.
+-------------+------------------------------+----------------------+ +-------------+------------------------------+----------------------+
| Status-Code | Reason-Phrase | Defined in... | | Status-Code | Reason-Phrase | Defined in... |
+-------------+------------------------------+----------------------+ +-------------+------------------------------+----------------------+
| 100 | Continue | Section 8.1.1 | | 100 | Continue | Section 8.1.1 |
| 101 | Switching Protocols | Section 8.1.2 | | 101 | Switching Protocols | Section 8.1.2 |
| 200 | OK | Section 8.2.1 | | 200 | OK | Section 8.2.1 |
skipping to change at page 11, line 23 skipping to change at page 11, line 23
| 203 | Non-Authoritative | Section 8.2.4 | | 203 | Non-Authoritative | Section 8.2.4 |
| | Information | | | | Information | |
| 204 | No Content | Section 8.2.5 | | 204 | No Content | Section 8.2.5 |
| 205 | Reset Content | Section 8.2.6 | | 205 | Reset Content | Section 8.2.6 |
| 206 | Partial Content | Section 3.1 of | | 206 | Partial Content | Section 3.1 of |
| | | [Part5] | | | | [Part5] |
| 300 | Multiple Choices | Section 8.3.1 | | 300 | Multiple Choices | Section 8.3.1 |
| 301 | Moved Permanently | Section 8.3.2 | | 301 | Moved Permanently | Section 8.3.2 |
| 302 | Found | Section 8.3.3 | | 302 | Found | Section 8.3.3 |
| 303 | See Other | Section 8.3.4 | | 303 | See Other | Section 8.3.4 |
| 304 | Not Modified | Section 3.1 of | | 304 | Not Modified | Section 4.1 of |
| | | [Part4] | | | | [Part4] |
| 305 | Use Proxy | Section 8.3.6 | | 305 | Use Proxy | Section 8.3.6 |
| 307 | Temporary Redirect | Section 8.3.8 | | 307 | Temporary Redirect | Section 8.3.8 |
| 400 | Bad Request | Section 8.4.1 | | 400 | Bad Request | Section 8.4.1 |
| 401 | Unauthorized | Section 3.1 of | | 401 | Unauthorized | Section 3.1 of |
| | | [Part7] | | | | [Part7] |
| 402 | Payment Required | Section 8.4.3 | | 402 | Payment Required | Section 8.4.3 |
| 403 | Forbidden | Section 8.4.4 | | 403 | Forbidden | Section 8.4.4 |
| 404 | Not Found | Section 8.4.5 | | 404 | Not Found | Section 8.4.5 |
| 405 | Method Not Allowed | Section 8.4.6 | | 405 | Method Not Allowed | Section 8.4.6 |
| 406 | Not Acceptable | Section 8.4.7 | | 406 | Not Acceptable | Section 8.4.7 |
| 407 | Proxy Authentication | Section 3.2 of | | 407 | Proxy Authentication | Section 3.2 of |
| | Required | [Part7] | | | Required | [Part7] |
| 408 | Request Time-out | Section 8.4.9 | | 408 | Request Time-out | Section 8.4.9 |
| 409 | Conflict | Section 8.4.10 | | 409 | Conflict | Section 8.4.10 |
| 410 | Gone | Section 8.4.11 | | 410 | Gone | Section 8.4.11 |
| 411 | Length Required | Section 8.4.12 | | 411 | Length Required | Section 8.4.12 |
| 412 | Precondition Failed | Section 3.2 of | | 412 | Precondition Failed | Section 4.2 of |
| | | [Part4] | | | | [Part4] |
| 413 | Request Entity Too Large | Section 8.4.14 | | 413 | Request Entity Too Large | Section 8.4.14 |
| 414 | URI Too Long | Section 8.4.15 | | 414 | URI Too Long | Section 8.4.15 |
| 415 | Unsupported Media Type | Section 8.4.16 | | 415 | Unsupported Media Type | Section 8.4.16 |
| 416 | Requested range not | Section 3.2 of | | 416 | Requested range not | Section 3.2 of |
| | satisfiable | [Part5] | | | satisfiable | [Part5] |
| 417 | Expectation Failed | Section 8.4.18 | | 417 | Expectation Failed | Section 8.4.18 |
| 426 | Upgrade Required | Section 8.4.19 | | 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 |
skipping to change at page 13, line 20 skipping to change at page 13, line 20
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]).
+--------------------+------------------------+ +--------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+--------------------+------------------------+ +--------------------+------------------------+
| Accept-Ranges | Section 5.1 of [Part5] | | Accept-Ranges | Section 5.1 of [Part5] |
| Age | Section 3.1 of [Part6] | | Age | Section 3.1 of [Part6] |
| Allow | Section 9.1 | | Allow | Section 9.1 |
| ETag | Section 6.1 of [Part4] | | ETag | Section 2.2 of [Part4] |
| Location | Section 9.4 | | Location | Section 9.4 |
| Proxy-Authenticate | Section 4.2 of [Part7] | | Proxy-Authenticate | Section 4.2 of [Part7] |
| Retry-After | Section 9.7 | | Retry-After | Section 9.7 |
| Server | Section 9.8 | | Server | Section 9.8 |
| Vary | Section 3.5 of [Part6] | | Vary | Section 3.5 of [Part6] |
| WWW-Authenticate | Section 4.4 of [Part7] | | WWW-Authenticate | Section 4.4 of [Part7] |
+--------------------+------------------------+ +--------------------+------------------------+
6. Representation 6. Representation
skipping to change at page 17, line 7 skipping to change at page 17, line 7
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 request 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.
Bodies on GET requests have no defined semantics. Note that sending
a body on a GET request might cause some existing implementations to
reject the request.
The response to a GET request is cacheable and MAY be used to satisfy The response to a GET request is cacheable and MAY be used to satisfy
subsequent GET and HEAD requests (see [Part6]). subsequent GET and HEAD requests (see [Part6]).
See Section 11.2 for security considerations when used for forms. See Section 11.2 for security considerations when used for forms.
7.4. HEAD 7.4. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response. The metadata contained in the return a message-body in the response. The metadata contained in the
HTTP header fields in response to a HEAD request SHOULD be identical HTTP header fields in response to a HEAD request SHOULD be identical
skipping to change at page 17, line 31 skipping to change at page 17, line 35
accessibility, and recent modification. accessibility, and recent modification.
The response to a HEAD request is cacheable and MAY be used to The response to a HEAD request is cacheable and MAY be used to
satisfy a subsequent HEAD request; see [Part6]. It also MAY be used satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
to update a previously cached representation from that resource; if to update a previously cached representation from that resource; if
the new field values indicate that the cached representation differs the new field values indicate that the cached representation differs
from the current representation (as would be indicated by a change in from the current representation (as would be indicated by a change in
Content-Length, Content-MD5, ETag or Last-Modified), then the cache Content-Length, Content-MD5, ETag or Last-Modified), then the cache
MUST treat the cache entry as stale. MUST treat the cache entry as stale.
Bodies on HEAD requests have no defined semantics. Note that sending
a body on a HEAD request might cause some existing implementations to
reject the request.
7.5. POST 7.5. POST
The POST method requests 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
skipping to change at page 20, line 51 skipping to change at page 21, line 12
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.
Bodies on DELETE requests have no defined semantics. Note that
sending a body on a DELETE request might cause some existing
implementations to reject the request.
Responses to the DELETE method are not cacheable. If a DELETE Responses to the DELETE method are not cacheable. If a DELETE
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 2.5 of [Part6]). invalidated (see Section 2.5 of [Part6]).
7.8. TRACE 7.8. TRACE
The TRACE method requests a remote, application-layer loop-back of The TRACE method requests a remote, application-layer loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received back to the client as the message-body reflect the message received back to the client as the message-body
skipping to change at page 22, line 9 skipping to change at page 22, line 21
except end-to-end protocol Upgrade requests, since the tunnel must be except end-to-end protocol Upgrade requests, since the tunnel must be
established first. established first.
For example, proxy authentication might be used to establish the For example, proxy authentication might be used to establish the
authority to create a tunnel: authority to create a tunnel:
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ= Proxy-Authorization: basic aGVsbG86d29ybGQ=
Bodies on CONNECT requests have no defined semantics. Note that
sending a body on a CONNECT request might cause some existing
implementations to reject the request.
Like any other pipelined HTTP/1.1 request, data to be tunnel may be 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: sent immediately after the blank line. The usual caveats also apply:
data may be discarded if the eventual response is negative, and the 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 connection may be reset with no response if more than one TCP segment
is outstanding. is outstanding.
7.9.1. Establishing a Tunnel with CONNECT 7.9.1. Establishing a Tunnel with CONNECT
Any successful (2xx) response to a CONNECT request indicates that the Any successful (2xx) response to a CONNECT request indicates that the
proxy has established a connection to the requested host and port, proxy has established a connection to the requested host and port,
skipping to change at page 24, line 35 skipping to change at page 25, line 5
response SHOULD include a payload containing a list of resource response SHOULD include a payload containing a list of resource
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The payload format is specified by choose the one most appropriate. The payload format is specified by
the media type given in the Content-Type header field. The origin the media type given in the Content-Type header field. The origin
server MUST create the resource before returning the 201 status code. server MUST create the resource before returning the 201 status code.
If the action cannot be carried out immediately, the server SHOULD If the action cannot be carried out immediately, the server SHOULD
respond with 202 (Accepted) response instead. respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating A 201 response MAY contain an ETag response header field indicating
the current value of the entity-tag for the representation of the the current value of the entity-tag for the representation of the
resource just created (see Section 6.1 of [Part4]). resource just created (see Section 2.2 of [Part4]).
8.2.3. 202 Accepted 8.2.3. 202 Accepted
The request has been accepted for processing, but the processing has The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be not been completed. The request might or might not eventually be
acted upon, as it might be disallowed when processing actually takes acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an place. There is no facility for re-sending a status code from an
asynchronous operation such as this. asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to The 202 response is intentionally non-committal. Its purpose is to
skipping to change at page 25, line 21 skipping to change at page 25, line 40
information about the resource might result in a superset of the information about the resource might result in a superset of the
metadata known by the origin server. Use of this response code is metadata known by the origin server. Use of this response code is
not required and is only appropriate when the response would not required and is only appropriate when the response would
otherwise be 200 (OK). otherwise be 200 (OK).
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 203 responses. determine freshness for 203 responses.
8.2.5. 204 No Content 8.2.5. 204 No Content
The server has successfully fulfilled the request, but there is no The 204 (No Content) status code indicates that the server has
additional content to return in the response payload body. The successfully fulfilled the request and that there is no additional
resource metadata and representation metadata in the response content to return in the response payload body. Metadata in the
message's header fields refer to the target resource and its current response header fields refer to the target resource and its current
representation, respectively, after the requested action. For representation after the requested action.
example, if a 204 status code is received in response to a PUT and
the response contains an ETag header field, then the value of that
field is the current entity-tag for the representation that was
successfully PUT.
If the client is a user agent, it SHOULD NOT change its document view For example, if a 204 status code is received in response to a PUT
from that which caused the request to be sent. This response is request and the response contains an ETag header field, then the PUT
primarily intended to allow input for actions to take place without was successful and the ETag field-value contains the entity-tag for
causing a change to the user agent's active document view, although the new representation of that target resource.
any new or updated metadata SHOULD be applied to the document
currently in the user agent's active view. The 204 response allows a server to indicate that the action has been
successfully applied to the target resource while implying that the
user agent SHOULD NOT traverse away from its current "document view"
(if any). The server assumes that the user agent will provide some
indication of the success to its user, in accord with its own
interface, and apply any new or updated metadata in the response to
the active representation. For example, a 204 status code is
commonly used with document editing interfaces corresponding to a
"save" action, such that the document being saved remains available
to the user for editing. It is also frequently used with interfaces
that expect automated data transfers to be prevalent, such as within
distributed version control systems.
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
skipping to change at page 28, line 48 skipping to change at page 29, line 30
scope of HTTP and thus entirely determined by the URI owner(s). scope of HTTP and thus entirely determined by the URI owner(s).
Except for responses to a HEAD request, the representation of a 303 Except for responses to a HEAD request, the representation of a 303
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the Location URI. the Location URI.
8.3.5. 304 Not Modified 8.3.5. 304 Not Modified
The response to the request has not been modified since the The response to the request has not been modified since the
conditions indicated by the client's conditional GET request, as conditions indicated by the client's conditional GET request, as
defined in Section 3.1 of [Part4]. defined in Section 4.1 of [Part4].
8.3.6. 305 Use Proxy 8.3.6. 305 Use Proxy
The 305 status code was defined in a previous version of this The 305 status code was defined in a previous version of this
specification (see Appendix A), and is now deprecated. specification (see Appendix A), and is now deprecated.
8.3.7. 306 (Unused) 8.3.7. 306 (Unused)
The 306 status code was used in a previous version of the The 306 status code was used in a previous version of the
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
skipping to change at page 32, line 43 skipping to change at page 33, line 21
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 header fields evaluated The precondition given in one or more of the header fields evaluated
to false when it was tested on the server, as defined in Section 3.2 to false when it was tested on the server, as defined in Section 4.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-
skipping to change at page 35, line 37 skipping to change at page 36, line 17
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" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised 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 request methods associated strictly to inform the recipient of valid request methods associated
with the resource. with the resource.
Allow = "Allow" ":" OWS Allow-v Allow = #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 -- it does not need to A proxy MUST NOT modify the Allow header field -- it does not need to
understand all the methods specified in order to handle them understand all the methods specified in order to handle them
according to the generic message handling rules. according to the generic message handling rules.
9.2. Expect 9.2. Expect
The "Expect" header field is used to indicate that particular server The "Expect" header field is used to indicate that particular server
behaviors are required by the client. behaviors are required by the client.
Expect = "Expect" ":" OWS Expect-v Expect = 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
the expectation values in the Expect field of a request MUST respond the expectation values in the Expect field of a request MUST respond
with appropriate error status code. The server MUST respond with a with appropriate error status code. The server MUST respond with a
417 (Expectation Failed) status code if any of the expectations 417 (Expectation Failed) status code if any of the expectations
skipping to change at page 37, line 5 skipping to change at page 37, line 28
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" header field, if given, SHOULD contain an Internet e-mail The "From" header field, if given, SHOULD contain an Internet e-mail
address for the human user who controls the requesting user agent. address for the human user who controls the requesting user agent.
The address SHOULD be machine-usable, as defined by "mailbox" in The address SHOULD be machine-usable, as defined by "mailbox" in
Section 3.4 of [RFC5322]: Section 3.4 of [RFC5322]:
From = "From" ":" OWS From-v From = 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
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
NOT be used as an insecure form of access protection. The NOT be used as an insecure form of access protection. The
skipping to change at page 37, line 50 skipping to change at page 38, line 23
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).
Location = "Location" ":" OWS Location-v Location = URI-reference
Location-v = URI-reference
Examples are: Examples are:
Location: http://www.example.org/pub/WWW/People.html#tim Location: http://www.example.org/pub/WWW/People.html#tim
Location: /index.html Location: /index.html
There are circumstances in which a fragment identifier in a Location There are circumstances in which a fragment identifier in a Location
URI would not be appropriate: URI would not be appropriate:
skipping to change at page 38, line 40 skipping to change at page 39, line 13
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" header field provides a mechanism with the TRACE The "Max-Forwards" header field provides a mechanism with the TRACE
(Section 7.8) and OPTIONS (Section 7.2) methods to limit the number (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number
of times that the request is forwarded by proxies. This can be of times that the request is forwarded by proxies. This can be
useful when the client is attempting to trace a request which appears useful when the client is attempting to trace a request 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 = 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 recipient of a TRACE or OPTIONS request containing a Max- Each recipient of a TRACE or OPTIONS request containing a Max-
Forwards header field MUST check and update its value prior to Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the forwarding the request. If the received value is zero (0), the
recipient MUST NOT forward the request; instead, it MUST respond as recipient MUST NOT forward the request; instead, it MUST respond as
the final recipient. If the received Max-Forwards value is greater the final recipient. If the received Max-Forwards value is greater
than zero, then the forwarded message MUST contain an updated Max- than zero, then the forwarded message MUST contain an updated Max-
skipping to change at page 39, line 27 skipping to change at page 39, line 48
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
field MUST either be sent with the value "about:blank", or not be field MUST either be sent with the value "about:blank", or not be
sent at all. Note that this requirement does not apply to sources sent at all. Note that this requirement does not apply to sources
with non-HTTP URIs (e.g., FTP). with non-HTTP URIs (e.g., FTP).
Referer = "Referer" ":" OWS Referer-v Referer = absolute-URI / partial-URI
Referer-v = absolute-URI / partial-URI
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the 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 header "Retry-After" field can be used with a 503 (Service The header "Retry-After" field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. user-agent is asked wait before issuing the 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 = HTTP-date / delta-seconds
Retry-After-v = HTTP-date / delta-seconds
Time spans are non-negative decimal integers, representing time in Time spans are non-negative decimal integers, representing time in
seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
skipping to change at page 40, line 25 skipping to change at page 40, line 44
9.8. Server 9.8. Server
The "Server" header field contains information about the software The "Server" header field contains information about the 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 = product *( RWS ( product / comment ) )
Server-v = product
*( 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 header field. Instead, it application MUST NOT modify the Server header field. Instead, it
MUST include a Via field (as described in Section 9.9 of [Part1]). MUST include a Via field (as described in Section 9.9 of [Part1]).
Note: Revealing the specific software version of the server might Note: Revealing the specific software version of the server might
skipping to change at page 41, line 24 skipping to change at page 41, line 40
subproducts by third parties. Overly long and detailed User-Agent subproducts by third parties. Overly long and detailed User-Agent
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 = product *( RWS ( product / comment ) )
User-Agent-v = product *( 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 request methods is defined by The registration procedure for HTTP request methods is defined by
skipping to change at page 46, line 34 skipping to change at page 46, line 34
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-13 and Message Parsing", draft-ietf-httpbis-p1-messaging-14
(work in progress), March 2011. (work in progress), April 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-13 and Content Negotiation", draft-ietf-httpbis-p3-payload-14
(work in progress), March 2011. (work in progress), April 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-13 (work in Requests", draft-ietf-httpbis-p4-conditional-14 (work in
progress), March 2011. progress), April 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-13 (work Partial Responses", draft-ietf-httpbis-p5-range-14 (work
in progress), March 2011. in progress), April 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-13 (work in 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in
progress), March 2011. progress), April 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-13 (work in progress), draft-ietf-httpbis-p7-auth-14 (work in progress),
March 2011. April 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 48, line 37 skipping to change at page 48, line 37
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 Define status 426 (Upgrade Required) (this was incorporated from
[RFC2817]). (Section 8.4.19) [RFC2817]). (Section 8.4.19)
Change ABNF productions for header fields to only define the field
value. (Section 9)
Reclassify "Allow" as response header field, removing the option to Reclassify "Allow" as response header field, removing the option to
specify it in a PUT request. Relax the server requirement on the specify it in a PUT request. Relax the server requirement on the
contents of the Allow header field and remove requirement on clients contents of the Allow header field and remove requirement on clients
to always trust the header field value. (Section 9.1) to always trust the header field value. (Section 9.1)
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)
skipping to change at page 48, line 49 skipping to change at page 49, line 4
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, Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
extension methods could have used it as well). (Section 9.5) 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
Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
Allow = "Allow:" OWS Allow-v Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
Expect = "Expect:" OWS Expect-v
Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
From = "From:" OWS From-v From = mailbox
From-v = mailbox
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
Location = "Location:" OWS Location-v Location = URI-reference
Location-v = URI-reference
Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v Max-Forwards = 1*DIGIT
Max-Forwards-v = 1*DIGIT
Method = token Method = token
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>
Reason-Phrase = *( WSP / VCHAR / obs-text ) Reason-Phrase = *( WSP / VCHAR / obs-text )
Referer = "Referer:" OWS Referer-v Referer = absolute-URI / partial-URI
Referer-v = absolute-URI / partial-URI Retry-After = HTTP-date / delta-seconds
Retry-After = "Retry-After:" OWS Retry-After-v
Retry-After-v = HTTP-date / delta-seconds
Server = "Server:" OWS Server-v Server = product *( RWS ( product / comment ) )
Server-v = product *( RWS ( product / comment ) )
Status-Code = 3DIGIT Status-Code = 3DIGIT
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 = product *( RWS ( product / comment ) )
User-Agent-v = product *( RWS ( product / comment ) )
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 ]
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>
skipping to change at page 57, line 14 skipping to change at page 57, line 41
o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
supporting certain methods" supporting certain methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
CONNECT from RFC2817 to p2" CONNECT from RFC2817 to p2"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
Upgrade details from RFC2817" Upgrade details from RFC2817"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT
PUT semantics'" semantics'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
ABNF for 'Method'" ABNF for 'Method'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields" ABNFs for header fields"
C.15. Since draft-ietf-httpbis-p2-semantics-13
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
ABNFs for header fields"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message-body
in CONNECT request"
Index Index
1 1
100 Continue (status code) 23 100 Continue (status code) 23
101 Switching Protocols (status code) 23 101 Switching Protocols (status code) 23
2 2
200 OK (status code) 23 200 OK (status code) 24
201 Created (status code) 24 201 Created (status code) 24
202 Accepted (status code) 24 202 Accepted (status code) 25
203 Non-Authoritative Information (status code) 25 203 Non-Authoritative Information (status code) 25
204 No Content (status code) 25 204 No Content (status code) 25
205 Reset Content (status code) 25 205 Reset Content (status code) 26
206 Partial Content (status code) 26 206 Partial Content (status code) 26
3 3
300 Multiple Choices (status code) 26 300 Multiple Choices (status code) 27
301 Moved Permanently (status code) 27 301 Moved Permanently (status code) 27
302 Found (status code) 27 302 Found (status code) 28
303 See Other (status code) 28 303 See Other (status code) 28
304 Not Modified (status code) 28 304 Not Modified (status code) 29
305 Use Proxy (status code) 29 305 Use Proxy (status code) 29
306 (Unused) (status code) 29 306 (Unused) (status code) 29
307 Temporary Redirect (status code) 29 307 Temporary Redirect (status code) 29
4 4
400 Bad Request (status code) 30 400 Bad Request (status code) 30
401 Unauthorized (status code) 30 401 Unauthorized (status code) 30
402 Payment Required (status code) 30 402 Payment Required (status code) 30
403 Forbidden (status code) 30 403 Forbidden (status code) 30
404 Not Found (status code) 30 404 Not Found (status code) 31
405 Method Not Allowed (status code) 30 405 Method Not Allowed (status code) 31
406 Not Acceptable (status code) 30 406 Not Acceptable (status code) 31
407 Proxy Authentication Required (status code) 31 407 Proxy Authentication Required (status code) 32
408 Request Timeout (status code) 31 408 Request Timeout (status code) 32
409 Conflict (status code) 31 409 Conflict (status code) 32
410 Gone (status code) 32 410 Gone (status code) 32
411 Length Required (status code) 32 411 Length Required (status code) 33
412 Precondition Failed (status code) 32 412 Precondition Failed (status code) 33
413 Request Entity Too Large (status code) 32 413 Request Entity Too Large (status code) 33
414 URI Too Long (status code) 33 414 URI Too Long (status code) 33
415 Unsupported Media Type (status code) 33 415 Unsupported Media Type (status code) 33
416 Requested Range Not Satisfiable (status code) 33 416 Requested Range Not Satisfiable (status code) 34
417 Expectation Failed (status code) 33 417 Expectation Failed (status code) 34
426 Upgrade Required (status code) 33 426 Upgrade Required (status code) 34
5 5
500 Internal Server Error (status code) 34 500 Internal Server Error (status code) 34
501 Not Implemented (status code) 34 501 Not Implemented (status code) 35
502 Bad Gateway (status code) 34 502 Bad Gateway (status code) 35
503 Service Unavailable (status code) 34 503 Service Unavailable (status code) 35
504 Gateway Timeout (status code) 35 504 Gateway Timeout (status code) 35
505 HTTP Version Not Supported (status code) 35 505 HTTP Version Not Supported (status code) 35
A A
Allow header field 35 Allow header field 36
C C
CONNECT method 21 CONNECT method 21
D D
DELETE method 20 DELETE method 20
E E
Expect header field 36 Expect header field 36
F F
From header field 36 From header field 37
G G
GET method 16 GET method 16
Grammar Grammar
Allow 35 Allow 36
Allow-v 35
delta-seconds 40 delta-seconds 40
Expect 36 Expect 36
expect-params 36 expect-params 36
Expect-v 36
expectation 36 expectation 36
expectation-extension 36 expectation-extension 36
extension-code 10 extension-code 10
From 37 From 37
From-v 37 Location 38
Location 37 Max-Forwards 39
Location-v 37
Max-Forwards 38
Max-Forwards-v 38
Method 7 Method 7
Reason-Phrase 10 Reason-Phrase 10
Referer 39 Referer 39
Referer-v 39 Retry-After 40
Retry-After 39
Retry-After-v 39
Server 40 Server 40
Server-v 40
Status-Code 10 Status-Code 10
User-Agent 41 User-Agent 41
User-Agent-v 41
H H
HEAD method 17 HEAD method 17
Header Fields Header Fields
Allow 35 Allow 36
Expect 36 Expect 36
From 36 From 37
Location 37 Location 38
Max-Forwards 38 Max-Forwards 39
Referer 39 Referer 39
Retry-After 39 Retry-After 40
Server 40 Server 40
User-Agent 40 User-Agent 41
I I
Idempotent Methods 15 Idempotent Methods 15
L L
Location header field 37 Location header field 38
M M
Max-Forwards header field 38 Max-Forwards header field 39
Methods Methods
CONNECT 21 CONNECT 21
DELETE 20 DELETE 20
GET 16 GET 16
HEAD 17 HEAD 17
OPTIONS 15 OPTIONS 15
POST 17 POST 17
PUT 18 PUT 18
TRACE 21 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 field 39 Referer header field 39
Retry-After header field 39 Retry-After header field 40
S S
Safe Methods 14 Safe Methods 14
Server header field 40 Server header field 40
Status Codes Status Codes
100 Continue 23 100 Continue 23
101 Switching Protocols 23 101 Switching Protocols 23
200 OK 23 200 OK 24
201 Created 24 201 Created 24
202 Accepted 24 202 Accepted 25
203 Non-Authoritative Information 25 203 Non-Authoritative Information 25
204 No Content 25 204 No Content 25
205 Reset Content 25 205 Reset Content 26
206 Partial Content 26 206 Partial Content 26
300 Multiple Choices 26 300 Multiple Choices 27
301 Moved Permanently 27 301 Moved Permanently 27
302 Found 27 302 Found 28
303 See Other 28 303 See Other 28
304 Not Modified 28 304 Not Modified 29
305 Use Proxy 29 305 Use Proxy 29
306 (Unused) 29 306 (Unused) 29
307 Temporary Redirect 29 307 Temporary Redirect 29
400 Bad Request 30 400 Bad Request 30
401 Unauthorized 30 401 Unauthorized 30
402 Payment Required 30 402 Payment Required 30
403 Forbidden 30 403 Forbidden 30
404 Not Found 30 404 Not Found 31
405 Method Not Allowed 30 405 Method Not Allowed 31
406 Not Acceptable 30 406 Not Acceptable 31
407 Proxy Authentication Required 31 407 Proxy Authentication Required 32
408 Request Timeout 31 408 Request Timeout 32
409 Conflict 31 409 Conflict 32
410 Gone 32 410 Gone 32
411 Length Required 32 411 Length Required 33
412 Precondition Failed 32 412 Precondition Failed 33
413 Request Entity Too Large 32 413 Request Entity Too Large 33
414 URI Too Long 33 414 URI Too Long 33
415 Unsupported Media Type 33 415 Unsupported Media Type 33
416 Requested Range Not Satisfiable 33 416 Requested Range Not Satisfiable 34
417 Expectation Failed 33 417 Expectation Failed 34
426 Upgrade Required 33 426 Upgrade Required 34
500 Internal Server Error 34 500 Internal Server Error 34
501 Not Implemented 34 501 Not Implemented 35
502 Bad Gateway 34 502 Bad Gateway 35
503 Service Unavailable 34 503 Service Unavailable 35
504 Gateway Timeout 35 504 Gateway Timeout 35
505 HTTP Version Not Supported 35 505 HTTP Version Not Supported 35
T T
TRACE method 21 TRACE method 21
U U
User-Agent header field 40 User-Agent header field 41
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 110 change blocks. 
200 lines changed or deleted 213 lines changed or added

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