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/