draft-ietf-httpbis-p2-semantics-02.txt   draft-ietf-httpbis-p2-semantics-03.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Updates: 2817 (if approved) One Laptop per Child
Expires: August 27, 2008 J. Mogul Intended status: Standards Track J. Mogul
HP Expires: December 19, 2008 HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
February 24, 2008 June 17, 2008
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-02 draft-ietf-httpbis-p2-semantics-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2008. This Internet-Draft will expire on December 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods, the semantics of HTTP messages as expressed by request methods,
skipping to change at page 2, line 29 skipping to change at page 2, line 25
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://www.tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://www.tools.ietf.org/wg/httpbis/>. <http://www.tools.ietf.org/wg/httpbis/>.
This draft incorporates those issue resolutions that were either The changes in this draft are summarized in Appendix B.4.
collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
2. Notational Conventions and Generic Grammar . . . . . . . . . . 6 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8
5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9
5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 11
6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12
8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12
8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 13
8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18
9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19
9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19
9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19
9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20
9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20
9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20
9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21
9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21
9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21
9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21
9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22
9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22
9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23
9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23
9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 24
9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 24
9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24
9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24
9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25
9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25
9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25
9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25
9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25
9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26
9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 26
9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 26
9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26
9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27
9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27
9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27
9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28
9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28
9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 28
9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28
9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28
9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28
9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29
9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29
9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 29
9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29
9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29
9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29
9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30
9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 30
10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30
10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33
10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34
10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 35
12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35 11.2. Message Header Registration . . . . . . . . . . . . . . . 37
12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 37
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 38
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 39
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
14.2. Informative References . . . . . . . . . . . . . . . . . . 38 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Compatibility with Previous Versions . . . . . . . . 38 14.1. Normative References . . . . . . . . . . . . . . . . . . . 39
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38 14.2. Informative References . . . . . . . . . . . . . . . . . . 40
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39 Appendix A. Compatibility with Previous Versions . . . . . . . . 40
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 40
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 41
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 40 publication) . . . . . . . . . . . . . . . . . . . . 42
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 42
B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40 B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 42
B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41 B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 51
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 8, line 11 skipping to change at page 8, line 11
Proxy-Authorization = Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 4.3> <Proxy-Authorization, defined in [Part7], Section 4.3>
WWW-Authenticate = WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 4.4> <WWW-Authenticate, defined in [Part7], Section 4.4>
3. Method 3. Method
The Method token indicates the method to be performed on the resource The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 8.2 Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2
| "GET" ; Section 8.3 | %x47.45.54 ; "GET", Section 8.3
| "HEAD" ; Section 8.4 | %x48.45.41.44 ; "HEAD", Section 8.4
| "POST" ; Section 8.5 | %x50.4F.53.54 ; "POST", Section 8.5
| "PUT" ; Section 8.6 | %x50.55.54 ; "PUT", Section 8.6
| "DELETE" ; Section 8.7 | %x44.45.4C.45.54.45 ; "DELETE", Section 8.7
| "TRACE" ; Section 8.8 | %x54.52.41.43.45 ; "TRACE", Section 8.8
| "CONNECT" ; Section 8.9 | %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9
| extension-method | extension-method
extension-method = token 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 10.1). The return code of the response Allow header field (Section 10.1). The return 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 return the status code 405 (Method Not An origin server SHOULD return 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 requested resource, and 501 (Not Implemented) if the method for the requested resource, and 501 (Not Implemented) if the method
skipping to change at page 11, line 16 skipping to change at page 11, line 16
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 entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
5.1. Status Code Registry
The HTTP Status Code Registry defines the name space for the Status-
Code token in the Status line of an HTTP response.
Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1). Any document registering new status codes
should be traceable through statuses of either 'Obsoletes' or
'Updates' to this document.
The registry itself is maintained at
<http://www.iana.org/assignments/http-status-codes>.
6. Response Header Fields 6. 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 resource identified by the Request-URI. about further access to the resource identified by the Request-URI.
response-header = Accept-Ranges ; [Part5], Section 6.1 response-header = Accept-Ranges ; [Part5], Section 6.1
| Age ; [Part6], Section 16.1 | Age ; [Part6], Section 16.1
| Allow ; Section 10.1
| ETag ; [Part4], Section 7.1 | ETag ; [Part4], Section 7.1
| Location ; Section 10.4 | Location ; Section 10.4
| Proxy-Authenticate ; [Part7], Section 4.2 | Proxy-Authenticate ; [Part7], Section 4.2
| Retry-After ; Section 10.7 | Retry-After ; Section 10.7
| Server ; Section 10.8 | Server ; Section 10.8
| Vary ; [Part6], Section 16.5 | Vary ; [Part6], Section 16.5
| WWW-Authenticate ; [Part7], Section 4.4 | WWW-Authenticate ; [Part7], Section 4.4
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
skipping to change at page 16, line 7 skipping to change at page 16, line 20
status of the request and refers to the new resource, and a Location status of the request and refers to the new resource, and a Location
header (see Section 10.4). header (see Section 10.4).
Responses to this method are not cacheable, unless the response Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. includes appropriate Cache-Control or Expires header fields.
However, the 303 (See Other) response can be used to direct the user However, the 303 (See Other) response can be used to direct the user
agent to retrieve a cacheable resource. agent to retrieve a cacheable resource.
8.6. PUT 8.6. PUT
The PUT method requests that the enclosed entity be stored under the The PUT method requests that the enclosed entity be stored at the
supplied Request-URI. If the Request-URI refers to an already supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a agent, the origin server can create the resource with that URI. If a
new resource is created at the Request-URI, the origin server MUST new resource is created at the Request-URI, the origin server MUST
inform the user agent via the 201 (Created) response. If an existing inform the user agent via the 201 (Created) response. If an existing
resource is modified, either the 200 (OK) or 204 (No Content) resource is modified, either the 200 (OK) or 204 (No Content)
response codes SHOULD be sent to indicate successful completion of response codes SHOULD be sent to indicate successful completion of
skipping to change at page 17, line 47 skipping to change at page 18, line 13
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 8.9 of information. The value of the Via header field (Section 8.9 of
[Part1]) is of particular interest, since it acts as a trace of the [Part1]) is of particular interest, since it acts as a trace of the
request chain. Use of the Max-Forwards header field allows the request chain. Use of the Max-Forwards header field allows the
client to limit the length of the request chain, which is useful for client to limit the length of the request chain, which is useful for
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
If the request is valid, the response SHOULD contain the entire If the request is valid, the response SHOULD contain the entire
request message in the entity-body, with a Content-Type of "message/ request message in the entity-body, with a Content-Type of "message/
http". Responses to this method MUST NOT be cached. http" (see Appendix A.1 of [Part1]). Responses to this method MUST
NOT be cached.
8.9. CONNECT 8.9. CONNECT
This specification reserves the method name CONNECT for use with a This specification reserves the method name CONNECT for use with a
proxy that can dynamically switch to being a tunnel (e.g. SSL proxy that can dynamically switch to being a tunnel (e.g. SSL
tunneling [Luo1998]). tunneling [Luo1998]).
9. Status Code Definitions 9. Status Code Definitions
Each Status-Code is described below, including a description of which Each Status-Code is described below, including a description of which
skipping to change at page 23, line 17 skipping to change at page 23, line 36
allowed to change the method on the redirected request. However, allowed to change the method on the redirected request. However,
most existing user agent implementations treat 302 as if it were a most existing user agent implementations treat 302 as if it were a
303 response, performing a GET on the Location field-value 303 response, performing a GET on the Location field-value
regardless of the original request method. The status codes 303 regardless of the original request method. The status codes 303
and 307 have been added for servers that wish to make and 307 have been added for servers that wish to make
unambiguously clear which kind of reaction is expected of the unambiguously clear which kind of reaction is expected of the
client. client.
9.3.4. 303 See Other 9.3.4. 303 See Other
The response to the request can be found under a different URI and The server directs the user agent to a different resource, indicated
SHOULD be retrieved using a GET method on that resource. This method by a URI in the Location header field, that provides an indirect
exists primarily to allow the output of a POST-activated script to response to the original request. The user agent MAY perform a GET
redirect the user agent to a selected resource. The new URI is not a request on the URI in the Location field in order to obtain a
substitute reference for the originally requested resource. The 303 representation corresponding to the response, be redirected again, or
response MUST NOT be cached, but the response to the second end with an error status. The Location URI is not a substitute
(redirected) request might be cacheable. reference for the originally requested resource.
The different URI SHOULD be given by the Location field in the The 303 status is generally applicable to any HTTP method. It is
response. Unless the request method was HEAD, the entity of the primarily used to allow the output of a POST action to redirect the
response SHOULD contain a short hypertext note with a hyperlink to user agent to a selected resource, since doing so provides the
the new URI(s). information corresponding to the POST response in a form that can be
separately identified, bookmarked, and cached independent of the
original request.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 A 303 response to a GET request indicates that the requested resource
status. When interoperability with such clients is a concern, the does not have a representation of its own that can be transferred by
302 status code may be used instead, since most user agents react the server over HTTP. The Location URI indicates a resource that is
to a 302 response as described here for 303. descriptive of the requested resource such that the follow-on
representation may be useful without implying that it adequately
represents the previously requested resource. Note that answers to
the questions of what can be represented, what representations are
adequate, and what might be a useful description are outside the
scope of HTTP and thus entirely determined by the resource owner(s).
A 303 response SHOULD NOT be cached unless it is indicated as
cacheable by Cache-Control or Expires header fields. Except for
responses to a HEAD request, the entity of a 303 response SHOULD
contain a short hypertext note with a hyperlink to the Location URI.
9.3.5. 304 Not Modified 9.3.5. 304 Not Modified
The response to the request has not been modified since the The response to the request has not been modified since the
conditions indicated by the client's conditional GET request, as conditions indicated by the client's conditional GET request, as
defined in [Part4]. defined in [Part4].
9.3.6. 305 Use Proxy 9.3.6. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The 305 status was defined in a previous version of this
the Location field. The Location field gives the URI of the proxy. specification (see Appendix A.2), and is now deprecated.
The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers.
Note: [RFC2068] was not clear that 305 was intended to redirect a
single request, and to be generated by origin servers only. Not
observing these limitations has significant security consequences.
9.3.7. 306 (Unused) 9.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.
9.3.8. 307 Temporary Redirect 9.3.8. 307 Temporary Redirect
The requested resource resides temporarily under a different URI. The requested resource resides temporarily under a different URI.
Since the redirection MAY be altered on occasion, the client SHOULD Since the redirection MAY be altered on occasion, the client SHOULD
skipping to change at page 30, line 16 skipping to change at page 30, line 36
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to request and response semantics. fields related to request and response semantics.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
10.1. Allow 10.1. Allow
The Allow entity-header field lists the set of methods supported by The Allow response-header field lists the set of methods advertised
the resource identified by the Request-URI. The purpose of this as supported by the resource identified by the Request-URI. The
field is strictly to inform the recipient of valid methods associated purpose of this field is strictly to inform the recipient of valid
with the resource. An Allow header field MUST be present in a 405 methods associated with the resource. An Allow header field MUST be
(Method Not Allowed) response. present in a 405 (Method Not Allowed) response.
Allow = "Allow" ":" #Method Allow = "Allow" ":" #Method
Example of use: Example of use:
Allow: GET, HEAD, PUT Allow: GET, HEAD, PUT
This field cannot prevent a client from trying other methods. The actual set of allowed methods is defined by the origin server at
However, the indications given by the Allow header field value SHOULD the time of each request.
be followed. The actual set of allowed methods is defined by the
origin server at the time of each request.
The Allow header field MAY be provided with a PUT request to
recommend the methods to be supported by the new or modified
resource. The server is not required to support these methods and
SHOULD include an Allow header in the response giving the actual
supported methods.
A proxy MUST NOT modify the Allow header field even if it does not A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent might have understand all the methods specified, since the user agent might have
other means of communicating with the origin server. other means of communicating with the origin server.
10.2. Expect 10.2. Expect
The Expect request-header field is used to indicate that particular The Expect request-header field is used to indicate that particular
server behaviors are required by the client. server behaviors are required by the client.
skipping to change at page 32, line 23 skipping to change at page 32, 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.
10.4. Location 10.4. Location
The Location response-header field is used to redirect the recipient The Location response-header field is used for the identification of
to a location other than the Request-URI for completion of the a new resource or to redirect the recipient to a location other than
request or identification of a new resource. For 201 (Created) the Request-URI for completion of the request. For 201 (Created)
responses, the Location is that of the new resource which was created responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. server's preferred URI for automatic redirection to the resource.
The field value consists of a single absolute URI. The field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI [ "#" fragment ] Location = "Location" ":" absoluteURI [ "#" fragment ]
An example is: An example is:
Location: http://www.example.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html
skipping to change at page 35, line 28 skipping to change at page 35, line 44
significance for identifying the application. significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment ) User-Agent = "User-Agent" ":" 1*( product | comment )
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
11. IANA Considerations 11. IANA Considerations
[[anchor1: TBD.]] 11.1. Status Code Registry
The registration procedure for HTTP Status Codes -- previously
defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1
of this document.
The HTTP Status Code Registry located at
<http://www.iana.org/assignments/http-status-codes> should be updated
with the registrations below:
+-------+---------------------------------+----------------+
| Value | Description | Reference |
+-------+---------------------------------+----------------+
| 100 | Continue | Section 9.1.1 |
| 101 | Switching Protocols | Section 9.1.2 |
| 200 | OK | Section 9.2.1 |
| 201 | Created | Section 9.2.2 |
| 202 | Accepted | Section 9.2.3 |
| 203 | Non-Authoritative Information | Section 9.2.4 |
| 204 | No Content | Section 9.2.5 |
| 205 | Reset Content | Section 9.2.6 |
| 206 | Partial Content | Section 9.2.7 |
| 300 | Multiple Choices | Section 9.3.1 |
| 301 | Moved Permanently | Section 9.3.2 |
| 302 | Found | Section 9.3.3 |
| 303 | See Other | Section 9.3.4 |
| 304 | Not Modified | Section 9.3.5 |
| 305 | Use Proxy | Section 9.3.6 |
| 306 | (Unused) | Section 9.3.7 |
| 307 | Temporary Redirect | Section 9.3.8 |
| 400 | Bad Request | Section 9.4.1 |
| 401 | Unauthorized | Section 9.4.2 |
| 402 | Payment Required | Section 9.4.3 |
| 403 | Forbidden | Section 9.4.4 |
| 404 | Not Found | Section 9.4.5 |
| 405 | Method Not Allowed | Section 9.4.6 |
| 406 | Not Acceptable | Section 9.4.7 |
| 407 | Proxy Authentication Required | Section 9.4.8 |
| 408 | Request Timeout | Section 9.4.9 |
| 409 | Conflict | Section 9.4.10 |
| 410 | Gone | Section 9.4.11 |
| 411 | Length Required | Section 9.4.12 |
| 412 | Precondition Failed | Section 9.4.13 |
| 413 | Request Entity Too Large | Section 9.4.14 |
| 414 | Request-URI Too Long | Section 9.4.15 |
| 415 | Unsupported Media Type | Section 9.4.16 |
| 416 | Requested Range Not Satisfiable | Section 9.4.17 |
| 417 | Expectation Failed | Section 9.4.18 |
| 500 | Internal Server Error | Section 9.5.1 |
| 501 | Not Implemented | Section 9.5.2 |
| 502 | Bad Gateway | Section 9.5.3 |
| 503 | Service Unavailable | Section 9.5.4 |
| 504 | Gateway Timeout | Section 9.5.5 |
| 505 | HTTP Version Not Supported | Section 9.5.6 |
+-------+---------------------------------+----------------+
11.2. Message Header Registration
The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+--------------+
| Allow | http | standard | Section 10.1 |
| Expect | http | standard | Section 10.2 |
| From | http | standard | Section 10.3 |
| Location | http | standard | Section 10.4 |
| Max-Forwards | http | standard | Section 10.5 |
| Referer | http | standard | Section 10.6 |
| Retry-After | http | standard | Section 10.7 |
| Server | http | standard | Section 10.8 |
| User-Agent | http | standard | Section 10.9 |
+-------------------+----------+----------+--------------+
The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force".
12. Security Considerations 12. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
12.1. Transfer of Sensitive Information 12.1. Transfer of Sensitive Information
skipping to change at page 37, line 26 skipping to change at page 39, line 22
13. Acknowledgments 13. Acknowledgments
14. References 14. References
14.1. Normative References 14.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-02 and Message Parsing", draft-ietf-httpbis-p1-messaging-03
(work in progress), February 2008. (work in progress), June 2008.
[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-02 and Content Negotiation", draft-ietf-httpbis-p3-payload-03
(work in progress), February 2008. (work in progress), June 2008.
[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-02 (work in Requests", draft-ietf-httpbis-p4-conditional-03 (work in
progress), February 2008. progress), June 2008.
[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-02 (work Partial Responses", draft-ietf-httpbis-p5-range-03 (work
in progress), February 2008. in progress), June 2008.
[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.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-02 (work in progress), draft-ietf-httpbis-p6-cache-03 (work in progress),
February 2008. June 2008.
[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-02 (work in progress), draft-ietf-httpbis-p7-auth-03 (work in progress),
February 2008. June 2008.
[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.
14.2. Informative References 14.2. Informative References
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
proxy servers", draft-luotonen-web-proxy-tunneling-01 proxy servers", draft-luotonen-web-proxy-tunneling-01
(work in progress), August 1998. (work in progress), August 1998.
skipping to change at page 38, line 33 skipping to change at page 40, line 28
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
A.1. Changes from RFC 2068 A.1. Changes from RFC 2068
Clarified which error code should be used for inbound server failures Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 9.5.5). (e.g. DNS failures). (Section 9.5.5).
201 (Created) had a race that required an Etag be sent when a 201 (Created) had a race that required an Etag be sent when a
resource is first created. (Section 9.2.2). resource is first created. (Section 9.2.2).
skipping to change at page 39, line 34 skipping to change at page 41, line 39
7. Allow servers to defend against denial-of-service attacks and 7. Allow servers to defend against denial-of-service attacks and
broken clients. broken clients.
This change adds the Expect header and 417 status code. This change adds the Expect header and 417 status code.
Clean up confusion between 403 and 404 responses. (Section 9.4.4, Clean up confusion between 403 and 404 responses. (Section 9.4.4,
9.4.5, and 9.4.11) 9.4.5, and 9.4.11)
The PATCH, LINK, UNLINK methods were defined but not commonly The PATCH, LINK, UNLINK methods were defined but not commonly
implemented in previous versions of this specification. See implemented in previous versions of this specification. See Section
[RFC2068]. 19.6.1 of [RFC2068].
A.2. Changes from RFC 2616 A.2. Changes from RFC 2616
This document takes over the Status Code Registry, previously defined
in Section 7.1 of [RFC2817]. (Section 5.1)
Clarify definition of POST. (Section 8.5) Clarify definition of POST. (Section 8.5)
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 9.3.2, 9.3.3 and 9.3.8 ) semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 )
Deprecate 305 Use Proxy status code, because user agents did not
implement it. It used to indicate that the requested resource must
be accessed through the proxy given by the Location field. The
Location field gave the URI of the proxy. The recipient was expected
to repeat this single request via the proxy. (Section 9.3.6)
Reclassify Allow header as response header, removing the option to
specify it in a PUT request. Relax the server requirement on the
contents of the Allow header and remove requirement on clients to
always trust the header value. (Section 10.1)
Correct syntax of Location header to allow fragment, as referred Correct syntax of Location header to allow fragment, as referred
symbol wasn't what was expected, and add some clarifications as to symbol wasn't what was expected, and add some clarifications as to
when it would not be appropriate. (Section 10.4) when it would not be appropriate. (Section 10.4)
In the description of the Server header, the Via field was described In the description of the Server header, the Via field was described
as a SHOULD. The requirement was and is stated correctly in the as a SHOULD. The requirement was and is stated correctly in the
description of the Via header in Section 8.9 of [Part1]. description of the Via header in Section 8.9 of [Part1].
(Section 10.8) (Section 10.8)
Appendix B. Change Log (to be removed by RFC Editor before publication) Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1. Since RFC2616 B.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
B.2. Since draft-ietf-httpbis-p2-semantics-00 B.2. Since draft-ietf-httpbis-p2-semantics-00
skipping to change at page 41, line 27 skipping to change at page 43, line 39
o Move "Product Tokens" section (back) into Part 1, as "token" is o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header. used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
o Copy definition of delta-seconds from Part6 instead of referencing o Copy definition of delta-seconds from Part6 instead of referencing
it. it.
B.4. Since draft-ietf-httpbis-p2-semantics-02
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
Allow in 405 responses"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status
Code Registry"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>:
"Redirection vs. Location"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>:
"Cacheability of 303 response"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use
Proxy"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>:
"Classification for Allow header"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT -
'store under' vs 'store at'"
Ongoing work on IANA Message Header Registration
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers
defined in this document.
Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Replace string literals when the string really is case-sensitive
(method).
Index Index
1 1
100 Continue (status code) 18 100 Continue (status code) 19
101 Switching Protocols (status code) 19 101 Switching Protocols (status code) 19
2 2
200 OK (status code) 19 200 OK (status code) 19
201 Created (status code) 19 201 Created (status code) 20
202 Accepted (status code) 20 202 Accepted (status code) 20
203 Non-Authoritative Information (status code) 20 203 Non-Authoritative Information (status code) 20
204 No Content (status code) 20 204 No Content (status code) 21
205 Reset Content (status code) 21 205 Reset Content (status code) 21
206 Partial Content (status code) 21 206 Partial Content (status code) 21
3 3
300 Multiple Choices (status code) 21 300 Multiple Choices (status code) 22
301 Moved Permanently (status code) 22 301 Moved Permanently (status code) 22
302 Found (status code) 22 302 Found (status code) 23
303 See Other (status code) 23 303 See Other (status code) 23
304 Not Modified (status code) 23 304 Not Modified (status code) 24
305 Use Proxy (status code) 23 305 Use Proxy (status code) 24
306 (Unused) (status code) 24 306 (Unused) (status code) 24
307 Temporary Redirect (status code) 24 307 Temporary Redirect (status code) 24
4 4
400 Bad Request (status code) 25 400 Bad Request (status code) 25
401 Unauthorized (status code) 25 401 Unauthorized (status code) 25
402 Payment Required (status code) 25 402 Payment Required (status code) 25
403 Forbidden (status code) 25 403 Forbidden (status code) 25
404 Not Found (status code) 25 404 Not Found (status code) 26
405 Method Not Allowed (status code) 25 405 Method Not Allowed (status code) 26
406 Not Acceptable (status code) 25 406 Not Acceptable (status code) 26
407 Proxy Authentication Required (status code) 26 407 Proxy Authentication Required (status code) 26
408 Request Timeout (status code) 26 408 Request Timeout (status code) 27
409 Conflict (status code) 26 409 Conflict (status code) 27
410 Gone (status code) 27 410 Gone (status code) 27
411 Length Required (status code) 27 411 Length Required (status code) 28
412 Precondition Failed (status code) 27 412 Precondition Failed (status code) 28
413 Request Entity Too Large (status code) 27 413 Request Entity Too Large (status code) 28
414 Request-URI Too Long (status code) 28 414 Request-URI Too Long (status code) 28
415 Unsupported Media Type (status code) 28 415 Unsupported Media Type (status code) 28
416 Requested Range Not Satisfiable (status code) 28 416 Requested Range Not Satisfiable (status code) 28
417 Expectation Failed (status code) 28 417 Expectation Failed (status code) 29
5 5
500 Internal Server Error (status code) 28 500 Internal Server Error (status code) 29
501 Not Implemented (status code) 29 501 Not Implemented (status code) 29
502 Bad Gateway (status code) 29 502 Bad Gateway (status code) 29
503 Service Unavailable (status code) 29 503 Service Unavailable (status code) 29
504 Gateway Timeout (status code) 29 504 Gateway Timeout (status code) 30
505 HTTP Version Not Supported (status code) 29 505 HTTP Version Not Supported (status code) 30
A A
Allow header 30 Allow header 30
C C
CONNECT method 18 CONNECT method 18
D D
DELETE method 17 DELETE method 17
E E
Expect header 30 Expect header 31
F F
From header 31 From header 31
G G
GET method 14 GET method 14
Grammar Grammar
Allow 30 Allow 30
delta-seconds 34 delta-seconds 34
Expect 30 Expect 31
expect-params 30 expect-params 31
expectation 30 expectation 31
expectation-extension 30 expectation-extension 31
extension-code 10 extension-code 10
extension-method 8 extension-method 8
From 31 From 32
Location 32 Location 32
Max-Forwards 33 Max-Forwards 33
Method 8 Method 8
Reason-Phrase 10 Reason-Phrase 10
Referer 33 Referer 34
request-header 9 request-header 9
response-header 11 response-header 11
Retry-After 34 Retry-After 34
Server 34 Server 35
Status-Code 10 Status-Code 10
User-Agent 35 User-Agent 35
H H
HEAD method 14 HEAD method 15
Headers Headers
Allow 30 Allow 30
Expect 30 Expect 31
From 31 From 31
Location 32 Location 32
Max-Forwards 33 Max-Forwards 33
Referer 33 Referer 33
Retry-After 34 Retry-After 34
Server 34 Server 34
User-Agent 35 User-Agent 35
L L
LINK method 39 LINK method 41
Location header 32 Location header 32
M M
Max-Forwards header 33 Max-Forwards header 33
Methods Methods
CONNECT 18 CONNECT 18
DELETE 17 DELETE 17
GET 14 GET 14
HEAD 14 HEAD 15
LINK 39 LINK 41
OPTIONS 13 OPTIONS 13
PATCH 39 PATCH 41
POST 15 POST 15
PUT 16 PUT 16
TRACE 17 TRACE 17
UNLINK 39 UNLINK 41
O O
OPTIONS method 13 OPTIONS method 13
P P
PATCH method 39 PATCH method 41
POST method 15 POST method 15
PUT method 16 PUT method 16
R R
Referer header 33 Referer header 33
Retry-After header 34 Retry-After header 34
S S
Server header 34 Server header 34
Status Codes Status Codes
100 Continue 18 100 Continue 19
101 Switching Protocols 19 101 Switching Protocols 19
200 OK 19 200 OK 19
201 Created 19 201 Created 20
202 Accepted 20 202 Accepted 20
203 Non-Authoritative Information 20 203 Non-Authoritative Information 20
204 No Content 20 204 No Content 21
205 Reset Content 21 205 Reset Content 21
206 Partial Content 21 206 Partial Content 21
300 Multiple Choices 21 300 Multiple Choices 22
301 Moved Permanently 22 301 Moved Permanently 22
302 Found 22 302 Found 23
303 See Other 23 303 See Other 23
304 Not Modified 23 304 Not Modified 24
305 Use Proxy 23 305 Use Proxy 24
306 (Unused) 24 306 (Unused) 24
307 Temporary Redirect 24 307 Temporary Redirect 24
400 Bad Request 25 400 Bad Request 25
401 Unauthorized 25 401 Unauthorized 25
402 Payment Required 25 402 Payment Required 25
403 Forbidden 25 403 Forbidden 25
404 Not Found 25 404 Not Found 26
405 Method Not Allowed 25 405 Method Not Allowed 26
406 Not Acceptable 25 406 Not Acceptable 26
407 Proxy Authentication Required 26 407 Proxy Authentication Required 26
408 Request Timeout 26 408 Request Timeout 27
409 Conflict 26 409 Conflict 27
410 Gone 27 410 Gone 27
411 Length Required 27 411 Length Required 28
412 Precondition Failed 27 412 Precondition Failed 28
413 Request Entity Too Large 27 413 Request Entity Too Large 28
414 Request-URI Too Long 28 414 Request-URI Too Long 28
415 Unsupported Media Type 28 415 Unsupported Media Type 28
416 Requested Range Not Satisfiable 28 416 Requested Range Not Satisfiable 28
417 Expectation Failed 28 417 Expectation Failed 29
500 Internal Server Error 28 500 Internal Server Error 29
501 Not Implemented 29 501 Not Implemented 29
502 Bad Gateway 29 502 Bad Gateway 29
503 Service Unavailable 29 503 Service Unavailable 29
504 Gateway Timeout 29 504 Gateway Timeout 30
505 HTTP Version Not Supported 29 505 HTTP Version Not Supported 30
T T
TRACE method 17 TRACE method 17
U U
UNLINK method 39 UNLINK method 41
User-Agent header 35 User-Agent header 35
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
skipping to change at page 48, line 44 skipping to change at line 2290
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 88 change blocks. 
180 lines changed or deleted 326 lines changed or added

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