draft-ietf-httpbis-p2-semantics-23.txt | draft-ietf-httpbis-p2-semantics-24.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Reschke, Ed. | Obsoletes: 2616 (if approved) J. Reschke, Ed. | |||
Updates: 2817 (if approved) greenbytes | Updates: 2817 (if approved) greenbytes | |||
Intended status: Standards Track July 15, 2013 | Intended status: Standards Track September 25, 2013 | |||
Expires: January 16, 2014 | Expires: March 29, 2014 | |||
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content | |||
draft-ietf-httpbis-p2-semantics-23 | draft-ietf-httpbis-p2-semantics-24 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypertext information | protocol for distributed, collaborative, hypertext information | |||
systems. This document defines the semantics of HTTP/1.1 messages, | systems. This document defines the semantics of HTTP/1.1 messages, | |||
as expressed by request methods, request header fields, response | as expressed by request methods, request header fields, response | |||
status codes, and response header fields, along with the payload of | status codes, and response header fields, along with the payload of | |||
messages (metadata and body content) and mechanisms for content | messages (metadata and body content) and mechanisms for content | |||
negotiation. | negotiation. | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
Discussion of this draft takes place on the HTTPBIS working group | Discussion of this draft takes place on the HTTPBIS working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix E.3. | The changes in this draft are summarized in Appendix E.4. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 16, 2014. | This Internet-Draft will expire on March 29, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 41 | skipping to change at page 2, line 41 | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 | 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 | 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 | |||
3.1.1. Processing the Data . . . . . . . . . . . . . . . . . 8 | 3.1.1. Processing Representation Data . . . . . . . . . . . . 8 | |||
3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 | 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 | |||
3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 | 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 | |||
3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 | 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 | |||
3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 | 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 | |||
3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 | 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 | |||
3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 | 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 | |||
3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 18 | 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 | |||
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 19 | 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 | |||
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 20 | 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 | 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 | |||
4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 | 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 | |||
4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 | 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 | |||
4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 23 | 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 | |||
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 23 | 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 | |||
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 28 | 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 29 | 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 | 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 | 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 32 | 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 | |||
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 | 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 | 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 | |||
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 | 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 | 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 | |||
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 | 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 | |||
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 | 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 | 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 | |||
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 | 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 | |||
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 | 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 | |||
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 | 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 | |||
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 | 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44 | 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 45 | 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 | |||
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 | 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 | |||
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 | 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 | |||
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49 | 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 | |||
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 | 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 | |||
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 | 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 | |||
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 | 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 | |||
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 | 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 | |||
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 | 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 | |||
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 | 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 | |||
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 | 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 | |||
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 | 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 | |||
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 | 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 | |||
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53 | 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 | |||
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54 | 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 | |||
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55 | 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 | |||
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 | 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 | |||
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56 | 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 | |||
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 | 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 | |||
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56 | 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 | |||
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57 | 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 | |||
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57 | 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 | |||
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57 | 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 | |||
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57 | 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 | |||
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 | 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 | |||
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58 | 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 | |||
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58 | 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 | |||
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58 | 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 | |||
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59 | 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 | |||
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59 | 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 | |||
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59 | 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60 | 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 | |||
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60 | 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 | |||
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60 | 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 | |||
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60 | 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 | |||
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61 | 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 | |||
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61 | 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 | |||
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61 | 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 | |||
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61 | 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 | |||
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 61 | 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 | |||
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62 | 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 | |||
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62 | 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 | |||
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62 | 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 | |||
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62 | 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 | |||
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 62 | 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 | |||
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63 | 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63 | 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 | |||
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 66 | 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 | |||
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 | 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 | |||
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 68 | 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 | |||
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 69 | 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 | |||
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 70 | 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 | |||
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70 | 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 | |||
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 | 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 | |||
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71 | 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 | |||
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72 | 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 | |||
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72 | 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 | |||
8.1.2. Considerations for New Methods . . . . . . . . . . . . 72 | 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 | |||
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73 | 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 | |||
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73 | 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 | |||
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 | 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 | |||
8.2.2. Considerations for New Status Codes . . . . . . . . . 74 | 8.2.2. Considerations for New Status Codes . . . . . . . . . 76 | |||
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 | 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 | |||
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76 | 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 | |||
8.3.1. Considerations for New Header Fields . . . . . . . . . 77 | 8.3.1. Considerations for New Header Fields . . . . . . . . . 78 | |||
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 | 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 | |||
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79 | 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 | |||
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 79 | 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 | |||
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 | 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 | |||
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 80 | 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 | |||
9.2. Personal Information . . . . . . . . . . . . . . . . . . . 81 | 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 | |||
9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 81 | 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 | |||
9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 | 9.4. Product Information . . . . . . . . . . . . . . . . . . . 83 | |||
9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 82 | 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 | |||
9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 82 | 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 83 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 85 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 86 | |||
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 | Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 | |||
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 87 | A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 | |||
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 87 | A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 | |||
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 | A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 | |||
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 | A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 | |||
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 88 | A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 | |||
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 88 | A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 | |||
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 | Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 | |||
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 91 | Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 | |||
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 | Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 | |||
Appendix E. Change Log (to be removed by RFC Editor before | Appendix E. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 95 | publication) . . . . . . . . . . . . . . . . . . . . 96 | |||
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 | E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96 | |||
E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 95 | E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96 | |||
E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 96 | E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 97 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 | E.4. Since draft-ietf-httpbis-p2-semantics-23 . . . . . . . . . 97 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 | ||||
1. Introduction | 1. Introduction | |||
Each Hypertext Transfer Protocol (HTTP) message is either a request | Each Hypertext Transfer Protocol (HTTP) message is either a request | |||
or a response. A server listens on a connection for a request, | or a response. A server listens on a connection for a request, | |||
parses each message received, interprets the message semantics in | parses each message received, interprets the message semantics in | |||
relation to the identified request target, and responds to that | relation to the identified request target, and responds to that | |||
request with one or more response messages. A client constructs | request with one or more response messages. A client constructs | |||
request messages to communicate specific intentions, and examines | request messages to communicate specific intentions, and examines | |||
received responses to see if the intentions were carried out and | received responses to see if the intentions were carried out and | |||
skipping to change at page 6, line 48 | skipping to change at page 6, line 48 | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Conformance criteria and considerations regarding error handling are | Conformance criteria and considerations regarding error handling are | |||
defined in Section 2.5 of [Part1]. | defined in Section 2.5 of [Part1]. | |||
1.2. Syntax Notation | 1.2. Syntax Notation | |||
This specification uses the Augmented Backus-Naur Form (ABNF) | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
notation of [RFC5234] with the list rule extension defined in Section | notation of [RFC5234] with the list rule extension defined in Section | |||
1.2 of [Part1]. Appendix C describes rules imported from other | 7 of [Part1]. Appendix C describes rules imported from other | |||
documents. Appendix D shows the collected ABNF with the list rule | documents. Appendix D shows the collected ABNF with the list rule | |||
expanded. | expanded. | |||
This specification uses the terms "character", "character encoding | This specification uses the terms "character", "character encoding | |||
scheme", "charset", and "protocol element" as they are defined in | scheme", "charset", and "protocol element" as they are defined in | |||
[RFC6365]. | [RFC6365]. | |||
2. Resources | 2. Resources | |||
The target of each HTTP request is called a resource. HTTP does not | The target of an HTTP request is called a resource. HTTP does not | |||
limit the nature of a resource; it merely defines an interface that | limit the nature of a resource; it merely defines an interface that | |||
might be used to interact with resources. Each resource is | might be used to interact with resources. Each resource is | |||
identified by a Uniform Resource Identifier (URI), as described in | identified by a Uniform Resource Identifier (URI), as described in | |||
Section 2.7 of [Part1]. | Section 2.7 of [Part1]. | |||
When a client constructs an HTTP/1.1 request message, it sends the | When a client constructs an HTTP/1.1 request message, it sends the | |||
target URI in one of various forms, as defined in (Section 5.3 of | target URI in one of various forms, as defined in (Section 5.3 of | |||
[Part1]). When a request is received, the server reconstructs an | [Part1]). When a request is received, the server reconstructs an | |||
effective request URI for the target resource (Section 5.5 of | effective request URI for the target resource (Section 5.5 of | |||
[Part1]). | [Part1]). | |||
skipping to change at page 8, line 18 | skipping to change at page 8, line 18 | |||
3.1. Representation Metadata | 3.1. Representation Metadata | |||
Representation header fields provide metadata about the | Representation header fields provide metadata about the | |||
representation. When a message includes a payload body, the | representation. When a message includes a payload body, the | |||
representation header fields describe how to interpret the | representation header fields describe how to interpret the | |||
representation data enclosed in the payload body. In a response to a | representation data enclosed in the payload body. In a response to a | |||
HEAD request, the representation header fields describe the | HEAD request, the representation header fields describe the | |||
representation data that would have been enclosed in the payload body | representation data that would have been enclosed in the payload body | |||
if the same request had been a GET. | if the same request had been a GET. | |||
The following header fields are defined to convey representation | The following header fields convey representation metadata: | |||
metadata: | ||||
+-------------------+-----------------+ | +-------------------+-----------------+ | |||
| Header Field Name | Defined in... | | | Header Field Name | Defined in... | | |||
+-------------------+-----------------+ | +-------------------+-----------------+ | |||
| Content-Type | Section 3.1.1.5 | | | Content-Type | Section 3.1.1.5 | | |||
| Content-Encoding | Section 3.1.2.2 | | | Content-Encoding | Section 3.1.2.2 | | |||
| Content-Language | Section 3.1.3.2 | | | Content-Language | Section 3.1.3.2 | | |||
| Content-Location | Section 3.1.4.2 | | | Content-Location | Section 3.1.4.2 | | |||
+-------------------+-----------------+ | +-------------------+-----------------+ | |||
3.1.1. Processing the Data | 3.1.1. Processing Representation Data | |||
3.1.1.1. Media Type | 3.1.1.1. Media Type | |||
HTTP uses Internet Media Types [RFC2046] in the Content-Type | HTTP uses Internet Media Types [RFC2046] in the Content-Type | |||
(Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order | (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order | |||
to provide open and extensible data typing and type negotiation. | to provide open and extensible data typing and type negotiation. | |||
Media types define both a data format and various processing models: | Media types define both a data format and various processing models: | |||
how to process that data in accordance with each context in which it | how to process that data in accordance with each context in which it | |||
is received. | is received. | |||
skipping to change at page 10, line 9 | skipping to change at page 10, line 8 | |||
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the | Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the | |||
performance characteristics of email deployments (i.e., store and | performance characteristics of email deployments (i.e., store and | |||
forward messages to peers) are significantly different from those | forward messages to peers) are significantly different from those | |||
common to HTTP and the Web (server-based information services). | common to HTTP and the Web (server-based information services). | |||
Furthermore, MIME's constraints for the sake of compatibility with | Furthermore, MIME's constraints for the sake of compatibility with | |||
older mail transfer protocols do not apply to HTTP (see Appendix A). | older mail transfer protocols do not apply to HTTP (see Appendix A). | |||
MIME's canonical form requires that media subtypes of the "text" type | MIME's canonical form requires that media subtypes of the "text" type | |||
use CRLF as the text line break. HTTP allows the transfer of text | use CRLF as the text line break. HTTP allows the transfer of text | |||
media with plain CR or LF alone representing a line break, when such | media with plain CR or LF alone representing a line break, when such | |||
line breaks are consistent for an entire representation. HTTP | line breaks are consistent for an entire representation. An HTTP | |||
senders MAY generate, and recipients MUST be able to parse, line | sender MAY generate, and a recipient MUST be able to parse, line | |||
breaks in text media that consist of CRLF, bare CR, or bare LF. In | breaks in text media that consist of CRLF, bare CR, or bare LF. In | |||
addition, text media in HTTP is not limited to charsets that use | addition, text media in HTTP is not limited to charsets that use | |||
octets 13 and 10 for CR and LF, respectively. This flexibility | octets 13 and 10 for CR and LF, respectively. This flexibility | |||
regarding line breaks applies only to text within a representation | regarding line breaks applies only to text within a representation | |||
that has been assigned a "text" media type; it does not apply to | that has been assigned a "text" media type; it does not apply to | |||
"multipart" types or HTTP elements outside the payload body (e.g., | "multipart" types or HTTP elements outside the payload body (e.g., | |||
header fields). | header fields). | |||
If a representation is encoded with a content-coding, the underlying | If a representation is encoded with a content-coding, the underlying | |||
data ought to be in a form defined above prior to being encoded. | data ought to be in a form defined above prior to being encoded. | |||
skipping to change at page 11, line 5 | skipping to change at page 11, line 4 | |||
message payload or the selected representation, as determined by the | message payload or the selected representation, as determined by the | |||
message semantics. The indicated media type defines both the data | message semantics. The indicated media type defines both the data | |||
format and how that data is intended to be processed by a recipient, | format and how that data is intended to be processed by a recipient, | |||
within the scope of the received message semantics, after any content | within the scope of the received message semantics, after any content | |||
codings indicated by Content-Encoding are decoded. | codings indicated by Content-Encoding are decoded. | |||
Content-Type = media-type | Content-Type = media-type | |||
Media types are defined in Section 3.1.1.1. An example of the field | Media types are defined in Section 3.1.1.1. An example of the field | |||
is | is | |||
Content-Type: text/html; charset=ISO-8859-4 | Content-Type: text/html; charset=ISO-8859-4 | |||
A sender that generates a message containing a payload body SHOULD | A sender that generates a message containing a payload body SHOULD | |||
generate a Content-Type header field in that message unless the | generate a Content-Type header field in that message unless the | |||
intended media type of the enclosed representation is unknown to the | intended media type of the enclosed representation is unknown to the | |||
sender. If a Content-Type header field is not present, recipients | sender. If a Content-Type header field is not present, the recipient | |||
MAY either assume a media type of "application/octet-stream" | MAY either assume a media type of "application/octet-stream" | |||
([RFC2046], Section 4.5.1) or examine the data to determine its type. | ([RFC2046], Section 4.5.1) or examine the data to determine its type. | |||
In practice, resource owners do not always properly configure their | In practice, resource owners do not always properly configure their | |||
origin server to provide the correct Content-Type for a given | origin server to provide the correct Content-Type for a given | |||
representation, with the result that some clients will examine a | representation, with the result that some clients will examine a | |||
payload's content and override the specified type. Clients that do | payload's content and override the specified type. Clients that do | |||
so risk drawing incorrect conclusions, which might expose additional | so risk drawing incorrect conclusions, which might expose additional | |||
security risks (e.g., "privilege escalation"). Furthermore, it is | security risks (e.g., "privilege escalation"). Furthermore, it is | |||
impossible to determine the sender's intent by examining the data | impossible to determine the sender's intent by examining the data | |||
skipping to change at page 11, line 36 | skipping to change at page 11, line 34 | |||
3.1.2. Encoding for Compression or Integrity | 3.1.2. Encoding for Compression or Integrity | |||
3.1.2.1. Content Codings | 3.1.2.1. Content Codings | |||
Content coding values indicate an encoding transformation that has | Content coding values indicate an encoding transformation that has | |||
been or can be applied to a representation. Content codings are | been or can be applied to a representation. Content codings are | |||
primarily used to allow a representation to be compressed or | primarily used to allow a representation to be compressed or | |||
otherwise usefully transformed without losing the identity of its | otherwise usefully transformed without losing the identity of its | |||
underlying media type and without loss of information. Frequently, | underlying media type and without loss of information. Frequently, | |||
the representation is stored in coded form, transmitted directly, and | the representation is stored in coded form, transmitted directly, and | |||
only decoded by the recipient. | only decoded by the final recipient. | |||
content-coding = token | content-coding = token | |||
All content-coding values are case-insensitive and ought to be | All content-coding values are case-insensitive and ought to be | |||
registered within the HTTP Content Coding registry, as defined in | registered within the HTTP Content Coding registry, as defined in | |||
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) | Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) | |||
and Content-Encoding (Section 3.1.2.2) header fields. | and Content-Encoding (Section 3.1.2.2) header fields. | |||
The following content-coding values are defined by this | The following content-coding values are defined by this | |||
specification: | specification: | |||
skipping to change at page 12, line 23 | skipping to change at page 12, line 21 | |||
header field. Content-Encoding is primarily used to allow a | header field. Content-Encoding is primarily used to allow a | |||
representation's data to be compressed without losing the identity of | representation's data to be compressed without losing the identity of | |||
its underlying media type. | its underlying media type. | |||
Content-Encoding = 1#content-coding | Content-Encoding = 1#content-coding | |||
An example of its use is | An example of its use is | |||
Content-Encoding: gzip | Content-Encoding: gzip | |||
If multiple encodings have been applied to a representation, the | If one or more encodings have been applied to a representation, the | |||
content codings MUST be listed in the order in which they were | sender that applied the encodings MUST generate a Content-Encoding | |||
applied. Additional information about the encoding parameters MAY be | header field that lists the content codings in the order in which | |||
provided by other header fields not defined by this specification. | they were applied. Additional information about the encoding | |||
parameters MAY be provided by other header fields not defined by this | ||||
specification. | ||||
Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings | Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings | |||
listed in Content-Encoding are a characteristic of the | listed in Content-Encoding are a characteristic of the | |||
representation; the representation is defined in terms of the coded | representation; the representation is defined in terms of the coded | |||
form, and all other metadata about the representation is about the | form, and all other metadata about the representation is about the | |||
coded form unless otherwise noted in the metadata definition. | coded form unless otherwise noted in the metadata definition. | |||
Typically, the representation is only decoded just prior to rendering | Typically, the representation is only decoded just prior to rendering | |||
or analogous usage. | or analogous usage. | |||
If the media type includes an inherent encoding, such as a data | If the media type includes an inherent encoding, such as a data | |||
skipping to change at page 13, line 12 | skipping to change at page 13, line 12 | |||
Media Type) if a representation in the request message has a content | Media Type) if a representation in the request message has a content | |||
coding that is not acceptable. | coding that is not acceptable. | |||
3.1.3. Audience Language | 3.1.3. Audience Language | |||
3.1.3.1. Language Tags | 3.1.3.1. Language Tags | |||
A language tag, as defined in [RFC5646], identifies a natural | A language tag, as defined in [RFC5646], identifies a natural | |||
language spoken, written, or otherwise conveyed by human beings for | language spoken, written, or otherwise conveyed by human beings for | |||
communication of information to other human beings. Computer | communication of information to other human beings. Computer | |||
languages are explicitly excluded. HTTP uses language tags within | languages are explicitly excluded. | |||
the Accept-Language and Content-Language header fields. | ||||
Accept-Language uses the looser language-range production defined in | HTTP uses language tags within the Accept-Language and Content- | |||
Section 5.3.5, whereas Content-Language uses the stricter language- | Language header fields. Accept-Language uses the broader language- | |||
tag production defined below. | range production defined in Section 5.3.5, whereas Content-Language | |||
uses the language-tag production defined below. | ||||
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> | |||
A language tag is composed of one or more parts: a primary language | A language tag is a sequence of one or more case-insensitive subtags, | |||
subtag followed by a possibly empty series of subtags. White space | each separated by a hyphen character ("-", %x2D). In most cases, a | |||
is not allowed within the tag and all tags are case-insensitive. | language tag consists of a primary language subtag that identifies a | |||
Example tags include: | broad family of related languages (e.g., "en" = English) which is | |||
optionally followed by a series of subtags that refine or narrow that | ||||
language's range (e.g., "en-CA" = the variety of English as | ||||
communicated in Canada). Whitespace is not allowed within a language | ||||
tag. Example tags include: | ||||
en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN | fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN | |||
See [RFC5646] for further information. | See [RFC5646] for further information. | |||
3.1.3.2. Content-Language | 3.1.3.2. Content-Language | |||
The "Content-Language" header field describes the natural language(s) | The "Content-Language" header field describes the natural language(s) | |||
of the intended audience for the representation. Note that this | of the intended audience for the representation. Note that this | |||
might not be equivalent to all the languages used within the | might not be equivalent to all the languages used within the | |||
representation. | representation. | |||
skipping to change at page 14, line 35 | skipping to change at page 14, line 39 | |||
payload, it is often desirable for the sender to supply, or the | payload, it is often desirable for the sender to supply, or the | |||
recipient to determine, an identifier for a resource corresponding to | recipient to determine, an identifier for a resource corresponding to | |||
that representation. | that representation. | |||
For a request message: | For a request message: | |||
o If the request has a Content-Location header field, then the | o If the request has a Content-Location header field, then the | |||
sender asserts that the payload is a representation of the | sender asserts that the payload is a representation of the | |||
resource identified by the Content-Location field-value. However, | resource identified by the Content-Location field-value. However, | |||
such an assertion cannot be trusted unless it can be verified by | such an assertion cannot be trusted unless it can be verified by | |||
other means (not defined by HTTP). The information might still be | other means (not defined by this specification). The information | |||
useful for revision history links. | might still be useful for revision history links. | |||
o Otherwise, the payload is unidentified. | o Otherwise, the payload is unidentified. | |||
For a response message, the following rules are applied in order | For a response message, the following rules are applied in order | |||
until a match is found: | until a match is found: | |||
1. If the request is GET or HEAD and the response status code is 200 | 1. If the request is GET or HEAD and the response status code is 200 | |||
(OK), 204 (No Content), 206 (Partial Content), or 304 (Not | (OK), 204 (No Content), 206 (Partial Content), or 304 (Not | |||
Modified), the payload is a representation of the resource | Modified), the payload is a representation of the resource | |||
identified by the effective request URI (Section 5.5 of [Part1]). | identified by the effective request URI (Section 5.5 of [Part1]). | |||
skipping to change at page 15, line 15 | skipping to change at page 15, line 20 | |||
3. If the response has a Content-Location header field and its | 3. If the response has a Content-Location header field and its | |||
field-value is a reference to the same URI as the effective | field-value is a reference to the same URI as the effective | |||
request URI, the payload is a representation of the resource | request URI, the payload is a representation of the resource | |||
identified by the effective request URI. | identified by the effective request URI. | |||
4. If the response has a Content-Location header field and its | 4. If the response has a Content-Location header field and its | |||
field-value is a reference to a URI different from the effective | field-value is a reference to a URI different from the effective | |||
request URI, then the sender asserts that the payload is a | request URI, then the sender asserts that the payload is a | |||
representation of the resource identified by the Content-Location | representation of the resource identified by the Content-Location | |||
field-value. However, such an assertion cannot be trusted unless | field-value. However, such an assertion cannot be trusted unless | |||
it can be verified by other means (not defined by HTTP). | it can be verified by other means (not defined by this | |||
specification). | ||||
5. Otherwise, the payload is unidentified. | 5. Otherwise, the payload is unidentified. | |||
3.1.4.2. Content-Location | 3.1.4.2. Content-Location | |||
The "Content-Location" header field references a URI that can be used | The "Content-Location" header field references a URI that can be used | |||
as an identifier for a specific resource corresponding to the | as an identifier for a specific resource corresponding to the | |||
representation in this message's payload. In other words, if one | representation in this message's payload. In other words, if one | |||
were to perform a GET request on this URI at the time of this | were to perform a GET request on this URI at the time of this | |||
message's generation, then a 200 (OK) response would contain the same | message's generation, then a 200 (OK) response would contain the same | |||
skipping to change at page 18, line 39 | skipping to change at page 18, line 45 | |||
patterns of content negotiation include "conditional content", where | patterns of content negotiation include "conditional content", where | |||
the representation consists of multiple parts that are selectively | the representation consists of multiple parts that are selectively | |||
rendered based on user agent parameters, "active content", where the | rendered based on user agent parameters, "active content", where the | |||
representation contains a script that makes additional (more | representation contains a script that makes additional (more | |||
specific) requests based on the user agent characteristics, and | specific) requests based on the user agent characteristics, and | |||
"Transparent Content Negotiation" ([RFC2295]), where content | "Transparent Content Negotiation" ([RFC2295]), where content | |||
selection is performed by an intermediary. These patterns are not | selection is performed by an intermediary. These patterns are not | |||
mutually exclusive, and each has trade-offs in applicability and | mutually exclusive, and each has trade-offs in applicability and | |||
practicality. | practicality. | |||
Note that, in all cases, the supplier of representations to the | Note that, in all cases, HTTP is not aware of the resource semantics. | |||
origin server determines which representations might be considered to | The consistency with which an origin server responds to requests, | |||
be the "same information". | over time and over the varying dimensions of content negotiation, and | |||
thus the "sameness" of a resource's observed representations over | ||||
time, is determined entirely by whatever entity or algorithm selects | ||||
or generates those responses. HTTP pays no attention to the man | ||||
behind the curtain. | ||||
3.4.1. Proactive Negotiation | 3.4.1. Proactive Negotiation | |||
When content negotiation preferences are sent by the user agent in a | When content negotiation preferences are sent by the user agent in a | |||
request in order to encourage an algorithm located at the server to | request to encourage an algorithm located at the server to select the | |||
select the preferred representation, it is called proactive | preferred representation, it is called proactive negotiation (a.k.a., | |||
negotiation (a.k.a., server-driven negotiation). Selection is based | server-driven negotiation). Selection is based on the available | |||
on the available representations for a response (the dimensions over | representations for a response (the dimensions over which it might | |||
which it might vary, such as language, content-coding, etc.) compared | vary, such as language, content-coding, etc.) compared to various | |||
to various information supplied in the request, including both the | information supplied in the request, including both the explicit | |||
explicit negotiation fields of Section 5.3 and implicit | negotiation fields of Section 5.3 and implicit characteristics, such | |||
characteristics, such as the client's network address or parts of the | as the client's network address or parts of the User-Agent field. | |||
User-Agent field. | ||||
Proactive negotiation is advantageous when the algorithm for | Proactive negotiation is advantageous when the algorithm for | |||
selecting from among the available representations is difficult to | selecting from among the available representations is difficult to | |||
describe to a user agent, or when the server desires to send its | describe to a user agent, or when the server desires to send its | |||
"best guess" to the user agent along with the first response (hoping | "best guess" to the user agent along with the first response (hoping | |||
to avoid the round-trip delay of a subsequent request if the "best | to avoid the round-trip delay of a subsequent request if the "best | |||
guess" is good enough for the user). In order to improve the | guess" is good enough for the user). In order to improve the | |||
server's guess, a user agent MAY send request header fields that | server's guess, a user agent MAY send request header fields that | |||
describe its preferences. | describe its preferences. | |||
skipping to change at page 19, line 50 | skipping to change at page 20, line 11 | |||
An origin server MAY generate a Vary header field (Section 7.1.4) in | An origin server MAY generate a Vary header field (Section 7.1.4) in | |||
responses that are subject to proactive negotiation to indicate what | responses that are subject to proactive negotiation to indicate what | |||
parameters of request information might be used in its selection | parameters of request information might be used in its selection | |||
algorithm, thereby providing a means for recipients to determine the | algorithm, thereby providing a means for recipients to determine the | |||
reusability of that same response for user agents with differing | reusability of that same response for user agents with differing | |||
request information. | request information. | |||
3.4.2. Reactive Negotiation | 3.4.2. Reactive Negotiation | |||
With reactive negotiation (a.k.a., agent-driven negotiation), | With reactive negotiation (a.k.a., agent-driven negotiation), | |||
selection of the best representation for a response is performed by | selection of the best response representation (regardless of the | |||
the user agent after receiving an initial response from the origin | status code) is performed by the user agent after receiving an | |||
server with a list of alternative resources. If the user agent is | initial response from the origin server that contains a list of | |||
not satisfied by the initial response, it can perform a GET request | resources for alternative representations. If the user agent is not | |||
on one or more of the alternative resources, selected based on | satisfied by the initial response representation, it can perform a | |||
metadata included in the list, to obtain a different form of | GET request on one or more of the alternative resources, selected | |||
representation. Selection of alternatives might be performed | based on metadata included in the list, to obtain a different form of | |||
automatically by the user agent or manually by the user selecting | representation for that response. Selection of alternatives might be | |||
from a generated (possibly hypertext) menu. | performed automatically by the user agent or manually by the user | |||
selecting from a generated (possibly hypertext) menu. | ||||
A server can send a 300 (Multiple Choices) response to indicate that | Note that the above refers to representations of the response, in | |||
reactive negotiation by the user agent is desired, or a 406 (Not | general, not representations of the resource. The alternative | |||
Acceptable) status code to indicate that proactive negotiation has | representations are only considered representations of the target | |||
failed. In both cases, the response ought to include information | resource if the response in which those alternatives are provided has | |||
about the available representations so that the user or user agent | the semantics of being a representation of the target resource (e.g., | |||
can react by making a selection. | a 200 (OK) response to a GET request) or has the semantics of | |||
providing links to alternative representations for the target | ||||
resource (e.g., a 300 (Multiple Choices) response to a GET request). | ||||
A server might choose not to send an initial representation, other | ||||
than the list of alternatives, and thereby indicate that reactive | ||||
negotiation by the user agent is preferred. For example, the | ||||
alternatives listed in responses with the 300 (Multiple Choices) and | ||||
406 (Not Acceptable) status codes include information about the | ||||
available representations so that the user or user agent can react by | ||||
making a selection. | ||||
Reactive negotiation is advantageous when the response would vary | Reactive negotiation is advantageous when the response would vary | |||
over commonly-used dimensions (such as type, language, or encoding), | over commonly-used dimensions (such as type, language, or encoding), | |||
when the origin server is unable to determine a user agent's | when the origin server is unable to determine a user agent's | |||
capabilities from examining the request, and generally when public | capabilities from examining the request, and generally when public | |||
caches are used to distribute server load and reduce network usage. | caches are used to distribute server load and reduce network usage. | |||
Reactive negotiation suffers from the disadvantages of transmitting a | Reactive negotiation suffers from the disadvantages of transmitting a | |||
list of alternatives to the user agent, which degrades user-perceived | list of alternatives to the user agent, which degrades user-perceived | |||
latency if transmitted in the header section, and needing a second | latency if transmitted in the header section, and needing a second | |||
skipping to change at page 20, line 39 | skipping to change at page 21, line 11 | |||
specification does not define a mechanism for supporting automatic | specification does not define a mechanism for supporting automatic | |||
selection, though it does not prevent such a mechanism from being | selection, though it does not prevent such a mechanism from being | |||
developed as an extension. | developed as an extension. | |||
4. Request Methods | 4. Request Methods | |||
4.1. Overview | 4.1. Overview | |||
The request method token is the primary source of request semantics; | The request method token is the primary source of request semantics; | |||
it indicates the purpose for which the client has made this request | it indicates the purpose for which the client has made this request | |||
and what is expected by the client as a successful result. The | and what is expected by the client as a successful result. | |||
request semantics might be further specialized by the semantics of | ||||
some header fields when present in a request (Section 5) if those | The request method's semantics might be further specialized by the | |||
additional semantics do not conflict with the method. | semantics of some header fields when present in a request (Section 5) | |||
if those additional semantics do not conflict with the method. For | ||||
example, a client can send conditional request header fields | ||||
(Section 5.2) to make the requested action conditional on the current | ||||
state of the target resource ([Part4]). | ||||
method = token | method = token | |||
HTTP was originally designed to be usable as an interface to | HTTP was originally designed to be usable as an interface to | |||
distributed object systems. The request method was envisioned as | distributed object systems. The request method was envisioned as | |||
applying semantics to a target resource in much the same way as | applying semantics to a target resource in much the same way as | |||
invoking a defined method on an identified object would apply | invoking a defined method on an identified object would apply | |||
semantics. The method token is case-sensitive because it might be | semantics. The method token is case-sensitive because it might be | |||
used as a gateway to object-based systems with case-sensitive method | used as a gateway to object-based systems with case-sensitive method | |||
names. | names. | |||
skipping to change at page 21, line 24 | skipping to change at page 22, line 11 | |||
commonly used in HTTP, as outlined by the following table. By | commonly used in HTTP, as outlined by the following table. By | |||
convention, standardized methods are defined in all-uppercase ASCII | convention, standardized methods are defined in all-uppercase ASCII | |||
letters. | letters. | |||
+---------+-------------------------------------------------+-------+ | +---------+-------------------------------------------------+-------+ | |||
| Method | Description | Sec. | | | Method | Description | Sec. | | |||
+---------+-------------------------------------------------+-------+ | +---------+-------------------------------------------------+-------+ | |||
| GET | Transfer a current representation of the target | 4.3.1 | | | GET | Transfer a current representation of the target | 4.3.1 | | |||
| | resource. | | | | | resource. | | | |||
| HEAD | Same as GET, but only transfer the status line | 4.3.2 | | | HEAD | Same as GET, but only transfer the status line | 4.3.2 | | |||
| | and header block. | | | | | and header section. | | | |||
| POST | Perform resource-specific processing on the | 4.3.3 | | | POST | Perform resource-specific processing on the | 4.3.3 | | |||
| | request payload. | | | | | request payload. | | | |||
| PUT | Replace all current representations of the | 4.3.4 | | | PUT | Replace all current representations of the | 4.3.4 | | |||
| | target resource with the request payload. | | | | | target resource with the request payload. | | | |||
| DELETE | Remove all current representations of the | 4.3.5 | | | DELETE | Remove all current representations of the | 4.3.5 | | |||
| | target resource. | | | | | target resource. | | | |||
| CONNECT | Establish a tunnel to the server identified by | 4.3.6 | | | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | | |||
| | the target resource. | | | | | the target resource. | | | |||
| OPTIONS | Describe the communication options for the | 4.3.7 | | | OPTIONS | Describe the communication options for the | 4.3.7 | | |||
| | target resource. | | | | | target resource. | | | |||
skipping to change at page 22, line 10 | skipping to change at page 22, line 45 | |||
The set of methods allowed by a target resource can be listed in an | The set of methods allowed by a target resource can be listed in an | |||
Allow header field (Section 7.4.1). However, the set of allowed | Allow header field (Section 7.4.1). However, the set of allowed | |||
methods can change dynamically. When a request method is received | methods can change dynamically. When a request method is received | |||
that is unrecognized or not implemented by an origin server, the | that is unrecognized or not implemented by an origin server, the | |||
origin server SHOULD respond with the 501 (Not Implemented) status | origin server SHOULD respond with the 501 (Not Implemented) status | |||
code. When a request method is received that is known by an origin | code. When a request method is received that is known by an origin | |||
server but not allowed for the target resource, the origin server | server but not allowed for the target resource, the origin server | |||
SHOULD respond with the 405 (Method Not Allowed) status code. | SHOULD respond with the 405 (Method Not Allowed) status code. | |||
A client can send conditional request header fields (Section 5.2) to | ||||
make the requested action conditional on the current state of the | ||||
target resource ([Part4]). | ||||
4.2. Common Method Properties | 4.2. Common Method Properties | |||
4.2.1. Safe Methods | 4.2.1. Safe Methods | |||
Request methods are considered "safe" if their defined semantics are | Request methods are considered "safe" if their defined semantics are | |||
essentially read-only; i.e., the client does not request, and does | essentially read-only; i.e., the client does not request, and does | |||
not expect, any state change on the origin server as a result of | not expect, any state change on the origin server as a result of | |||
applying a safe method to a target resource. Likewise, reasonable | applying a safe method to a target resource. Likewise, reasonable | |||
use of a safe method is not expected to cause any harm, loss of | use of a safe method is not expected to cause any harm, loss of | |||
property, or unusual burden on the origin server. | property, or unusual burden on the origin server. | |||
skipping to change at page 23, line 9 | skipping to change at page 23, line 39 | |||
A user agent SHOULD distinguish between safe and unsafe methods when | A user agent SHOULD distinguish between safe and unsafe methods when | |||
presenting potential actions to a user, such that the user can be | presenting potential actions to a user, such that the user can be | |||
made aware of an unsafe action before it is requested. | made aware of an unsafe action before it is requested. | |||
When a resource is constructed such that parameters within the | When a resource is constructed such that parameters within the | |||
effective request URI have the effect of selecting an action, it is | effective request URI have the effect of selecting an action, it is | |||
the resource owner's responsibility to ensure that the action is | the resource owner's responsibility to ensure that the action is | |||
consistent with the request method semantics. For example, it is | consistent with the request method semantics. For example, it is | |||
common for Web-based content editing software to use actions within | common for Web-based content editing software to use actions within | |||
query parameters, such as "page?do=delete". If the purpose of such a | query parameters, such as "page?do=delete". If the purpose of such a | |||
resource is to perform an unsafe action, then the resource MUST | resource is to perform an unsafe action, then the resource owner MUST | |||
disable or disallow that action when it is accessed using a safe | disable or disallow that action when it is accessed using a safe | |||
request method. Failure to do so will result in unfortunate side- | request method. Failure to do so will result in unfortunate side- | |||
effects when automated processes perform a GET on every URI reference | effects when automated processes perform a GET on every URI reference | |||
for the sake of link maintenance, pre-fetching, building a search | for the sake of link maintenance, pre-fetching, building a search | |||
index, etc. | index, etc. | |||
4.2.2. Idempotent Methods | 4.2.2. Idempotent Methods | |||
Request methods are considered "idempotent" if the intended effect of | Request methods are considered "idempotent" if the intended effect of | |||
multiple identical requests is the same as for a single request. Of | multiple identical requests is the same as for a single request. Of | |||
skipping to change at page 23, line 40 | skipping to change at page 24, line 22 | |||
client is able to read the server's response. For example, if a | client is able to read the server's response. For example, if a | |||
client sends a PUT request and the underlying connection is closed | client sends a PUT request and the underlying connection is closed | |||
before any response is received, then it can establish a new | before any response is received, then it can establish a new | |||
connection and retry the idempotent request because it knows that | connection and retry the idempotent request because it knows that | |||
repeating the request will have the same effect even if the original | repeating the request will have the same effect even if the original | |||
request succeeded. Note, however, that repeated failures would | request succeeded. Note, however, that repeated failures would | |||
indicate a problem within the server. | indicate a problem within the server. | |||
4.2.3. Cacheable Methods | 4.2.3. Cacheable Methods | |||
Request methods are considered "cacheable" if it is possible and | Request methods can be defined as "cacheable" to indicate that | |||
useful to answer a current client request with a stored response from | responses to them are allowed to be stored for future reuse; for | |||
a prior request. GET and HEAD are defined to be cacheable. In | specific requirements see [Part6]. In general, safe methods that do | |||
general, safe methods that do not depend on a current or | not depend on a current or authoritative response are defined as | |||
authoritative response are cacheable, though the overwhelming | cacheable; this specification defines GET, HEAD and POST as | |||
majority of caches only support GET and HEAD. HTTP requirements for | cacheable, although the overwhelming majority of cache | |||
cache behavior and cacheable responses are defined in [Part6]. | implementations only support GET and HEAD. | |||
4.3. Method Definitions | 4.3. Method Definitions | |||
4.3.1. GET | 4.3.1. GET | |||
The GET method requests transfer of a current selected representation | The GET method requests transfer of a current selected representation | |||
for the target resource. GET is the primary mechanism of information | for the target resource. GET is the primary mechanism of information | |||
retrieval and the focus of almost all performance optimizations. | retrieval and the focus of almost all performance optimizations. | |||
Hence, when people speak of retrieving some identifiable information | Hence, when people speak of retrieving some identifiable information | |||
via HTTP, they are generally referring to making a GET request. | via HTTP, they are generally referring to making a GET request. | |||
It is tempting to think of resource identifiers as remote filesystem | It is tempting to think of resource identifiers as remote filesystem | |||
pathnames, and of representations as being a copy of the contents of | pathnames, and of representations as being a copy of the contents of | |||
skipping to change at page 24, line 39 | skipping to change at page 25, line 18 | |||
requesting transfer of only some part(s) of the selected | requesting transfer of only some part(s) of the selected | |||
representation, by sending a Range header field in the request | representation, by sending a Range header field in the request | |||
([Part5]). | ([Part5]). | |||
A payload within a GET request message has no defined semantics; | A payload within a GET request message has no defined semantics; | |||
sending a payload body on a GET request might cause some existing | sending a payload body on a GET request might cause some existing | |||
implementations to reject the request. | implementations to reject the request. | |||
The response to a GET request is cacheable; a cache MAY use it to | The response to a GET request is cacheable; a cache MAY use it to | |||
satisfy subsequent GET and HEAD requests unless otherwise indicated | satisfy subsequent GET and HEAD requests unless otherwise indicated | |||
by the Cache-Control header field (Section 7.2 of [Part6]). | by the Cache-Control header field (Section 5.2 of [Part6]). | |||
4.3.2. HEAD | 4.3.2. 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 | |||
send a message body in the response (i.e., the response terminates at | send a message body in the response (i.e., the response terminates at | |||
the end of the header block). Aside from the payload header fields | the end of the header section). The server SHOULD send the same | |||
(Section 3.3), the server SHOULD send the same header fields in | header fields in response to a HEAD request as it would have sent if | |||
response to a HEAD request as it would have sent if the request had | the request had been a GET, except that the payload header fields | |||
been a GET. This method can be used for obtaining metadata about the | (Section 3.3) MAY be omitted. This method can be used for obtaining | |||
selected representation without transferring the representation data. | metadata about the selected representation without transferring the | |||
This method is often used for testing hypertext links for validity, | representation data and is often used for testing hypertext links for | |||
accessibility, and recent modification. | validity, accessibility, and recent modification. | |||
A payload within a HEAD request message has no defined semantics; | A payload within a HEAD request message has no defined semantics; | |||
sending a payload body on a HEAD request might cause some existing | sending a payload body on a HEAD request might cause some existing | |||
implementations to reject the request. | implementations to reject the request. | |||
The response to a HEAD request is cacheable; a cache MAY use it to | The response to a HEAD request is cacheable; a cache MAY use it to | |||
satisfy subsequent HEAD requests unless otherwise indicated by the | satisfy subsequent HEAD requests unless otherwise indicated by the | |||
Cache-Control header field (Section 7.2 of [Part6]). A HEAD response | Cache-Control header field (Section 5.2 of [Part6]). A HEAD response | |||
might also have an effect on previously cached responses to GET; see | might also have an effect on previously cached responses to GET; see | |||
Section 5 of [Part6]. | Section 4.3.5 of [Part6]. | |||
4.3.3. POST | 4.3.3. POST | |||
The POST method requests that the target resource process the | The POST method requests that the target resource process the | |||
representation enclosed in the request according to the resource's | representation enclosed in the request according to the resource's | |||
own specific semantics. For example, POST is used for the following | own specific semantics. For example, POST is used for the following | |||
functions (among others): | functions (among others): | |||
o Providing a block of data, such as the fields entered into an HTML | o Providing a block of data, such as the fields entered into an HTML | |||
form, to a data-handling process; | form, to a data-handling process; | |||
skipping to change at page 25, line 47 | skipping to change at page 26, line 27 | |||
being 206, 304, and 416). | being 206, 304, and 416). | |||
If one or more resources has been created on the origin server as a | If one or more resources has been created on the origin server as a | |||
result of successfully processing a POST request, the origin server | result of successfully processing a POST request, the origin server | |||
SHOULD send a 201 (Created) response containing a Location header | SHOULD send a 201 (Created) response containing a Location header | |||
field that provides an identifier for the primary resource created | field that provides an identifier for the primary resource created | |||
(Section 7.1.2) and a representation that describes the status of the | (Section 7.1.2) and a representation that describes the status of the | |||
request while referring to the new resource(s). | request while referring to the new resource(s). | |||
Responses to POST requests are only cacheable when they include | Responses to POST requests are only cacheable when they include | |||
explicit freshness information (see Section 4.1.1 of [Part6]). | explicit freshness information (see Section 4.2.1 of [Part6]). | |||
However, POST caching is not widely implemented. For cases where an | However, POST caching is not widely implemented. For cases where an | |||
origin server wishes the client to be able to cache the result of a | origin server wishes the client to be able to cache the result of a | |||
POST in a way that can be reused by a later GET, the origin server | POST in a way that can be reused by a later GET, the origin server | |||
MAY send a 200 (OK) response containing the result and a Content- | MAY send a 200 (OK) response containing the result and a Content- | |||
Location header field that has the same value as the POST's effective | Location header field that has the same value as the POST's effective | |||
request URI (Section 3.1.4.2). | request URI (Section 3.1.4.2). | |||
If the result of processing a POST would be equivalent to a | If the result of processing a POST would be equivalent to a | |||
representation of an existing resource, an origin server MAY redirect | representation of an existing resource, an origin server MAY redirect | |||
the user agent to that resource by sending a 303 (See Other) response | the user agent to that resource by sending a 303 (See Other) response | |||
skipping to change at page 26, line 35 | skipping to change at page 27, line 15 | |||
subject to dynamic processing by the origin server, before any | subject to dynamic processing by the origin server, before any | |||
subsequent GET is received. A successful response only implies that | subsequent GET is received. A successful response only implies that | |||
the user agent's intent was achieved at the time of its processing by | the user agent's intent was achieved at the time of its processing by | |||
the origin server. | the origin server. | |||
If the target resource does not have a current representation and the | If the target resource does not have a current representation and the | |||
PUT successfully creates one, then the origin server MUST inform the | PUT successfully creates one, then the origin server MUST inform the | |||
user agent by sending a 201 (Created) response. If the target | user agent by sending a 201 (Created) response. If the target | |||
resource does have a current representation and that representation | resource does have a current representation and that representation | |||
is successfully modified in accordance with the state of the enclosed | is successfully modified in accordance with the state of the enclosed | |||
representation, then either a 200 (OK) or 204 (No Content) response | representation, then the origin server MUST send either a 200 (OK) or | |||
SHOULD be sent to indicate successful completion of the request. | a 204 (No Content) response to indicate successful completion of the | |||
request. | ||||
An origin server SHOULD ignore unrecognized header fields received in | An origin server SHOULD ignore unrecognized header fields received in | |||
a PUT request (i.e., do not save them as part of the resource state). | a PUT request (i.e., do not save them as part of the resource state). | |||
An origin server SHOULD verify that the PUT representation is | An origin server SHOULD verify that the PUT representation is | |||
consistent with any constraints the server has for the target | consistent with any constraints the server has for the target | |||
resource that cannot or will not be changed by the PUT. This is | resource that cannot or will not be changed by the PUT. This is | |||
particularly important when the origin server uses internal | particularly important when the origin server uses internal | |||
configuration information related to the URI in order to set the | configuration information related to the URI in order to set the | |||
values for representation metadata on GET responses. When a PUT | values for representation metadata on GET responses. When a PUT | |||
representation is inconsistent with the target resource, the origin | representation is inconsistent with the target resource, the origin | |||
server SHOULD either make them consistent, by transforming the | server SHOULD either make them consistent, by transforming the | |||
representation or changing the resource configuration, or respond | representation or changing the resource configuration, or respond | |||
with an appropriate error message containing sufficient information | with an appropriate error message containing sufficient information | |||
to explain why the representation is unsuitable. The 409 (Conflict) | to explain why the representation is unsuitable. The 409 (Conflict) | |||
or 415 (Unsupported Media Type) status codes are suggested, with the | or 415 (Unsupported Media Type) status codes are suggested, with the | |||
latter being specific to constraints on Content-Type values. | latter being specific to constraints on Content-Type values. | |||
For example, if the target resource is configured to always have a | For example, if the target resource is configured to always have a | |||
Content-Type of "text/html" and the representation being PUT has a | Content-Type of "text/html" and the representation being PUT has a | |||
Content-Type of "image/jpeg", then the origin server SHOULD do one | Content-Type of "image/jpeg", the origin server ought to do one of: | |||
of: | ||||
a. reconfigure the target resource to reflect the new media type; | a. reconfigure the target resource to reflect the new media type; | |||
b. transform the PUT representation to a format consistent with that | b. transform the PUT representation to a format consistent with that | |||
of the resource before saving it as the new resource state; or, | of the resource before saving it as the new resource state; or, | |||
c. reject the request with a 415 (Unsupported Media Type) response | c. reject the request with a 415 (Unsupported Media Type) response | |||
indicating that the target resource is limited to "text/html", | indicating that the target resource is limited to "text/html", | |||
perhaps including a link to a different resource that would be a | perhaps including a link to a different resource that would be a | |||
suitable target for the new representation. | suitable target for the new representation. | |||
skipping to change at page 28, line 18 | skipping to change at page 28, line 46 | |||
knows which target resource is desired. A service that selects a | knows which target resource is desired. A service that selects a | |||
proper URI on behalf of the client, after receiving a state-changing | proper URI on behalf of the client, after receiving a state-changing | |||
request, SHOULD be implemented using the POST method rather than PUT. | request, SHOULD be implemented using the POST method rather than PUT. | |||
If the origin server will not make the requested PUT state change to | If the origin server will not make the requested PUT state change to | |||
the target resource and instead wishes to have it applied to a | the target resource and instead wishes to have it applied to a | |||
different resource, such as when the resource has been moved to a | different resource, such as when the resource has been moved to a | |||
different URI, then the origin server MUST send an appropriate 3xx | different URI, then the origin server MUST send an appropriate 3xx | |||
(Redirection) response; the user agent MAY then make its own decision | (Redirection) response; the user agent MAY then make its own decision | |||
regarding whether or not to redirect the request. | regarding whether or not to redirect the request. | |||
A PUT request applied to the target resource MAY have side-effects on | A PUT request applied to the target resource can have side-effects on | |||
other resources. For example, an article might have a URI for | other resources. For example, an article might have a URI for | |||
identifying "the current version" (a resource) that is separate from | identifying "the current version" (a resource) that is separate from | |||
the URIs identifying each particular version (different resources | the URIs identifying each particular version (different resources | |||
that at one point shared the same state as the current version | that at one point shared the same state as the current version | |||
resource). A successful PUT request on "the current version" URI | resource). A successful PUT request on "the current version" URI | |||
might therefore create a new version resource in addition to changing | might therefore create a new version resource in addition to changing | |||
the state of the target resource, and might also cause links to be | the state of the target resource, and might also cause links to be | |||
added between the related resources. | added between the related resources. | |||
An origin server SHOULD reject any PUT request that contains a | An origin server that allows PUT on a given target resource MUST send | |||
Content-Range header field (Section 4.2 of [Part5]), since it might | a 400 (Bad Request) response to a PUT request that contains a | |||
be misinterpreted as partial content (or might be partial content | Content-Range header field (Section 4.2 of [Part5]), since the | |||
that is being mistakenly PUT as a full representation). Partial | payload is likely to be partial content that has been mistakenly PUT | |||
content updates are possible by targeting a separately identified | as a full representation. Partial content updates are possible by | |||
resource with state that overlaps a portion of the larger resource, | targeting a separately identified resource with state that overlaps a | |||
or by using a different method that has been specifically defined for | portion of the larger resource, or by using a different method that | |||
partial updates (for example, the PATCH method defined in [RFC5789]). | has been specifically defined for partial updates (for example, the | |||
PATCH method defined in [RFC5789]). | ||||
Responses to the PUT method are not cacheable. If a PUT request | Responses to the PUT method are not cacheable. If a successful PUT | |||
passes through a cache that has one or more stored responses for the | request passes through a cache that has one or more stored responses | |||
effective request URI, those stored responses will be invalidated | for the effective request URI, those stored responses will be | |||
(see Section 6 of [Part6]). | invalidated (see Section 4.4 of [Part6]). | |||
4.3.5. DELETE | 4.3.5. DELETE | |||
The DELETE method requests that the origin server remove the | The DELETE method requests that the origin server remove the | |||
association between the target resource and its current | association between the target resource and its current | |||
functionality. In effect, this method is similar to the rm command | functionality. In effect, this method is similar to the rm command | |||
in UNIX: it expresses a deletion operation on the URI mapping of the | in UNIX: it expresses a deletion operation on the URI mapping of the | |||
origin server, rather than an expectation that the previously | origin server, rather than an expectation that the previously | |||
associated information be deleted. | associated information be deleted. | |||
skipping to change at page 29, line 27 | skipping to change at page 30, line 8 | |||
previously created using a PUT request, or identified via the | previously created using a PUT request, or identified via the | |||
Location header field after a 201 (Created) response to a POST | Location header field after a 201 (Created) response to a POST | |||
request, might allow a corresponding DELETE request to undo those | request, might allow a corresponding DELETE request to undo those | |||
actions. Similarly, custom user agent implementations that implement | actions. Similarly, custom user agent implementations that implement | |||
an authoring function, such as revision control clients using HTTP | an authoring function, such as revision control clients using HTTP | |||
for remote operations, might use DELETE based on an assumption that | for remote operations, might use DELETE based on an assumption that | |||
the server's URI space has been crafted to correspond to a version | the server's URI space has been crafted to correspond to a version | |||
repository. | repository. | |||
If a DELETE method is successfully applied, the origin server SHOULD | If a DELETE method is successfully applied, the origin server SHOULD | |||
send a 202 (Accepted) status code if the action seems okay but has | send a 202 (Accepted) status code if the action will likely succeed | |||
not yet been enacted, a 204 (No Content) status code if the action | but has not yet been enacted, a 204 (No Content) status code if the | |||
has been enacted and no further information is to be supplied, or a | action has been enacted and no further information is to be supplied, | |||
200 (OK) status code if the action has been enacted and the response | or a 200 (OK) status code if the action has been enacted and the | |||
message includes a representation describing the status. | response message includes a representation describing the status. | |||
A payload within a DELETE request message has no defined semantics; | A payload within a DELETE request message has no defined semantics; | |||
sending a payload body on a DELETE request might cause some existing | sending a payload body on a DELETE request might cause some existing | |||
implementations to reject the request. | implementations to reject the request. | |||
Responses to the DELETE method are not cacheable. If a DELETE | Responses to the DELETE method are not cacheable. If a DELETE | |||
request passes through a cache that has one or more stored responses | request passes through a cache that has one or more stored responses | |||
for the effective request URI, those stored responses will be | for the effective request URI, those stored responses will be | |||
invalidated (see Section 6 of [Part6]). | invalidated (see Section 4.4 of [Part6]). | |||
4.3.6. CONNECT | 4.3.6. CONNECT | |||
The CONNECT method requests that the recipient establish a tunnel to | The CONNECT method requests that the recipient establish a tunnel to | |||
the destination origin server identified by the request-target and, | the destination origin server identified by the request-target and, | |||
if successful, thereafter restrict its behavior to blind forwarding | if successful, thereafter restrict its behavior to blind forwarding | |||
of packets, in both directions, until the connection is closed. | of packets, in both directions, until the tunnel is closed. | |||
CONNECT is intended only for use in requests to a proxy. An origin | CONNECT is intended only for use in requests to a proxy. An origin | |||
server that receives a CONNECT request for itself MAY respond with a | server that receives a CONNECT request for itself MAY respond with a | |||
2xx status code to indicate that a connection is established. | 2xx status code to indicate that a connection is established. | |||
However, most origin servers do not implement CONNECT. | However, most origin servers do not implement CONNECT. | |||
A client sending a CONNECT request MUST send the authority form of | A client sending a CONNECT request MUST send the authority form of | |||
request-target (Section 5.3 of [Part1]); i.e., the request-target | request-target (Section 5.3 of [Part1]); i.e., the request-target | |||
consists of only the host name and port number of the tunnel | consists of only the host name and port number of the tunnel | |||
destination, separated by a colon. For example, | destination, separated by a colon. For example, | |||
CONNECT server.example.com:80 HTTP/1.1 | CONNECT server.example.com:80 HTTP/1.1 | |||
Host: server.example.com:80 | Host: server.example.com:80 | |||
skipping to change at page 30, line 20 | skipping to change at page 30, line 48 | |||
destination, separated by a colon. For example, | destination, separated by a colon. For example, | |||
CONNECT server.example.com:80 HTTP/1.1 | CONNECT server.example.com:80 HTTP/1.1 | |||
Host: server.example.com:80 | Host: server.example.com:80 | |||
The recipient proxy can establish a tunnel either by directly | The recipient proxy can establish a tunnel either by directly | |||
connecting to the request-target or, if configured to use another | connecting to the request-target or, if configured to use another | |||
proxy, by forwarding the CONNECT request to the next inbound proxy. | proxy, by forwarding the CONNECT request to the next inbound proxy. | |||
Any 2xx (Successful) response indicates that the sender (and all | Any 2xx (Successful) response indicates that the sender (and all | |||
inbound proxies) will switch to tunnel mode immediately after the | inbound proxies) will switch to tunnel mode immediately after the | |||
blank line that concludes the successful response's header block; | blank line that concludes the successful response's header section; | |||
data received after that blank line is from the server identified by | data received after that blank line is from the server identified by | |||
the request-target. Any response other than a successful response | the request-target. Any response other than a successful response | |||
indicates that the tunnel has not yet been formed and that the | indicates that the tunnel has not yet been formed and that the | |||
connection remains governed by HTTP. | connection remains governed by HTTP. | |||
A server SHOULD NOT send any Transfer-Encoding or Content-Length | A tunnel is closed when a tunnel intermediary detects that either | |||
header fields in a successful response. A client MUST ignore any | side has closed its connection: the intermediary MUST attempt to send | |||
Content-Length or Transfer-Encoding header fields received in a | any outstanding data that came from the closed side to the other | |||
successful response. | side, close both connections, and then discard any remaining data | |||
left undelivered. | ||||
Proxy authentication might be used to establish the authority to | ||||
create a tunnel. For example, | ||||
CONNECT server.example.com:80 HTTP/1.1 | ||||
Host: server.example.com:80 | ||||
Proxy-Authorization: basic aGVsbG86d29ybGQ= | ||||
There are significant risks in establishing a tunnel to arbitrary | There are significant risks in establishing a tunnel to arbitrary | |||
servers, particularly when the destination is a well-known or | servers, particularly when the destination is a well-known or | |||
reserved TCP port that is not intended for Web traffic. For example, | reserved TCP port that is not intended for Web traffic. For example, | |||
a CONNECT to a request-target of "example.com:25" would suggest that | a CONNECT to a request-target of "example.com:25" would suggest that | |||
the proxy connect to the reserved port for SMTP traffic; if allowed, | the proxy connect to the reserved port for SMTP traffic; if allowed, | |||
that could trick the proxy into relaying spam email. Proxies that | that could trick the proxy into relaying spam email. Proxies that | |||
support CONNECT SHOULD restrict its use to a limited set of known | support CONNECT SHOULD restrict its use to a limited set of known | |||
ports or a configurable whitelist of safe request targets. | ports or a configurable whitelist of safe request targets. | |||
Proxy authentication might be used to establish the authority to | A server MUST NOT send any Transfer-Encoding or Content-Length header | |||
create a tunnel. For example, | fields in a 2xx (Successful) response to CONNECT. A client MUST | |||
ignore any Content-Length or Transfer-Encoding header fields received | ||||
CONNECT server.example.com:80 HTTP/1.1 | in a successful response to CONNECT. | |||
Host: server.example.com:80 | ||||
Proxy-Authorization: basic aGVsbG86d29ybGQ= | ||||
When a tunnel intermediary detects that either side has closed its | ||||
connection, any outstanding data that came from that side will first | ||||
be sent to the other side and then the intermediary will close both | ||||
connections. If there is outstanding data left undelivered, that | ||||
data will be discarded. | ||||
A payload within a CONNECT request message has no defined semantics; | A payload within a CONNECT request message has no defined semantics; | |||
sending a payload body on a CONNECT request might cause some existing | sending a payload body on a CONNECT request might cause some existing | |||
implementations to reject the request. | implementations to reject the request. | |||
Responses to the CONNECT method are not cacheable. | Responses to the CONNECT method are not cacheable. | |||
4.3.7. OPTIONS | 4.3.7. OPTIONS | |||
The OPTIONS method requests information about the communication | The OPTIONS method requests information about the communication | |||
options available on the request/response chain identified by the | options available for the target resource, either at the origin | |||
effective request URI. This method allows a client to determine the | server or an intervening intermediary. This method allows a client | |||
options and/or requirements associated with a resource, or the | to determine the options and/or requirements associated with a | |||
capabilities of a server, without implying a resource action. | resource, or the capabilities of a server, without implying a | |||
resource action. | ||||
An OPTIONS request with an asterisk ("*") as the request-target | An OPTIONS request with an asterisk ("*") as the request-target | |||
(Section 5.3 of [Part1]) applies to the server in general rather than | (Section 5.3 of [Part1]) applies to the server in general rather than | |||
to a specific resource. Since a server's communication options | to a specific resource. Since a server's communication options | |||
typically depend on the resource, the "*" request is only useful as a | typically depend on the resource, the "*" request is only useful as a | |||
"ping" or "no-op" type of method; it does nothing beyond allowing the | "ping" or "no-op" type of method; it does nothing beyond allowing the | |||
client to test the capabilities of the server. For example, this can | client to test the capabilities of the server. For example, this can | |||
be used to test a proxy for HTTP/1.1 conformance (or lack thereof). | be used to test a proxy for HTTP/1.1 conformance (or lack thereof). | |||
If the request-target is not an asterisk, the OPTIONS request applies | If the request-target is not an asterisk, the OPTIONS request applies | |||
skipping to change at page 32, line 16 | skipping to change at page 32, line 46 | |||
resource. | resource. | |||
Responses to the OPTIONS method are not cacheable. | Responses to the OPTIONS method are not cacheable. | |||
4.3.8. TRACE | 4.3.8. TRACE | |||
The TRACE method requests a remote, application-level loop-back of | The TRACE method requests a remote, application-level loop-back of | |||
the request message. The final recipient of the request SHOULD | the request message. The final recipient of the request SHOULD | |||
reflect the message received, excluding some fields described below, | reflect the message received, excluding some fields described below, | |||
back to the client as the message body of a 200 (OK) response with a | back to the client as the message body of a 200 (OK) response with a | |||
Content-Type of "message/http" (Section 7.3.1 of [Part1]). The final | Content-Type of "message/http" (Section 8.3.1 of [Part1]). The final | |||
recipient is either the origin server or the first server to receive | recipient is either the origin server or the first server to receive | |||
a Max-Forwards value of zero (0) in the request (Section 5.1.2). | a Max-Forwards value of zero (0) in the request (Section 5.1.2). | |||
A client MUST NOT send header fields in a TRACE request containing | A client MUST NOT generate header fields in a TRACE request | |||
sensitive data that might be disclosed by the response. For example, | containing sensitive data that might be disclosed by the response. | |||
it would be foolish for a user agent to send stored user credentials | ||||
[Part7] or cookies [RFC6265] in a TRACE request. The final recipient | For example, it would be foolish for a user agent to send stored user | |||
SHOULD exclude any request header fields from the response body that | credentials [Part7] or cookies [RFC6265] in a TRACE request. The | |||
are likely to contain sensitive data. | final recipient of the request SHOULD exclude any request header | |||
fields that are likely to contain sensitive data when that recipient | ||||
generates the response body. | ||||
TRACE allows the client to see what is being received at the other | TRACE allows the client to see what is being received at the other | |||
end of the request chain and use that data for testing or diagnostic | end of the request chain and use that data for testing or diagnostic | |||
information. The value of the Via header field (Section 5.7.1 of | information. The value of the Via header field (Section 5.7.1 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. | |||
A client MUST NOT send a message body in a TRACE request. | A client MUST NOT send a message body in a TRACE request. | |||
skipping to change at page 33, line 8 | skipping to change at page 33, line 40 | |||
parameters on a programming language method invocation. | parameters on a programming language method invocation. | |||
5.1. Controls | 5.1. Controls | |||
Controls are request header fields that direct specific handling of | Controls are request header fields that direct specific handling of | |||
the request. | the request. | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
| Header Field Name | Defined in... | | | Header Field Name | Defined in... | | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
| Cache-Control | Section 7.2 of [Part6] | | | Cache-Control | Section 5.2 of [Part6] | | |||
| Expect | Section 5.1.1 | | | Expect | Section 5.1.1 | | |||
| Host | Section 5.4 of [Part1] | | | Host | Section 5.4 of [Part1] | | |||
| Max-Forwards | Section 5.1.2 | | | Max-Forwards | Section 5.1.2 | | |||
| Pragma | Section 7.4 of [Part6] | | | Pragma | Section 5.4 of [Part6] | | |||
| Range | Section 3.1 of [Part5] | | | Range | Section 3.1 of [Part5] | | |||
| TE | Section 4.3 of [Part1] | | | TE | Section 4.3 of [Part1] | | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
5.1.1. Expect | 5.1.1. Expect | |||
The "Expect" header field is used to indicate that particular server | The "Expect" header field in a request indicates a certain set of | |||
behaviors are required by the client. | behaviors (expectations) that need to be supported by the server in | |||
order to properly handle this request. The only such expectation | ||||
Expect = 1#expectation | defined by this specification is 100-continue. | |||
expectation = expect-name [ BWS "=" BWS expect-value ] | ||||
*( OWS ";" [ OWS expect-param ] ) | ||||
expect-param = expect-name [ BWS "=" BWS expect-value ] | ||||
expect-name = token | ||||
expect-value = token / quoted-string | ||||
If all received Expect header field(s) are syntactically valid but | ||||
contain an expectation that the recipient does not understand or | ||||
cannot comply with, the recipient MUST respond with a 417 | ||||
(Expectation Failed) status code. A recipient of a syntactically | ||||
invalid Expectation header field MUST respond with a 4xx status code | ||||
other than 417. | ||||
Comparison is case-insensitive for names (expect-name), and case- | ||||
sensitive for values (expect-value). | ||||
The Expect header field MUST be forwarded if the request is | ||||
forwarded. | ||||
Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect | ||||
header field. | ||||
5.1.1.1. Use of the 100 (Continue) Status | Expect = "100-continue" | |||
The only expectation defined by this specification is: | The Expect field-value is case-insensitive. | |||
100-continue | A server that receives an Expect field-value other than 100-continue | |||
MAY respond with a 417 (Expectation Failed) status code to indicate | ||||
that the unexpected expectation cannot be met. | ||||
The request includes a payload body and the client will wait for a | A 100-continue expectation informs recipients that the client is | |||
100 (Continue) response after sending the request header section | about to send a (presumably large) message body in this request and | |||
but before sending the payload body. The 100-continue expectation | wishes to receive a 100 (Continue) interim response if the request- | |||
does not use any expect-params. | line and header fields are not sufficient to cause an immediate | |||
success, redirect, or error response. This allows the client to wait | ||||
for an indication that it is worthwhile to send the message body | ||||
before actually doing so, which can improve efficiency when the | ||||
message body is huge or when the client anticipates that an error is | ||||
likely (e.g., when sending a state-changing method, for the first | ||||
time, without previously verified authentication credentials). | ||||
The primary purpose of the 100 (Continue) status code (Section 6.2.1) | For example, a request that begins with | |||
is to allow a client that is sending a request message with a payload | ||||
to determine if the origin server is willing to accept the request | ||||
(based on the request header fields) before the client sends the | ||||
payload body. In some cases, it might either be inappropriate or | ||||
highly inefficient for the client to send the payload body if the | ||||
server will reject the message without looking at the body. | ||||
Requirements for HTTP/1.1 clients: | PUT /somewhere/fun HTTP/1.1 | |||
Host: origin.example.com | ||||
Content-Type: video/h264 | ||||
Content-Length: 1234567890987 | ||||
Expect: 100-continue | ||||
o If a client will wait for a 100 (Continue) response before sending | allows the origin server to immediately respond with an error | |||
the payload body, it MUST send an Expect header field with the | message, such as 401 (Unauthorized) or 405 (Method Not Allowed), | |||
"100-continue" expectation. | before the client starts filling the pipes with an unnecessary data | |||
transfer. | ||||
o A client MUST NOT send an Expect header field with the "100- | Requirements for clients: | |||
continue" expectation if it does not intend to send a payload | ||||
body. | ||||
Because of the presence of older implementations, the protocol allows | o A client MUST NOT generate a 100-continue expectation in a request | |||
ambiguous situations in which a client might send "Expect: 100- | that does not include a message body. | |||
continue" without receiving either a 417 (Expectation Failed) or a | ||||
100 (Continue) status code. Therefore, when a client sends this | ||||
header field to an origin server (possibly via a proxy) from which it | ||||
has never seen a 100 (Continue) status code, the client SHOULD NOT | ||||
wait for an indefinite period before sending the payload body. | ||||
Requirements for HTTP/1.1 origin servers: | o A client that will wait for a 100 (Continue) response before | |||
sending the request message body MUST send an Expect header field | ||||
containing a 100-continue expectation. | ||||
o Upon receiving a request that includes an Expect header field with | o A client that sends a 100-continue expectation is not required to | |||
the "100-continue" expectation, an origin server MUST either | wait for any specific length of time; such a client MAY proceed to | |||
respond with 100 (Continue) status code and continue to read from | send the message body even if it has not yet received a response. | |||
the input stream, or respond with a final status code. The origin | Furthermore, since 100 (Continue) responses cannot be sent through | |||
server MUST NOT wait for the payload body before sending the 100 | an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an | |||
(Continue) response. If the origin server responds with a final | indefinite period before sending the message body. | |||
status code, it MUST NOT have performed the request method and MAY | ||||
either close the connection or continue to read and discard the | ||||
rest of the request. | ||||
o An origin server SHOULD NOT send a 100 (Continue) response if the | o A client that receives a 417 (Expectation Failed) status code in | |||
request message does not include an Expect header field with the | response to a request containing a 100-continue expectation SHOULD | |||
"100-continue" expectation, and MUST NOT send a 100 (Continue) | repeat that request without a 100-continue expectation, since the | |||
response if such a request comes from an HTTP/1.0 (or earlier) | 417 response merely indicates that the response chain does not | |||
client. There is an exception to this rule: for compatibility | support expectations (e.g., it passes through an HTTP/1.0 server). | |||
with [RFC2068], a server MAY send a 100 (Continue) status code in | ||||
response to an HTTP/1.1 PUT or POST request that does not include | ||||
an Expect header field with the "100-continue" expectation. This | ||||
exception, the purpose of which is to minimize any client | ||||
processing delays associated with an undeclared wait for 100 | ||||
(Continue) status code, applies only to HTTP/1.1 requests, and not | ||||
to requests with any other HTTP-version value. | ||||
o An origin server MAY omit a 100 (Continue) response if it has | Requirements for servers: | |||
already received some or all of the payload body for the | ||||
corresponding request. | ||||
o An origin server that sends a 100 (Continue) response MUST | o A server that receives a 100-continue expectation in an HTTP/1.0 | |||
ultimately send a final status code, once the payload body is | request MUST ignore that expectation. | |||
received and processed, unless it terminates the transport | ||||
connection prematurely. | ||||
o If an origin server receives a request that does not include an | o A server MAY omit sending a 100 (Continue) response if it has | |||
Expect header field with the "100-continue" expectation, the | already received some or all of the message body for the | |||
request includes a payload body, and the server responds with a | corresponding request, or if the framing indicates that there is | |||
final status code before reading the entire payload body from the | no message body. | |||
transport connection, then the server SHOULD NOT close the | ||||
transport connection until it has read the entire request, or | ||||
until the client closes the connection. Otherwise, the client | ||||
might not reliably receive the response message. However, this | ||||
requirement ought not be construed as preventing a server from | ||||
defending itself against denial-of-service attacks, or from badly | ||||
broken client implementations. | ||||
Requirements for HTTP/1.1 proxies: | o A server that sends a 100 (Continue) response MUST ultimately send | |||
a final status code, once the message body is received and | ||||
processed, unless the connection is closed prematurely. | ||||
o If a proxy receives a request that includes an Expect header field | o A server that responds with a final status code before reading the | |||
with the "100-continue" expectation, and the proxy either knows | entire message body SHOULD indicate in that response whether it | |||
that the next-hop server complies with HTTP/1.1 or higher, or does | intends to close the connection or continue reading and discarding | |||
not know the HTTP version of the next-hop server, it MUST forward | the request message (see Section 6.6 of [Part1]). | |||
the request, including the Expect header field. | ||||
o If the proxy knows that the version of the next-hop server is | An origin server MUST, upon receiving an HTTP/1.1 (or later) request- | |||
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST | line and a complete header section that contains a 100-continue | |||
respond with a 417 (Expectation Failed) status code. | expectation and indicates a request message body will follow, either | |||
send an immediate response with a final status code, if that status | ||||
can be determined by examining just the request-line and header | ||||
fields, or send an immediate 100 (Continue) response to encourage the | ||||
client to send the request's message body. The origin server MUST | ||||
NOT wait for the message body before sending the 100 (Continue) | ||||
response. | ||||
o Proxies SHOULD maintain a record of the HTTP version numbers | A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and | |||
received from recently-referenced next-hop servers. | a complete header section that contains a 100-continue expectation | |||
and indicates a request message body will follow, either send an | ||||
immediate response with a final status code, if that status can be | ||||
determined by examining just the request-line and header fields, or | ||||
begin forwarding the request toward the origin server by sending a | ||||
corresponding request-line and header section to the next inbound | ||||
server. If the proxy believes (from configuration or past | ||||
interaction) that the next inbound server only supports HTTP/1.0, the | ||||
proxy MAY generate an immediate 100 (Continue) response to encourage | ||||
the client to begin sending the message body. | ||||
o A proxy MUST NOT forward a 100 (Continue) response if the request | Note: The Expect header field was added after the original | |||
message was received from an HTTP/1.0 (or earlier) client and did | publication of HTTP/1.1 [RFC2068] as both the means to request an | |||
not include an Expect header field with the "100-continue" | interim 100 response and the general mechanism for indicating | |||
expectation. This requirement overrides the general rule for | must-understand extensions. However, the extension mechanism has | |||
forwarding of 1xx responses (see Section 6.2.1). | not been used by clients and the must-understand requirements have | |||
not been implemented by many servers, rendering the extension | ||||
mechanism useless. This specification has removed the extension | ||||
mechanism in order to simplify the definition and processing of | ||||
100-continue. | ||||
5.1.2. Max-Forwards | 5.1.2. Max-Forwards | |||
The "Max-Forwards" header field provides a mechanism with the TRACE | The "Max-Forwards" header field provides a mechanism with the TRACE | |||
(Section 4.3.8) and OPTIONS (Section 4.3.7) methods to limit the | (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit | |||
number of times that the request is forwarded by proxies. This can | the number of times that the request is forwarded by proxies. This | |||
be useful when the client is attempting to trace a request that | can be useful when the client is attempting to trace a request that | |||
appears to be failing or looping mid-chain. | appears to be failing or looping mid-chain. | |||
Max-Forwards = 1*DIGIT | Max-Forwards = 1*DIGIT | |||
The Max-Forwards value is a decimal integer indicating the remaining | The Max-Forwards value is a decimal integer indicating the remaining | |||
number of times this request message can be forwarded. | number of times this request message can be forwarded. | |||
Each recipient of a TRACE or OPTIONS request containing a Max- | Each intermediary that receives a TRACE or OPTIONS request containing | |||
Forwards header field MUST check and update its value prior to | a Max-Forwards header field MUST check and update its value prior to | |||
forwarding the request. If the received value is zero (0), the | forwarding the request. If the received value is zero (0), the | |||
recipient MUST NOT forward the request; instead, it MUST respond as | intermediary MUST NOT forward the request; instead, the intermediary | |||
the final recipient. If the received Max-Forwards value is greater | MUST respond as the final recipient. If the received Max-Forwards | |||
than zero, then the forwarded message MUST contain an updated Max- | value is greater than zero, the intermediary MUST generate an updated | |||
Forwards field with a value decremented by one (1). | Max-Forwards field in the forwarded message with a field-value that | |||
is the lesser of: a) the received value decremented by one (1), or b) | ||||
the recipient's maximum supported value for Max-Forwards. | ||||
The Max-Forwards header field MAY be ignored for all other request | A recipient MAY ignore a Max-Forwards header field received with any | |||
methods. | other request methods. | |||
5.2. Conditionals | 5.2. Conditionals | |||
The HTTP conditional request header fields [Part4] allow a client to | The HTTP conditional request header fields [Part4] allow a client to | |||
place a precondition on the state of the target resource, so that the | place a precondition on the state of the target resource, so that the | |||
action corresponding to the method semantics will not be applied if | action corresponding to the method semantics will not be applied if | |||
the precondition evaluates to false. Each precondition defined by | the precondition evaluates to false. Each precondition defined by | |||
this specification consists of a comparison between a set of | this specification consists of a comparison between a set of | |||
validators obtained from prior representations of the target resource | validators obtained from prior representations of the target resource | |||
to the current state of validators for the selected representation | to the current state of validators for the selected representation | |||
skipping to change at page 38, line 51 | skipping to change at page 39, line 11 | |||
"q" from being used with a media range, such an event is believed | "q" from being used with a media range, such an event is believed | |||
to be unlikely given the lack of any "q" parameters in the IANA | to be unlikely given the lack of any "q" parameters in the IANA | |||
media type registry and the rare usage of any media type | media type registry and the rare usage of any media type | |||
parameters in Accept. Future media types are discouraged from | parameters in Accept. Future media types are discouraged from | |||
registering any parameter named "q". | registering any parameter named "q". | |||
The example | The example | |||
Accept: audio/*; q=0.2, audio/basic | Accept: audio/*; q=0.2, audio/basic | |||
SHOULD be interpreted as "I prefer audio/basic, but send me any audio | is interpreted as "I prefer audio/basic, but send me any audio type | |||
type if it is the best available after an 80% mark-down in quality". | if it is the best available after an 80% mark-down in quality". | |||
A request without any Accept header field implies that the user agent | A request without any Accept header field implies that the user agent | |||
will accept any media type in response. If the header field is | will accept any media type in response. If the header field is | |||
present in a request and none of the available representations for | present in a request and none of the available representations for | |||
the response have a media type that is listed as acceptable, the | the response have a media type that is listed as acceptable, the | |||
origin server can either honor the header field by sending a 406 (Not | origin server can either honor the header field by sending a 406 (Not | |||
Acceptable) response or disregard the header field by treating the | Acceptable) response or disregard the header field by treating the | |||
response as if it is not subject to content negotiation. | response as if it is not subject to content negotiation. | |||
A more elaborate example is | A more elaborate example is | |||
skipping to change at page 44, line 39 | skipping to change at page 44, line 46 | |||
An example is: | An example is: | |||
From: webmaster@example.org | From: webmaster@example.org | |||
The From header field is rarely sent by non-robotic user agents. A | The From header field is rarely sent by non-robotic user agents. A | |||
user agent SHOULD NOT send a From header field without explicit | user agent SHOULD NOT send a From header field without explicit | |||
configuration by the user, since that might conflict with the user's | configuration by the user, since that might conflict with the user's | |||
privacy interests or their site's security policy. | privacy interests or their site's security policy. | |||
Robotic user agents SHOULD send a valid From header field so that the | A robotic user agent SHOULD send a valid From header field so that | |||
person responsible for running the robot can be contacted if problems | the person responsible for running the robot can be contacted if | |||
occur on servers, such as if the robot is sending excessive, | problems occur on servers, such as if the robot is sending excessive, | |||
unwanted, or invalid requests. | unwanted, or invalid requests. | |||
Servers SHOULD NOT use the From header field for access control or | A server SHOULD NOT use the From header field for access control or | |||
authentication, since most recipients will assume that the field | authentication, since most recipients will assume that the field | |||
value is public information. | value is public information. | |||
5.5.2. Referer | 5.5.2. Referer | |||
The "Referer" [sic] header field allows the user agent to specify a | The "Referer" [sic] header field allows the user agent to specify a | |||
URI reference for the resource from which the target URI was obtained | URI reference for the resource from which the target URI was obtained | |||
(i.e., the "referrer", though the field name is misspelled). A user | (i.e., the "referrer", though the field name is misspelled). A user | |||
agent MUST exclude any fragment or userinfo components [RFC3986] when | agent MUST NOT include the fragment and userinfo components of the | |||
generating the Referer field value. | URI reference [RFC3986], if any, when generating the Referer field | |||
value. | ||||
Referer = absolute-URI / partial-URI | Referer = absolute-URI / partial-URI | |||
Referer allows servers to generate back-links to other resources for | Referer allows servers to generate back-links to other resources for | |||
simple analytics, logging, optimized caching, etc. It also allows | simple analytics, logging, optimized caching, etc. It also allows | |||
obsolete or mistyped links to be found for maintenance. Some servers | obsolete or mistyped links to be found for maintenance. Some servers | |||
use Referer as a means of denying links from other sites (so-called | use Referer as a means of denying links from other sites (so-called | |||
"deep linking") or restricting cross-site request forgery (CSRF), but | "deep linking") or restricting cross-site request forgery (CSRF), but | |||
not all requests contain a Referer header field. | not all requests contain a Referer header field. | |||
skipping to change at page 45, line 32 | skipping to change at page 45, line 40 | |||
user's bookmarks/favorites), the user agent MUST either exclude | user's bookmarks/favorites), the user agent MUST either exclude | |||
Referer or send it with a value of "about:blank". | Referer or send it with a value of "about:blank". | |||
The Referer field has the potential to reveal information about the | The Referer field has the potential to reveal information about the | |||
request context or browsing history of the user, which is a privacy | request context or browsing history of the user, which is a privacy | |||
concern if the referring resource's identifier reveals personal | concern if the referring resource's identifier reveals personal | |||
information (such as an account name) or a resource that is supposed | information (such as an account name) or a resource that is supposed | |||
to be confidential (such as behind a firewall or internal to a | to be confidential (such as behind a firewall or internal to a | |||
secured service). Most general-purpose user agents do not send the | secured service). Most general-purpose user agents do not send the | |||
Referer header field when the referring resource is a local "file" or | Referer header field when the referring resource is a local "file" or | |||
"data" URI. A user agent SHOULD NOT send a Referer header field in | "data" URI. A user agent MUST NOT send a Referer header field in an | |||
an unsecured HTTP request if the referring page was received with a | unsecured HTTP request if the referring page was received with a | |||
secure protocol. See Section 9.3 for additional security | secure protocol. See Section 9.3 for additional security | |||
considerations. | considerations. | |||
Some intermediaries have been known to indiscriminately remove | Some intermediaries have been known to indiscriminately remove | |||
Referer header fields from outgoing requests. This has the | Referer header fields from outgoing requests. This has the | |||
unfortunate side-effect of interfering with protection against CSRF | unfortunate side-effect of interfering with protection against CSRF | |||
attacks, which can be far more harmful to their users. | attacks, which can be far more harmful to their users. | |||
Intermediaries and user agent extensions that wish to limit | Intermediaries and user agent extensions that wish to limit | |||
information disclosure in Referer ought to restrict their changes to | information disclosure in Referer ought to restrict their changes to | |||
specific edits, such as replacing internal domain names with | specific edits, such as replacing internal domain names with | |||
pseudonyms or truncating the query and/or path components. | pseudonyms or truncating the query and/or path components. An | |||
Intermediaries SHOULD NOT modify or delete the Referer field when the | intermediary SHOULD NOT modify or delete the Referer header field | |||
field value shares the same scheme and host as the request target. | when the field value shares the same scheme and host as the request | |||
target. | ||||
5.5.3. User-Agent | 5.5.3. User-Agent | |||
The "User-Agent" header field contains information about the user | The "User-Agent" header field contains information about the user | |||
agent originating the request, which is often used by servers to help | agent originating the request, which is often used by servers to help | |||
identify the scope of reported interoperability problems, to work | identify the scope of reported interoperability problems, to work | |||
around or tailor responses to avoid particular user agent | around or tailor responses to avoid particular user agent | |||
limitations, and for analytics regarding browser or operating system | limitations, and for analytics regarding browser or operating system | |||
use. A user agent SHOULD send a User-Agent field in each request | use. A user agent SHOULD send a User-Agent field in each request | |||
unless specifically configured not to do so. | unless specifically configured not to do so. | |||
skipping to change at page 46, line 23 | skipping to change at page 46, line 32 | |||
identifiers, each followed by zero or more comments (Section 3.2 of | identifiers, each followed by zero or more comments (Section 3.2 of | |||
[Part1]), which together identify the user agent software and its | [Part1]), which together identify the user agent software and its | |||
significant subproducts. By convention, the product identifiers are | significant subproducts. By convention, the product identifiers are | |||
listed in decreasing order of their significance for identifying the | listed in decreasing order of their significance for identifying the | |||
user agent software. Each product identifier consists of a name and | user agent software. Each product identifier consists of a name and | |||
optional version. | optional version. | |||
product = token ["/" product-version] | product = token ["/" product-version] | |||
product-version = token | product-version = token | |||
Senders SHOULD limit generated product identifiers to what is | A sender SHOULD limit generated product identifiers to what is | |||
necessary to identify the product; senders MUST NOT generate | necessary to identify the product; a sender MUST NOT generate | |||
advertising or other non-essential information within the product | advertising or other non-essential information within the product | |||
identifier. Senders SHOULD NOT generate information in product- | identifier. A sender SHOULD NOT generate information in product- | |||
version that is not a version identifier (i.e., successive versions | version that is not a version identifier (i.e., successive versions | |||
of the same product name ought to only differ in the product-version | of the same product name ought to only differ in the product-version | |||
portion of the product identifier). | portion of the product identifier). | |||
Example: | Example: | |||
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 | |||
A user agent SHOULD NOT generate a User-Agent field containing | A user agent SHOULD NOT generate a User-Agent field containing | |||
needlessly fine-grained detail and SHOULD limit the addition of | needlessly fine-grained detail and SHOULD limit the addition of | |||
skipping to change at page 47, line 12 | skipping to change at page 47, line 17 | |||
that identified user agent, even if they might not work as well for | that identified user agent, even if they might not work as well for | |||
the actual user agent being used. | the actual user agent being used. | |||
6. Response Status Codes | 6. Response Status Codes | |||
The status-code element is a 3-digit integer code giving the result | The status-code element is a 3-digit integer code giving the result | |||
of the attempt to understand and satisfy the request. | of the attempt to understand and satisfy the request. | |||
HTTP status codes are extensible. HTTP clients are not required to | HTTP status codes are extensible. HTTP clients are not required to | |||
understand the meaning of all registered status codes, though such | understand the meaning of all registered status codes, though such | |||
understanding is obviously desirable. However, clients MUST | understanding is obviously desirable. However, a client 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 an unrecognized status code as being equivalent to | digit, and treat an unrecognized status code as being equivalent to | |||
the x00 status code of that class, with the exception that a response | the x00 status code of that class, with the exception that a | |||
with an unrecognized status code MUST NOT be cached. | recipient MUST NOT cache a response with an unrecognized status code. | |||
For example, if an unrecognized status code of 471 is received by a | For example, if an unrecognized status code of 471 is received by a | |||
client, the client can assume that there was something wrong with its | client, the client can assume that there was something wrong with its | |||
request and treat the response as if it had received a 400 status | request and treat the response as if it had received a 400 status | |||
code. The response message will usually contain a representation | code. The response message will usually contain a representation | |||
that explains the status. | that explains the status. | |||
The first digit of the status-code defines the class of response. | The first digit of the status-code defines the class of response. | |||
The last two digits do not have any categorization role. There are 5 | The last two digits do not have any categorization role. There are 5 | |||
values for the first digit: | values for the first digit: | |||
skipping to change at page 48, line 5 | skipping to change at page 48, line 6 | |||
o 5xx (Server Error): The server failed to fulfill an apparently | o 5xx (Server Error): The server failed to fulfill an apparently | |||
valid request | valid request | |||
6.1. Overview of Status Codes | 6.1. Overview of Status Codes | |||
The status codes listed below are defined in this specification, | The status codes listed below are defined in this specification, | |||
Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. | Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. | |||
The reason phrases listed here are only recommendations -- they can | The reason phrases listed here are only recommendations -- they can | |||
be replaced by local equivalents without affecting the protocol. | be replaced by local equivalents without affecting the protocol. | |||
Responses with status codes that are defined as cacheable by default | ||||
(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be | ||||
reused by a cache with heuristic expiration unless otherwise | ||||
indicated by the method definition or explicit cache controls | ||||
[Part6]; all other status codes are not cacheable by default. | ||||
+------+-------------------------------+------------------------+ | +------+-------------------------------+------------------------+ | |||
| code | reason-phrase | Defined in... | | | code | reason-phrase | Defined in... | | |||
+------+-------------------------------+------------------------+ | +------+-------------------------------+------------------------+ | |||
| 100 | Continue | Section 6.2.1 | | | 100 | Continue | Section 6.2.1 | | |||
| 101 | Switching Protocols | Section 6.2.2 | | | 101 | Switching Protocols | Section 6.2.2 | | |||
| 200 | OK | Section 6.3.1 | | | 200 | OK | Section 6.3.1 | | |||
| 201 | Created | Section 6.3.2 | | | 201 | Created | Section 6.3.2 | | |||
| 202 | Accepted | Section 6.3.3 | | | 202 | Accepted | Section 6.3.3 | | |||
| 203 | Non-Authoritative Information | Section 6.3.4 | | | 203 | Non-Authoritative Information | Section 6.3.4 | | |||
| 204 | No Content | Section 6.3.5 | | | 204 | No Content | Section 6.3.5 | | |||
skipping to change at page 48, line 52 | skipping to change at page 49, line 52 | |||
| 426 | Upgrade Required | Section 6.5.15 | | | 426 | Upgrade Required | Section 6.5.15 | | |||
| 500 | Internal Server Error | Section 6.6.1 | | | 500 | Internal Server Error | Section 6.6.1 | | |||
| 501 | Not Implemented | Section 6.6.2 | | | 501 | Not Implemented | Section 6.6.2 | | |||
| 502 | Bad Gateway | Section 6.6.3 | | | 502 | Bad Gateway | Section 6.6.3 | | |||
| 503 | Service Unavailable | Section 6.6.4 | | | 503 | Service Unavailable | Section 6.6.4 | | |||
| 504 | Gateway Time-out | Section 6.6.5 | | | 504 | Gateway Time-out | Section 6.6.5 | | |||
| 505 | HTTP Version Not Supported | Section 6.6.6 | | | 505 | HTTP Version Not Supported | Section 6.6.6 | | |||
+------+-------------------------------+------------------------+ | +------+-------------------------------+------------------------+ | |||
Note that this list is not exhaustive -- it does not include | Note that this list is not exhaustive -- it does not include | |||
extension status codes defined in other specifications. | extension status codes defined in other specifications. The complete | |||
list of status codes is maintained by IANA. See Section 8.2 for | ||||
Responses with status codes that are defined as cacheable by default | details. | |||
(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be | ||||
reused by a cache with heuristic expiration unless otherwise | ||||
indicated by the method definition or explicit cache controls | ||||
[Part6]; all other status codes are not cacheable by default. | ||||
6.2. Informational 1xx | 6.2. Informational 1xx | |||
The 1xx (Informational) class of status code indicates an interim | The 1xx (Informational) class of status code indicates an interim | |||
response for communicating connection status or request progress | response for communicating connection status or request progress | |||
prior to completing the requested action and sending a final | prior to completing the requested action and sending a final | |||
response. All 1xx responses consist of only the status-line and | response. All 1xx responses consist of only the status-line and | |||
optional header fields, and thus are terminated by the empty line at | optional header fields, and thus are terminated by the empty line at | |||
the end of the header block. Since HTTP/1.0 did not define any 1xx | the end of the header section. Since HTTP/1.0 did not define any 1xx | |||
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 | status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 | |||
client except under experimental conditions. | client. | |||
A client MUST be prepared to accept one or more 1xx status responses | A client MUST be able to parse one or more 1xx responses received | |||
prior to a final response, even if the client does not expect one. A | prior to a final response, even if the client does not expect one. A | |||
user agent MAY ignore unexpected 1xx status responses. | user agent MAY ignore unexpected 1xx responses. | |||
Proxies MUST forward 1xx responses, unless the connection between the | A proxy MUST forward 1xx responses unless the proxy itself requested | |||
proxy and its client has been closed, or unless the proxy itself | the generation of the 1xx response. For example, if a proxy adds an | |||
requested the generation of the 1xx response. For example, if a | "Expect: 100-continue" field when it forwards a request, then it need | |||
proxy adds an "Expect: 100-continue" field when it forwards a | not forward the corresponding 100 (Continue) response(s). | |||
request, then it need not forward the corresponding 100 (Continue) | ||||
response(s). | ||||
6.2.1. 100 Continue | 6.2.1. 100 Continue | |||
The 100 (Continue) status code indicates that the initial part of a | The 100 (Continue) status code indicates that the initial part of a | |||
request has been received and has not yet been rejected by the | request has been received and has not yet been rejected by the | |||
server. The server intends to send a final response after the | server. The server intends to send a final response after the | |||
request has been fully received and acted upon. | request has been fully received and acted upon. | |||
When the request contains an Expect header field that includes a 100- | When the request contains an Expect header field that includes a 100- | |||
continue expectation, the 100 response indicates that the server | continue expectation, the 100 response indicates that the server | |||
wishes to receive the request payload body, as described in | wishes to receive the request payload body, as described in | |||
Section 5.1.1.1. The client ought to continue sending the request | Section 5.1.1. The client ought to continue sending the request and | |||
and discard the 100 response. | discard the 100 response. | |||
If the request did not contain an Expect header field containing the | If the request did not contain an Expect header field containing the | |||
100-continue expectation, the client can simply discard this interim | 100-continue expectation, the client can simply discard this interim | |||
response. | response. | |||
6.2.2. 101 Switching Protocols | 6.2.2. 101 Switching Protocols | |||
The 101 (Switching Protocols) status code indicates that the server | The 101 (Switching Protocols) status code indicates that the server | |||
understands and is willing to comply with the client's request, via | understands and is willing to comply with the client's request, via | |||
the Upgrade header field (Section 6.7 of [Part1]), for a change in | the Upgrade header field (Section 6.7 of [Part1]), for a change in | |||
skipping to change at page 51, line 5 | skipping to change at page 51, line 45 | |||
OPTIONS a representation of the communications options; | OPTIONS a representation of the communications options; | |||
TRACE a representation of the request message as received by the end | TRACE a representation of the request message as received by the end | |||
server. | server. | |||
Aside from responses to CONNECT, a 200 response always has a payload, | Aside from responses to CONNECT, a 200 response always has a payload, | |||
though an origin server MAY generate a payload body of zero length. | though an origin server MAY generate a payload body of zero length. | |||
If no payload is desired, an origin server ought to send 204 (No | If no payload is desired, an origin server ought to send 204 (No | |||
Content) instead. For CONNECT, no payload is allowed because the | Content) instead. For CONNECT, no payload is allowed because the | |||
successful result is a tunnel, which begins immediately after the 200 | successful result is a tunnel, which begins immediately after the 200 | |||
response header block. | response header section. | |||
A 200 response is cacheable unless otherwise indicated by the method | A 200 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.3.2. 201 Created | 6.3.2. 201 Created | |||
The 201 (Created) status code indicates that the request has been | The 201 (Created) status code indicates that the request has been | |||
fulfilled and has resulted in one or more new resources being | fulfilled and has resulted in one or more new resources being | |||
created. The primary resource created by the request is identified | created. The primary resource created by the request is identified | |||
by either a Location header field in the response or, if no Location | by either a Location header field in the response or, if no Location | |||
field is received, by the effective request URI. | field is received, by the effective request URI. | |||
The 201 response payload typically describes and links to the | The 201 response payload typically describes and links to the | |||
skipping to change at page 52, line 6 | skipping to change at page 52, line 49 | |||
the request was successful but the enclosed payload has been modified | the request was successful but the enclosed payload has been modified | |||
from that of the origin server's 200 (OK) response by a transforming | from that of the origin server's 200 (OK) response by a transforming | |||
proxy (Section 5.7.2 of [Part1]). This status code allows the proxy | proxy (Section 5.7.2 of [Part1]). This status code allows the proxy | |||
to notify recipients when a transformation has been applied, since | to notify recipients when a transformation has been applied, since | |||
that knowledge might impact later decisions regarding the content. | that knowledge might impact later decisions regarding the content. | |||
For example, future cache validation requests for the content might | For example, future cache validation requests for the content might | |||
only be applicable along the same request path (through the same | only be applicable along the same request path (through the same | |||
proxies). | proxies). | |||
The 203 response is similar to the Warning code of 214 Transformation | The 203 response is similar to the Warning code of 214 Transformation | |||
Applied (Section 7.5 of [Part6]), which has the advantage of being | Applied (Section 5.5 of [Part6]), which has the advantage of being | |||
applicable to responses with any status code. | applicable to responses with any status code. | |||
A 203 response is cacheable unless otherwise indicated by the method | A 203 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.3.5. 204 No Content | 6.3.5. 204 No Content | |||
The 204 (No Content) status code indicates that the server has | The 204 (No Content) status code indicates that the server has | |||
successfully fulfilled the request and that there is no additional | successfully fulfilled the request and that there is no additional | |||
content to send in the response payload body. Metadata in the | content to send in the response payload body. Metadata in the | |||
response header fields refer to the target resource and its selected | response header fields refer to the target resource and its selected | |||
representation after the requested action was applied. | representation after the requested action was applied. | |||
For example, if a 204 status code is received in response to a PUT | For example, if a 204 status code is received in response to a PUT | |||
skipping to change at page 52, line 43 | skipping to change at page 53, line 37 | |||
For example, a 204 status code is commonly used with document editing | For example, a 204 status code is commonly used with document editing | |||
interfaces corresponding to a "save" action, such that the document | interfaces corresponding to a "save" action, such that the document | |||
being saved remains available to the user for editing. It is also | being saved remains available to the user for editing. It is also | |||
frequently used with interfaces that expect automated data transfers | frequently used with interfaces that expect automated data transfers | |||
to be prevalent, such as within distributed version control systems. | to be prevalent, such as within distributed version control systems. | |||
A 204 response is terminated by the first empty line after the header | A 204 response is terminated by the first empty line after the header | |||
fields because it cannot contain a message body. | fields because it cannot contain a message body. | |||
A 204 response is cacheable unless otherwise indicated by the method | A 204 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.3.6. 205 Reset Content | 6.3.6. 205 Reset Content | |||
The 205 (Reset Content) status code indicates that the server has | The 205 (Reset Content) status code indicates that the server has | |||
fulfilled the request and desires that the user agent reset the | fulfilled the request and desires that the user agent reset the | |||
"document view", which caused the request to be sent, to its original | "document view", which caused the request to be sent, to its original | |||
state as received from the origin server. | state as received from the origin server. | |||
This response is intended to support a common data entry use case | This response is intended to support a common data entry use case | |||
where the user receives content that supports data entry (a form, | where the user receives content that supports data entry (a form, | |||
notepad, canvas, etc.), enters or manipulates data in that space, | notepad, canvas, etc.), enters or manipulates data in that space, | |||
causes the entered data to be submitted in a request, and then the | causes the entered data to be submitted in a request, and then the | |||
data entry mechanism is reset for the next entry so that the user can | data entry mechanism is reset for the next entry so that the user can | |||
easily initiate another input action. | easily initiate another input action. | |||
Since the 205 status code implies that no additional content will be | Since the 205 status code implies that no additional content will be | |||
provided in the payload, the server MUST send a message body of zero | provided, a server MUST NOT generate a payload in a 205 response. In | |||
length. In other words, the server MUST send a "Content-Length: 0" | other words, a server MUST do one of the following for a 205 | |||
field in a 205 response or close the connection immediately after | response: a) indicate a zero-length body for the response by | |||
sending the blank line terminating the header section. | including a Content-Length header field with a value of 0; b) | |||
indicate a zero-length payload for the response by including a | ||||
Transfer-Encoding header field with a value of chunked and a message | ||||
body consisting of a single chunk of zero-length; or, c) close the | ||||
connection immediately after sending the blank line terminating the | ||||
header section. | ||||
6.4. Redirection 3xx | 6.4. Redirection 3xx | |||
The 3xx (Redirection) class of status code indicates that further | The 3xx (Redirection) class of status code indicates that further | |||
action needs to be taken by the user agent in order to fulfill the | action needs to be taken by the user agent in order to fulfill the | |||
request. If a Location header field (Section 7.1.2) is provided, the | request. If a Location header field (Section 7.1.2) is provided, the | |||
user agent MAY automatically redirect its request to the URI | user agent MAY automatically redirect its request to the URI | |||
referenced by the Location field value, even if the specific status | referenced by the Location field value, even if the specific status | |||
code is not understood. Automatic redirection needs to done with | code is not understood. Automatic redirection needs to done with | |||
care for methods not known to be safe, as defined in Section 4.2.1, | care for methods not known to be safe, as defined in Section 4.2.1, | |||
skipping to change at page 54, line 12 | skipping to change at page 55, line 11 | |||
originally defined the former semantics for 301 and 302 (to match | originally defined the former semantics for 301 and 302 (to match | |||
its original implementation at CERN), and defined 303 (See Other) | its original implementation at CERN), and defined 303 (See Other) | |||
to match the latter semantics, prevailing practice gradually | to match the latter semantics, prevailing practice gradually | |||
converged on the latter semantics for 301 and 302 as well. The | converged on the latter semantics for 301 and 302 as well. The | |||
first revision of HTTP/1.1 added 307 (Temporary Redirect) to | first revision of HTTP/1.1 added 307 (Temporary Redirect) to | |||
indicate the former semantics without being impacted by divergent | indicate the former semantics without being impacted by divergent | |||
practice. Over 10 years later, most user agents still do method | practice. Over 10 years later, most user agents still do method | |||
rewriting for 301 and 302; therefore, this specification makes | rewriting for 301 and 302; therefore, this specification makes | |||
that behavior conformant when the original request is POST. | that behavior conformant when the original request is POST. | |||
Clients SHOULD detect and intervene in cyclical redirections (i.e., | A client SHOULD detect and intervene in cyclical redirections (i.e., | |||
"infinite" redirection loops). | "infinite" redirection loops). | |||
Note: An earlier version of this specification recommended a | Note: An earlier version of this specification recommended a | |||
maximum of five redirections ([RFC2068], Section 10.3). Content | maximum of five redirections ([RFC2068], Section 10.3). Content | |||
developers need to be aware that some clients might implement such | developers need to be aware that some clients might implement such | |||
a fixed limitation. | a fixed limitation. | |||
6.4.1. 300 Multiple Choices | 6.4.1. 300 Multiple Choices | |||
The 300 (Multiple Choices) status code indicates that the target | The 300 (Multiple Choices) status code indicates that the target | |||
skipping to change at page 54, line 45 | skipping to change at page 55, line 44 | |||
For request methods other than HEAD, the server SHOULD generate a | For request methods other than HEAD, the server SHOULD generate a | |||
payload in the 300 response containing a list of representation | payload in the 300 response containing a list of representation | |||
metadata and URI reference(s) from which the user or user agent can | metadata and URI reference(s) from which the user or user agent can | |||
choose the one most preferred. The user agent MAY make a selection | choose the one most preferred. The user agent MAY make a selection | |||
from that list automatically, depending upon the list format, but | from that list automatically, depending upon the list format, but | |||
this specification does not define a standard for such automatic | this specification does not define a standard for such automatic | |||
selection. | selection. | |||
A 300 response is cacheable unless otherwise indicated by the method | A 300 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
Note: The original proposal for 300 defined the URI header field | Note: The original proposal for 300 defined the URI header field | |||
as providing a list of alternative representations, such that it | as providing a list of alternative representations, such that it | |||
would be usable for 200, 300, and 406 responses and be transferred | would be usable for 200, 300, and 406 responses and be transferred | |||
in responses to the HEAD method. However, lack of deployment and | in responses to the HEAD method. However, lack of deployment and | |||
disagreement over syntax led to both URI and Alternates (a | disagreement over syntax led to both URI and Alternates (a | |||
subsequent proposal) being dropped from this specification. It is | subsequent proposal) being dropped from this specification. It is | |||
possible to communicate the list using a set of Link header fields | possible to communicate the list using a set of Link header fields | |||
[RFC5988], each with a relationship of "alternate", though | [RFC5988], each with a relationship of "alternate", though | |||
deployment is a chicken-and-egg problem. | deployment is a chicken-and-egg problem. | |||
skipping to change at page 55, line 24 | skipping to change at page 56, line 23 | |||
Clients with link editing capabilities ought to automatically re-link | Clients with link editing capabilities ought to automatically re-link | |||
references to the effective request URI to one or more of the new | references to the effective request URI to one or more of the new | |||
references sent by the server, where possible. | references sent by the server, where possible. | |||
The server SHOULD generate a Location header field in the response | The server SHOULD generate a Location header field in the response | |||
containing a preferred URI reference for the new permanent URI. The | containing a preferred URI reference for the new permanent URI. The | |||
user agent MAY use the Location field value for automatic | user agent MAY use the Location field value for automatic | |||
redirection. The server's response payload usually contains a short | redirection. The server's response payload usually contains a short | |||
hypertext note with a hyperlink to the new URI(s). | hypertext note with a hyperlink to the new URI(s). | |||
Note: For historic reasons, user agents MAY change the request | Note: For historic reasons, a user agent MAY change the request | |||
method from POST to GET for the subsequent request. If this | method from POST to GET for the subsequent request. If this | |||
behavior is undesired, status code 307 (Temporary Redirect) can be | behavior is undesired, the 307 (Temporary Redirect) status code | |||
used instead. | can be used instead. | |||
A 301 response is cacheable unless otherwise indicated by the method | A 301 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.4.3. 302 Found | 6.4.3. 302 Found | |||
The 302 (Found) status code indicates that the target resource | The 302 (Found) status code indicates that the target resource | |||
resides temporarily under a different URI. Since the redirection | resides temporarily under a different URI. Since the redirection | |||
might be altered on occasion, the client ought to continue to use the | might be altered on occasion, the client ought to continue to use the | |||
effective request URI for future requests. | effective request URI for future requests. | |||
The server SHOULD generate a Location header field in the response | The server SHOULD generate a Location header field in the response | |||
containing a URI reference for the different URI. The user agent MAY | containing a URI reference for the different URI. The user agent MAY | |||
use the Location field value for automatic redirection. The server's | use the Location field value for automatic redirection. The server's | |||
response payload usually contains a short hypertext note with a | response payload usually contains a short hypertext note with a | |||
hyperlink to the different URI(s). | hyperlink to the different URI(s). | |||
Note: For historic reasons, user agents MAY change the request | Note: For historic reasons, a user agent MAY change the request | |||
method from POST to GET for the subsequent request. If this | method from POST to GET for the subsequent request. If this | |||
behavior is undesired, status code 307 (Temporary Redirect) can be | behavior is undesired, the 307 (Temporary Redirect) status code | |||
used instead. | can be used instead. | |||
6.4.4. 303 See Other | 6.4.4. 303 See Other | |||
The 303 (See Other) status code indicates that the server is | The 303 (See Other) status code indicates that the server is | |||
redirecting the user agent to a different resource, as indicated by a | redirecting the user agent to a different resource, as indicated by a | |||
URI in the Location header field, that is intended to provide an | URI in the Location header field, that is intended to provide an | |||
indirect response to the original request. In order to satisfy the | indirect response to the original request. In order to satisfy the | |||
original request, a user agent ought to perform a retrieval request | original request, a user agent ought to perform a retrieval request | |||
using the Location URI (a GET or HEAD request if using HTTP), which | using the Location URI (a GET or HEAD request if using HTTP), which | |||
can itself be redirected further, and present the eventual result as | can itself be redirected further, and present the eventual result as | |||
skipping to change at page 57, line 38 | skipping to change at page 58, line 38 | |||
The 4xx (Client Error) class of status code indicates that the client | The 4xx (Client Error) class of status code indicates that the client | |||
seems to have erred. Except when responding to a HEAD request, the | seems to have erred. Except when responding to a HEAD request, the | |||
server SHOULD send a representation containing an explanation of the | server SHOULD send a representation 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. These status codes are applicable to any request method. | condition. These status codes are applicable to any request method. | |||
User agents SHOULD display any included representation to the user. | User agents SHOULD display any included representation to the user. | |||
6.5.1. 400 Bad Request | 6.5.1. 400 Bad Request | |||
The 400 (Bad Request) status code indicates that the server cannot or | The 400 (Bad Request) status code indicates that the server cannot or | |||
will not process the request because the received syntax is invalid, | will not process the request due to something which is perceived to | |||
nonsensical, or exceeds some limitation on what the server is willing | be a client error (e.g., malformed request syntax, invalid request | |||
to process. | message framing, or deceptive request routing). | |||
6.5.2. 402 Payment Required | 6.5.2. 402 Payment Required | |||
The 402 (Payment Required) status code is reserved for future use. | The 402 (Payment Required) status code is reserved for future use. | |||
6.5.3. 403 Forbidden | 6.5.3. 403 Forbidden | |||
The 403 (Forbidden) status code indicates that the server understood | The 403 (Forbidden) status code indicates that the server understood | |||
the request but refuses to authorize it. A server that wishes to | the request but refuses to authorize it. A server that wishes to | |||
make public why the request has been forbidden can describe that | make public why the request has been forbidden can describe that | |||
reason in the response payload (if any). | reason in the response payload (if any). | |||
If authentication credentials were provided in the request, the | If authentication credentials were provided in the request, the | |||
server considers them insufficient to grant access. The client | server considers them insufficient to grant access. The client | |||
SHOULD NOT repeat the request with the same credentials. The client | SHOULD NOT automatically repeat the request with the same | |||
MAY repeat the request with new or different credentials. However, a | credentials. The client MAY repeat the request with new or different | |||
request might be forbidden for reasons unrelated to the credentials. | credentials. However, a request might be forbidden for reasons | |||
unrelated to the credentials. | ||||
An origin server that wishes to "hide" the current existence of a | An origin server that wishes to "hide" the current existence of a | |||
forbidden target resource MAY instead respond with a status code of | forbidden target resource MAY instead respond with a status code of | |||
404 (Not Found). | 404 (Not Found). | |||
6.5.4. 404 Not Found | 6.5.4. 404 Not Found | |||
The 404 (Not Found) status code indicates that the origin server did | The 404 (Not Found) status code indicates that the origin server did | |||
not find a current representation for the target resource or is not | not find a current representation for the target resource or is not | |||
willing to disclose that one exists. A 404 status does not indicate | willing to disclose that one exists. A 404 status code does not | |||
whether this lack of representation is temporary or permanent; the | indicate whether this lack of representation is temporary or | |||
410 (Gone) status code is preferred over 404 if the origin server | permanent; the 410 (Gone) status code is preferred over 404 if the | |||
knows, presumably through some configurable means, that the condition | origin server knows, presumably through some configurable means, that | |||
is likely to be permanent. | the condition is likely to be permanent. | |||
A 404 response is cacheable unless otherwise indicated by the method | A 404 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.5.5. 405 Method Not Allowed | 6.5.5. 405 Method Not Allowed | |||
The 405 (Method Not Allowed) status code indicates that the method | The 405 (Method Not Allowed) status code indicates that the method | |||
specified in the request-line is known by the origin server but not | received in the request-line is known by the origin server but not | |||
supported by the target resource. The origin server MUST generate an | supported by the target resource. The origin server MUST generate an | |||
Allow header field in a 405 response containing a list of the target | Allow header field in a 405 response containing a list of the target | |||
resource's currently supported methods. | resource's currently supported methods. | |||
A 405 response is cacheable unless otherwise indicated by the method | A 405 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.5.6. 406 Not Acceptable | 6.5.6. 406 Not Acceptable | |||
The 406 (Not Acceptable) status code indicates that the target | The 406 (Not Acceptable) status code indicates that the target | |||
resource does not have a current representation that would be | resource does not have a current representation that would be | |||
acceptable to the user agent, according to the proactive negotiation | acceptable to the user agent, according to the proactive negotiation | |||
header fields received in the request (Section 5.3), and the server | header fields received in the request (Section 5.3), and the server | |||
is unwilling to supply a default representation. | is unwilling to supply a default representation. | |||
The server SHOULD generate a payload containing a list of available | The server SHOULD generate a payload containing a list of available | |||
skipping to change at page 59, line 19 | skipping to change at page 60, line 20 | |||
not receive a complete request message within the time that it was | not receive a complete request message within the time that it was | |||
prepared to wait. A server SHOULD send the close connection option | prepared to wait. A server SHOULD send the close connection option | |||
(Section 6.1 of [Part1]) in the response, since 408 implies that the | (Section 6.1 of [Part1]) in the response, since 408 implies that the | |||
server has decided to close the connection rather than continue | server has decided to close the connection rather than continue | |||
waiting. If the client has an outstanding request in transit, the | waiting. If the client has an outstanding request in transit, the | |||
client MAY repeat that request on a new connection. | client MAY repeat that request on a new connection. | |||
6.5.8. 409 Conflict | 6.5.8. 409 Conflict | |||
The 409 (Conflict) status code indicates that the request could not | The 409 (Conflict) status code indicates that the request could not | |||
be completed due to a conflict with the current state of the | be completed due to a conflict with the current state of the target | |||
resource. This code is used in situations where the user might be | resource. This code is used in situations where the user might be | |||
able to resolve the conflict and resubmit the request. The server | able to resolve the conflict and resubmit the request. The server | |||
SHOULD generate a payload that includes enough information for a user | SHOULD generate a payload that includes enough information for a user | |||
to recognize the source of the conflict. | to recognize the source of the conflict. | |||
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 representation being | example, if versioning were being used and the representation being | |||
PUT included changes to a resource that conflict with those made by | PUT included changes to a resource that conflict with those made by | |||
an earlier (third-party) request, the origin server might use a 409 | an earlier (third-party) request, the origin server might use a 409 | |||
response to indicate that it can't complete the request. In this | response to indicate that it can't complete the request. In this | |||
skipping to change at page 60, line 6 | skipping to change at page 61, line 6 | |||
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 associated with the origin server's site. It | individuals no longer associated with the origin server's site. It | |||
is not necessary to mark all permanently unavailable resources as | is not necessary to mark all permanently unavailable resources as | |||
"gone" or to keep the mark for any length of time -- that is left to | "gone" or to keep the mark for any length of time -- that is left to | |||
the discretion of the server owner. | the discretion of the server owner. | |||
A 410 response is cacheable unless otherwise indicated by the method | A 410 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.5.10. 411 Length Required | 6.5.10. 411 Length Required | |||
The 411 (Length Required) status code indicates that the server | The 411 (Length Required) status code indicates that the server | |||
refuses to accept the request without a defined Content-Length | refuses to accept the request without a defined Content-Length | |||
(Section 3.3.2 of [Part1]). The client MAY repeat the request if it | (Section 3.3.2 of [Part1]). The client MAY repeat the request if it | |||
adds a valid Content-Length header field containing the length of the | adds a valid Content-Length header field containing the length of the | |||
message body in the request message. | message body in the request message. | |||
6.5.11. 413 Payload Too Large | 6.5.11. 413 Payload Too Large | |||
skipping to change at page 60, line 40 | skipping to change at page 61, line 40 | |||
refusing to service the request because the request-target (Section | refusing to service the request because the request-target (Section | |||
5.3 of [Part1]) is longer than the server is willing to interpret. | 5.3 of [Part1]) is longer than the server is willing to interpret. | |||
This rare condition is only likely to occur when a client has | This rare condition is only likely to occur when a client has | |||
improperly converted a POST request to a GET request with long query | improperly converted a POST request to a GET request with long query | |||
information, when the client has descended into a "black hole" of | information, when the client has descended into a "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 potential security holes. | exploit potential security holes. | |||
A 414 response is cacheable unless otherwise indicated by the method | A 414 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.5.13. 415 Unsupported Media Type | 6.5.13. 415 Unsupported Media Type | |||
The 415 (Unsupported Media Type) status code indicates that the | The 415 (Unsupported Media Type) status code indicates that the | |||
origin server is refusing to service the request because the payload | origin server is refusing to service the request because the payload | |||
is in a format not supported by the target resource for this method. | is in a format not supported by this method on the target resource. | |||
The format problem might be due to the request's indicated Content- | The format problem might be due to the request's indicated Content- | |||
Type or Content-Encoding, or as a result of inspecting the data | Type or Content-Encoding, or as a result of inspecting the data | |||
directly. | directly. | |||
6.5.14. 417 Expectation Failed | 6.5.14. 417 Expectation Failed | |||
The 417 (Expectation Failed) status code indicates that the | The 417 (Expectation Failed) status code indicates that the | |||
expectation given in the request's Expect header field | expectation given in the request's Expect header field | |||
(Section 5.1.1) could not be met by at least one of the inbound | (Section 5.1.1) could not be met by at least one of the inbound | |||
servers. | servers. | |||
skipping to change at page 61, line 38 | skipping to change at page 62, line 38 | |||
This service requires use of the HTTP/3.0 protocol. | This service requires use of the HTTP/3.0 protocol. | |||
6.6. Server Error 5xx | 6.6. Server Error 5xx | |||
The 5xx (Server Error) class of status code indicates that the server | The 5xx (Server Error) class of status code indicates that the server | |||
is aware that it has erred or is incapable of performing the | is aware that it has erred or is incapable of performing the | |||
requested method. Except when responding to a HEAD request, the | requested method. Except when responding to a HEAD request, the | |||
server SHOULD send a representation containing an explanation of the | server SHOULD send a representation 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 representation to | condition. A user agent SHOULD display any included representation | |||
the user. These response codes are applicable to any request method. | to the user. These response codes are applicable to any request | |||
method. | ||||
6.6.1. 500 Internal Server Error | 6.6.1. 500 Internal Server Error | |||
The 500 (Internal Server Error) status code indicates that the server | The 500 (Internal Server Error) status code indicates that the server | |||
encountered an unexpected condition that prevented it from fulfilling | encountered an unexpected condition that prevented it from fulfilling | |||
the request. | the request. | |||
6.6.2. 501 Not Implemented | 6.6.2. 501 Not Implemented | |||
The 501 (Not Implemented) status code indicates that the server does | The 501 (Not Implemented) status code indicates that the server does | |||
not support the functionality required to fulfill the request. This | not support the functionality required to fulfill the request. This | |||
is the appropriate response when the server does not recognize the | is the appropriate response when the server does not recognize the | |||
request method and is not capable of supporting it for any resource. | request method and is not capable of supporting it for any resource. | |||
A 501 response is cacheable unless otherwise indicated by the method | A 501 response is cacheable unless otherwise indicated by the method | |||
definition or explicit cache controls (see Section 4.1.2 of [Part6]). | definition or explicit cache controls (see Section 4.2.2 of [Part6]). | |||
6.6.3. 502 Bad Gateway | 6.6.3. 502 Bad Gateway | |||
The 502 (Bad Gateway) status code indicates that the server, while | The 502 (Bad Gateway) status code indicates that the server, while | |||
acting as a gateway or proxy, received an invalid response from an | acting as a gateway or proxy, received an invalid response from an | |||
inbound server it accessed while attempting to fulfill the request. | inbound server it accessed while attempting to fulfill the request. | |||
6.6.4. 503 Service Unavailable | 6.6.4. 503 Service Unavailable | |||
The 503 (Service Unavailable) status code indicates that the server | The 503 (Service Unavailable) status code indicates that the server | |||
skipping to change at page 63, line 18 | skipping to change at page 64, line 19 | |||
7.1. Control Data | 7.1. Control Data | |||
Response header fields can supply control data that supplements the | Response header fields can supply control data that supplements the | |||
status code, directs caching, or instructs the client where to go | status code, directs caching, or instructs the client where to go | |||
next. | next. | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
| Header Field Name | Defined in... | | | Header Field Name | Defined in... | | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
| Age | Section 7.1 of [Part6] | | | Age | Section 5.1 of [Part6] | | |||
| Cache-Control | Section 7.2 of [Part6] | | | Cache-Control | Section 5.2 of [Part6] | | |||
| Expires | Section 7.3 of [Part6] | | | Expires | Section 5.3 of [Part6] | | |||
| Date | Section 7.1.1.2 | | | Date | Section 7.1.1.2 | | |||
| Location | Section 7.1.2 | | | Location | Section 7.1.2 | | |||
| Retry-After | Section 7.1.3 | | | Retry-After | Section 7.1.3 | | |||
| Vary | Section 7.1.4 | | | Vary | Section 7.1.4 | | |||
| Warning | Section 7.5 of [Part6] | | | Warning | Section 5.5 of [Part6] | | |||
+-------------------+------------------------+ | +-------------------+------------------------+ | |||
7.1.1. Origination Date | 7.1.1. Origination Date | |||
7.1.1.1. Date/Time Formats | 7.1.1.1. Date/Time Formats | |||
Prior to 1995, there were three different formats commonly used by | Prior to 1995, there were three different formats commonly used by | |||
servers to communicate timestamps. For compatibility with old | servers to communicate timestamps. For compatibility with old | |||
implementations, all three are defined here. The preferred format is | implementations, all three are defined here. The preferred format is | |||
a fixed-length and single-zone subset of the date and time | a fixed-length and single-zone subset of the date and time | |||
skipping to change at page 63, line 50 | skipping to change at page 64, line 51 | |||
An example of the preferred format is | An example of the preferred format is | |||
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate | Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate | |||
Examples of the two obsolete formats are | Examples of the two obsolete formats are | |||
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format | |||
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format | |||
A recipient that parses a timestamp value in an HTTP header field | A recipient that parses a timestamp value in an HTTP header field | |||
MUST accept all three formats. A sender MUST generate the IMF- | MUST accept all three HTTP-date formats. When a sender generates a | |||
fixdate format when sending an HTTP-date value in a header field. | header field that contains one or more timestamps defined as HTTP- | |||
date, the sender MUST generate those timestamps in the IMF-fixdate | ||||
format. | ||||
An HTTP-date value represents time as an instance of Coordinated | An HTTP-date value represents time as an instance of Coordinated | |||
Universal Time (UTC). The first two formats indicate UTC by the | Universal Time (UTC). The first two formats indicate UTC by the | |||
three-letter abbreviation for Greenwich Mean Time, "GMT", a | three-letter abbreviation for Greenwich Mean Time, "GMT", a | |||
predecessor of the UTC name; values in the asctime format are assumed | predecessor of the UTC name; values in the asctime format are assumed | |||
to be in UTC. A sender that generates HTTP-date values from a local | to be in UTC. A sender that generates HTTP-date values from a local | |||
clock ought to use NTP ([RFC1305]) or some similar protocol to | clock ought to use NTP ([RFC1305]) or some similar protocol to | |||
synchronize its clock to UTC. | synchronize its clock to UTC. | |||
Preferred format: | Preferred format: | |||
skipping to change at page 65, line 32 | skipping to change at page 67, line 27 | |||
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) | |||
; e.g., Jun 2 | ; e.g., Jun 2 | |||
HTTP-date is case sensitive. A sender MUST NOT generate additional | HTTP-date is case sensitive. A sender MUST NOT generate additional | |||
whitespace in an HTTP-date beyond that specifically included as SP in | whitespace in an HTTP-date beyond that specifically included as SP in | |||
the grammar. The semantics of day-name, day, month, year, and time- | the grammar. The semantics of day-name, day, month, year, and time- | |||
of-day are the same as those defined for the Internet Message Format | of-day are the same as those defined for the Internet Message Format | |||
constructs with the corresponding name ([RFC5322], Section 3.3). | constructs with the corresponding name ([RFC5322], Section 3.3). | |||
Recipients of a timestamp value in rfc850-date format, which uses a | Recipients of a timestamp value in rfc850-date format, which uses a | |||
two-digit year, SHOULD interpret a timestamp that appears to be more | two-digit year, MUST interpret a timestamp that appears to be more | |||
than 50 years in the future as representing the most recent year in | than 50 years in the future as representing the most recent year in | |||
the past that had the same last two digits. | the past that had the same last two digits. | |||
Recipients of timestamp values are encouraged to be robust in parsing | Recipients of timestamp values are encouraged to be robust in parsing | |||
timestamps unless otherwise restricted by the field definition. For | timestamps unless otherwise restricted by the field definition. For | |||
example, messages are occasionally forwarded over HTTP from a non- | example, messages are occasionally forwarded over HTTP from a non- | |||
HTTP source that might generate any of the date and time | HTTP source that might generate any of the date and time | |||
specifications defined by the Internet Message Format. | specifications defined by the Internet Message Format. | |||
Note: HTTP requirements for the date/time stamp format apply only | Note: HTTP requirements for the date/time stamp format apply only | |||
skipping to change at page 66, line 33 | skipping to change at page 68, line 24 | |||
An origin server MUST NOT send a Date header field if it does not | An origin server MUST NOT send a Date header field if it does not | |||
have a clock capable of providing a reasonable approximation of the | have a clock capable of providing a reasonable approximation of the | |||
current instance in Coordinated Universal Time. An origin server MAY | current instance in Coordinated Universal Time. An origin server MAY | |||
send a Date header field if the response is in the 1xx | send a Date header field if the response is in the 1xx | |||
(Informational) or 5xx (Server Error) class of status codes. An | (Informational) or 5xx (Server Error) class of status codes. An | |||
origin server MUST send a Date header field in all other cases. | origin server MUST send a Date header field in all other cases. | |||
A recipient with a clock that receives a response message without a | A recipient with a clock that receives a response message without a | |||
Date header field MUST record the time it was received and append a | Date header field MUST record the time it was received and append a | |||
corresponding Date header field to the message's header block if it | corresponding Date header field to the message's header section if it | |||
is cached or forwarded downstream. | is cached or forwarded downstream. | |||
A user agent MAY send a Date header field in a request, though | A user agent MAY send a Date header field in a request, though | |||
generally will not do so unless it is believed to convey useful | generally will not do so unless it is believed to convey useful | |||
information to the server. For example, custom applications of HTTP | information to the server. For example, custom applications of HTTP | |||
might convey a Date if the server is expected to adjust its | might convey a Date if the server is expected to adjust its | |||
interpretation of the user's request based on differences between the | interpretation of the user's request based on differences between the | |||
user agent and server clocks. | user agent and server clocks. | |||
7.1.2. Location | 7.1.2. Location | |||
skipping to change at page 67, line 13 | skipping to change at page 69, line 5 | |||
The field value consists of a single URI-reference. When it has the | The field value consists of a single URI-reference. When it has the | |||
form of a relative reference ([RFC3986], Section 4.2), the final | form of a relative reference ([RFC3986], Section 4.2), the final | |||
value is computed by resolving it against the effective request URI | value is computed by resolving it against the effective request URI | |||
([RFC3986], Section 5). | ([RFC3986], Section 5). | |||
For 201 (Created) responses, the Location value refers to the primary | For 201 (Created) responses, the Location value refers to the primary | |||
resource created by the request. For 3xx (Redirection) responses, | resource created by the request. For 3xx (Redirection) responses, | |||
the Location value refers to the preferred target resource for | the Location value refers to the preferred target resource for | |||
automatically redirecting the request. | automatically redirecting the request. | |||
When Location is provided in a 3xx (Redirection) response and the URI | If the Location value provided in a 3xx (Redirection) does not have a | |||
reference that the user agent used to generate the request target | fragment component, a user agent MUST process the redirection as if | |||
contains a fragment identifier, the user agent SHOULD process the | the value inherits the fragment component of the URI reference used | |||
redirection as if the Location field value inherits the original | to generate the request target (i.e., the redirection inherits the | |||
fragment. In other words, if the Location does not have a fragment | original reference's fragment, if any). | |||
component, the user agent SHOULD interpret the Location reference as | ||||
if it had the original reference's fragment. | ||||
For example, a GET request generated for the URI reference | For example, a GET request generated for the URI reference | |||
"http://www.example.org/~tim" might result in a 303 (See Other) | "http://www.example.org/~tim" might result in a 303 (See Other) | |||
response containing the header field: | response containing the header field: | |||
Location: /People.html#tim | Location: /People.html#tim | |||
which suggests that the user agent redirect to | which suggests that the user agent redirect to | |||
"http://www.example.org/People.html#tim" | "http://www.example.org/People.html#tim" | |||
skipping to change at page 68, line 40 | skipping to change at page 70, line 26 | |||
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. | |||
7.1.4. Vary | 7.1.4. Vary | |||
The "Vary" header field describes what parts of a request message, | The "Vary" header field in a response describes what parts of a | |||
aside from the method, the Host header field and the request target, | request message, aside from the method, Host header field, and | |||
might influence the origin server's process for selecting and | request target, might influence the origin server's process for | |||
representing the response. The value consists of either a single | selecting and representing this response. The value consists of | |||
asterisk ("*") or a list of header field names (case-insensitive). | either a single asterisk ("*") or a list of header field names (case- | |||
insensitive). | ||||
Vary = "*" / 1#field-name | Vary = "*" / 1#field-name | |||
A Vary field value of "*" signals that anything about the request | A Vary field value of "*" signals that anything about the request | |||
might play a role in selecting the response representation, possibly | might play a role in selecting the response representation, possibly | |||
including elements outside the message syntax (e.g., the client's | including elements outside the message syntax (e.g., the client's | |||
network address), and thus a recipient will not be able to determine | network address), and thus a recipient will not be able to determine | |||
whether this response is appropriate for a later request without | whether this response is appropriate for a later request without | |||
forwarding the request to the origin server. A proxy MUST NOT | forwarding the request to the origin server. A proxy MUST NOT | |||
generate a Vary field with a "*" value. | generate a Vary field with a "*" value. | |||
skipping to change at page 69, line 26 | skipping to change at page 71, line 18 | |||
indicates that the origin server might have used the request's | indicates that the origin server might have used the request's | |||
Accept-Encoding and Accept-Language fields (or lack thereof) as | Accept-Encoding and Accept-Language fields (or lack thereof) as | |||
determining factors while choosing the content for this response. | determining factors while choosing the content for this response. | |||
An origin server might send Vary with a list of fields for two | An origin server might send Vary with a list of fields for two | |||
purposes: | purposes: | |||
1. To inform cache recipients that they MUST NOT use this response | 1. To inform cache recipients that they MUST NOT use this response | |||
to satisfy a later request unless the later request has the same | to satisfy a later request unless the later request has the same | |||
values for the listed fields as the original request (Section 4.3 | values for the listed fields as the original request (Section 4.1 | |||
of [Part6]). In other words, Vary expands the cache key required | of [Part6]). In other words, Vary expands the cache key required | |||
to match a new request to the stored cache entry. | to match a new request to the stored cache entry. | |||
2. To inform user agent recipients that this response is subject to | 2. To inform user agent recipients that this response is subject to | |||
content negotiation (Section 5.3) and that a different | content negotiation (Section 5.3) and that a different | |||
representation might be sent in a subsequent request if | representation might be sent in a subsequent request if | |||
additional parameters are provided in the listed header fields | additional parameters are provided in the listed header fields | |||
(proactive negotiation). | (proactive negotiation). | |||
An origin server SHOULD send a Vary header field when its algorithm | An origin server SHOULD send a Vary header field when its algorithm | |||
for selecting a representation varies based on aspects of the request | for selecting a representation varies based on aspects of the request | |||
message other than the method and request target, unless the variance | message other than the method and request target, unless the variance | |||
cannot be crossed or the origin server has been deliberately | cannot be crossed or the origin server has been deliberately | |||
configured to prevent cache transparency. For example, there is no | configured to prevent cache transparency. For example, there is no | |||
need to send the Authorization field name in Vary because reuse | need to send the Authorization field name in Vary because reuse | |||
across users is constrained by the field definition (Section 4.1 of | across users is constrained by the field definition (Section 4.1 of | |||
[Part7]). Likewise, an origin server might use Cache-Control | [Part7]). Likewise, an origin server might use Cache-Control | |||
directives (Section 7.2 of [Part6]) to supplant Vary if it considers | directives (Section 5.2 of [Part6]) to supplant Vary if it considers | |||
the variance less significant than the performance cost of Vary's | the variance less significant than the performance cost of Vary's | |||
impact on caching. | impact on caching. | |||
7.2. Validator Header Fields | 7.2. Validator Header Fields | |||
Validator header fields convey metadata about the selected | Validator header fields convey metadata about the selected | |||
representation (Section 3). In responses to safe requests, validator | representation (Section 3). In responses to safe requests, validator | |||
fields describe the selected representation chosen by the origin | fields describe the selected representation chosen by the origin | |||
server while handling the response. Note that, depending on the | server while handling the response. Note that, depending on the | |||
status code semantics, the selected representation for a given | status code semantics, the selected representation for a given | |||
skipping to change at page 77, line 23 | skipping to change at page 78, line 23 | |||
Authors of specifications defining new fields are advised to keep the | Authors of specifications defining new fields are advised to keep the | |||
name as short as practical and to not prefix the name with "X-" | name as short as practical and to not prefix the name with "X-" | |||
unless the header field will never be used on the Internet. (The | unless the header field will never be used on the Internet. (The | |||
"x-" prefix idiom has been extensively misused in practice; it was | "x-" prefix idiom has been extensively misused in practice; it was | |||
intended to only be used as a mechanism for avoiding name collisions | intended to only be used as a mechanism for avoiding name collisions | |||
inside proprietary software or intranet processing, since the prefix | inside proprietary software or intranet processing, since the prefix | |||
would ensure that private names never collide with a newly registered | would ensure that private names never collide with a newly registered | |||
Internet name.) | Internet name.) | |||
New header field values typically have their syntax defined using | New header field values typically have their syntax defined using | |||
ABNF ([RFC5234]), using the extension defined in Appendix B of | ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] | |||
[Part1] as necessary, and are usually constrained to the range of | as necessary, and are usually constrained to the range of ASCII | |||
ASCII characters. Header fields needing a greater range of | characters. Header fields needing a greater range of characters can | |||
characters can use an encoding such as the one defined in [RFC5987]. | use an encoding such as the one defined in [RFC5987]. | |||
Leading and trailing whitespace in raw field values is removed upon | Leading and trailing whitespace in raw field values is removed upon | |||
field parsing (Section 3.2.4 of [Part1]). Field definitions where | field parsing (Section 3.2.4 of [Part1]). Field definitions where | |||
leading or trailing whitespace in values is significant will have to | leading or trailing whitespace in values is significant will have to | |||
use a container syntax such as quoted-string. | use a container syntax such as quoted-string. | |||
Because commas (",") are used as a generic delimiter between field- | Because commas (",") are used as a generic delimiter between field- | |||
values, they need to be treated with care if they are allowed in the | values, they need to be treated with care if they are allowed in the | |||
field-value. Typically, components that might contain a comma are | field-value. Typically, components that might contain a comma are | |||
protected with double-quotes using the quoted-string ABNF production | protected with double-quotes using the quoted-string ABNF production | |||
skipping to change at page 83, line 10 | skipping to change at page 84, line 10 | |||
cookies). Many general-purpose user agents (i.e., Web browsers) have | cookies). Many general-purpose user agents (i.e., Web browsers) have | |||
taken steps to reduce their fingerprints. | taken steps to reduce their fingerprints. | |||
There are a number of request header fields that might reveal | There are a number of request header fields that might reveal | |||
information to servers that is sufficiently unique to enable | information to servers that is sufficiently unique to enable | |||
fingerprinting. The From header field is the most obvious, though it | fingerprinting. The From header field is the most obvious, though it | |||
is expected that From will only be sent when self-identification is | is expected that From will only be sent when self-identification is | |||
desired by the user. Likewise, Cookie header fields are deliberately | desired by the user. Likewise, Cookie header fields are deliberately | |||
designed to enable re-identification, so we can assume that | designed to enable re-identification, so we can assume that | |||
fingerprinting concerns only apply to situations where cookies are | fingerprinting concerns only apply to situations where cookies are | |||
disabled or restricted by browser configuration. | disabled or restricted by the user agent's configuration. | |||
The User-Agent header field might contain enough information to | The User-Agent header field might contain enough information to | |||
uniquely identify a specific device, usually when combined with other | uniquely identify a specific device, usually when combined with other | |||
characteristics, particularly if the user agent sends excessive | characteristics, particularly if the user agent sends excessive | |||
details about the user's system or extensions. However, the source | details about the user's system or extensions. However, the source | |||
of unique information that is least expected by users is proactive | of unique information that is least expected by users is proactive | |||
negotiation (Section 5.3), including the Accept, Accept-Charset, | negotiation (Section 5.3), including the Accept, Accept-Charset, | |||
Accept-Encoding, and Accept-Language header fields. | Accept-Encoding, and Accept-Language header fields. | |||
In addition to the fingerprinting concern, detailed use of the | In addition to the fingerprinting concern, detailed use of the | |||
skipping to change at page 83, line 40 | skipping to change at page 84, line 40 | |||
In environments where proxies are used to enhance privacy, user | In environments where proxies are used to enhance privacy, user | |||
agents ought to be conservative in sending proactive negotiation | agents ought to be conservative in sending proactive negotiation | |||
header fields. General-purpose user agents that provide a high | header fields. General-purpose user agents that provide a high | |||
degree of header field configurability ought to inform users about | degree of header field configurability ought to inform users about | |||
the loss of privacy that might result if too much detail is provided. | the loss of privacy that might result if too much detail is provided. | |||
As an extreme privacy measure, proxies could filter the proactive | As an extreme privacy measure, proxies could filter the proactive | |||
negotiation header fields in relayed requests. | negotiation header fields in relayed requests. | |||
10. Acknowledgments | 10. Acknowledgments | |||
See Section 9 of [Part1]. | See Section 10 of [Part1]. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Message Syntax and | Transfer Protocol (HTTP/1.1): Message Syntax and | |||
Routing", draft-ietf-httpbis-p1-messaging-23 (work in | Routing", draft-ietf-httpbis-p1-messaging-24 (work in | |||
progress), July 2013. | progress), September 2013. | |||
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Conditional Requests", | Transfer Protocol (HTTP/1.1): Conditional Requests", | |||
draft-ietf-httpbis-p4-conditional-23 (work in | draft-ietf-httpbis-p4-conditional-24 (work in | |||
progress), July 2013. | progress), September 2013. | |||
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
"Hypertext Transfer Protocol (HTTP/1.1): Range | "Hypertext Transfer Protocol (HTTP/1.1): Range | |||
Requests", draft-ietf-httpbis-p5-range-23 (work in | Requests", draft-ietf-httpbis-p5-range-24 (work in | |||
progress), July 2013. | progress), September 2013. | |||
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
draft-ietf-httpbis-p6-cache-23 (work in progress), | draft-ietf-httpbis-p6-cache-24 (work in progress), | |||
July 2013. | September 2013. | |||
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Authentication", | Transfer Protocol (HTTP/1.1): Authentication", | |||
draft-ietf-httpbis-p7-auth-23 (work in progress), | draft-ietf-httpbis-p7-auth-24 (work in progress), | |||
July 2013. | September 2013. | |||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data | |||
Format Specification version 3.3", RFC 1950, May 1996. | Format Specification version 3.3", RFC 1950, May 1996. | |||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format | |||
Specification version 1.3", RFC 1951, May 1996. | Specification version 1.3", RFC 1951, May 1996. | |||
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and | |||
G. Randers-Pehrson, "GZIP file format specification | G. Randers-Pehrson, "GZIP file format specification | |||
version 4.3", RFC 1952, May 1996. | version 4.3", RFC 1952, May 1996. | |||
skipping to change at page 89, line 16 | skipping to change at page 90, line 16 | |||
that might be contained therein. | that might be contained therein. | |||
Appendix B. Changes from RFC 2616 | Appendix B. Changes from RFC 2616 | |||
The primary changes in this revision have been editorial in nature: | The primary changes in this revision have been editorial in nature: | |||
extracting the messaging syntax and partitioning HTTP semantics into | extracting the messaging syntax and partitioning HTTP semantics into | |||
separate documents for the core features, conditional requests, | separate documents for the core features, conditional requests, | |||
partial requests, caching, and authentication. The conformance | partial requests, caching, and authentication. The conformance | |||
language has been revised to clearly target requirements and the | language has been revised to clearly target requirements and the | |||
terminology has been improved to distinguish payload from | terminology has been improved to distinguish payload from | |||
representations and representations from resources. An algorithm has | representations and representations from resources. | |||
been added for determining if a payload is associated with a specific | ||||
identifier (Section 3.1.4.1). | ||||
A new requirement has been added that semantics embedded in a URI | A new requirement has been added that semantics embedded in a URI | |||
should be disabled when those semantics are inconsistent with the | should be disabled when those semantics are inconsistent with the | |||
request method, since this is a common cause of interoperability | request method, since this is a common cause of interoperability | |||
failure. | failure. (Section 2) | |||
The default charset of ISO-8859-1 for text media types has been | An algorithm has been added for determining if a payload is | |||
removed; the default is now whatever the media type definition says | associated with a specific identifier. (Section 3.1.4.1) | |||
(Section 3.1.1.3). Likewise, special treatment of ISO-8859-1 has | ||||
been removed from the Accept-Charset header field (Section 5.3.3). | ||||
The Content-Disposition header field has been removed since it is now | The default charset of ISO-8859-1 for text media types has been | |||
defined by [RFC6266]. | removed; the default is now whatever the media type definition says. | |||
Likewise, special treatment of ISO-8859-1 has been removed from the | ||||
Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) | ||||
The definition of Content-Location has been changed to no longer | The definition of Content-Location has been changed to no longer | |||
affect the base URI for resolving relative URI references, due to | affect the base URI for resolving relative URI references, due to | |||
poor implementation support and the undesirable effect of potentially | poor implementation support and the undesirable effect of potentially | |||
breaking relative links in content-negotiated resources | breaking relative links in content-negotiated resources. | |||
(Section 3.1.4.2). | (Section 3.1.4.2) | |||
The Content-MD5 header field has been removed because it was | ||||
inconsistently implemented with respect to partial responses. | ||||
To be consistent with the method-neutral parsing algorithm of | To be consistent with the method-neutral parsing algorithm of | |||
[Part1], the definition of GET has been relaxed so that requests can | [Part1], the definition of GET has been relaxed so that requests can | |||
have a body, even though a body has no meaning for GET | have a body, even though a body has no meaning for GET. | |||
(Section 4.3.1). | (Section 4.3.1) | |||
Servers are no longer required to handle all Content-* header fields | Servers are no longer required to handle all Content-* header fields | |||
and use of Content-Range has been explicitly banned in PUT requests | and use of Content-Range has been explicitly banned in PUT requests. | |||
(Section 4.3.4). | (Section 4.3.4) | |||
Definition of the CONNECT method has been moved from [RFC2817] to | Definition of the CONNECT method has been moved from [RFC2817] to | |||
this specification (Section 4.3.6). | this specification. (Section 4.3.6) | |||
The OPTIONS (Section 4.3.7) and TRACE (Section 4.3.8) request methods | ||||
have been defined as being safe. | ||||
The definition of Expect has been both fixed to allow parameters for | The OPTIONS and TRACE request methods have been defined as being | |||
value-less expectations and simplified to allow trailing semicolons | safe. (Section 4.3.7 and Section 4.3.8) | |||
after "100-continue" (Section 5.1.1). | The Expect header field's extension mechanism has been removed due to | |||
widely-deployed broken implementations. (Section 5.1.1) | ||||
The Max-Forwards header field (Section 5.1.2) has been restricted to | The Max-Forwards header field has been restricted to the OPTIONS and | |||
the OPTIONS and TRACE methods; previously, extension methods could | TRACE methods; previously, extension methods could have used it as | |||
have used it as well. | well. (Section 5.1.2) | |||
The "about:blank" URI has been suggested as a value for the Referer | The "about:blank" URI has been suggested as a value for the Referer | |||
header field when no referring URI is applicable, which distinguishes | header field when no referring URI is applicable, which distinguishes | |||
that case from others where the Referer field is not sent or has been | that case from others where the Referer field is not sent or has been | |||
removed (Section 5.5.2). | removed. (Section 5.5.2) | |||
The following status codes are now cacheable (that is, they can be | ||||
stored and reused by a cache without explicit freshness information | ||||
present): 204, 404, 405, 414, 501. (Section 6) | ||||
The 201 (Created) status description has been changed to allow for | The 201 (Created) status description has been changed to allow for | |||
the possibility that more than one resource has been created | the possibility that more than one resource has been created. | |||
(Section 6.3.2). | (Section 6.3.2) | |||
The definition of 203 (Non-Authoritative Information) has been | The definition of 203 (Non-Authoritative Information) has been | |||
broadened to include cases of payload transformations as well | broadened to include cases of payload transformations as well. | |||
(Section 6.3.4). | (Section 6.3.4) | |||
The redirect status codes 301, 302, and 307 no longer have normative | The set of request methods that are safe to automatically redirect is | |||
requirements on response payloads and user interaction (Section 6.4). | no longer closed; user agents are able to make that determination | |||
based upon the request method semantics. The redirect status codes | ||||
301, 302, and 307 no longer have normative requirements on response | ||||
payloads and user interaction. (Section 6.4) | ||||
The request methods that are safe to automatically redirect is no | The status codes 301 and 302 have been changed to allow user agents | |||
longer a closed set; user agents are able to make that determination | to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) | |||
based upon the request method semantics (Section 6.4). | ||||
The description of 303 (See Other) status code has been changed to | The description of 303 (See Other) status code has been changed to | |||
allow it to be cached if explicit freshness information is given, and | allow it to be cached if explicit freshness information is given, and | |||
a specific definition has been added for a 303 response to GET | a specific definition has been added for a 303 response to GET. | |||
(Section 6.4.4). | (Section 6.4.4) | |||
The status codes 301 and 302 (sections 6.4.2 and 6.4.3) have been | ||||
changed to allow user agents to rewrite the method from POST to GET. | ||||
The 305 (Use Proxy) status code has been deprecated due to security | The 305 (Use Proxy) status code has been deprecated due to security | |||
concerns regarding in-band configuration of a proxy (Section 6.4.5). | concerns regarding in-band configuration of a proxy. (Section 6.4.5) | |||
The 400 (Bad Request) status code has been relaxed so that it isn't | The 400 (Bad Request) status code has been relaxed so that it isn't | |||
limited to syntax errors (Section 6.5.1). | limited to syntax errors. (Section 6.5.1) | |||
The 426 (Upgrade Required) status code has been incorporated from | The 426 (Upgrade Required) status code has been incorporated from | |||
[RFC2817]. (Section 6.5.15) | ||||
[RFC2817] (Section 6.5.15). | ||||
The following status codes are now cacheable (that is, they can be | ||||
stored and reused by a cache without explicit freshness information | ||||
present): 204, 404, 405, 414, 501. | ||||
Allow has been reclassified as a response header field, removing the | ||||
option to specify it in a PUT request. Requirements relating to the | ||||
content of Allow have been relaxed; correspondingly, clients are not | ||||
required to always trust its value (Section 7.4.1). | ||||
The target of requirements on HTTP-date and the Date header field | The target of requirements on HTTP-date and the Date header field | |||
have been reduced to those systems generating the date, rather than | have been reduced to those systems generating the date, rather than | |||
all systems sending a date (Section 7.1.1). | all systems sending a date. (Section 7.1.1) | |||
The syntax of the Location header field has been changed to allow all | The syntax of the Location header field has been changed to allow all | |||
URI references, including relative references and fragments, along | URI references, including relative references and fragments, along | |||
with some clarifications as to when use of fragments would not be | with some clarifications as to when use of fragments would not be | |||
appropriate (Section 7.1.2). | appropriate. (Section 7.1.2) | |||
A Method Registry has been defined (Section 8.1). | Allow has been reclassified as a response header field, removing the | |||
option to specify it in a PUT request. Requirements relating to the | ||||
content of Allow have been relaxed; correspondingly, clients are not | ||||
required to always trust its value. (Section 7.4.1) | ||||
The Status Code Registry (Section 8.2) has been redefined by this | A Method Registry has been defined. (Section 8.1) | |||
specification; previously, it was defined in Section 7.1 of | ||||
[RFC2817]. | The Status Code Registry has been redefined by this specification; | |||
previously, it was defined in Section 7.1 of [RFC2817]. | ||||
(Section 8.2) | ||||
Registration of Content Codings has been changed to require IETF | Registration of Content Codings has been changed to require IETF | |||
Review (Section 8.4). | Review. (Section 8.4) | |||
The Content-Disposition header field has been removed since it is now | ||||
defined by [RFC6266]. | ||||
The Content-MD5 header field has been removed because it was | ||||
inconsistently implemented with respect to partial responses. | ||||
Appendix C. Imported ABNF | Appendix C. Imported ABNF | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), | |||
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double | |||
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF | quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF | |||
(line feed), OCTET (any 8-bit sequence of data), SP (space), and | (line feed), OCTET (any 8-bit sequence of data), SP (space), and | |||
VCHAR (any visible US-ASCII character). | VCHAR (any visible US-ASCII character). | |||
skipping to change at page 92, line 43 | skipping to change at page 93, line 43 | |||
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS | Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS | |||
content-coding ] ) | content-coding ] ) | |||
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS | Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS | |||
language-tag ] ) | language-tag ] ) | |||
Content-Location = absolute-URI / partial-URI | Content-Location = absolute-URI / partial-URI | |||
Content-Type = media-type | Content-Type = media-type | |||
Date = HTTP-date | Date = HTTP-date | |||
Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) | Expect = "100-continue" | |||
From = mailbox | From = mailbox | |||
GMT = %x47.4D.54 ; GMT | GMT = %x47.4D.54 ; GMT | |||
HTTP-date = IMF-fixdate / obs-date | HTTP-date = IMF-fixdate / obs-date | |||
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT | IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT | |||
Location = URI-reference | Location = URI-reference | |||
skipping to change at page 94, line 4 | skipping to change at page 95, line 4 | |||
/ %x53.61.74 ; Sat | / %x53.61.74 ; Sat | |||
/ %x53.75.6E ; Sun | / %x53.75.6E ; Sun | |||
day-name-l = %x4D.6F.6E.64.61.79 ; Monday | day-name-l = %x4D.6F.6E.64.61.79 ; Monday | |||
/ %x54.75.65.73.64.61.79 ; Tuesday | / %x54.75.65.73.64.61.79 ; Tuesday | |||
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday | |||
/ %x54.68.75.72.73.64.61.79 ; Thursday | / %x54.68.75.72.73.64.61.79 ; Thursday | |||
/ %x46.72.69.64.61.79 ; Friday | / %x46.72.69.64.61.79 ; Friday | |||
/ %x53.61.74.75.72.64.61.79 ; Saturday | / %x53.61.74.75.72.64.61.79 ; Saturday | |||
/ %x53.75.6E.64.61.79 ; Sunday | / %x53.75.6E.64.61.79 ; Sunday | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
expect-name = token | ||||
expect-param = expect-name [ BWS "=" BWS expect-value ] | ||||
expect-value = token / quoted-string | ||||
expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ | ||||
OWS expect-param ] ) | ||||
field-name = <comment, defined in [Part1], Section 3.2> | field-name = <comment, defined in [Part1], Section 3.2> | |||
hour = 2DIGIT | hour = 2DIGIT | |||
language-range = <language-range, defined in [RFC4647], Section 2.1> | language-range = <language-range, defined in [RFC4647], Section 2.1> | |||
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> | language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> | |||
mailbox = <mailbox, defined in [RFC5322], Section 3.4> | mailbox = <mailbox, defined in [RFC5322], Section 3.4> | |||
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS | media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS | |||
";" OWS parameter ) | ";" OWS parameter ) | |||
skipping to change at page 96, line 24 | skipping to change at page 97, line 18 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in | o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in | |||
header field considerations that leading/trailing WS is lossy" | header field considerations that leading/trailing WS is lossy" | |||
E.3. Since draft-ietf-httpbis-p2-semantics-22 | E.3. Since draft-ietf-httpbis-p2-semantics-22 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list | o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list | |||
expansion in ABNF appendices" | expansion in ABNF appendices" | |||
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback | o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for | |||
for Accept-Language" | Accept-Language" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a | o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a | |||
higher minor HTTP version number" | higher minor HTTP version number" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag | o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag | |||
vs. language-range" | vs. language-range" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering | o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering | |||
x-gzip and x-deflate" | x-gzip and x-deflate" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and | o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and | |||
method registrations" | method registrations" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection | o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection | |||
based upon request target" | based upon request target" | |||
E.4. Since draft-ietf-httpbis-p2-semantics-23 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response | ||||
isn't generic" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/450>: "p2 Editorial | ||||
feedback" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/452>: "Content- | ||||
Length in HEAD responses" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/458>: "Requirements | ||||
upon proxies for Expect" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/468>: "Expectation | ||||
Extensions" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/470>: "What is | ||||
'Cacheable'?" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and | ||||
other feedback" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission | ||||
of 403" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205 | ||||
allow chunked encoding?" | ||||
Index | Index | |||
1 | 1 | |||
1xx Informational (status code class) 49 | 1xx Informational (status code class) 50 | |||
2 | 2 | |||
2xx Successful (status code class) 50 | 2xx Successful (status code class) 51 | |||
3 | 3 | |||
3xx Redirection (status code class) 53 | 3xx Redirection (status code class) 54 | |||
4 | 4 | |||
4xx Client Error (status code class) 57 | 4xx Client Error (status code class) 58 | |||
5 | 5 | |||
5xx Server Error (status code class) 61 | 5xx Server Error (status code class) 62 | |||
1 | 1 | |||
100 Continue (status code) 49 | 100 Continue (status code) 50 | |||
100-continue (expect value) 33 | 100-continue (expect value) 34 | |||
101 Switching Protocols (status code) 50 | 101 Switching Protocols (status code) 50 | |||
2 | 2 | |||
200 OK (status code) 50 | 200 OK (status code) 51 | |||
201 Created (status code) 51 | 201 Created (status code) 52 | |||
202 Accepted (status code) 51 | 202 Accepted (status code) 52 | |||
203 Non-Authoritative Information (status code) 51 | 203 Non-Authoritative Information (status code) 52 | |||
204 No Content (status code) 52 | 204 No Content (status code) 53 | |||
205 Reset Content (status code) 52 | 205 Reset Content (status code) 53 | |||
3 | 3 | |||
300 Multiple Choices (status code) 54 | 300 Multiple Choices (status code) 55 | |||
301 Moved Permanently (status code) 55 | 301 Moved Permanently (status code) 56 | |||
302 Found (status code) 55 | 302 Found (status code) 56 | |||
303 See Other (status code) 56 | 303 See Other (status code) 57 | |||
305 Use Proxy (status code) 56 | 305 Use Proxy (status code) 57 | |||
306 (Unused) (status code) 56 | 306 (Unused) (status code) 57 | |||
307 Temporary Redirect (status code) 57 | 307 Temporary Redirect (status code) 58 | |||
4 | 4 | |||
400 Bad Request (status code) 57 | 400 Bad Request (status code) 58 | |||
402 Payment Required (status code) 57 | 402 Payment Required (status code) 58 | |||
403 Forbidden (status code) 57 | 403 Forbidden (status code) 58 | |||
404 Not Found (status code) 58 | 404 Not Found (status code) 59 | |||
405 Method Not Allowed (status code) 58 | 405 Method Not Allowed (status code) 59 | |||
406 Not Acceptable (status code) 58 | 406 Not Acceptable (status code) 59 | |||
408 Request Timeout (status code) 59 | 408 Request Timeout (status code) 60 | |||
409 Conflict (status code) 59 | 409 Conflict (status code) 60 | |||
410 Gone (status code) 59 | 410 Gone (status code) 60 | |||
411 Length Required (status code) 60 | 411 Length Required (status code) 61 | |||
413 Payload Too Large (status code) 60 | 413 Payload Too Large (status code) 61 | |||
414 URI Too Long (status code) 60 | 414 URI Too Long (status code) 61 | |||
415 Unsupported Media Type (status code) 60 | 415 Unsupported Media Type (status code) 61 | |||
417 Expectation Failed (status code) 61 | 417 Expectation Failed (status code) 62 | |||
426 Upgrade Required (status code) 61 | 426 Upgrade Required (status code) 62 | |||
5 | 5 | |||
500 Internal Server Error (status code) 61 | 500 Internal Server Error (status code) 62 | |||
501 Not Implemented (status code) 61 | 501 Not Implemented (status code) 62 | |||
502 Bad Gateway (status code) 62 | 502 Bad Gateway (status code) 63 | |||
503 Service Unavailable (status code) 62 | 503 Service Unavailable (status code) 63 | |||
504 Gateway Timeout (status code) 62 | 504 Gateway Timeout (status code) 63 | |||
505 HTTP Version Not Supported (status code) 62 | 505 HTTP Version Not Supported (status code) 63 | |||
A | A | |||
Accept header field 38 | Accept header field 38 | |||
Accept-Charset header field 40 | Accept-Charset header field 40 | |||
Accept-Encoding header field 41 | Accept-Encoding header field 41 | |||
Accept-Language header field 42 | Accept-Language header field 42 | |||
Allow header field 71 | Allow header field 72 | |||
C | C | |||
cacheable 23 | cacheable 24 | |||
compress (content coding) 11 | compress (content coding) 11 | |||
conditional request 36 | conditional request 36 | |||
CONNECT method 29 | CONNECT method 30 | |||
content coding 11 | content coding 11 | |||
content negotiation 6 | content negotiation 6 | |||
Content-Encoding header field 12 | Content-Encoding header field 12 | |||
Content-Language header field 13 | Content-Language header field 13 | |||
Content-Location header field 15 | Content-Location header field 15 | |||
Content-Transfer-Encoding header field 88 | Content-Transfer-Encoding header field 89 | |||
Content-Type header field 10 | Content-Type header field 10 | |||
D | D | |||
Date header field 66 | Date header field 67 | |||
deflate (content coding) 11 | deflate (content coding) 11 | |||
DELETE method 28 | DELETE method 29 | |||
E | E | |||
Expect header field 33 | Expect header field 34 | |||
Expect Values | ||||
100-continue 33 | ||||
F | F | |||
From header field 44 | From header field 44 | |||
G | G | |||
GET method 24 | GET method 24 | |||
Grammar | Grammar | |||
Accept 38 | Accept 38 | |||
Accept-Charset 40 | Accept-Charset 40 | |||
Accept-Encoding 41 | Accept-Encoding 41 | |||
accept-ext 38 | accept-ext 38 | |||
Accept-Language 42 | Accept-Language 42 | |||
accept-params 38 | accept-params 38 | |||
Allow 71 | Allow 72 | |||
asctime-date 65 | asctime-date 67 | |||
attribute 8 | attribute 8 | |||
charset 9 | charset 9 | |||
codings 41 | codings 41 | |||
content-coding 11 | content-coding 11 | |||
Content-Encoding 12 | Content-Encoding 12 | |||
Content-Language 13 | Content-Language 13 | |||
Content-Location 15 | Content-Location 15 | |||
Content-Type 10 | Content-Type 10 | |||
Date 66 | Date 67 | |||
date1 64 | date1 66 | |||
day 64 | day 66 | |||
day-name 64 | day-name 66 | |||
day-name-l 64 | day-name-l 66 | |||
delta-seconds 68 | delta-seconds 70 | |||
Expect 33 | Expect 34 | |||
expect-name 33 | ||||
expect-param 33 | ||||
expect-value 33 | ||||
expectation 33 | ||||
From 44 | From 44 | |||
GMT 64 | GMT 66 | |||
hour 64 | hour 66 | |||
HTTP-date 63 | HTTP-date 64 | |||
IMF-fixdate 64 | IMF-fixdate 66 | |||
language-range 42 | language-range 42 | |||
language-tag 13 | language-tag 13 | |||
Location 66 | Location 68 | |||
Max-Forwards 36 | Max-Forwards 36 | |||
media-range 38 | media-range 38 | |||
media-type 8 | media-type 8 | |||
method 20 | method 21 | |||
minute 64 | minute 66 | |||
month 64 | month 66 | |||
obs-date 65 | obs-date 66 | |||
parameter 8 | parameter 8 | |||
product 46 | product 46 | |||
product-version 46 | product-version 46 | |||
qvalue 37 | qvalue 38 | |||
Referer 45 | Referer 45 | |||
Retry-After 68 | Retry-After 70 | |||
rfc850-date 65 | rfc850-date 67 | |||
second 64 | second 66 | |||
Server 71 | Server 73 | |||
subtype 8 | subtype 8 | |||
time-of-day 64 | time-of-day 66 | |||
type 8 | type 8 | |||
User-Agent 46 | User-Agent 46 | |||
value 8 | value 8 | |||
Vary 68 | Vary 70 | |||
weight 37 | weight 38 | |||
year 64 | year 66 | |||
gzip (content coding) 11 | gzip (content coding) 11 | |||
H | H | |||
HEAD method 24 | HEAD method 25 | |||
I | I | |||
idempotent 23 | idempotent 23 | |||
L | L | |||
Location header field 66 | Location header field 68 | |||
M | M | |||
Max-Forwards header field 36 | Max-Forwards header field 36 | |||
MIME-Version header field 87 | MIME-Version header field 88 | |||
O | O | |||
OPTIONS method 31 | OPTIONS method 31 | |||
P | P | |||
payload 17 | payload 17 | |||
POST method 25 | POST method 25 | |||
PUT method 26 | PUT method 26 | |||
R | R | |||
Referer header field 44 | Referer header field 45 | |||
representation 7 | representation 7 | |||
Retry-After header field 68 | Retry-After header field 69 | |||
S | S | |||
safe 22 | safe 22 | |||
selected representation 7, 69 | selected representation 7, 71 | |||
Server header field 71 | Server header field 73 | |||
Status Codes Classes | Status Codes Classes | |||
1xx Informational 49 | 1xx Informational 50 | |||
2xx Successful 50 | 2xx Successful 51 | |||
3xx Redirection 53 | 3xx Redirection 54 | |||
4xx Client Error 57 | 4xx Client Error 58 | |||
5xx Server Error 61 | 5xx Server Error 62 | |||
T | T | |||
TRACE method 32 | TRACE method 32 | |||
U | U | |||
User-Agent header field 45 | User-Agent header field 46 | |||
V | V | |||
Vary header field 68 | Vary header field 70 | |||
X | X | |||
x-compress (content coding) 11 | x-compress (content coding) 11 | |||
x-gzip (content coding) 11 | x-gzip (content coding) 11 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
End of changes. 208 change blocks. | ||||
655 lines changed or deleted | 685 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |