draft-ietf-httpbis-p2-semantics-05.txt | draft-ietf-httpbis-p2-semantics-06.txt | |||
---|---|---|---|---|
Network Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Updates: 2817 (if approved) One Laptop per Child | Updates: 2817 (if approved) One Laptop per Child | |||
Intended status: Standards Track J. Mogul | Intended status: Standards Track J. Mogul | |||
Expires: May 20, 2009 HP | Expires: September 10, 2009 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 | |||
November 16, 2008 | March 9, 2009 | |||
HTTP/1.1, part 2: Message Semantics | HTTP/1.1, part 2: Message Semantics | |||
draft-ietf-httpbis-p2-semantics-05 | draft-ietf-httpbis-p2-semantics-06 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | This Internet-Draft is submitted to IETF in full conformance with the | |||
applicable patent or other IPR claims of which he or she is aware | provisions of BCP 78 and BCP 79. This document may contain material | |||
have been or will be disclosed, and any of which he or she becomes | from IETF Documents or IETF Contributions published or made publicly | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | ||||
Trust the right to allow modifications of such material outside the | ||||
IETF Standards Process. Without obtaining an adequate license from | ||||
the person(s) controlling the copyright in such materials, this | ||||
document may not be modified outside the IETF Standards Process, and | ||||
derivative works of it may not be created outside the IETF Standards | ||||
Process, except to format it for publication as an RFC or to | ||||
translate it into languages other than English. | ||||
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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
skipping to change at page 1, line 42 | skipping to change at page 2, line 4 | |||
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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on May 20, 2009. | This Internet-Draft will expire on September 10, 2009. | |||
Copyright Notice | ||||
Copyright (c) 2009 IETF Trust and the persons identified as the | ||||
document authors. All rights reserved. | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | ||||
Provisions Relating to IETF Documents in effect on the date of | ||||
publication of this document (http://trustee.ietf.org/license-info). | ||||
Please review these documents carefully, as they describe your rights | ||||
and restrictions with respect to this document. | ||||
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 25 | skipping to change at page 2, line 43 | |||
fields. | fields. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix B.6. | The changes in this draft are summarized in Appendix C.7. | |||
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 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 | 1.2.2. ABNF Rules defined in other Parts of the | |||
4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 | Specification . . . . . . . . . . . . . . . . . . . . 7 | |||
5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 | 2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 | 2.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8 | |||
6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 | 3. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9 | |||
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10 | |||
8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 | 4.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 | 5. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 | 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 | 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13 | |||
8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 7.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13 | |||
8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14 | |||
8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 | 7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 | 7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19 | 7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 | 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20 | 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 19 | |||
9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 | 8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 20 | |||
9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20 | 8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 20 | |||
9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 | 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 | 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21 | 8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 21 | |||
9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 | 8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 21 | |||
9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 | 8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 21 | |||
9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 | 8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 22 | |||
9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22 | 8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 22 | |||
9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 | 8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 22 | |||
9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23 | 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 22 | |||
9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 | 8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 23 | |||
9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 | 8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 23 | |||
9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 | 8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 24 | |||
9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 | 8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 24 | |||
9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 | 8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 25 | |||
9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25 | 8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 25 | |||
9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 | 8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 25 | |||
9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 | 8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 25 | |||
9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 | 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 26 | |||
9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 | 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 26 | |||
9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26 | 8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 26 | |||
9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 | 8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 26 | |||
9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 | 8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 26 | |||
9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 | 8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 27 | |||
9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27 | 8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 27 | |||
9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27 | 8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 27 | |||
9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 | 8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 27 | |||
9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28 | 8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 28 | |||
9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28 | 8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 28 | |||
9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 | 8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 29 | 8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 29 | |||
9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 | 8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 29 | |||
9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 | 8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 29 | |||
9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29 | 8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 29 | |||
9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29 | 8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 29 | |||
9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 | 8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 29 | |||
9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 | 8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 30 | |||
9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 | 8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 30 | |||
9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 | 8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 30 | |||
9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30 | 8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 30 | |||
9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 | 8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 30 | |||
10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31 | 8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 30 | |||
10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 31 | |||
10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 31 | |||
10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 31 | |||
10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 | 9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 | 9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 | 9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 | 9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
11.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 36 | 9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
11.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 | 9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
11.3. Message Header Registration . . . . . . . . . . . . . . . 39 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 | 10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 37 | |||
12.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 | 10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 37 | |||
12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 | 10.3. Message Header Registration . . . . . . . . . . . . . . . 39 | |||
12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 | |||
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 | 11.1. Transfer of Sensitive Information . . . . . . . . . . . . 39 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | 11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 40 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . . 41 | 11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 41 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . . 42 | 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | ||||
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 | ||||
13.2. Informative References . . . . . . . . . . . . . . . . . . 42 | ||||
Appendix A. Compatibility with Previous Versions . . . . . . . . 42 | Appendix A. Compatibility with Previous Versions . . . . . . . . 42 | |||
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42 | |||
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43 | |||
Appendix B. Change Log (to be removed by RFC Editor before | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44 | |||
publication) . . . . . . . . . . . . . . . . . . . . 44 | Appendix C. Change Log (to be removed by RFC Editor before | |||
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44 | publication) . . . . . . . . . . . . . . . . . . . . 47 | |||
B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44 | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47 | |||
B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45 | C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47 | |||
B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45 | C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47 | |||
B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46 | C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48 | |||
B.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46 | C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 | C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 | C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 54 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 | ||||
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 6, line 42 | skipping to change at page 6, line 42 | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the MUST or REQUIRED level requirements for the protocols it | of the MUST or REQUIRED level requirements for the protocols it | |||
implements. An implementation that satisfies all the MUST or | implements. An implementation that satisfies all the MUST or | |||
REQUIRED level and all the SHOULD level requirements for its | REQUIRED level and all the SHOULD level requirements for its | |||
protocols is said to be "unconditionally compliant"; one that | protocols is said to be "unconditionally compliant"; one that | |||
satisfies all the MUST level requirements but not all the SHOULD | satisfies all the MUST level requirements but not all the SHOULD | |||
level requirements for its protocols is said to be "conditionally | level requirements for its protocols is said to be "conditionally | |||
compliant." | compliant." | |||
2. Notational Conventions and Generic Grammar | 1.2. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 2.1 of | This specification uses the ABNF syntax defined in Section 1.2 of | |||
[Part1] and the core rules defined in Section 2.2 of [Part1]: | [Part1] (which extends the syntax defined in [RFC5234] with a list | |||
rule). Appendix B shows the collected ABNF, with the list rule | ||||
expanded. | ||||
DIGIT = <DIGIT, defined in [Part1], Section 2.2> | The following core rules are included by reference, as defined in | |||
comment = <comment, defined in [Part1], Section 2.2> | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
quoted-string = <quoted-string, defined in [Part1], Section 2.2> | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
token = <token, defined in [Part1], Section 2.2> | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
OWS = <OWS, defined in [Part1], Section 2.2> | sequence of data), SP (space), VCHAR (any visible USASCII character), | |||
RWS = <RWS, defined in [Part1], Section 2.2> | and WSP (whitespace). | |||
1.2.1. Core Rules | ||||
The core rules below are defined in Section 1.2.2 of [Part1]: | ||||
comment = <comment, defined in [Part1], Section 1.2.2> | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | ||||
token = <token, 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> | ||||
obs-text = <obs-text, defined in [Part1], Section 1.2.2> | ||||
1.2.2. ABNF Rules defined in other Parts of the Specification | ||||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
absolute-URI = <absolute-URI, defined in [Part1], Section 3.2> | absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> | |||
fragment = <fragment, defined in [Part1], Section 3.2> | fragment = <fragment, defined in [Part1], Section 2.1> | |||
Host = <Host, defined in [Part1], Section 3.2> | Host = <Host, defined in [Part1], Section 2.1> | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> | HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> | |||
product = <product, defined in [Part1], Section 3.5> | partial-URI = <partial-URI, defined in [Part1], Section 2.1> | |||
relativeURI = <relativeURI, defined in [Part1], Section 3.2> | product = <product, defined in [Part1], Section 3.4> | |||
TE = <TE, defined in [Part1], Section 8.8> | TE = <TE, defined in [Part1], Section 8.8> | |||
Accept = <Accept, defined in [Part3], Section 6.1> | Accept = <Accept, defined in [Part3], Section 5.1> | |||
Accept-Charset = | Accept-Charset = | |||
<Accept-Charset, defined in [Part3], Section 6.2> | <Accept-Charset, defined in [Part3], Section 5.2> | |||
Accept-Encoding = | Accept-Encoding = | |||
<Accept-Encoding, defined in [Part3], Section 6.3> | <Accept-Encoding, defined in [Part3], Section 5.3> | |||
Accept-Language = | Accept-Language = | |||
<Accept-Language, defined in [Part3], Section 6.4> | <Accept-Language, defined in [Part3], Section 5.4> | |||
ETag = <ETag, defined in [Part4], Section 7.1> | ETag = <ETag, defined in [Part4], Section 6.1> | |||
If-Match = <If-Match, defined in [Part4], Section 7.2> | If-Match = <If-Match, defined in [Part4], Section 6.2> | |||
If-Modified-Since = | If-Modified-Since = | |||
<If-Modified-Since, defined in [Part4], Section 7.3> | <If-Modified-Since, defined in [Part4], Section 6.3> | |||
If-None-Match = <If-None-Match, defined in [Part4], Section 7.4> | If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> | |||
If-Unmodified-Since = | If-Unmodified-Since = | |||
<If-Unmodified-Since, defined in [Part4], Section 7.5> | <If-Unmodified-Since, defined in [Part4], Section 6.5> | |||
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1> | Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> | |||
If-Range = <If-Range, defined in [Part5], Section 6.3> | If-Range = <If-Range, defined in [Part5], Section 5.3> | |||
Range = <Range, defined in [Part5], Section 6.4> | Range = <Range, defined in [Part5], Section 5.4> | |||
Age = <Age, defined in [Part6], Section 3.1> | ||||
Vary = <Vary, defined in [Part6], Section 3.5> | ||||
Age = <Age, defined in [Part6], Section 16.1> | Authorization = <Authorization, defined in [Part7], Section 3.1> | |||
Vary = <Vary, defined in [Part6], Section 16.5> | ||||
Authorization = <Authorization, defined in [Part7], Section 4.1> | ||||
Proxy-Authenticate = | Proxy-Authenticate = | |||
<Proxy-Authenticate, defined in [Part7], Section 4.2> | <Proxy-Authenticate, defined in [Part7], Section 3.2> | |||
Proxy-Authorization = | Proxy-Authorization = | |||
<Proxy-Authorization, defined in [Part7], Section 4.3> | <Proxy-Authorization, defined in [Part7], Section 3.3> | |||
WWW-Authenticate = | WWW-Authenticate = | |||
<WWW-Authenticate, defined in [Part7], Section 4.4> | <WWW-Authenticate, defined in [Part7], Section 3.4> | |||
3. Method | 2. 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-target. The method is case-sensitive. | |||
Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2 | Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 7.2 | |||
/ %x47.45.54 ; "GET", Section 8.3 | / %x47.45.54 ; "GET", Section 7.3 | |||
/ %x48.45.41.44 ; "HEAD", Section 8.4 | / %x48.45.41.44 ; "HEAD", Section 7.4 | |||
/ %x50.4F.53.54 ; "POST", Section 8.5 | / %x50.4F.53.54 ; "POST", Section 7.5 | |||
/ %x50.55.54 ; "PUT", Section 8.6 | / %x50.55.54 ; "PUT", Section 7.6 | |||
/ %x44.45.4C.45.54.45 ; "DELETE", Section 8.7 | / %x44.45.4C.45.54.45 ; "DELETE", Section 7.7 | |||
/ %x54.52.41.43.45 ; "TRACE", Section 8.8 | / %x54.52.41.43.45 ; "TRACE", Section 7.8 | |||
/ %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9 | / %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 7.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 9.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 | |||
is unrecognized or not implemented by the origin server. The methods | is unrecognized or not implemented by the origin server. The methods | |||
GET and HEAD MUST be supported by all general-purpose servers. All | GET and HEAD MUST be supported by all general-purpose servers. All | |||
other methods are OPTIONAL; however, if the above methods are | other methods are OPTIONAL; however, if the above methods are | |||
implemented, they MUST be implemented with the same semantics as | implemented, they MUST be implemented with the same semantics as | |||
those specified in Section 8. | those specified in Section 7. | |||
3.1. Method Registry | 2.1. Method Registry | |||
The HTTP Method Registry defines the name space for the Method token | The HTTP Method Registry defines the name space for the Method token | |||
in the Request line of an HTTP request. | in the Request line of an HTTP request. | |||
Registrations MUST include the following fields: | Registrations MUST include the following fields: | |||
o Method Name (see Section 3) | o Method Name (see Section 2) | |||
o Safe ("yes" or "no", see Section 8.1.1) | ||||
o Safe ("yes" or "no", see Section 7.1.1) | ||||
o Pointer to specification text | o Pointer to specification text | |||
Values to be added to this name space are subject to IETF review | Values to be added to this name space are subject to IETF review | |||
([RFC5226], Section 4.1). Any document registering new method names | ([RFC5226], Section 4.1). Any document registering new method names | |||
should be traceable through statuses of either 'Obsoletes' or | should be traceable through statuses of either 'Obsoletes' or | |||
'Updates' to this document. | 'Updates' to this document. | |||
The registry itself is maintained at | The registry itself is maintained at | |||
<http://www.iana.org/assignments/http-methods>. | <http://www.iana.org/assignments/http-methods>. | |||
4. Request Header Fields | 3. Request Header Fields | |||
The request-header fields allow the client to pass additional | The request-header fields allow the client to pass additional | |||
information about the request, and about the client itself, to the | information about the request, and about the client itself, to the | |||
server. These fields act as request modifiers, with semantics | server. These fields act as request modifiers, with semantics | |||
equivalent to the parameters on a programming language method | equivalent to the parameters on a programming language method | |||
invocation. | invocation. | |||
request-header = Accept ; [Part3], Section 6.1 | request-header = Accept ; [Part3], Section 5.1 | |||
/ Accept-Charset ; [Part3], Section 6.2 | / Accept-Charset ; [Part3], Section 5.2 | |||
/ Accept-Encoding ; [Part3], Section 6.3 | / Accept-Encoding ; [Part3], Section 5.3 | |||
/ Accept-Language ; [Part3], Section 6.4 | / Accept-Language ; [Part3], Section 5.4 | |||
/ Authorization ; [Part7], Section 4.1 | / Authorization ; [Part7], Section 3.1 | |||
/ Expect ; Section 10.2 | / Expect ; Section 9.2 | |||
/ From ; Section 10.3 | / From ; Section 9.3 | |||
/ Host ; [Part1], Section 8.4 | / Host ; [Part1], Section 8.4 | |||
/ If-Match ; [Part4], Section 7.2 | / If-Match ; [Part4], Section 6.2 | |||
/ If-Modified-Since ; [Part4], Section 7.3 | / If-Modified-Since ; [Part4], Section 6.3 | |||
/ If-None-Match ; [Part4], Section 7.4 | / If-None-Match ; [Part4], Section 6.4 | |||
/ If-Range ; [Part5], Section 6.3 | / If-Range ; [Part5], Section 5.3 | |||
/ If-Unmodified-Since ; [Part4], Section 7.5 | / If-Unmodified-Since ; [Part4], Section 6.5 | |||
/ Max-Forwards ; Section 10.5 | / Max-Forwards ; Section 9.5 | |||
/ Proxy-Authorization ; [Part7], Section 4.3 | / Proxy-Authorization ; [Part7], Section 3.3 | |||
/ Range ; [Part5], Section 6.4 | / Range ; [Part5], Section 5.4 | |||
/ Referer ; Section 10.6 | / Referer ; Section 9.6 | |||
/ TE ; [Part1], Section 8.8 | / TE ; [Part1], Section 8.8 | |||
/ User-Agent ; Section 10.9 | / User-Agent ; Section 9.9 | |||
Request-header field names can be extended reliably only in | Request-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of request- | experimental header fields MAY be given the semantics of request- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be request-header fields. Unrecognized header fields are treated as | be request-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
5. Status Code and Reason Phrase | 4. Status Code and Reason Phrase | |||
The Status-Code element is a 3-digit integer result code of the | The Status-Code element is a 3-digit integer result code of the | |||
attempt to understand and satisfy the request. The status codes | attempt to understand and satisfy the request. The status codes | |||
listed below are defined in Section 9. The Reason-Phrase is intended | listed below are defined in Section 8. The Reason-Phrase is intended | |||
to give a short textual description of the Status-Code. The Status- | to give a short textual description of the Status-Code. The Status- | |||
Code is intended for use by automata and the Reason-Phrase is | Code is intended for use by automata and the Reason-Phrase is | |||
intended for the human user. The client is not required to examine | intended for the human user. The client is not required to examine | |||
or display the Reason-Phrase. | or display the Reason-Phrase. | |||
The individual values of the numeric status codes defined for | The individual values of the numeric status codes defined for | |||
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | HTTP/1.1, and an example set of corresponding Reason-Phrase's, are | |||
presented below. The reason phrases listed here are only | presented below. The reason phrases listed here are only | |||
recommendations -- they MAY be replaced by local equivalents without | recommendations -- they MAY be replaced by local equivalents without | |||
affecting the protocol. | affecting the protocol. | |||
Status-Code = | Status-Code = | |||
"100" ; Section 9.1.1: Continue | "100" ; Section 8.1.1: Continue | |||
/ "101" ; Section 9.1.2: Switching Protocols | / "101" ; Section 8.1.2: Switching Protocols | |||
/ "200" ; Section 9.2.1: OK | / "200" ; Section 8.2.1: OK | |||
/ "201" ; Section 9.2.2: Created | / "201" ; Section 8.2.2: Created | |||
/ "202" ; Section 9.2.3: Accepted | / "202" ; Section 8.2.3: Accepted | |||
/ "203" ; Section 9.2.4: Non-Authoritative Information | / "203" ; Section 8.2.4: Non-Authoritative Information | |||
/ "204" ; Section 9.2.5: No Content | / "204" ; Section 8.2.5: No Content | |||
/ "205" ; Section 9.2.6: Reset Content | / "205" ; Section 8.2.6: Reset Content | |||
/ "206" ; Section 9.2.7: Partial Content | / "206" ; Section 8.2.7: Partial Content | |||
/ "300" ; Section 9.3.1: Multiple Choices | / "300" ; Section 8.3.1: Multiple Choices | |||
/ "301" ; Section 9.3.2: Moved Permanently | / "301" ; Section 8.3.2: Moved Permanently | |||
/ "302" ; Section 9.3.3: Found | / "302" ; Section 8.3.3: Found | |||
/ "303" ; Section 9.3.4: See Other | / "303" ; Section 8.3.4: See Other | |||
/ "304" ; Section 9.3.5: Not Modified | / "304" ; Section 8.3.5: Not Modified | |||
/ "305" ; Section 9.3.6: Use Proxy | / "305" ; Section 8.3.6: Use Proxy | |||
/ "307" ; Section 9.3.8: Temporary Redirect | / "307" ; Section 8.3.8: Temporary Redirect | |||
/ "400" ; Section 9.4.1: Bad Request | / "400" ; Section 8.4.1: Bad Request | |||
/ "401" ; Section 9.4.2: Unauthorized | / "401" ; Section 8.4.2: Unauthorized | |||
/ "402" ; Section 9.4.3: Payment Required | / "402" ; Section 8.4.3: Payment Required | |||
/ "403" ; Section 9.4.4: Forbidden | / "403" ; Section 8.4.4: Forbidden | |||
/ "404" ; Section 9.4.5: Not Found | / "404" ; Section 8.4.5: Not Found | |||
/ "405" ; Section 9.4.6: Method Not Allowed | / "405" ; Section 8.4.6: Method Not Allowed | |||
/ "406" ; Section 9.4.7: Not Acceptable | / "406" ; Section 8.4.7: Not Acceptable | |||
/ "407" ; Section 9.4.8: Proxy Authentication Required | / "407" ; Section 8.4.8: Proxy Authentication Required | |||
/ "408" ; Section 9.4.9: Request Time-out | / "408" ; Section 8.4.9: Request Time-out | |||
/ "409" ; Section 9.4.10: Conflict | / "409" ; Section 8.4.10: Conflict | |||
/ "410" ; Section 9.4.11: Gone | / "410" ; Section 8.4.11: Gone | |||
/ "411" ; Section 9.4.12: Length Required | / "411" ; Section 8.4.12: Length Required | |||
/ "412" ; Section 9.4.13: Precondition Failed | / "412" ; Section 8.4.13: Precondition Failed | |||
/ "413" ; Section 9.4.14: Request Entity Too Large | / "413" ; Section 8.4.14: Request Entity Too Large | |||
/ "414" ; Section 9.4.15: Request-URI Too Large | / "414" ; Section 8.4.15: URI Too Long | |||
/ "415" ; Section 9.4.16: Unsupported Media Type | / "415" ; Section 8.4.16: Unsupported Media Type | |||
/ "416" ; Section 9.4.17: Requested range not satisfiable | / "416" ; Section 8.4.17: Requested range not satisfiable | |||
/ "417" ; Section 9.4.18: Expectation Failed | / "417" ; Section 8.4.18: Expectation Failed | |||
/ "500" ; Section 9.5.1: Internal Server Error | / "500" ; Section 8.5.1: Internal Server Error | |||
/ "501" ; Section 9.5.2: Not Implemented | / "501" ; Section 8.5.2: Not Implemented | |||
/ "502" ; Section 9.5.3: Bad Gateway | / "502" ; Section 8.5.3: Bad Gateway | |||
/ "503" ; Section 9.5.4: Service Unavailable | / "503" ; Section 8.5.4: Service Unavailable | |||
/ "504" ; Section 9.5.5: Gateway Time-out | / "504" ; Section 8.5.5: Gateway Time-out | |||
/ "505" ; Section 9.5.6: HTTP Version not supported | / "505" ; Section 8.5.6: HTTP Version not supported | |||
/ extension-code | / extension-code | |||
extension-code = 3DIGIT | extension-code = 3DIGIT | |||
Reason-Phrase = *<TEXT, excluding CR, LF> | Reason-Phrase = *( WSP / VCHAR / obs-text ) | |||
HTTP status codes are extensible. HTTP applications are not required | HTTP status codes are extensible. HTTP applications are not required | |||
to understand the meaning of all registered status codes, though such | to understand the meaning of all registered status codes, though such | |||
understanding is obviously desirable. However, applications MUST | understanding is obviously desirable. However, applications MUST | |||
understand the class of any status code, as indicated by the first | understand the class of any status code, as indicated by the first | |||
digit, and treat any unrecognized response as being equivalent to the | digit, and treat any unrecognized response as being equivalent to the | |||
x00 status code of that class, with the exception that an | x00 status code of that class, with the exception that an | |||
unrecognized response MUST NOT be cached. For example, if an | unrecognized response MUST NOT be cached. For example, if an | |||
unrecognized status code of 431 is received by the client, it can | unrecognized status code of 431 is received by the client, it can | |||
safely assume that there was something wrong with its request and | safely assume that there was something wrong with its request and | |||
treat the response as if it had received a 400 status code. In such | treat the response as if it had received a 400 status code. In such | |||
cases, user agents SHOULD present to the user the 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 | 4.1. Status Code Registry | |||
The HTTP Status Code Registry defines the name space for the Status- | The HTTP Status Code Registry defines the name space for the Status- | |||
Code token in the Status line of an HTTP response. | Code token in the Status line of an HTTP response. | |||
Values to be added to this name space are subject to IETF review | Values to be added to this name space are subject to IETF review | |||
([RFC5226], Section 4.1). Any document registering new status codes | ([RFC5226], Section 4.1). Any document registering new status codes | |||
should be traceable through statuses of either 'Obsoletes' or | should be traceable through statuses of either 'Obsoletes' or | |||
'Updates' to this document. | 'Updates' to this document. | |||
The registry itself is maintained at | The registry itself is maintained at | |||
<http://www.iana.org/assignments/http-status-codes>. | <http://www.iana.org/assignments/http-status-codes>. | |||
6. Response Header Fields | 5. Response Header Fields | |||
The response-header fields allow the server to pass additional | The response-header fields allow the server to pass additional | |||
information about the response which cannot be placed in the Status- | information about the response which cannot be placed in the Status- | |||
Line. These header fields give information about the server and | Line. These header fields give information about the server and | |||
about further access to the resource identified by the Request-URI. | about further access to the resource identified by the request- | |||
target. | ||||
response-header = Accept-Ranges ; [Part5], Section 6.1 | response-header = Accept-Ranges ; [Part5], Section 5.1 | |||
/ Age ; [Part6], Section 16.1 | / Age ; [Part6], Section 3.1 | |||
/ Allow ; Section 10.1 | / Allow ; Section 9.1 | |||
/ ETag ; [Part4], Section 7.1 | / ETag ; [Part4], Section 6.1 | |||
/ Location ; Section 10.4 | / Location ; Section 9.4 | |||
/ Proxy-Authenticate ; [Part7], Section 4.2 | / Proxy-Authenticate ; [Part7], Section 3.2 | |||
/ Retry-After ; Section 10.7 | / Retry-After ; Section 9.7 | |||
/ Server ; Section 10.8 | / Server ; Section 9.8 | |||
/ Vary ; [Part6], Section 16.5 | / Vary ; [Part6], Section 3.5 | |||
/ WWW-Authenticate ; [Part7], Section 4.4 | / WWW-Authenticate ; [Part7], Section 3.4 | |||
Response-header field names can be extended reliably only in | Response-header field names can be extended reliably only in | |||
combination with a change in the protocol version. However, new or | combination with a change in the protocol version. However, new or | |||
experimental header fields MAY be given the semantics of response- | experimental header fields MAY be given the semantics of response- | |||
header fields if all parties in the communication recognize them to | header fields if all parties in the communication recognize them to | |||
be response-header fields. Unrecognized header fields are treated as | be response-header fields. Unrecognized header fields are treated as | |||
entity-header fields. | entity-header fields. | |||
7. Entity | 6. Entity | |||
Request and Response messages MAY transfer an entity if not otherwise | Request and Response messages MAY transfer an entity if not otherwise | |||
restricted by the request method or response status code. An entity | restricted by the request method or response status code. An entity | |||
consists of entity-header fields and an entity-body, although some | consists of entity-header fields and an entity-body, although some | |||
responses will only include the entity-headers. HTTP entity-body and | responses will only include the entity-headers. HTTP entity-body and | |||
entity-header fields are defined in [Part3]. | entity-header fields are defined in [Part3]. | |||
An entity-body is only present in a message when a message-body is | An entity-body is only present in a message when a message-body is | |||
present, as described in Section 4.3 of [Part1]. The entity-body is | present, as described in Section 4.3 of [Part1]. The entity-body is | |||
obtained from the message-body by decoding any Transfer-Encoding that | obtained from the message-body by decoding any Transfer-Encoding that | |||
might have been applied to ensure safe and proper transfer of the | might have been applied to ensure safe and proper transfer of the | |||
message. | message. | |||
8. Method Definitions | 7. Method Definitions | |||
The set of common methods for HTTP/1.1 is defined below. Although | The set of common methods for HTTP/1.1 is defined below. Although | |||
this set can be expanded, additional methods cannot be assumed to | this set can be expanded, additional methods cannot be assumed to | |||
share the same semantics for separately extended clients and servers. | share the same semantics for separately extended clients and servers. | |||
8.1. Safe and Idempotent Methods | 7.1. Safe and Idempotent Methods | |||
8.1.1. Safe Methods | 7.1.1. Safe Methods | |||
Implementors should be aware that the software represents the user in | Implementors should be aware that the software represents the user in | |||
their interactions over the Internet, and should be careful to allow | their interactions over the Internet, and should be careful to allow | |||
the user to be aware of any actions they might take which may have an | the user to be aware of any actions they might take which may have an | |||
unexpected significance to themselves or others. | unexpected significance to themselves or others. | |||
In particular, the convention has been established that the GET and | In particular, the convention has been established that the GET and | |||
HEAD methods SHOULD NOT have the significance of taking an action | HEAD methods SHOULD NOT have the significance of taking an action | |||
other than retrieval. These methods ought to be considered "safe". | other than retrieval. These methods ought to be considered "safe". | |||
This allows user agents to represent other methods, such as POST, PUT | This allows user agents to represent other methods, such as POST, PUT | |||
and DELETE, in a special way, so that the user is made aware of the | and DELETE, in a special way, so that the user is made aware of the | |||
fact that a possibly unsafe action is being requested. | fact that a possibly unsafe action is being requested. | |||
Naturally, it is not possible to ensure that the server does not | Naturally, it is not possible to ensure that the server does not | |||
generate side-effects as a result of performing a GET request; in | generate side-effects as a result of performing a GET request; in | |||
fact, some dynamic resources consider that a feature. The important | fact, some dynamic resources consider that a feature. The important | |||
distinction here is that the user did not request the side-effects, | distinction here is that the user did not request the side-effects, | |||
so therefore cannot be held accountable for them. | so therefore cannot be held accountable for them. | |||
8.1.2. Idempotent Methods | 7.1.2. Idempotent Methods | |||
Methods can also have the property of "idempotence" in that (aside | Methods can also have the property of "idempotence" in that (aside | |||
from error or expiration issues) the side-effects of N > 0 identical | from error or expiration issues) the side-effects of N > 0 identical | |||
requests is the same as for a single request. The methods GET, HEAD, | requests is the same as for a single request. The methods GET, HEAD, | |||
PUT and DELETE share this property. Also, the methods OPTIONS and | PUT and DELETE share this property. Also, the methods OPTIONS and | |||
TRACE SHOULD NOT have side effects, and so are inherently idempotent. | TRACE SHOULD NOT have side effects, and so are inherently idempotent. | |||
However, it is possible that a sequence of several requests is non- | However, it is possible that a sequence of several requests is non- | |||
idempotent, even if all of the methods executed in that sequence are | idempotent, even if all of the methods executed in that sequence are | |||
idempotent. (A sequence is idempotent if a single execution of the | idempotent. (A sequence is idempotent if a single execution of the | |||
entire sequence always yields a result that is not changed by a | entire sequence always yields a result that is not changed by a | |||
reexecution of all, or part, of that sequence.) For example, a | reexecution of all, or part, of that sequence.) For example, a | |||
sequence is non-idempotent if its result depends on a value that is | sequence is non-idempotent if its result depends on a value that is | |||
later modified in the same sequence. | later modified in the same sequence. | |||
A sequence that never has side effects is idempotent, by definition | A sequence that never has side effects is idempotent, by definition | |||
(provided that no concurrent operations are being executed on the | (provided that no concurrent operations are being executed on the | |||
same set of resources). | same set of resources). | |||
8.2. OPTIONS | 7.2. OPTIONS | |||
The OPTIONS method represents a request for information about the | The OPTIONS method represents a request for information about the | |||
communication options available on the request/response chain | communication options available on the request/response chain | |||
identified by the Request-URI. This method allows the client to | identified by the request-target. This method allows the client to | |||
determine the options and/or requirements associated with a resource, | determine the options and/or requirements associated with a resource, | |||
or the capabilities of a server, without implying a resource action | or the capabilities of a server, without implying a resource action | |||
or initiating a resource retrieval. | or initiating a resource retrieval. | |||
Responses to this method are not cacheable. | Responses to this method are not cacheable. | |||
If the OPTIONS request includes an entity-body (as indicated by the | If the OPTIONS request includes an entity-body (as indicated by the | |||
presence of Content-Length or Transfer-Encoding), then the media type | presence of Content-Length or Transfer-Encoding), then the media type | |||
MUST be indicated by a Content-Type field. Although this | MUST be indicated by a Content-Type field. Although this | |||
specification does not define any use for such a body, future | specification does not define any use for such a body, future | |||
extensions to HTTP might use the OPTIONS body to make more detailed | extensions to HTTP might use the OPTIONS body to make more detailed | |||
queries on the server. | queries on the server. | |||
If the Request-URI is an asterisk ("*"), the OPTIONS request is | If the request-target is an asterisk ("*"), the OPTIONS request is | |||
intended to apply to the server in general rather than to a specific | intended to apply to the server in general rather than to a specific | |||
resource. Since a server's communication options typically depend on | resource. Since a server's communication options typically depend on | |||
the resource, the "*" request is only useful as a "ping" or "no-op" | the resource, the "*" request is only useful as a "ping" or "no-op" | |||
type of method; it does nothing beyond allowing the client to test | type of method; it does nothing beyond allowing the client to test | |||
the capabilities of the server. For example, this can be used to | the capabilities of the server. For example, this can be used to | |||
test a proxy for HTTP/1.1 compliance (or lack thereof). | test a proxy for HTTP/1.1 compliance (or lack thereof). | |||
If the Request-URI is not an asterisk, the OPTIONS request applies | If the request-target is not an asterisk, the OPTIONS request applies | |||
only to the options that are available when communicating with that | only to the options that are available when communicating with that | |||
resource. | resource. | |||
A 200 response SHOULD include any header fields that indicate | A 200 response SHOULD include any header fields that indicate | |||
optional features implemented by the server and applicable to that | optional features implemented by the server and applicable to that | |||
resource (e.g., Allow), possibly including extensions not defined by | resource (e.g., Allow), possibly including extensions not defined by | |||
this specification. The response body, if any, SHOULD also include | this specification. The response body, if any, SHOULD also include | |||
information about the communication options. The format for such a | information about the communication options. The format for such a | |||
body is not defined by this specification, but might be defined by | body is not defined by this specification, but might be defined by | |||
future extensions to HTTP. Content negotiation MAY be used to select | future extensions to HTTP. Content negotiation MAY be used to select | |||
skipping to change at page 15, line 29 | skipping to change at page 15, line 29 | |||
OPTIONS request on an absolute-URI for which request forwarding is | OPTIONS request on an absolute-URI for which request forwarding is | |||
permitted, the proxy MUST check for a Max-Forwards field. If the | permitted, the proxy MUST check for a Max-Forwards field. If the | |||
Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward | Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward | |||
the message; instead, the proxy SHOULD respond with its own | the message; instead, the proxy SHOULD respond with its own | |||
communication options. If the Max-Forwards field-value is an integer | communication options. If the Max-Forwards field-value is an integer | |||
greater than zero, the proxy MUST decrement the field-value when it | greater than zero, the proxy MUST decrement the field-value when it | |||
forwards the request. If no Max-Forwards field is present in the | forwards the request. If no Max-Forwards field is present in the | |||
request, then the forwarded request MUST NOT include a Max-Forwards | request, then the forwarded request MUST NOT include a Max-Forwards | |||
field. | field. | |||
8.3. GET | 7.3. GET | |||
The GET method means retrieve whatever information (in the form of an | The GET method means retrieve whatever information (in the form of an | |||
entity) is identified by the Request-URI. If the Request-URI refers | entity) is identified by the request-target. If the request-target | |||
to a data-producing process, it is the produced data which shall be | refers to a data-producing process, it is the produced data which | |||
returned as the entity in the response and not the source text of the | shall be returned as the entity in the response and not the source | |||
process, unless that text happens to be the output of the process. | text of the process, unless that text happens to be the output of the | |||
process. | ||||
The semantics of the GET method change to a "conditional GET" if the | The semantics of the GET method change to a "conditional GET" if the | |||
request message includes an If-Modified-Since, If-Unmodified-Since, | request message includes an If-Modified-Since, If-Unmodified-Since, | |||
If-Match, If-None-Match, or If-Range header field. A conditional GET | If-Match, If-None-Match, or If-Range header field. A conditional GET | |||
method requests that the entity be transferred only under the | method requests that the entity be transferred only under the | |||
circumstances described by the conditional header field(s). The | circumstances described by the conditional header field(s). The | |||
conditional GET method is intended to reduce unnecessary network | conditional GET method is intended to reduce unnecessary network | |||
usage by allowing cached entities to be refreshed without requiring | usage by allowing cached entities to be refreshed without requiring | |||
multiple requests or transferring data already held by the client. | multiple requests or transferring data already held by the 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 entity be transferred, as described in | requests that only part of the entity be transferred, as described in | |||
Section 6.4 of [Part5]. The partial GET method is intended to reduce | Section 5.4 of [Part5]. The partial GET method is intended to reduce | |||
unnecessary network usage by allowing partially-retrieved entities to | unnecessary network usage by allowing partially-retrieved entities to | |||
be completed without transferring data already held by the client. | be completed without transferring data already held by the client. | |||
The response to a GET request is cacheable if and only if it meets | The response to a GET request is cacheable if and only if it meets | |||
the requirements for HTTP caching described in [Part6]. | the requirements for HTTP caching described in [Part6]. | |||
See Section 12.2 for security considerations when used for forms. | See Section 11.2 for security considerations when used for forms. | |||
8.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 metainformation contained | return a message-body in the response. The metainformation contained | |||
in the HTTP headers in response to a HEAD request SHOULD be identical | in the HTTP headers in response to a HEAD request SHOULD be identical | |||
to the information sent in response to a GET request. This method | to the information sent in response to a GET request. This method | |||
can be used for obtaining metainformation about the entity implied by | can be used for obtaining metainformation about the entity implied by | |||
the request without transferring the entity-body itself. This method | the request without transferring the entity-body itself. This method | |||
is often used for testing hypertext links for validity, | is often used for testing hypertext links for validity, | |||
accessibility, and recent modification. | accessibility, and recent modification. | |||
The response to a HEAD request MAY be cacheable in the sense that the | The response to a HEAD request MAY be cacheable in the sense that the | |||
information contained in the response MAY be used to update a | information contained in the response MAY be used to update a | |||
previously cached entity from that resource. If the new field values | previously cached entity from that resource. If the new field values | |||
indicate that the cached entity differs from the current entity (as | indicate that the cached entity differs from the current entity (as | |||
would be indicated by a change in Content-Length, Content-MD5, ETag | would be indicated by a change in Content-Length, Content-MD5, ETag | |||
or Last-Modified), then the cache MUST treat the cache entry as | or Last-Modified), then the cache MUST treat the cache entry as | |||
stale. | stale. | |||
8.5. POST | 7.5. POST | |||
The POST method is used to request that the origin server accept the | The POST method is used to request that the origin server accept the | |||
entity enclosed in the request as data to be processed by the | entity enclosed in the request as data to be processed by the | |||
resource identified by the Request-URI in the Request-Line. POST is | resource identified by the request-target in the Request-Line. POST | |||
designed to allow a uniform method to cover the following functions: | is designed to allow a uniform method to cover the following | |||
functions: | ||||
o Annotation of existing resources; | o Annotation of existing resources; | |||
o Posting a message to a bulletin board, newsgroup, mailing list, or | o Posting a message to a bulletin board, newsgroup, mailing list, or | |||
similar group of articles; | similar group of articles; | |||
o Providing a block of data, such as the result of submitting a | o Providing a block of data, such as the result of submitting a | |||
form, to a data-handling process; | form, to a data-handling process; | |||
o Extending a database through an append operation. | o Extending a database through an append operation. | |||
The actual function performed by the POST method is determined by the | The actual function performed by the POST method is determined by the | |||
server and is usually dependent on the Request-URI. | server and is usually dependent on the request-target. | |||
The action performed by the POST method might not result in a | The action performed by the POST method might not result in a | |||
resource that can be identified by a URI. In this case, either 200 | resource that can be identified by a URI. In this case, either 200 | |||
(OK) or 204 (No Content) is the appropriate response status, | (OK) or 204 (No Content) is the appropriate response status, | |||
depending on whether or not the response includes an entity that | depending on whether or not the response includes an entity that | |||
describes the result. | describes the result. | |||
If a resource has been created on the origin server, the response | If a resource has been created on the origin server, the response | |||
SHOULD be 201 (Created) and contain an entity which describes the | SHOULD be 201 (Created) and contain an entity which describes the | |||
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 9.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 | 7.6. PUT | |||
The PUT method requests that the enclosed entity be stored at 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-target. If the request-target 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-target does not point to an existing resource, and that URI | |||
capable of being defined as a new resource by the requesting user | is 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-target, 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 | |||
the request. If the resource could not be created or modified with | the request. If the resource could not be created or modified with | |||
the Request-URI, an appropriate error response SHOULD be given that | the request-target, an appropriate error response SHOULD be given | |||
reflects the nature of the problem. The recipient of the entity MUST | that reflects the nature of the problem. The recipient of the entity | |||
NOT ignore any Content-* headers (headers starting with the prefix | MUST NOT ignore any Content-* headers (headers starting with the | |||
'Content-') that it does not understand or implement and MUST return | prefix 'Content-') that it does not understand or implement and MUST | |||
a 501 (Not Implemented) response in such cases. | return a 501 (Not Implemented) response in such cases. | |||
If the request passes through a cache and the Request-URI identifies | If the request passes through a cache and the request-target | |||
one or more currently cached entities, those entries SHOULD be | identifies one or more currently cached entities, those entries | |||
treated as stale. Responses to this method are not cacheable. | SHOULD be treated as stale. Responses to this method are not | |||
cacheable. | ||||
The fundamental difference between the POST and PUT requests is | The fundamental difference between the POST and PUT requests is | |||
reflected in the different meaning of the Request-URI. The URI in a | reflected in the different meaning of the request-target. The URI in | |||
POST request identifies the resource that will handle the enclosed | a POST request identifies the resource that will handle the enclosed | |||
entity. That resource might be a data-accepting process, a gateway | entity. That resource might be a data-accepting process, a gateway | |||
to some other protocol, or a separate entity that accepts | to some other protocol, or a separate entity that accepts | |||
annotations. In contrast, the URI in a PUT request identifies the | annotations. In contrast, the URI in a PUT request identifies the | |||
entity enclosed with the request -- the user agent knows what URI is | entity enclosed with the request -- the user agent knows what URI is | |||
intended and the server MUST NOT attempt to apply the request to some | intended and the server MUST NOT attempt to apply the request to some | |||
other resource. If the server desires that the request be applied to | other resource. If the server desires that the request be applied to | |||
a different URI, it MUST send a 301 (Moved Permanently) response; the | a different URI, it MUST send a 301 (Moved Permanently) response; the | |||
user agent MAY then make its own decision regarding whether or not to | user agent MAY then make its own decision regarding whether or not to | |||
redirect the request. | redirect the request. | |||
skipping to change at page 18, line 18 | skipping to change at page 18, line 22 | |||
version. In this case, a PUT request on a general URI might result | version. In this case, a PUT request on a general URI might result | |||
in several other URIs being defined by the origin server. | in several other URIs being defined by the origin server. | |||
HTTP/1.1 does not define how a PUT method affects the state of an | HTTP/1.1 does not define how a PUT method affects the state of an | |||
origin server. | origin server. | |||
Unless otherwise specified for a particular entity-header, the | Unless otherwise specified for a particular entity-header, the | |||
entity-headers in the PUT request SHOULD be applied to the resource | entity-headers in the PUT request SHOULD be applied to the resource | |||
created or modified by the PUT. | created or modified by the PUT. | |||
8.7. DELETE | 7.7. DELETE | |||
The DELETE method requests that the origin server delete the resource | The DELETE method requests that the origin server delete the resource | |||
identified by the Request-URI. This method MAY be overridden by | identified by the request-target. This method MAY be overridden by | |||
human intervention (or other means) on the origin server. The client | human intervention (or other means) on the origin server. The client | |||
cannot be guaranteed that the operation has been carried out, even if | cannot be guaranteed that the operation has been carried out, even if | |||
the status code returned from the origin server indicates that the | the status code returned from the origin server indicates that the | |||
action has been completed successfully. However, the server SHOULD | action has been completed successfully. However, the server SHOULD | |||
NOT indicate success unless, at the time the response is given, it | NOT indicate success unless, at the time the response is given, it | |||
intends to delete the resource or move it to an inaccessible | intends to delete the resource or move it to an inaccessible | |||
location. | 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 | |||
entity describing the status, 202 (Accepted) if the action has not | entity describing the status, 202 (Accepted) if the action has not | |||
yet been enacted, or 204 (No Content) if the action has been enacted | yet been enacted, or 204 (No Content) if the action has been enacted | |||
but the response does not include an entity. | but the response does not include an entity. | |||
If the request passes through a cache and the Request-URI identifies | If the request passes through a cache and the request-target | |||
one or more currently cached entities, those entries SHOULD be | identifies one or more currently cached entities, those entries | |||
treated as stale. Responses to this method are not cacheable. | SHOULD be treated as stale. Responses to this method are not | |||
cacheable. | ||||
8.8. TRACE | 7.8. TRACE | |||
The TRACE method is used to invoke a remote, application-layer loop- | The TRACE method is used to invoke a remote, application-layer loop- | |||
back of the request message. The final recipient of the request | back of the request message. The final recipient of the request | |||
SHOULD reflect the message received back to the client as the entity- | SHOULD reflect the message received back to the client as the entity- | |||
body of a 200 (OK) response. The final recipient is either the | body of a 200 (OK) response. The final recipient is either the | |||
origin server or the first proxy or gateway to receive a Max-Forwards | origin server or the first proxy or gateway to receive a Max-Forwards | |||
value of zero (0) in the request (see Section 10.5). A TRACE request | value of zero (0) in the request (see Section 9.5). A TRACE request | |||
MUST NOT include an entity. | MUST NOT include an entity. | |||
TRACE allows the client to see what is being received at the other | TRACE allows the client to see what is being received at the other | |||
end of the request chain and use that data for testing or diagnostic | end of the request chain and use that data for testing or diagnostic | |||
information. The value of the Via header field (Section 8.9 of | information. The value of the Via header field (Section 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" (see Section 9.3.1 of [Part1]). Responses to this method MUST | http" (see Section 9.3.1 of [Part1]). Responses to this method MUST | |||
NOT be cached. | NOT be cached. | |||
8.9. CONNECT | 7.9. CONNECT | |||
This specification reserves the method name CONNECT for use with a | This specification reserves the method name CONNECT for use with a | |||
proxy that can dynamically switch to being a tunnel (e.g. SSL | proxy that can dynamically switch to being a tunnel (e.g. SSL | |||
tunneling [RFC2817]). | tunneling [RFC2817]). | |||
9. Status Code Definitions | 8. 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 | |||
method(s) it can follow and any metainformation required in the | method(s) it can follow and any metainformation required in the | |||
response. | response. | |||
9.1. Informational 1xx | 8.1. Informational 1xx | |||
This class of status code indicates a provisional response, | This class of status code indicates a provisional response, | |||
consisting only of the Status-Line and optional headers, and is | consisting only of the Status-Line and optional headers, and is | |||
terminated by an empty line. There are no required headers for this | terminated by an empty line. There are no required headers for this | |||
class of status code. Since HTTP/1.0 did not define any 1xx status | class of status code. Since HTTP/1.0 did not define any 1xx status | |||
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client | codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client | |||
except under experimental conditions. | except under experimental conditions. | |||
A client MUST be prepared to accept one or more 1xx status responses | A client MUST be prepared to accept one or more 1xx status responses | |||
prior to a regular response, even if the client does not expect a 100 | prior to a regular response, even if the client does not expect a 100 | |||
(Continue) status message. Unexpected 1xx status responses MAY be | (Continue) status message. Unexpected 1xx status responses MAY be | |||
ignored by a user agent. | ignored by a user agent. | |||
Proxies MUST forward 1xx responses, unless the connection between the | Proxies MUST forward 1xx responses, unless the connection between the | |||
proxy and its client has been closed, or unless the proxy itself | proxy and its client has been closed, or unless the proxy itself | |||
requested the generation of the 1xx response. (For example, if a | requested the generation of the 1xx response. (For example, if a | |||
proxy adds a "Expect: 100-continue" field when it forwards a request, | proxy adds a "Expect: 100-continue" field when it forwards a request, | |||
then it need not forward the corresponding 100 (Continue) | then it need not forward the corresponding 100 (Continue) | |||
response(s).) | response(s).) | |||
9.1.1. 100 Continue | 8.1.1. 100 Continue | |||
The client SHOULD continue with its request. This interim response | The client SHOULD continue with its request. This interim response | |||
is used to inform the client that the initial part of the request has | is used to inform the client that the initial part of the request has | |||
been received and has not yet been rejected by the server. The | been received and has not yet been rejected by the server. The | |||
client SHOULD continue by sending the remainder of the request or, if | client SHOULD continue by sending the remainder of the request or, if | |||
the request has already been completed, ignore this response. The | the request has already been completed, ignore this response. The | |||
server MUST send a final response after the request has been | server MUST send a final response after the request has been | |||
completed. See Section 7.2.3 of [Part1] for detailed discussion of | completed. See Section 7.2.3 of [Part1] for detailed discussion of | |||
the use and handling of this status code. | the use and handling of this status code. | |||
9.1.2. 101 Switching Protocols | 8.1.2. 101 Switching Protocols | |||
The server understands and is willing to comply with the client's | The server understands and is willing to comply with the client's | |||
request, via the Upgrade message header field (Section 6.4 of | request, via the Upgrade message header field (Section 5.4 of | |||
[Part5]), for a change in the application protocol being used on this | [Part5]), for a change in the application protocol being used on this | |||
connection. The server will switch protocols to those defined by the | connection. The server will switch protocols to those defined by the | |||
response's Upgrade header field immediately after the empty line | response's Upgrade header field immediately after the empty line | |||
which terminates the 101 response. | which terminates the 101 response. | |||
The protocol SHOULD be switched only when it is advantageous to do | The protocol SHOULD be switched only when it is advantageous to do | |||
so. For example, switching to a newer version of HTTP is | so. For example, switching to a newer version of HTTP is | |||
advantageous over older versions, and switching to a real-time, | advantageous over older versions, and switching to a real-time, | |||
synchronous protocol might be advantageous when delivering resources | synchronous protocol might be advantageous when delivering resources | |||
that use such features. | that use such features. | |||
9.2. Successful 2xx | 8.2. Successful 2xx | |||
This class of status code indicates that the client's request was | This class of status code indicates that the client's request was | |||
successfully received, understood, and accepted. | successfully received, understood, and accepted. | |||
9.2.1. 200 OK | 8.2.1. 200 OK | |||
The request has succeeded. The information returned with the | The request has succeeded. The information returned with the | |||
response is dependent on the method used in the request, for example: | response is dependent on the method used in the request, for example: | |||
GET an entity corresponding to the requested resource is sent in the | GET an entity corresponding to the requested resource is sent in the | |||
response; | response; | |||
HEAD the entity-header fields corresponding to the requested | HEAD the entity-header fields corresponding to the requested | |||
resource are sent in the response without any message-body; | resource are sent in the response without any message-body; | |||
POST an entity describing or containing the result of the action; | POST an entity describing or containing the result of the action; | |||
TRACE an entity containing the request message as received by the | TRACE an entity containing the request message as received by the | |||
end server. | end server. | |||
9.2.2. 201 Created | 8.2.2. 201 Created | |||
The request has been fulfilled and resulted in a new resource being | The request has been fulfilled and resulted in a new resource being | |||
created. The newly created resource can be referenced by the URI(s) | created. The newly created resource can be referenced by the URI(s) | |||
returned in the entity of the response, with the most specific URI | returned in the entity of the response, with the most specific URI | |||
for the resource given by a Location header field. The response | for the resource given by a Location header field. The response | |||
SHOULD include an entity containing a list of resource | SHOULD include an entity 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 entity format is specified by | choose the one most appropriate. The entity 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 requested variant just | the current value of the entity tag for the requested variant just | |||
created, see Section 7.1 of [Part4]. | created, see Section 6.1 of [Part4]. | |||
9.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 | |||
allow a server to accept a request for some other process (perhaps a | allow a server to accept a request for some other process (perhaps a | |||
batch-oriented process that is only run once per day) without | batch-oriented process that is only run once per day) without | |||
requiring that the user agent's connection to the server persist | requiring that the user agent's connection to the server persist | |||
until the process is completed. The entity returned with this | until the process is completed. The entity returned with this | |||
response SHOULD include an indication of the request's current status | response SHOULD include an indication of the request's current status | |||
and either a pointer to a status monitor or some estimate of when the | and either a pointer to a status monitor or some estimate of when the | |||
user can expect the request to be fulfilled. | user can expect the request to be fulfilled. | |||
9.2.4. 203 Non-Authoritative Information | 8.2.4. 203 Non-Authoritative Information | |||
The returned metainformation in the entity-header is not the | The returned metainformation in the entity-header is not the | |||
definitive set as available from the origin server, but is gathered | definitive set as available from the origin server, but is gathered | |||
from a local or a third-party copy. The set presented MAY be a | from a local or a third-party copy. The set presented MAY be a | |||
subset or superset of the original version. For example, including | subset or superset of the original version. For example, including | |||
local annotation information about the resource might result in a | local annotation information about the resource might result in a | |||
superset of the metainformation known by the origin server. Use of | superset of the metainformation known by the origin server. Use of | |||
this response code is not required and is only appropriate when the | this response code is not required and is only appropriate when the | |||
response would otherwise be 200 (OK). | response would otherwise be 200 (OK). | |||
9.2.5. 204 No Content | 8.2.5. 204 No Content | |||
The server has fulfilled the request but does not need to return an | The server has fulfilled the request but does not need to return an | |||
entity-body, and might want to return updated metainformation. The | entity-body, and might want to return updated metainformation. The | |||
response MAY include new or updated metainformation in the form of | response MAY include new or updated metainformation in the form of | |||
entity-headers, which if present SHOULD be associated with the | entity-headers, which if present SHOULD be associated with the | |||
requested variant. | requested variant. | |||
If the client is a user agent, it SHOULD NOT change its document view | If the client is a user agent, it SHOULD NOT change its document view | |||
from that which caused the request to be sent. This response is | from that which caused the request to be sent. This response is | |||
primarily intended to allow input for actions to take place without | primarily intended to allow input for actions to take place without | |||
causing a change to the user agent's active document view, although | causing a change to the user agent's active document view, although | |||
any new or updated metainformation SHOULD be applied to the document | any new or updated metainformation SHOULD be applied to the document | |||
currently in the user agent's active view. | currently in the user agent's active view. | |||
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. | |||
9.2.6. 205 Reset Content | 8.2.6. 205 Reset Content | |||
The server has fulfilled the request and the user agent SHOULD reset | The server has fulfilled the request and the user agent SHOULD reset | |||
the document view which caused the request to be sent. This response | the document view which caused the request to be sent. This response | |||
is primarily intended to allow input for actions to take place via | is primarily intended to allow input for actions to take place via | |||
user input, followed by a clearing of the form in which the input is | user input, followed by a clearing of the form in which the input is | |||
given so that the user can easily initiate another input action. The | given so that the user can easily initiate another input action. The | |||
response MUST NOT include an entity. | response MUST NOT include an entity. | |||
9.2.7. 206 Partial Content | 8.2.7. 206 Partial Content | |||
The server has fulfilled the partial GET request for the resource and | The server has fulfilled the partial GET request for the resource and | |||
the enclosed entity is a partial representation as defined in | the enclosed entity is a partial representation as defined in | |||
[Part5]. | [Part5]. | |||
9.3. Redirection 3xx | 8.3. Redirection 3xx | |||
This class of status code indicates that further action needs to be | This class of status code indicates that further action needs to be | |||
taken by the user agent in order to fulfill the request. The action | taken by the user agent in order to fulfill the request. The action | |||
required MAY be carried out by the user agent without interaction | required MAY be carried out by the user agent without interaction | |||
with the user if and only if the method used in the second request is | with the user if and only if the method used in the second request is | |||
GET or HEAD. A client SHOULD detect infinite redirection loops, | GET or HEAD. A client SHOULD detect infinite redirection loops, | |||
since such loops generate network traffic for each redirection. | since such loops generate network traffic for each redirection. | |||
Note: previous versions of this specification recommended a | Note: previous versions of this specification recommended a | |||
maximum of five redirections. Content developers should be aware | maximum of five redirections. Content developers should be aware | |||
that there might be clients that implement such a fixed | that there might be clients that implement such a fixed | |||
limitation. | limitation. | |||
9.3.1. 300 Multiple Choices | 8.3.1. 300 Multiple Choices | |||
The requested resource corresponds to any one of a set of | The requested resource corresponds to any one of a set of | |||
representations, each with its own specific location, and agent- | representations, each with its own specific location, and agent- | |||
driven negotiation information (Section 5 of [Part3]) is being | driven negotiation information (Section 4 of [Part3]) is being | |||
provided so that the user (or user agent) can select a preferred | provided so that the user (or user agent) can select a preferred | |||
representation and redirect its request to that location. | representation and redirect its request to that location. | |||
Unless it was a HEAD request, the response SHOULD include an entity | Unless it was a HEAD request, the response SHOULD include an entity | |||
containing a list of resource characteristics and location(s) from | containing a list of resource characteristics and location(s) from | |||
which the user or user agent can choose the one most appropriate. | which the user or user agent can choose the one most appropriate. | |||
The entity format is specified by the media type given in the | The entity format is specified by the media type given in the | |||
Content-Type header field. Depending upon the format and the | Content-Type header field. Depending upon the format and the | |||
capabilities of the user agent, selection of the most appropriate | capabilities of the user agent, selection of the most appropriate | |||
choice MAY be performed automatically. However, this specification | choice MAY be performed automatically. However, this specification | |||
does not define any standard for such automatic selection. | does not define any standard for such automatic selection. | |||
If the server has a preferred choice of representation, it SHOULD | If the server has a preferred choice of representation, it SHOULD | |||
include the specific URI for that representation in the Location | include the specific URI for that representation in the Location | |||
field; user agents MAY use the Location field value for automatic | field; user agents MAY use the Location field value for automatic | |||
redirection. This response is cacheable unless indicated otherwise. | redirection. This response is cacheable unless indicated otherwise. | |||
9.3.2. 301 Moved Permanently | 8.3.2. 301 Moved Permanently | |||
The requested resource has been assigned a new permanent URI and any | The requested resource has been assigned a new permanent URI and any | |||
future references to this resource SHOULD use one of the returned | future references to this resource SHOULD use one of the returned | |||
URIs. Clients with link editing capabilities ought to automatically | URIs. Clients with link editing capabilities ought to automatically | |||
re-link references to the Request-URI to one or more of the new | re-link references to the request-target to one or more of the new | |||
references returned by the server, where possible. This response is | references returned by the server, where possible. This response is | |||
cacheable unless indicated otherwise. | cacheable unless indicated otherwise. | |||
The new permanent URI SHOULD be given by the Location field in the | The new permanent URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s). | the new URI(s). | |||
If the 301 status code is received in response to a request method | If the 301 status code is received in response to a request method | |||
that is known to be "safe", as defined in Section 8.1.1, then the | that is known to be "safe", as defined in Section 7.1.1, then the | |||
request MAY be automatically redirected by the user agent without | request MAY be automatically redirected by the user agent without | |||
confirmation. Otherwise, the user agent MUST NOT automatically | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | redirect the request unless it can be confirmed by the user, since | |||
this might change the conditions under which the request was issued. | this might change the conditions under which the request was issued. | |||
Note: When automatically redirecting a POST request after | Note: When automatically redirecting a POST request after | |||
receiving a 301 status code, some existing HTTP/1.0 user agents | receiving a 301 status code, some existing HTTP/1.0 user agents | |||
will erroneously change it into a GET request. | will erroneously change it into a GET request. | |||
9.3.3. 302 Found | 8.3.3. 302 Found | |||
The requested resource resides temporarily under a different URI. | The requested resource resides temporarily under a different URI. | |||
Since the redirection might be altered on occasion, the client SHOULD | Since the redirection might be altered on occasion, the client SHOULD | |||
continue to use the Request-URI for future requests. This response | continue to use the request-target for future requests. This | |||
is only cacheable if indicated by a Cache-Control or Expires header | response is only cacheable if indicated by a Cache-Control or Expires | |||
field. | header field. | |||
The temporary URI SHOULD be given by the Location field in the | The temporary URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s). | the new URI(s). | |||
If the 302 status code is received in response to a request method | If the 302 status code is received in response to a request method | |||
that is known to be "safe", as defined in Section 8.1.1, then the | that is known to be "safe", as defined in Section 7.1.1, then the | |||
request MAY be automatically redirected by the user agent without | request MAY be automatically redirected by the user agent without | |||
confirmation. Otherwise, the user agent MUST NOT automatically | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | redirect the request unless it can be confirmed by the user, since | |||
this might change the conditions under which the request was issued. | this might change the conditions under which the request was issued. | |||
Note: [RFC1945] and [RFC2068] specify that the client is not | Note: [RFC1945] and [RFC2068] specify that the client is not | |||
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 | 8.3.4. 303 See Other | |||
The server directs the user agent to a different resource, indicated | The server directs the user agent to a different resource, indicated | |||
by a URI in the Location header field, that provides an indirect | by a URI in the Location header field, that provides an indirect | |||
response to the original request. The user agent MAY perform a GET | response to the original request. The user agent MAY perform a GET | |||
request on the URI in the Location field in order to obtain a | request on the URI in the Location field in order to obtain a | |||
representation corresponding to the response, be redirected again, or | representation corresponding to the response, be redirected again, or | |||
end with an error status. The Location URI is not a substitute | end with an error status. The Location URI is not a substitute | |||
reference for the originally requested resource. | reference for the originally requested resource. | |||
The 303 status is generally applicable to any HTTP method. It is | The 303 status is generally applicable to any HTTP method. It is | |||
skipping to change at page 25, line 7 | skipping to change at page 25, line 17 | |||
represents the previously requested resource. Note that answers to | represents the previously requested resource. Note that answers to | |||
the questions of what can be represented, what representations are | the questions of what can be represented, what representations are | |||
adequate, and what might be a useful description are outside the | adequate, and what might be a useful description are outside the | |||
scope of HTTP and thus entirely determined by the resource owner(s). | scope of HTTP and thus entirely determined by the resource owner(s). | |||
A 303 response SHOULD NOT be cached unless it is indicated as | A 303 response SHOULD NOT be cached unless it is indicated as | |||
cacheable by Cache-Control or Expires header fields. Except for | cacheable by Cache-Control or Expires header fields. Except for | |||
responses to a HEAD request, the entity of a 303 response SHOULD | responses to a HEAD request, the entity of a 303 response SHOULD | |||
contain a short hypertext note with a hyperlink to the Location URI. | contain a short hypertext note with a hyperlink to the Location URI. | |||
9.3.5. 304 Not Modified | 8.3.5. 304 Not Modified | |||
The response to the request has not been modified since the | The response to the request has not been modified since the | |||
conditions indicated by the client's conditional GET request, as | conditions indicated by the client's conditional GET request, as | |||
defined in [Part4]. | defined in [Part4]. | |||
9.3.6. 305 Use Proxy | 8.3.6. 305 Use Proxy | |||
The 305 status was defined in a previous version of this | The 305 status was defined in a previous version of this | |||
specification (see Appendix A.2), and is now deprecated. | specification (see Appendix A.2), and is now deprecated. | |||
9.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. | |||
9.3.8. 307 Temporary Redirect | 8.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 | |||
continue to use the Request-URI for future requests. This response | continue to use the request-target for future requests. This | |||
is only cacheable if indicated by a Cache-Control or Expires header | response is only cacheable if indicated by a Cache-Control or Expires | |||
field. | header field. | |||
The temporary URI SHOULD be given by the Location field in the | The temporary URI SHOULD be given by the Location field in the | |||
response. Unless the request method was HEAD, the entity of the | response. Unless the request method was HEAD, the entity of the | |||
response SHOULD contain a short hypertext note with a hyperlink to | response SHOULD contain a short hypertext note with a hyperlink to | |||
the new URI(s) , since many pre-HTTP/1.1 user agents do not | the new URI(s) , since many pre-HTTP/1.1 user agents do not | |||
understand the 307 status. Therefore, the note SHOULD contain the | understand the 307 status. Therefore, the note SHOULD contain the | |||
information necessary for a user to repeat the original request on | information necessary for a user to repeat the original request on | |||
the new URI. | the new URI. | |||
If the 307 status code is received in response to a request method | If the 307 status code is received in response to a request method | |||
that is known to be "safe", as defined in Section 8.1.1, then the | that is known to be "safe", as defined in Section 7.1.1, then the | |||
request MAY be automatically redirected by the user agent without | request MAY be automatically redirected by the user agent without | |||
confirmation. Otherwise, the user agent MUST NOT automatically | confirmation. Otherwise, the user agent MUST NOT automatically | |||
redirect the request unless it can be confirmed by the user, since | redirect the request unless it can be confirmed by the user, since | |||
this might change the conditions under which the request was issued. | this might change the conditions under which the request was issued. | |||
9.4. Client Error 4xx | 8.4. Client Error 4xx | |||
The 4xx class of status code is intended for cases in which the | The 4xx class of status code is intended for cases in which the | |||
client seems to have erred. Except when responding to a HEAD | client seems to have erred. Except when responding to a HEAD | |||
request, the server SHOULD include an entity containing an | request, the server SHOULD include an entity containing an | |||
explanation of the error situation, and whether it is a temporary or | explanation of the error situation, and whether it is a temporary or | |||
permanent condition. These status codes are applicable to any | permanent condition. These status codes are applicable to any | |||
request method. User agents SHOULD display any included entity to | request method. User agents SHOULD display any included entity to | |||
the user. | the user. | |||
If the client is sending data, a server implementation using TCP | If the client is sending data, a server implementation using TCP | |||
SHOULD be careful to ensure that the client acknowledges receipt of | SHOULD be careful to ensure that the client acknowledges receipt of | |||
the packet(s) containing the response, before the server closes the | the packet(s) containing the response, before the server closes the | |||
input connection. If the client continues sending data to the server | input connection. If the client continues sending data to the server | |||
after the close, the server's TCP stack will send a reset packet to | after the close, the server's TCP stack will send a reset packet to | |||
the client, which may erase the client's unacknowledged input buffers | the client, which may erase the client's unacknowledged input buffers | |||
before they can be read and interpreted by the HTTP application. | before they can be read and interpreted by the HTTP application. | |||
9.4.1. 400 Bad Request | 8.4.1. 400 Bad Request | |||
The request could not be understood by the server due to malformed | The request could not be understood by the server due to malformed | |||
syntax. The client SHOULD NOT repeat the request without | syntax. The client SHOULD NOT repeat the request without | |||
modifications. | modifications. | |||
9.4.2. 401 Unauthorized | 8.4.2. 401 Unauthorized | |||
The request requires user authentication (see [Part7]). | The request requires user authentication (see [Part7]). | |||
9.4.3. 402 Payment Required | 8.4.3. 402 Payment Required | |||
This code is reserved for future use. | This code is reserved for future use. | |||
9.4.4. 403 Forbidden | 8.4.4. 403 Forbidden | |||
The server understood the request, but is refusing to fulfill it. | The server understood the request, but is refusing to fulfill it. | |||
Authorization will not help and the request SHOULD NOT be repeated. | Authorization will not help and the request SHOULD NOT be repeated. | |||
If the request method was not HEAD and the server wishes to make | If the request method was not HEAD and the server wishes to make | |||
public why the request has not been fulfilled, it SHOULD describe the | public why the request has not been fulfilled, it SHOULD describe the | |||
reason for the refusal in the entity. If the server does not wish to | reason for the refusal in the entity. If the server does not wish to | |||
make this information available to the client, the status code 404 | make this information available to the client, the status code 404 | |||
(Not Found) can be used instead. | (Not Found) can be used instead. | |||
9.4.5. 404 Not Found | 8.4.5. 404 Not Found | |||
The server has not found anything matching the Request-URI. No | The server has not found anything matching the request-target. No | |||
indication is given of whether the condition is temporary or | indication is given of whether the condition is temporary or | |||
permanent. The 410 (Gone) status code SHOULD be used if the server | permanent. The 410 (Gone) status code SHOULD be used if the server | |||
knows, through some internally configurable mechanism, that an old | knows, through some internally configurable mechanism, that an old | |||
resource is permanently unavailable and has no forwarding address. | resource is permanently unavailable and has no forwarding address. | |||
This status code is commonly used when the server does not wish to | This status code is commonly used when the server does not wish to | |||
reveal exactly why the request has been refused, or when no other | reveal exactly why the request has been refused, or when no other | |||
response is applicable. | response is applicable. | |||
9.4.6. 405 Method Not Allowed | 8.4.6. 405 Method Not Allowed | |||
The method specified in the Request-Line is not allowed for the | The method specified in the Request-Line is not allowed for the | |||
resource identified by the Request-URI. The response MUST include an | resource identified by the request-target. The response MUST include | |||
Allow header containing a list of valid methods for the requested | an Allow header containing a list of valid methods for the requested | |||
resource. | resource. | |||
9.4.7. 406 Not Acceptable | 8.4.7. 406 Not Acceptable | |||
The resource identified by the request is only capable of generating | The resource identified by the request is only capable of generating | |||
response entities which have content characteristics not acceptable | response entities which have content characteristics not acceptable | |||
according to the accept headers sent in the request. | according to the accept headers sent in the request. | |||
Unless it was a HEAD request, the response SHOULD include an entity | Unless it was a HEAD request, the response SHOULD include an entity | |||
containing a list of available entity characteristics and location(s) | containing a list of available entity characteristics and location(s) | |||
from which the user or user agent can choose the one most | from which the user or user agent can choose the one most | |||
appropriate. The entity format is specified by the media type given | appropriate. The entity format is specified by the media type given | |||
in the Content-Type header field. Depending upon the format and the | in the Content-Type header field. Depending upon the format and the | |||
skipping to change at page 27, line 37 | skipping to change at page 27, line 48 | |||
Note: HTTP/1.1 servers are allowed to return responses which are | Note: HTTP/1.1 servers are allowed to return responses which are | |||
not acceptable according to the accept headers sent in the | not acceptable according to the accept headers sent in the | |||
request. In some cases, this may even be preferable to sending a | request. In some cases, this may even be preferable to sending a | |||
406 response. User agents are encouraged to inspect the headers | 406 response. User agents are encouraged to inspect the headers | |||
of an incoming response to determine if it is acceptable. | of an incoming response to determine if it is acceptable. | |||
If the response could be unacceptable, a user agent SHOULD | If the response could be unacceptable, a user agent SHOULD | |||
temporarily stop receipt of more data and query the user for a | temporarily stop receipt of more data and query the user for a | |||
decision on further actions. | decision on further actions. | |||
9.4.8. 407 Proxy Authentication Required | 8.4.8. 407 Proxy Authentication Required | |||
This code is similar to 401 (Unauthorized), but indicates that the | This code is similar to 401 (Unauthorized), but indicates that the | |||
client must first authenticate itself with the proxy (see [Part7]). | client must first authenticate itself with the proxy (see [Part7]). | |||
9.4.9. 408 Request Timeout | 8.4.9. 408 Request Timeout | |||
The client did not produce a request within the time that the server | The client did not produce a request within the time that the server | |||
was prepared to wait. The client MAY repeat the request without | was prepared to wait. The client MAY repeat the request without | |||
modifications at any later time. | modifications at any later time. | |||
9.4.10. 409 Conflict | 8.4.10. 409 Conflict | |||
The request could not be completed due to a conflict with the current | The request could not be completed due to a conflict with the current | |||
state of the resource. This code is only allowed in situations where | state of the resource. This code is only allowed in situations where | |||
it is expected that the user might be able to resolve the conflict | it is expected that the user might be able to resolve the conflict | |||
and resubmit the request. The response body SHOULD include enough | and resubmit the request. The response body SHOULD include enough | |||
information for the user to recognize the source of the conflict. | information for the user to recognize the source of the conflict. | |||
Ideally, the response entity would include enough information for the | Ideally, the response entity would include enough information for the | |||
user or user agent to fix the problem; however, that might not be | user or user agent to fix the problem; however, that might not be | |||
possible and is not required. | possible and is not required. | |||
Conflicts are most likely to occur in response to a PUT request. For | Conflicts are most likely to occur in response to a PUT request. For | |||
example, if versioning were being used and the entity being PUT | example, if versioning were being used and the entity being PUT | |||
included changes to a resource which conflict with those made by an | included changes to a resource which conflict with those made by an | |||
earlier (third-party) request, the server might use the 409 response | earlier (third-party) request, the server might use the 409 response | |||
to indicate that it can't complete the request. In this case, the | to indicate that it can't complete the request. In this case, the | |||
response entity would likely contain a list of the differences | response entity would likely contain a list of the differences | |||
between the two versions in a format defined by the response Content- | between the two versions in a format defined by the response Content- | |||
Type. | Type. | |||
9.4.11. 410 Gone | 8.4.11. 410 Gone | |||
The requested resource is no longer available at the server and no | The requested resource is no longer available at the server and no | |||
forwarding address is known. This condition is expected to be | forwarding address is known. This condition is expected to be | |||
considered permanent. Clients with link editing capabilities SHOULD | considered permanent. Clients with link editing capabilities SHOULD | |||
delete references to the Request-URI after user approval. If the | delete references to the request-target after user approval. If the | |||
server does not know, or has no facility to determine, whether or not | server does not know, or has no facility to determine, whether or not | |||
the condition is permanent, the status code 404 (Not Found) SHOULD be | the condition is permanent, the status code 404 (Not Found) SHOULD be | |||
used instead. This response is cacheable unless indicated otherwise. | used instead. This response is cacheable unless indicated otherwise. | |||
The 410 response is primarily intended to assist the task of web | The 410 response is primarily intended to assist the task of web | |||
maintenance by notifying the recipient that the resource is | maintenance by notifying the recipient that the resource is | |||
intentionally unavailable and that the server owners desire that | intentionally unavailable and that the server owners desire that | |||
remote links to that resource be removed. Such an event is common | remote links to that resource be removed. Such an event is common | |||
for limited-time, promotional services and for resources belonging to | for limited-time, promotional services and for resources belonging to | |||
individuals no longer working at the server's site. It is not | individuals no longer working at the server's site. It is not | |||
necessary to mark all permanently unavailable resources as "gone" or | necessary to mark all permanently unavailable resources as "gone" or | |||
to keep the mark for any length of time -- that is left to the | to keep the mark for any length of time -- that is left to the | |||
discretion of the server owner. | discretion of the server owner. | |||
9.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. | |||
9.4.13. 412 Precondition Failed | 8.4.13. 412 Precondition Failed | |||
The precondition given in one or more of the request-header fields | The precondition given in one or more of the request-header fields | |||
evaluated to false when it was tested on the server, as defined in | evaluated to false when it was tested on the server, as defined in | |||
[Part4]. | [Part4]. | |||
9.4.14. 413 Request Entity Too Large | 8.4.14. 413 Request Entity Too Large | |||
The server is refusing to process a request because the request | The server is refusing to process a request because the request | |||
entity is larger than the server is willing or able to process. The | entity is larger than the server is willing or able to process. The | |||
server MAY close the connection to prevent the client from continuing | server MAY close the connection to prevent the client from continuing | |||
the request. | the request. | |||
If the condition is temporary, the server SHOULD include a Retry- | If the condition is temporary, the server SHOULD include a Retry- | |||
After header field to indicate that it is temporary and after what | After header field to indicate that it is temporary and after what | |||
time the client MAY try again. | time the client MAY try again. | |||
9.4.15. 414 Request-URI Too Long | 8.4.15. 414 URI Too Long | |||
The server is refusing to service the request because the Request-URI | The server is refusing to service the request because the request- | |||
is longer than the server is willing to interpret. This rare | target is longer than the server is willing to interpret. This rare | |||
condition is only likely to occur when a client has improperly | condition is only likely to occur when a client has improperly | |||
converted a POST request to a GET request with long query | converted a POST request to a GET request with long query | |||
information, when the client has descended into a URI "black hole" of | information, when the client has descended into a URI "black hole" of | |||
redirection (e.g., a redirected URI prefix that points to a suffix of | redirection (e.g., a redirected URI prefix that points to a suffix of | |||
itself), or when the server is under attack by a client attempting to | itself), or when the server is under attack by a client attempting to | |||
exploit security holes present in some servers using fixed-length | exploit security holes present in some servers using fixed-length | |||
buffers for reading or manipulating the Request-URI. | buffers for reading or manipulating the request-target. | |||
9.4.16. 415 Unsupported Media Type | 8.4.16. 415 Unsupported Media Type | |||
The server is refusing to service the request because the entity of | The server is refusing to service the request because the entity of | |||
the request is in a format not supported by the requested resource | the request is in a format not supported by the requested resource | |||
for the requested method. | for the requested method. | |||
9.4.17. 416 Requested Range Not Satisfiable | 8.4.17. 416 Requested Range Not Satisfiable | |||
The request included a Range request-header field (Section 6.4 of | The request included a Range request-header field (Section 5.4 of | |||
[Part5]) and none of the range-specifier values in this field overlap | [Part5]) and none of the range-specifier values in this field overlap | |||
the current extent of the selected resource. | the current extent of the selected resource. | |||
9.4.18. 417 Expectation Failed | 8.4.18. 417 Expectation Failed | |||
The expectation given in an Expect request-header field (see | The expectation given in an Expect request-header field (see | |||
Section 10.2) could not be met by this server, or, if the server is a | Section 9.2) could not be met by this server, or, if the server is a | |||
proxy, the server has unambiguous evidence that the request could not | proxy, the server has unambiguous evidence that the request could not | |||
be met by the next-hop server. | be met by the next-hop server. | |||
9.5. Server Error 5xx | 8.5. Server Error 5xx | |||
Response status codes beginning with the digit "5" indicate cases in | Response status codes beginning with the digit "5" indicate cases in | |||
which the server is aware that it has erred or is incapable of | which the server is aware that it has erred or is incapable of | |||
performing the request. Except when responding to a HEAD request, | performing the request. Except when responding to a HEAD request, | |||
the server SHOULD include an entity containing an explanation of the | the server SHOULD include an entity containing an explanation of the | |||
error situation, and whether it is a temporary or permanent | error situation, and whether it is a temporary or permanent | |||
condition. User agents SHOULD display any included entity to the | condition. User agents SHOULD display any included entity to the | |||
user. These response codes are applicable to any request method. | user. These response codes are applicable to any request method. | |||
9.5.1. 500 Internal Server Error | 8.5.1. 500 Internal Server Error | |||
The server encountered an unexpected condition which prevented it | The server encountered an unexpected condition which prevented it | |||
from fulfilling the request. | from fulfilling the request. | |||
9.5.2. 501 Not Implemented | 8.5.2. 501 Not Implemented | |||
The server does not support the functionality required to fulfill the | The server does not support the functionality required to fulfill the | |||
request. This is the appropriate response when the server does not | request. This is the appropriate response when the server does not | |||
recognize the request method and is not capable of supporting it for | recognize the request method and is not capable of supporting it for | |||
any resource. | any resource. | |||
9.5.3. 502 Bad Gateway | 8.5.3. 502 Bad Gateway | |||
The server, while acting as a gateway or proxy, received an invalid | The server, while acting as a gateway or proxy, received an invalid | |||
response from the upstream server it accessed in attempting to | response from the upstream server it accessed in attempting to | |||
fulfill the request. | fulfill the request. | |||
9.5.4. 503 Service Unavailable | 8.5.4. 503 Service Unavailable | |||
The server is currently unable to handle the request due to a | The server is currently unable to handle the request due to a | |||
temporary overloading or maintenance of the server. The implication | temporary overloading or maintenance of the server. The implication | |||
is that this is a temporary condition which will be alleviated after | is that this is a temporary condition which will be alleviated after | |||
some delay. If known, the length of the delay MAY be indicated in a | some delay. If known, the length of the delay MAY be indicated in a | |||
Retry-After header. If no Retry-After is given, the client SHOULD | Retry-After header. If no Retry-After is given, the client SHOULD | |||
handle the response as it would for a 500 response. | handle the response as it would for a 500 response. | |||
Note: The existence of the 503 status code does not imply that a | Note: The existence of the 503 status code does not imply that a | |||
server must use it when becoming overloaded. Some servers may | server must use it when becoming overloaded. Some servers may | |||
wish to simply refuse the connection. | wish to simply refuse the connection. | |||
9.5.5. 504 Gateway Timeout | 8.5.5. 504 Gateway Timeout | |||
The server, while acting as a gateway or proxy, did not receive a | The server, while acting as a gateway or proxy, did not receive a | |||
timely response from the upstream server specified by the URI (e.g. | timely response from the upstream server specified by the URI (e.g. | |||
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed | HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed | |||
to access in attempting to complete the request. | to access in attempting to complete the request. | |||
Note: Note to implementors: some deployed proxies are known to | Note: Note to implementors: some deployed proxies are known to | |||
return 400 or 500 when DNS lookups time out. | return 400 or 500 when DNS lookups time out. | |||
9.5.6. 505 HTTP Version Not Supported | 8.5.6. 505 HTTP Version Not Supported | |||
The server does not support, or refuses to support, the protocol | The server does not support, or refuses to support, the protocol | |||
version that was used in the request message. The server is | version that was used in the request message. The server is | |||
indicating that it is unable or unwilling to complete the request | indicating that it is unable or unwilling to complete the request | |||
using the same major version as the client, as described in Section | using the same major version as the client, as described in Section | |||
3.1 of [Part1], other than with this error message. The response | 3.1 of [Part1], other than with this error message. The response | |||
SHOULD contain an entity describing why that version is not supported | SHOULD contain an entity describing why that version is not supported | |||
and what other protocols are supported by that server. | and what other protocols are supported by that server. | |||
10. Header Field Definitions | 9. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to request and response semantics. | fields related to request and response semantics. | |||
For entity-header fields, both sender and recipient refer to either | For entity-header fields, both sender and recipient refer to either | |||
the client or the server, depending on who sends and who receives the | the client or the server, depending on who sends and who receives the | |||
entity. | entity. | |||
10.1. Allow | 9.1. Allow | |||
The response-header field "Allow" lists the set of methods advertised | The response-header field "Allow" lists the set of methods advertised | |||
as supported by the resource identified by the Request-URI. The | as supported by the resource identified by the request-target. The | |||
purpose of this field is strictly to inform the recipient of valid | purpose of this field is strictly to inform the recipient of valid | |||
methods associated with the resource. An Allow header field MUST be | methods associated with the resource. An Allow header field MUST be | |||
present in a 405 (Method Not Allowed) response. | present in a 405 (Method Not Allowed) response. | |||
Allow = "Allow" ":" OWS Allow-v | Allow = "Allow" ":" OWS Allow-v | |||
Allow-v = #Method | Allow-v = #Method | |||
Example of use: | Example of use: | |||
Allow: GET, HEAD, PUT | Allow: GET, HEAD, PUT | |||
The actual set of allowed methods is defined by the origin server at | The actual set of allowed methods is defined by the origin server at | |||
the time of each request. | the time of each request. | |||
A proxy MUST NOT modify the Allow header field even if it does not | A proxy MUST NOT modify the Allow header field even if it does not | |||
understand all the methods specified, since the user agent might have | understand all the methods specified, since the user agent might have | |||
other means of communicating with the origin server. | other means of communicating with the origin server. | |||
10.2. Expect | 9.2. Expect | |||
The request-header field "Expect" is used to indicate that particular | The request-header field "Expect" is used to indicate that particular | |||
server behaviors are required by the client. | server behaviors are required by the client. | |||
Expect = "Expect" ":" OWS Expect-v | Expect = "Expect" ":" OWS Expect-v | |||
Expect-v = 1#expectation | Expect-v = 1#expectation | |||
expectation = "100-continue" / expectation-extension | expectation = "100-continue" / expectation-extension | |||
expectation-extension = token [ "=" ( token / quoted-string ) | expectation-extension = token [ "=" ( token / quoted-string ) | |||
*expect-params ] | *expect-params ] | |||
skipping to change at page 32, line 41 | skipping to change at page 33, line 5 | |||
with an expectation that it cannot meet. However, the Expect | with an expectation that it cannot meet. However, the Expect | |||
request-header itself is end-to-end; it MUST be forwarded if the | request-header itself is end-to-end; it MUST be forwarded if the | |||
request is forwarded. | request is forwarded. | |||
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | Many older HTTP/1.0 and HTTP/1.1 applications do not understand the | |||
Expect header. | Expect header. | |||
See Section 7.2.3 of [Part1] for the use of the 100 (Continue) | See Section 7.2.3 of [Part1] for the use of the 100 (Continue) | |||
status. | status. | |||
10.3. From | 9.3. From | |||
The request-header field "From", if given, SHOULD contain an Internet | The request-header field "From", if given, SHOULD contain an Internet | |||
e-mail address for the human user who controls the requesting user | e-mail address for the human user who controls the requesting user | |||
agent. The address SHOULD be machine-usable, as defined by "mailbox" | agent. The address SHOULD be machine-usable, as defined by "mailbox" | |||
in Section 3.4 of [RFC5322]: | in Section 3.4 of [RFC5322]: | |||
From = "From" ":" OWS From-v | From = "From" ":" OWS From-v | |||
From-v = mailbox | From-v = mailbox | |||
mailbox = <mailbox, defined in [RFC5322], Section 3.4> | mailbox = <mailbox, defined in [RFC5322], Section 3.4> | |||
skipping to change at page 33, line 28 | skipping to change at page 33, line 41 | |||
Internet host which issued the request. For example, when a request | Internet host which issued the request. For example, when a request | |||
is passed through a proxy the original issuer's address SHOULD be | is passed through a proxy the original issuer's address SHOULD be | |||
used. | used. | |||
The client SHOULD NOT send the From header field without the user's | The client SHOULD NOT send the From header field without the user's | |||
approval, as it might conflict with the user's privacy interests or | approval, as it might conflict with the user's privacy interests or | |||
their site's security policy. It is strongly recommended that the | their site's security policy. It is strongly recommended that the | |||
user be able to disable, enable, and modify the value of this field | user be able to disable, enable, and modify the value of this field | |||
at any time prior to a request. | at any time prior to a request. | |||
10.4. Location | 9.4. Location | |||
The response-header field "Location" is used for the identification | The response-header field "Location" is used for the identification | |||
of a new resource or to redirect the recipient to a location other | of a new resource or to redirect the recipient to a location other | |||
than the Request-URI for completion of the request. For 201 | than the request-target for completion of the request. For 201 | |||
(Created) responses, the Location is that of the new resource which | (Created) responses, the Location is that of the new resource which | |||
was created by the request. For 3xx responses, the location SHOULD | was created by the request. For 3xx responses, the location SHOULD | |||
indicate the server's preferred URI for automatic redirection to the | indicate the server's preferred URI for automatic redirection to the | |||
resource. The field value consists of a single absolute URI. | resource. The field value consists of a single absolute URI. | |||
Location = "Location" ":" OWS Location-v | Location = "Location" ":" OWS Location-v | |||
Location-v = absolute-URI [ "#" fragment ] | Location-v = absolute-URI [ "#" 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 | |||
Note: The Content-Location header field (Section 6.7 of [Part3]) | Note: The Content-Location header field (Section 5.7 of [Part3]) | |||
differs from Location in that the Content-Location identifies the | differs from Location in that the Content-Location identifies the | |||
original location of the entity enclosed in the response. It is | original location of the entity enclosed in the response. It is | |||
therefore possible for a response to contain header fields for | therefore possible for a response to contain header fields for | |||
both Location and Content-Location. | both Location and Content-Location. | |||
There are circumstances in which a fragment identifier in a Location | There are circumstances in which a fragment identifier in a Location | |||
URL would not be appropriate: | URL would not be appropriate: | |||
o With a 201 Created response, because in this usage the Location | o With a 201 Created response, because in this usage the Location | |||
header specifies the URL for the entire created resource. | header specifies the URL for the entire created resource. | |||
o With a 300 Multiple Choices, since the choice decision is intended | o With a 300 Multiple Choices, since the choice decision is intended | |||
to be made on resource characteristics and not fragment | to be made on resource characteristics and not fragment | |||
characteristics. | characteristics. | |||
o With 305 Use Proxy. | o With 305 Use Proxy. | |||
10.5. Max-Forwards | 9.5. Max-Forwards | |||
The request-header "Max-Forwards" field provides a mechanism with the | The request-header "Max-Forwards" field provides a mechanism with the | |||
TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the | TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the | |||
number of proxies or gateways that can forward the request to the | number of proxies or gateways that can forward the request to the | |||
next inbound server. This can be useful when the client is | next inbound server. This can be useful when the client is | |||
attempting to trace a request chain which appears to be failing or | attempting to trace a request chain which appears to be failing or | |||
looping in mid-chain. | looping in mid-chain. | |||
Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v | Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v | |||
Max-Forwards-v = 1*DIGIT | Max-Forwards-v = 1*DIGIT | |||
The Max-Forwards value is a decimal integer indicating the remaining | The Max-Forwards value is a decimal integer indicating the remaining | |||
number of times this request message may be forwarded. | number of times this request message may be forwarded. | |||
skipping to change at page 34, line 42 | skipping to change at page 35, line 5 | |||
value prior to forwarding the request. If the received value is zero | value prior to forwarding the request. If the received value is zero | |||
(0), the recipient MUST NOT forward the request; instead, it MUST | (0), the recipient MUST NOT forward the request; instead, it MUST | |||
respond as the final recipient. If the received Max-Forwards value | respond as the final recipient. If the received Max-Forwards value | |||
is greater than zero, then the forwarded message MUST contain an | is greater than zero, then the forwarded message MUST contain an | |||
updated Max-Forwards field with a value decremented by one (1). | updated Max-Forwards field with a value decremented by one (1). | |||
The Max-Forwards header field MAY be ignored for all other methods | The Max-Forwards header field MAY be ignored for all other methods | |||
defined by this specification and for any extension methods for which | defined by this specification and for any extension methods for which | |||
it is not explicitly referred to as part of that method definition. | it is not explicitly referred to as part of that method definition. | |||
10.6. Referer | 9.6. Referer | |||
The request-header field "Referer" [sic] allows the client to | The request-header field "Referer" [sic] allows the client to | |||
specify, for the server's benefit, the address (URI) of the resource | specify, for the server's benefit, the address (URI) of the resource | |||
from which the Request-URI was obtained (the "referrer", although the | from which the request-target was obtained (the "referrer", although | |||
header field is misspelled.) The Referer request-header allows a | the header field is misspelled.) The Referer request-header allows a | |||
server to generate lists of back-links to resources for interest, | server to generate lists of back-links to resources for interest, | |||
logging, optimized caching, etc. It also allows obsolete or mistyped | logging, optimized caching, etc. It also allows obsolete or mistyped | |||
links to be traced for maintenance. The Referer field MUST NOT be | links to be traced for maintenance. The Referer field MUST NOT be | |||
sent if the Request-URI was obtained from a source that does not have | sent if the request-target was obtained from a source that does not | |||
its own URI, such as input from the user keyboard. | have its own URI, such as input from the user keyboard. | |||
Referer = "Referer" ":" OWS Referer-v | Referer = "Referer" ":" OWS Referer-v | |||
Referer-v = absolute-URI / relativeURI | 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 Request-URI. The URI MUST NOT include a fragment. | relative to the request-target. The URI MUST NOT include a fragment. | |||
See Section 12.2 for security considerations. | See Section 11.2 for security considerations. | |||
10.7. Retry-After | 9.7. Retry-After | |||
The response-header "Retry-After" field can be used with a 503 | The response-header "Retry-After" field can be used with a 503 | |||
(Service Unavailable) response to indicate how long the service is | (Service Unavailable) response to indicate how long the service is | |||
expected to be unavailable to the requesting client. This field MAY | expected to be unavailable to the requesting client. This field MAY | |||
also be used with any 3xx (Redirection) response to indicate the | also be used with any 3xx (Redirection) response to indicate the | |||
minimum time the user-agent is asked wait before issuing the | minimum time the user-agent is asked wait before issuing the | |||
redirected request. The value of this field can be either an HTTP- | redirected request. The value of this field can be either an HTTP- | |||
date or an integer number of seconds (in decimal) after the time of | date or an integer number of seconds (in decimal) after the time of | |||
the response. | the response. | |||
skipping to change at page 35, line 43 | skipping to change at page 36, line 5 | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
Two examples of its use are | Two examples of its use are | |||
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | Retry-After: Fri, 31 Dec 1999 23:59:59 GMT | |||
Retry-After: 120 | Retry-After: 120 | |||
In the latter example, the delay is 2 minutes. | In the latter example, the delay is 2 minutes. | |||
10.8. Server | 9.8. Server | |||
The response-header field "Server" contains information about the | The response-header field "Server" contains information about the | |||
software used by the origin server to handle the request. The field | software used by the origin server to handle the request. The field | |||
can contain multiple product tokens (Section 3.5 of [Part1]) and | can contain multiple product tokens (Section 3.4 of [Part1]) and | |||
comments identifying the server and any significant subproducts. The | comments identifying the server and any significant subproducts. The | |||
product tokens are listed in order of their significance for | product tokens are listed in order of their significance for | |||
identifying the application. | identifying the application. | |||
Server = "Server" ":" OWS Server-v | Server = "Server" ":" OWS Server-v | |||
Server-v = product | Server-v = product | |||
*( RWS ( product / comment ) ) | *( RWS ( product / comment ) ) | |||
Example: | Example: | |||
skipping to change at page 36, line 23 | skipping to change at page 36, line 32 | |||
If the response is being forwarded through a proxy, the proxy | If the response is being forwarded through a proxy, the proxy | |||
application MUST NOT modify the Server response-header. Instead, it | application MUST NOT modify the Server response-header. Instead, it | |||
MUST include a Via field (as described in Section 8.9 of [Part1]). | MUST include a Via field (as described in Section 8.9 of [Part1]). | |||
Note: Revealing the specific software version of the server might | Note: Revealing the specific software version of the server might | |||
allow the server machine to become more vulnerable to attacks | allow the server machine to become more vulnerable to attacks | |||
against software that is known to contain security holes. Server | against software that is known to contain security holes. Server | |||
implementors are encouraged to make this field a configurable | implementors are encouraged to make this field a configurable | |||
option. | option. | |||
10.9. User-Agent | 9.9. User-Agent | |||
The request-header field "User-Agent" contains information about the | The request-header field "User-Agent" contains information about the | |||
user agent originating the request. This is for statistical | user agent originating the request. This is for statistical | |||
purposes, the tracing of protocol violations, and automated | purposes, the tracing of protocol violations, and automated | |||
recognition of user agents for the sake of tailoring responses to | recognition of user agents for the sake of tailoring responses to | |||
avoid particular user agent limitations. User agents SHOULD include | avoid particular user agent limitations. User agents SHOULD include | |||
this field with requests. The field can contain multiple product | this field with requests. The field can contain multiple product | |||
tokens (Section 3.5 of [Part1]) and comments identifying the agent | tokens (Section 3.4 of [Part1]) and comments identifying the agent | |||
and any subproducts which form a significant part of the user agent. | and any subproducts which form a significant part of the user agent. | |||
By convention, the product tokens are listed in order of their | By convention, the product tokens are listed in order of their | |||
significance for identifying the application. | significance for identifying the application. | |||
User-Agent = "User-Agent" ":" OWS User-Agent-v | User-Agent = "User-Agent" ":" OWS User-Agent-v | |||
User-Agent-v = product | User-Agent-v = product | |||
*( RWS ( product / comment ) ) | *( RWS ( product / comment ) ) | |||
Example: | Example: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
11. IANA Considerations | 10. IANA Considerations | |||
11.1. Method Registry | 10.1. Method Registry | |||
The registration procedure for HTTP Methods is defined by Section 3.1 | The registration procedure for HTTP Methods is defined by Section 2.1 | |||
of this document. | of this document. | |||
The HTTP Method Registry located at | The HTTP Method Registry located at | |||
<http://www.iana.org/assignments/http-methods> should be populated | <http://www.iana.org/assignments/http-methods> should be populated | |||
with the registrations below: | with the registrations below: | |||
+---------+------+-------------+ | +---------+------+-------------+ | |||
| Method | Safe | Reference | | | Method | Safe | Reference | | |||
+---------+------+-------------+ | +---------+------+-------------+ | |||
| CONNECT | no | Section 8.9 | | | CONNECT | no | Section 7.9 | | |||
| DELETE | no | Section 8.7 | | | DELETE | no | Section 7.7 | | |||
| GET | yes | Section 8.3 | | | GET | yes | Section 7.3 | | |||
| HEAD | yes | Section 8.4 | | | HEAD | yes | Section 7.4 | | |||
| OPTIONS | yes | Section 8.2 | | | OPTIONS | yes | Section 7.2 | | |||
| POST | no | Section 8.5 | | | POST | no | Section 7.5 | | |||
| PUT | no | Section 8.6 | | | PUT | no | Section 7.6 | | |||
| TRACE | yes | Section 8.8 | | | TRACE | yes | Section 7.8 | | |||
+---------+------+-------------+ | +---------+------+-------------+ | |||
11.2. Status Code Registry | 10.2. Status Code Registry | |||
The registration procedure for HTTP Status Codes -- previously | The registration procedure for HTTP Status Codes -- previously | |||
defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1 | defined in Section 7.1 of [RFC2817] -- is now defined by Section 4.1 | |||
of this document. | of this document. | |||
The HTTP Status Code Registry located at | The HTTP Status Code Registry located at | |||
<http://www.iana.org/assignments/http-status-codes> should be updated | <http://www.iana.org/assignments/http-status-codes> should be updated | |||
with the registrations below: | with the registrations below: | |||
+-------+---------------------------------+----------------+ | +-------+---------------------------------+----------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+---------------------------------+----------------+ | +-------+---------------------------------+----------------+ | |||
| 100 | Continue | Section 9.1.1 | | | 100 | Continue | Section 8.1.1 | | |||
| 101 | Switching Protocols | Section 9.1.2 | | | 101 | Switching Protocols | Section 8.1.2 | | |||
| 200 | OK | Section 9.2.1 | | | 200 | OK | Section 8.2.1 | | |||
| 201 | Created | Section 9.2.2 | | | 201 | Created | Section 8.2.2 | | |||
| 202 | Accepted | Section 9.2.3 | | | 202 | Accepted | Section 8.2.3 | | |||
| 203 | Non-Authoritative Information | Section 9.2.4 | | | 203 | Non-Authoritative Information | Section 8.2.4 | | |||
| 204 | No Content | Section 9.2.5 | | | 204 | No Content | Section 8.2.5 | | |||
| 205 | Reset Content | Section 9.2.6 | | | 205 | Reset Content | Section 8.2.6 | | |||
| 206 | Partial Content | Section 9.2.7 | | | 206 | Partial Content | Section 8.2.7 | | |||
| 300 | Multiple Choices | Section 9.3.1 | | | 300 | Multiple Choices | Section 8.3.1 | | |||
| 301 | Moved Permanently | Section 9.3.2 | | | 301 | Moved Permanently | Section 8.3.2 | | |||
| 302 | Found | Section 9.3.3 | | | 302 | Found | Section 8.3.3 | | |||
| 303 | See Other | Section 9.3.4 | | | 303 | See Other | Section 8.3.4 | | |||
| 304 | Not Modified | Section 9.3.5 | | | 304 | Not Modified | Section 8.3.5 | | |||
| 305 | Use Proxy | Section 9.3.6 | | | 305 | Use Proxy | Section 8.3.6 | | |||
| 306 | (Unused) | Section 9.3.7 | | | 306 | (Unused) | Section 8.3.7 | | |||
| 307 | Temporary Redirect | Section 9.3.8 | | | 307 | Temporary Redirect | Section 8.3.8 | | |||
| 400 | Bad Request | Section 9.4.1 | | | 400 | Bad Request | Section 8.4.1 | | |||
| 401 | Unauthorized | Section 9.4.2 | | | 401 | Unauthorized | Section 8.4.2 | | |||
| 402 | Payment Required | Section 9.4.3 | | | 402 | Payment Required | Section 8.4.3 | | |||
| 403 | Forbidden | Section 9.4.4 | | | 403 | Forbidden | Section 8.4.4 | | |||
| 404 | Not Found | Section 9.4.5 | | | 404 | Not Found | Section 8.4.5 | | |||
| 405 | Method Not Allowed | Section 9.4.6 | | | 405 | Method Not Allowed | Section 8.4.6 | | |||
| 406 | Not Acceptable | Section 9.4.7 | | | 406 | Not Acceptable | Section 8.4.7 | | |||
| 407 | Proxy Authentication Required | Section 9.4.8 | | | 407 | Proxy Authentication Required | Section 8.4.8 | | |||
| 408 | Request Timeout | Section 9.4.9 | | | 408 | Request Timeout | Section 8.4.9 | | |||
| 409 | Conflict | Section 9.4.10 | | | 409 | Conflict | Section 8.4.10 | | |||
| 410 | Gone | Section 9.4.11 | | | 410 | Gone | Section 8.4.11 | | |||
| 411 | Length Required | Section 9.4.12 | | | 411 | Length Required | Section 8.4.12 | | |||
| 412 | Precondition Failed | Section 9.4.13 | | | 412 | Precondition Failed | Section 8.4.13 | | |||
| 413 | Request Entity Too Large | Section 9.4.14 | | | 413 | Request Entity Too Large | Section 8.4.14 | | |||
| 414 | Request-URI Too Long | Section 9.4.15 | | | 414 | URI Too Long | Section 8.4.15 | | |||
| 415 | Unsupported Media Type | Section 9.4.16 | | | 415 | Unsupported Media Type | Section 8.4.16 | | |||
| 416 | Requested Range Not Satisfiable | Section 9.4.17 | | | 416 | Requested Range Not Satisfiable | Section 8.4.17 | | |||
| 417 | Expectation Failed | Section 9.4.18 | | | 417 | Expectation Failed | Section 8.4.18 | | |||
| 500 | Internal Server Error | Section 9.5.1 | | | 500 | Internal Server Error | Section 8.5.1 | | |||
| 501 | Not Implemented | Section 9.5.2 | | | 501 | Not Implemented | Section 8.5.2 | | |||
| 502 | Bad Gateway | Section 9.5.3 | | | 502 | Bad Gateway | Section 8.5.3 | | |||
| 503 | Service Unavailable | Section 9.5.4 | | | 503 | Service Unavailable | Section 8.5.4 | | |||
| 504 | Gateway Timeout | Section 9.5.5 | | | 504 | Gateway Timeout | Section 8.5.5 | | |||
| 505 | HTTP Version Not Supported | Section 9.5.6 | | | 505 | HTTP Version Not Supported | Section 8.5.6 | | |||
+-------+---------------------------------+----------------+ | +-------+---------------------------------+----------------+ | |||
11.3. Message Header Registration | 10.3. Message Header Registration | |||
The Message Header Registry located at <http://www.iana.org/ | The Message Header Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> should be | assignments/message-headers/message-header-index.html> should be | |||
updated with the permanent registrations below (see [RFC3864]): | updated with the permanent registrations below (see [RFC3864]): | |||
+-------------------+----------+----------+--------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+--------------+ | +-------------------+----------+----------+-------------+ | |||
| Allow | http | standard | Section 10.1 | | | Allow | http | standard | Section 9.1 | | |||
| Expect | http | standard | Section 10.2 | | | Expect | http | standard | Section 9.2 | | |||
| From | http | standard | Section 10.3 | | | From | http | standard | Section 9.3 | | |||
| Location | http | standard | Section 10.4 | | | Location | http | standard | Section 9.4 | | |||
| Max-Forwards | http | standard | Section 10.5 | | | Max-Forwards | http | standard | Section 9.5 | | |||
| Referer | http | standard | Section 10.6 | | | Referer | http | standard | Section 9.6 | | |||
| Retry-After | http | standard | Section 10.7 | | | Retry-After | http | standard | Section 9.7 | | |||
| Server | http | standard | Section 10.8 | | | Server | http | standard | Section 9.8 | | |||
| User-Agent | http | standard | Section 10.9 | | | User-Agent | http | standard | Section 9.9 | | |||
+-------------------+----------+----------+--------------+ | +-------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
12. Security Considerations | 11. 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 | 11.1. Transfer of Sensitive Information | |||
Like any generic data transfer protocol, HTTP cannot regulate the | Like any generic data transfer protocol, HTTP cannot regulate the | |||
content of the data that is transferred, nor is there any a priori | content of the data that is transferred, nor is there any a priori | |||
method of determining the sensitivity of any particular piece of | method of determining the sensitivity of any particular piece of | |||
information within the context of any given request. Therefore, | information within the context of any given request. Therefore, | |||
applications SHOULD supply as much control over this information as | applications SHOULD supply as much control over this information as | |||
possible to the provider of that information. Four header fields are | possible to the provider of that information. Four header fields are | |||
worth special mention in this context: Server, Via, Referer and From. | worth special mention in this context: Server, Via, Referer and From. | |||
Revealing the specific software version of the server might allow the | Revealing the specific software version of the server might allow the | |||
skipping to change at page 40, line 27 | skipping to change at page 40, line 27 | |||
privacy interests or their site's security policy, and hence it | privacy interests or their site's security policy, and hence it | |||
SHOULD NOT be transmitted without the user being able to disable, | SHOULD NOT be transmitted without the user being able to disable, | |||
enable, and modify the contents of the field. The user MUST be able | enable, and modify the contents of the field. The user MUST be able | |||
to set the contents of this field within a user preference or | to set the contents of this field within a user preference or | |||
application defaults configuration. | application defaults configuration. | |||
We suggest, though do not require, that a convenient toggle interface | We suggest, though do not require, that a convenient toggle interface | |||
be provided for the user to enable or disable the sending of From and | be provided for the user to enable or disable the sending of From and | |||
Referer information. | Referer information. | |||
The User-Agent (Section 10.9) or Server (Section 10.8) header fields | The User-Agent (Section 9.9) or Server (Section 9.8) header fields | |||
can sometimes be used to determine that a specific client or server | can sometimes be used to determine that a specific client or server | |||
have a particular security hole which might be exploited. | have a particular security hole which might be exploited. | |||
Unfortunately, this same information is often used for other valuable | Unfortunately, this same information is often used for other valuable | |||
purposes for which HTTP currently has no better mechanism. | purposes for which HTTP currently has no better mechanism. | |||
12.2. Encoding Sensitive Information in URIs | 11.2. Encoding Sensitive Information in URIs | |||
Because the source of a link might be private information or might | Because the source of a link might be private information or might | |||
reveal an otherwise private information source, it is strongly | reveal an otherwise private information source, it is strongly | |||
recommended that the user be able to select whether or not the | recommended that the user be able to select whether or not the | |||
Referer field is sent. For example, a browser client could have a | Referer field is sent. For example, a browser client could have a | |||
toggle switch for browsing openly/anonymously, which would | toggle switch for browsing openly/anonymously, which would | |||
respectively enable/disable the sending of Referer and From | respectively enable/disable the sending of Referer and From | |||
information. | information. | |||
Clients SHOULD NOT include a Referer header field in a (non-secure) | Clients SHOULD NOT include a Referer header field in a (non-secure) | |||
HTTP request if the referring page was transferred with a secure | HTTP request if the referring page was transferred with a secure | |||
protocol. | protocol. | |||
Authors of services should not use GET-based forms for the submission | Authors of services should not use GET-based forms for the submission | |||
of sensitive data because that data will be encoded in the Request- | of sensitive data because that data will be encoded in the Request- | |||
URI. Many existing servers, proxies, and user agents log or display | target. Many existing servers, proxies, and user agents log or | |||
the Request-URI in places where it might be visible to third parties. | display the Request-target in places where it might be visible to | |||
Such services can use POST-based form submission instead. | third parties. Such services can use POST-based form submission | |||
instead. | ||||
12.3. Location Headers and Spoofing | 11.3. Location Headers and Spoofing | |||
If a single server supports multiple organizations that do not trust | If a single server supports multiple organizations that do not trust | |||
one another, then it MUST check the values of Location and Content- | one another, then it MUST check the values of Location and Content- | |||
Location headers in responses that are generated under control of | Location headers in responses that are generated under control of | |||
said organizations to make sure that they do not attempt to | said organizations to make sure that they do not attempt to | |||
invalidate resources over which they have no authority. | invalidate resources over which they have no authority. | |||
13. Acknowledgments | 12. Acknowledgments | |||
14. References | 13. References | |||
14.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-05 | and Message Parsing", draft-ietf-httpbis-p1-messaging-06 | |||
(work in progress), November 2008. | (work in progress), March 2009. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-05 | and Content Negotiation", draft-ietf-httpbis-p3-payload-06 | |||
(work in progress), November 2008. | (work in progress), March 2009. | |||
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | |||
Requests", draft-ietf-httpbis-p4-conditional-05 (work in | Requests", draft-ietf-httpbis-p4-conditional-06 (work in | |||
progress), November 2008. | progress), March 2009. | |||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | |||
Partial Responses", draft-ietf-httpbis-p5-range-05 (work | Partial Responses", draft-ietf-httpbis-p5-range-06 (work | |||
in progress), November 2008. | in progress), March 2009. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
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-05 (work in progress), | draft-ietf-httpbis-p6-cache-06 (work in progress), | |||
November 2008. | March 2009. | |||
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", | |||
draft-ietf-httpbis-p7-auth-05 (work in progress), | draft-ietf-httpbis-p7-auth-06 (work in progress), | |||
November 2008. | March 2009. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
14.2. Informative References | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | ||||
13.2. Informative References | ||||
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext | |||
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. | |||
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. | |||
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 | |||
skipping to change at page 42, line 43 | skipping to change at page 42, line 49 | |||
May 2008. | May 2008. | |||
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, | |||
October 2008. | October 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 8.5.5). | |||
201 (Created) had a race that required an Etag be sent when a | 201 (Created) had a race that required an Etag be sent when a | |||
resource is first created. (Section 9.2.2). | resource is first created. (Section 8.2.2). | |||
Rewrite of message transmission requirements to make it much harder | Rewrite of message transmission requirements to make it much harder | |||
for implementors to get it wrong, as the consequences of errors here | for implementors to get it wrong, as the consequences of errors here | |||
can have significant impact on the Internet, and to deal with the | can have significant impact on the Internet, and to deal with the | |||
following problems: | following problems: | |||
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where | 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where | |||
this was incorrectly placing a requirement on the behavior of an | this was incorrectly placing a requirement on the behavior of an | |||
implementation of a future version of HTTP/1.x | implementation of a future version of HTTP/1.x | |||
skipping to change at page 43, line 31 | skipping to change at page 43, line 36 | |||
before it sends a required 100 (Continue) response. | before it sends a required 100 (Continue) response. | |||
6. Allow, rather than require, a server to omit 100 (Continue) if it | 6. Allow, rather than require, a server to omit 100 (Continue) if it | |||
has already seen some of the request body. | has already seen some of the request body. | |||
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 8.4.4, | |||
9.4.5, and 9.4.11) | 8.4.5, and 8.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 Section | implemented in previous versions of this specification. See Section | |||
19.6.1 of [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 | This document takes over the Status Code Registry, previously defined | |||
in Section 7.1 of [RFC2817]. (Section 5.1) | in Section 7.1 of [RFC2817]. (Section 4.1) | |||
Clarify definition of POST. (Section 8.5) | Clarify definition of POST. (Section 7.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 8.3.2, 8.3.3 and 8.3.8) | |||
Deprecate 305 Use Proxy status code, because user agents did not | Deprecate 305 Use Proxy status code, because user agents did not | |||
implement it. It used to indicate that the requested resource must | implement it. It used to indicate that the requested resource must | |||
be accessed through the proxy given by the Location field. The | be accessed through the proxy given by the Location field. The | |||
Location field gave the URI of the proxy. The recipient was expected | Location field gave the URI of the proxy. The recipient was expected | |||
to repeat this single request via the proxy. (Section 9.3.6) | to repeat this single request via the proxy. (Section 8.3.6) | |||
Reclassify Allow header as response header, removing the option to | Reclassify Allow header as response header, removing the option to | |||
specify it in a PUT request. Relax the server requirement on the | specify it in a PUT request. Relax the server requirement on the | |||
contents of the Allow header and remove requirement on clients to | contents of the Allow header and remove requirement on clients to | |||
always trust the header value. (Section 10.1) | always trust the header value. (Section 9.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 9.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 9.8) | |||
Appendix B. Change Log (to be removed by RFC Editor before publication) | Appendix B. Collected ABNF | |||
B.1. Since RFC2616 | Accept = <Accept, defined in [Part3], Section 5.1> | |||
Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2> | ||||
Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3> | ||||
Accept-Language = <Accept-Language, defined in [Part3], Section 5.4> | ||||
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 5.1> | ||||
Age = <Age, defined in [Part6], Section 3.1> | ||||
Allow = "Allow:" OWS Allow-v | ||||
Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] | ||||
Authorization = <Authorization, defined in [Part7], Section 3.1> | ||||
ETag = <ETag, defined in [Part4], Section 6.1> | ||||
Expect = "Expect:" OWS Expect-v | ||||
Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) | ||||
From = "From:" OWS From-v | ||||
From-v = mailbox | ||||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1> | ||||
Host = <Host, defined in [Part1], Section 2.1> | ||||
If-Match = <If-Match, defined in [Part4], Section 6.2> | ||||
If-Modified-Since = | ||||
<If-Modified-Since, defined in [Part4], Section 6.3> | ||||
If-None-Match = <If-None-Match, defined in [Part4], Section 6.4> | ||||
If-Range = <If-Range, defined in [Part5], Section 5.3> | ||||
If-Unmodified-Since = | ||||
<If-Unmodified-Since, defined in [Part4], Section 6.5> | ||||
Location = "Location:" OWS Location-v | ||||
Location-v = absolute-URI [ "#" fragment ] | ||||
Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v | ||||
Max-Forwards-v = 1*DIGIT | ||||
Method = %x4F.50.54.49.4F.4E.53 / %x47.45.54 / %x48.45.41.44 / | ||||
%x50.4F.54 / %x50.55.54 / %x44.45.4C.45.54.45 / %x54.52.41.43.45 / | ||||
%x43.4E.4E.45.43.54 / extension-method | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | ||||
Proxy-Authenticate = | ||||
<Proxy-Authenticate, defined in [Part7], Section 3.2> | ||||
Proxy-Authorization = | ||||
<Proxy-Authorization, defined in [Part7], Section 3.3> | ||||
RWS = <RWS, defined in [Part1], Section 1.2.2> | ||||
Range = <Range, defined in [Part5], Section 5.4> | ||||
Reason-Phrase = *( WSP / VCHAR / obs-text ) | ||||
Referer = "Referer:" OWS Referer-v | ||||
Referer-v = absolute-URI / partial-URI | ||||
Retry-After = "Retry-After:" OWS Retry-After-v | ||||
Retry-After-v = HTTP-date / delta-seconds | ||||
Server = "Server:" OWS Server-v | ||||
Server-v = product *( RWS ( product / comment ) ) | ||||
Status-Code = "100" / "101" / "200" / "201" / "202" / "203" / "204" / | ||||
"205" / "206" / "300" / "301" / "302" / "303" / "304" / "305" / | ||||
"307" / "400" / "401" / "402" / "403" / "404" / "405" / "406" / | ||||
"407" / "408" / "409" / "410" / "411" / "412" / "413" / "414" / | ||||
"415" / "416" / "417" / "500" / "501" / "502" / "503" / "504" / | ||||
"505" / extension-code | ||||
TE = <TE, defined in [Part1], Section 8.8> | ||||
User-Agent = "User-Agent:" OWS User-Agent-v | ||||
User-Agent-v = product *( RWS ( product / comment ) ) | ||||
Vary = <Vary, defined in [Part6], Section 3.5> | ||||
WWW-Authenticate = | ||||
<WWW-Authenticate, defined in [Part7], Section 3.4> | ||||
absolute-URI = <absolute-URI, defined in [Part1], Section 2.1> | ||||
comment = <comment, defined in [Part1], Section 1.2.2> | ||||
delta-seconds = 1*DIGIT | ||||
expect-params = ";" token [ "=" ( token / quoted-string ) ] | ||||
expectation = "100-continue" / expectation-extension | ||||
expectation-extension = token [ "=" ( token / quoted-string ) | ||||
*expect-params ] | ||||
extension-code = 3DIGIT | ||||
extension-method = token | ||||
fragment = <fragment, defined in [Part1], Section 2.1> | ||||
mailbox = <mailbox, defined in [RFC5322], Section 3.4> | ||||
obs-text = <obs-text, defined in [Part1], Section 1.2.2> | ||||
partial-URI = <partial-URI, defined in [Part1], Section 2.1> | ||||
product = <product, defined in [Part1], Section 3.4> | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | ||||
request-header = Accept / Accept-Charset / Accept-Encoding / | ||||
Accept-Language / Authorization / Expect / From / Host / If-Match / | ||||
If-Modified-Since / If-None-Match / If-Range / If-Unmodified-Since / | ||||
Max-Forwards / Proxy-Authorization / Range / Referer / TE / | ||||
User-Agent | ||||
response-header = Accept-Ranges / Age / Allow / ETag / Location / | ||||
Proxy-Authenticate / Retry-After / Server / Vary / WWW-Authenticate | ||||
token = <token, defined in [Part1], Section 1.2.2> | ||||
ABNF diagnostics: | ||||
; Reason-Phrase defined but not used | ||||
; Status-Code defined but not used | ||||
; request-header defined but not used | ||||
; response-header defined but not used | ||||
Appendix C. Change Log (to be removed by RFC Editor before publication) | ||||
C.1. Since RFC2616 | ||||
Extracted relevant partitions from [RFC2616]. | Extracted relevant partitions from [RFC2616]. | |||
B.2. Since draft-ietf-httpbis-p2-semantics-00 | C.2. Since draft-ietf-httpbis-p2-semantics-00 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" | o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST" | |||
(<http://purl.org/NET/http-errata#via-must>) | (<http://purl.org/NET/http-errata#via-must>) | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments | o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments | |||
allowed in Location" | allowed in Location" | |||
(<http://purl.org/NET/http-errata#location-fragments>) | (<http://purl.org/NET/http-errata#location-fragments>) | |||
skipping to change at page 45, line 14 | skipping to change at page 47, line 45 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative | |||
references" | references" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant | o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant | |||
cross-references" | cross-references" | |||
Other changes: | Other changes: | |||
o Move definitions of 304 and 412 condition codes to [Part4] | o Move definitions of 304 and 412 condition codes to [Part4] | |||
B.3. Since draft-ietf-httpbis-p2-semantics-01 | C.3. Since draft-ietf-httpbis-p2-semantics-01 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side | o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side | |||
effects" | effects" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host | o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host | |||
header requirements" | header requirements" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Move "Product Tokens" section (back) into Part 1, as "token" is | o Move "Product Tokens" section (back) into Part 1, as "token" is | |||
used in the definition of the Upgrade header. | used in the definition of the Upgrade header. | |||
o Add explicit references to BNF syntax and rules imported from | o Add explicit references to BNF syntax and rules imported from | |||
skipping to change at page 45, line 36 | skipping to change at page 48, line 19 | |||
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 | C.4. Since draft-ietf-httpbis-p2-semantics-02 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring | o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring | |||
Allow in 405 responses" | Allow in 405 responses" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code | o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code | |||
Registry" | Registry" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection | o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection | |||
skipping to change at page 46, line 24 | skipping to change at page 49, line 8 | |||
o Reference RFC 3984, and update header registrations for headers | o Reference RFC 3984, and update header registrations for headers | |||
defined in this document. | defined in this document. | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Replace string literals when the string really is case-sensitive | o Replace string literals when the string really is case-sensitive | |||
(method). | (method). | |||
B.5. Since draft-ietf-httpbis-p2-semantics-03 | C.5. Since draft-ietf-httpbis-p2-semantics-03 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS | o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS | |||
request bodies" | request bodies" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description | o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description | |||
of CONNECT should refer to RFC2817" | of CONNECT should refer to RFC2817" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location | o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location | |||
Content-Location reference request/response mixup" | Content-Location reference request/response mixup" | |||
Ongoing work on Method Registry | Ongoing work on Method Registry | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>): | |||
o Added initial proposal for registration process, plus initial | o Added initial proposal for registration process, plus initial | |||
content (non-HTTP/1.1 methods to be added by a separate | content (non-HTTP/1.1 methods to be added by a separate | |||
specification). | specification). | |||
B.6. Since draft-ietf-httpbis-p2-semantics-04 | C.6. Since draft-ietf-httpbis-p2-semantics-04 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" | o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | |||
updated by RFC 5322" | updated by RFC 5322" | |||
Ongoing work on ABNF conversion | Ongoing work on ABNF conversion | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Use "/" instead of "|" for alternatives. | o Use "/" instead of "|" for alternatives. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | value format definitions. | |||
skipping to change at page 47, line 15 | skipping to change at page 49, line 48 | |||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | |||
o Use "/" instead of "|" for alternatives. | o Use "/" instead of "|" for alternatives. | |||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | |||
whitespace ("OWS") and required whitespace ("RWS"). | whitespace ("OWS") and required whitespace ("RWS"). | |||
o Rewrite ABNFs to spell out whitespace rules, factor out header | o Rewrite ABNFs to spell out whitespace rules, factor out header | |||
value format definitions. | value format definitions. | |||
C.7. Since draft-ietf-httpbis-p2-semantics-05 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase | ||||
BNF" | ||||
Final work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Add appendix containing collected and expanded ABNF, reorganize | ||||
ABNF introduction. | ||||
Index | Index | |||
1 | 1 | |||
100 Continue (status code) 19 | 100 Continue (status code) 20 | |||
101 Switching Protocols (status code) 20 | 101 Switching Protocols (status code) 20 | |||
2 | 2 | |||
200 OK (status code) 20 | 200 OK (status code) 20 | |||
201 Created (status code) 20 | 201 Created (status code) 21 | |||
202 Accepted (status code) 21 | 202 Accepted (status code) 21 | |||
203 Non-Authoritative Information (status code) 21 | 203 Non-Authoritative Information (status code) 21 | |||
204 No Content (status code) 21 | 204 No Content (status code) 22 | |||
205 Reset Content (status code) 22 | 205 Reset Content (status code) 22 | |||
206 Partial Content (status code) 22 | 206 Partial Content (status code) 22 | |||
3 | 3 | |||
300 Multiple Choices (status code) 22 | 300 Multiple Choices (status code) 23 | |||
301 Moved Permanently (status code) 23 | 301 Moved Permanently (status code) 23 | |||
302 Found (status code) 23 | 302 Found (status code) 24 | |||
303 See Other (status code) 24 | 303 See Other (status code) 24 | |||
304 Not Modified (status code) 25 | 304 Not Modified (status code) 25 | |||
305 Use Proxy (status code) 25 | 305 Use Proxy (status code) 25 | |||
306 (Unused) (status code) 25 | 306 (Unused) (status code) 25 | |||
307 Temporary Redirect (status code) 25 | 307 Temporary Redirect (status code) 25 | |||
4 | 4 | |||
400 Bad Request (status code) 26 | 400 Bad Request (status code) 26 | |||
401 Unauthorized (status code) 26 | 401 Unauthorized (status code) 26 | |||
402 Payment Required (status code) 26 | 402 Payment Required (status code) 26 | |||
403 Forbidden (status code) 26 | 403 Forbidden (status code) 26 | |||
404 Not Found (status code) 26 | 404 Not Found (status code) 27 | |||
405 Method Not Allowed (status code) 27 | 405 Method Not Allowed (status code) 27 | |||
406 Not Acceptable (status code) 27 | 406 Not Acceptable (status code) 27 | |||
407 Proxy Authentication Required (status code) 27 | 407 Proxy Authentication Required (status code) 27 | |||
408 Request Timeout (status code) 27 | 408 Request Timeout (status code) 28 | |||
409 Conflict (status code) 27 | 409 Conflict (status code) 28 | |||
410 Gone (status code) 28 | 410 Gone (status code) 28 | |||
411 Length Required (status code) 28 | 411 Length Required (status code) 29 | |||
412 Precondition Failed (status code) 28 | 412 Precondition Failed (status code) 29 | |||
413 Request Entity Too Large (status code) 29 | 413 Request Entity Too Large (status code) 29 | |||
414 Request-URI Too Long (status code) 29 | 414 URI Too Long (status code) 29 | |||
415 Unsupported Media Type (status code) 29 | 415 Unsupported Media Type (status code) 29 | |||
416 Requested Range Not Satisfiable (status code) 29 | 416 Requested Range Not Satisfiable (status code) 29 | |||
417 Expectation Failed (status code) 29 | 417 Expectation Failed (status code) 30 | |||
5 | 5 | |||
500 Internal Server Error (status code) 30 | 500 Internal Server Error (status code) 30 | |||
501 Not Implemented (status code) 30 | 501 Not Implemented (status code) 30 | |||
502 Bad Gateway (status code) 30 | 502 Bad Gateway (status code) 30 | |||
503 Service Unavailable (status code) 30 | 503 Service Unavailable (status code) 30 | |||
504 Gateway Timeout (status code) 30 | 504 Gateway Timeout (status code) 31 | |||
505 HTTP Version Not Supported (status code) 31 | 505 HTTP Version Not Supported (status code) 31 | |||
A | A | |||
Allow header 31 | Allow header 31 | |||
C | C | |||
CONNECT method 19 | CONNECT method 19 | |||
D | D | |||
DELETE method 18 | DELETE method 18 | |||
E | E | |||
Expect header 31 | Expect header 32 | |||
F | F | |||
From header 32 | From header 33 | |||
G | G | |||
GET method 15 | GET method 15 | |||
Grammar | Grammar | |||
Allow 31 | Allow 31 | |||
Allow-v 31 | Allow-v 31 | |||
delta-seconds 35 | delta-seconds 35 | |||
Expect 32 | Expect 32 | |||
expect-params 32 | expect-params 32 | |||
Expect-v 32 | Expect-v 32 | |||
expectation 32 | expectation 32 | |||
expectation-extension 32 | expectation-extension 32 | |||
extension-code 11 | extension-code 11 | |||
extension-method 8 | extension-method 8 | |||
From 32 | From 33 | |||
From-v 32 | From-v 33 | |||
Location 33 | Location 33 | |||
Location-v 33 | Location-v 33 | |||
Max-Forwards 34 | Max-Forwards 34 | |||
Max-Forwards-v 34 | Max-Forwards-v 34 | |||
Method 8 | Method 8 | |||
Reason-Phrase 11 | Reason-Phrase 11 | |||
Referer 35 | Referer 35 | |||
Referer-v 35 | Referer-v 35 | |||
request-header 9 | request-header 9 | |||
response-header 12 | response-header 12 | |||
skipping to change at page 49, line 25 | skipping to change at page 52, line 23 | |||
Server 36 | Server 36 | |||
Server-v 36 | Server-v 36 | |||
Status-Code 11 | Status-Code 11 | |||
User-Agent 36 | User-Agent 36 | |||
User-Agent-v 36 | User-Agent-v 36 | |||
H | H | |||
HEAD method 16 | HEAD method 16 | |||
Headers | Headers | |||
Allow 31 | Allow 31 | |||
Expect 31 | Expect 32 | |||
From 32 | From 33 | |||
Location 33 | Location 33 | |||
Max-Forwards 34 | Max-Forwards 34 | |||
Referer 34 | Referer 35 | |||
Retry-After 35 | Retry-After 35 | |||
Server 35 | Server 36 | |||
User-Agent 36 | User-Agent 36 | |||
I | I | |||
Idempotent Methods 14 | Idempotent Methods 14 | |||
L | L | |||
LINK method 43 | LINK method 43 | |||
Location header 33 | Location header 33 | |||
M | M | |||
skipping to change at page 50, line 17 | skipping to change at page 53, line 15 | |||
O | O | |||
OPTIONS method 14 | OPTIONS method 14 | |||
P | P | |||
PATCH method 43 | PATCH method 43 | |||
POST method 16 | POST method 16 | |||
PUT method 17 | PUT method 17 | |||
R | R | |||
Referer header 34 | Referer header 35 | |||
Retry-After header 35 | Retry-After header 35 | |||
S | S | |||
Safe Methods 13 | Safe Methods 13 | |||
Server header 35 | Server header 36 | |||
Status Codes | Status Codes | |||
100 Continue 19 | 100 Continue 20 | |||
101 Switching Protocols 20 | 101 Switching Protocols 20 | |||
200 OK 20 | 200 OK 20 | |||
201 Created 20 | 201 Created 21 | |||
202 Accepted 21 | 202 Accepted 21 | |||
203 Non-Authoritative Information 21 | 203 Non-Authoritative Information 21 | |||
204 No Content 21 | 204 No Content 22 | |||
205 Reset Content 22 | 205 Reset Content 22 | |||
206 Partial Content 22 | 206 Partial Content 22 | |||
300 Multiple Choices 22 | 300 Multiple Choices 23 | |||
301 Moved Permanently 23 | 301 Moved Permanently 23 | |||
302 Found 23 | 302 Found 24 | |||
303 See Other 24 | 303 See Other 24 | |||
304 Not Modified 25 | 304 Not Modified 25 | |||
305 Use Proxy 25 | 305 Use Proxy 25 | |||
306 (Unused) 25 | 306 (Unused) 25 | |||
307 Temporary Redirect 25 | 307 Temporary Redirect 25 | |||
400 Bad Request 26 | 400 Bad Request 26 | |||
401 Unauthorized 26 | 401 Unauthorized 26 | |||
402 Payment Required 26 | 402 Payment Required 26 | |||
403 Forbidden 26 | 403 Forbidden 26 | |||
404 Not Found 26 | 404 Not Found 27 | |||
405 Method Not Allowed 27 | 405 Method Not Allowed 27 | |||
406 Not Acceptable 27 | 406 Not Acceptable 27 | |||
407 Proxy Authentication Required 27 | 407 Proxy Authentication Required 27 | |||
408 Request Timeout 27 | 408 Request Timeout 28 | |||
409 Conflict 27 | 409 Conflict 28 | |||
410 Gone 28 | 410 Gone 28 | |||
411 Length Required 28 | 411 Length Required 29 | |||
412 Precondition Failed 28 | 412 Precondition Failed 29 | |||
413 Request Entity Too Large 29 | 413 Request Entity Too Large 29 | |||
414 Request-URI Too Long 29 | 414 URI Too Long 29 | |||
415 Unsupported Media Type 29 | 415 Unsupported Media Type 29 | |||
416 Requested Range Not Satisfiable 29 | 416 Requested Range Not Satisfiable 29 | |||
417 Expectation Failed 29 | 417 Expectation Failed 30 | |||
500 Internal Server Error 30 | 500 Internal Server Error 30 | |||
501 Not Implemented 30 | 501 Not Implemented 30 | |||
502 Bad Gateway 30 | 502 Bad Gateway 30 | |||
503 Service Unavailable 30 | 503 Service Unavailable 30 | |||
504 Gateway Timeout 30 | 504 Gateway Timeout 31 | |||
505 HTTP Version Not Supported 31 | 505 HTTP Version Not Supported 31 | |||
T | T | |||
TRACE method 18 | TRACE method 18 | |||
U | U | |||
UNLINK method 43 | UNLINK method 43 | |||
User-Agent header 36 | User-Agent header 36 | |||
Authors' Addresses | Authors' Addresses | |||
skipping to change at page 54, line 4 | skipping to change at line 2528 | |||
Julian F. Reschke (editor) | Julian F. Reschke (editor) | |||
greenbytes GmbH | greenbytes GmbH | |||
Hafenweg 16 | Hafenweg 16 | |||
Muenster, NW 48155 | Muenster, NW 48155 | |||
Germany | Germany | |||
Phone: +49 251 2807760 | Phone: +49 251 2807760 | |||
Fax: +49 251 2807761 | Fax: +49 251 2807761 | |||
Email: julian.reschke@greenbytes.de | Email: julian.reschke@greenbytes.de | |||
URI: http://greenbytes.de/tech/webdav/ | URI: http://greenbytes.de/tech/webdav/ | |||
Full Copyright Statement | ||||
Copyright (C) The IETF Trust (2008). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
End of changes. 237 change blocks. | ||||
517 lines changed or deleted | 689 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/ |