draft-ietf-httpbis-p1-messaging-21.txt | draft-ietf-httpbis-p1-messaging-22.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. | Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. | |||
Updates: 2817 (if approved) greenbytes | Updates: 2817,2818 (if approved) greenbytes | |||
Intended status: Standards Track October 4, 2012 | Intended status: Standards Track February 23, 2013 | |||
Expires: April 7, 2013 | Expires: August 27, 2013 | |||
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing | |||
draft-ietf-httpbis-p1-messaging-21 | draft-ietf-httpbis-p1-messaging-22 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypertext information | protocol for distributed, collaborative, hypertext information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document provides an | information initiative since 1990. This document provides an | |||
overview of HTTP architecture and its associated terminology, defines | overview of HTTP architecture and its associated terminology, defines | |||
the "http" and "https" Uniform Resource Identifier (URI) schemes, | the "http" and "https" Uniform Resource Identifier (URI) schemes, | |||
defines the HTTP/1.1 message syntax and parsing requirements, and | defines the HTTP/1.1 message syntax and parsing requirements, and | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
Discussion of this draft takes place on the HTTPBIS working group | Discussion of this draft takes place on the HTTPBIS working group | |||
mailing list (ietf-http-wg@w3.org), which is archived at | mailing list (ietf-http-wg@w3.org), which is archived at | |||
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | The current issues list is at | |||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix D.22. | The changes in this draft are summarized in Appendix D.2. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on April 7, 2013. | This Internet-Draft will expire on August 27, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 51 | skipping to change at page 2, line 51 | |||
2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 | 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 | |||
2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 | 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 | |||
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 | 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 | |||
2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 | 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 | |||
2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 | 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 | |||
2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 | 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 | |||
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 | 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 | |||
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 | 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 | |||
2.7.3. http and https URI Normalization and Comparison . . . 18 | 2.7.3. http and https URI Normalization and Comparison . . . 18 | |||
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18 | 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 | 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 | 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 | |||
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 | 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 | |||
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 21 | 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.2.1. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 | 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 | |||
3.2.2. Field Parsing . . . . . . . . . . . . . . . . . . . . 23 | 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 | |||
3.2.3. Field Length . . . . . . . . . . . . . . . . . . . . . 24 | 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3.2.4. Field value components . . . . . . . . . . . . . . . . 24 | 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 | |||
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 | ||||
3.2.6. Field value components . . . . . . . . . . . . . . . . 25 | ||||
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 | 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 26 | 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 | |||
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 | 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 28 | |||
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 29 | 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 | |||
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 31 | 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 | |||
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 32 | 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 | |||
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 32 | 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 33 | 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 | |||
4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 34 | 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 35 | 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 | |||
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 35 | 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 | |||
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 35 | 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 | |||
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 35 | 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 | |||
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 36 | 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 | |||
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 37 | 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 37 | 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 | |||
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 37 | 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 | |||
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 38 | 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 41 | 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 | |||
5.6. Message Forwarding . . . . . . . . . . . . . . . . . . . . 42 | 5.6. Associating a Response to a Request . . . . . . . . . . . 44 | |||
5.7. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 | |||
5.8. Message Transforming . . . . . . . . . . . . . . . . . . . 44 | 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
5.9. Associating a Response to a Request . . . . . . . . . . . 46 | 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 | |||
6. Connection Management . . . . . . . . . . . . . . . . . . . . 46 | 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 | |||
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46 | 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
6.2. Persistent Connections . . . . . . . . . . . . . . . . . . 48 | 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 | |||
6.2.1. Establishment . . . . . . . . . . . . . . . . . . . . 49 | 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
6.2.2. Reuse . . . . . . . . . . . . . . . . . . . . . . . . 50 | 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 50 | |||
6.2.3. Concurrency . . . . . . . . . . . . . . . . . . . . . 51 | 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 | |||
6.2.4. Failures and Time-outs . . . . . . . . . . . . . . . . 51 | 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
6.2.5. Tear-down . . . . . . . . . . . . . . . . . . . . . . 52 | 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 | |||
6.3. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 | 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
7.1. Header Field Registration . . . . . . . . . . . . . . . . 54 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 | |||
7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 55 | 7.1. Header Field Registration . . . . . . . . . . . . . . . . 55 | |||
7.3. Internet Media Type Registrations . . . . . . . . . . . . 56 | 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 | |||
7.3.1. Internet Media Type message/http . . . . . . . . . . . 56 | 7.3. Internet Media Type Registration . . . . . . . . . . . . . 56 | |||
7.3.2. Internet Media Type application/http . . . . . . . . . 57 | 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 | |||
7.3.2. Internet Media Type application/http . . . . . . . . . 58 | ||||
7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 58 | 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 | |||
7.5. Transfer Coding Registrations . . . . . . . . . . . . . . 58 | 7.5. Transfer Coding Registration . . . . . . . . . . . . . . . 59 | |||
7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 59 | 7.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 60 | |||
7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 60 | 7.7. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 60 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 | |||
8.1. Personal Information . . . . . . . . . . . . . . . . . . . 60 | 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 | |||
8.2. Abuse of Server Log Information . . . . . . . . . . . . . 60 | 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 | |||
8.3. Attacks Based On File and Path Names . . . . . . . . . . . 61 | 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 62 | |||
8.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 61 | 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 62 | |||
8.5. Intermediaries and Caching . . . . . . . . . . . . . . . . 61 | 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 63 | |||
8.6. Protocol Element Size Overflows . . . . . . . . . . . . . 62 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 65 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 66 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 65 | Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 68 | |||
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 67 | A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 69 | |||
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 67 | A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 69 | |||
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 68 | A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 69 | |||
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 68 | A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 70 | |||
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 69 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 | |||
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 69 | Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 72 | |||
Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 70 | Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 | |||
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71 | ||||
Appendix D. Change Log (to be removed by RFC Editor before | Appendix D. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 74 | publication) . . . . . . . . . . . . . . . . . . . . 76 | |||
D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 74 | D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 | |||
D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 74 | D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 76 | |||
D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 | |||
D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 | ||||
D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 77 | ||||
D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 | ||||
D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 78 | ||||
D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 79 | ||||
D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 | ||||
D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 80 | ||||
D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 80 | ||||
D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 81 | ||||
D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 81 | ||||
D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 82 | ||||
D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 82 | ||||
D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 83 | ||||
D.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 83 | ||||
D.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 83 | ||||
D.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 84 | ||||
D.20. Since draft-ietf-httpbis-p1-messaging-18 . . . . . . . . . 84 | ||||
D.21. Since draft-ietf-httpbis-p1-messaging-19 . . . . . . . . . 84 | ||||
D.22. Since draft-ietf-httpbis-p1-messaging-20 . . . . . . . . . 85 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 | ||||
1. Introduction | 1. Introduction | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
request/response protocol that uses extensible semantics and MIME- | request/response protocol that uses extensible semantics and self- | |||
like message payloads for flexible interaction with network-based | descriptive message payloads for flexible interaction with network- | |||
hypertext information systems. This document is the first in a | based hypertext information systems. This document is the first in a | |||
series of documents that collectively form the HTTP/1.1 | series of documents that collectively form the HTTP/1.1 | |||
specification: | specification: | |||
RFC xxx1: Message Syntax and Routing | RFC xxx1: Message Syntax and Routing | |||
RFC xxx2: Semantics and Content | RFC xxx2: Semantics and Content | |||
RFC xxx3: Conditional Requests | RFC xxx3: Conditional Requests | |||
RFC xxx4: Range Requests | RFC xxx4: Range Requests | |||
RFC xxx5: Caching | RFC xxx5: Caching | |||
RFC xxx6: Authentication | RFC xxx6: Authentication | |||
This HTTP/1.1 specification obsoletes and moves to historic status | This HTTP/1.1 specification obsoletes and moves to historic status | |||
RFC 2616, its predecessor RFC 2068, RFC 2145 (on HTTP versioning), | RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP | |||
and RFC 2817 (on using CONNECT for TLS upgrades). | versioning). This specification also updates the use of CONNECT to | |||
establish a tunnel, previously defined in RFC 2817, and defines the | ||||
"https" URI scheme that was described informally in RFC 2818. | ||||
HTTP is a generic interface protocol for information systems. It is | HTTP is a generic interface protocol for information systems. It is | |||
designed to hide the details of how a service is implemented by | designed to hide the details of how a service is implemented by | |||
presenting a uniform interface to clients that is independent of the | presenting a uniform interface to clients that is independent of the | |||
types of resources provided. Likewise, servers do not need to be | types of resources provided. Likewise, servers do not need to be | |||
aware of each client's purpose: an HTTP request can be considered in | aware of each client's purpose: an HTTP request can be considered in | |||
isolation rather than being associated with a specific type of client | isolation rather than being associated with a specific type of client | |||
or a predetermined sequence of application steps. The result is a | or a predetermined sequence of application steps. The result is a | |||
protocol that can be used effectively in many different contexts and | protocol that can be used effectively in many different contexts and | |||
for which implementations can evolve independently over time. | for which implementations can evolve independently over time. | |||
HTTP is also designed for use as an intermediation protocol for | HTTP is also designed for use as an intermediation protocol for | |||
translating communication to and from non-HTTP information systems. | translating communication to and from non-HTTP information systems. | |||
HTTP proxies and gateways can provide access to alternative | HTTP proxies and gateways can provide access to alternative | |||
information services by translating their diverse protocols into a | information services by translating their diverse protocols into a | |||
hypertext format that can be viewed and manipulated by clients in the | hypertext format that can be viewed and manipulated by clients in the | |||
same way as HTTP services. | same way as HTTP services. | |||
One consequence of HTTP flexibility is that the protocol cannot be | One consequence of this flexibility is that the protocol cannot be | |||
defined in terms of what occurs behind the interface. Instead, we | defined in terms of what occurs behind the interface. Instead, we | |||
are limited to defining the syntax of communication, the intent of | are limited to defining the syntax of communication, the intent of | |||
received communication, and the expected behavior of recipients. If | received communication, and the expected behavior of recipients. If | |||
the communication is considered in isolation, then successful actions | the communication is considered in isolation, then successful actions | |||
ought to be reflected in corresponding changes to the observable | ought to be reflected in corresponding changes to the observable | |||
interface provided by servers. However, since multiple clients might | interface provided by servers. However, since multiple clients might | |||
act in parallel and perhaps at cross-purposes, we cannot require that | act in parallel and perhaps at cross-purposes, we cannot require that | |||
such changes be observable beyond the scope of a single response. | such changes be observable beyond the scope of a single response. | |||
This document describes the architectural elements that are used or | This document describes the architectural elements that are used or | |||
skipping to change at page 7, line 18 | skipping to change at page 7, line 18 | |||
exchanging messages (Section 3) across a reliable transport or | exchanging messages (Section 3) across a reliable transport or | |||
session-layer "connection" (Section 6). An HTTP "client" is a | session-layer "connection" (Section 6). An HTTP "client" is a | |||
program that establishes a connection to a server for the purpose of | program that establishes a connection to a server for the purpose of | |||
sending one or more HTTP requests. An HTTP "server" is a program | sending one or more HTTP requests. An HTTP "server" is a program | |||
that accepts connections in order to service HTTP requests by sending | that accepts connections in order to service HTTP requests by sending | |||
HTTP responses. | HTTP responses. | |||
The terms client and server refer only to the roles that these | The terms client and server refer only to the roles that these | |||
programs perform for a particular connection. The same program might | programs perform for a particular connection. The same program might | |||
act as a client on some connections and a server on others. We use | act as a client on some connections and a server on others. We use | |||
the term "user agent" to refer to the program that initiates a | the term "user agent" to refer to any of the various client programs | |||
request, such as a WWW browser, editor, or spider (web-traversing | that initiate a request, including (but not limited to) browsers, | |||
robot), and the term "origin server" to refer to the program that can | spiders (web-based robots), command-line tools, native applications, | |||
originate authoritative responses to a request. For general | and mobile apps. The term "origin server" is used to refer to the | |||
requirements, we use the term "sender" to refer to whichever | program that can originate authoritative responses to a request. For | |||
component sent a given message and the term "recipient" to refer to | general requirements, we use the terms "sender" and "recipient" to | |||
any component that receives the message. | refer to any component that sends or receives, respectively, a given | |||
message. | ||||
HTTP relies upon the Uniform Resource Identifier (URI) standard | HTTP relies upon the Uniform Resource Identifier (URI) standard | |||
[RFC3986] to indicate the target resource (Section 5.1) and | [RFC3986] to indicate the target resource (Section 5.1) and | |||
relationships between resources. Messages are passed in a format | relationships between resources. Messages are passed in a format | |||
similar to that used by Internet mail [RFC5322] and the Multipurpose | similar to that used by Internet mail [RFC5322] and the Multipurpose | |||
Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] | Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] | |||
for the differences between HTTP and MIME messages). | for the differences between HTTP and MIME messages). | |||
Most HTTP communication consists of a retrieval request (GET) for a | Most HTTP communication consists of a retrieval request (GET) for a | |||
representation of some resource identified by a URI. In the simplest | representation of some resource identified by a URI. In the simplest | |||
skipping to change at page 8, line 12 | skipping to change at page 8, line 13 | |||
A server responds to a client's request by sending one or more HTTP | A server responds to a client's request by sending one or more HTTP | |||
response messages, each beginning with a status line that includes | response messages, each beginning with a status line that includes | |||
the protocol version, a success or error code, and textual reason | the protocol version, a success or error code, and textual reason | |||
phrase (Section 3.1.2), possibly followed by header fields containing | phrase (Section 3.1.2), possibly followed by header fields containing | |||
server information, resource metadata, and representation metadata | server information, resource metadata, and representation metadata | |||
(Section 3.2), an empty line to indicate the end of the header | (Section 3.2), an empty line to indicate the end of the header | |||
section, and finally a message body containing the payload body (if | section, and finally a message body containing the payload body (if | |||
any, Section 3.3). | any, Section 3.3). | |||
A connection might be used for multiple request/response exchanges, | A connection might be used for multiple request/response exchanges, | |||
as defined in Section 6.2. | as defined in Section 6.3. | |||
The following example illustrates a typical message exchange for a | The following example illustrates a typical message exchange for a | |||
GET request on the URI "http://www.example.com/hello.txt": | GET request on the URI "http://www.example.com/hello.txt": | |||
client request: | client request: | |||
GET /hello.txt HTTP/1.1 | GET /hello.txt HTTP/1.1 | |||
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 | User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 | |||
Host: www.example.com | Host: www.example.com | |||
Accept-Language: en, mi | Accept-Language: en, mi | |||
skipping to change at page 8, line 38 | skipping to change at page 8, line 39 | |||
Server: Apache | Server: Apache | |||
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT | Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT | |||
ETag: "34aa387-d-1568eb00" | ETag: "34aa387-d-1568eb00" | |||
Accept-Ranges: bytes | Accept-Ranges: bytes | |||
Content-Length: 14 | Content-Length: 14 | |||
Vary: Accept-Encoding | Vary: Accept-Encoding | |||
Content-Type: text/plain | Content-Type: text/plain | |||
Hello World! | Hello World! | |||
(Note that the content length includes the trailing CR/LF sequence of | ||||
the body text) | ||||
2.2. Implementation Diversity | 2.2. Implementation Diversity | |||
When considering the design of HTTP, it is easy to fall into a trap | When considering the design of HTTP, it is easy to fall into a trap | |||
of thinking that all user agents are general-purpose browsers and all | of thinking that all user agents are general-purpose browsers and all | |||
origin servers are large public websites. That is not the case in | origin servers are large public websites. That is not the case in | |||
practice. Common HTTP user agents include household appliances, | practice. Common HTTP user agents include household appliances, | |||
stereos, scales, firmware update scripts, command-line programs, | stereos, scales, firmware update scripts, command-line programs, | |||
mobile apps, and communication devices in a multitude of shapes and | mobile apps, and communication devices in a multitude of shapes and | |||
sizes. Likewise, common HTTP origin servers include home automation | sizes. Likewise, common HTTP origin servers include home automation | |||
units, configurable networking components, office machines, | units, configurable networking components, office machines, | |||
skipping to change at page 9, line 20 | skipping to change at page 9, line 23 | |||
erroneous). Spiders, for example, are typically given a start URI | erroneous). Spiders, for example, are typically given a start URI | |||
and configured to follow certain behavior while crawling the Web as a | and configured to follow certain behavior while crawling the Web as a | |||
hypertext graph. | hypertext graph. | |||
The implementation diversity of HTTP means that we cannot assume the | The implementation diversity of HTTP means that we cannot assume the | |||
user agent can make interactive suggestions to a user or provide | user agent can make interactive suggestions to a user or provide | |||
adequate warning for security or privacy options. In the few cases | adequate warning for security or privacy options. In the few cases | |||
where this specification requires reporting of errors to the user, it | where this specification requires reporting of errors to the user, it | |||
is acceptable for such reporting to only be observable in an error | is acceptable for such reporting to only be observable in an error | |||
console or log file. Likewise, requirements that an automated action | console or log file. Likewise, requirements that an automated action | |||
be confirmed by the user before proceeding can me met via advance | be confirmed by the user before proceeding can be met via advance | |||
configuration choices, run-time options, or simply not proceeding | configuration choices, run-time options, or simply not proceeding | |||
with the unsafe action. | with the unsafe action. | |||
2.3. Intermediaries | 2.3. Intermediaries | |||
HTTP enables the use of intermediaries to satisfy requests through a | HTTP enables the use of intermediaries to satisfy requests through a | |||
chain of connections. There are three common forms of HTTP | chain of connections. There are three common forms of HTTP | |||
intermediary: proxy, gateway, and tunnel. In some cases, a single | intermediary: proxy, gateway, and tunnel. In some cases, a single | |||
intermediary might act as an origin server, proxy, gateway, or | intermediary might act as an origin server, proxy, gateway, or | |||
tunnel, switching behavior based on the nature of each request. | tunnel, switching behavior based on the nature of each request. | |||
skipping to change at page 10, line 30 | skipping to change at page 10, line 34 | |||
that would be significant to the original sender or potentially | that would be significant to the original sender or potentially | |||
significant to downstream recipients). For example, a transforming | significant to downstream recipients). For example, a transforming | |||
proxy might be acting as a shared annotation server (modifying | proxy might be acting as a shared annotation server (modifying | |||
responses to include references to a local annotation database), a | responses to include references to a local annotation database), a | |||
malware filter, a format transcoder, or an intranet-to-Internet | malware filter, a format transcoder, or an intranet-to-Internet | |||
privacy filter. Such transformations are presumed to be desired by | privacy filter. Such transformations are presumed to be desired by | |||
the client (or client organization) that selected the proxy and are | the client (or client organization) that selected the proxy and are | |||
beyond the scope of this specification. However, when a proxy is not | beyond the scope of this specification. However, when a proxy is not | |||
intended to transform a given message, we use the term "non- | intended to transform a given message, we use the term "non- | |||
transforming proxy" to target requirements that preserve HTTP message | transforming proxy" to target requirements that preserve HTTP message | |||
semantics. See Section 7.3.4 of [Part2] and Section 7.5 of [Part6] | semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] | |||
for status and warning codes related to transformations. | for status and warning codes related to transformations. | |||
A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts | A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts | |||
as a layer above some other server(s) and translates the received | as a layer above some other server(s) and translates the received | |||
requests to the underlying server's protocol. Gateways are often | requests to the underlying server's protocol. Gateways are often | |||
used to encapsulate legacy or untrusted information services, to | used to encapsulate legacy or untrusted information services, to | |||
improve server performance through "accelerator" caching, and to | improve server performance through "accelerator" caching, and to | |||
enable partitioning or load-balancing of HTTP services across | enable partitioning or load-balancing of HTTP services across | |||
multiple machines. | multiple machines. | |||
A gateway behaves as an origin server on its outbound connection and | A gateway behaves as an origin server on its outbound connection and | |||
as a user agent on its inbound connection. All HTTP requirements | as a user agent on its inbound connection. All HTTP requirements | |||
applicable to an origin server also apply to the outbound | applicable to an origin server also apply to the outbound | |||
communication of a gateway. A gateway communicates with inbound | communication of a gateway. A gateway communicates with inbound | |||
servers using any protocol that it desires, including private | servers using any protocol that it desires, including private | |||
extensions to HTTP that are outside the scope of this specification. | extensions to HTTP that are outside the scope of this specification. | |||
However, an HTTP-to-HTTP gateway that wishes to interoperate with | However, an HTTP-to-HTTP gateway that wishes to interoperate with | |||
third-party HTTP servers MUST conform to HTTP user agent requirements | third-party HTTP servers MUST conform to HTTP user agent requirements | |||
on the gateway's inbound connection and MUST implement the Connection | on the gateway's inbound connection and MUST implement the Connection | |||
(Section 6.1) and Via (Section 5.7) header fields for both | (Section 6.1) and Via (Section 5.7.1) header fields for both | |||
connections. | connections. | |||
A "tunnel" acts as a blind relay between two connections without | A "tunnel" acts as a blind relay between two connections without | |||
changing the messages. Once active, a tunnel is not considered a | changing the messages. Once active, a tunnel is not considered a | |||
party to the HTTP communication, though the tunnel might have been | party to the HTTP communication, though the tunnel might have been | |||
initiated by an HTTP request. A tunnel ceases to exist when both | initiated by an HTTP request. A tunnel ceases to exist when both | |||
ends of the relayed connection are closed. Tunnels are used to | ends of the relayed connection are closed. Tunnels are used to | |||
extend a virtual connection through an intermediary, such as when | extend a virtual connection through an intermediary, such as when | |||
Transport Layer Security (TLS, [RFC5246]) is used to establish | Transport Layer Security (TLS, [RFC5246]) is used to establish | |||
confidential communication through a shared firewall proxy. | confidential communication through a shared firewall proxy. | |||
skipping to change at page 11, line 34 | skipping to change at page 11, line 38 | |||
TCP port 80 packets (and occasionally other common port traffic). | TCP port 80 packets (and occasionally other common port traffic). | |||
Interception proxies are commonly found on public network access | Interception proxies are commonly found on public network access | |||
points, as a means of enforcing account subscription prior to | points, as a means of enforcing account subscription prior to | |||
allowing use of non-local Internet services, and within corporate | allowing use of non-local Internet services, and within corporate | |||
firewalls to enforce network usage policies. They are | firewalls to enforce network usage policies. They are | |||
indistinguishable from a man-in-the-middle attack. | indistinguishable from a man-in-the-middle attack. | |||
HTTP is defined as a stateless protocol, meaning that each request | HTTP is defined as a stateless protocol, meaning that each request | |||
message can be understood in isolation. Many implementations depend | message can be understood in isolation. Many implementations depend | |||
on HTTP's stateless design in order to reuse proxied connections or | on HTTP's stateless design in order to reuse proxied connections or | |||
dynamically load balance requests across multiple servers. Hence, | dynamically load-balance requests across multiple servers. Hence, | |||
servers MUST NOT assume that two requests on the same connection are | servers MUST NOT assume that two requests on the same connection are | |||
from the same user agent unless the connection is secured and | from the same user agent unless the connection is secured and | |||
specific to that agent. Some non-standard HTTP extensions (e.g., | specific to that agent. Some non-standard HTTP extensions (e.g., | |||
[RFC4559]) have been known to violate this requirement, resulting in | [RFC4559]) have been known to violate this requirement, resulting in | |||
security and interoperability problems. | security and interoperability problems. | |||
2.4. Caches | 2.4. Caches | |||
A "cache" is a local store of previous response messages and the | A "cache" is a local store of previous response messages and the | |||
subsystem that controls its message storage, retrieval, and deletion. | subsystem that controls its message storage, retrieval, and deletion. | |||
A cache stores cacheable responses in order to reduce the response | A cache stores cacheable responses in order to reduce the response | |||
time and network bandwidth consumption on future, equivalent | time and network bandwidth consumption on future, equivalent | |||
requests. Any client or server MAY employ a cache, though a cache | requests. Any client or server MAY employ a cache, though a cache | |||
cannot be used by a server while it is acting as a tunnel. | cannot be used by a server while it is acting as a tunnel. | |||
The effect of a cache is that the request/response chain is shortened | The effect of a cache is that the request/response chain is shortened | |||
if one of the participants along the chain has a cached response | if one of the participants along the chain has a cached response | |||
applicable to that request. The following illustrates the resulting | applicable to that request. The following illustrates the resulting | |||
chain if B has a cached copy of an earlier response from O (via C) | chain if B has a cached copy of an earlier response from O (via C) | |||
for a request which has not been cached by UA or A. | for a request that has not been cached by UA or A. | |||
> > | > > | |||
UA =========== A =========== B - - - - - - C - - - - - - O | UA =========== A =========== B - - - - - - C - - - - - - O | |||
< < | < < | |||
A response is "cacheable" if a cache is allowed to store a copy of | A response is "cacheable" if a cache is allowed to store a copy of | |||
the response message for use in answering subsequent requests. Even | the response message for use in answering subsequent requests. Even | |||
when a response is cacheable, there might be additional constraints | when a response is cacheable, there might be additional constraints | |||
placed by the client or by the origin server on when that cached | placed by the client or by the origin server on when that cached | |||
response can be used for a particular request. HTTP requirements for | response can be used for a particular request. HTTP requirements for | |||
cache behavior and cacheable responses are defined in Section 2 of | cache behavior and cacheable responses are defined in Section 2 of | |||
[Part6]. | [Part6]. | |||
There are a wide variety of architectures and configurations of | There are a wide variety of architectures and configurations of | |||
caches and proxies deployed across the World Wide Web and inside | caches deployed across the World Wide Web and inside large | |||
large organizations. These systems include national hierarchies of | organizations. These include national hierarchies of proxy caches to | |||
proxy caches to save transoceanic bandwidth, systems that broadcast | save transoceanic bandwidth, collaborative systems that broadcast or | |||
or multicast cache entries, organizations that distribute subsets of | multicast cache entries, archives of pre-fetched cache entries for | |||
cached data via optical media, and so on. | use in off-line or high-latency environments, and so on. | |||
2.5. Conformance and Error Handling | 2.5. Conformance and Error Handling | |||
This specification targets conformance criteria according to the role | This specification targets conformance criteria according to the role | |||
of a participant in HTTP communication. Hence, HTTP requirements are | of a participant in HTTP communication. Hence, HTTP requirements are | |||
placed on senders, recipients, clients, servers, user agents, | placed on senders, recipients, clients, servers, user agents, | |||
intermediaries, origin servers, proxies, gateways, or caches, | intermediaries, origin servers, proxies, gateways, or caches, | |||
depending on what behavior is being constrained by the requirement. | depending on what behavior is being constrained by the requirement. | |||
Additional (social) requirements are placed on implementations, | Additional (social) requirements are placed on implementations, | |||
resource owners, and protocol element registrations when they apply | resource owners, and protocol element registrations when they apply | |||
skipping to change at page 15, line 23 | skipping to change at page 15, line 28 | |||
performed unless triggered by specific client attributes, such as | performed unless triggered by specific client attributes, such as | |||
when one or more of the request header fields (e.g., User-Agent) | when one or more of the request header fields (e.g., User-Agent) | |||
uniquely match the values sent by a client known to be in error. | uniquely match the values sent by a client known to be in error. | |||
The intention of HTTP's versioning design is that the major number | The intention of HTTP's versioning design is that the major number | |||
will only be incremented if an incompatible message syntax is | will only be incremented if an incompatible message syntax is | |||
introduced, and that the minor number will only be incremented when | introduced, and that the minor number will only be incremented when | |||
changes made to the protocol have the effect of adding to the message | changes made to the protocol have the effect of adding to the message | |||
semantics or implying additional capabilities of the sender. | semantics or implying additional capabilities of the sender. | |||
However, the minor version was not incremented for the changes | However, the minor version was not incremented for the changes | |||
introduced between [RFC2068] and [RFC2616], and this revision is | introduced between [RFC2068] and [RFC2616], and this revision has | |||
specifically avoiding any such changes to the protocol. | specifically avoiding any such changes to the protocol. | |||
2.7. Uniform Resource Identifiers | 2.7. Uniform Resource Identifiers | |||
Uniform Resource Identifiers (URIs) [RFC3986] are used throughout | Uniform Resource Identifiers (URIs) [RFC3986] are used throughout | |||
HTTP as the means for identifying resources (Section 2 of [Part2]). | HTTP as the means for identifying resources (Section 2 of [Part2]). | |||
URI references are used to target requests, indicate redirects, and | URI references are used to target requests, indicate redirects, and | |||
define relationships. | define relationships. | |||
This specification adopts the definitions of "URI-reference", | This specification adopts the definitions of "URI-reference", | |||
"absolute-URI", "relative-part", "port", "host", "path-abempty", | "absolute-URI", "relative-part", "port", "host", "path-abempty", | |||
"path-absolute", "query", and "authority" from the URI generic | "query", "segment", and "authority" from the URI generic syntax. In | |||
syntax. In addition, we define a partial-URI rule for protocol | addition, we define an "absolute-path" rule (that differs from RFC | |||
elements that allow a relative URI but not a fragment. | 3986's "path-absolute" in that it allows a leading "//") and a | |||
"partial-URI" rule for protocol elements that allow a relative URI | ||||
but not a fragment. | ||||
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | |||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | |||
relative-part = <relative-part, defined in [RFC3986], Section 4.2> | relative-part = <relative-part, defined in [RFC3986], Section 4.2> | |||
authority = <authority, defined in [RFC3986], Section 3.2> | authority = <authority, defined in [RFC3986], Section 3.2> | |||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | |||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> | ||||
port = <port, defined in [RFC3986], Section 3.2.3> | port = <port, defined in [RFC3986], Section 3.2.3> | |||
query = <query, defined in [RFC3986], Section 3.4> | query = <query, defined in [RFC3986], Section 3.4> | |||
segment = <segment, defined in [RFC3986], Section 3.3> | ||||
uri-host = <host, defined in [RFC3986], Section 3.2.2> | uri-host = <host, defined in [RFC3986], Section 3.2.2> | |||
absolute-path = 1*( "/" segment ) | ||||
partial-URI = relative-part [ "?" query ] | partial-URI = relative-part [ "?" query ] | |||
Each protocol element in HTTP that allows a URI reference will | Each protocol element in HTTP that allows a URI reference will | |||
indicate in its ABNF production whether the element allows any form | indicate in its ABNF production whether the element allows any form | |||
of reference (URI-reference), only a URI in absolute form (absolute- | of reference (URI-reference), only a URI in absolute form (absolute- | |||
URI), only the path and optional query components, or some | URI), only the path and optional query components, or some | |||
combination of the above. Unless otherwise indicated, URI references | combination of the above. Unless otherwise indicated, URI references | |||
are parsed relative to the effective request URI (Section 5.5). | are parsed relative to the effective request URI (Section 5.5). | |||
2.7.1. http URI scheme | 2.7.1. http URI scheme | |||
skipping to change at page 16, line 26 | skipping to change at page 16, line 41 | |||
http-URI = "http:" "//" authority path-abempty [ "?" query ] | http-URI = "http:" "//" authority path-abempty [ "?" query ] | |||
The HTTP origin server is identified by the generic syntax's | The HTTP origin server is identified by the generic syntax's | |||
authority component, which includes a host identifier and optional | authority component, which includes a host identifier and optional | |||
TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, | TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, | |||
consisting of both the hierarchical path component and optional query | consisting of both the hierarchical path component and optional query | |||
component, serves as an identifier for a potential resource within | component, serves as an identifier for a potential resource within | |||
that origin server's name space. | that origin server's name space. | |||
If the host identifier is provided as an IP literal or IPv4 address, | If the host identifier is provided as an IP address, then the origin | |||
then the origin server is any listener on the indicated TCP port at | server is any listener on the indicated TCP port at that IP address. | |||
that IP address. If host is a registered name, then that name is | If host is a registered name, then that name is considered an | |||
considered an indirect identifier and the recipient might use a name | indirect identifier and the recipient might use a name resolution | |||
resolution service, such as DNS, to find the address of a listener | service, such as DNS, to find the address of a listener for that | |||
for that host. The host MUST NOT be empty; if an "http" URI is | host. The host MUST NOT be empty; if an "http" URI is received with | |||
received with an empty host, then it MUST be rejected as invalid. If | an empty host, then it MUST be rejected as invalid. If the port | |||
the port subcomponent is empty or not given, then TCP port 80 is | subcomponent is empty or not given, then TCP port 80 is assumed (the | |||
assumed (the default reserved port for WWW services). | default reserved port for WWW services). | |||
Regardless of the form of host identifier, access to that host is not | Regardless of the form of host identifier, access to that host is not | |||
implied by the mere presence of its name or address. The host might | implied by the mere presence of its name or address. The host might | |||
or might not exist and, even when it does exist, might or might not | or might not exist and, even when it does exist, might or might not | |||
be running an HTTP server or listening to the indicated port. The | be running an HTTP server or listening to the indicated port. The | |||
"http" URI scheme makes use of the delegated nature of Internet names | "http" URI scheme makes use of the delegated nature of Internet names | |||
and addresses to establish a naming authority (whatever entity has | and addresses to establish a naming authority (whatever entity has | |||
the ability to place an HTTP server at that Internet name or address) | the ability to place an HTTP server at that Internet name or address) | |||
and allows that authority to determine which names are valid and how | and allows that authority to determine which names are valid and how | |||
they might be used. | they might be used. | |||
When an "http" URI is used within a context that calls for access to | When an "http" URI is used within a context that calls for access to | |||
the indicated resource, a client MAY attempt access by resolving the | the indicated resource, a client MAY attempt access by resolving the | |||
host to an IP address, establishing a TCP connection to that address | host to an IP address, establishing a TCP connection to that address | |||
on the indicated port, and sending an HTTP request message | on the indicated port, and sending an HTTP request message | |||
(Section 3) containing the URI's identifying data (Section 5) to the | (Section 3) containing the URI's identifying data (Section 5) to the | |||
server. If the server responds to that request with a non-interim | server. If the server responds to that request with a non-interim | |||
HTTP response message, as described in Section 7 of [Part2], then | HTTP response message, as described in Section 6 of [Part2], then | |||
that response is considered an authoritative answer to the client's | that response is considered an authoritative answer to the client's | |||
request. | request. | |||
Although HTTP is independent of the transport protocol, the "http" | Although HTTP is independent of the transport protocol, the "http" | |||
scheme is specific to TCP-based services because the name delegation | scheme is specific to TCP-based services because the name delegation | |||
process depends on TCP for establishing authority. An HTTP service | process depends on TCP for establishing authority. An HTTP service | |||
based on some other underlying connection protocol would presumably | based on some other underlying connection protocol would presumably | |||
be identified using a different URI scheme, just as the "https" | be identified using a different URI scheme, just as the "https" | |||
scheme (below) is used for resources that require an end-to-end | scheme (below) is used for resources that require an end-to-end | |||
secured connection. Other protocols might also be used to provide | secured connection. Other protocols might also be used to provide | |||
access to "http" identified resources -- it is only the authoritative | access to "http" identified resources -- it is only the authoritative | |||
interface used for mapping the namespace that is specific to TCP. | interface used for mapping the namespace that is specific to TCP. | |||
The URI generic syntax for authority also includes a deprecated | The URI generic syntax for authority also includes a deprecated | |||
userinfo subcomponent ([RFC3986], Section 3.2.1) for including user | userinfo subcomponent ([RFC3986], Section 3.2.1) for including user | |||
authentication information in the URI. Some implementations make use | authentication information in the URI. Some implementations make use | |||
of the userinfo component for internal configuration of | of the userinfo component for internal configuration of | |||
authentication information, such as within command invocation | authentication information, such as within command invocation | |||
options, configuration files, or bookmark lists, even though such | options, configuration files, or bookmark lists, even though such | |||
usage might expose a user identifier or password. Senders MUST NOT | usage might expose a user identifier or password. Senders MUST | |||
include a userinfo subcomponent (and its "@" delimiter) when | exclude the userinfo subcomponent (and its "@" delimiter) when an | |||
transmitting an "http" URI in a message. Recipients of HTTP messages | "http" URI is transmitted within a message as a request target or | |||
that contain a URI reference SHOULD parse for the existence of | header field value. Recipients of an "http" URI reference SHOULD | |||
userinfo and treat its presence as an error, likely indicating that | parse for userinfo and treat its presence as an error, since it is | |||
the deprecated subcomponent is being used to obscure the authority | likely being used to obscure the authority for the sake of phishing | |||
for the sake of phishing attacks. | attacks. | |||
2.7.2. https URI scheme | 2.7.2. https URI scheme | |||
The "https" URI scheme is hereby defined for the purpose of minting | The "https" URI scheme is hereby defined for the purpose of minting | |||
identifiers according to their association with the hierarchical | identifiers according to their association with the hierarchical | |||
namespace governed by a potential HTTP origin server listening to a | namespace governed by a potential HTTP origin server listening to a | |||
given TCP port for TLS-secured connections [RFC5246]. | given TCP port for TLS-secured connections [RFC5246]. | |||
All of the requirements listed above for the "http" scheme are also | All of the requirements listed above for the "http" scheme are also | |||
requirements for the "https" scheme, except that a default TCP port | requirements for the "https" scheme, except that a default TCP port | |||
of 443 is assumed if the port subcomponent is empty or not given, and | of 443 is assumed if the port subcomponent is empty or not given, and | |||
the TCP connection MUST be secured, end-to-end, through the use of | the TCP connection MUST be secured, end-to-end, through the use of | |||
strong encryption prior to sending the first HTTP request. | strong encryption prior to sending the first HTTP request. | |||
https-URI = "https:" "//" authority path-abempty [ "?" query ] | https-URI = "https:" "//" authority path-abempty [ "?" query ] | |||
Unlike the "http" scheme, responses to "https" identified requests | ||||
are never "public" and thus MUST NOT be reused for shared caching. | ||||
They can, however, be reused in a private cache if the message is | ||||
cacheable by default in HTTP or specifically indicated as such by the | ||||
Cache-Control header field (Section 7.2 of [Part6]). | ||||
Resources made available via the "https" scheme have no shared | Resources made available via the "https" scheme have no shared | |||
identity with the "http" scheme even if their resource identifiers | identity with the "http" scheme even if their resource identifiers | |||
indicate the same authority (the same host listening to the same TCP | indicate the same authority (the same host listening to the same TCP | |||
port). They are distinct name spaces and are considered to be | port). They are distinct name spaces and are considered to be | |||
distinct origin servers. However, an extension to HTTP that is | distinct origin servers. However, an extension to HTTP that is | |||
defined to apply to entire host domains, such as the Cookie protocol | defined to apply to entire host domains, such as the Cookie protocol | |||
[RFC6265], can allow information set by one service to impact | [RFC6265], can allow information set by one service to impact | |||
communication with other services within a matching group of host | communication with other services within a matching group of host | |||
domains. | domains. | |||
skipping to change at page 18, line 26 | skipping to change at page 18, line 34 | |||
resource is defined in [RFC2818]. | resource is defined in [RFC2818]. | |||
2.7.3. http and https URI Normalization and Comparison | 2.7.3. http and https URI Normalization and Comparison | |||
Since the "http" and "https" schemes conform to the URI generic | Since the "http" and "https" schemes conform to the URI generic | |||
syntax, such URIs are normalized and compared according to the | syntax, such URIs are normalized and compared according to the | |||
algorithm defined in [RFC3986], Section 6, using the defaults | algorithm defined in [RFC3986], Section 6, using the defaults | |||
described above for each scheme. | described above for each scheme. | |||
If the port is equal to the default port for a scheme, the normal | If the port is equal to the default port for a scheme, the normal | |||
form is to elide the port subcomponent. Likewise, an empty path | form is to elide the port subcomponent. When not being used in | |||
component is equivalent to an absolute path of "/", so the normal | absolute form as the request target of an OPTIONS request, an empty | |||
form is to provide a path of "/" instead. The scheme and host are | path component is equivalent to an absolute path of "/", so the | |||
case-insensitive and normally provided in lowercase; all other | normal form is to provide a path of "/" instead. The scheme and host | |||
are case-insensitive and normally provided in lowercase; all other | ||||
components are compared in a case-sensitive manner. Characters other | components are compared in a case-sensitive manner. Characters other | |||
than those in the "reserved" set are equivalent to their percent- | than those in the "reserved" set are equivalent to their percent- | |||
encoded octets (see [RFC3986], Section 2.1): the normal form is to | encoded octets (see [RFC3986], Section 2.1): the normal form is to | |||
not encode them. | not encode them. | |||
For example, the following three URIs are equivalent: | For example, the following three URIs are equivalent: | |||
http://example.com:80/~smith/home.html | http://example.com:80/~smith/home.html | |||
http://EXAMPLE.com/%7Esmith/home.html | http://EXAMPLE.com/%7Esmith/home.html | |||
http://EXAMPLE.com:/%7esmith/home.html | http://EXAMPLE.com:/%7esmith/home.html | |||
skipping to change at page 19, line 35 | skipping to change at page 19, line 48 | |||
incremental delivery of partial messages, since some implementations | incremental delivery of partial messages, since some implementations | |||
will buffer or delay message forwarding for the sake of network | will buffer or delay message forwarding for the sake of network | |||
efficiency, security checks, or payload transformations. | efficiency, security checks, or payload transformations. | |||
3.1. Start Line | 3.1. Start Line | |||
An HTTP message can either be a request from client to server or a | An HTTP message can either be a request from client to server or a | |||
response from server to client. Syntactically, the two types of | response from server to client. Syntactically, the two types of | |||
message differ only in the start-line, which is either a request-line | message differ only in the start-line, which is either a request-line | |||
(for requests) or a status-line (for responses), and in the algorithm | (for requests) or a status-line (for responses), and in the algorithm | |||
for determining the length of the message body (Section 3.3). In | for determining the length of the message body (Section 3.3). | |||
theory, a client could receive requests and a server could receive | ||||
In theory, a client could receive requests and a server could receive | ||||
responses, distinguishing them by their different start-line formats, | responses, distinguishing them by their different start-line formats, | |||
but in practice servers are implemented to only expect a request (a | but in practice servers are implemented to only expect a request (a | |||
response is interpreted as an unknown or invalid request method) and | response is interpreted as an unknown or invalid request method) and | |||
clients are implemented to only expect a response. | clients are implemented to only expect a response. | |||
start-line = request-line / status-line | start-line = request-line / status-line | |||
A sender MUST NOT send whitespace between the start-line and the | A sender MUST NOT send whitespace between the start-line and the | |||
first header field. The presence of such whitespace in a request | first header field. The presence of such whitespace in a request | |||
might be an attempt to trick a server into ignoring that field or | might be an attempt to trick a server into ignoring that field or | |||
processing the line after it as a new request, either of which might | processing the line after it as a new request, either of which might | |||
result in a security vulnerability if other implementations within | result in a security vulnerability if other implementations within | |||
the request chain interpret the same message differently. Likewise, | the request chain interpret the same message differently. Likewise, | |||
the presence of such whitespace in a response might be ignored by | the presence of such whitespace in a response might be ignored by | |||
some clients or cause others to cease parsing. | some clients or cause others to cease parsing. | |||
A recipient that receives whitespace between the start-line and the | ||||
first header field MUST either reject the message as invalid or | ||||
consume each whitespace-preceded line without further processing of | ||||
it (i.e., ignore the entire line, along with any subsequent lines | ||||
preceded by whitespace, until a properly formed header field is | ||||
received or the header block is terminated). | ||||
3.1.1. Request Line | 3.1.1. Request Line | |||
A request-line begins with a method token, followed by a single space | A request-line begins with a method token, followed by a single space | |||
(SP), the request-target, another single space (SP), the protocol | (SP), the request-target, another single space (SP), the protocol | |||
version, and ending with CRLF. | version, and ending with CRLF. | |||
request-line = method SP request-target SP HTTP-version CRLF | request-line = method SP request-target SP HTTP-version CRLF | |||
A server MUST be able to parse any received message that begins with | ||||
a request-line and matches the ABNF rule for HTTP-message. | ||||
The method token indicates the request method to be performed on the | The method token indicates the request method to be performed on the | |||
target resource. The request method is case-sensitive. | target resource. The request method is case-sensitive. | |||
method = token | method = token | |||
The methods defined by this specification can be found in Section 5 | The methods defined by this specification can be found in Section 4 | |||
of [Part2], along with information regarding the HTTP method registry | of [Part2], along with information regarding the HTTP method registry | |||
and considerations for defining new methods. | and considerations for defining new methods. | |||
The request-target identifies the target resource upon which to apply | The request-target identifies the target resource upon which to apply | |||
the request, as defined in Section 5.3. | the request, as defined in Section 5.3. | |||
No whitespace is allowed inside the method, request-target, and | No whitespace is allowed inside the method, request-target, and | |||
protocol version. Hence, recipients typically parse the request-line | protocol version. Hence, recipients typically parse the request-line | |||
into its component parts by splitting on the SP characters. | into its component parts by splitting on whitespace (see | |||
Section 3.5). | ||||
Unfortunately, some user agents fail to properly encode hypertext | Unfortunately, some user agents fail to properly encode hypertext | |||
references that have embedded whitespace, sending the characters | references that have embedded whitespace, sending the characters | |||
directly instead of properly percent-encoding the disallowed | directly instead of properly encoding or excluding the disallowed | |||
characters. Recipients of an invalid request-line SHOULD respond | characters. Recipients of an invalid request-line SHOULD respond | |||
with either a 400 (Bad Request) error or a 301 (Moved Permanently) | with either a 400 (Bad Request) error or a 301 (Moved Permanently) | |||
redirect with the request-target properly encoded. Recipients SHOULD | redirect with the request-target properly encoded. Recipients SHOULD | |||
NOT attempt to autocorrect and then process the request without a | NOT attempt to autocorrect and then process the request without a | |||
redirect, since the invalid request-line might be deliberately | redirect, since the invalid request-line might be deliberately | |||
crafted to bypass security filters along the request chain. | crafted to bypass security filters along the request chain. | |||
HTTP does not place a pre-defined limit on the length of a request- | HTTP does not place a pre-defined limit on the length of a request- | |||
line. A server that receives a method longer than any that it | line. A server that receives a method longer than any that it | |||
implements SHOULD respond with either a 405 (Method Not Allowed), if | implements SHOULD respond with a 501 (Not Implemented) status code. | |||
it is an origin server, or a 501 (Not Implemented) status code. A | A server MUST be prepared to receive URIs of unbounded length and | |||
server MUST be prepared to receive URIs of unbounded length and | ||||
respond with the 414 (URI Too Long) status code if the received | respond with the 414 (URI Too Long) status code if the received | |||
request-target would be longer than the server wishes to handle (see | request-target would be longer than the server wishes to handle (see | |||
Section 7.5.12 of [Part2]). | Section 6.5.12 of [Part2]). | |||
Various ad-hoc limitations on request-line length are found in | Various ad-hoc limitations on request-line length are found in | |||
practice. It is RECOMMENDED that all HTTP senders and recipients | practice. It is RECOMMENDED that all HTTP senders and recipients | |||
support, at a minimum, request-line lengths of up to 8000 octets. | support, at a minimum, request-line lengths of 8000 octets. | |||
3.1.2. Status Line | 3.1.2. Status Line | |||
The first line of a response message is the status-line, consisting | The first line of a response message is the status-line, consisting | |||
of the protocol version, a space (SP), the status code, another | of the protocol version, a space (SP), the status code, another | |||
space, a possibly-empty textual phrase describing the status code, | space, a possibly-empty textual phrase describing the status code, | |||
and ending with CRLF. | and ending with CRLF. | |||
status-line = HTTP-version SP status-code SP reason-phrase CRLF | status-line = HTTP-version SP status-code SP reason-phrase CRLF | |||
A client MUST be able to parse any received message that begins with | ||||
a status-line and matches the ABNF rule for HTTP-message. | ||||
The status-code element is a 3-digit integer code describing the | The status-code element is a 3-digit integer code describing the | |||
result of the server's attempt to understand and satisfy the client's | result of the server's attempt to understand and satisfy the client's | |||
corresponding request. The rest of the response message is to be | corresponding request. The rest of the response message is to be | |||
interpreted in light of the semantics defined for that status code. | interpreted in light of the semantics defined for that status code. | |||
See Section 7 of [Part2] for information about the semantics of | See Section 6 of [Part2] for information about the semantics of | |||
status codes, including the classes of status code (indicated by the | status codes, including the classes of status code (indicated by the | |||
first digit), the status codes defined by this specification, | first digit), the status codes defined by this specification, | |||
considerations for the definition of new status codes, and the IANA | considerations for the definition of new status codes, and the IANA | |||
registry. | registry. | |||
status-code = 3DIGIT | status-code = 3DIGIT | |||
The reason-phrase element exists for the sole purpose of providing a | The reason-phrase element exists for the sole purpose of providing a | |||
textual description associated with the numeric status code, mostly | textual description associated with the numeric status code, mostly | |||
out of deference to earlier Internet application protocols that were | out of deference to earlier Internet application protocols that were | |||
skipping to change at page 21, line 49 | skipping to change at page 22, line 16 | |||
Each HTTP header field consists of a case-insensitive field name | Each HTTP header field consists of a case-insensitive field name | |||
followed by a colon (":"), optional whitespace, and the field value. | followed by a colon (":"), optional whitespace, and the field value. | |||
header-field = field-name ":" OWS field-value BWS | header-field = field-name ":" OWS field-value BWS | |||
field-name = token | field-name = token | |||
field-value = *( field-content / obs-fold ) | field-value = *( field-content / obs-fold ) | |||
field-content = *( HTAB / SP / VCHAR / obs-text ) | field-content = *( HTAB / SP / VCHAR / obs-text ) | |||
obs-fold = CRLF ( SP / HTAB ) | obs-fold = CRLF ( SP / HTAB ) | |||
; obsolete line folding | ; obsolete line folding | |||
; see Section 3.2.2 | ; see Section 3.2.4 | |||
The field-name token labels the corresponding field-value as having | The field-name token labels the corresponding field-value as having | |||
the semantics defined by that header field. For example, the Date | the semantics defined by that header field. For example, the Date | |||
header field is defined in Section 8.1.1.2 of [Part2] as containing | header field is defined in Section 7.1.1.2 of [Part2] as containing | |||
the origination timestamp for the message in which it appears. | the origination timestamp for the message in which it appears. | |||
3.2.1. Field Extensibility | ||||
HTTP header fields are fully extensible: there is no limit on the | HTTP header fields are fully extensible: there is no limit on the | |||
introduction of new field names, each presumably defining new | introduction of new field names, each presumably defining new | |||
semantics, or on the number of header fields used in a given message. | semantics, nor on the number of header fields used in a given | |||
Existing fields are defined in each part of this specification and in | message. Existing fields are defined in each part of this | |||
many other specifications outside the standards process. New header | specification and in many other specifications outside the core | |||
fields can be introduced without changing the protocol version if | standard. New header fields can be introduced without changing the | |||
their defined semantics allow them to be safely ignored by recipients | protocol version if their defined semantics allow them to be safely | |||
that do not recognize them. | ignored by recipients that do not recognize them. | |||
New HTTP header fields SHOULD be registered with IANA in the Message | New HTTP header fields ought to be be registered with IANA in the | |||
Header Field Registry, as described in Section 9.3 of [Part2]. | Message Header Field Registry, as described in Section 8.3 of | |||
Unrecognized header fields MUST be forwarded by a proxy unless the | [Part2]. A proxy MUST forward unrecognized header fields unless the | |||
field-name is listed in the Connection header field (Section 6.1) or | field-name is listed in the Connection header field (Section 6.1) or | |||
the proxy is specifically configured to block or otherwise transform | the proxy is specifically configured to block, or otherwise | |||
such fields. Unrecognized header fields SHOULD be ignored by other | transform, such fields. Other recipients SHOULD ignore unrecognized | |||
recipients. | header fields. | |||
3.2.2. Field Order | ||||
The order in which header fields with differing field names are | The order in which header fields with differing field names are | |||
received is not significant. However, it is "good practice" to send | received is not significant. However, it is "good practice" to send | |||
header fields that contain control data first, such as Host on | header fields that contain control data first, such as Host on | |||
requests and Date on responses, so that implementations can decide | requests and Date on responses, so that implementations can decide | |||
when not to handle a message as early as possible. A server MUST | when not to handle a message as early as possible. A server MUST | |||
wait until the entire header section is received before interpreting | wait until the entire header section is received before interpreting | |||
a request message, since later header fields might include | a request message, since later header fields might include | |||
conditionals, authentication credentials, or deliberately misleading | conditionals, authentication credentials, or deliberately misleading | |||
duplicate header fields that would impact request processing. | duplicate header fields that would impact request processing. | |||
Multiple header fields with the same field name MUST NOT be sent in a | A sender MUST NOT generate multiple header fields with the same field | |||
message unless the entire field value for that header field is | name in a message unless either the entire field value for that | |||
defined as a comma-separated list [i.e., #(values)]. Multiple header | header field is defined as a comma-separated list [i.e., #(values)] | |||
fields with the same field name can be combined into one "field-name: | or the header field is a well-known exception (as noted below). | |||
field-value" pair, without changing the semantics of the message, by | ||||
appending each subsequent field value to the combined field value in | ||||
order, separated by a comma. The order in which header fields with | ||||
the same field name are received is therefore significant to the | ||||
interpretation of the combined field value; a proxy MUST NOT change | ||||
the order of these field values when forwarding a message. | ||||
Note: The "Set-Cookie" header field as implemented in practice can | Multiple header fields with the same field name can be combined into | |||
occur multiple times, but does not use the list syntax, and thus | one "field-name: field-value" pair, without changing the semantics of | |||
cannot be combined into a single line ([RFC6265]). (See Appendix | the message, by appending each subsequent field value to the combined | |||
A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 | field value in order, separated by a comma. The order in which | |||
header field specified in [RFC2965] does not share this problem. | header fields with the same field name are received is therefore | |||
significant to the interpretation of the combined field value; a | ||||
proxy MUST NOT change the order of these field values when forwarding | ||||
a message. | ||||
3.2.1. Whitespace | Note: In practice, the "Set-Cookie" header field ([RFC6265]) often | |||
appears multiple times in a response message and does not use the | ||||
list syntax, violating the above requirements on multiple header | ||||
fields with the same name. Since it cannot be combined into a | ||||
single field-value, recipients ought to handle "Set-Cookie" as a | ||||
special case while processing header fields. (See Appendix A.2.3 | ||||
of [Kri2001] for details.) | ||||
3.2.3. Whitespace | ||||
This specification uses three rules to denote the use of linear | This specification uses three rules to denote the use of linear | |||
whitespace: OWS (optional whitespace), RWS (required whitespace), and | whitespace: OWS (optional whitespace), RWS (required whitespace), and | |||
BWS ("bad" whitespace). | BWS ("bad" whitespace). | |||
The OWS rule is used where zero or more linear whitespace octets | The OWS rule is used where zero or more linear whitespace octets | |||
might appear. OWS SHOULD either not be produced or be produced as a | might appear. OWS SHOULD either not be generated or be generated as | |||
single SP. Multiple OWS octets that occur within field-content | a single SP. Multiple OWS octets that occur within field-content | |||
SHOULD either be replaced with a single SP or transformed to all SP | SHOULD either be replaced with a single SP or transformed to all SP | |||
octets (each octet other than SP replaced with SP) before | octets (each octet other than SP replaced with SP) before | |||
interpreting the field value or forwarding the message downstream. | interpreting the field value or forwarding the message downstream. | |||
RWS is used when at least one linear whitespace octet is required to | RWS is used when at least one linear whitespace octet is required to | |||
separate field tokens. RWS SHOULD be produced as a single SP. | separate field tokens. RWS SHOULD be generated as a single SP. | |||
Multiple RWS octets that occur within field-content SHOULD either be | Multiple RWS octets that occur within field-content SHOULD either be | |||
replaced with a single SP or transformed to all SP octets before | replaced with a single SP or transformed to all SP octets before | |||
interpreting the field value or forwarding the message downstream. | interpreting the field value or forwarding the message downstream. | |||
BWS is used where the grammar allows optional whitespace, for | BWS is used where the grammar allows optional whitespace, for | |||
historical reasons, but senders SHOULD NOT produce it in messages; | historical reasons, but senders SHOULD NOT generate it in messages; | |||
recipients MUST accept such bad optional whitespace and remove it | recipients MUST accept such bad optional whitespace and remove it | |||
before interpreting the field value or forwarding the message | before interpreting the field value or forwarding the message | |||
downstream. | downstream. | |||
OWS = *( SP / HTAB ) | OWS = *( SP / HTAB ) | |||
; "optional" whitespace | ; optional whitespace | |||
RWS = 1*( SP / HTAB ) | RWS = 1*( SP / HTAB ) | |||
; "required" whitespace | ; required whitespace | |||
BWS = OWS | BWS = OWS | |||
; "bad" whitespace | ; "bad" whitespace | |||
3.2.2. Field Parsing | 3.2.4. Field Parsing | |||
No whitespace is allowed between the header field-name and colon. In | No whitespace is allowed between the header field-name and colon. In | |||
the past, differences in the handling of such whitespace have led to | the past, differences in the handling of such whitespace have led to | |||
security vulnerabilities in request routing and response handling. | security vulnerabilities in request routing and response handling. A | |||
Any received request message that contains whitespace between a | server MUST reject any received request message that contains | |||
header field-name and colon MUST be rejected with a response code of | whitespace between a header field-name and colon with a response code | |||
400 (Bad Request). A proxy MUST remove any such whitespace from a | of 400 (Bad Request). A proxy MUST remove any such whitespace from a | |||
response message before forwarding the message downstream. | response message before forwarding the message downstream. | |||
A field value MAY be preceded by optional whitespace (OWS); a single | A field value is preceded by optional whitespace (OWS); a single SP | |||
SP is preferred. The field value does not include any leading or | is preferred. The field value does not include any leading or | |||
trailing white space: OWS occurring before the first non-whitespace | trailing white space: OWS occurring before the first non-whitespace | |||
octet of the field value or after the last non-whitespace octet of | octet of the field value or after the last non-whitespace octet of | |||
the field value is ignored and SHOULD be removed before further | the field value is ignored and SHOULD be removed before further | |||
processing (as this does not change the meaning of the header field). | processing (as this does not change the meaning of the header field). | |||
Historically, HTTP header field values could be extended over | Historically, HTTP header field values could be extended over | |||
multiple lines by preceding each extra line with at least one space | multiple lines by preceding each extra line with at least one space | |||
or horizontal tab (obs-fold). This specification deprecates such | or horizontal tab (obs-fold). This specification deprecates such | |||
line folding except within the message/http media type | line folding except within the message/http media type | |||
(Section 7.3.1). HTTP senders MUST NOT produce messages that include | (Section 7.3.1). Senders MUST NOT generate messages that include | |||
line folding (i.e., that contain any field-value that matches the | line folding (i.e., that contain any field-value that contains a | |||
obs-fold rule) unless the message is intended for packaging within | match to the obs-fold rule) unless the message is intended for | |||
the message/http media type. HTTP recipients SHOULD accept line | packaging within the message/http media type. When an obs-fold is | |||
folding and replace any embedded obs-fold whitespace with either a | received in a message, recipients MUST do one of: | |||
single SP or a matching number of SP octets (to avoid buffer copying) | ||||
prior to interpreting the field value or forwarding the message | o accept the message and replace any embedded obs-fold whitespace | |||
downstream. | with either a single SP or a matching number of SP octets (to | |||
avoid buffer copying) prior to interpreting the field value or | ||||
forwarding the message downstream; | ||||
o if it is a request, reject the message by sending a 400 (Bad | ||||
Request) response with a representation explaining that obsolete | ||||
line folding is unacceptable; or, | ||||
o if it is a response, discard the message and generate a 502 (Bad | ||||
Gateway) response with a representation explaining that | ||||
unacceptable line folding was received. | ||||
Recipients that choose not to implement obs-fold processing (as | ||||
described above) MUST NOT accept messages containing header fields | ||||
with leading whitespace, as this can expose them to attacks that | ||||
exploit this difference in processing. | ||||
Historically, HTTP has allowed field content with text in the ISO- | Historically, HTTP has allowed field content with text in the ISO- | |||
8859-1 [ISO-8859-1] character encoding and supported other character | 8859-1 [ISO-8859-1] charset, supporting other charsets only through | |||
sets only through use of [RFC2047] encoding. In practice, most HTTP | use of [RFC2047] encoding. In practice, most HTTP header field | |||
header field values use only a subset of the US-ASCII character | values use only a subset of the US-ASCII charset [USASCII]. Newly | |||
encoding [USASCII]. Newly defined header fields SHOULD limit their | defined header fields SHOULD limit their field values to US-ASCII | |||
field values to US-ASCII octets. Recipients SHOULD treat other (obs- | octets. Recipients SHOULD treat other octets in field content (obs- | |||
text) octets in field content as opaque data. | text) as opaque data. | |||
3.2.3. Field Length | 3.2.5. Field Limits | |||
HTTP does not place a pre-defined limit on the length of header | HTTP does not place a pre-defined limit on the length of each header | |||
fields, either in isolation or as a set. A server MUST be prepared | field or on the length of the header block as a whole. Various ad- | |||
to receive request header fields of unbounded length and respond with | hoc limitations on individual header field length are found in | |||
a 4xx (Client Error) status code if the received header field(s) | practice, often depending on the specific field semantics. | |||
would be longer than the server wishes to handle. | ||||
A client that receives response header fields that are longer than it | A server MUST be prepared to receive request header fields of | |||
wishes to handle can only treat it as a server error. | unbounded length and respond with an appropriate 4xx (Client Error) | |||
status code if the received header field(s) are larger than the | ||||
server wishes to process. | ||||
Various ad-hoc limitations on header field length are found in | A client MUST be prepared to receive response header fields of | |||
practice. It is RECOMMENDED that all HTTP senders and recipients | unbounded length. A client MAY discard or truncate received header | |||
support messages whose combined header fields have 4000 or more | fields that are larger than the client wishes to process if the field | |||
octets. | semantics are such that the dropped value(s) can be safely ignored | |||
without changing the response semantics. | ||||
3.2.4. Field value components | 3.2.6. Field value components | |||
Many HTTP header field values consist of words (token or quoted- | Many HTTP header field values consist of words (token or quoted- | |||
string) separated by whitespace or special characters. These special | string) separated by whitespace or special characters. These special | |||
characters MUST be in a quoted string to be used within a parameter | characters MUST be in a quoted string to be used within a parameter | |||
value (as defined in Section 4). | value (as defined in Section 4). | |||
word = token / quoted-string | word = token / quoted-string | |||
token = 1*tchar | token = 1*tchar | |||
skipping to change at page 25, line 22 | skipping to change at page 26, line 10 | |||
; any VCHAR, except special | ; any VCHAR, except special | |||
special = "(" / ")" / "<" / ">" / "@" / "," | special = "(" / ")" / "<" / ">" / "@" / "," | |||
/ ";" / ":" / "\" / DQUOTE / "/" / "[" | / ";" / ":" / "\" / DQUOTE / "/" / "[" | |||
/ "]" / "?" / "=" / "{" / "}" | / "]" / "?" / "=" / "{" / "}" | |||
A string of text is parsed as a single word if it is quoted using | A string of text is parsed as a single word if it is quoted using | |||
double-quote marks. | double-quote marks. | |||
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | |||
qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text | qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text | |||
obs-text = %x80-FF | obs-text = %x80-FF | |||
The backslash octet ("\") can be used as a single-octet quoting | The backslash octet ("\") can be used as a single-octet quoting | |||
mechanism within quoted-string constructs: | mechanism within quoted-string constructs: | |||
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) | |||
Recipients that process the value of the quoted-string MUST handle a | Recipients that process the value of a quoted-string MUST handle a | |||
quoted-pair as if it were replaced by the octet following the | quoted-pair as if it were replaced by the octet following the | |||
backslash. | backslash. | |||
Senders SHOULD NOT escape octets in quoted-strings that do not | Senders SHOULD NOT generate a quoted-pair in a quoted-string except | |||
require escaping (i.e., other than DQUOTE and the backslash octet). | where necessary to quote DQUOTE and backslash octets occurring within | |||
that string. | ||||
Comments can be included in some HTTP header fields by surrounding | Comments can be included in some HTTP header fields by surrounding | |||
the comment text with parentheses. Comments are only allowed in | the comment text with parentheses. Comments are only allowed in | |||
fields containing "comment" as part of their field value definition. | fields containing "comment" as part of their field value definition. | |||
comment = "(" *( ctext / quoted-cpair / comment ) ")" | comment = "(" *( ctext / quoted-cpair / comment ) ")" | |||
ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text | ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text | |||
The backslash octet ("\") can be used as a single-octet quoting | The backslash octet ("\") can be used as a single-octet quoting | |||
mechanism within comment constructs: | mechanism within comment constructs: | |||
quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) | |||
Senders SHOULD NOT escape octets in comments that do not require | Senders SHOULD NOT escape octets in comments that do not require | |||
escaping (i.e., other than the backslash octet "\" and the | escaping (i.e., other than the backslash octet "\" and the | |||
parentheses "(" and ")"). | parentheses "(" and ")"). | |||
skipping to change at page 26, line 17 | skipping to change at page 27, line 6 | |||
The message body (if any) of an HTTP message is used to carry the | The message body (if any) of an HTTP message is used to carry the | |||
payload body of that request or response. The message body is | payload body of that request or response. The message body is | |||
identical to the payload body unless a transfer coding has been | identical to the payload body unless a transfer coding has been | |||
applied, as described in Section 3.3.1. | applied, as described in Section 3.3.1. | |||
message-body = *OCTET | message-body = *OCTET | |||
The rules for when a message body is allowed in a message differ for | The rules for when a message body is allowed in a message differ for | |||
requests and responses. | requests and responses. | |||
The presence of a message body in a request is signaled by a a | The presence of a message body in a request is signaled by a Content- | |||
Content-Length or Transfer-Encoding header field. Request message | Length or Transfer-Encoding header field. Request message framing is | |||
framing is independent of method semantics, even if the method does | independent of method semantics, even if the method does not define | |||
not define any use for a message body. | any use for a message body. | |||
The presence of a message body in a response depends on both the | The presence of a message body in a response depends on both the | |||
request method to which it is responding and the response status code | request method to which it is responding and the response status code | |||
(Section 3.1.2). Responses to the HEAD request method never include | (Section 3.1.2). Responses to the HEAD request method never include | |||
a message body because the associated response header fields (e.g., | a message body because the associated response header fields (e.g., | |||
Transfer-Encoding, Content-Length, etc.), if present, indicate only | Transfer-Encoding, Content-Length, etc.), if present, indicate only | |||
what their values would have been if the request method had been GET | what their values would have been if the request method had been GET | |||
(Section 5.3.2 of [Part2]). 2xx (Successful) responses to CONNECT | (Section 4.3.2 of [Part2]). 2xx (Successful) responses to CONNECT | |||
switch to tunnel mode instead of having a message body (Section 5.3.6 | switch to tunnel mode instead of having a message body (Section 4.3.6 | |||
of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not | of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not | |||
Modified) responses MUST NOT include a message body. All other | Modified) responses do not include a message body. All other | |||
responses do include a message body, although the body MAY be of zero | responses do include a message body, although the body might be of | |||
length. | zero length. | |||
3.3.1. Transfer-Encoding | 3.3.1. Transfer-Encoding | |||
When one or more transfer codings are applied to a payload body in | The Transfer-Encoding header field lists the transfer coding names | |||
order to form the message body, a Transfer-Encoding header field MUST | corresponding to the sequence of transfer codings that have been (or | |||
be sent in the message and MUST contain the list of corresponding | will be) applied to the payload body in order to form the message | |||
transfer-coding names in the same order that they were applied. | body. Transfer codings are defined in Section 4. | |||
Transfer codings are defined in Section 4. | ||||
Transfer-Encoding = 1#transfer-coding | Transfer-Encoding = 1#transfer-coding | |||
Transfer-Encoding is analogous to the Content-Transfer-Encoding field | Transfer-Encoding is analogous to the Content-Transfer-Encoding field | |||
of MIME, which was designed to enable safe transport of binary data | of MIME, which was designed to enable safe transport of binary data | |||
over a 7-bit transport service ([RFC2045], Section 6). However, safe | over a 7-bit transport service ([RFC2045], Section 6). However, safe | |||
transport has a different focus for an 8bit-clean transfer protocol. | transport has a different focus for an 8bit-clean transfer protocol. | |||
In HTTP's case, Transfer-Encoding is primarily intended to accurately | In HTTP's case, Transfer-Encoding is primarily intended to accurately | |||
delimit a dynamically generated payload and to distinguish payload | delimit a dynamically generated payload and to distinguish payload | |||
encodings that are only applied for transport efficiency or security | encodings that are only applied for transport efficiency or security | |||
from those that are characteristics of the target resource. | from those that are characteristics of the selected resource. | |||
The "chunked" transfer-coding (Section 4.1) MUST be implemented by | All HTTP/1.1 recipients MUST implement the chunked transfer coding | |||
all HTTP/1.1 recipients because it plays a crucial role in delimiting | (Section 4.1) because it plays a crucial role in framing messages | |||
messages when the payload body size is not known in advance. When | when the payload body size is not known in advance. If chunked is | |||
the "chunked" transfer-coding is used, it MUST be the last transfer- | applied to a payload body, the sender MUST NOT apply chunked more | |||
coding applied to form the message body and MUST NOT be applied more | than once (i.e., chunking an already chunked message is not allowed). | |||
than once in a message body. If any transfer-coding is applied to a | If any transfer coding is applied to a request payload body, the | |||
request payload body, the final transfer-coding applied MUST be | sender MUST apply chunked as the final transfer coding to ensure that | |||
"chunked". If any transfer-coding is applied to a response payload | the message is properly framed. If any transfer coding is applied to | |||
body, then either the final transfer-coding applied MUST be "chunked" | a response payload body, the sender MUST either apply chunked as the | |||
or the message MUST be terminated by closing the connection. | final transfer coding or terminate the message by closing the | |||
connection. | ||||
For example, | For example, | |||
Transfer-Encoding: gzip, chunked | Transfer-Encoding: gzip, chunked | |||
indicates that the payload body has been compressed using the gzip | indicates that the payload body has been compressed using the gzip | |||
coding and then chunked using the chunked coding while forming the | coding and then chunked using the chunked coding while forming the | |||
message body. | message body. | |||
If more than one Transfer-Encoding header field is present in a | ||||
message, the multiple field-values MUST be combined into one field- | ||||
value, according to the algorithm defined in Section 3.2, before | ||||
determining the message body length. | ||||
Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- | Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- | |||
Encoding is a property of the message, not of the payload, and thus | Encoding is a property of the message, not of the representation, and | |||
MAY be added or removed by any implementation along the request/ | any recipient along the request/response chain MAY decode the | |||
response chain. Additional information about the encoding parameters | received transfer coding(s) or apply additional transfer coding(s) to | |||
MAY be provided by other header fields not defined by this | the message body, assuming that corresponding changes are made to the | |||
specification. | Transfer-Encoding field-value. Additional information about the | |||
encoding parameters MAY be provided by other header fields not | ||||
defined by this specification. | ||||
Transfer-Encoding MAY be sent in a response to a HEAD request or in a | Transfer-Encoding MAY be sent in a response to a HEAD request or in a | |||
304 (Not Modified) response (Section 4.1 of [Part4]) to a GET | 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET | |||
request, neither of which includes a message body, to indicate that | request, neither of which includes a message body, to indicate that | |||
the origin server would have applied a transfer coding to the message | the origin server would have applied a transfer coding to the message | |||
body if the request had been an unconditional GET. This indication | body if the request had been an unconditional GET. This indication | |||
is not required, however, because any recipient on the response chain | is not required, however, because any recipient on the response chain | |||
(including the origin server) can remove transfer codings when they | (including the origin server) can remove transfer codings when they | |||
are not needed. | are not needed. | |||
Transfer-Encoding was added in HTTP/1.1. It is generally assumed | Transfer-Encoding was added in HTTP/1.1. It is generally assumed | |||
that implementations advertising only HTTP/1.0 support will not | that implementations advertising only HTTP/1.0 support will not | |||
understand how to process a transfer-encoded payload. A client MUST | understand how to process a transfer-encoded payload. A client MUST | |||
NOT send a request containing Transfer-Encoding unless it knows the | NOT send a request containing Transfer-Encoding unless it knows the | |||
server will handle HTTP/1.1 (or later) requests; such knowledge might | server will handle HTTP/1.1 (or later) requests; such knowledge might | |||
be in the form of specific user configuration or by remembering the | be in the form of specific user configuration or by remembering the | |||
version of a prior received response. A server MUST NOT send a | version of a prior received response. A server MUST NOT send a | |||
response containing Transfer-Encoding unless the corresponding | response containing Transfer-Encoding unless the corresponding | |||
request indicates HTTP/1.1 (or later). | request indicates HTTP/1.1 (or later). | |||
A server that receives a request message with a transfer-coding it | A server that receives a request message with a transfer coding it | |||
does not understand SHOULD respond with 501 (Not Implemented) and | does not understand SHOULD respond with 501 (Not Implemented). | |||
then close the connection. | ||||
3.3.2. Content-Length | 3.3.2. Content-Length | |||
When a message is allowed to contain a message body, does not have a | When a message does not have a Transfer-Encoding header field, a | |||
Transfer-Encoding header field, and has a payload body length that is | Content-Length header field can provide the anticipated size, as a | |||
known to the sender before the message header section has been sent, | decimal number of octets, for a potential payload body. For messages | |||
the sender SHOULD send a Content-Length header field to indicate the | that do include a payload body, the Content-Length field-value | |||
length of the payload body as a decimal number of octets. | provides the framing information necessary for determining where the | |||
body (and message) ends. For messages that do not include a payload | ||||
body, the Content-Length indicates the size of the selected | ||||
representation (Section 3 of [Part2]). | ||||
Content-Length = 1*DIGIT | Content-Length = 1*DIGIT | |||
An example is | An example is | |||
Content-Length: 3495 | Content-Length: 3495 | |||
A sender MUST NOT send a Content-Length header field in any message | A sender MUST NOT send a Content-Length header field in any message | |||
that contains a Transfer-Encoding header field. | that contains a Transfer-Encoding header field. | |||
A user agent SHOULD send a Content-Length in a request message when | ||||
no Transfer-Encoding is sent and the request method defines a meaning | ||||
for an enclosed payload body. For example, a Content-Length header | ||||
field is normally sent in a POST request even when the value is 0 | ||||
(indicating an empty payload body). A user agent SHOULD NOT send a | ||||
Content-Length header field when the request message does not contain | ||||
a payload body and the method semantics do not anticipate such a | ||||
body. | ||||
A server MAY send a Content-Length header field in a response to a | A server MAY send a Content-Length header field in a response to a | |||
HEAD request (Section 5.3.2 of [Part2]); a server MUST NOT send | HEAD request (Section 4.3.2 of [Part2]); a server MUST NOT send | |||
Content-Length in such a response unless its field-value equals the | Content-Length in such a response unless its field-value equals the | |||
decimal number of octets that would have been sent in the payload | decimal number of octets that would have been sent in the payload | |||
body of a response if the same request had used the GET method. | body of a response if the same request had used the GET method. | |||
A server MAY send a Content-Length header field in a 304 (Not | A server MAY send a Content-Length header field in a 304 (Not | |||
Modified) response to a conditional GET request (Section 4.1 of | Modified) response to a conditional GET request (Section 4.1 of | |||
[Part4]); a server MUST NOT send Content-Length in such a response | [Part4]); a server MUST NOT send Content-Length in such a response | |||
unless its field-value equals the decimal number of octets that would | unless its field-value equals the decimal number of octets that would | |||
have been sent in the payload body of a 200 (OK) response to the same | have been sent in the payload body of a 200 (OK) response to the same | |||
request. | request. | |||
A server MUST NOT send a Content-Length header field in any response | A server MUST NOT send a Content-Length header field in any response | |||
with a status code of 1xx (Informational) or 204 (No Content). A | with a status code of 1xx (Informational) or 204 (No Content). A | |||
server SHOULD NOT send a Content-Length header field in any 2xx | server SHOULD NOT send a Content-Length header field in any 2xx | |||
(Successful) response to a CONNECT request (Section 5.3.6 of | (Successful) response to a CONNECT request (Section 4.3.6 of | |||
[Part2]). | [Part2]). | |||
Aside from the cases defined above, in the absence of Transfer- | ||||
Encoding, an origin server SHOULD send a Content-Length header field | ||||
when the payload body size is known prior to sending the complete | ||||
header block. This will allow downstream recipients to measure | ||||
transfer progress, know when a received message is complete, and | ||||
potentially reuse the connection for additional requests. | ||||
Any Content-Length field value greater than or equal to zero is | Any Content-Length field value greater than or equal to zero is | |||
valid. Since there is no predefined limit to the length of an HTTP | valid. Since there is no predefined limit to the length of a | |||
payload, recipients SHOULD anticipate potentially large decimal | payload, recipients SHOULD anticipate potentially large decimal | |||
numerals and prevent parsing errors due to integer conversion | numerals and prevent parsing errors due to integer conversion | |||
overflows (Section 8.6). | overflows (Section 8.3). | |||
If a message is received that has multiple Content-Length header | If a message is received that has multiple Content-Length header | |||
fields with field-values consisting of the same decimal value, or a | fields with field-values consisting of the same decimal value, or a | |||
single Content-Length header field with a field value containing a | single Content-Length header field with a field value containing a | |||
list of identical decimal values (e.g., "Content-Length: 42, 42"), | list of identical decimal values (e.g., "Content-Length: 42, 42"), | |||
indicating that duplicate Content-Length header fields have been | indicating that duplicate Content-Length header fields have been | |||
generated or combined by an upstream message processor, then the | generated or combined by an upstream message processor, then the | |||
recipient MUST either reject the message as invalid or replace the | recipient MUST either reject the message as invalid or replace the | |||
duplicated field-values with a single valid Content-Length field | duplicated field-values with a single valid Content-Length field | |||
containing that decimal value prior to determining the message body | containing that decimal value prior to determining the message body | |||
skipping to change at page 29, line 38 | skipping to change at page 30, line 44 | |||
code is always terminated by the first empty line after the | code is always terminated by the first empty line after the | |||
header fields, regardless of the header fields present in the | header fields, regardless of the header fields present in the | |||
message, and thus cannot contain a message body. | message, and thus cannot contain a message body. | |||
2. Any 2xx (Successful) response to a CONNECT request implies that | 2. Any 2xx (Successful) response to a CONNECT request implies that | |||
the connection will become a tunnel immediately after the empty | the connection will become a tunnel immediately after the empty | |||
line that concludes the header fields. A client MUST ignore any | line that concludes the header fields. A client MUST ignore any | |||
Content-Length or Transfer-Encoding header fields received in | Content-Length or Transfer-Encoding header fields received in | |||
such a message. | such a message. | |||
3. If a Transfer-Encoding header field is present and the "chunked" | 3. If a Transfer-Encoding header field is present and the chunked | |||
transfer-coding (Section 4.1) is the final encoding, the message | transfer coding (Section 4.1) is the final encoding, the message | |||
body length is determined by reading and decoding the chunked | body length is determined by reading and decoding the chunked | |||
data until the transfer-coding indicates the data is complete. | data until the transfer coding indicates the data is complete. | |||
If a Transfer-Encoding header field is present in a response and | If a Transfer-Encoding header field is present in a response and | |||
the "chunked" transfer-coding is not the final encoding, the | the chunked transfer coding is not the final encoding, the | |||
message body length is determined by reading the connection until | message body length is determined by reading the connection until | |||
it is closed by the server. If a Transfer-Encoding header field | it is closed by the server. If a Transfer-Encoding header field | |||
is present in a request and the "chunked" transfer-coding is not | is present in a request and the chunked transfer coding is not | |||
the final encoding, the message body length cannot be determined | the final encoding, the message body length cannot be determined | |||
reliably; the server MUST respond with the 400 (Bad Request) | reliably; the server MUST respond with the 400 (Bad Request) | |||
status code and then close the connection. | status code and then close the connection. | |||
If a message is received with both a Transfer-Encoding and a | If a message is received with both a Transfer-Encoding and a | |||
Content-Length header field, the Transfer-Encoding overrides the | Content-Length header field, the Transfer-Encoding overrides the | |||
Content-Length. Such a message might indicate an attempt to | Content-Length. Such a message might indicate an attempt to | |||
perform request or response smuggling (bypass of security-related | perform request or response smuggling (bypass of security-related | |||
checks on message routing or content) and thus ought to be | checks on message routing or content) and thus ought to be | |||
handled as an error. The provided Content-Length MUST be | handled as an error. A sender MUST remove the received Content- | |||
removed, prior to forwarding the message downstream, or replaced | Length field prior to forwarding such a message downstream. | |||
with the real message body length after the transfer-coding is | ||||
decoded. | ||||
4. If a message is received without Transfer-Encoding and with | 4. If a message is received without Transfer-Encoding and with | |||
either multiple Content-Length header fields having differing | either multiple Content-Length header fields having differing | |||
field-values or a single Content-Length header field having an | field-values or a single Content-Length header field having an | |||
invalid value, then the message framing is invalid and MUST be | invalid value, then the message framing is invalid and MUST be | |||
treated as an error to prevent request or response smuggling. If | treated as an error to prevent request or response smuggling. If | |||
this is a request message, the server MUST respond with a 400 | this is a request message, the server MUST respond with a 400 | |||
(Bad Request) status code and then close the connection. If this | (Bad Request) status code and then close the connection. If this | |||
is a response message received by a proxy, the proxy MUST discard | is a response message received by a proxy, the proxy MUST discard | |||
the received response, send a 502 (Bad Gateway) status code as | the received response, send a 502 (Bad Gateway) status code as | |||
its downstream response, and then close the connection. If this | its downstream response, and then close the connection. If this | |||
is a response message received by a user-agent, it MUST be | is a response message received by a user agent, it MUST be | |||
treated as an error by discarding the message and closing the | treated as an error by discarding the message and closing the | |||
connection. | connection. | |||
5. If a valid Content-Length header field is present without | 5. If a valid Content-Length header field is present without | |||
Transfer-Encoding, its decimal value defines the message body | Transfer-Encoding, its decimal value defines the expected message | |||
length in octets. If the actual number of octets sent in the | body length in octets. If the sender closes the connection or | |||
message is less than the indicated Content-Length, the recipient | the recipient times out before the indicated number of octets are | |||
MUST consider the message to be incomplete and treat the | received, the recipient MUST consider the message to be | |||
connection as no longer usable. If the actual number of octets | incomplete and close the connection. | |||
sent in the message is more than the indicated Content-Length, | ||||
the recipient MUST only process the message body up to the field | ||||
value's number of octets; the remainder of the message MUST | ||||
either be discarded or treated as the next message in a pipeline. | ||||
For the sake of robustness, a user-agent MAY attempt to detect | ||||
and correct such an error in message framing if it is parsing the | ||||
response to the last request on a connection and the connection | ||||
has been closed by the server. | ||||
6. If this is a request message and none of the above are true, then | 6. If this is a request message and none of the above are true, then | |||
the message body length is zero (no message body is present). | the message body length is zero (no message body is present). | |||
7. Otherwise, this is a response message without a declared message | 7. Otherwise, this is a response message without a declared message | |||
body length, so the message body length is determined by the | body length, so the message body length is determined by the | |||
number of octets received prior to the server closing the | number of octets received prior to the server closing the | |||
connection. | connection. | |||
Since there is no way to distinguish a successfully completed, close- | Since there is no way to distinguish a successfully completed, close- | |||
delimited message from a partially-received message interrupted by | delimited message from a partially-received message interrupted by | |||
network failure, a server SHOULD use encoding or length-delimited | network failure, a server SHOULD use encoding or length-delimited | |||
messages whenever possible. The close-delimiting feature exists | messages whenever possible. The close-delimiting feature exists | |||
primarily for backwards compatibility with HTTP/1.0. | primarily for backwards compatibility with HTTP/1.0. | |||
A server MAY reject a request that contains a message body but not a | A server MAY reject a request that contains a message body but not a | |||
Content-Length by responding with 411 (Length Required). | Content-Length by responding with 411 (Length Required). | |||
Unless a transfer-coding other than "chunked" has been applied, a | Unless a transfer coding other than chunked has been applied, a | |||
client that sends a request containing a message body SHOULD use a | client that sends a request containing a message body SHOULD use a | |||
valid Content-Length header field if the message body length is known | valid Content-Length header field if the message body length is known | |||
in advance, rather than the "chunked" encoding, since some existing | in advance, rather than the chunked transfer coding, since some | |||
services respond to "chunked" with a 411 (Length Required) status | existing services respond to chunked with a 411 (Length Required) | |||
code even though they understand the chunked encoding. This is | status code even though they understand the chunked transfer coding. | |||
typically because such services are implemented via a gateway that | This is typically because such services are implemented via a gateway | |||
requires a content-length in advance of being called and the server | that requires a content-length in advance of being called and the | |||
is unable or unwilling to buffer the entire request before | server is unable or unwilling to buffer the entire request before | |||
processing. | processing. | |||
A client that sends a request containing a message body MUST include | A user agent that sends a request containing a message body MUST send | |||
a valid Content-Length header field if it does not know the server | a valid Content-Length header field if it does not know the server | |||
will handle HTTP/1.1 (or later) requests; such knowledge can be in | will handle HTTP/1.1 (or later) requests; such knowledge can be in | |||
the form of specific user configuration or by remembering the version | the form of specific user configuration or by remembering the version | |||
of a prior received response. | of a prior received response. | |||
If the final response to the last request on a connection has been | ||||
completely received and there remains additional data to read, a user | ||||
agent MAY discard the remaining data or attempt to determine if that | ||||
data belongs as part of the prior response body, which might be the | ||||
case if the prior message's Content-Length value is incorrect. A | ||||
client MUST NOT process, cache, or forward such extra data as a | ||||
separate response, since such behavior would be vulnerable to cache | ||||
poisoning. | ||||
3.4. Handling Incomplete Messages | 3.4. Handling Incomplete Messages | |||
Request messages that are prematurely terminated, possibly due to a | A server that receives an incomplete request message, usually due to | |||
canceled connection or a server-imposed time-out exception, MUST | a canceled request or a triggered time-out exception, MAY send an | |||
result in closure of the connection; sending an error response prior | error response prior to closing the connection. | |||
to closing the connection is OPTIONAL. | ||||
Response messages that are prematurely terminated, usually by closure | A client that receives an incomplete response message, which can | |||
of the connection prior to receiving the expected number of octets or | occur when a connection is closed prematurely or when decoding a | |||
by failure to decode a transfer-encoded message body, MUST be | supposedly chunked transfer coding fails, MUST record the message as | |||
recorded as incomplete. A response that terminates in the middle of | incomplete. Cache requirements for incomplete responses are defined | |||
the header block (before the empty line is received) cannot be | in Section 3 of [Part6]. | |||
assumed to convey the full semantics of the response and MUST be | ||||
treated as an error. | ||||
A message body that uses the chunked transfer encoding is incomplete | If a response terminates in the middle of the header block (before | |||
if the zero-sized chunk that terminates the encoding has not been | the empty line is received) and the status code might rely on header | |||
fields to convey the full meaning of the response, then the client | ||||
cannot assume that meaning has been conveyed; the client might need | ||||
to repeat the request in order to determine what action to take next. | ||||
A message body that uses the chunked transfer coding is incomplete if | ||||
the zero-sized chunk that terminates the encoding has not been | ||||
received. A message that uses a valid Content-Length is incomplete | received. A message that uses a valid Content-Length is incomplete | |||
if the size of the message body received (in octets) is less than the | if the size of the message body received (in octets) is less than the | |||
value given by Content-Length. A response that has neither chunked | value given by Content-Length. A response that has neither chunked | |||
transfer encoding nor Content-Length is terminated by closure of the | transfer coding nor Content-Length is terminated by closure of the | |||
connection, and thus is considered complete regardless of the number | connection, and thus is considered complete regardless of the number | |||
of message body octets received, provided that the header block was | of message body octets received, provided that the header block was | |||
received intact. | received intact. | |||
A user agent MUST NOT render an incomplete response message body as | ||||
if it were complete (i.e., some indication needs to be given to the | ||||
user that an error occurred). Cache requirements for incomplete | ||||
responses are defined in Section 3 of [Part6]. | ||||
A server MUST read the entire request message body or close the | ||||
connection after sending its response, since otherwise the remaining | ||||
data on a persistent connection would be misinterpreted as the next | ||||
request. Likewise, a client MUST read the entire response message | ||||
body if it intends to reuse the same connection for a subsequent | ||||
request. Pipelining multiple requests on a connection is described | ||||
in Section 6.2.2.1. | ||||
3.5. Message Parsing Robustness | 3.5. Message Parsing Robustness | |||
Older HTTP/1.0 client implementations might send an extra CRLF after | Older HTTP/1.0 user agent implementations might send an extra CRLF | |||
a POST request as a lame workaround for some early server | after a POST request as a lame workaround for some early server | |||
applications that failed to read message body content that was not | applications that failed to read message body content that was not | |||
terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or | terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface | |||
follow a request with an extra CRLF. If terminating the request | or follow a request with an extra CRLF. If terminating the request | |||
message body with a line-ending is desired, then the client MUST | message body with a line-ending is desired, then the user agent MUST | |||
include the terminating CRLF octets as part of the message body | count the terminating CRLF octets as part of the message body length. | |||
length. | ||||
In the interest of robustness, servers SHOULD ignore at least one | In the interest of robustness, servers SHOULD ignore at least one | |||
empty line received where a request-line is expected. In other | empty line received where a request-line is expected. In other | |||
words, if the server is reading the protocol stream at the beginning | words, if a server is reading the protocol stream at the beginning of | |||
of a message and receives a CRLF first, it SHOULD ignore the CRLF. | a message and receives a CRLF first, the server SHOULD ignore the | |||
Likewise, although the line terminator for the start-line and header | CRLF. | |||
fields is the sequence CRLF, we recommend that recipients recognize a | ||||
single LF as a line terminator and ignore any CR. | Although the line terminator for the start-line and header fields is | |||
the sequence CRLF, recipients MAY recognize a single LF as a line | ||||
terminator and ignore any preceding CR. | ||||
Although the request-line and status-line grammar rules require that | ||||
each of the component elements be separated by a single SP octet, | ||||
recipients MAY instead parse on whitespace-delimited word boundaries | ||||
and, aside from the CRLF terminator, treat any form of whitespace as | ||||
the SP separator while ignoring preceding or trailing whitespace; | ||||
such whitespace includes one or more of the following octets: SP, | ||||
HTAB, VT (%x0B), FF (%x0C), or bare CR. | ||||
When a server listening only for HTTP request messages, or processing | When a server listening only for HTTP request messages, or processing | |||
what appears from the start-line to be an HTTP request message, | what appears from the start-line to be an HTTP request message, | |||
receives a sequence of octets that does not match the HTTP-message | receives a sequence of octets that does not match the HTTP-message | |||
grammar aside from the robustness exceptions listed above, the server | grammar aside from the robustness exceptions listed above, the server | |||
MUST respond with an HTTP/1.1 400 (Bad Request) response. | SHOULD respond with a 400 (Bad Request) response. | |||
4. Transfer Codings | 4. Transfer Codings | |||
Transfer-coding values are used to indicate an encoding | Transfer coding names are used to indicate an encoding transformation | |||
transformation that has been, can be, or might need to be applied to | that has been, can be, or might need to be applied to a payload body | |||
a payload body in order to ensure "safe transport" through the | in order to ensure "safe transport" through the network. This | |||
network. This differs from a content coding in that the transfer- | differs from a content coding in that the transfer coding is a | |||
coding is a property of the message rather than a property of the | property of the message rather than a property of the representation | |||
representation that is being transferred. | that is being transferred. | |||
transfer-coding = "chunked" ; Section 4.1 | transfer-coding = "chunked" ; Section 4.1 | |||
/ "compress" ; Section 4.2.1 | / "compress" ; Section 4.2.1 | |||
/ "deflate" ; Section 4.2.2 | / "deflate" ; Section 4.2.2 | |||
/ "gzip" ; Section 4.2.3 | / "gzip" ; Section 4.2.3 | |||
/ transfer-extension | / transfer-extension | |||
transfer-extension = token *( OWS ";" OWS transfer-parameter ) | transfer-extension = token *( OWS ";" OWS transfer-parameter ) | |||
Parameters are in the form of attribute/value pairs. | Parameters are in the form of attribute/value pairs. | |||
transfer-parameter = attribute BWS "=" BWS value | transfer-parameter = attribute BWS "=" BWS value | |||
attribute = token | attribute = token | |||
value = word | value = word | |||
All transfer-coding values are case-insensitive and SHOULD be | All transfer-coding names are case-insensitive and ought to be | |||
registered within the HTTP Transfer Coding registry, as defined in | registered within the HTTP Transfer Coding registry, as defined in | |||
Section 7.4. They are used in the TE (Section 4.3) and Transfer- | Section 7.4. They are used in the TE (Section 4.3) and Transfer- | |||
Encoding (Section 3.3.1) header fields. | Encoding (Section 3.3.1) header fields. | |||
4.1. Chunked Transfer Coding | 4.1. Chunked Transfer Coding | |||
The chunked encoding modifies the body of a message in order to | The chunked transfer coding modifies the body of a message in order | |||
transfer it as a series of chunks, each with its own size indicator, | to transfer it as a series of chunks, each with its own size | |||
followed by an OPTIONAL trailer containing header fields. This | indicator, followed by an OPTIONAL trailer containing header fields. | |||
allows dynamically produced content to be transferred along with the | This allows dynamically generated content to be transferred along | |||
information necessary for the recipient to verify that it has | with the information necessary for the recipient to verify that it | |||
received the full message. | has received the full message. | |||
chunked-body = *chunk | chunked-body = *chunk | |||
last-chunk | last-chunk | |||
trailer-part | trailer-part | |||
CRLF | CRLF | |||
chunk = chunk-size [ chunk-ext ] CRLF | chunk = chunk-size [ chunk-ext ] CRLF | |||
chunk-data CRLF | chunk-data CRLF | |||
chunk-size = 1*HEXDIG | chunk-size = 1*HEXDIG | |||
last-chunk = 1*("0") [ chunk-ext ] CRLF | last-chunk = 1*("0") [ chunk-ext ] CRLF | |||
skipping to change at page 33, line 52 | skipping to change at page 35, line 25 | |||
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token / quoted-str-nf | chunk-ext-val = token / quoted-str-nf | |||
chunk-data = 1*OCTET ; a sequence of chunk-size octets | chunk-data = 1*OCTET ; a sequence of chunk-size octets | |||
trailer-part = *( header-field CRLF ) | trailer-part = *( header-field CRLF ) | |||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | |||
; like quoted-string, but disallowing line folding | ; like quoted-string, but disallowing line folding | |||
qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text | qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text | |||
Chunk extensions within the chucked encoding are deprecated. Senders | Chunk extensions within the chunked transfer coding are deprecated. | |||
SHOULD NOT send chunk-ext. Definition of new chunk extensions is | Senders SHOULD NOT send chunk-ext. Definition of new chunk | |||
discouraged. | extensions is discouraged. | |||
The chunk-size field is a string of hex digits indicating the size of | The chunk-size field is a string of hex digits indicating the size of | |||
the chunk-data in octets. The chunked encoding is ended by any chunk | the chunk-data in octets. The chunked transfer coding is complete | |||
whose size is zero, followed by the trailer, which is terminated by | when a chunk with a chunk-size of zero is received, possibly followed | |||
an empty line. | by a trailer, and finally terminated by an empty line. | |||
4.1.1. Trailer | 4.1.1. Trailer | |||
A trailer allows the sender to include additional fields at the end | A trailer allows the sender to include additional fields at the end | |||
of a chunked message in order to supply metadata that might be | of a chunked message in order to supply metadata that might be | |||
dynamically generated while the message body is sent, such as a | dynamically generated while the message body is sent, such as a | |||
message integrity check, digital signature, or post-processing | message integrity check, digital signature, or post-processing | |||
status. The trailer MUST NOT contain fields that need to be known | status. The trailer MUST NOT contain fields that need to be known | |||
before a recipient processes the body, such as Transfer-Encoding, | before a recipient processes the body, such as Transfer-Encoding, | |||
Content-Length, and Trailer. | Content-Length, and Trailer. | |||
When a message includes a message body encoded with the chunked | When a message includes a message body encoded with the chunked | |||
transfer-coding and the sender desires to send metadata in the form | transfer coding and the sender desires to send metadata in the form | |||
of trailer fields at the end of the message, the sender SHOULD send a | of trailer fields at the end of the message, the sender SHOULD send a | |||
Trailer header field before the message body to indicate which fields | Trailer header field before the message body to indicate which fields | |||
will be present in the trailers. This allows the recipient to | will be present in the trailers. This allows the recipient to | |||
prepare for receipt of that metadata before it starts processing the | prepare for receipt of that metadata before it starts processing the | |||
body, which is useful if the message is being streamed and the | body, which is useful if the message is being streamed and the | |||
recipient wishes to confirm an integrity check on the fly. | recipient wishes to confirm an integrity check on the fly. | |||
Trailer = 1#field-name | Trailer = 1#field-name | |||
If no Trailer header field is present, the sender of a chunked | If no Trailer header field is present, the sender of a chunked | |||
message body SHOULD send an empty trailer. | message body SHOULD send an empty trailer. | |||
A server MUST send an empty trailer with the chunked transfer-coding | A server MUST send an empty trailer with the chunked transfer coding | |||
unless at least one of the following is true: | unless at least one of the following is true: | |||
1. the request included a TE header field that indicates "trailers" | 1. the request included a TE header field that indicates "trailers" | |||
is acceptable in the transfer-coding of the response, as | is acceptable in the transfer coding of the response, as | |||
described in Section 4.3; or, | described in Section 4.3; or, | |||
2. the trailer fields consist entirely of optional metadata and the | 2. the trailer fields consist entirely of optional metadata and the | |||
recipient could use the message (in a manner acceptable to the | recipient could use the message (in a manner acceptable to the | |||
server where the field originated) without receiving that | server where the field originated) without receiving that | |||
metadata. In other words, the server that generated the header | metadata. In other words, the server that generated the header | |||
field is willing to accept the possibility that the trailer | field is willing to accept the possibility that the trailer | |||
fields might be silently discarded along the path to the client. | fields might be silently discarded along the path to the client. | |||
The above requirement prevents the need for an infinite buffer when a | The above requirement prevents the need for an infinite buffer when a | |||
message is being received by an HTTP/1.1 (or later) proxy and | message is being received by an HTTP/1.1 (or later) proxy and | |||
forwarded to an HTTP/1.0 recipient. | forwarded to an HTTP/1.0 recipient. | |||
4.1.2. Decoding chunked | 4.1.2. Decoding chunked | |||
A process for decoding the "chunked" transfer-coding can be | A process for decoding the chunked transfer coding can be represented | |||
represented in pseudo-code as: | in pseudo-code as: | |||
length := 0 | length := 0 | |||
read chunk-size, chunk-ext (if any) and CRLF | read chunk-size, chunk-ext (if any) and CRLF | |||
while (chunk-size > 0) { | while (chunk-size > 0) { | |||
read chunk-data and CRLF | read chunk-data and CRLF | |||
append chunk-data to decoded-body | append chunk-data to decoded-body | |||
length := length + chunk-size | length := length + chunk-size | |||
read chunk-size and CRLF | read chunk-size and CRLF | |||
} | } | |||
read header-field | read header-field | |||
while (header-field not empty) { | while (header-field not empty) { | |||
append header-field to existing header fields | append header-field to existing header fields | |||
read header-field | read header-field | |||
} | } | |||
Content-Length := length | Content-Length := length | |||
Remove "chunked" from Transfer-Encoding | Remove "chunked" from Transfer-Encoding | |||
Remove Trailer from existing header fields | Remove Trailer from existing header fields | |||
All recipients MUST be able to receive and decode the "chunked" | All recipients MUST be able to receive and decode the chunked | |||
transfer-coding and MUST ignore chunk-ext extensions they do not | transfer coding and MUST ignore chunk-ext extensions they do not | |||
understand. | understand. | |||
4.2. Compression Codings | 4.2. Compression Codings | |||
The codings defined below can be used to compress the payload of a | The codings defined below can be used to compress the payload of a | |||
message. | message. | |||
4.2.1. Compress Coding | 4.2.1. Compress Coding | |||
The "compress" format is produced by the common UNIX file compression | The "compress" format is produced by the common UNIX file compression | |||
skipping to change at page 36, line 17 | skipping to change at page 37, line 35 | |||
4.2.3. Gzip Coding | 4.2.3. Gzip Coding | |||
The "gzip" format is produced by the file compression program "gzip" | The "gzip" format is produced by the file compression program "gzip" | |||
(GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv | (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv | |||
coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" | coding (LZ77) with a 32 bit CRC. Recipients SHOULD consider "x-gzip" | |||
to be equivalent to "gzip". | to be equivalent to "gzip". | |||
4.3. TE | 4.3. TE | |||
The "TE" header field in a request indicates what transfer-codings, | The "TE" header field in a request indicates what transfer codings, | |||
besides "chunked", the client is willing to accept in response, and | besides chunked, the client is willing to accept in response, and | |||
whether or not the client is willing to accept trailer fields in a | whether or not the client is willing to accept trailer fields in a | |||
chunked transfer-coding. | chunked transfer coding. | |||
The TE field-value consists of a comma-separated list of transfer- | The TE field-value consists of a comma-separated list of transfer | |||
coding names, each allowing for optional parameters (as described in | coding names, each allowing for optional parameters (as described in | |||
Section 4), and/or the keyword "trailers". Clients MUST NOT send the | Section 4), and/or the keyword "trailers". Clients MUST NOT send the | |||
chunked transfer-coding name in TE; chunked is always acceptable for | chunked transfer coding name in TE; chunked is always acceptable for | |||
HTTP/1.1 recipients. | HTTP/1.1 recipients. | |||
TE = #t-codings | TE = #t-codings | |||
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) | |||
t-ranking = OWS ";" OWS "q=" rank | t-ranking = OWS ";" OWS "q=" rank | |||
rank = ( "0" [ "." 0*3DIGIT ] ) | rank = ( "0" [ "." 0*3DIGIT ] ) | |||
/ ( "1" [ "." 0*3("0") ] ) | / ( "1" [ "." 0*3("0") ] ) | |||
Three examples of TE use are below. | Three examples of TE use are below. | |||
TE: deflate | TE: deflate | |||
TE: | TE: | |||
TE: trailers, deflate;q=0.5 | TE: trailers, deflate;q=0.5 | |||
The presence of the keyword "trailers" indicates that the client is | The presence of the keyword "trailers" indicates that the client is | |||
willing to accept trailer fields in a chunked transfer-coding, as | willing to accept trailer fields in a chunked transfer coding, as | |||
defined in Section 4.1, on behalf of itself and any downstream | defined in Section 4.1, on behalf of itself and any downstream | |||
clients. For chained requests, this implies that either: (a) all | clients. For chained requests, this implies that either: (a) all | |||
downstream clients are willing to accept trailer fields in the | downstream clients are willing to accept trailer fields in the | |||
forwarded response; or, (b) the client will attempt to buffer the | forwarded response; or, (b) the client will attempt to buffer the | |||
response on behalf of downstream recipients. Note that HTTP/1.1 does | response on behalf of downstream recipients. Note that HTTP/1.1 does | |||
not define any means to limit the size of a chunked response such | not define any means to limit the size of a chunked response such | |||
that a client can be assured of buffering the entire response. | that a client can be assured of buffering the entire response. | |||
When multiple transfer-codings are acceptable, the client MAY rank | When multiple transfer codings are acceptable, the client MAY rank | |||
the codings by preference using a case-insensitive "q" parameter | the codings by preference using a case-insensitive "q" parameter | |||
(similar to the qvalues used in content negotiation fields, Section | (similar to the qvalues used in content negotiation fields, Section | |||
6.3.1 of [Part2]). The rank value is a real number in the range 0 | 5.3.1 of [Part2]). The rank value is a real number in the range 0 | |||
through 1, where 0.001 is the least preferred and 1 is the most | through 1, where 0.001 is the least preferred and 1 is the most | |||
preferred; a value of 0 means "not acceptable". | preferred; a value of 0 means "not acceptable". | |||
If the TE field-value is empty or if no TE field is present, the only | If the TE field-value is empty or if no TE field is present, the only | |||
acceptable transfer-coding is "chunked". A message with no transfer- | acceptable transfer coding is chunked. A message with no transfer | |||
coding is always acceptable. | coding is always acceptable. | |||
Since the TE header field only applies to the immediate connection, a | Since the TE header field only applies to the immediate connection, a | |||
sender of TE MUST also send a "TE" connection option within the | sender of TE MUST also send a "TE" connection option within the | |||
Connection header field (Section 6.1) in order to prevent the TE | Connection header field (Section 6.1) in order to prevent the TE | |||
field from being forwarded by intermediaries that do not support its | field from being forwarded by intermediaries that do not support its | |||
semantics. | semantics. | |||
5. Message Routing | 5. Message Routing | |||
skipping to change at page 38, line 39 | skipping to change at page 40, line 10 | |||
request message (Section 3) with a request-target derived from the | request message (Section 3) with a request-target derived from the | |||
target URI. There are four distinct formats for the request-target, | target URI. There are four distinct formats for the request-target, | |||
depending on both the method being requested and whether the request | depending on both the method being requested and whether the request | |||
is to a proxy. | is to a proxy. | |||
request-target = origin-form | request-target = origin-form | |||
/ absolute-form | / absolute-form | |||
/ authority-form | / authority-form | |||
/ asterisk-form | / asterisk-form | |||
origin-form = path-absolute [ "?" query ] | origin-form = absolute-path [ "?" query ] | |||
absolute-form = absolute-URI | absolute-form = absolute-URI | |||
authority-form = authority | authority-form = authority | |||
asterisk-form = "*" | asterisk-form = "*" | |||
origin-form | ||||
The most common form of request-target is the origin-form. When | The most common form of request-target is the origin-form. When | |||
making a request directly to an origin server, other than a CONNECT | making a request directly to an origin server, other than a CONNECT | |||
or server-wide OPTIONS request (as detailed below), a client MUST | or server-wide OPTIONS request (as detailed below), a client MUST | |||
send only the absolute path and query components of the target URI as | send only the absolute path and query components of the target URI as | |||
the request-target. If the target URI's path component is empty, | the request-target. If the target URI's path component is empty, | |||
then the client MUST send "/" as the path within the origin-form of | then the client MUST send "/" as the path within the origin-form of | |||
request-target. A Host header field is also sent, as defined in | request-target. A Host header field is also sent, as defined in | |||
Section 5.4, containing the target URI's authority component | Section 5.4, containing the target URI's authority component | |||
(excluding any userinfo). | (excluding any userinfo). | |||
skipping to change at page 39, line 20 | skipping to change at page 40, line 41 | |||
directly from the origin server would open (or reuse) a TCP | directly from the origin server would open (or reuse) a TCP | |||
connection to port 80 of the host "www.example.org" and send the | connection to port 80 of the host "www.example.org" and send the | |||
lines: | lines: | |||
GET /where?q=now HTTP/1.1 | GET /where?q=now HTTP/1.1 | |||
Host: www.example.org | Host: www.example.org | |||
followed by the remainder of the request message. | followed by the remainder of the request message. | |||
absolute-form | ||||
When making a request to a proxy, other than a CONNECT or server-wide | When making a request to a proxy, other than a CONNECT or server-wide | |||
OPTIONS request (as detailed below), a client MUST send the target | OPTIONS request (as detailed below), a client MUST send the target | |||
URI in absolute-form as the request-target. The proxy is requested | URI in absolute-form as the request-target. The proxy is requested | |||
to either service that request from a valid cache, if possible, or | to either service that request from a valid cache, if possible, or | |||
make the same request on the client's behalf to either the next | make the same request on the client's behalf to either the next | |||
inbound proxy server or directly to the origin server indicated by | inbound proxy server or directly to the origin server indicated by | |||
the request-target. Requirements on such "forwarding" of messages | the request-target. Requirements on such "forwarding" of messages | |||
are defined in Section 5.6. | are defined in Section 5.7. | |||
An example absolute-form of request-line would be: | An example absolute-form of request-line would be: | |||
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 | |||
To allow for transition to the absolute-form for all requests in some | To allow for transition to the absolute-form for all requests in some | |||
future version of HTTP, HTTP/1.1 servers MUST accept the absolute- | future version of HTTP, HTTP/1.1 servers MUST accept the absolute- | |||
form in requests, even though HTTP/1.1 clients will only send them in | form in requests, even though HTTP/1.1 clients will only send them in | |||
requests to proxies. | requests to proxies. | |||
authority-form | ||||
The authority-form of request-target is only used for CONNECT | The authority-form of request-target is only used for CONNECT | |||
requests (Section 5.3.6 of [Part2]). When making a CONNECT request | requests (Section 4.3.6 of [Part2]). When making a CONNECT request | |||
to establish a tunnel through one or more proxies, a client MUST send | to establish a tunnel through one or more proxies, a client MUST send | |||
only the target URI's authority component (excluding any userinfo) as | only the target URI's authority component (excluding any userinfo) as | |||
the request-target. For example, | the request-target. For example, | |||
CONNECT www.example.com:80 HTTP/1.1 | CONNECT www.example.com:80 HTTP/1.1 | |||
asterisk-form | ||||
The asterisk-form of request-target is only used for a server-wide | The asterisk-form of request-target is only used for a server-wide | |||
OPTIONS request (Section 5.3.7 of [Part2]). When a client wishes to | OPTIONS request (Section 4.3.7 of [Part2]). When a client wishes to | |||
request OPTIONS for the server as a whole, as opposed to a specific | request OPTIONS for the server as a whole, as opposed to a specific | |||
named resource of that server, the client MUST send only "*" (%x2A) | named resource of that server, the client MUST send only "*" (%x2A) | |||
as the request-target. For example, | as the request-target. For example, | |||
OPTIONS * HTTP/1.1 | OPTIONS * HTTP/1.1 | |||
If a proxy receives an OPTIONS request with an absolute-form of | If a proxy receives an OPTIONS request with an absolute-form of | |||
request-target in which the URI has an empty path and no query | request-target in which the URI has an empty path and no query | |||
component, then the last proxy on the request chain MUST send a | component, then the last proxy on the request chain MUST send a | |||
request-target of "*" when it forwards the request to the indicated | request-target of "*" when it forwards the request to the indicated | |||
origin server. | origin server. | |||
For example, the request | For example, the request | |||
skipping to change at page 42, line 43 | skipping to change at page 44, line 24 | |||
An origin server that does not allow resources to differ by requested | An origin server that does not allow resources to differ by requested | |||
host MAY ignore the Host field-value and instead replace it with a | host MAY ignore the Host field-value and instead replace it with a | |||
configured server name when constructing the effective request URI. | configured server name when constructing the effective request URI. | |||
Recipients of an HTTP/1.0 request that lacks a Host header field MAY | Recipients of an HTTP/1.0 request that lacks a Host header field MAY | |||
attempt to use heuristics (e.g., examination of the URI path for | attempt to use heuristics (e.g., examination of the URI path for | |||
something unique to a particular host) in order to guess the | something unique to a particular host) in order to guess the | |||
effective request URI's authority component. | effective request URI's authority component. | |||
5.6. Message Forwarding | 5.6. Associating a Response to a Request | |||
HTTP does not include a request identifier for associating a given | ||||
request message with its corresponding one or more response messages. | ||||
Hence, it relies on the order of response arrival to correspond | ||||
exactly to the order in which requests are made on the same | ||||
connection. More than one response message per request only occurs | ||||
when one or more informational responses (1xx, see Section 6.2 of | ||||
[Part2]) precede a final response to the same request. | ||||
A client that has more than one outstanding request on a connection | ||||
MUST maintain a list of outstanding requests in the order sent and | ||||
MUST associate each received response message on that connection to | ||||
the highest ordered request that has not yet received a final (non- | ||||
1xx) response. | ||||
5.7. Message Forwarding | ||||
As described in Section 2.3, intermediaries can serve a variety of | As described in Section 2.3, intermediaries can serve a variety of | |||
roles in the processing of HTTP requests and responses. Some | roles in the processing of HTTP requests and responses. Some | |||
intermediaries are used to improve performance or availability. | intermediaries are used to improve performance or availability. | |||
Others are used for access control or to filter content. Since an | Others are used for access control or to filter content. Since an | |||
HTTP stream has characteristics similar to a pipe-and-filter | HTTP stream has characteristics similar to a pipe-and-filter | |||
architecture, there are no inherent limits to the extent an | architecture, there are no inherent limits to the extent an | |||
intermediary can enhance (or interfere) with either direction of the | intermediary can enhance (or interfere) with either direction of the | |||
stream. | stream. | |||
Intermediaries that forward a message MUST implement the Connection | Intermediaries that forward a message MUST implement the Connection | |||
header field, as specified in Section 6.1, to exclude fields that are | header field, as specified in Section 6.1, to exclude fields that are | |||
only intended for the incoming connection. | only intended for the incoming connection. | |||
In order to avoid request loops, a proxy that forwards requests to | In order to avoid request loops, a proxy that forwards requests to | |||
other proxies MUST be able to recognize and exclude all of its own | other proxies MUST be able to recognize and exclude all of its own | |||
server names, including any aliases, local variations, or literal IP | server names, including any aliases, local variations, or literal IP | |||
addresses. | addresses. | |||
5.7. Via | 5.7.1. Via | |||
The "Via" header field MUST be sent by a proxy or gateway in | The "Via" header field MUST be sent by a proxy or gateway in | |||
forwarded messages to indicate the intermediate protocols and | forwarded messages to indicate the intermediate protocols and | |||
recipients between the user agent and the server on requests, and | recipients between the user agent and the server on requests, and | |||
between the origin server and the client on responses. It is | between the origin server and the client on responses. It is | |||
analogous to the "Received" field used by email systems (Section | analogous to the "Received" field used by email systems (Section | |||
3.6.7 of [RFC5322]). Via is used in HTTP for tracking message | 3.6.7 of [RFC5322]). Via is used in HTTP for tracking message | |||
forwards, avoiding request loops, and identifying the protocol | forwards, avoiding request loops, and identifying the protocol | |||
capabilities of all senders along the request/response chain. | capabilities of all senders along the request/response chain. | |||
Via = 1#( received-protocol RWS received-by | Via = 1#( received-protocol RWS received-by | |||
[ RWS comment ] ) | [ RWS comment ] ) | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
; see Section 6.7 | ||||
received-by = ( uri-host [ ":" port ] ) / pseudonym | received-by = ( uri-host [ ":" port ] ) / pseudonym | |||
pseudonym = token | pseudonym = token | |||
The received-protocol indicates the protocol version of the message | The received-protocol indicates the protocol version of the message | |||
received by the server or client along each segment of the request/ | received by the server or client along each segment of the request/ | |||
response chain. The received-protocol version is appended to the Via | response chain. The received-protocol version is appended to the Via | |||
field value when the message is forwarded so that information about | field value when the message is forwarded so that information about | |||
the protocol capabilities of upstream applications remains visible to | the protocol capabilities of upstream applications remains visible to | |||
all recipients. | all recipients. | |||
skipping to change at page 44, line 33 | skipping to change at page 46, line 32 | |||
received-protocol values. For example, | received-protocol values. For example, | |||
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy | |||
could be collapsed to | could be collapsed to | |||
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy | |||
Senders SHOULD NOT combine multiple entries unless they are all under | Senders SHOULD NOT combine multiple entries unless they are all under | |||
the same organizational control and the hosts have already been | the same organizational control and the hosts have already been | |||
replaced by pseudonyms. Senders MUST NOT combine entries which have | replaced by pseudonyms. Senders MUST NOT combine entries that have | |||
different received-protocol values. | different received-protocol values. | |||
5.8. Message Transforming | 5.7.2. Transformations | |||
Some intermediaries include features for transforming messages and | ||||
their payloads. A transforming proxy might, for example, convert | ||||
between image formats in order to save cache space or to reduce the | ||||
amount of traffic on a slow link. However, operational problems | ||||
might occur when these transformations are applied to payloads | ||||
intended for critical applications, such as medical imaging or | ||||
scientific data analysis, particularly when integrity checks or | ||||
digital signatures are used to ensure that the payload received is | ||||
identical to the original. | ||||
If a proxy receives a request-target with a host name that is not a | If a proxy receives a request-target with a host name that is not a | |||
fully qualified domain name, it MAY add its own domain to the host | fully qualified domain name, it MAY add its own domain to the host | |||
name it received when forwarding the request. A proxy MUST NOT | name it received when forwarding the request. A proxy MUST NOT | |||
change the host name if it is a fully qualified domain name. | change the host name if it is a fully qualified domain name. | |||
A non-transforming proxy MUST NOT modify the "path-absolute" and | A proxy MUST NOT modify the "absolute-path" and "query" parts of the | |||
"query" parts of the received request-target when forwarding it to | received request-target when forwarding it to the next inbound | |||
the next inbound server, except as noted above to replace an empty | server, except as noted above to replace an empty path with "/" or | |||
path with "/" or "*". | "*". | |||
A non-transforming proxy MUST preserve the message payload (Section | ||||
3.3 of [Part2]), though it MAY change the message body through | ||||
application or removal of a transfer-coding (Section 4). | ||||
A non-transforming proxy SHOULD NOT modify header fields that provide | ||||
information about the end points of the communication chain, the | ||||
resource state, or the selected representation. | ||||
A non-transforming proxy MUST NOT modify any of the following fields | ||||
in a request or response, and it MUST NOT add any of these fields if | ||||
not already present: | ||||
o Allow (Section 8.4.1 of [Part2]) | ||||
o Content-Location (Section 3.1.4.2 of [Part2]) | ||||
o Content-MD5 (Section 14.15 of [RFC2616]) | ||||
o ETag (Section 2.3 of [Part4]) | ||||
o Last-Modified (Section 2.2 of [Part4]) | ||||
o Server (Section 8.4.2 of [Part2]) | ||||
A non-transforming proxy MUST NOT modify an Expires header field | ||||
(Section 7.3 of [Part6]) if already present in a response, but it MAY | ||||
add an Expires header field with a field-value identical to that of | ||||
the Date header field. | ||||
A proxy MUST NOT modify or add any of the following fields in a | ||||
message that contains the no-transform cache-control directive: | ||||
o Content-Encoding (Section 3.1.2.2 of [Part2]) | ||||
o Content-Range (Section 5.2 of [Part5]) | A proxy MUST NOT modify header fields that provide information about | |||
the end points of the communication chain, the resource state, or the | ||||
selected representation. A proxy MAY change the message body through | ||||
application or removal of a transfer coding (Section 4). | ||||
o Content-Type (Section 3.1.1.5 of [Part2]) | A non-transforming proxy MUST preserve the message payload (Section | |||
3.3 of [Part2]). A transforming proxy MUST preserve the payload of a | ||||
message that contains the no-transform cache-control directive. | ||||
A transforming proxy MAY modify or add these fields to a message that | A transforming proxy MAY transform the payload of a message that does | |||
does not include no-transform, but if it does so, it MUST add a | not contain the no-transform cache-control directive; if the payload | |||
Warning 214 (Transformation applied) if one does not already appear | is transformed, the transforming proxy MUST add a Warning 214 | |||
(Transformation applied) header field if one does not already appear | ||||
in the message (see Section 7.5 of [Part6]). | in the message (see Section 7.5 of [Part6]). | |||
Warning: Unnecessary modification of header fields might cause | ||||
authentication failures if stronger authentication mechanisms are | ||||
introduced in later versions of HTTP. Such authentication | ||||
mechanisms MAY rely on the values of header fields not listed | ||||
here. | ||||
5.9. Associating a Response to a Request | ||||
HTTP does not include a request identifier for associating a given | ||||
request message with its corresponding one or more response messages. | ||||
Hence, it relies on the order of response arrival to correspond | ||||
exactly to the order in which requests are made on the same | ||||
connection. More than one response message per request only occurs | ||||
when one or more informational responses (1xx, see Section 7.2 of | ||||
[Part2]) precede a final response to the same request. | ||||
A client that uses persistent connections and sends more than one | ||||
request per connection MUST maintain a list of outstanding requests | ||||
in the order sent on that connection and MUST associate each received | ||||
response message to the highest ordered request that has not yet | ||||
received a final (non-1xx) response. | ||||
6. Connection Management | 6. Connection Management | |||
HTTP messaging is independent of the underlying transport or session- | HTTP messaging is independent of the underlying transport or session- | |||
layer connection protocol(s). HTTP only presumes a reliable | layer connection protocol(s). HTTP only presumes a reliable | |||
transport with in-order delivery of requests and the corresponding | transport with in-order delivery of requests and the corresponding | |||
in-order delivery of responses. The mapping of HTTP request and | in-order delivery of responses. The mapping of HTTP request and | |||
response structures onto the data units of an underlying transport | response structures onto the data units of an underlying transport | |||
protocol is outside the scope of this specification. | protocol is outside the scope of this specification. | |||
As described in Section 5.2, the specific connection protocols to be | As described in Section 5.2, the specific connection protocols to be | |||
skipping to change at page 47, line 6 | skipping to change at page 48, line 13 | |||
fair use and detect denial of service attacks. | fair use and detect denial of service attacks. | |||
6.1. Connection | 6.1. Connection | |||
The "Connection" header field allows the sender to indicate desired | The "Connection" header field allows the sender to indicate desired | |||
control options for the current connection. In order to avoid | control options for the current connection. In order to avoid | |||
confusing downstream recipients, a proxy or gateway MUST remove or | confusing downstream recipients, a proxy or gateway MUST remove or | |||
replace any received connection options before forwarding the | replace any received connection options before forwarding the | |||
message. | message. | |||
When a header field is used to supply control information for or | When a header field aside from Connection is used to supply control | |||
about the current connection, the sender SHOULD list the | information for or about the current connection, the sender MUST list | |||
corresponding field-name within the "Connection" header field. A | the corresponding field-name within the "Connection" header field. A | |||
proxy or gateway MUST parse a received Connection header field before | proxy or gateway MUST parse a received Connection header field before | |||
a message is forwarded and, for each connection-option in this field, | a message is forwarded and, for each connection-option in this field, | |||
remove any header field(s) from the message with the same name as the | remove any header field(s) from the message with the same name as the | |||
connection-option, and then remove the Connection header field itself | connection-option, and then remove the Connection header field itself | |||
(or replace it with the intermediary's own connection options for the | (or replace it with the intermediary's own connection options for the | |||
forwarded message). | forwarded message). | |||
Hence, the Connection header field provides a declarative way of | Hence, the Connection header field provides a declarative way of | |||
distinguishing header fields that are only intended for the immediate | distinguishing header fields that are only intended for the immediate | |||
recipient ("hop-by-hop") from those fields that are intended for all | recipient ("hop-by-hop") from those fields that are intended for all | |||
skipping to change at page 47, line 31 | skipping to change at page 48, line 38 | |||
to be deployed without fear that they will be blindly forwarded by | to be deployed without fear that they will be blindly forwarded by | |||
older intermediaries. | older intermediaries. | |||
The Connection header field's value has the following grammar: | The Connection header field's value has the following grammar: | |||
Connection = 1#connection-option | Connection = 1#connection-option | |||
connection-option = token | connection-option = token | |||
Connection options are case-insensitive. | Connection options are case-insensitive. | |||
A sender MUST NOT include field-names in the Connection header field- | A sender MUST NOT send a connection option corresponding to a header | |||
value for fields that are defined as expressing constraints for all | field that is intended for all recipients of the payload. For | |||
recipients in the request or response chain, such as the Cache- | example, Cache-Control is never appropriate as a connection option | |||
Control header field (Section 7.2 of [Part6]). | (Section 7.2 of [Part6]). | |||
The connection options do not have to correspond to a header field | The connection options do not have to correspond to a header field | |||
present in the message, since a connection-specific header field | present in the message, since a connection-specific header field | |||
might not be needed if there are no parameters associated with that | might not be needed if there are no parameters associated with that | |||
connection option. Recipients that trigger certain connection | connection option. Recipients that trigger certain connection | |||
behavior based on the presence of connection options MUST do so based | behavior based on the presence of connection options MUST do so based | |||
on the presence of the connection-option rather than only the | on the presence of the connection-option rather than only the | |||
presence of the optional header field. In other words, if the | presence of the optional header field. In other words, if the | |||
connection option is received as a header field but not indicated | connection option is received as a header field but not indicated | |||
within the Connection field-value, then the recipient MUST ignore the | within the Connection field-value, then the recipient MUST ignore the | |||
skipping to change at page 48, line 16 | skipping to change at page 49, line 22 | |||
since it would be unwise for senders to use that field-name for | since it would be unwise for senders to use that field-name for | |||
anything else. | anything else. | |||
The "close" connection option is defined for a sender to signal that | The "close" connection option is defined for a sender to signal that | |||
this connection will be closed after completion of the response. For | this connection will be closed after completion of the response. For | |||
example, | example, | |||
Connection: close | Connection: close | |||
in either the request or the response header fields indicates that | in either the request or the response header fields indicates that | |||
the connection SHOULD be closed after the current request/response is | the connection MUST be closed after the current request/response is | |||
complete (Section 6.2.5). | complete (Section 6.6). | |||
A client that does not support persistent connections MUST send the | A client that does not support persistent connections MUST send the | |||
"close" connection option in every request message. | "close" connection option in every request message. | |||
A server that does not support persistent connections MUST send the | A server that does not support persistent connections MUST send the | |||
"close" connection option in every response message that does not | "close" connection option in every response message that does not | |||
have a 1xx (Informational) status code. | have a 1xx (Informational) status code. | |||
6.2. Persistent Connections | 6.2. Establishment | |||
HTTP was originally designed to use a separate connection for each | ||||
request/response pair. As the Web evolved and embedded requests | ||||
became common for inline images, the connection establishment | ||||
overhead was a significant drain on performance and a concern for | ||||
Internet congestion. Message framing (via Content-Length) and | ||||
optional long-lived connections (via Keep-Alive) were added to | ||||
HTTP/1.0 in order to improve performance for some requests. However, | ||||
these extensions were insufficient for dynamically generated | ||||
responses and difficult to use with intermediaries. | ||||
HTTP/1.1 defaults to the use of "persistent connections", which allow | ||||
multiple requests and responses to be carried over a single | ||||
connection. The "close" connection-option is used to signal that a | ||||
connection will close after the current request/response. Persistent | ||||
connections have a number of advantages: | ||||
o By opening and closing fewer connections, CPU time is saved in | ||||
routers and hosts (clients, servers, proxies, gateways, tunnels, | ||||
or caches), and memory used for protocol control blocks can be | ||||
saved in hosts. | ||||
o Most requests and responses can be pipelined on a connection. | ||||
Pipelining allows a client to make multiple requests without | ||||
waiting for each response, allowing a single connection to be used | ||||
much more efficiently and with less overall latency. | ||||
o For TCP connections, network congestion is reduced by eliminating | ||||
the packets associated with the three way handshake and graceful | ||||
close procedures, and by allowing sufficient time to determine the | ||||
congestion state of the network. | ||||
o Latency on subsequent requests is reduced since there is no time | ||||
spent in the connection opening handshake. | ||||
o HTTP can evolve more gracefully, since most errors can be reported | ||||
without the penalty of closing the connection. Clients using | ||||
future versions of HTTP might optimistically try a new feature, | ||||
but if communicating with an older server, retry with old | ||||
semantics after an error is reported. | ||||
HTTP implementations SHOULD implement persistent connections. | ||||
6.2.1. Establishment | ||||
It is beyond the scope of this specification to describe how | It is beyond the scope of this specification to describe how | |||
connections are established via various transport or session-layer | connections are established via various transport or session-layer | |||
protocols. Each connection applies to only one transport link. | protocols. Each connection applies to only one transport link. | |||
6.3. Persistence | ||||
HTTP/1.1 defaults to the use of "persistent connections", allowing | ||||
multiple requests and responses to be carried over a single | ||||
connection. The "close" connection-option is used to signal that a | ||||
connection will not persist after the current request/response. HTTP | ||||
implementations SHOULD support persistent connections. | ||||
A recipient determines whether a connection is persistent or not | A recipient determines whether a connection is persistent or not | |||
based on the most recently received message's protocol version and | based on the most recently received message's protocol version and | |||
Connection header field (if any): | Connection header field (if any): | |||
o If the close connection option is present, the connection will not | o If the close connection option is present, the connection will not | |||
persist after the current response; else, | persist after the current response; else, | |||
o If the received protocol is HTTP/1.1 (or later), the connection | o If the received protocol is HTTP/1.1 (or later), the connection | |||
will persist after the current response; else, | will persist after the current response; else, | |||
o If the received protocol is HTTP/1.0, the "keep-alive" connection | o If the received protocol is HTTP/1.0, the "keep-alive" connection | |||
option is present, the recipient is not a proxy, and the recipient | option is present, the recipient is not a proxy, and the recipient | |||
wishes to honor the HTTP/1.0 "keep-alive" mechanism, the | wishes to honor the HTTP/1.0 "keep-alive" mechanism, the | |||
connection will persist after the current response; otherwise, | connection will persist after the current response; otherwise, | |||
o The connection will close after the current response. | o The connection will close after the current response. | |||
A proxy server MUST NOT maintain a persistent connection with an | ||||
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and | ||||
discussion of the problems with the Keep-Alive header field | ||||
implemented by many HTTP/1.0 clients). | ||||
6.2.2. Reuse | ||||
In order to remain persistent, all messages on a connection MUST have | ||||
a self-defined message length (i.e., one not defined by closure of | ||||
the connection), as described in Section 3.3. | ||||
A server MAY assume that an HTTP/1.1 client intends to maintain a | A server MAY assume that an HTTP/1.1 client intends to maintain a | |||
persistent connection until a close connection option is received in | persistent connection until a close connection option is received in | |||
a request. | a request. | |||
A client MAY reuse a persistent connection until it sends or receives | A client MAY reuse a persistent connection until it sends or receives | |||
a close connection option or receives an HTTP/1.0 response without a | a close connection option or receives an HTTP/1.0 response without a | |||
"keep-alive" connection option. | "keep-alive" connection option. | |||
In order to remain persistent, all messages on a connection MUST have | ||||
a self-defined message length (i.e., one not defined by closure of | ||||
the connection), as described in Section 3.3. A server MUST read the | ||||
entire request message body or close the connection after sending its | ||||
response, since otherwise the remaining data on a persistent | ||||
connection would be misinterpreted as the next request. Likewise, a | ||||
client MUST read the entire response message body if it intends to | ||||
reuse the same connection for a subsequent request. | ||||
A proxy server MUST NOT maintain a persistent connection with an | ||||
HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and | ||||
discussion of the problems with the Keep-Alive header field | ||||
implemented by many HTTP/1.0 clients). | ||||
Clients and servers SHOULD NOT assume that a persistent connection is | Clients and servers SHOULD NOT assume that a persistent connection is | |||
maintained for HTTP versions less than 1.1 unless it is explicitly | maintained for HTTP versions less than 1.1 unless it is explicitly | |||
signaled. See Appendix A.1.2 for more information on backward | signaled. See Appendix A.1.2 for more information on backward | |||
compatibility with HTTP/1.0 clients. | compatibility with HTTP/1.0 clients. | |||
6.2.2.1. Pipelining | 6.3.1. Retrying Requests | |||
Connections can be closed at any time, with or without intention. | ||||
Implementations ought to anticipate the need to recover from | ||||
asynchronous close events. | ||||
When an inbound connection is closed prematurely, a client MAY open a | ||||
new connection and automatically retransmit an aborted sequence of | ||||
requests if all of those requests have idempotent methods (Section | ||||
4.2.2 of [Part2]). A proxy MUST NOT automatically retry non- | ||||
idempotent requests. | ||||
A user agent MUST NOT automatically retry a request with a non- | ||||
idempotent method unless it has some means to know that the request | ||||
semantics are actually idempotent, regardless of the method, or some | ||||
means to detect that the original request was never applied. For | ||||
example, a user agent that knows (through design or configuration) | ||||
that a POST request to a given resource is safe can repeat that | ||||
request automatically. Likewise, a user agent designed specifically | ||||
to operate on a version control repository might be able to recover | ||||
from partial failure conditions by checking the target resource | ||||
revision(s) after a failed connection, reverting or fixing any | ||||
changes that were partially applied, and then automatically retrying | ||||
the requests that failed. | ||||
An automatic retry SHOULD NOT be repeated if it fails. | ||||
6.3.2. Pipelining | ||||
A client that supports persistent connections MAY "pipeline" its | A client that supports persistent connections MAY "pipeline" its | |||
requests (i.e., send multiple requests without waiting for each | requests (i.e., send multiple requests without waiting for each | |||
response). A server MUST send its responses to those requests in the | response). A server MAY process a sequence of pipelined requests in | |||
same order that the requests were received. | parallel if they all have safe methods (Section 4.2.1 of [Part2]), | |||
but MUST send the corresponding responses in the same order that the | ||||
Clients which assume persistent connections and pipeline immediately | requests were received. | |||
after connection establishment SHOULD be prepared to retry their | ||||
connection if the first pipelined attempt fails. If a client does | ||||
such a retry, it MUST NOT pipeline before it knows the connection is | ||||
persistent. Clients MUST also be prepared to resend their requests | ||||
if the server closes the connection before sending all of the | ||||
corresponding responses. | ||||
Clients SHOULD NOT pipeline requests using non-idempotent request | A client that pipelines requests MUST be prepared to retry those | |||
methods or non-idempotent sequences of request methods (see Section | requests if the connection closes before it receives all of the | |||
5.2.2 of [Part2]). Otherwise, a premature termination of the | corresponding responses. A client that assumes a persistent | |||
transport connection could lead to indeterminate results. A client | connection and pipelines immediately after connection establishment | |||
wishing to send a non-idempotent request SHOULD wait to send that | MUST NOT pipeline on a retry connection until it knows the connection | |||
request until it has received the response status line for the | is persistent. | |||
previous request. | ||||
6.2.2.2. Retrying Requests | Idempotent methods (Section 4.2.2 of [Part2]) are significant to | |||
pipelining because they can be automatically retried after a | ||||
connection failure. A user agent SHOULD NOT pipeline requests after | ||||
a non-idempotent method until the final response status code for that | ||||
method has been received, unless the user agent has a means to detect | ||||
and recover from partial failure conditions involving the pipelined | ||||
sequence. | ||||
Senders can close the transport connection at any time. Therefore, | An intermediary that receives pipelined requests MAY pipeline those | |||
clients, servers, and proxies MUST be able to recover from | requests when forwarding them inbound, since it can rely on the | |||
asynchronous close events. Client software MAY reopen the transport | outbound user agent(s) to determine what requests can be safely | |||
connection and retransmit the aborted sequence of requests without | pipelined. If the inbound connection fails before receiving a | |||
user interaction so long as the request sequence is idempotent (see | response, the pipelining intermediary MAY attempt to retry a sequence | |||
Section 5.2.2 of [Part2]). Non-idempotent request methods or | of requests that have yet to receive a response if the requests all | |||
sequences MUST NOT be automatically retried, although user agents MAY | have idempotent methods; otherwise, the pipelining intermediary | |||
offer a human operator the choice of retrying the request(s). | SHOULD forward any received responses and then close the | |||
Confirmation by user-agent software with semantic understanding of | corresponding outbound connection(s) so that the outbound user | |||
the application MAY substitute for user confirmation. The automatic | agent(s) can recover accordingly. | |||
retry SHOULD NOT be repeated if the second sequence of requests | ||||
fails. | ||||
6.2.3. Concurrency | 6.4. Concurrency | |||
Clients SHOULD limit the number of simultaneous connections that they | Clients SHOULD limit the number of simultaneous connections that they | |||
maintain to a given server. | maintain to a given server. | |||
Previous revisions of HTTP gave a specific number of connections as a | Previous revisions of HTTP gave a specific number of connections as a | |||
ceiling, but this was found to be impractical for many applications. | ceiling, but this was found to be impractical for many applications. | |||
As a result, this specification does not mandate a particular maximum | As a result, this specification does not mandate a particular maximum | |||
number of connections, but instead encourages clients to be | number of connections, but instead encourages clients to be | |||
conservative when opening multiple connections. | conservative when opening multiple connections. | |||
Multiple connections are typically used to avoid the "head-of-line | Multiple connections are typically used to avoid the "head-of-line | |||
blocking" problem, wherein a request that takes significant server- | blocking" problem, wherein a request that takes significant server- | |||
side processing and/or has a large payload blocks subsequent requests | side processing and/or has a large payload blocks subsequent requests | |||
on the same connection. However, each connection consumes server | on the same connection. However, each connection consumes server | |||
resources. Furthermore, using multiple connections can cause | resources. Furthermore, using multiple connections can cause | |||
undesirable side effects in congested networks. | undesirable side effects in congested networks. | |||
Note that servers might reject traffic that they deem abusive, | Note that servers might reject traffic that they deem abusive, | |||
including an excessive number of connections from a client. | including an excessive number of connections from a client. | |||
6.2.4. Failures and Time-outs | 6.5. Failures and Time-outs | |||
Servers will usually have some time-out value beyond which they will | Servers will usually have some time-out value beyond which they will | |||
no longer maintain an inactive connection. Proxy servers might make | no longer maintain an inactive connection. Proxy servers might make | |||
this a higher value since it is likely that the client will be making | this a higher value since it is likely that the client will be making | |||
more connections through the same server. The use of persistent | more connections through the same server. The use of persistent | |||
connections places no requirements on the length (or existence) of | connections places no requirements on the length (or existence) of | |||
this time-out for either the client or the server. | this time-out for either the client or the server. | |||
When a client or server wishes to time-out it SHOULD issue a graceful | When a client or server wishes to time-out it SHOULD issue a graceful | |||
close on the transport connection. Clients and servers SHOULD both | close on the transport connection. Clients and servers SHOULD both | |||
skipping to change at page 52, line 20 | skipping to change at page 53, line 13 | |||
underlying transport's flow control mechanisms to resolve temporary | underlying transport's flow control mechanisms to resolve temporary | |||
overloads, rather than terminate connections with the expectation | overloads, rather than terminate connections with the expectation | |||
that clients will retry. The latter technique can exacerbate network | that clients will retry. The latter technique can exacerbate network | |||
congestion. | congestion. | |||
A client sending a message body SHOULD monitor the network connection | A client sending a message body SHOULD monitor the network connection | |||
for an error status code while it is transmitting the request. If | for an error status code while it is transmitting the request. If | |||
the client sees an error status code, it SHOULD immediately cease | the client sees an error status code, it SHOULD immediately cease | |||
transmitting the body and close the connection. | transmitting the body and close the connection. | |||
6.2.5. Tear-down | 6.6. Tear-down | |||
The Connection header field (Section 6.1) provides a "close" | The Connection header field (Section 6.1) provides a "close" | |||
connection option that a sender SHOULD send when it wishes to close | connection option that a sender SHOULD send when it wishes to close | |||
the connection after the current request/response pair. | the connection after the current request/response pair. | |||
A client that sends a close connection option MUST NOT send further | A client that sends a close connection option MUST NOT send further | |||
requests on that connection (after the one containing close) and MUST | requests on that connection (after the one containing close) and MUST | |||
close the connection after reading the final response message | close the connection after reading the final response message | |||
corresponding to this request. | corresponding to this request. | |||
A server that receives a close connection option MUST initiate a | A server that receives a close connection option MUST initiate a | |||
lingering close of the connection after it sends the final response | lingering close (see below) of the connection after it sends the | |||
to the request that contained close. The server SHOULD include a | final response to the request that contained close. The server | |||
close connection option in its final response on that connection. | SHOULD send a close connection option in its final response on that | |||
The server MUST NOT process any further requests received on that | connection. The server MUST NOT process any further requests | |||
connection. | received on that connection. | |||
A server that sends a close connection option MUST initiate a | A server that sends a close connection option MUST initiate a | |||
lingering close of the connection after it sends the response | lingering close of the connection after it sends the response | |||
containing close. The server MUST NOT process any further requests | containing close. The server MUST NOT process any further requests | |||
received on that connection. | received on that connection. | |||
A client that receives a close connection option MUST cease sending | A client that receives a close connection option MUST cease sending | |||
requests on that connection and close the connection after reading | requests on that connection and close the connection after reading | |||
the response message containing the close; if additional pipelined | the response message containing the close; if additional pipelined | |||
requests had been sent on the connection, the client SHOULD assume | requests had been sent on the connection, the client SHOULD assume | |||
skipping to change at page 53, line 23 | skipping to change at page 54, line 17 | |||
write connection (a half-close) and continuing to read from the | write connection (a half-close) and continuing to read from the | |||
connection until the connection is closed by the client or the server | connection until the connection is closed by the client or the server | |||
is reasonably certain that its own TCP stack has received the | is reasonably certain that its own TCP stack has received the | |||
client's acknowledgement of the packet(s) containing the server's | client's acknowledgement of the packet(s) containing the server's | |||
last response. It is then safe for the server to fully close the | last response. It is then safe for the server to fully close the | |||
connection. | connection. | |||
It is unknown whether the reset problem is exclusive to TCP or might | It is unknown whether the reset problem is exclusive to TCP or might | |||
also be found in other transport connection protocols. | also be found in other transport connection protocols. | |||
6.3. Upgrade | 6.7. Upgrade | |||
The "Upgrade" header field is intended to provide a simple mechanism | The "Upgrade" header field is intended to provide a simple mechanism | |||
for transitioning from HTTP/1.1 to some other protocol on the same | for transitioning from HTTP/1.1 to some other protocol on the same | |||
connection. A client MAY send a list of protocols in the Upgrade | connection. A client MAY send a list of protocols in the Upgrade | |||
header field of a request to invite the server to switch to one or | header field of a request to invite the server to switch to one or | |||
more of those protocols before sending the final response. A server | more of those protocols before sending the final response. A server | |||
MUST send an Upgrade header field in 101 (Switching Protocols) | MUST send an Upgrade header field in 101 (Switching Protocols) | |||
responses to indicate which protocol(s) are being switched to, and | responses to indicate which protocol(s) are being switched to, and | |||
MUST send it in 426 (Upgrade Required) responses to indicate | MUST send it in 426 (Upgrade Required) responses to indicate | |||
acceptable protocols. A server MAY send an Upgrade header field in | acceptable protocols. A server MAY send an Upgrade header field in | |||
skipping to change at page 54, line 14 | skipping to change at page 55, line 7 | |||
or target resource). | or target resource). | |||
Upgrade cannot be used to insist on a protocol change; its acceptance | Upgrade cannot be used to insist on a protocol change; its acceptance | |||
and use by the server is optional. The capabilities and nature of | and use by the server is optional. The capabilities and nature of | |||
the application-level communication after the protocol change is | the application-level communication after the protocol change is | |||
entirely dependent upon the new protocol chosen, although the first | entirely dependent upon the new protocol chosen, although the first | |||
action after changing the protocol MUST be a response to the initial | action after changing the protocol MUST be a response to the initial | |||
HTTP request that contained the Upgrade header field. | HTTP request that contained the Upgrade header field. | |||
For example, if the Upgrade header field is received in a GET request | For example, if the Upgrade header field is received in a GET request | |||
and the server decides to switch protocols, then it MUST first | and the server decides to switch protocols, then it first responds | |||
respond with a 101 (Switching Protocols) message in HTTP/1.1 and then | with a 101 (Switching Protocols) message in HTTP/1.1 and then | |||
immediately follow that with the new protocol's equivalent of a | immediately follows that with the new protocol's equivalent of a | |||
response to a GET on the target resource. This allows a connection | response to a GET on the target resource. This allows a connection | |||
to be upgraded to protocols with the same semantics as HTTP without | to be upgraded to protocols with the same semantics as HTTP without | |||
the latency cost of an additional round-trip. A server MUST NOT | the latency cost of an additional round-trip. A server MUST NOT | |||
switch protocols unless the received message semantics can be honored | switch protocols unless the received message semantics can be honored | |||
by the new protocol; an OPTIONS request can be honored by any | by the new protocol; an OPTIONS request can be honored by any | |||
protocol. | protocol. | |||
When Upgrade is sent, a sender MUST also send a Connection header | When Upgrade is sent, a sender MUST also send a Connection header | |||
field (Section 6.1) that contains the "upgrade" connection option, in | field (Section 6.1) that contains the "upgrade" connection option, in | |||
order to prevent Upgrade from being accidentally forwarded by | order to prevent Upgrade from being accidentally forwarded by | |||
intermediaries that might not implement the listed protocols. A | intermediaries that might not implement the listed protocols. A | |||
server MUST ignore an Upgrade header field that is received in an | server MUST ignore an Upgrade header field that is received in an | |||
HTTP/1.0 request. | HTTP/1.0 request. | |||
The Upgrade header field only applies to switching application-level | The Upgrade header field only applies to switching application-level | |||
protocols on the existing connection; it cannot be used to switch to | protocols on the existing connection; it cannot be used to switch to | |||
a protocol on a different connection. For that purpose, it is more | a protocol on a different connection. For that purpose, it is more | |||
appropriate to use a 3xx (Redirection) response (Section 7.4 of | appropriate to use a 3xx (Redirection) response (Section 6.4 of | |||
[Part2]). | [Part2]). | |||
This specification only defines the protocol name "HTTP" for use by | This specification only defines the protocol name "HTTP" for use by | |||
the family of Hypertext Transfer Protocols, as defined by the HTTP | the family of Hypertext Transfer Protocols, as defined by the HTTP | |||
version rules of Section 2.6 and future updates to this | version rules of Section 2.6 and future updates to this | |||
specification. Additional tokens can be registered with IANA using | specification. Additional tokens ought to be registered with IANA | |||
the registration procedure defined in Section 7.6. | using the registration procedure defined in Section 7.6. | |||
7. IANA Considerations | 7. IANA Considerations | |||
7.1. Header Field Registration | 7.1. Header Field Registration | |||
HTTP header fields are registered within the Message Header Field | HTTP header fields are registered within the Message Header Field | |||
Registry [RFC3864] maintained by IANA at <http://www.iana.org/ | Registry [BCP90] maintained by IANA at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html>. | assignments/message-headers/message-header-index.html>. | |||
This document defines the following HTTP header fields, so their | This document defines the following HTTP header fields, so their | |||
associated registry entries shall be updated according to the | associated registry entries shall be updated according to the | |||
permanent registrations below: | permanent registrations below: | |||
+-------------------+----------+----------+---------------+ | +-------------------+----------+----------+---------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+---------------+ | +-------------------+----------+----------+---------------+ | |||
| Connection | http | standard | Section 6.1 | | | Connection | http | standard | Section 6.1 | | |||
| Content-Length | http | standard | Section 3.3.2 | | | Content-Length | http | standard | Section 3.3.2 | | |||
| Host | http | standard | Section 5.4 | | | Host | http | standard | Section 5.4 | | |||
| TE | http | standard | Section 4.3 | | | TE | http | standard | Section 4.3 | | |||
| Trailer | http | standard | Section 4.1.1 | | | Trailer | http | standard | Section 4.1.1 | | |||
| Transfer-Encoding | http | standard | Section 3.3.1 | | | Transfer-Encoding | http | standard | Section 3.3.1 | | |||
| Upgrade | http | standard | Section 6.3 | | | Upgrade | http | standard | Section 6.7 | | |||
| Via | http | standard | Section 5.7 | | | Via | http | standard | Section 5.7.1 | | |||
+-------------------+----------+----------+---------------+ | +-------------------+----------+----------+---------------+ | |||
Furthermore, the header field-name "Close" shall be registered as | Furthermore, the header field-name "Close" shall be registered as | |||
"reserved", since using that name as an HTTP header field might | "reserved", since using that name as an HTTP header field might | |||
conflict with the "close" connection option of the "Connection" | conflict with the "close" connection option of the "Connection" | |||
header field (Section 6.1). | header field (Section 6.1). | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
| Close | http | reserved | Section 7.1 | | | Close | http | reserved | Section 7.1 | | |||
+-------------------+----------+----------+-------------+ | +-------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
7.2. URI Scheme Registration | 7.2. URI Scheme Registration | |||
IANA maintains the registry of URI Schemes [RFC4395] at | IANA maintains the registry of URI Schemes [BCP115] at | |||
<http://www.iana.org/assignments/uri-schemes.html>. | <http://www.iana.org/assignments/uri-schemes.html>. | |||
This document defines the following URI schemes, so their associated | This document defines the following URI schemes, so their associated | |||
registry entries shall be updated according to the permanent | registry entries shall be updated according to the permanent | |||
registrations below: | registrations below: | |||
+------------+------------------------------------+---------------+ | +------------+------------------------------------+---------------+ | |||
| URI Scheme | Description | Reference | | | URI Scheme | Description | Reference | | |||
+------------+------------------------------------+---------------+ | +------------+------------------------------------+---------------+ | |||
| http | Hypertext Transfer Protocol | Section 2.7.1 | | | http | Hypertext Transfer Protocol | Section 2.7.1 | | |||
| https | Hypertext Transfer Protocol Secure | Section 2.7.2 | | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | | |||
+------------+------------------------------------+---------------+ | +------------+------------------------------------+---------------+ | |||
7.3. Internet Media Type Registrations | 7.3. Internet Media Type Registration | |||
This document serves as the specification for the Internet media | This document serves as the specification for the Internet media | |||
types "message/http" and "application/http". The following is to be | types "message/http" and "application/http". The following is to be | |||
registered with IANA (see [RFC4288]). | registered with IANA (see [BCP13]). | |||
7.3.1. Internet Media Type message/http | 7.3.1. Internet Media Type message/http | |||
The message/http type can be used to enclose a single HTTP request or | The message/http type can be used to enclose a single HTTP request or | |||
response message, provided that it obeys the MIME restrictions for | response message, provided that it obeys the MIME restrictions for | |||
all "message" types regarding line length and encodings. | all "message" types regarding line length and encodings. | |||
Type name: message | Type name: message | |||
Subtype name: http | Subtype name: http | |||
skipping to change at page 58, line 47 | skipping to change at page 59, line 41 | |||
Values to be added to this name space require IETF Review (see | Values to be added to this name space require IETF Review (see | |||
Section 4.1 of [RFC5226]), and MUST conform to the purpose of | Section 4.1 of [RFC5226]), and MUST conform to the purpose of | |||
transfer coding defined in this section. Use of program names for | transfer coding defined in this section. Use of program names for | |||
the identification of encoding formats is not desirable and is | the identification of encoding formats is not desirable and is | |||
discouraged for future encodings. | discouraged for future encodings. | |||
The registry itself is maintained at | The registry itself is maintained at | |||
<http://www.iana.org/assignments/http-parameters>. | <http://www.iana.org/assignments/http-parameters>. | |||
7.5. Transfer Coding Registrations | 7.5. Transfer Coding Registration | |||
The HTTP Transfer Coding Registry shall be updated with the | The HTTP Transfer Coding Registry shall be updated with the | |||
registrations below: | registrations below: | |||
+----------+----------------------------------------+---------------+ | +----------+----------------------------------------+---------------+ | |||
| Name | Description | Reference | | | Name | Description | Reference | | |||
+----------+----------------------------------------+---------------+ | +----------+----------------------------------------+---------------+ | |||
| chunked | Transfer in a series of chunks | Section 4.1 | | | chunked | Transfer in a series of chunks | Section 4.1 | | |||
| compress | UNIX "compress" program method | Section 4.2.1 | | | compress | UNIX "compress" program method | Section 4.2.1 | | |||
| deflate | "deflate" compression mechanism | Section 4.2.2 | | | deflate | "deflate" compression mechanism | Section 4.2.2 | | |||
skipping to change at page 60, line 23 | skipping to change at page 61, line 23 | |||
+-------+----------------------+----------------------+-------------+ | +-------+----------------------+----------------------+-------------+ | |||
| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | | | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | | |||
| | Protocol | (e.g, "2.0") | | | | | Protocol | (e.g, "2.0") | | | |||
+-------+----------------------+----------------------+-------------+ | +-------+----------------------+----------------------+-------------+ | |||
The responsible party is: "IETF (iesg@ietf.org) - Internet | The responsible party is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
8. Security Considerations | 8. Security Considerations | |||
This section is meant to inform application developers, information | This section is meant to inform developers, information providers, | |||
providers, and users of the security limitations in HTTP/1.1 as | and users of known security concerns relevant to HTTP/1.1 message | |||
described by this document. The discussion does not include | syntax, parsing, and routing. | |||
definitive solutions to the problems revealed, though it does make | ||||
some suggestions for reducing security risks. | ||||
8.1. Personal Information | ||||
HTTP clients are often privy to large amounts of personal | ||||
information, including both information provided by the user to | ||||
interact with resources (e.g., the user's name, location, mail | ||||
address, passwords, encryption keys, etc.) and information about the | ||||
user's browsing activity over time (e.g., history, bookmarks, etc.). | ||||
HTTP implementations need to prevent unintentional leakage of this | ||||
information. | ||||
8.2. Abuse of Server Log Information | ||||
A server is in the position to save personal data about a user's | ||||
requests which might identify their reading patterns or subjects of | ||||
interest. In particular, log information gathered at an intermediary | ||||
often contains a history of user agent interaction, across a | ||||
multitude of sites, that can be traced to individual users. | ||||
HTTP log information is confidential in nature; its handling is often | ||||
constrained by laws and regulations. Log information needs to be | ||||
securely stored and appropriate guidelines followed for its analysis. | ||||
Anonymization of personal information within individual entries | ||||
helps, but is generally not sufficient to prevent real log traces | ||||
from being re-identified based on correlation with other access | ||||
characteristics. As such, access traces that are keyed to a specific | ||||
client should not be published even if the key is pseudonymous. | ||||
To minimize the risk of theft or accidental publication, log | ||||
information should be purged of personally identifiable information, | ||||
including user identifiers, IP addresses, and user-provided query | ||||
parameters, as soon as that information is no longer necessary to | ||||
support operational needs for security, auditing, or fraud control. | ||||
8.3. Attacks Based On File and Path Names | ||||
Origin servers SHOULD be careful to restrict the documents returned | ||||
by HTTP requests to be only those that were intended by the server | ||||
administrators. If an HTTP server translates HTTP URIs directly into | ||||
file system calls, the server MUST take special care not to serve | ||||
files that were not intended to be delivered to HTTP clients. For | ||||
example, UNIX, Microsoft Windows, and other operating systems use | ||||
".." as a path component to indicate a directory level above the | ||||
current one. On such a system, an HTTP server MUST disallow any such | ||||
construct in the request-target if it would otherwise allow access to | ||||
a resource outside those intended to be accessible via the HTTP | ||||
server. Similarly, files intended for reference only internally to | ||||
the server (such as access control files, configuration files, and | ||||
script code) MUST be protected from inappropriate retrieval, since | ||||
they might contain sensitive information. | ||||
8.4. DNS-related Attacks | 8.1. DNS-related Attacks | |||
HTTP clients rely heavily on the Domain Name Service (DNS), and are | HTTP clients rely heavily on the Domain Name Service (DNS), and are | |||
thus generally prone to security attacks based on the deliberate | thus generally prone to security attacks based on the deliberate | |||
misassociation of IP addresses and DNS names not protected by DNSSec. | misassociation of IP addresses and DNS names not protected by DNSSEC. | |||
Clients need to be cautious in assuming the validity of an IP number/ | Clients need to be cautious in assuming the validity of an IP number/ | |||
DNS name association unless the response is protected by DNSSec | DNS name association unless the response is protected by DNSSEC | |||
([RFC4033]). | ([RFC4033]). | |||
8.5. Intermediaries and Caching | 8.2. Intermediaries and Caching | |||
By their very nature, HTTP intermediaries are men-in-the-middle, and | By their very nature, HTTP intermediaries are men-in-the-middle, and | |||
represent an opportunity for man-in-the-middle attacks. Compromise | represent an opportunity for man-in-the-middle attacks. Compromise | |||
of the systems on which the intermediaries run can result in serious | of the systems on which the intermediaries run can result in serious | |||
security and privacy problems. Intermediaries have access to | security and privacy problems. Intermediaries have access to | |||
security-related information, personal information about individual | security-related information, personal information about individual | |||
users and organizations, and proprietary information belonging to | users and organizations, and proprietary information belonging to | |||
users and content providers. A compromised intermediary, or an | users and content providers. A compromised intermediary, or an | |||
intermediary implemented or configured without regard to security and | intermediary implemented or configured without regard to security and | |||
privacy considerations, might be used in the commission of a wide | privacy considerations, might be used in the commission of a wide | |||
skipping to change at page 62, line 16 | skipping to change at page 62, line 11 | |||
to cache poisoning attacks. | to cache poisoning attacks. | |||
Implementers need to consider the privacy and security implications | Implementers need to consider the privacy and security implications | |||
of their design and coding decisions, and of the configuration | of their design and coding decisions, and of the configuration | |||
options they provide to operators (especially the default | options they provide to operators (especially the default | |||
configuration). | configuration). | |||
Users need to be aware that intermediaries are no more trustworthy | Users need to be aware that intermediaries are no more trustworthy | |||
than the people who run them; HTTP itself cannot solve this problem. | than the people who run them; HTTP itself cannot solve this problem. | |||
8.6. Protocol Element Size Overflows | 8.3. Buffer Overflows | |||
Because HTTP uses mostly textual, character-delimited fields, | Because HTTP uses mostly textual, character-delimited fields, | |||
attackers can overflow buffers in implementations, and/or perform a | attackers can overflow buffers in implementations, and/or perform a | |||
Denial of Service against implementations that accept fields with | Denial of Service against implementations that accept fields with | |||
unlimited lengths. | unlimited lengths. | |||
To promote interoperability, this specification makes specific | To promote interoperability, this specification makes specific | |||
recommendations for minimum size limits on request-line | recommendations for minimum size limits on request-line | |||
(Section 3.1.1) and blocks of header fields (Section 3.2). These are | (Section 3.1.1) and blocks of header fields (Section 3.2). These are | |||
minimum recommendations, chosen to be supportable even by | minimum recommendations, chosen to be supportable even by | |||
implementations with limited resources; it is expected that most | implementations with limited resources; it is expected that most | |||
implementations will choose substantially higher limits. | implementations will choose substantially higher limits. | |||
This specification also provides a way for servers to reject messages | This specification also provides a way for servers to reject messages | |||
that have request-targets that are too long (Section 7.5.12 of | that have request-targets that are too long (Section 6.5.12 of | |||
[Part2]) or request entities that are too large (Section 7.5 of | [Part2]) or request entities that are too large (Section 6.5 of | |||
[Part2]). | [Part2]). | |||
Recipients SHOULD carefully limit the extent to which they read other | Recipients SHOULD carefully limit the extent to which they read other | |||
fields, including (but not limited to) request methods, response | fields, including (but not limited to) request methods, response | |||
status phrases, header field-names, and body chunks, so as to avoid | status phrases, header field-names, and body chunks, so as to avoid | |||
denial of service attacks without impeding interoperability. | denial of service attacks without impeding interoperability. | |||
8.4. Message Integrity | ||||
HTTP does not define a specific mechanism for ensuring message | ||||
integrity, instead relying on the error-detection ability of | ||||
underlying transport protocols and the use of length or chunk- | ||||
delimited framing to detect completeness. Additional integrity | ||||
mechanisms, such as hash functions or digital signatures applied to | ||||
the content, can be selectively added to messages via extensible | ||||
metadata header fields. Historically, the lack of a single integrity | ||||
mechanism has been justified by the informal nature of most HTTP | ||||
communication. However, the prevalence of HTTP as an information | ||||
access mechanism has resulted in its increasing use within | ||||
environments where verification of message integrity is crucial. | ||||
User agents are encouraged to implement configurable means for | ||||
detecting and reporting failures of message integrity such that those | ||||
means can be enabled within environments for which integrity is | ||||
necessary. For example, a browser being used to view medical history | ||||
or drug interaction information needs to indicate to the user when | ||||
such information is detected by the protocol to be incomplete, | ||||
expired, or corrupted during transfer. Such mechanisms might be | ||||
selectively enabled via user agent extensions or the presence of | ||||
message integrity metadata in a response. At a minimum, user agents | ||||
ought to provide some indication that allows a user to distinguish | ||||
between a complete and incomplete response message (Section 3.4) when | ||||
such verification is desired. | ||||
8.5. Server Log Information | ||||
A server is in the position to save personal data about a user's | ||||
requests over time, which might identify their reading patterns or | ||||
subjects of interest. In particular, log information gathered at an | ||||
intermediary often contains a history of user agent interaction, | ||||
across a multitude of sites, that can be traced to individual users. | ||||
HTTP log information is confidential in nature; its handling is often | ||||
constrained by laws and regulations. Log information needs to be | ||||
securely stored and appropriate guidelines followed for its analysis. | ||||
Anonymization of personal information within individual entries | ||||
helps, but is generally not sufficient to prevent real log traces | ||||
from being re-identified based on correlation with other access | ||||
characteristics. As such, access traces that are keyed to a specific | ||||
client should not be published even if the key is pseudonymous. | ||||
To minimize the risk of theft or accidental publication, log | ||||
information should be purged of personally identifiable information, | ||||
including user identifiers, IP addresses, and user-provided query | ||||
parameters, as soon as that information is no longer necessary to | ||||
support operational needs for security, auditing, or fraud control. | ||||
9. Acknowledgments | 9. Acknowledgments | |||
This edition of HTTP builds on the many contributions that went into | This edition of HTTP/1.1 builds on the many contributions that went | |||
RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including substantial | into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including | |||
contributions made by the previous authors, editors, and working | substantial contributions made by the previous authors, editors, and | |||
group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Henrik | working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, | |||
Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul | Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, | |||
J. Leach, and Mark Nottingham. See Section 16 of [RFC2616] for | and Paul J. Leach. Mark Nottingham oversaw this effort as working | |||
additional acknowledgements from prior revisions. | group chair. | |||
Since 1999, the following contributors have helped improve the HTTP | Since 1999, the following contributors have helped improve the HTTP | |||
specification by reporting bugs, asking smart questions, drafting or | specification by reporting bugs, asking smart questions, drafting or | |||
reviewing text, and evaluating open issues: | reviewing text, and evaluating open issues: | |||
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de | Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de | |||
Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex | Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex | |||
Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai | Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai | |||
Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, | Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, | |||
Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, | Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok | |||
Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven- | Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin | |||
Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, | Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob | |||
Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, | Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, | |||
Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, | Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl | |||
Carsten Bormann, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert | Kugler, Carsten Bormann, Charles Fry, Chris Newman, Chris Weber, | |||
Anderson, Dan Wing, Dan Winship, Daniel Stenberg, Dave Cridland, Dave | Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel | |||
Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, | Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, | |||
Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, | David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry | |||
Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. | Kurochkin, Drummond Reed, Duane Wessels, Duncan Cragg, Edward Lee, | |||
Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, | Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric | |||
Florian Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, | Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, Florian | |||
Geoffrey Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, | Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, Geoffrey | |||
Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, | Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Harald Tveit | |||
Henry S. Thompson, Henry Story, Herbert van de Sompel, Howard Melman, | Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. | |||
Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ingo Struck, J. Ross | Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo | |||
Nicoll, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, | Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo | |||
Jan Algermissen, Jeff Hodges (who came up with the term 'effective | Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, | |||
Request-URI'), Jeff Walden, Jim Luther, Joe D. Williams, Joe | Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term | |||
Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan, | 'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, | |||
John Kemp, John Panzer, John Schneider, John Stracke, John Sullivan, | Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. | |||
Jonas Sicking, Jonathan Billington, Jonathan Moore, Jonathan Rees, | Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John | |||
Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien | Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan | |||
Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin | Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi | |||
James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen | Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, | |||
Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej | Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, | |||
Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, | Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, | |||
Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, | Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, | |||
Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew | Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, | |||
Cox, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen, | Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, | |||
Mike Belshe, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. | Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, | |||
Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico | Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike | |||
Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Pablo | Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta | |||
Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman, | Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas | |||
Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, | ||||
Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, | ||||
Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil | Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil | |||
Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, | Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, | |||
Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, | Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, | |||
Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, | Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, | |||
Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, | Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, | |||
Roberto Javier Godoy, Roberto Peon, Ronny Widjaja, S. Mike Dierken, | Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. | |||
Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (who | Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott | |||
maintained the original issues list), Sean B. Palmer, Shane McCarron, | Lawrence (who maintained the original issues list), Sean B. Palmer, | |||
Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane | Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, | |||
Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu | Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, | |||
Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted | Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan | |||
Hardie, Thomas Broyer, Thomas Nordin, Thomas Roessler, Tim Bray, Tim | Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, | |||
Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent | Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, | |||
Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent | ||||
Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez | Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez | |||
Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, | Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, | |||
Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka | Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka | |||
Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, | Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, | |||
and Zhong Yu. | and Zhong Yu. | |||
See Section 16 of [RFC2616] for additional acknowledgements from | ||||
prior revisions. | ||||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Semantics and Content", | Transfer Protocol (HTTP/1.1): Semantics and Content", | |||
draft-ietf-httpbis-p2-semantics-21 (work in progress), | draft-ietf-httpbis-p2-semantics-22 (work in progress), | |||
October 2012. | February 2013. | |||
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Conditional Requests", | Transfer Protocol (HTTP/1.1): Conditional Requests", | |||
draft-ietf-httpbis-p4-conditional-21 (work in | draft-ietf-httpbis-p4-conditional-22 (work in | |||
progress), October 2012. | progress), February 2013. | |||
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
"Hypertext Transfer Protocol (HTTP/1.1): Range | "Hypertext Transfer Protocol (HTTP/1.1): Range | |||
Requests", draft-ietf-httpbis-p5-range-21 (work in | Requests", draft-ietf-httpbis-p5-range-22 (work in | |||
progress), October 2012. | progress), February 2013. | |||
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | |||
draft-ietf-httpbis-p6-cache-21 (work in progress), | draft-ietf-httpbis-p6-cache-22 (work in progress), | |||
October 2012. | February 2013. | |||
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext | |||
Transfer Protocol (HTTP/1.1): Authentication", | Transfer Protocol (HTTP/1.1): Authentication", | |||
draft-ietf-httpbis-p7-auth-21 (work in progress), | draft-ietf-httpbis-p7-auth-22 (work in progress), | |||
October 2012. | February 2013. | |||
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data | [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data | |||
Format Specification version 3.3", RFC 1950, May 1996. | Format Specification version 3.3", RFC 1950, May 1996. | |||
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format | |||
Specification version 1.3", RFC 1951, May 1996. | Specification version 1.3", RFC 1951, May 1996. | |||
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and | [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and | |||
G. Randers-Pehrson, "GZIP file format specification | G. Randers-Pehrson, "GZIP file format specification | |||
version 4.3", RFC 1952, May 1996. | version 4.3", RFC 1952, May 1996. | |||
skipping to change at page 65, line 22 | skipping to change at page 66, line 26 | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for | |||
Syntax Specifications: ABNF", STD 68, RFC 5234, | Syntax Specifications: ABNF", STD 68, RFC 5234, | |||
January 2008. | January 2008. | |||
[USASCII] American National Standards Institute, "Coded Character | [USASCII] American National Standards Institute, "Coded Character | |||
Set -- 7-bit American Standard Code for Information | Set -- 7-bit American Standard Code for Information | |||
Interchange", ANSI X3.4, 1986. | Interchange", ANSI X3.4, 1986. | |||
10.2. Informative References | 10.2. Informative References | |||
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines | ||||
and Registration Procedures for New URI Schemes", | ||||
BCP 115, RFC 4395, February 2006. | ||||
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type | ||||
Specifications and Registration Procedures", BCP 13, | ||||
RFC 6838, January 2013. | ||||
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration | ||||
Procedures for Message Header Fields", BCP 90, | ||||
RFC 3864, September 2004. | ||||
[ISO-8859-1] International Organization for Standardization, | [ISO-8859-1] International Organization for Standardization, | |||
"Information technology -- 8-bit single-byte coded | "Information technology -- 8-bit single-byte coded | |||
graphic character sets -- Part 1: Latin alphabet No. | graphic character sets -- Part 1: Latin alphabet No. | |||
1", ISO/IEC 8859-1:1998, 1998. | 1", ISO/IEC 8859-1:1998, 1998. | |||
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and | [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and | |||
Politics", ACM Transactions on Internet Technology Vol. | Politics", ACM Transactions on Internet Technology Vol. | |||
1, #2, November 2001, | 1, #2, November 2001, | |||
<http://arxiv.org/abs/cs.SE/0105018>. | <http://arxiv.org/abs/cs.SE/0105018>. | |||
skipping to change at page 66, line 15 | skipping to change at page 67, line 31 | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within | [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within | |||
HTTP/1.1", RFC 2817, May 2000. | HTTP/1.1", RFC 2817, May 2000. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | |||
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management | ||||
Mechanism", RFC 2965, October 2000. | ||||
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web | [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web | |||
Replication and Caching Taxonomy", RFC 3040, | Replication and Caching Taxonomy", RFC 3040, | |||
January 2001. | January 2001. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | ||||
Procedures for Message Header Fields", BCP 90, | ||||
RFC 3864, September 2004. | ||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications | ||||
and Registration Procedures", BCP 13, RFC 4288, | ||||
December 2005. | ||||
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines | ||||
and Registration Procedures for New URI Schemes", | ||||
BCP 115, RFC 4395, February 2006. | ||||
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based | [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based | |||
Kerberos and NTLM HTTP Authentication in Microsoft | Kerberos and NTLM HTTP Authentication in Microsoft | |||
Windows", RFC 4559, June 2006. | Windows", RFC 4559, June 2006. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing | |||
an IANA Considerations Section in RFCs", BCP 26, | an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 5226, May 2008. | RFC 5226, May 2008. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer | |||
Security (TLS) Protocol Version 1.2", RFC 5246, | Security (TLS) Protocol Version 1.2", RFC 5246, | |||
skipping to change at page 68, line 35 | skipping to change at page 69, line 40 | |||
In HTTP/1.0, each connection is established by the client prior to | In HTTP/1.0, each connection is established by the client prior to | |||
the request and closed by the server after sending the response. | the request and closed by the server after sending the response. | |||
However, some implementations implement the explicitly negotiated | However, some implementations implement the explicitly negotiated | |||
("Keep-Alive") version of persistent connections described in Section | ("Keep-Alive") version of persistent connections described in Section | |||
19.7.1 of [RFC2068]. | 19.7.1 of [RFC2068]. | |||
Some clients and servers might wish to be compatible with these | Some clients and servers might wish to be compatible with these | |||
previous approaches to persistent connections, by explicitly | previous approaches to persistent connections, by explicitly | |||
negotiating for them with a "Connection: keep-alive" request header | negotiating for them with a "Connection: keep-alive" request header | |||
field. However, some experimental implementations of HTTP/1.0 | field. However, some experimental implementations of HTTP/1.0 | |||
persistent connections are faulty; for example, if a HTTP/1.0 proxy | persistent connections are faulty; for example, if an HTTP/1.0 proxy | |||
server doesn't understand Connection, it will erroneously forward | server doesn't understand Connection, it will erroneously forward | |||
that header field to the next inbound server, which would result in a | that header field to the next inbound server, which would result in a | |||
hung connection. | hung connection. | |||
One attempted solution was the introduction of a Proxy-Connection | One attempted solution was the introduction of a Proxy-Connection | |||
header field, targeted specifically at proxies. In practice, this | header field, targeted specifically at proxies. In practice, this | |||
was also unworkable, because proxies are often deployed in multiple | was also unworkable, because proxies are often deployed in multiple | |||
layers, bringing about the same problem discussed above. | layers, bringing about the same problem discussed above. | |||
As a result, clients are encouraged not to send the Proxy-Connection | As a result, clients are encouraged not to send the Proxy-Connection | |||
skipping to change at page 69, line 9 | skipping to change at page 70, line 15 | |||
Clients are also encouraged to consider the use of Connection: keep- | Clients are also encouraged to consider the use of Connection: keep- | |||
alive in requests carefully; while they can enable persistent | alive in requests carefully; while they can enable persistent | |||
connections with HTTP/1.0 servers, clients using them need will need | connections with HTTP/1.0 servers, clients using them need will need | |||
to monitor the connection for "hung" requests (which indicate that | to monitor the connection for "hung" requests (which indicate that | |||
the client ought stop sending the header field), and this mechanism | the client ought stop sending the header field), and this mechanism | |||
ought not be used by clients at all when a proxy is being used. | ought not be used by clients at all when a proxy is being used. | |||
A.1.3. Introduction of Transfer-Encoding | A.1.3. Introduction of Transfer-Encoding | |||
HTTP/1.1 introduces the Transfer-Encoding header field | HTTP/1.1 introduces the Transfer-Encoding header field | |||
(Section 3.3.1). Proxies/gateways MUST remove any transfer-coding | (Section 3.3.1). Transfer codings need to be decoded prior to | |||
prior to forwarding a message via a MIME-compliant protocol. | forwarding an HTTP message over a MIME-compliant protocol. | |||
A.2. Changes from RFC 2616 | A.2. Changes from RFC 2616 | |||
Clarify that the string "HTTP" in the HTTP-version ABNF production is | HTTP's approach to error handling has been explained. (Section 2.5) | |||
case sensitive. Restrict the version numbers to be single digits due | ||||
to the fact that implementations are known to handle multi-digit | ||||
version numbers incorrectly. (Section 2.6) | ||||
Require that invalid whitespace around field-names be rejected. | The expectation to support HTTP/0.9 requests has been removed. | |||
Change ABNF productions for header fields to only define the field | ||||
The term "Effective Request URI" has been introduced. (Section 5.5) | ||||
HTTP messages can be (and often are) buffered by implementations; | ||||
despite it sometimes being available as a stream, HTTP is | ||||
fundamentally a message-oriented protocol. (Section 3) | ||||
Minimum supported sizes for various protocol elements have been | ||||
suggested, to improve interoperability. | ||||
Header fields that span multiple lines ("line folding") are | ||||
deprecated. (Section 3.2.4) | ||||
The HTTP-version ABNF production has been clarified to be case- | ||||
sensitive. Additionally, version numbers has been restricted to | ||||
single digits, due to the fact that implementations are known to | ||||
handle multi-digit version numbers incorrectly. (Section 2.6) | ||||
The HTTPS URI scheme is now defined by this specification; | ||||
previously, it was done in Section 2.4 of [RFC2818]. (Section 2.7.2) | ||||
The HTTPS URI scheme implies end-to-end security. (Section 2.7.2) | ||||
Userinfo (i.e., username and password) are now disallowed in HTTP and | ||||
HTTPS URIs, because of security issues related to their transmission | ||||
on the wire. (Section 2.7.1) | ||||
Invalid whitespace around field-names is now required to be rejected, | ||||
because accepting it represents a security vulnerability. | ||||
(Section 3.2) | ||||
The ABNF productions defining header fields now only list the field | ||||
value. (Section 3.2) | value. (Section 3.2) | |||
Rules about implicit linear whitespace between certain grammar | Rules about implicit linear whitespace between certain grammar | |||
productions have been removed; now whitespace is only allowed where | productions have been removed; now whitespace is only allowed where | |||
specifically defined in the ABNF. (Section 3.2.1) | specifically defined in the ABNF. (Section 3.2.3) | |||
The NUL octet is no longer allowed in comment and quoted-string text, | ||||
and handling of backslash-escaping in them has been clarified. | ||||
(Section 3.2.6) | ||||
The NUL octet is no longer allowed in comment and quoted-string text. | ||||
The quoted-pair rule no longer allows escaping control characters | The quoted-pair rule no longer allows escaping control characters | |||
other than HTAB. Non-ASCII content in header fields and reason | other than HTAB. (Section 3.2.6) | |||
phrase has been obsoleted and made opaque (the TEXT rule was | ||||
removed). (Section 3.2.4) | ||||
Require recipients to handle bogus "Content-Length" header fields as | Non-ASCII content in header fields and the reason phrase has been | |||
errors. (Section 3.3) | obsoleted and made opaque (the TEXT rule was removed). | |||
(Section 3.2.6) | ||||
Remove reference to non-existent identity transfer-coding value | Bogus "Content-Length" header fields are now required to be handled | |||
tokens. (Sections 3.3 and 4) | as errors by recipients. (Section 3.3.2) | |||
Clarification that the chunk length does not include the count of the | The "identity" transfer coding token has been removed. (Sections 3.3 | |||
octets in the chunk header and trailer. Furthermore disallowed line | and 4) | |||
folding in chunk extensions, and deprecate their use. (Section 4.1) | ||||
Update use of abs_path production from RFC 1808 to the path-absolute | The algorithm for determining the message body length has been | |||
+ query components of RFC 3986. State that the asterisk form is | clarified to indicate all of the special cases (e.g., driven by | |||
allowed for the OPTIONS request method only. (Section 5.3) | methods or status codes) that affect it, and that new protocol | |||
elements cannot define such special cases. (Section 3.3.3) | ||||
Clarify exactly when "close" connection options have to be sent; drop | "multipart/byteranges" is no longer a way of determining message body | |||
notion of header fields being "hop-by-hop" without being listed in | length detection. (Section 3.3.3) | |||
the Connection header field. (Section 6.1) | ||||
Remove hard limit of two connections per server. Remove requirement | CONNECT is a new, special case in determining message body length. | |||
to retry a sequence of requests as long it was idempotent. Remove | (Section 3.3.3) | |||
requirements about when servers are allowed to close connections | ||||
prematurely. (Section 6.2) | ||||
Remove requirement to retry requests under certain circumstances when | Chunk length does not include the count of the octets in the chunk | |||
the server prematurely closes the connection. (Section 6.2.2) | header and trailer. (Section 4.1) | |||
Define the semantics of the Upgrade header field in responses other | Use of chunk extensions is deprecated, and line folding in them is | |||
than 101 (this was incorporated from [RFC2817]). (Section 6.3) | disallowed. (Section 4.1) | |||
The segment + query components of RFC3986 have been used to define | ||||
the request-target, instead of abs_path from RFC 1808. (Section 5.3) | ||||
The asterisk form of the request-target is only allowed in the | ||||
OPTIONS method. (Section 5.3) | ||||
Exactly when "close" connection options have to be sent has been | ||||
clarified. (Section 6.1) | ||||
"hop-by-hop" header fields are required to appear in the Connection | ||||
header field; just because they're defined as hop-by-hop in this | ||||
specification doesn't exempt them. (Section 6.1) | ||||
The limit of two connections per server has been removed. | ||||
(Section 6.3) | ||||
An idempotent sequence of requests is no longer required to be | ||||
retried. (Section 6.3) | ||||
The requirement to retry requests under certain circumstances when | ||||
the server prematurely closes the connection has been removed. | ||||
(Section 6.3) | ||||
Some extraneous requirements about when servers are allowed to close | ||||
connections prematurely have been removed. (Section 6.3) | ||||
The semantics of the Upgrade header field is now defined in responses | ||||
other than 101 (this was incorporated from [RFC2817]). (Section 6.7) | ||||
Registration of Transfer Codings now requires IETF Review | Registration of Transfer Codings now requires IETF Review | |||
(Section 7.4) | (Section 7.4) | |||
Take over the Upgrade Token Registry, previously defined in Section | The meaning of the "deflate" content coding has been clarified. | |||
7.2 of [RFC2817]. (Section 7.6) | (Section 4.2.2) | |||
Empty list elements in list productions have been deprecated. | This specification now defines the Upgrade Token Registry, previously | |||
(Appendix B) | defined in Section 7.2 of [RFC2817]. (Section 7.6) | |||
Empty list elements in list productions (e.g., a list header | ||||
containing ", ,") have been deprecated. (Appendix B) | ||||
Issues with the Keep-Alive and Proxy-Connection headers in requests | ||||
are pointed out, with use of the latter being discouraged altogether. | ||||
(Appendix A.1.2) | ||||
Appendix B. ABNF list extension: #rule | Appendix B. ABNF list extension: #rule | |||
A #rule extension to the ABNF rules of [RFC5234] is used to improve | A #rule extension to the ABNF rules of [RFC5234] is used to improve | |||
readability in the definitions of some header field values. | readability in the definitions of some header field values. | |||
A construct "#" is defined, similar to "*", for defining comma- | A construct "#" is defined, similar to "*", for defining comma- | |||
delimited lists of elements. The full form is "<n>#<m>element" | delimited lists of elements. The full form is "<n>#<m>element" | |||
indicating at least <n> and at most <m> elements, each separated by a | indicating at least <n> and at most <m> elements, each separated by a | |||
single comma (",") and optional whitespace (OWS). | single comma (",") and optional whitespace (OWS). | |||
skipping to change at page 71, line 11 | skipping to change at page 73, line 31 | |||
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] | |||
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) | |||
Note that empty elements do not contribute to the count of elements | Note that empty elements do not contribute to the count of elements | |||
present, though. | present, though. | |||
For example, given these ABNF productions: | For example, given these ABNF productions: | |||
example-list = 1#example-list-elmt | example-list = 1#example-list-elmt | |||
example-list-elmt = token ; see Section 3.2.4 | example-list-elmt = token ; see Section 3.2.6 | |||
Then these are valid values for example-list (not including the | Then these are valid values for example-list (not including the | |||
double quotes, which are present for delimitation only): | double quotes, which are present for delimitation only): | |||
"foo,bar" | "foo,bar" | |||
"foo ,bar," | "foo ,bar," | |||
"foo , ,bar,charlie " | "foo , ,bar,charlie " | |||
But these values would be invalid, as at least one non-empty element | But these values would be invalid, as at least one non-empty element | |||
is required: | is required: | |||
skipping to change at page 72, line 14 | skipping to change at page 74, line 32 | |||
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> | |||
Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) | Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) | |||
Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment | Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment | |||
] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS | ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS | |||
comment ] ) ] ) | comment ] ) ] ) | |||
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> | |||
absolute-form = absolute-URI | absolute-form = absolute-URI | |||
absolute-path = 1*( "/" segment ) | ||||
asterisk-form = "*" | asterisk-form = "*" | |||
attribute = token | attribute = token | |||
authority = <authority, defined in [RFC3986], Section 3.2> | authority = <authority, defined in [RFC3986], Section 3.2> | |||
authority-form = authority | authority-form = authority | |||
chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF | chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF | |||
chunk-data = 1*OCTET | chunk-data = 1*OCTET | |||
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) | |||
chunk-ext-name = token | chunk-ext-name = token | |||
chunk-ext-val = token / quoted-str-nf | chunk-ext-val = token / quoted-str-nf | |||
chunk-size = 1*HEXDIG | chunk-size = 1*HEXDIG | |||
chunked-body = *chunk last-chunk trailer-part CRLF | chunked-body = *chunk last-chunk trailer-part CRLF | |||
comment = "(" *( ctext / quoted-cpair / comment ) ")" | comment = "(" *( ctext / quoted-cpair / comment ) ")" | |||
connection-option = token | connection-option = token | |||
ctext = OWS / %x21-27 ; '!'-''' | ctext = HTAB / SP / %x21-27 ; '!'-''' | |||
/ %x2A-5B ; '*'-'[' | / %x2A-5B ; '*'-'[' | |||
/ %x5D-7E ; ']'-'~' | / %x5D-7E ; ']'-'~' | |||
/ obs-text | / obs-text | |||
field-content = *( HTAB / SP / VCHAR / obs-text ) | field-content = *( HTAB / SP / VCHAR / obs-text ) | |||
field-name = token | field-name = token | |||
field-value = *( field-content / obs-fold ) | field-value = *( field-content / obs-fold ) | |||
header-field = field-name ":" OWS field-value BWS | header-field = field-name ":" OWS field-value BWS | |||
http-URI = "http://" authority path-abempty [ "?" query ] | http-URI = "http://" authority path-abempty [ "?" query ] | |||
https-URI = "https://" authority path-abempty [ "?" query ] | https-URI = "https://" authority path-abempty [ "?" query ] | |||
last-chunk = 1*"0" [ chunk-ext ] CRLF | last-chunk = 1*"0" [ chunk-ext ] CRLF | |||
message-body = *OCTET | message-body = *OCTET | |||
method = token | method = token | |||
obs-fold = CRLF ( SP / HTAB ) | obs-fold = CRLF ( SP / HTAB ) | |||
obs-text = %x80-FF | obs-text = %x80-FF | |||
origin-form = path-absolute [ "?" query ] | origin-form = absolute-path [ "?" query ] | |||
partial-URI = relative-part [ "?" query ] | partial-URI = relative-part [ "?" query ] | |||
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> | |||
path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> | ||||
port = <port, defined in [RFC3986], Section 3.2.3> | port = <port, defined in [RFC3986], Section 3.2.3> | |||
protocol = protocol-name [ "/" protocol-version ] | protocol = protocol-name [ "/" protocol-version ] | |||
protocol-name = token | protocol-name = token | |||
protocol-version = token | protocol-version = token | |||
pseudonym = token | pseudonym = token | |||
qdtext = OWS / "!" / %x23-5B ; '#'-'[' | qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' | |||
/ %x5D-7E ; ']'-'~' | / %x5D-7E ; ']'-'~' | |||
/ obs-text | / obs-text | |||
qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' | qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' | |||
/ %x5D-7E ; ']'-'~' | / %x5D-7E ; ']'-'~' | |||
/ obs-text | / obs-text | |||
query = <query, defined in [RFC3986], Section 3.4> | query = <query, defined in [RFC3986], Section 3.4> | |||
quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) | quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) | |||
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) | quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) | |||
quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE | |||
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE | |||
rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) | rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) | |||
reason-phrase = *( HTAB / SP / VCHAR / obs-text ) | reason-phrase = *( HTAB / SP / VCHAR / obs-text ) | |||
received-by = ( uri-host [ ":" port ] ) / pseudonym | received-by = ( uri-host [ ":" port ] ) / pseudonym | |||
received-protocol = [ protocol-name "/" ] protocol-version | received-protocol = [ protocol-name "/" ] protocol-version | |||
relative-part = <relative-part, defined in [RFC3986], Section 4.2> | relative-part = <relative-part, defined in [RFC3986], Section 4.2> | |||
request-line = method SP request-target SP HTTP-version CRLF | request-line = method SP request-target SP HTTP-version CRLF | |||
request-target = origin-form / absolute-form / authority-form / | request-target = origin-form / absolute-form / authority-form / | |||
asterisk-form | asterisk-form | |||
segment = <segment, defined in [RFC3986], Section 3.3> | ||||
special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / | special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / | |||
DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" | DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" | |||
start-line = request-line / status-line | start-line = request-line / status-line | |||
status-code = 3DIGIT | status-code = 3DIGIT | |||
status-line = HTTP-version SP status-code SP reason-phrase CRLF | status-line = HTTP-version SP status-code SP reason-phrase CRLF | |||
t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) | t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) | |||
t-ranking = OWS ";" OWS "q=" rank | t-ranking = OWS ";" OWS "q=" rank | |||
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / | |||
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA | |||
skipping to change at page 74, line 4 | skipping to change at page 76, line 24 | |||
token = 1*tchar | token = 1*tchar | |||
trailer-part = *( header-field CRLF ) | trailer-part = *( header-field CRLF ) | |||
transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / | transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / | |||
transfer-extension | transfer-extension | |||
transfer-extension = token *( OWS ";" OWS transfer-parameter ) | transfer-extension = token *( OWS ";" OWS transfer-parameter ) | |||
transfer-parameter = attribute BWS "=" BWS value | transfer-parameter = attribute BWS "=" BWS value | |||
uri-host = <host, defined in [RFC3986], Section 3.2.2> | uri-host = <host, defined in [RFC3986], Section 3.2.2> | |||
value = word | value = word | |||
word = token / quoted-string | word = token / quoted-string | |||
Appendix D. Change Log (to be removed by RFC Editor before publication) | Appendix D. Change Log (to be removed by RFC Editor before publication) | |||
D.1. Since RFC 2616 | D.1. Since RFC 2616 | |||
Extracted relevant partitions from [RFC2616]. | Changes up to the first Working Group Last Call draft are summarized | |||
in <http://trac.tools.ietf.org/html/ | ||||
D.2. Since draft-ietf-httpbis-p1-messaging-00 | draft-ietf-httpbis-p1-messaging-21#appendix-D>. | |||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/1>: "HTTP Version | ||||
should be case sensitive" | ||||
(<http://purl.org/NET/http-errata#verscase>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/2>: "'unsafe' | ||||
characters" (<http://purl.org/NET/http-errata#unsafe-uri>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/3>: "Chunk Size | ||||
Definition" (<http://purl.org/NET/http-errata#chunk-size>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/4>: "Message Length" | ||||
(<http://purl.org/NET/http-errata#msg-len-chars>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type | ||||
Registrations" (<http://purl.org/NET/http-errata#media-reg>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/11>: "URI includes | ||||
query" (<http://purl.org/NET/http-errata#uriquery>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/15>: "No close on | ||||
1xx responses" (<http://purl.org/NET/http-errata#noclose1xx>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove | ||||
'identity' token references" | ||||
(<http://purl.org/NET/http-errata#identity>) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/26>: "Import query | ||||
BNF" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/31>: "qdtext BNF" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and | ||||
Informative references" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606 | ||||
Compliance" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/45>: "RFC977 | ||||
reference" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700 | ||||
references" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/47>: "inconsistency | ||||
in date format explanation" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference | ||||
typo" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative | ||||
references" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 | ||||
Reference" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- | ||||
to-date references" | ||||
Other changes: | ||||
o Update media type registrations to use RFC4288 template. | ||||
o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF | ||||
for chunk-data (work in progress on | ||||
<http://tools.ietf.org/wg/httpbis/trac/ticket/36>) | ||||
D.3. Since draft-ietf-httpbis-p1-messaging-01 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/19>: "Bodies on GET | ||||
(and other) requests" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to | ||||
RFC4288" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/57>: "Status Code | ||||
and Reason Phrase" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not | ||||
used" | ||||
Ongoing work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Get rid of duplicate BNF rule names ("host" -> "uri-host", | ||||
"trailer" -> "trailer-part"). | ||||
o Avoid underscore character in rule names ("http_URL" -> "http- | ||||
URL", "abs_path" -> "path-absolute"). | ||||
o Add rules for terms imported from URI spec ("absoluteURI", | ||||
"authority", "path-absolute", "port", "query", "relativeURI", | ||||
"host) -- these will have to be updated when switching over to | ||||
RFC3986. | ||||
o Synchronize core rules with RFC5234. | ||||
o Get rid of prose rules that span multiple lines. | ||||
o Get rid of unused rules LOALPHA and UPALPHA. | ||||
o Move "Product Tokens" section (back) into Part 1, as "token" is | ||||
used in the definition of the Upgrade header field. | ||||
o Add explicit references to BNF syntax and rules imported from | ||||
other parts of the specification. | ||||
o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule | ||||
"TEXT". | ||||
D.4. Since draft-ietf-httpbis-p1-messaging-02 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date vs. | ||||
rfc1123-date" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in quoted- | ||||
pair" | ||||
Ongoing work on IANA Message Header Field Registration | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): | ||||
o Reference RFC 3984, and update header field registrations for | ||||
header fields defined in this document. | ||||
Ongoing work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Replace string literals when the string really is case-sensitive | ||||
(HTTP-version). | ||||
D.5. Since draft-ietf-httpbis-p1-messaging-03 | D.2. Since draft-ietf-httpbis-p1-messaging-21 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection | ||||
closing" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/97>: "Move | ||||
registrations and registry information to IANA Considerations" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/120>: "need new URL | ||||
for PAD1995 reference" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/127>: "IANA | ||||
Considerations: update HTTP URI scheme registration" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS | o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS | |||
URI scheme definition" | URI scheme definition" (the spec now includes the HTTPs scheme | |||
definition and thus updates RFC 2818) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/129>: "List-type | ||||
header fields vs Set-Cookie" | ||||
Ongoing work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Replace string literals when the string really is case-sensitive | ||||
(HTTP-Date). | ||||
o Replace HEX by HEXDIG for future consistence with RFC 5234's core | ||||
rules. | ||||
D.6. Since draft-ietf-httpbis-p1-messaging-04 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/34>: "Out-of-date | ||||
reference for URIs" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is | ||||
updated by RFC 5322" | ||||
Ongoing work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Use "/" instead of "|" for alternatives. | ||||
o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. | ||||
o Only reference RFC 5234's core rules. | ||||
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional | ||||
whitespace ("OWS") and required whitespace ("RWS"). | ||||
o Rewrite ABNFs to spell out whitespace rules, factor out header | ||||
field value format definitions. | ||||
D.7. Since draft-ietf-httpbis-p1-messaging-05 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/30>: "Header LWS" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/52>: "Sort 1.3 | ||||
Terminology" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/63>: "RFC2047 | ||||
encoded words" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/74>: "Character | ||||
Encodings in TEXT" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/77>: "Line Folding" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and | ||||
proxies" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase | ||||
BNF" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/111>: "Use of TEXT" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join | ||||
"Differences Between HTTP Entities and RFC 2045 Entities"?" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/134>: "RFC822 | ||||
reference left in discussion of date formats" | ||||
Final work on ABNF conversion | ||||
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): | ||||
o Rewrite definition of list rules, deprecate empty list elements. | ||||
o Add appendix containing collected and expanded ABNF. | ||||
Other changes: | ||||
o Rewrite introduction; add mostly new Architecture Section. | ||||
o Move definition of quality values from Part 3 into Part 1; make TE | ||||
request header field grammar independent of accept-params (defined | ||||
in Part 3). | ||||
D.8. Since draft-ietf-httpbis-p1-messaging-06 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for | ||||
numeric protocol elements" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/162>: "comment ABNF" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies" | ||||
(took out language that implied that there might be methods for | ||||
which a payload body MUST NOT be included) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/163>: "editorial | ||||
improvements around HTTP-date" | ||||
D.9. Since draft-ietf-httpbis-p1-messaging-07 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/93>: "Repeating | ||||
single-value header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/131>: "increase | ||||
connection limit" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/157>: "IP addresses | ||||
in URLs" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/172>: "take over | ||||
HTTP Upgrade Token Registry" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/173>: "CR and LF in | ||||
chunk extension values" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/184>: "HTTP/0.9 | ||||
support" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA | ||||
policy (RFC5226) for Transfer Coding / Content Coding" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move | ||||
definitions of gzip/deflate/compress to part 1" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow | ||||
control characters in quoted-pair" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA | ||||
requirements wrt Transfer-Coding values" (add the IANA | ||||
Considerations subsection) | ||||
D.10. Since draft-ietf-httpbis-p1-messaging-08 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header | ||||
parsing, treatment of leading and trailing OWS" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of | ||||
13.5.1 and 13.5.2" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term | ||||
"word" when talking about header field structure" | ||||
D.11. Since draft-ietf-httpbis-p1-messaging-09 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/73>: "Clarification | ||||
of the term 'deflate'" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/83>: "OPTIONS * and | ||||
proxies" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version | ||||
not listed in P1, general header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry | ||||
for content/transfer encodings" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/165>: "Case- | ||||
sensitivity of HTTP-date" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term | ||||
"word" when talking about header field structure" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the | ||||
requested resource's URI" | ||||
D.12. Since draft-ietf-httpbis-p1-messaging-10 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/28>: "Connection | ||||
Closing" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting | ||||
messages with multipart/byteranges" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling | ||||
multiple Content-Length header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify | ||||
entity / representation / variant terminology" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider | ||||
removing the 'changes from 2068' sections" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI | ||||
scheme definitions" | ||||
D.13. Since draft-ietf-httpbis-p1-messaging-11 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/193>: "Trailer | ||||
requirements" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about | ||||
clock requirement for caches belongs in p6" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/221>: "effective | ||||
request URI: handling of missing host in HTTP/1.0" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/248>: "confusing | ||||
Date requirements for clients" | ||||
Partly resolved issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling | ||||
multiple Content-Length header fields" | ||||
D.14. Since draft-ietf-httpbis-p1-messaging-12 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/75>: "RFC2145 | ||||
Normative" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/159>: "HTTP(s) URI | ||||
scheme definitions" (tune the requirements on userinfo) | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/210>: "define | ||||
'transparent' proxy" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field | ||||
Classification" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/233>: "Is * usable | ||||
as a request-uri for new methods?" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate | ||||
Upgrade details from RFC2817" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle | ||||
ABNFs for header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC | ||||
2109 reference" | ||||
D.15. Since draft-ietf-httpbis-p1-messaging-13 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not | ||||
in 13.5.2" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/95>: "Handling | ||||
multiple Content-Length header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle | ||||
ABNFs for header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content- | ||||
Length ABNF broken" | ||||
D.16. Since draft-ietf-httpbis-p1-messaging-14 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/273>: "HTTP-version | ||||
should be redefined as fixed length pair of DIGIT . DIGIT" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend | ||||
minimum sizes for protocol elements" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/283>: "Set | ||||
expectations around buffering" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/288>: "Considering | ||||
messages in isolation" | ||||
D.17. Since draft-ietf-httpbis-p1-messaging-15 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/100>: "DNS Spoofing | ||||
/ DNS Binding advice" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/254>: "move RFCs | ||||
2145, 2616, 2817 to Historic status" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/270>: "\-escaping in | ||||
quoted strings" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/305>: "'Close' | ||||
should be reserved in the HTTP header field registry" | ||||
D.18. Since draft-ietf-httpbis-p1-messaging-16 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document | ||||
HTTP's error-handling philosophy" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/215>: "Explain | ||||
header field registration" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/219>: "Revise | ||||
Acknowledgements Sections" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/297>: "Retrying | ||||
Requests" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/318>: "Closing the | ||||
connection on server error" | ||||
D.19. Since draft-ietf-httpbis-p1-messaging-17 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/158>: "Proxy- | ||||
Connection and Keep-Alive" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/166>: "Clarify 'User | ||||
Agent'" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/300>: "Define non- | ||||
final responses" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended | ||||
maturity level vs normative references" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/324>: "Intermediary | ||||
rewriting of queries" | ||||
D.20. Since draft-ietf-httpbis-p1-messaging-18 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body | ||||
in CONNECT response" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced | ||||
text on connection handling in p2" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/335>: "wording of | ||||
line folding rule" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of | |||
extensions" | 'proxies' in section about caches" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA | o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF | |||
policy definitions consistent" | terms from RFC 3986" | |||
D.21. Since draft-ietf-httpbis-p1-messaging-19 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial | |||
improvements to message length definition" | ||||
Closed issues: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection | |||
header field MUST vs SHOULD" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA | o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial | |||
policy definitions consistent" | improvements to persistent connections section" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/359>: "clarify | o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI | |||
connection header field values are case-insensitive" | normalization vs empty path" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF | o <http://tools.ietf.org/wg/httpbis/trac/ticket/408>: "p1 feedback" | |||
requirements for recipients" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note | o <http://tools.ietf.org/wg/httpbis/trac/ticket/409>: "is parsing | |||
introduction of new IANA registries as normative changes" | OBS-FOLD mandatory?" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/374>: "Reference to | o <http://tools.ietf.org/wg/httpbis/trac/ticket/410>: "HTTPS and | |||
ISO-8859-1 is informative" | Shared Caching" | |||
D.22. Since draft-ietf-httpbis-p1-messaging-20 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/411>: "Requirements | |||
for recipients of ws between start-line and first header field" | ||||
Closed issues: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/412>: "SP and HT | |||
when being tolerant" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/378>: "is 'q=' case- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/414>: "Message | |||
sensitive?" | Parsing Strictness" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/383>: "Semantics of | o <http://tools.ietf.org/wg/httpbis/trac/ticket/415>: "'Render'" | |||
HTTPS" | ||||
Other changes: | o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform" | |||
o Drop notion of header fields being "hop-by-hop" without being | o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial | |||
listed in the Connection header field. | feedback" | |||
o Section about connection management rewritten; dropping some | o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content- | |||
historic information. | Length SHOULD be sent" | |||
o Move description of "100-continue" into Part 2. | o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form | |||
does not allow path starting with "//"" | ||||
o Rewrite the persistent connection and Upgrade requirements to be | o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in | |||
actionable by role and consistent with the rest of HTTP. | part 1 example" | |||
Index | Index | |||
A | A | |||
absolute-form (of request-target) 39 | absolute-form (of request-target) 40 | |||
accelerator 10 | accelerator 10 | |||
application/http Media Type 57 | application/http Media Type 58 | |||
asterisk-form (of request-target) 39 | asterisk-form (of request-target) 41 | |||
authority-form (of request-target) 39 | authority-form (of request-target) 41 | |||
B | B | |||
browser 7 | browser 7 | |||
C | C | |||
cache 11 | cache 11 | |||
cacheable 12 | cacheable 12 | |||
captive portal 11 | captive portal 11 | |||
chunked (Coding Format) 33 | chunked (Coding Format) 27, 30, 34 | |||
client 7 | client 7 | |||
close 46, 52 | close 48, 53 | |||
compress (Coding Format) 35 | compress (Coding Format) 37 | |||
connection 7 | connection 7 | |||
Connection header field 46, 52 | Connection header field 48, 53 | |||
Content-Length header field 28 | Content-Length header field 28 | |||
D | D | |||
deflate (Coding Format) 35 | deflate (Coding Format) 37 | |||
downstream 9 | downstream 9 | |||
E | E | |||
effective request URI 41 | effective request URI 43 | |||
G | G | |||
gateway 10 | gateway 10 | |||
Grammar | Grammar | |||
absolute-form 38 | absolute-form 40 | |||
absolute-URI 15 | absolute-path 16 | |||
absolute-URI 16 | ||||
ALPHA 6 | ALPHA 6 | |||
asterisk-form 38 | asterisk-form 40 | |||
attribute 33 | attribute 34 | |||
authority 15 | authority 16 | |||
authority-form 38 | authority-form 40 | |||
BWS 23 | BWS 24 | |||
chunk 33 | chunk 35 | |||
chunk-data 33 | chunk-data 35 | |||
chunk-ext 33 | chunk-ext 35 | |||
chunk-ext-name 33 | chunk-ext-name 35 | |||
chunk-ext-val 33 | chunk-ext-val 35 | |||
chunk-size 33 | chunk-size 35 | |||
chunked-body 33 | chunked-body 35 | |||
comment 25 | comment 26 | |||
Connection 47 | Connection 48 | |||
connection-option 47 | connection-option 48 | |||
Content-Length 28 | Content-Length 29 | |||
CR 6 | CR 6 | |||
CRLF 6 | CRLF 6 | |||
ctext 25 | ctext 26 | |||
CTL 6 | CTL 6 | |||
date2 33 | date2 34 | |||
date3 33 | date3 34 | |||
DIGIT 6 | DIGIT 6 | |||
DQUOTE 6 | DQUOTE 6 | |||
field-content 21 | field-content 22 | |||
field-name 21 | field-name 22 | |||
field-value 21 | field-value 22 | |||
header-field 21 | header-field 22 | |||
HEXDIG 6 | HEXDIG 6 | |||
Host 40 | Host 42 | |||
HTAB 6 | HTAB 6 | |||
HTTP-message 18 | HTTP-message 19 | |||
HTTP-name 13 | HTTP-name 13 | |||
http-URI 16 | http-URI 16 | |||
HTTP-version 13 | HTTP-version 13 | |||
https-URI 17 | https-URI 18 | |||
last-chunk 33 | last-chunk 35 | |||
LF 6 | LF 6 | |||
message-body 26 | message-body 26 | |||
method 20 | method 20 | |||
obs-fold 21 | obs-fold 22 | |||
obs-text 25 | obs-text 26 | |||
OCTET 6 | OCTET 6 | |||
origin-form 38 | origin-form 40 | |||
OWS 23 | OWS 24 | |||
partial-URI 15 | partial-URI 16 | |||
path-absolute 15 | port 16 | |||
port 15 | protocol-name 45 | |||
protocol-name 43 | protocol-version 45 | |||
protocol-version 43 | pseudonym 45 | |||
pseudonym 43 | qdtext 26 | |||
qdtext 25 | qdtext-nf 35 | |||
qdtext-nf 33 | query 16 | |||
query 15 | quoted-cpair 26 | |||
quoted-cpair 25 | quoted-pair 26 | |||
quoted-pair 25 | quoted-str-nf 35 | |||
quoted-str-nf 33 | quoted-string 26 | |||
quoted-string 25 | rank 37 | |||
rank 36 | ||||
reason-phrase 21 | reason-phrase 21 | |||
received-by 43 | received-by 45 | |||
received-protocol 43 | received-protocol 45 | |||
request-line 20 | request-line 20 | |||
request-target 38 | request-target 40 | |||
RWS 23 | RWS 24 | |||
segment 16 | ||||
SP 6 | SP 6 | |||
special 25 | special 25 | |||
start-line 19 | start-line 20 | |||
status-code 21 | status-code 21 | |||
status-line 21 | status-line 21 | |||
t-codings 36 | t-codings 37 | |||
t-ranking 36 | t-ranking 37 | |||
tchar 25 | tchar 25 | |||
TE 36 | TE 37 | |||
token 25 | token 25 | |||
Trailer 34 | Trailer 35 | |||
trailer-part 33 | trailer-part 35 | |||
transfer-coding 33 | transfer-coding 34 | |||
Transfer-Encoding 26 | Transfer-Encoding 27 | |||
transfer-extension 33 | transfer-extension 34 | |||
transfer-parameter 33 | transfer-parameter 34 | |||
Upgrade 53 | Upgrade 54 | |||
uri-host 15 | uri-host 16 | |||
URI-reference 15 | URI-reference 16 | |||
value 33 | value 34 | |||
VCHAR 6 | VCHAR 6 | |||
Via 43 | Via 45 | |||
word 25 | word 25 | |||
gzip (Coding Format) 36 | gzip (Coding Format) 37 | |||
H | H | |||
header field 18 | header field 19 | |||
header section 18 | header section 19 | |||
headers 18 | headers 19 | |||
Host header field 40 | Host header field 41 | |||
http URI scheme 16 | http URI scheme 16 | |||
https URI scheme 17 | https URI scheme 17 | |||
I | I | |||
inbound 9 | inbound 9 | |||
interception proxy 11 | interception proxy 11 | |||
intermediary 9 | intermediary 9 | |||
M | M | |||
Media Type | Media Type | |||
application/http 57 | application/http 58 | |||
message/http 56 | message/http 57 | |||
message 7 | message 7 | |||
message/http Media Type 56 | message/http Media Type 57 | |||
method 20 | method 20 | |||
N | N | |||
non-transforming proxy 10 | non-transforming proxy 10 | |||
O | O | |||
origin server 7 | origin server 7 | |||
origin-form (of request-target) 38 | origin-form (of request-target) 40 | |||
outbound 9 | outbound 9 | |||
P | P | |||
proxy 10 | proxy 10 | |||
R | R | |||
recipient 7 | recipient 7 | |||
request 7 | request 7 | |||
request-target 20 | request-target 20 | |||
resource 15 | resource 15 | |||
response 7 | response 7 | |||
reverse proxy 10 | reverse proxy 10 | |||
S | S | |||
sender 7 | sender 7 | |||
server 7 | server 7 | |||
spider 7 | spider 7 | |||
T | T | |||
target resource 37 | target resource 38 | |||
target URI 37 | target URI 38 | |||
TE header field 36 | TE header field 37 | |||
Trailer header field 34 | Trailer header field 35 | |||
Transfer-Encoding header field 26 | Transfer-Encoding header field 27 | |||
transforming proxy 10 | transforming proxy 10 | |||
transparent proxy 11 | transparent proxy 11 | |||
tunnel 11 | tunnel 11 | |||
U | U | |||
Upgrade header field 53 | Upgrade header field 54 | |||
upstream 9 | upstream 9 | |||
URI scheme | URI scheme | |||
http 16 | http 16 | |||
https 17 | https 17 | |||
user agent 7 | user agent 7 | |||
V | V | |||
Via header field 43 | Via header field 45 | |||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
End of changes. 270 change blocks. | ||||
1397 lines changed or deleted | 972 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |