draft-ietf-httpbis-p2-semantics-25.txt   draft-ietf-httpbis-p2-semantics-26.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 November 17, 2013 Intended status: Standards Track February 6, 2014
Expires: May 21, 2014 Expires: August 10, 2014
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-25 draft-ietf-httpbis-p2-semantics-26
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is a stateless application-
protocol for distributed, collaborative, hypertext information level 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.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
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.2. The changes in this draft are summarized in Appendix E.3.
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 May 21, 2014. This Internet-Draft will expire on August 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . 33 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . . . . . 45 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 49
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 58 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 62 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 70
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 71
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 71
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 72
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 73
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73
8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 8.1.2. Considerations for New Methods . . . . . . . . . . . . 73
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 74
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 74
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.2.2. Considerations for New Status Codes . . . . . . . . . 76 8.2.2. Considerations for New Status Codes . . . . . . . . . 75
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76
8.3.1. Considerations for New Header Fields . . . . . . . . . 78 8.3.1. Considerations for New Header Fields . . . . . . . . . 77
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81
9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 9.2. Attacks Based On Command, Code, or Query Injection . . . . 81
9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 9.3. Disclosure of Personal Information . . . . . . . . . . . . 82
9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 82
9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 82
9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 9.6. Disclosure of Product Information . . . . . . . . . . . . 83
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84
11.2. Informative References . . . . . . . . . . . . . . . . . . 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 85
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92
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) . . . . . . . . . . . . . . . . . . . . 95
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95
E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95 E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95
E.3. Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 96
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
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
skipping to change at page 6, line 47 skipping to change at page 6, line 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 a list extension, defined in Section 7 of
7 of [Part1]. Appendix C describes rules imported from other [Part1], that allows for compact definition of comma-separated lists
documents. Appendix D shows the collected ABNF with the list rule using a '#' operator (similar to how the '*' operator indicates
expanded. repetition). Appendix C describes rules imported from other
documents. Appendix D shows the collected grammar with all list
operators expanded to standard ABNF notation.
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 an 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
skipping to change at page 7, line 24 skipping to change at page 7, line 26
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]).
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 4) and a few request- semantics in the request method (Section 4) and a few request-
modifying header fields (Section 5). Resource owners SHOULD NOT modifying header fields (Section 5). If there is a conflict between
include request semantics within a URI, such as by specifying an the method semantics and any semantic implied by the URI itself, as
action to invoke within the path or query components of the effective described in Section 4.2.1, the method semantics take precedence.
request URI, unless those semantics are disabled when they are
inconsistent with the request method.
3. Representations 3. Representations
If we consider that a resource could be anything, and that the Considering that a resource could be anything, and that the uniform
uniform interface provided by HTTP is similar to a window through interface provided by HTTP is similar to a window through which one
which one can observe and act upon such a thing only through the can observe and act upon such a thing only through the communication
communication of messages to some independent actor on the other of messages to some independent actor on the other side, an
side, then we need an abstraction to represent ("take the place of") abstraction is needed to represent ("take the place of") the current
the current or desired state of that thing in our communications. We or desired state of that thing in our communications. That
call that abstraction a representation [REST]. abstraction is called a representation [REST].
For the purposes of HTTP, a "representation" is information that is For the purposes of HTTP, a "representation" is information that is
intended to reflect a past, current, or desired state of a given intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the resource, in a format that can be readily communicated via the
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or capable of generating, An origin server might be provided with, or capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. We refer to that one representation as the "selected negotiation. This "selected representation" is used to provide the
representation" and use its particular data and metadata for data and metadata for evaluating conditional requests [Part4] and
evaluating conditional requests [Part4] and constructing the payload constructing the payload for 200 (OK) and 304 (Not Modified)
for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1). responses to GET (Section 4.3.1).
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.
skipping to change at page 8, line 45 skipping to change at page 8, line 44
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.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type/subtype MAY be followed by parameters in the form of The type/subtype MAY be followed by parameters in the form of
attribute/value pairs. name=value pairs.
parameter = attribute "=" value parameter = token "=" ( token / quoted-string )
attribute = token
value = word
The type, subtype, and parameter attribute names are case- The type, subtype, and parameter name tokens are case-insensitive.
insensitive. Parameter values might or might not be case-sensitive, Parameter values might or might not be case-sensitive, depending on
depending on the semantics of the parameter name. The presence or the semantics of the parameter name. The presence or absence of a
absence of a parameter might be significant to the processing of a parameter might be significant to the processing of a media-type,
media-type, depending on its definition within the media type depending on its definition within the media type registry.
registry.
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted as either a token or within a quoted-string. The quoted transmitted as either a token or within a quoted-string. The quoted
and unquoted values are equivalent. For example, the following and unquoted values are equivalent. For example, the following
examples are all equivalent, but the first is preferred for examples are all equivalent, but the first is preferred for
consistency: consistency:
text/html;charset=utf-8 text/html;charset=utf-8
text/html;charset=UTF-8 text/html;charset=UTF-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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 one or more encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
sender that applied the encodings MUST generate a Content-Encoding sender that applied the encodings MUST generate a Content-Encoding
header field that lists the content codings in the order in which header field that lists the content codings in the order in which
they were applied. Additional information about the encoding they were applied. Additional information about the encoding
parameters MAY be provided by other header fields not defined by this parameters can be provided by other header fields not defined by this
specification. 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.
skipping to change at page 14, line 47 skipping to change at page 14, line 47
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 this specification). The information other means (not defined by this specification). The information
might still be 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 method is GET or HEAD and the response status code
(OK), 204 (No Content), 206 (Partial Content), or 304 (Not is 200 (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]).
2. If the request is GET or HEAD and the response status code is 203 2. If the request method is GET or HEAD and the response status code
(Non-Authoritative Information), the payload is a potentially is 203 (Non-Authoritative Information), the payload is a
modified or enhanced representation of the target resource as potentially modified or enhanced representation of the target
provided by an intermediary. resource as provided by an intermediary.
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
skipping to change at page 15, line 48 skipping to change at page 15, line 48
It has the same syntax and semantics as the header field of the same It has the same syntax and semantics as the header field of the same
name defined for MIME body parts in Section 4 of [RFC2557]. However, name defined for MIME body parts in Section 4 of [RFC2557]. However,
its appearance in an HTTP message has some special implications for its appearance in an HTTP message has some special implications for
HTTP recipients. HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For resource at the time indicated by the message origination date. For
a GET or HEAD request, this is the same as the default semantics when a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the
no Content-Location is provided by the server. For a state-changing same as the default semantics when no Content-Location is provided by
request like PUT or POST, it implies that the server's response the server. For a state-changing request like PUT (Section 4.3.4) or
contains the new representation of that resource, thereby POST (Section 4.3.3), it implies that the server's response contains
distinguishing it from representations that might only report about the new representation of that resource, thereby distinguishing it
the action (e.g., "It worked!"). This allows authoring applications from representations that might only report about the action (e.g.,
to update their local copies without the need for a subsequent GET "It worked!"). This allows authoring applications to update their
request. local copies without the need for a subsequent GET request.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically share the same resource owner, which cannot be programmatically
determined via HTTP. determined via HTTP.
o For a response to a GET or HEAD request, this is an indication o For a response to a GET or HEAD request, this is an indication
skipping to change at page 17, line 39 skipping to change at page 17, line 39
the message "payload". In some cases, a payload might contain only the message "payload". In some cases, a payload might contain only
the associated representation's header fields (e.g., responses to the associated representation's header fields (e.g., responses to
HEAD) or only some part(s) of the representation data (e.g., the 206 HEAD) or only some part(s) of the representation data (e.g., the 206
(Partial Content) status code). (Partial Content) status code).
The purpose of a payload in a request is defined by the method The purpose of a payload in a request is defined by the method
semantics. For example, a representation in the payload of a PUT semantics. For example, a representation in the payload of a PUT
request (Section 4.3.4) represents the desired state of the target request (Section 4.3.4) represents the desired state of the target
resource if the request is successfully applied, whereas a resource if the request is successfully applied, whereas a
representation in the payload of a POST request (Section 4.3.3) representation in the payload of a POST request (Section 4.3.3)
represents an anonymous resource for providing data to be processed, represents information to be processed by the target resource.
such as the information that a user entered within an HTML form.
In a response, the payload's purpose is defined by both the request In a response, the payload's purpose is defined by both the request
method and the response status code. For example, the payload of a method and the response status code. For example, the payload of a
200 (OK) response to GET (Section 4.3.1) represents the current state 200 (OK) response to GET (Section 4.3.1) represents the current state
of the target resource, as observed at the time of the message of the target resource, as observed at the time of the message
origination date (Section 7.1.1.2), whereas the payload of the same origination date (Section 7.1.1.2), whereas the payload of the same
status code in a response to POST might represent either the status code in a response to POST might represent either the
processing result or the new state of the target resource after processing result or the new state of the target resource after
applying the processing. Response messages with an error status code applying the processing. Response messages with an error status code
usually contain a payload that represents the error condition, such usually contain a payload that represents the error condition, such
skipping to change at page 18, line 16 skipping to change at page 18, line 15
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| Content-Length | Section 3.3.2 of [Part1] | | Content-Length | Section 3.3.2 of [Part1] |
| Content-Range | Section 4.2 of [Part5] | | Content-Range | Section 4.2 of [Part5] |
| Trailer | Section 4.4 of [Part1] |
| Transfer-Encoding | Section 3.3.1 of [Part1] | | Transfer-Encoding | Section 3.3.1 of [Part1] |
+-------------------+--------------------------+ +-------------------+--------------------------+
3.4. Content Negotiation 3.4. Content Negotiation
When responses convey payload information, whether indicating a When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of success or an error, the origin server often has different ways of
representing that information; for example, in different formats, representing that information; for example, in different formats,
languages, or encodings. Likewise, different users or user agents languages, or encodings. Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences might have differing capabilities, characteristics, or preferences
skipping to change at page 19, line 50 skipping to change at page 19, line 50
algorithms for generating responses to a request; and, algorithms for generating responses to a request; and,
o It limits the reusability of responses for shared caching. o It limits the reusability of responses for shared caching.
A user agent cannot rely on proactive negotiation preferences being A user agent cannot rely on proactive negotiation preferences being
consistently honored, since the origin server might not implement consistently honored, since the origin server might not implement
proactive negotiation for the requested resource or might decide that proactive negotiation for the requested resource or might decide that
sending a response that doesn't conform to the user agent's sending a response that doesn't conform to the user agent's
preferences is better than sending a 406 (Not Acceptable) response. preferences is better than sending a 406 (Not Acceptable) response.
An origin server MAY generate a Vary header field (Section 7.1.4) in A Vary header field (Section 7.1.4) is often sent in a response
responses that are subject to proactive negotiation to indicate what subject to proactive negotiation to indicate what parts of the
parameters of request information might be used in its selection request information were used in the selection algorithm.
algorithm, thereby providing a means for recipients to determine the
reusability of that same response for user agents with differing
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 response representation (regardless of the selection of the best response representation (regardless of the
status code) is performed by the user agent after receiving an status code) is performed by the user agent after receiving an
initial response from the origin server that contains a list of initial response from the origin server that contains a list of
resources for alternative representations. If the user agent is not resources for alternative representations. If the user agent is not
satisfied by the initial response representation, it can perform a satisfied by the initial response representation, it can perform a
GET request on one or more of the alternative resources, selected GET request on one or more of the alternative resources, selected
skipping to change at page 22, line 27 skipping to change at page 22, line 27
| | 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. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 | | TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | | | | to the target resource. | |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL; when implemented, a server MUST All other methods are OPTIONAL.
implement the above methods according to the semantics defined for
them in Section 4.3.
Additional methods, outside the scope of this specification, have Additional methods, outside the scope of this specification, have
been standardized for use in HTTP. All such methods ought to be been standardized for use in HTTP. All such methods ought to be
registered within the HTTP Method Registry maintained by IANA, as registered within the HTTP Method Registry maintained by IANA, as
defined in Section 8.1. defined in Section 8.1.
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
skipping to change at page 24, line 16 skipping to change at page 24, line 13
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement request separately, retain a revision control history, or implement
other non-idempotent side-effects for each idempotent request. other non-idempotent side-effects for each idempotent request.
Idempotent methods are distinguished because the request can be Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the repeated automatically if a communication failure occurs before the
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 the client can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request because it knows that connection and retry the idempotent request. It knows that repeating
repeating the request will have the same effect (even if the original the request will have the same intended effect, even if the original
request succeeded, though the status codes might differ in response). request succeeded, though the response might differ.
Note, however, that repeated communication failures might indicate
that the server has failed in general, or that something in the
request is triggering a connection drop.
4.2.3. Cacheable Methods 4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for responses to them are allowed to be stored for future reuse; for
specific requirements see [Part6]. In general, safe methods that do specific requirements see [Part6]. In general, safe methods that do
not depend on a current or authoritative response are defined as not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD and POST as cacheable; this specification defines GET, HEAD and POST as
cacheable, although the overwhelming majority of cache cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. implementations only support GET and HEAD.
skipping to change at page 24, line 43 skipping to change at page 24, line 37
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 file system
pathnames, and of representations as being a copy of the contents of pathnames, and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are Section 9.1 for related security considerations). However, there are
no such limitations in practice. The HTTP interface for a resource no such limitations in practice. The HTTP interface for a resource
is just as likely to be implemented as a tree of content objects, a is just as likely to be implemented as a tree of content objects, a
programmatic view on various database records, or a gateway to other programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to information systems. Even when the URI mapping mechanism is tied to
a filesystem, an origin server might be configured to execute the a file system, an origin server might be configured to execute the
files with the request as input and send the output as the files with the request as input and send the output as the
representation, rather than transfer the files directly. Regardless, representation, rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource only the origin server needs to know how each of its resource
identifiers corresponds to an implementation, and how each identifiers corresponds to an implementation, and how each
implementation manages to select and send a current representation of implementation manages to select and send a current representation of
the target resource in a response to GET. the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
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
skipping to change at page 30, line 30 skipping to change at page 30, line 24
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 4.4 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 tunnel is closed. of packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]).
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,
skipping to change at page 38, line 33 skipping to change at page 38, line 28
small set of desired types, as in the case of a request for an in- small set of desired types, as in the case of a request for an in-
line image. line image.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext ) accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" word ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
The asterisk "*" character is used to group media types into ranges, The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range can include media type subtypes of that type. The media-range can include media type
parameters that are applicable to that range. parameters that are applicable to that range.
Each media-range might be followed by zero or more applicable media Each media-range might be followed by zero or more applicable media
type parameters (e.g., charset), an optional "q" parameter for type parameters (e.g., charset), an optional "q" parameter for
indicating a relative weight (Section 5.3.1), and then zero or more indicating a relative weight (Section 5.3.1), and then zero or more
extension parameters. The "q" parameter is necessary if any extension parameters. The "q" parameter is necessary if any
skipping to change at page 41, line 6 skipping to change at page 40, line 50
matches every charset that is not mentioned elsewhere in the Accept- matches every charset that is not mentioned elsewhere in the Accept-
Charset field. If no "*" is present in an Accept-Charset field, then Charset field. If no "*" is present in an Accept-Charset field, then
any charsets not explicitly mentioned in the field are considered any charsets not explicitly mentioned in the field are considered
"not acceptable" to the client. "not acceptable" to the client.
A request without any Accept-Charset header field implies that the A request without any Accept-Charset header field implies that the
user agent will accept any charset in response. Most general-purpose user agent will accept any charset in response. Most general-purpose
user agents do not send Accept-Charset, unless specifically user agents do not send Accept-Charset, unless specifically
configured to do so, because a detailed list of supported charsets configured to do so, because a detailed list of supported charsets
makes it easier for a server to identify an individual by virtue of makes it easier for a server to identify an individual by virtue of
the user agent's request characteristics (Section 9.6). the user agent's request characteristics (Section 9.7).
If an Accept-Charset header field is present in a request and none of If an Accept-Charset header field is present in a request and none of
the available representations for the response has a charset that is the available representations for the response has a charset that is
listed as acceptable, the origin server can either honor the header listed as acceptable, the origin server can either honor the header
field, by sending a 406 (Not Acceptable) response, or disregard the field, by sending a 406 (Not Acceptable) response, or disregard the
header field by treating the resource as if it is not subject to header field by treating the resource as if it is not subject to
content negotiation. content negotiation.
5.3.4. Accept-Encoding 5.3.4. Accept-Encoding
skipping to change at page 43, line 26 skipping to change at page 43, line 22
found in Section 2.3 of [RFC4647]. found in Section 2.3 of [RFC4647].
For matching, Section 3 of [RFC4647] defines several matching For matching, Section 3 of [RFC4647] defines several matching
schemes. Implementations can offer the most appropriate matching schemes. Implementations can offer the most appropriate matching
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 9.6). preferences of the user in every request (Section 9.7).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic user agents need to allow user control over the linguistic preference
preference. A user agent that does not provide such control to the (either through configuration of the user agent itself, or by
user MUST NOT send an Accept-Language header field. defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept-
Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
language matching as described above. For example, users might language matching as described above. For example, users might
assume that on selecting "en-gb", they will be served any kind of assume that on selecting "en-gb", they will be served any kind of
English document if British English is not available. A user English document if British English is not available. A user
agent might suggest, in such a case, to add "en" to the list for agent might suggest, in such a case, to add "en" to the list for
better matching behavior. better matching behavior.
5.4. Authentication Credentials 5.4. Authentication Credentials
Two header fields are used for carrying authentication credentials, Two header fields are used for carrying authentication credentials,
as defined in [Part7]. Note that various custom mechanisms for user as defined in [Part7]. Note that various custom mechanisms for user
authentication use the Cookie header field for this purpose, as authentication use the Cookie header field for this purpose, as
defined in [RFC6265]. defined in [RFC6265].
+---------------------+------------------------+ +---------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+------------------------+ +---------------------+------------------------+
| Authorization | Section 4.1 of [Part7] | | Authorization | Section 4.2 of [Part7] |
| Proxy-Authorization | Section 4.3 of [Part7] | | Proxy-Authorization | Section 4.4 of [Part7] |
+---------------------+------------------------+ +---------------------+------------------------+
5.5. Request Context 5.5. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
skipping to change at page 45, line 43 skipping to change at page 45, line 36
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 MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in 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.4 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. An pseudonyms or truncating the query and/or path components. An
skipping to change at page 51, line 19 skipping to change at page 50, line 21
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
6.3. Successful 2xx 6.3. Successful 2xx
The 2xx (Successful) class of status code indicates that the client's The 2xx (Successful) class of status code indicates that the client's
request was successfully received, understood, and accepted. request was successfully received, understood, and accepted.
6.3.1. 200 OK 6.3.1. 200 OK
The The 200 (OK) status code indicates that the request has succeeded.
200 (OK) status code indicates that the request has succeeded. The The payload sent in a 200 response depends on the request method.
payload sent in a 200 response depends on the request method. For For the methods defined by this specification, the intended meaning
the methods defined by this specification, the intended meaning of of the payload can be summarized as:
the payload can be summarized as:
GET a representation of the target resource; GET a representation of the target resource;
HEAD the same representation as GET, but without the representation HEAD the same representation as GET, but without the representation
data; data;
POST a representation of the status of, or results obtained from, POST a representation of the status of, or results obtained from,
the action; the action;
PUT, DELETE a representation of the status of the action; PUT, DELETE a representation of the status of the action;
skipping to change at page 55, line 42 skipping to change at page 54, line 42
If the server has a preferred choice, the server SHOULD generate a If the server has a preferred choice, the server SHOULD generate a
Location header field containing a preferred choice's URI reference. Location header field containing a preferred choice's URI reference.
The user agent MAY use the Location field value for automatic The user agent MAY use the Location field value for automatic
redirection. redirection.
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 if it understands the provided media
this specification does not define a standard for such automatic type. A specific format for automatic selection is not defined by
selection. this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise A 300 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). 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
skipping to change at page 56, line 30 skipping to change at page 55, line 31
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, a user agent MAY change the request Note: For historical 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, the 307 (Temporary Redirect) status code behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead. can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise A 301 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [Part6]).
6.4.3. 302 Found 6.4.3. 302 Found
skipping to change at page 57, line 5 skipping to change at page 56, line 5
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, a user agent MAY change the request Note: For historical 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, the 307 (Temporary Redirect) status code behavior is undesired, the 307 (Temporary Redirect) status code
can be 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, which is intended to provide an
indirect response to the original request. In order to satisfy the indirect response to the original request. A user agent can perform
original request, a user agent ought to perform a retrieval request a retrieval request targeting that URI (a GET or HEAD request if
using the Location URI (a GET or HEAD request if using HTTP), which using HTTP), which might also be redirected, and present the eventual
can itself be redirected further, and present the eventual result as result as an answer to the original request. Note that the new URI
an answer to the original request. Note that the new URI in the in the Location header field is not considered equivalent to the
Location header field is not considered equivalent to the effective effective request URI.
request URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original identified, bookmarked, and cached independent of the original
request. request.
A 303 response to a GET request indicates that the origin server does A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be not have a representation of the target resource that can be
skipping to change at page 66, line 6 skipping to change at page 65, line 6
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 ([RFC5905]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone subset of the format defined in ; fixed length/zone/capitalization subset of the format
; Section 3.3 of [RFC5322] ; defined in Section 3.3 of [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive / %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive / %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive / %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive / %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive / %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive / %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year date1 = day SP month SP year
skipping to change at page 70, line 38 skipping to change at page 69, line 38
request target, might influence the origin server's process for request target, might influence the origin server's process for
selecting and representing this response. The value consists of selecting and representing this response. The value consists of
either a single asterisk ("*") or a list of header field names (case- either a single asterisk ("*") or a list of header field names (case-
insensitive). 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). A recipient will not be able to determine whether
whether this response is appropriate for a later request without this response is appropriate for a later request without forwarding
forwarding the request to the origin server. A proxy MUST NOT the request to the origin server. A proxy MUST NOT generate a Vary
generate a Vary field with a "*" value. field with a "*" value.
A Vary field value consisting of a comma-separated list of names A Vary field value consisting of a comma-separated list of names
indicates that the named request header fields, known as the indicates that the named request header fields, known as the
selecting header fields, might have a role in selecting the selecting header fields, might have a role in selecting the
representation. The potential selecting header fields are not representation. The potential selecting header fields are not
limited to those defined by this specification. limited to those defined by this specification.
For example, a response that contains For example, a response that contains
Vary: accept-encoding, accept-language Vary: accept-encoding, accept-language
skipping to change at page 71, line 34 skipping to change at page 70, line 34
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.2 of
[Part7]). Likewise, an origin server might use Cache-Control [Part7]). Likewise, an origin server might use Cache-Control
directives (Section 5.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
skipping to change at page 72, line 25 skipping to change at page 71, line 25
+-------------------+------------------------+ +-------------------+------------------------+
7.3. Authentication Challenges 7.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+------------------------+ +--------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+--------------------+------------------------+ +--------------------+------------------------+
| WWW-Authenticate | Section 4.4 of [Part7] | | WWW-Authenticate | Section 4.1 of [Part7] |
| Proxy-Authenticate | Section 4.2 of [Part7] | | Proxy-Authenticate | Section 4.3 of [Part7] |
+--------------------+------------------------+ +--------------------+------------------------+
7.4. Response Context 7.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+-------------------+------------------------+ +-------------------+------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+------------------------+
skipping to change at page 78, line 32 skipping to change at page 77, line 32
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 Section 7 of [Part1] ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1]
as necessary, and are usually constrained to the range of ASCII as necessary, and are usually constrained to the range of ASCII
characters. Header fields needing a greater range of characters can characters. Header fields needing a greater range of 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 (Section 3.2.6 of
[Part1]).
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.
(Section 3.2.6 of [Part1]).
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside double- quoted-string production; using a different syntax inside double-
skipping to change at page 80, line 10 skipping to change at page 79, line 10
o Whether it is appropriate to list the field-name in a Vary o Whether it is appropriate to list the field-name in a Vary
response header field (e.g., when the request header field is used response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see by an origin server's content selection algorithm; see
Section 7.1.4). Section 7.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 4.1 of [Part1]). Section 4.1 of [Part1]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data.
8.3.2. Registrations 8.3.2. Registrations
The Message Header Field Registry shall be updated with the following The Message Header Field Registry shall be updated with the following
permanent registrations: permanent registrations:
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 | | Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 | | Accept-Charset | http | standard | Section 5.3.3 |
skipping to change at page 81, line 35 skipping to change at page 80, line 39
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | | | | Accept-Encoding) | |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP/1.1 semantics and users of known security concerns relevant to HTTP semantics and
and its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are
discussed in Section 9 of [Part1].
The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]).
9.1. Attacks Based On File and Path Names 9.1. Attacks Based On File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Implementers need to be aware that most file representations. Implementers need to be aware that most file
systems are not designed to protect against malicious file or path systems are not designed to protect against malicious file or path
names, and thus depend on the origin server to avoid mapping to file names, and thus depend on the origin server to avoid mapping to file
names, folders, or directories that have special significance to the names, folders, or directories that have special significance to the
system. system.
skipping to change at page 82, line 14 skipping to change at page 81, line 30
an annoying tendency to prefer user-friendliness over security when an annoying tendency to prefer user-friendliness over security when
handling invalid or unexpected characters, recomposition of handling invalid or unexpected characters, recomposition of
decomposed characters, and case-normalization of case-insensitive decomposed characters, and case-normalization of case-insensitive
names. names.
Attacks based on such special names tend to focus on either denial of Attacks based on such special names tend to focus on either denial of
service (e.g., telling the server to read from a COM port) or service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
9.2. Personal Information 9.2. Attacks Based On Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain
data that might be misinterpreted as a command, code, or query when
passed through a command invocation, language interpreter, or
database interface.
For example, SQL injection is a common attack wherein additional
query language is inserted within some part of the request-target or
header fields (e.g., Host, Referer, etc.). If the received data is
used directly within a SELECT statement, the query language might be
interpreted as a database command instead of a simple string value.
This type of implementation vulnerability is extremely common, in
spite of being easy to prevent.
In general, resource implementations ought to avoid use of request
data in contexts that are processed or interpreted as instructions.
Parameters ought to be compared to fixed strings and acted upon as a
result of that comparison, rather than passed through an interface
that is not prepared for untrusted data. Received data that isn't
based on fixed parameters ought to be carefully filtered or encoded
to avoid being misinterpreted.
Similar considerations apply to request data when it is stored and
later processed, such as within log files, monitoring tools, or when
included within a data format that allows embedded scripts.
9.3. Disclosure of Personal Information
Clients are often privy to large amounts of personal information, Clients are often privy to large amounts of personal information,
including both information provided by the user to interact with including both information provided by the user to interact with
resources (e.g., the user's name, location, mail address, passwords, resources (e.g., the user's name, location, mail address, passwords,
encryption keys, etc.) and information about the user's browsing encryption keys, etc.) and information about the user's browsing
activity over time (e.g., history, bookmarks, etc.). Implementations activity over time (e.g., history, bookmarks, etc.). Implementations
need to prevent unintentional leakage of personal information. need to prevent unintentional disclosure of personal information.
9.3. Sensitive Information in URIs 9.4. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. It is therefore unwise to include
information within a URI that is sensitive, personally identifiable, information within a URI that is sensitive, personally identifiable,
or a risk to disclose. or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission Authors of services ought to avoid GET-based forms for the submission
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
skipping to change at page 82, line 46 skipping to change at page 82, line 44
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on Referer are described in Section 5.5.2 to URI. Limitations on Referer are described in Section 5.5.2 to
address some of its security considerations. address some of its security considerations.
9.4. Product Information 9.5. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new
reference in Location (Section 7.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance.
9.6. Disclosure of Product Information
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and
Server (Section 7.4.2) header fields often reveal information about Server (Section 7.4.2) header fields often reveal information about
the respective sender's software systems. In theory, this can make the respective sender's software systems. In theory, this can make
it easier for an attacker to exploit known security holes; in it easier for an attacker to exploit known security holes; in
practice, attackers tend to try all potential holes regardless of the practice, attackers tend to try all potential holes regardless of the
apparent software versions being used. apparent software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
pseudonyms. pseudonyms.
9.5. Fragment after Redirects 9.7. Browser Fingerprinting
Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new
reference in Location (Section 7.1.2), this might have the effect of
leaking one site's fragment to another site. If the first site uses
personal information in fragments, it ought to ensure that redirects
to other sites include a (possibly empty) fragment component in order
to block that inheritance.
9.6. Browser Fingerprinting
Browser fingerprinting is a set of techniques for identifying a Browser fingerprinting is a set of techniques for identifying a
specific user agent over time through its unique set of specific user agent over time through its unique set of
characteristics. These characteristics might include information characteristics. These characteristics might include information
related to its TCP behavior, feature capabilities, and scripting related to its TCP behavior, feature capabilities, and scripting
environment, though of particular interest here is the set of unique environment, though of particular interest here is the set of unique
characteristics that might be communicated via HTTP. Fingerprinting characteristics that might be communicated via HTTP. Fingerprinting
is considered a privacy concern because it enables tracking of a user is considered a privacy concern because it enables tracking of a user
agent's behavior over time without the corresponding controls that agent's behavior over time without the corresponding controls that
the user might have over other forms of data collection (e.g., the user might have over other forms of data collection (e.g.,
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 fingerprinting concerns only
fingerprinting concerns only apply to situations where cookies are apply to situations where cookies are disabled or restricted by the
disabled or restricted by the user agent's configuration. 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
Accept-Language header field can reveal information the user might Accept-Language header field can reveal information the user might
consider to be of a private nature, because the understanding of consider to be of a private nature. For example, understanding a
particular languages is often strongly correlated to membership in a given language set might be strongly correlated to membership in a
particular ethnic group. An approach that limits such loss of particular ethnic group. An approach that limits such loss of
privacy would be for a user agent to omit the sending of Accept- privacy would be for a user agent to omit the sending of Accept-
Language except for sites that have been whitelisted, perhaps via Language except for sites that have been whitelisted, perhaps via
interaction after detecting a Vary header field that would indicate interaction after detecting a Vary header field that indicates
language negotiation might be useful. language negotiation might be useful.
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 10 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-25 (work in Routing", draft-ietf-httpbis-p1-messaging-26 (work in
progress), November 2013. progress), February 2014.
[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-25 (work in draft-ietf-httpbis-p4-conditional-26 (work in
progress), November 2013. progress), February 2014.
[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-25 (work in Requests", draft-ietf-httpbis-p5-range-26 (work in
progress), November 2013. progress), February 2014.
[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-25 (work in progress), draft-ietf-httpbis-p6-cache-26 (work in progress),
November 2013. February 2014.
[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-25 (work in progress), draft-ietf-httpbis-p7-auth-26 (work in progress),
November 2013. February 2014.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996. RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 86, line 9 skipping to change at page 86, line 5
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web
Application Security Project (OWASP) 2.0.1, July 2005,
<https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Doctoral Network-based Software Architectures",
Dissertation, University of California, Irvine , Doctoral Dissertation, University of California,
September 2000, Irvine, September 2000,
<http://roy.gbiv.com/pubs/dissertation/top.htm>. <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
skipping to change at page 87, line 5 skipping to change at page 87, line 6
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008. RFC 5226, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010. RFC 5789, March 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010. Algorithms Specification", RFC 5905, June 2010.
skipping to change at page 92, line 33 skipping to change at page 92, line 38
BWS = <BWS, defined in [Part1], Section 3.2.3> BWS = <BWS, defined in [Part1], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.3> OWS = <OWS, defined in [Part1], Section 3.2.3>
RWS = <RWS, defined in [Part1], Section 3.2.3> RWS = <RWS, defined in [Part1], Section 3.2.3>
URI-reference = <URI-reference, defined in [Part1], Section 2.7> URI-reference = <URI-reference, defined in [Part1], Section 2.7>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
comment = <comment, defined in [Part1], Section 3.2.6> comment = <comment, defined in [Part1], Section 3.2.6>
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, defined in [Part1], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, defined in [Part1], Section 2.7>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
word = <word, defined in [Part1], Section 3.2.6>
Appendix D. Collected ABNF Appendix D. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section In the collected ABNF below, list rules are expanded as per Section
1.2 of [Part1]. 1.2 of [Part1].
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
skipping to change at page 93, line 42 skipping to change at page 93, line 47
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, defined in [Part1], Section 2.7> URI-reference = <URI-reference, defined in [Part1], Section 2.7>
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) ) ) )
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" word ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
attribute = token
charset = token charset = token
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
comment = <comment, defined in [Part1], Section 3.2.6> comment = <comment, defined in [Part1], Section 3.2.6>
content-coding = token content-coding = token
date1 = day SP month SP year date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT day = 2DIGIT
day-name = %x4D.6F.6E ; Mon day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue / %x54.75.65 ; Tue
/ %x57.65.64 ; Wed / %x57.65.64 ; Wed
/ %x54.68.75 ; Thu / %x54.68.75 ; Thu
/ %x46.72.69 ; Fri / %x46.72.69 ; Fri
/ %x53.61.74 ; Sat / %x53.61.74 ; Sat
skipping to change at page 95, line 4 skipping to change at page 95, line 6
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
parameter = attribute "=" value
parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, defined in [Part1], Section 2.7>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, defined in [Part1], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
subtype = token subtype = token
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = <token, defined in [Part1], Section 3.2.6> token = <token, defined in [Part1], Section 3.2.6>
type = token type = token
value = word
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
word = <word, defined in [Part1], Section 3.2.6>
year = 4DIGIT year = 4DIGIT
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC 2616 E.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in <http:// Changes up to the IETF Last Call draft are summarized in <http://
trac.tools.ietf.org/html/ trac.tools.ietf.org/html/
draft-ietf-httpbis-p2-semantics-24#appendix-E>. draft-ietf-httpbis-p2-semantics-24#appendix-E>.
skipping to change at page 96, line 8 skipping to change at page 96, line 8
o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency: o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
clarify 'effect'" clarify 'effect'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
review of draft-ietf-httpbis-p2-semantics-24" review of draft-ietf-httpbis-p2-semantics-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
registrations to correct draft" registrations to correct draft"
E.3. Since draft-ietf-httpbis-p2-semantics-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/520>: "Gen-Art
review of draft-ietf-httpbis-p2-semantics-24 with security
considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/532>: "IESG ballot
on draft-ietf-httpbis-p2-semantics-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/545>: "requirement
on implementing methods according to their semantics"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/546>:
"considerations for new headers: privacy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
Index Index
1 1
1xx Informational (status code class) 50 1xx Informational (status code class) 49
2 2
2xx Successful (status code class) 51 2xx Successful (status code class) 50
3 3
3xx Redirection (status code class) 54 3xx Redirection (status code class) 53
4 4
4xx Client Error (status code class) 58 4xx Client Error (status code class) 57
5 5
5xx Server Error (status code class) 62 5xx Server Error (status code class) 61
1 1
100 Continue (status code) 50 100 Continue (status code) 49
100-continue (expect value) 34 100-continue (expect value) 33
101 Switching Protocols (status code) 50 101 Switching Protocols (status code) 49
2 2
200 OK (status code) 51 200 OK (status code) 50
201 Created (status code) 52 201 Created (status code) 51
202 Accepted (status code) 52 202 Accepted (status code) 51
203 Non-Authoritative Information (status code) 52 203 Non-Authoritative Information (status code) 51
204 No Content (status code) 53 204 No Content (status code) 52
205 Reset Content (status code) 53 205 Reset Content (status code) 52
3 3
300 Multiple Choices (status code) 55 300 Multiple Choices (status code) 54
301 Moved Permanently (status code) 56 301 Moved Permanently (status code) 55
302 Found (status code) 56 302 Found (status code) 55
303 See Other (status code) 57 303 See Other (status code) 56
305 Use Proxy (status code) 57 305 Use Proxy (status code) 56
306 (Unused) (status code) 58 306 (Unused) (status code) 56
307 Temporary Redirect (status code) 58 307 Temporary Redirect (status code) 57
4 4
400 Bad Request (status code) 58 400 Bad Request (status code) 57
402 Payment Required (status code) 58 402 Payment Required (status code) 57
403 Forbidden (status code) 59 403 Forbidden (status code) 57
404 Not Found (status code) 59 404 Not Found (status code) 58
405 Method Not Allowed (status code) 59 405 Method Not Allowed (status code) 58
406 Not Acceptable (status code) 59 406 Not Acceptable (status code) 58
408 Request Timeout (status code) 60 408 Request Timeout (status code) 59
409 Conflict (status code) 60 409 Conflict (status code) 59
410 Gone (status code) 60 410 Gone (status code) 59
411 Length Required (status code) 61 411 Length Required (status code) 60
413 Payload Too Large (status code) 61 413 Payload Too Large (status code) 60
414 URI Too Long (status code) 61 414 URI Too Long (status code) 60
415 Unsupported Media Type (status code) 62 415 Unsupported Media Type (status code) 60
417 Expectation Failed (status code) 62 417 Expectation Failed (status code) 61
426 Upgrade Required (status code) 62 426 Upgrade Required (status code) 61
5 5
500 Internal Server Error (status code) 63 500 Internal Server Error (status code) 61
501 Not Implemented (status code) 63 501 Not Implemented (status code) 62
502 Bad Gateway (status code) 63 502 Bad Gateway (status code) 62
503 Service Unavailable (status code) 63 503 Service Unavailable (status code) 62
504 Gateway Timeout (status code) 63 504 Gateway Timeout (status code) 62
505 HTTP Version Not Supported (status code) 63 505 HTTP Version Not Supported (status code) 62
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 72 Allow header field 71
C C
cacheable 24 cacheable 24
compress (content coding) 11 compress (content coding) 11
conditional request 36 conditional request 36
CONNECT method 30 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 89 Content-Transfer-Encoding header field 89
Content-Type header field 10 Content-Type header field 10
D D
Date header field 67 Date header field 66
deflate (content coding) 11 deflate (content coding) 11
DELETE method 29 DELETE method 29
E E
Expect header field 34 Expect header field 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 72 Allow 71
asctime-date 67 asctime-date 66
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 67 Date 66
date1 66 date1 65
day 66 day 65
day-name 66 day-name 65
day-name-l 66 day-name-l 65
delay-seconds 70 delay-seconds 69
Expect 34 Expect 34
From 44 From 44
GMT 66 GMT 65
hour 66 hour 65
HTTP-date 64 HTTP-date 63
IMF-fixdate 66 IMF-fixdate 65
language-range 42 language-range 42
language-tag 13 language-tag 13
Location 68 Location 67
Max-Forwards 36 Max-Forwards 36
media-range 38 media-range 38
media-type 8 media-type 8
method 21 method 21
minute 66 minute 65
month 66 month 65
obs-date 66 obs-date 65
parameter 8 parameter 8
product 46 product 46
product-version 46 product-version 46
qvalue 38 qvalue 38
Referer 45 Referer 45
Retry-After 70 Retry-After 69
rfc850-date 67 rfc850-date 66
second 66 second 65
Server 73 Server 72
subtype 8 subtype 8
time-of-day 66 time-of-day 65
type 8 type 8
User-Agent 46 User-Agent 46
value 8 Vary 69
Vary 70
weight 38 weight 38
year 66 year 65
gzip (content coding) 11 gzip (content coding) 11
H H
HEAD method 25 HEAD method 25
I I
idempotent 23 idempotent 23
L L
Location header field 68 Location header field 67
M M
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 88 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 45 Referer header field 44
representation 7 representation 7
Retry-After header field 69 Retry-After header field 68
S S
safe 22 safe 22
selected representation 7, 71 selected representation 7, 70
Server header field 73 Server header field 72
Status Codes Classes Status Codes Classes
1xx Informational 50 1xx Informational 49
2xx Successful 51 2xx Successful 50
3xx Redirection 54 3xx Redirection 53
4xx Client Error 58 4xx Client Error 57
5xx Server Error 62 5xx Server Error 61
T T
TRACE method 32 TRACE method 32
U U
User-Agent header field 46 User-Agent header field 46
V V
Vary header field 70 Vary header field 69
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. 103 change blocks. 
315 lines changed or deleted 387 lines changed or added

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