INTRODUCTION, paragraph 1:
OLD:
HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed.
Updates: 2817 (if approved) greenbytes
Intended status: Standards Track May 6, 2014
Expires: November 7, 2014
NEW:
Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 7231 Adobe
Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 greenbytes
Category: Standards Track May 2014
ISSN: 2070-1721
INTRODUCTION, paragraph 2:
OLD:
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-latest
NEW:
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
INTRODUCTION, paragraph 5:
OLD:
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
.
The current issues list is at
and related
documents (including fancy diffs) can be found at
.
The changes in this draft are summarized in Appendix E.4.
Status of This Memo
NEW:
Status of This Memo
INTRODUCTION, paragraph 6:
OLD:
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
NEW:
This is an Internet Standards Track document.
INTRODUCTION, paragraph 7:
OLD:
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
NEW:
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
INTRODUCTION, paragraph 8:
OLD:
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2014.
NEW:
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7231.
Section 11., paragraph 0:
OLD:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8
3.1.1. Processing Representation Data . . . . . . . . . . . . 8
3.1.2. Encoding for Compression or Integrity . . . . . . . . 11
3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13
3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14
3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17
3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17
3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18
3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22
4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23
4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Considerations for New Methods . . . . . . . . . . . . 74
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 82
9.2. Attacks Based On Command, Code, or Query Injection . . . . 82
9.3. Disclosure of Personal Information . . . . . . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83
9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 90
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 96
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96
E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 96
E.3. Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 97
E.4. Since draft-ietf-httpbis-p2-semantics-26 . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
NEW:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8
3.1.1. Processing Representation Data . . . . . . . . . . . . 8
3.1.2. Encoding for Compression or Integrity . . . . . . . . 11
3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13
3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14
3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17
3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17
3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18
3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22
4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23
4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Considerations for New Methods . . . . . . . . . . . . 74
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82
9.2. Attacks Based on Command, Code, or Query Injection . . . . 82
9.3. Disclosure of Personal Information . . . . . . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83
9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90
A.6. MHTML and Line-Length Limitations . . . . . . . . . . . . 90
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Section 1., paragraph 1:
OLD:
Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that
request with one or more response messages. A client constructs
request messages to communicate specific intentions, and examines
received responses to see if the intentions were carried out and
determine how to interpret the results. This document defines
HTTP/1.1 request and response semantics in terms of the architecture
defined in [RFC7230].
NEW:
Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that
request with one or more response messages. A client constructs
request messages to communicate specific intentions, examines
received responses to see if the intentions were carried out, and
determines how to interpret the results. This document defines
HTTP/1.1 request and response semantics in terms of the architecture
defined in [RFC7230].
Section 2., paragraph 1:
OLD:
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
might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in
Section 2.7 of [RFC7230].
NEW:
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
might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in
Section 2.7 of [RFC7230].
Section 3., paragraph 3:
OLD:
An origin server might be provided with, or capable of generating,
multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as
most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests [RFC7232] and
constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 4.3.1).
NEW:
An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as
most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests [RFC7232] and
constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 4.3.1).
Section 3.1.1.1., paragraph 1:
OLD:
HTTP uses Internet Media Types [RFC2046] in the Content-Type
(Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models:
how to process that data in accordance with each context in which it
is received.
NEW:
HTTP uses Internet media types [RFC2046] in the Content-Type
(Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models:
how to process that data in accordance with each context in which it
is received.
Section 3.1.1.1., paragraph 5:
OLD:
The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on
the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry.
NEW:
The type, subtype, and parameter name tokens are case insensitive.
Parameter values might or might not be case sensitive, depending on
the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry.
Section 3.1.1.1., paragraph 6:
OLD:
A parameter value that matches the token production can be
transmitted as either a token or within a quoted-string. The quoted
and unquoted values are equivalent. For example, the following
examples are all equivalent, but the first is preferred for
consistency:
NEW:
A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. For example, the following
examples are all equivalent, but the first is preferred for
consistency:
Section 3.1.1.2., paragraph 3:
OLD:
Charset names ought to be registered in IANA Character Set registry
() according to the
procedures defined in [RFC2978].
NEW:
Charset names ought to be registered in the IANA "Character Sets"
registry according
to the procedures defined in [RFC2978].
Section 3.1.1.3., paragraph 2:
OLD:
MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break. HTTP allows the transfer of text
media with plain CR or LF alone representing a line break, when such
line breaks are consistent for an entire representation. An HTTP
sender MAY generate, and a recipient MUST be able to parse, line
breaks in text media that consist of CRLF, bare CR, or bare LF. In
addition, text media in HTTP is not limited to charsets that use
octets 13 and 10 for CR and LF, respectively. This flexibility
regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload body (e.g.,
header fields).
NEW:
MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break. HTTP allows the transfer of text
media with plain carriage return (CR) or line feed (LF) alone
representing a line break, when such line breaks are consistent for
an entire representation. An HTTP sender MAY generate, and a
recipient MUST be able to parse, line breaks in text media that
consist of CRLF, bare CR, or bare LF. In addition, text media in
HTTP is not limited to charsets that use octets 13 and 10 for CR and
LF, respectively. This flexibility regarding line breaks applies
only to text within a representation that has been assigned a "text"
media type; it does not apply to "multipart" types or HTTP elements
outside the payload body (e.g., header fields).
Section 3.1.2.1., paragraph 3:
OLD:
All content-coding values are case-insensitive and ought to be
registered within the HTTP Content Coding registry, as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields.
NEW:
All content-coding values are case insensitive and ought to be
registered within the "HTTP Content Coding Registry", as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields.
Section 3.1.3.1., paragraph 4:
OLD:
A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English) which is
optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include:
NEW:
A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include:
Section 3.1.3.2., paragraph 5:
OLD:
If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended.
NEW:
If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language,
or that the sender does not know which language is being used.
Section 406, paragraph 1:
OLD:
Reactive negotiation is advantageous when the response would vary
over commonly-used dimensions (such as type, language, or encoding),
when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public
caches are used to distribute server load and reduce network usage.
NEW:
Reactive negotiation is advantageous when the response would vary
over commonly used dimensions (such as type, language, or encoding),
when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public
caches are used to distribute server load and reduce network usage.
Section 4.1., paragraph 4:
OLD:
HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply
semantics. The method token is case-sensitive because it might be
used as a gateway to object-based systems with case-sensitive method
names.
NEW:
HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply
semantics. The method token is case sensitive because it might be
used as a gateway to object-based systems with case-sensitive method
names.
Section 4.1., paragraph 5:
OLD:
Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed.
NEW:
Unlike distributed objects, the standardized request methods in HTTP
are not resource specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed.
Section 4.1., paragraph 9:
OLD:
Additional methods, outside the scope of this specification, have
been standardized for use in HTTP. All such methods ought to be
registered within the HTTP Method Registry maintained by IANA, as
defined in Section 8.1.
NEW:
Additional methods, outside the scope of this specification, have
been standardized for use in HTTP. All such methods ought to be
registered within the "Hypertext Transfer Protocol (HTTP) Method"
registry maintained by IANA, as defined in Section 8.1.
Section 4.2.1., paragraph 2:
OLD:
This definition of safe methods does not prevent an implementation
from including behavior that is potentially harmful, not entirely
read-only, or which causes side-effects while invoking a safe method.
What is important, however, is that the client did not request that
additional behavior and cannot be held accountable for it. For
example, most servers append request information to access log files
at the completion of every response, regardless of the method, and
that is considered safe even though the log storage might become full
and crash the server. Likewise, a safe request initiated by
selecting an advertisement on the Web will often have the side-effect
of charging an advertising account.
NEW:
This definition of safe method does not prevent an implementation
from including behavior that is potentially harmful, that is not
entirely read-only, or that causes side effects while invoking a safe
method. What is important, however, is that the client did not
request that additional behavior and cannot be held accountable for
it. For example, most servers append request information to access
log files at the completion of every response, regardless of the
method, and that is considered safe even though the log storage might
become full and crash the server. Likewise, a safe request initiated
by selecting an advertisement on the Web will often have the side
effect of charging an advertising account.
Section 4.2.1., paragraph 6:
OLD:
When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action, it is
the resource owner's responsibility to ensure that the action is
consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within
query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side-
effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search
index, etc.
NEW:
When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action, it is
the resource owner's responsibility to ensure that the action is
consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within
query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search
index, etc.
Section 4.2.2., paragraph 2:
OLD:
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
request separately, retain a revision control history, or implement
other non-idempotent side-effects for each idempotent request.
NEW:
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
request separately, retain a revision control history, or implement
other non-idempotent side effects for each idempotent request.
Section 4.2.3., paragraph 1:
OLD:
Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for
specific requirements see [RFC7234]. In general, safe methods that
do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD and POST as
cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD.
NEW:
Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for
specific requirements see [RFC7234]. In general, safe methods that
do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD, and POST as
cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD.
Section 4.3.1., paragraph 2:
OLD:
It is tempting to think of resource identifiers as remote file system
pathnames, and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are
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
programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to
a file system, an origin server might be configured to execute the
files with the request as input and send the output as the
representation, rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource
identifiers corresponds to an implementation, and how each
implementation manages to select and send a current representation of
the target resource in a response to GET.
NEW:
It is tempting to think of resource identifiers as remote file system
pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are
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
programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to
a file system, an origin server might be configured to execute the
files with the request as input and send the output as the
representation rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource
identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of
the target resource in a response to GET.
Section 4.3.3., paragraph 6:
OLD:
An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions
being 206, 304, and 416).
NEW:
An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions
being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
Satisfiable)).
Section 4.3.4., paragraph 10:
OLD:
An origin server MUST NOT send a validator header field
(Section 7.2), such as an ETag or Last-Modified field, in a
successful response to PUT unless the request's representation data
was saved without any transformation applied to the body (i.e., the
resource's new representation data is identical to the representation
data received in the PUT request) and the validator field value
reflects the new representation. This requirement allows a user
agent to know when the representation body it has in memory remains
current as a result of the PUT, thus not in need of retrieving again
from the origin server, and that the new validator(s) received in the
response can be used for future conditional requests in order to
prevent accidental overwrites (Section 5.2).
NEW:
An origin server MUST NOT send a validator header field
(Section 7.2), such as an ETag or Last-Modified field, in a
successful response to PUT unless the request's representation data
was saved without any transformation applied to the body (i.e., the
resource's new representation data is identical to the representation
data received in the PUT request) and the validator field value
reflects the new representation. This requirement allows a user
agent to know when the representation body it has in memory remains
current as a result of the PUT, thus not in need of being retrieved
again from the origin server, and that the new validator(s) received
in the response can be used for future conditional requests in order
to prevent accidental overwrites (Section 5.2).
Section 4.3.4., paragraph 13:
OLD:
A PUT request applied to the target resource can have side-effects on
other resources. For example, an article might have a URI for
identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources
that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be
added between the related resources.
NEW:
A PUT request applied to the target resource can have side effects on
other resources. For example, an article might have a URI for
identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources
that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be
added between the related resources.
Section 4.3.5., paragraph 1:
OLD:
The DELETE method requests that the origin server remove the
association between the target resource and its current
functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the
origin server, rather than an expectation that the previously
associated information be deleted.
NEW:
The DELETE method requests that the origin server remove the
association between the target resource and its current
functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the
origin server rather than an expectation that the previously
associated information be deleted.
Section 4.3.6., paragraph 2:
OLD:
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
2xx status code to indicate that a connection is established.
However, most origin servers do not implement CONNECT.
NEW:
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
2xx (Successful) status code to indicate that a connection is
established. However, most origin servers do not implement CONNECT.
Section 4.3.7., paragraph 1:
OLD:
The OPTIONS method requests information about the communication
options available for the target resource, either at the origin
server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a
resource action.
NEW:
The OPTIONS method requests information about the communication
options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a
resource action.
Section 4.3.8., paragraph 2:
OLD:
A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user
credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient
generates the response body.
NEW:
A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user
credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient
generates the response body.
Section 5.1.1., paragraph 3:
OLD:
The Expect field-value is case-insensitive.
NEW:
The Expect field-value is case insensitive.
Section 5.1.1., paragraph 21:
OLD:
Note: The Expect header field was added after the original
publication of HTTP/1.1 [RFC2068] as both the means to request an
interim 100 response and the general mechanism for indicating
must-understand extensions. However, the extension mechanism has
not been used by clients and the must-understand requirements have
not been implemented by many servers, rendering the extension
mechanism useless. This specification has removed the extension
mechanism in order to simplify the definition and processing of
100-continue.
NEW:
Note: The Expect header field was added after the original
publication of HTTP/1.1 [RFC2068] as both the means to request an
interim 100 (Continue) response and the general mechanism for
indicating must-understand extensions. However, the extension
mechanism has not been used by clients and the must-understand
requirements have not been implemented by many servers, rendering
the extension mechanism useless. This specification has removed
the extension mechanism in order to simplify the definition and
processing of 100-continue.
Section 5.1.2., paragraph 4:
OLD:
Each intermediary that receives a TRACE or OPTIONS request containing
a Max-Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the
intermediary MUST NOT forward the request; instead, the intermediary
MUST respond as the final recipient. If the received Max-Forwards
value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that
is the lesser of: a) the received value decremented by one (1), or b)
the recipient's maximum supported value for Max-Forwards.
NEW:
Each intermediary that receives a TRACE or OPTIONS request containing
a Max-Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the
intermediary MUST NOT forward the request; instead, the intermediary
MUST respond as the final recipient. If the received Max-Forwards
value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that
is the lesser of a) the received value decremented by one (1) or b)
the recipient's maximum supported value for Max-Forwards.
Section 5.3.2., paragraph 9:
OLD:
is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% mark-down in quality".
NEW:
is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% markdown in quality".
Section 5.3.5., paragraph 6:
OLD:
A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field
is present in a request and none of the available representations for
the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it
is not subject to content negotiation, or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example).
NEW:
A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field
is present in a request and none of the available representations for
the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it
is not subject to content negotiation or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example).
Section 5.3.5., paragraph 10:
OLD:
Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself, or by
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.
NEW:
Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by
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.
Section 5.5.1., paragraph 1:
OLD:
The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]:
NEW:
The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought
to be machine usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]:
Section 5.5.2., paragraph 6:
OLD:
If the target URI was obtained from a source that does not have its
own URI (e.g., input from the user keyboard, or an entry within the
user's bookmarks/favorites), the user agent MUST either exclude
Referer or send it with a value of "about:blank".
NEW:
If the target URI was obtained from a source that does not have its
own URI (e.g., input from the user keyboard, or an entry within the
user's bookmarks/favorites), the user agent MUST either exclude the
Referer or send it with a value of "about:blank".
Section 5.5.2., paragraph 8:
OLD:
Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the
unfortunate side-effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the request
target.
NEW:
Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the
unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the request
target.
Section 5.5.3., paragraph 1:
OLD:
The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so.
NEW:
The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user-agent
limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so.
Section 5.5.3., paragraph 3:
OLD:
The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 3.2 of
[RFC7230]), which together identify the user agent software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
user agent software. Each product identifier consists of a name and
optional version.
NEW:
The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 3.2 of
[RFC7230]), which together identify the user-agent software and its
significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the
user-agent software. Each product identifier consists of a name and
optional version.
Section 5.5.3., paragraph 5:
OLD:
A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate
advertising or other non-essential information within the product
identifier. A sender SHOULD NOT generate information in product-
version that is not a version identifier (i.e., successive versions
of the same product name ought to only differ in the product-version
portion of the product identifier).
NEW:
A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate
advertising or other nonessential information within the product
identifier. A sender SHOULD NOT generate information in product-
version that is not a version identifier (i.e., successive versions
of the same product name ought only to differ in the product-version
portion of the product identifier).
Section 5.5.3., paragraph 9:
OLD:
Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for
the actual user agent being used.
NEW:
Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for
the actual user agent being implemented.
Section 6., paragraph 1:
OLD:
The status-code element is a 3-digit integer code giving the result
of the attempt to understand and satisfy the request.
NEW:
The status-code element is a three-digit integer code giving the
result of the attempt to understand and satisfy the request.
Section 6., paragraph 3:
OLD:
For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 status
code. The response message will usually contain a representation
that explains the status.
NEW:
For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a
representation that explains the status.
Section 6., paragraph 4:
OLD:
The first digit of the status-code defines the class of response.
The last two digits do not have any categorization role. There are 5
values for the first digit:
NEW:
The first digit of the status-code defines the class of response.
The last two digits do not have any categorization role. There are
five values for the first digit:
Section 6.1., paragraph 2:
OLD:
Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
specification) can be reused by a cache with heuristic expiration
unless otherwise indicated by the method definition or explicit cache
controls [RFC7234]; all other status codes are not cacheable by
default.
NEW:
Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
this specification) can be reused by a cache with heuristic
expiration unless otherwise indicated by the method definition or
explicit cache controls [RFC7234]; all other status codes are not
cacheable by default.
Section 6.1., paragraph 3:
OLD:
+------+-------------------------------+--------------------------+
| code | reason-phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Time-out | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Time-out | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+
NEW:
+------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Time-out | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Time-out | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+
Section 6.2., paragraph 1:
OLD:
The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress
prior to completing the requested action and sending a final
response. All 1xx responses consist of only the status-line and
optional header fields, and thus are terminated by the empty line at
the end of the header section. Since HTTP/1.0 did not define any 1xx
status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
client.
NEW:
The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress
prior to completing the requested action and sending a final
response. All 1xx responses consist of only the status-line and
optional header fields and, thus, are terminated by the empty line at
the end of the header section. Since HTTP/1.0 did not define any 1xx
status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
client.
Section 6.3.3., paragraph 2:
OLD:
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this
response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.
NEW:
The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this
response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.
Section 6.4.1., paragraph 5:
OLD:
Note: The original proposal for 300 defined the URI header field
as providing a list of alternative representations, such that it
would be usable for 200, 300, and 406 responses and be transferred
in responses to the HEAD method. However, lack of deployment and
disagreement over syntax led to both URI and Alternates (a
subsequent proposal) being dropped from this specification. It is
possible to communicate the list using a set of Link header fields
[RFC5988], each with a relationship of "alternate", though
deployment is a chicken-and-egg problem.
NEW:
Note: The original proposal for the 300 response defined the URI
header field as providing a list of alternative representations,
such that it would be usable for 200, 300, and 406 responses and
be transferred in responses to the HEAD method. However, lack of
deployment and disagreement over syntax led to both URI and
Alternates (a subsequent proposal) being dropped from this
specification. It is possible to communicate the list using a set
of Link header fields [RFC5988], each with a relationship of
"alternate", though deployment is a chicken-and-egg problem.
Section 6.4.2., paragraph 1:
OLD:
The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new
references sent by the server, where possible.
NEW:
The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs.
Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new
references sent by the server, where possible.
Section 6.4.4., paragraph 2:
OLD:
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
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original
request.
NEW:
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
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached, independent of the original
request.
Section 6.4.7., paragraph 3:
OLD:
Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved
Permanently) ([status-308], however, defines the status code 308
(Permanent Redirect) for this purpose).
NEW:
Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved
Permanently) ([RFC7238]; however, it defines the status code 308
(Permanent Redirect) for this purpose).
Section 6.5.1., paragraph 1:
OLD:
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something which is perceived to
be a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
NEW:
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
Section 5.3, paragraph 0:
OLD:
The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to
exploit potential security holes.
NEW:
The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of
itself) or when the server is under attack by a client attempting to
exploit potential security holes.
Section 7.1.1.1., paragraph 11:
OLD:
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
NEW:
day-name = %x4D.6F.6E ; "Mon", case sensitive
/ %x54.75.65 ; "Tue", case sensitive
/ %x57.65.64 ; "Wed", case sensitive
/ %x54.68.75 ; "Thu", case sensitive
/ %x46.72.69 ; "Fri", case sensitive
/ %x53.61.74 ; "Sat", case sensitive
/ %x53.75.6E ; "Sun", case sensitive
Section 7.1.1.1., paragraph 13:
OLD:
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
NEW:
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case sensitive
/ %x46.65.62 ; "Feb", case sensitive
/ %x4D.61.72 ; "Mar", case sensitive
/ %x41.70.72 ; "Apr", case sensitive
/ %x4D.61.79 ; "May", case sensitive
/ %x4A.75.6E ; "Jun", case sensitive
/ %x4A.75.6C ; "Jul", case sensitive
/ %x41.75.67 ; "Aug", case sensitive
/ %x53.65.70 ; "Sep", case sensitive
/ %x4F.63.74 ; "Oct", case sensitive
/ %x4E.6F.76 ; "Nov", case sensitive
/ %x44.65.63 ; "Dec", case sensitive
year = 4DIGIT
Section 7.1.1.1., paragraph 14:
OLD:
GMT = %x47.4D.54 ; "GMT", case-sensitive
NEW:
GMT = %x47.4D.54 ; "GMT", case sensitive
Section 7.1.1.1., paragraph 19:
OLD:
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
NEW:
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case sensitive
/ %x46.72.69.64.61.79 ; "Friday", case sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case sensitive
Section 7.1.2., paragraph 5:
OLD:
If the Location value provided in a 3xx (Redirection) does not have a
fragment component, a user agent MUST process the redirection as if
the value inherits the fragment component of the URI reference used
to generate the request target (i.e., the redirection inherits the
original reference's fragment, if any).
NEW:
If the Location value provided in a 3xx (Redirection) response does
not have a fragment component, a user agent MUST process the
redirection as if the value inherits the fragment component of the
URI reference used to generate the request target (i.e., the
redirection inherits the original reference's fragment, if any).
Section 7.1.4., paragraph 1:
OLD:
The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and
request target, might influence the origin server's process for
selecting and representing this response. The value consists of
either a single asterisk ("*") or a list of header field names (case-
insensitive).
NEW:
The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and
request target, might influence the origin server's process for
selecting and representing this response. The value consists of
either a single asterisk ("*") or a list of header field names (case
insensitive).
Section 1., paragraph 1:
OLD:
2. To inform user agent recipients that this response is subject to
content negotiation (Section 5.3) and that a different
representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields
(proactive negotiation).
NEW:
2. To inform user-agent recipients that this response is subject to
content negotiation (Section 5.3) and that a different
representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields
(proactive negotiation).
Section 7.2., paragraph 3:
OLD:
For example, an ETag header field in a 201 response communicates the
entity-tag of the newly created resource's representation, so that it
can be used in later conditional requests to prevent the "lost
update" problem [RFC7232].
NEW:
For example, an ETag header field in a 201 (Created) response
communicates the entity-tag of the newly created resource's
representation, so that it can be used in later conditional requests
to prevent the "lost update" problem [RFC7232].
Section 8.1., paragraph 1:
OLD:
The HTTP Method Registry defines the name space for the request
method token (Section 4). The method registry will be created and
maintained at (the suggested URI)
.
NEW:
The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
namespace for the request method token (Section 4). The "HTTP Method
Registry" has been created and is now maintained at
.
Section 8.1.2., paragraph 3:
OLD:
A new method definition needs to indicate whether it is safe
(Section 4.2.1), idempotent (Section 4.2.2), cacheable
(Section 4.2.3), what semantics are to be associated with the payload
body if any is present in the request, and what refinements the
method makes to header field or status code semantics. If the new
method is cacheable, its definition ought to describe how, and under
what conditions, a cache can store a response and use it to satisfy a
subsequent request. The new method ought to describe whether it can
be made conditional (Section 5.2) and, if so, how a server responds
when the condition is false. Likewise, if the new method might have
some use for partial response semantics ([RFC7233]), it ought to
document this too.
NEW:
A new method definition needs to indicate whether it is safe
(Section 4.2.1), idempotent (Section 4.2.2), or cacheable
(Section 4.2.3). It needs to indicate what semantics are to be
associated with the payload body if any is present in the request and
what refinements the method makes to header field or status code
semantics. If the new method is cacheable, its definition ought to
describe how, and under what conditions, a cache can store a response
and use it to satisfy a subsequent request. The new method ought to
describe whether it can be made conditional (Section 5.2) and, if so,
how a server responds when the condition is false. Likewise, if the
new method might have some use for partial response semantics
([RFC7233]), it ought to document this, too.
Section 8.1.3., paragraph 1:
OLD:
The HTTP Method Registry shall be populated with the registrations
below:
NEW:
The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
populated with the registrations below:
Section 8.2., paragraph 1:
OLD:
The HTTP Status Code Registry defines the name space for the response
status-code token (Section 6). The status code registry is
maintained at .
NEW:
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
the namespace for the response status-code token (Section 6). The
"HTTP Status Codes" registry is maintained at
.
Section 8.2., paragraph 2:
OLD:
This Section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817].
NEW:
This section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817].
Section 8.2.3., paragraph 1:
OLD:
The HTTP Status Code Registry shall be updated with the registrations
below:
NEW:
The "HTTP Status Codes" registry has been updated with the
registrations below:
Section 8.3., paragraph 1:
OLD:
HTTP header fields are registered within the Message Header Field
Registry located at , as defined by [BCP90].
NEW:
HTTP header fields are registered within the "Message Headers"
registry located at
as defined by [BCP90].
Section 8.3.1., paragraph 3:
OLD:
Authors of specifications defining new fields are advised to keep the
name as short as practical and to not prefix the name with "X-"
unless the header field will never be used on the Internet. (The
"x-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered
Internet name; see [BCP178] for further information)
NEW:
Authors of specifications defining new fields are advised to keep the
name as short as practical and not to prefix the name with "X-"
unless the header field will never be used on the Internet. (The
"X-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered
Internet name; see [BCP178] for further information).
Section 8.3.1., paragraph 4:
OLD:
New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 7 of
[RFC7230] as necessary, and are usually constrained to the range of
ASCII characters. Header fields needing a greater range of
characters can use an encoding such as the one defined in [RFC5987].
NEW:
New header field values typically have their syntax defined using
ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
[RFC7230] as necessary), and they are usually constrained to the
range of ASCII characters. Header fields needing a greater range of
characters can use an encoding such as the one defined in [RFC5987].
Section 8.3.1., paragraph 13:
OLD:
o Whether the field is a single value, or whether it can be a list
(delimited by commas; see Section 3.2 of [RFC7230]).
NEW:
o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 3.2 of [RFC7230]).
Section 8.3.2., paragraph 1:
OLD:
The Message Header Field Registry shall be updated with the following
permanent registrations:
NEW:
The "Message Headers" registry has been updated with the following
permanent registrations:
Section 8.3.2., paragraph 2:
OLD:
+-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Max-Forwards | http | standard | Section 5.1.2 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+
NEW:
+-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+
Section 8.4., paragraph 1:
OLD:
The HTTP Content Coding Registry defines the name space for content
coding names (Section 4.2 of [RFC7230]). The content coding registry
is maintained at .
NEW:
The "HTTP Content Coding Registry" defines the namespace for content
coding names (Section 4.2 of [RFC7230]). The "HTTP Content Coding
Registry" is maintained at
.
Section 8.4.1., paragraph 1:
OLD:
Content Coding registrations MUST include the following fields:
NEW:
Content coding registrations MUST include the following fields:
Section 8.4.1., paragraph 6:
OLD:
Values to be added to this name space require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
coding defined in this section.
NEW:
Values to be added to this namespace require IETF Review (see Section
4.1 of [RFC5226]) and MUST conform to the purpose of content coding
defined in this section.
Section 8.4.2., paragraph 1:
OLD:
The HTTP Content Codings Registry shall be updated with the
registrations below:
NEW:
The "HTTP Content Codings Registry" has been updated with the
registrations below:
Section 9., paragraph 2:
OLD:
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]).
NEW:
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) or securing user-agent
processing of payloads received via HTTP. Secure use of the Internet
in general, rather than security of the protocol, might also be
related. Various organizations maintain topical information and
links to current research on Web application security (e.g.,
[OWASP]).
Section 9., paragraph 3:
OLD:
9.1. Attacks Based On File and Path Names
NEW:
9.1. Attacks Based on File and Path Names
Section 9., paragraph 4:
OLD:
Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource
representations. Implementers need to be aware that most file
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, folders, or directories that have special significance to the
system.
NEW:
Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource
representations. Implementers need to be aware that most file
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, folders, or directories that have special significance to the
system.
Section 9., paragraph 5:
OLD:
For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the
current one, and use specially named paths or file names to send data
to system devices. Similar naming conventions might exist within
other types of storage systems. Likewise, local storage systems have
an annoying tendency to prefer user-friendliness over security when
handling invalid or unexpected characters, recomposition of
decomposed characters, and case-normalization of case-insensitive
names.
NEW:
For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the
current one, and they use specially named paths or file names to send
data to system devices. Similar naming conventions might exist
within other types of storage systems. Likewise, local storage
systems have an annoying tendency to prefer user-friendliness over
security when handling invalid or unexpected characters,
recomposition of decomposed characters, and case-normalization of
case-insensitive names.
Section 9., paragraph 7:
OLD:
9.2. Attacks Based On Command, Code, or Query Injection
NEW:
9.2. Attacks Based on Command, Code, or Query Injection
Section 9.4., paragraph 3:
OLD:
Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any
personal information that might be found in the referring resource's
URI. Limitations on Referer are described in Section 5.5.2 to
address some of its security considerations.
NEW:
Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any
personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in
Section 5.5.2 to address some of its security considerations.
Section 11.1., paragraph 1:
OLD:
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
NEW:
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
Section 11.1., paragraph 2:
OLD:
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
NEW:
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
Section 11.1., paragraph 4:
OLD:
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
NEW:
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Section 11.1., paragraph 5:
OLD:
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of
Language Tags", BCP 47, RFC 4647, September 2006.
NEW:
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, September 2006.
Section 11.1., paragraph 6:
OLD:
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
NEW:
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Section 11.1., paragraph 7:
OLD:
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646,
September 2009.
NEW:
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
Section 11.1., paragraph 9:
OLD:
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-latest (work
in progress), May 2014.
NEW:
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, May 2014.
Section 11.1., paragraph 10:
OLD:
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in
progress), May 2014.
NEW:
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
May 2014.
Section 11.1., paragraph 11:
OLD:
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-latest (work in
progress), May 2014.
NEW:
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, May 2014.
Section 11.1., paragraph 12:
OLD:
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress),
May 2014.
NEW:
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, May 2014.
Section 11.1., paragraph 13:
OLD:
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-latest (work in progress),
May 2014.
NEW:
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
Section 11.2., paragraph 3:
OLD:
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
NEW:
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
Section 11.2., paragraph 4:
OLD:
[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,
.
NEW:
[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,
.
Section 11.2., paragraph 5:
OLD:
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures",
Doctoral Dissertation, University of California,
Irvine, September 2000,
.
NEW:
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures",
Doctoral Dissertation, University of California, Irvine,
September 2000,
.
Section 11.2., paragraph 6:
OLD:
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
NEW:
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
Section 11.2., paragraph 7:
OLD:
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996.
NEW:
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
Section 11.2., paragraph 8:
OLD:
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2068, January 1997.
NEW:
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
Section 11.2., paragraph 9:
OLD:
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content
Negotiation in HTTP", RFC 2295, March 1998.
NEW:
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, March 1998.
Section 11.2., paragraph 11:
OLD:
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC 2557, March 1999.
NEW:
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999.
Section 11.2., paragraph 16:
OLD:
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
NEW:
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Section 11.2., paragraph 17:
OLD:
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
NEW:
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Section 11.2., paragraph 20:
OLD:
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
NEW:
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
Section 11.2., paragraph 24:
OLD:
[RFC6266] Reschke, J., "Use of the Content-Disposition Header
Field in the Hypertext Transfer Protocol (HTTP)",
RFC 6266, June 2011.
NEW:
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
June 2011.
Section 11.2., paragraph 25:
OLD:
[status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)",
draft-reschke-http-status-308-07 (work in progress),
March 2012.
NEW:
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
Appendix A., paragraph 1:
OLD:
HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email, and hence HTTP has
features that differ from MIME. These differences were carefully
chosen to optimize performance over binary connections, to allow
greater freedom in the use of new media types, to make date
comparisons easier, and to acknowledge the practice of some early
HTTP servers and clients.
NEW:
HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email; hence, HTTP has features
that differ from MIME. These differences were carefully chosen to
optimize performance over binary connections, to allow greater
freedom in the use of new media types, to make date comparisons
easier, and to acknowledge the practice of some early HTTP servers
and clients.
Appendix A., paragraph 16:
OLD:
A.6. MHTML and Line Length Limitations
NEW:
A.6. MHTML and Line-Length Limitations
Appendix A., paragraph 17:
OLD:
HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type (Appendix A
of [RFC7233]), does not interpret the content or any MIME header
lines that might be contained therein.
NEW:
HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line-length limitations.
Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line-length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type (Appendix A
of [RFC7233]), does not interpret the content or any MIME header
lines that might be contained therein.
Appendix B., paragraph 2:
OLD:
A new requirement has been added that semantics embedded in a URI
should be disabled when those semantics are inconsistent with the
request method, since this is a common cause of interoperability
failure. (Section 2)
NEW:
A new requirement has been added that semantics embedded in a URI be
disabled when those semantics are inconsistent with the request
method, since this is a common cause of interoperability failure
(Section 2).
Appendix B., paragraph 3:
OLD:
An algorithm has been added for determining if a payload is
associated with a specific identifier. (Section 3.1.4.1)
NEW:
An algorithm has been added for determining if a payload is
associated with a specific identifier (Section 3.1.4.1).
Appendix B., paragraph 4:
OLD:
The default charset of ISO-8859-1 for text media types has been
removed; the default is now whatever the media type definition says.
Likewise, special treatment of ISO-8859-1 has been removed from the
Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)
NEW:
The default charset of ISO-8859-1 for text media types has been
removed; the default is now whatever the media type definition says.
Likewise, special treatment of ISO-8859-1 has been removed from the
Accept-Charset header field. (Sections 3.1.1.3 and 5.3.3.)
Appendix B., paragraph 5:
OLD:
The definition of Content-Location has been changed to no longer
affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources.
(Section 3.1.4.2)
NEW:
The definition of Content-Location has been changed to no longer
affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources
(Section 3.1.4.2).
Appendix B., paragraph 6:
OLD:
To be consistent with the method-neutral parsing algorithm of
[RFC7230], the definition of GET has been relaxed so that requests
can have a body, even though a body has no meaning for GET.
(Section 4.3.1)
NEW:
To be consistent with the method-neutral parsing algorithm of
[RFC7230], the definition of GET has been relaxed so that requests
can have a body, even though a body has no meaning for GET
(Section 4.3.1).
Appendix B., paragraph 7:
OLD:
Servers are no longer required to handle all Content-* header fields
and use of Content-Range has been explicitly banned in PUT requests.
(Section 4.3.4)
NEW:
Servers are no longer required to handle all Content-* header fields
and use of Content-Range has been explicitly banned in PUT requests
(Section 4.3.4).
Appendix B., paragraph 8:
OLD:
Definition of the CONNECT method has been moved from [RFC2817] to
this specification. (Section 4.3.6)
NEW:
Definition of the CONNECT method has been moved from [RFC2817] to
this specification (Section 4.3.6).
Appendix B., paragraph 9:
OLD:
The OPTIONS and TRACE request methods have been defined as being
safe. (Section 4.3.7 and Section 4.3.8)
NEW:
The OPTIONS and TRACE request methods have been defined as being safe
(Section 4.3.7 and Section 4.3.8).
Appendix B., paragraph 10:
OLD:
The Expect header field's extension mechanism has been removed due to
widely-deployed broken implementations. (Section 5.1.1)
NEW:
The Expect header field's extension mechanism has been removed due to
widely deployed broken implementations (Section 5.1.1).
Appendix B., paragraph 11:
OLD:
The Max-Forwards header field has been restricted to the OPTIONS and
TRACE methods; previously, extension methods could have used it as
well. (Section 5.1.2)
NEW:
The Max-Forwards header field has been restricted to the OPTIONS and
TRACE methods; previously, extension methods could have used it as
well (Section 5.1.2).
Appendix B., paragraph 12:
OLD:
The "about:blank" URI has been suggested as a value for the Referer
header field when no referring URI is applicable, which distinguishes
that case from others where the Referer field is not sent or has been
removed. (Section 5.5.2)
NEW:
The "about:blank" URI has been suggested as a value for the Referer
header field when no referring URI is applicable, which distinguishes
that case from others where the Referer field is not sent or has been
removed (Section 5.5.2).
Appendix B., paragraph 13:
OLD:
The following status codes are now cacheable (that is, they can be
stored and reused by a cache without explicit freshness information
present): 204, 404, 405, 414, 501. (Section 6)
NEW:
The following status codes are now cacheable (that is, they can be
stored and reused by a cache without explicit freshness information
present): 204, 404, 405, 414, 501 (Section 6).
Appendix B., paragraph 14:
OLD:
The 201 (Created) status description has been changed to allow for
the possibility that more than one resource has been created.
(Section 6.3.2)
NEW:
The 201 (Created) status description has been changed to allow for
the possibility that more than one resource has been created
(Section 6.3.2).
Appendix B., paragraph 15:
OLD:
The definition of 203 (Non-Authoritative Information) has been
broadened to include cases of payload transformations as well.
(Section 6.3.4)
NEW:
The definition of 203 (Non-Authoritative Information) has been
broadened to include cases of payload transformations as well
(Section 6.3.4).
Appendix B., paragraph 16:
OLD:
The set of request methods that are safe to automatically redirect is
no longer closed; user agents are able to make that determination
based upon the request method semantics. The redirect status codes
301, 302, and 307 no longer have normative requirements on response
payloads and user interaction. (Section 6.4)
NEW:
The set of request methods that are safe to automatically redirect is
no longer closed; user agents are able to make that determination
based upon the request method semantics. The redirect status codes
301, 302, and 307 no longer have normative requirements on response
payloads and user interaction (Section 6.4).
Appendix B., paragraph 17:
OLD:
The status codes 301 and 302 have been changed to allow user agents
to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
NEW:
The status codes 301 and 302 have been changed to allow user agents
to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3.)
Appendix B., paragraph 18:
OLD:
The description of 303 (See Other) status code has been changed to
allow it to be cached if explicit freshness information is given, and
a specific definition has been added for a 303 response to GET.
(Section 6.4.4)
NEW:
The description of the 303 (See Other) status code has been changed
to allow it to be cached if explicit freshness information is given,
and a specific definition has been added for a 303 response to GET
(Section 6.4.4).
Appendix B., paragraph 19:
OLD:
The 305 (Use Proxy) status code has been deprecated due to security
concerns regarding in-band configuration of a proxy. (Section 6.4.5)
NEW:
The 305 (Use Proxy) status code has been deprecated due to security
concerns regarding in-band configuration of a proxy (Section 6.4.5).
Appendix B., paragraph 20:
OLD:
The 400 (Bad Request) status code has been relaxed so that it isn't
limited to syntax errors. (Section 6.5.1)
NEW:
The 400 (Bad Request) status code has been relaxed so that it isn't
limited to syntax errors (Section 6.5.1).
Appendix B., paragraph 21:
OLD:
The 426 (Upgrade Required) status code has been incorporated from
[RFC2817]. (Section 6.5.15)
NEW:
The 426 (Upgrade Required) status code has been incorporated from
[RFC2817] (Section 6.5.15).
Appendix B., paragraph 22:
OLD:
The target of requirements on HTTP-date and the Date header field
have been reduced to those systems generating the date, rather than
all systems sending a date. (Section 7.1.1)
NEW:
The target of requirements on HTTP-date and the Date header field
have been reduced to those systems generating the date, rather than
all systems sending a date (Section 7.1.1).
Appendix B., paragraph 23:
OLD:
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2)
NEW:
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate (Section 7.1.2).
Appendix B., paragraph 24:
OLD:
Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value. (Section 7.4.1)
NEW:
Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value (Section 7.4.1).
A Method Registry has been defined (Section 8.1).
Appendix B., paragraph 25:
OLD:
A Method Registry has been defined. (Section 8.1)
The Status Code Registry has been redefined by this specification;
previously, it was defined in Section 7.1 of [RFC2817].
(Section 8.2)
NEW:
The Status Code Registry has been redefined by this specification;
previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
Appendix B., paragraph 26:
OLD:
Registration of Content Codings has been changed to require IETF
Review. (Section 8.4)
NEW:
Registration of content codings has been changed to require IETF
Review (Section 8.4).
Section 1.2, paragraph 1:
OLD:
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
NEW:
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
Section 1.2, paragraph 3:
OLD:
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type
Date = HTTP-date
NEW:
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type
Date = HTTP-date
Section 1.2, paragraph 24:
OLD:
parameter = token "=" ( token / quoted-string )
partial-URI =
product = token [ "/" product-version ]
product-version = token
quoted-string =
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
NEW:
parameter = token "=" ( token / quoted-string )
partial-URI =
product = token [ "/" product-version ]
product-version = token
quoted-string =
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
Section 1.2, paragraph 30:
OLD:
Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in .
E.2. Since draft-ietf-httpbis-p2-semantics-24
Closed issues:
o : "Review
Cachability of Status Codes WRT 'Negative Caching'"
o : "RFC 1305 ref
needs to be updated to 5905"
o : "idempotency:
clarify 'effect'"
o : "APPSDIR
review of draft-ietf-httpbis-p2-semantics-24"
o : "move IANA
registrations to correct draft"
E.3. Since draft-ietf-httpbis-p2-semantics-25
Closed issues:
o : "Gen-Art
review of draft-ietf-httpbis-p2-semantics-24 with security
considerations"
o : "IESG ballot
on draft-ietf-httpbis-p2-semantics-25"
o : "add
'stateless' to Abstract"
o : "improve
introduction of list rule"
o : "requirement
on implementing methods according to their semantics"
o :
"considerations for new headers: privacy"
o : "augment
security considerations with pointers to current research"
E.4. Since draft-ietf-httpbis-p2-semantics-26
None yet.
Index
NEW:
Index
Section 1.2, paragraph 50:
OLD:
M
Max-Forwards header field 36
MIME-Version header field 89
NEW:
M
Max-Forwards header field 36
MIME-Version header field 88