draft-ietf-httpbis-p1-messaging-26.txt   draft-ietf-httpbis-p1-messaging-latest.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 J. Reschke, Ed.
Updates: 2817,2818 (if approved) greenbytes (if approved) greenbytes
Intended status: Standards Track February 6, 2014 Updates: 2817, 2818 (if approved) June 2014
Expires: August 10, 2014 Intended status: Standards Track
Expires: December 3, 2014
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-26 draft-ietf-httpbis-p1-messaging-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document provides an overview of HTTP architecture and systems. This document provides an overview of HTTP architecture and
its associated terminology, defines the "http" and "https" Uniform its associated terminology, defines the "http" and "https" Uniform
Resource Identifier (URI) schemes, defines the HTTP/1.1 message Resource Identifier (URI) schemes, defines the HTTP/1.1 message
syntax and parsing requirements, and describes related security syntax and parsing requirements, and describes related security
concerns for implementations. concerns for implementations.
skipping to change at page 1, line 34 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 C.3. _This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
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 August 10, 2014.
This Internet-Draft will expire on December 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 39
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . 16 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 2.7.1. http URI Scheme . . . . . . . . . . . . . . . . . . . 16
2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 2.7.2. https URI Scheme . . . . . . . . . . . . . . . . . . . 18
2.7.3. http and https URI Normalization and Comparison . . . 19 2.7.3. http and https URI Normalization and Comparison . . . 19
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21
3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22
3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23
3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23
3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24
3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. Field value components . . . . . . . . . . . . . . . . 26 3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26
3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28
3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31
3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33
3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34
4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37
4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38
4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 39
5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41
5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 41
5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42
5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44
5.6. Associating a Response to a Request . . . . . . . . . . . 46 5.6. Associating a Response to a Request . . . . . . . . . . . 46
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 8.1. Header Field Registration . . . . . . . . . . . . . . . . 59
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 8.3. Internet Media Type Registration . . . . . . . . . . . . . 60
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
8.3.2. Internet Media Type application/http . . . . . . . . . 62 8.3.2. Internet Media Type application/http . . . . . . . . . 62
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64
8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65
8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66
9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66
9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67
9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 67
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 69
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
11.2. Informative References . . . . . . . . . . . . . . . . . . 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 73
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 75
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 76
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 77
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Appendix C. Change Log (to be removed by RFC Editor before Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
publication) . . . . . . . . . . . . . . . . . . . . 82
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82
C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 83
C.3. Since draft-ietf-httpbis-p1-messaging-25 . . . . . . . . . 83
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive message payloads for flexible interaction with self-descriptive message payloads for flexible interaction with
network-based hypertext information systems. This document is the network-based hypertext information systems. This document is the
first in a series of documents that collectively form the HTTP/1.1 first in a series of documents that collectively form the HTTP/1.1
specification: specification:
RFC xxx1: Message Syntax and Routing 1. "Message Syntax and Routing" (this document)
RFC xxx2: Semantics and Content 2. "Semantics and Content" [RFC7231]
RFC xxx3: Conditional Requests 3. "Conditional Requests" [RFC7232]
RFC xxx4: Range Requests 4. "Range Requests" [RFC7233]
RFC xxx5: Caching 5. "Caching" [RFC7234]
RFC xxx6: Authentication 6. "Authentication" [RFC7235]
This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
versioning). This specification also updates the use of CONNECT to versioning). This specification also updates the use of CONNECT to
establish a tunnel, previously defined in RFC 2817, and defines the establish a tunnel, previously defined in RFC 2817, and defines the
"https" URI scheme that was described informally in RFC 2818. "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
skipping to change at page 6, line 18 skipping to change at page 6, line 18
This document describes the architectural elements that are used or This document describes the architectural elements that are used or
referred to in HTTP, defines the "http" and "https" URI schemes, referred to in HTTP, defines the "http" and "https" URI schemes,
describes overall network operation and connection management, and describes overall network operation and connection management, and
defines HTTP message framing and forwarding requirements. Our goal defines HTTP message framing and forwarding requirements. Our goal
is to define all of the mechanisms necessary for HTTP message is to define all of the mechanisms necessary for HTTP message
handling that are independent of message semantics, thereby defining handling that are independent of message semantics, thereby defining
the complete set of requirements for message parsers and message- the complete set of requirements for message parsers and message-
forwarding intermediaries. forwarding intermediaries.
1.1. Requirement Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5. defined in Section 2.5.
1.2. Syntax Notation 1.2. Syntax Notation
skipping to change at page 7, line 8 skipping to change at page 7, line 8
2. Architecture 2. Architecture
HTTP was created for the World Wide Web (WWW) architecture and has HTTP was created for the World Wide Web (WWW) architecture and has
evolved over time to support the scalability needs of a worldwide evolved over time to support the scalability needs of a worldwide
hypertext system. Much of that architecture is reflected in the hypertext system. Much of that architecture is reflected in the
terminology and syntax productions used to define HTTP. terminology and syntax productions used to define HTTP.
2.1. Client/Server Messaging 2.1. Client/Server Messaging
HTTP is a stateless request/response protocol that operates by HTTP is a stateless request/response protocol that operates by
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. The term act as a client on some connections and a server on others. The term
""user agent"" refers to any of the various client programs that ""user agent"" refers to any of the various client programs that
initiate a request, including (but not limited to) browsers, spiders initiate a request, including (but not limited to) browsers, spiders
(web-based robots), command-line tools, custom applications, and (web-based robots), command-line tools, custom applications, and
mobile apps. The term ""origin server"" refers to the program that mobile apps. The term ""origin server"" refers to the program that
can originate authoritative responses for a given target resource. can originate authoritative responses for a given target resource.
The terms ""sender"" and ""recipient"" refer to any implementation The terms ""sender"" and ""recipient"" refer to any implementation
that sends or receives a given message, respectively. that sends or receives a given message, respectively.
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
for the differences between HTTP and MIME messages). [RFC7231] 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
case, this might be accomplished via a single bidirectional case, this might be accomplished via a single bidirectional
connection (===) between the user agent (UA) and the origin server connection (===) between the user agent (UA) and the origin server
(O). (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
skipping to change at page 8, line 15 skipping to change at page 8, line 15
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.3. 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 (Section 4.3.1 of [Part2]) on the URI GET request (Section 4.3.1 of [RFC7231]) on the URI
"http://www.example.com/hello.txt": "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
Server response: Server response:
skipping to change at page 8, line 50 skipping to change at page 8, line 50
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,
autonomous robots, news feeds, traffic cameras, ad selectors, and autonomous robots, news feeds, traffic cameras, ad selectors, and
video delivery platforms. video-delivery platforms.
The term "user agent" does not imply that there is a human user The term "user agent" does not imply that there is a human user
directly interacting with the software agent at the time of a directly interacting with the software agent at the time of a
request. In many cases, a user agent is installed or configured to request. In many cases, a user agent is installed or configured to
run in the background and save its results for later inspection (or run in the background and save its results for later inspection (or
save only a subset of those results that might be interesting or save only a subset of those results that might be interesting or
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.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
tunnel, switching behavior based on the nature of each request. tunnel, switching behavior based on the nature of each request.
> > > > > > > >
UA =========== A =========== B =========== C =========== O UA =========== A =========== B =========== C =========== O
< < < < < < < <
The figure above shows three intermediaries (A, B, and C) between the The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that user agent and origin server. A request or response message that
travels the whole chain will pass through four separate connections. travels the whole chain will pass through four separate connections.
Some HTTP communication options might apply only to the connection Some HTTP communication options might apply only to the connection
with the nearest, non-tunnel neighbor, only to the end-points of the with the nearest, non-tunnel neighbor, only to the endpoints of the
chain, or to all connections along the chain. Although the diagram chain, or to all connections along the chain. Although the diagram
is linear, each participant might be engaged in multiple, is linear, each participant might be engaged in multiple,
simultaneous communications. For example, B might be receiving simultaneous communications. For example, B might be receiving
requests from many clients other than A, and/or forwarding requests requests from many clients other than A, and/or forwarding requests
to servers other than C, at the same time that it is handling A's to servers other than C, at the same time that it is handling A's
request. Likewise, later requests might be sent through a different request. Likewise, later requests might be sent through a different
path of connections, often based on dynamic configuration for load path of connections, often based on dynamic configuration for load
balancing. balancing.
The terms ""upstream"" and ""downstream"" are used to describe The terms ""upstream"" and ""downstream"" are used to describe
directional requirements in relation to the message flow: all directional requirements in relation to the message flow: all
messages flow from upstream to downstream. The terms inbound and messages flow from upstream to downstream. The terms "inbound" and
outbound are used to describe directional requirements in relation to "outbound" are used to describe directional requirements in relation
the request route: ""inbound"" means toward the origin server and to the request route: ""inbound"" means toward the origin server and
""outbound"" means toward the user agent. ""outbound"" means toward the user agent.
A ""proxy"" is a message forwarding agent that is selected by the A ""proxy"" is a message-forwarding agent that is selected by the
client, usually via local configuration rules, to receive requests client, usually via local configuration rules, to receive requests
for some type(s) of absolute URI and attempt to satisfy those for some type(s) of absolute URI and attempt to satisfy those
requests via translation through the HTTP interface. Some requests via translation through the HTTP interface. Some
translations are minimal, such as for proxy requests for "http" URIs, translations are minimal, such as for proxy requests for "http" URIs,
whereas other requests might require translation to and from entirely whereas other requests might require translation to and from entirely
different application-level protocols. Proxies are often used to different application-level protocols. Proxies are often used to
group an organization's HTTP requests through a common intermediary group an organization's HTTP requests through a common intermediary
for the sake of security, annotation services, or shared caching. for the sake of security, annotation services, or shared caching.
Some proxies are designed to apply transformations to selected Some proxies are designed to apply transformations to selected
messages or payloads while they are being forwarded, as described in messages or payloads while they are being forwarded, as described in
Section 5.7.2. Section 5.7.2.
A ""gateway"" (a.k.a., ""reverse proxy"") is an intermediary that A ""gateway"" (a.k.a. ""reverse proxy"") is an intermediary that acts
acts as an origin server for the outbound connection, but translates as an origin server for the outbound connection but translates
received requests and forwards them inbound to another server or received requests and forwards them inbound to another server or
servers. Gateways are often used to encapsulate legacy or untrusted servers. Gateways are often used to encapsulate legacy or untrusted
information services, to improve server performance through information services, to improve server performance through
""accelerator"" caching, and to enable partitioning or load balancing ""accelerator"" caching, and to enable partitioning or load balancing
of HTTP services across multiple machines. of HTTP services across multiple machines.
All HTTP requirements applicable to an origin server also apply to All HTTP requirements applicable to an origin server also apply to
the outbound communication of a gateway. A gateway communicates with the outbound communication of a gateway. A gateway communicates with
inbound servers using any protocol that it desires, including private inbound 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.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
Instead, an interception proxy filters or redirects outgoing TCP port Instead, an interception proxy filters or redirects outgoing TCP port
80 packets (and occasionally other common port traffic). 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. firewalls to enforce network usage policies.
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, a dynamically load balance requests across multiple servers. Hence, a
server MUST NOT assume that two requests on the same connection are server 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.
skipping to change at page 12, line 6 skipping to change at page 12, line 6
> > > >
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]. [RFC7234].
There are a wide variety of architectures and configurations of There is a wide variety of architectures and configurations of caches
caches deployed across the World Wide Web and inside large deployed across the World Wide Web and inside large organizations.
organizations. These include national hierarchies of proxy caches to These include national hierarchies of proxy caches to save
save transoceanic bandwidth, collaborative systems that broadcast or transoceanic bandwidth, collaborative systems that broadcast or
multicast cache entries, archives of pre-fetched cache entries for multicast cache entries, archives of pre-fetched cache entries for
use in off-line or high-latency environments, 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.
skipping to change at page 12, line 44 skipping to change at page 12, line 44
elements. A sender MUST NOT generate protocol elements that convey a elements. A sender MUST NOT generate protocol elements that convey a
meaning that is known by that sender to be false. A sender MUST NOT meaning that is known by that sender to be false. A sender MUST NOT
generate protocol elements that do not match the grammar defined by generate protocol elements that do not match the grammar defined by
the corresponding ABNF rules. Within a given message, a sender MUST the corresponding ABNF rules. Within a given message, a sender MUST
NOT generate protocol elements or syntax alternatives that are only NOT generate protocol elements or syntax alternatives that are only
allowed to be generated by participants in other roles (i.e., a role allowed to be generated by participants in other roles (i.e., a role
that the sender does not have for that message). that the sender does not have for that message).
When a received protocol element is parsed, the recipient MUST be When a received protocol element is parsed, the recipient MUST be
able to parse any value of reasonable length that is applicable to able to parse any value of reasonable length that is applicable to
the recipient's role and matches the grammar defined by the the recipient's role and that matches the grammar defined by the
corresponding ABNF rules. Note, however, that some received protocol corresponding ABNF rules. Note, however, that some received protocol
elements might not be parsed. For example, an intermediary elements might not be parsed. For example, an intermediary
forwarding a message might parse a header-field into generic field- forwarding a message might parse a header-field into generic field-
name and field-value components, but then forward the header field name and field-value components, but then forward the header field
without further parsing inside the field-value. without further parsing inside the field-value.
HTTP does not have specific length limitations for many of its HTTP does not have specific length limitations for many of its
protocol elements because the lengths that might be appropriate will protocol elements because the lengths that might be appropriate will
vary widely, depending on the deployment context and purpose of the vary widely, depending on the deployment context and purpose of the
implementation. Hence, interoperability between senders and implementation. Hence, interoperability between senders and
recipients depends on shared expectations regarding what is a recipients depends on shared expectations regarding what is a
reasonable length for each protocol element. Furthermore, what is reasonable length for each protocol element. Furthermore, what is
commonly understood to be a reasonable length for some protocol commonly understood to be a reasonable length for some protocol
elements has changed over the course of the past two decades of HTTP elements has changed over the course of the past two decades of HTTP
use, and is expected to continue changing in the future. use and is expected to continue changing in the future.
At a minimum, a recipient MUST be able to parse and process protocol At a minimum, a recipient MUST be able to parse and process protocol
element lengths that are at least as long as the values that it element lengths that are at least as long as the values that it
generates for those same protocol elements in other messages. For generates for those same protocol elements in other messages. For
example, an origin server that publishes very long URI references to example, an origin server that publishes very long URI references to
its own resources needs to be able to parse and process those same its own resources needs to be able to parse and process those same
references when received as a request target. references when received as a request target.
A recipient MUST interpret a received protocol element according to A recipient MUST interpret a received protocol element according to
the semantics defined for it by this specification, including the semantics defined for it by this specification, including
skipping to change at page 16, line 8 skipping to change at page 16, line 8
it were in the highest minor version within that major version to it were in the highest minor version within that major version to
which the recipient is conformant. A recipient can assume that a which the recipient is conformant. A recipient can assume that a
message with a higher minor version, when sent to a recipient that message with a higher minor version, when sent to a recipient that
has not yet indicated support for that higher version, is has not yet indicated support for that higher version, is
sufficiently backwards-compatible to be safely processed by any sufficiently backwards-compatible to be safely processed by any
implementation of the same major version. implementation of the same major version.
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 [RFC7231]).
URI references are used to target requests, indicate redirects, and URI references are used to target requests, indicate redirects, and
define relationships. define relationships.
The definitions of "URI-reference", "absolute-URI", "relative-part", The definitions of "URI-reference", "absolute-URI", "relative-part",
"scheme", "authority", "port", "host", "path-abempty", "segment", "scheme", "authority", "port", "host", "path-abempty", "segment",
"query", and "fragment" are adopted from the URI generic syntax. An "query", and "fragment" are adopted from the URI generic syntax. An
"absolute-path" rule is defined for protocol elements that can "absolute-path" rule is defined for protocol elements that can
contain a non-empty path component. (This rule differs slightly from contain a non-empty path component. (This rule differs slightly from
RFC 3986's path-abempty rule, which allows for an empty path to be the path-abempty rule of RFC 3986, which allows for an empty path to
used in references, and path-absolute rule, which does not allow be used in references, and path-absolute rule, which does not allow
paths that begin with "//".) A "partial-URI" rule is defined for paths that begin with "//".) A "partial-URI" rule is defined for
protocol elements that can contain a relative URI but not a fragment protocol elements that can contain a relative URI but not a fragment
component. component.
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, see [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
relative-part = <relative-part, defined in [RFC3986], Section 4.2> relative-part = <relative-part, see [RFC3986], Section 4.2>
scheme = <scheme, defined in [RFC3986], Section 3.1> scheme = <scheme, see [RFC3986], Section 3.1>
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, see [RFC3986], Section 3.2>
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, see [RFC3986], Section 3.2.3>
path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, defined in [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
query = <query, defined in [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, defined in [RFC3986], Section 3.5> fragment = <fragment, see [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment ) 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
The "http" URI scheme is hereby defined for the purpose of minting The "http" 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 for namespace governed by a potential HTTP origin server listening for
TCP ([RFC0793]) connections on a given port. TCP ([RFC0793]) connections on a given port.
http-URI = "http:" "//" authority path-abempty [ "?" query ] http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
skipping to change at page 17, line 44 skipping to change at page 17, line 44
federated namespace, based on control over the indicated host and federated namespace, based on control over the indicated host and
port, whether or not an HTTP server is present. See Section 9.1 for port, whether or not an HTTP server is present. See Section 9.1 for
security considerations related to establishing authority. security considerations related to establishing authority.
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 6 of [Part2], then HTTP response message, as described in Section 6 of [RFC7231], 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
skipping to change at page 18, line 23 skipping to change at page 18, line 23
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. A sender MUST NOT usage might expose a user identifier or password. A sender MUST NOT
generate the userinfo subcomponent (and its "@" delimiter) when an generate the userinfo subcomponent (and its "@" delimiter) when an
"http" URI reference is generated within a message as a request "http" URI reference is generated within a message as a request
target or header field value. Before making use of an "http" URI target or header field value. Before making use of an "http" URI
reference received from an untrusted source, a recipient SHOULD parse reference received from an untrusted source, a recipient SHOULD parse
for userinfo and treat its presence as an error; it is likely being for userinfo and treat its presence as an error; it is likely being
used to obscure the authority for the sake of phishing attacks. used to obscure the authority for the sake of phishing 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 TCP port 443 is the requirements for the "https" scheme, except that TCP port 443 is the
default if the port subcomponent is empty or not given, and the user default if the port subcomponent is empty or not given, and the user
agent MUST ensure that its connection to the origin server is secured agent MUST ensure that its connection to the origin server is secured
through the use of strong encryption, end-to-end, prior to sending through the use of strong encryption, end-to-end, prior to sending
the first HTTP request. the first HTTP request.
https-URI = "https:" "//" authority path-abempty [ "?" query ] https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ] [ "#" fragment ]
Note that the "https" URI scheme depends on both TLS and TCP for Note that the "https" URI scheme depends on both TLS and TCP for
establishing authority. Resources made available via the "https" establishing authority. Resources made available via the "https"
scheme have no shared identity with the "http" scheme even if their scheme have no shared identity with the "http" scheme even if their
resource identifiers indicate the same authority (the same host resource identifiers indicate the same authority (the same host
listening to the same TCP port). They are distinct name spaces and listening to the same TCP port). They are distinct namespaces and
are considered to be distinct origin servers. However, an extension are considered to be distinct origin servers. However, an extension
to HTTP that is defined to apply to entire host domains, such as the to HTTP that is defined to apply to entire host domains, such as the
Cookie protocol [RFC6265], can allow information set by one service Cookie protocol [RFC6265], can allow information set by one service
to impact communication with other services within a matching group to impact communication with other services within a matching group
of host domains. of host domains.
The process for authoritative access to an "https" identified The process for authoritative access to an "https" identified
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
skipping to change at page 20, line 37 skipping to change at page 20, line 37
The presence of such whitespace in a request might be an attempt to The presence of such whitespace in a request might be an attempt to
trick a server into ignoring that field or processing the line after trick a server into ignoring that field or processing the line after
it as a new request, either of which might result in a security it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or such whitespace in a response might be ignored by some clients or
cause others to cease parsing. cause others to cease parsing.
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 be either 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). for determining the length of the message body (Section 3.3).
In 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
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 ends with CRLF.
request-line = method SP request-target SP HTTP-version CRLF request-line = method SP request-target SP HTTP-version CRLF
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 request methods defined by this specification can be found in The request methods defined by this specification can be found in
Section 4 of [Part2], along with information regarding the HTTP Section 4 of [RFC7231], along with information regarding the HTTP
method registry and considerations for defining new methods. method registry 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.
Recipients typically parse the request-line into its component parts Recipients typically parse the request-line into its component parts
by splitting on whitespace (see Section 3.5), since no whitespace is by splitting on whitespace (see Section 3.5), since no whitespace is
allowed in the three components. Unfortunately, some user agents allowed in the three components. Unfortunately, some user agents
fail to properly encode or exclude whitespace found in hypertext fail to properly encode or exclude whitespace found in hypertext
references, resulting in those disallowed characters being sent in a references, resulting in those disallowed characters being sent in a
request-target. request-target.
Recipients of an invalid request-line SHOULD respond with either a Recipients of an invalid request-line SHOULD respond with either a
400 (Bad Request) error or a 301 (Moved Permanently) redirect with 400 (Bad Request) error or a 301 (Moved Permanently) redirect with
the request-target properly encoded. A recipient SHOULD NOT attempt the request-target properly encoded. A recipient SHOULD NOT attempt
to autocorrect and then process the request without a redirect, since to autocorrect and then process the request without a redirect, since
the invalid request-line might be deliberately crafted to bypass the invalid request-line might be deliberately crafted to bypass
security filters along the request chain. 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 predefined limit on the length of a request-
line, as described in Section 2.5. A server that receives a method line, as described in Section 2.5. A server that receives a method
longer than any that it implements SHOULD respond with a 501 (Not longer than any that it implements SHOULD respond with a 501 (Not
Implemented) status code. A server that receives a request-target Implemented) status code. A server that receives a request-target
longer than any URI it wishes to parse MUST respond with a 414 (URI longer than any URI it wishes to parse MUST respond with a 414 (URI
Too Long) status code (see Section 6.5.12 of [Part2]). Too Long) status code (see Section 6.5.12 of [RFC7231]).
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 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
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 6 of [Part2] for information about the semantics of See Section 6 of [RFC7231] 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 23, line 4 skipping to change at page 23, line 4
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
obs-fold = CRLF 1*( SP / HTAB ) obs-fold = CRLF 1*( SP / HTAB )
; obsolete line folding ; obsolete line folding
; see Section 3.2.4 ; 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 7.1.1.2 of [Part2] as containing header field is defined in Section 7.1.1.2 of [RFC7231] 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 3.2.1. Field Extensibility
Header fields are fully extensible: there is no limit on the 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, nor on the number of header fields used in a given semantics, nor on the number of header fields used in a given
message. Existing fields are defined in each part of this message. Existing fields are defined in each part of this
specification and in many other specifications outside this document specification and in many other specifications outside this document
set. set.
skipping to change at page 23, line 29 skipping to change at page 23, line 29
evaluation, or refine the meaning of responses. evaluation, or refine the meaning of responses.
A proxy MUST forward unrecognized header fields unless the field-name A proxy MUST forward unrecognized header fields unless the field-name
is listed in the Connection header field (Section 6.1) or the proxy is listed in the Connection header field (Section 6.1) or the proxy
is specifically configured to block, or otherwise transform, such is specifically configured to block, or otherwise transform, such
fields. Other recipients SHOULD ignore unrecognized header fields. fields. Other recipients SHOULD ignore unrecognized header fields.
These requirements allow HTTP's functionality to be enhanced without These requirements allow HTTP's functionality to be enhanced without
requiring prior update of deployed intermediaries. requiring prior update of deployed intermediaries.
All defined header fields ought to be registered with IANA in the All defined header fields ought to be registered with IANA in the
Message Header Field Registry, as described in Section 8.3 of "Message Headers" registry, as described in Section 8.3 of [RFC7231].
[Part2].
3.2.2. Field Order 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 NOT when not to handle a message as early as possible. A server MUST NOT
apply a request to the target resource until the entire request apply a request to the target resource until the entire request
header section is received, since later header fields might include header section is received, since later header fields might include
skipping to change at page 24, line 28 skipping to change at page 24, line 27
3.2.3. Whitespace 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. For protocol elements where optional whitespace is might appear. For protocol elements where optional whitespace is
preferred to improve readability, a sender SHOULD generate the preferred to improve readability, a sender SHOULD generate the
optional whitespace as a single SP; otherwise, a sender SHOULD NOT optional whitespace as a single SP; otherwise, a sender SHOULD NOT
generate optional whitespace except as needed to white-out invalid or generate optional whitespace except as needed to white out invalid or
unwanted protocol elements during in-place message filtering. unwanted protocol elements during in-place message filtering.
The RWS rule is used when at least one linear whitespace octet is The RWS rule is used when at least one linear whitespace octet is
required to separate field tokens. A sender SHOULD generate RWS as a required to separate field tokens. A sender SHOULD generate RWS as a
single SP. single SP.
The BWS rule is used where the grammar allows optional whitespace The BWS rule is used where the grammar allows optional whitespace
only for historical reasons. A sender MUST NOT generate BWS in only for historical reasons. A sender MUST NOT generate BWS in
messages. A recipient MUST parse for such bad whitespace and remove messages. A recipient MUST parse for such bad whitespace and remove
it before interpreting the protocol element. it before interpreting the protocol element.
skipping to change at page 25, line 13 skipping to change at page 25, line 7
; "bad" whitespace ; "bad" whitespace
3.2.4. Field Parsing 3.2.4. Field Parsing
Messages are parsed using a generic algorithm, independent of the Messages are parsed using a generic algorithm, independent of the
individual header field names. The contents within a given field individual header field names. The contents within a given field
value are not parsed until a later stage of message interpretation value are not parsed until a later stage of message interpretation
(usually after the message's entire header section has been (usually after the message's entire header section has been
processed). Consequently, this specification does not use ABNF rules processed). Consequently, this specification does not use ABNF rules
to define each "Field-Name: Field Value" pair, as was done in to define each "Field-Name: Field Value" pair, as was done in
previous editions. Instead, this specification uses ABNF rules which previous editions. Instead, this specification uses ABNF rules that
are named according to each registered field name, wherein the rule are named according to each registered field name, wherein the rule
defines the valid grammar for that field's corresponding field values defines the valid grammar for that field's corresponding field values
(i.e., after the field-value has been extracted from the header (i.e., after the field-value has been extracted from the header
section by a generic field parser). section by a generic field parser).
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. A security vulnerabilities in request routing and response handling. A
server MUST reject any received request message that contains server MUST reject any received request message that contains
whitespace between a header field-name and colon with a response code whitespace between a header field-name and colon with a response code
of 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 might be preceded and/or followed by optional A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans. The field value does not for consistent readability by humans. The field value does not
include any leading or trailing white space: OWS occurring before the include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last non- first non-whitespace octet of the field value or after the last non-
whitespace octet of the field value ought to be excluded by parsers whitespace octet of the field value ought to be excluded by parsers
when extracting the field value from a header field. when extracting the field value from a 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 8.3.1). A sender MUST NOT generate a message that includes (Section 8.3.1). A sender MUST NOT generate a message that includes
line folding (i.e., that has any field-value that contains a match to line folding (i.e., that has any field-value that contains a match to
skipping to change at page 26, line 15 skipping to change at page 26, line 10
with a representation explaining that unacceptable line folding was with a representation explaining that unacceptable line folding was
received, or replace each received obs-fold with one or more SP received, or replace each received obs-fold with one or more SP
octets prior to interpreting the field value or forwarding the octets prior to interpreting the field value or forwarding the
message downstream. message downstream.
A user agent that receives an obs-fold in a response message that is A user agent that receives an obs-fold in a response message that is
not within a message/http container MUST replace each received obs- not within a message/http container MUST replace each received obs-
fold with one or more SP octets prior to interpreting the field fold with one or more SP octets prior to interpreting the field
value. value.
Historically, HTTP has allowed field content with text in the ISO- Historically, HTTP has allowed field content with text in the
8859-1 [ISO-8859-1] charset, supporting other charsets only through ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
use of [RFC2047] encoding. In practice, most HTTP header field through use of [RFC2047] encoding. In practice, most HTTP header
values use only a subset of the US-ASCII charset [USASCII]. Newly field values use only a subset of the US-ASCII charset [USASCII].
defined header fields SHOULD limit their field values to US-ASCII Newly defined header fields SHOULD limit their field values to
octets. A recipient SHOULD treat other octets in field content (obs- US-ASCII octets. A recipient SHOULD treat other octets in field
text) as opaque data. content (obs-text) as opaque data.
3.2.5. Field Limits 3.2.5. Field Limits
HTTP does not place a pre-defined limit on the length of each header HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described field or on the length of the header section as a whole, as described
in Section 2.5. Various ad-hoc limitations on individual header in Section 2.5. Various ad hoc limitations on individual header
field length are found in practice, often depending on the specific field length are found in practice, often depending on the specific
field semantics. field semantics.
A server that receives a request header field, or set of fields, A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would (Client Error) status code. Ignoring such header fields would
increase the server's vulnerability to request smuggling attacks increase the server's vulnerability to request smuggling attacks
(Section 9.5). (Section 9.5).
A client MAY discard or truncate received header fields that are A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics. the message framing or response semantics.
3.2.6. Field value components 3.2.6. Field Value Components
Most HTTP header field values are defined using common syntax Most HTTP header field values are defined using common syntax
components (token, quoted-string, and comment) separated by components (token, quoted-string, and comment) separated by
whitespace or specific delimiting characters. Delimiters are chosen whitespace or specific delimiting characters. Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[\]{}"). (DQUOTE and "(),/:;<=>?@[\]{}").
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
skipping to change at page 28, line 10 skipping to change at page 27, line 50
requests and responses. requests and responses.
The presence of a message body in a request is signaled by a Content- The presence of a message body in a request is signaled by a Content-
Length or Transfer-Encoding header field. Request message framing is Length or Transfer-Encoding header field. Request message framing is
independent of method semantics, even if the method does not define independent of method semantics, even if the method does 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 (Section 4.3.2 (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2
of [Part2]) never include a message body because the associated of [RFC7231]) never include a message body because the associated
response header fields (e.g., Transfer-Encoding, Content-Length, response header fields (e.g., Transfer-Encoding, Content-Length,
etc.), if present, indicate only what their values would have been if etc.), if present, indicate only what their values would have been if
the request method had been GET (Section 4.3.1 of [Part2]). 2xx the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx
(Successful) responses to a CONNECT request method (Section 4.3.6 of (Successful) responses to a CONNECT request method (Section 4.3.6 of
[Part2]) switch to tunnel mode instead of having a message body. All [RFC7231]) switch to tunnel mode instead of having a message body.
1xx (Informational), 204 (No Content), and 304 (Not Modified) All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
responses do not include a message body. All other responses do responses do not include a message body. All other responses do
include a message body, although the body might be of zero length. include a message body, although the body might be of zero length.
3.3.1. Transfer-Encoding 3.3.1. Transfer-Encoding
The Transfer-Encoding header field lists the transfer coding names The Transfer-Encoding header field lists the transfer coding names
corresponding to the sequence of transfer codings that have been (or corresponding to the sequence of transfer codings that have been (or
will be) applied to the payload body in order to form the message will be) applied to the payload body in order to form the message
body. Transfer codings are defined in Section 4. body. Transfer codings are defined in Section 4.
skipping to change at page 29, line 13 skipping to change at page 28, line 50
by closing the connection. 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.
Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-
Encoding is a property of the message, not of the representation, and Encoding is a property of the message, not of the representation, and
any recipient along the request/response chain MAY decode the any recipient along the request/response chain MAY decode the
received transfer coding(s) or apply additional transfer coding(s) to received transfer coding(s) or apply additional transfer coding(s) to
the message body, assuming that corresponding changes are made to the the message body, assuming that corresponding changes are made to the
Transfer-Encoding field-value. Additional information about the Transfer-Encoding field-value. Additional information about the
encoding parameters can be provided by other header fields not encoding parameters can be provided by other header fields not
defined by this specification. 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 [RFC7232]) 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.
A server MUST NOT send a Transfer-Encoding header field in any A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No response with a status code of 1xx (Informational) or 204 (No
Content). A server MUST NOT send a Transfer-Encoding header field in Content). A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of
[Part2]). [RFC7231]).
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).
skipping to change at page 30, line 14 skipping to change at page 29, line 48
3.3.2. Content-Length 3.3.2. Content-Length
When a message does not have a Transfer-Encoding header field, a When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body. For messages decimal number of octets, for a potential payload body. For messages
that do include a payload body, the Content-Length field-value that do include a payload body, the Content-Length field-value
provides the framing information necessary for determining where the provides the framing information necessary for determining where the
body (and message) ends. For messages that do not include a payload body (and message) ends. For messages that do not include a payload
body, the Content-Length indicates the size of the selected body, the Content-Length indicates the size of the selected
representation (Section 3 of [Part2]). representation (Section 3 of [RFC7231]).
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 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 no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header 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 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 (indicating an empty payload body). A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a a payload body and the method semantics do not anticipate such a
body. 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 4.3.2 of [Part2]); a server MUST NOT send HEAD request (Section 4.3.2 of [RFC7231]); 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 [RFC7232]); 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 MUST NOT send a Content-Length header field in any 2xx server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of (Successful) response to a CONNECT request (Section 4.3.6 of
[Part2]). [RFC7231]).
Aside from the cases defined above, in the absence of Transfer- Aside from the cases defined above, in the absence of Transfer-
Encoding, an origin server SHOULD send a Content-Length header field Encoding, an origin server SHOULD send a Content-Length header field
when the payload body size is known prior to sending the complete when the payload body size is known prior to sending the complete
header section. This will allow downstream recipients to measure header section. This will allow downstream recipients to measure
transfer progress, know when a received message is complete, and transfer progress, know when a received message is complete, and
potentially reuse the connection for additional requests. 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 a valid. Since there is no predefined limit to the length of a
skipping to change at page 33, line 6 skipping to change at page 32, line 40
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 generate encoding or length- network failure, a server SHOULD generate encoding or length-
delimited messages whenever possible. The close-delimiting feature delimited messages whenever possible. The close-delimiting feature
exists primarily for backwards compatibility with HTTP/1.0. exists 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
skipping to change at page 33, line 43 skipping to change at page 33, line 29
agent MAY discard the remaining data or attempt to determine if that 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 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 case if the prior message's Content-Length value is incorrect. A
client MUST NOT process, cache, or forward such extra data as a client MUST NOT process, cache, or forward such extra data as a
separate response, since such behavior would be vulnerable to cache separate response, since such behavior would be vulnerable to cache
poisoning. poisoning.
3.4. Handling Incomplete Messages 3.4. Handling Incomplete Messages
A server that receives an incomplete request message, usually due to A server that receives an incomplete request message, usually due to
a canceled request or a triggered time-out exception, MAY send an a canceled request or a triggered timeout exception, MAY send an
error response prior to closing the connection. error response prior to closing the connection.
A client that receives an incomplete response message, which can A client that receives an incomplete response message, which can
occur when a connection is closed prematurely or when decoding a occur when a connection is closed prematurely or when decoding a
supposedly chunked transfer coding fails, MUST record the message as supposedly chunked transfer coding fails, MUST record the message as
incomplete. Cache requirements for incomplete responses are defined incomplete. Cache requirements for incomplete responses are defined
in Section 3 of [Part6]. in Section 3 of [RFC7234].
If a response terminates in the middle of the header section (before If a response terminates in the middle of the header section (before
the empty line is received) and the status code might rely on header 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 fields to convey the full meaning of the response, then the client
cannot assume that meaning has been conveyed; the client might need cannot assume that meaning has been conveyed; the client might need
to repeat the request in order to determine what action to take next. 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 A message body that uses the chunked transfer coding is incomplete if
the zero-sized chunk that terminates the encoding has not been 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 coding 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 section was of message body octets received, provided that the header section was
received intact. received intact.
3.5. Message Parsing Robustness 3.5. Message Parsing Robustness
Older HTTP/1.0 user agent implementations might send an extra CRLF Older HTTP/1.0 user agent implementations might send an extra CRLF
after a POST request as a workaround for some early server after a POST request as a 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 user agent MUST NOT preface terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
or follow a request with an extra CRLF. If terminating the request or follow a request with an extra CRLF. If terminating the request
skipping to change at page 37, line 6 skipping to change at page 36, line 47
message integrity check, digital signature, or post-processing message integrity check, digital signature, or post-processing
status. The trailer fields are identical to header fields, except status. The trailer fields are identical to header fields, except
they are sent in a chunked trailer instead of the message's header they are sent in a chunked trailer instead of the message's header
section. section.
trailer-part = *( header-field CRLF ) trailer-part = *( header-field CRLF )
A sender MUST NOT generate a trailer that contains a field necessary A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length), for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of [Part2]), authentication (e.g., see conditionals in Section 5 of [RFC7231]), authentication (e.g., see
[Part7] and [RFC6265]), response control data (e.g., see Section 7.1 [RFC7235] and [RFC6265]), response control data (e.g., see Section
of [Part2]), or determining how to process the payload (e.g., 7.1 of [RFC7231]), or determining how to process the payload (e.g.,
Content-Encoding, Content-Type, Content-Range, and Trailer). Content-Encoding, Content-Type, Content-Range, and Trailer).
When a chunked message containing a non-empty trailer is received, When a chunked message containing a non-empty trailer is received,
the recipient MAY process the fields (aside from those forbidden the recipient MAY process the fields (aside from those forbidden
above) as if they were appended to the message's header section. A above) as if they were appended to the message's header section. A
recipient MUST ignore (or consider as an error) any fields that are recipient MUST ignore (or consider as an error) any fields that are
forbidden to be sent in a trailer, since processing them as if they forbidden to be sent in a trailer, since processing them as if they
were present in the header section might bypass external security were present in the header section might bypass external security
filters. filters.
skipping to change at page 38, line 28 skipping to change at page 38, line 23
The "deflate" coding is a "zlib" data format [RFC1950] containing a The "deflate" coding is a "zlib" data format [RFC1950] containing a
"deflate" compressed data stream [RFC1951] that uses a combination of "deflate" compressed data stream [RFC1951] that uses a combination of
the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.
Note: Some non-conformant implementations send the "deflate" Note: Some non-conformant implementations send the "deflate"
compressed data without the zlib wrapper. compressed data without the zlib wrapper.
4.2.3. Gzip Coding 4.2.3. Gzip Coding
The "gzip" coding is an LZ77 coding with a 32 bit CRC that is The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
commonly produced by the gzip file compression program [RFC1952]. A Check (CRC) that is commonly produced by the gzip file compression
recipient SHOULD consider "x-gzip" to be equivalent to "gzip". program [RFC1952]. A recipient SHOULD consider "x-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
skipping to change at page 39, line 23 skipping to change at page 39, line 19
either: (a) all downstream clients are willing to accept trailer either: (a) all downstream clients are willing to accept trailer
fields in the forwarded response; or, (b) the intermediary will fields in the forwarded response; or, (b) the intermediary will
attempt to buffer the response on behalf of downstream recipients. attempt to buffer the response on behalf of downstream recipients.
Note that HTTP/1.1 does not define any means to limit the size of a Note that HTTP/1.1 does not define any means to limit the size of a
chunked response such that an intermediary can be assured of chunked response such that an intermediary can be assured of
buffering the entire response. 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
5.3.1 of [Part2]). The rank value is a real number in the range 0 5.3.1 of [RFC7231]). 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
skipping to change at page 40, line 23 skipping to change at page 40, line 15
5.1. Identifying a Target Resource 5.1. Identifying a Target Resource
HTTP is used in a wide variety of applications, ranging from general- HTTP is used in a wide variety of applications, ranging from general-
purpose computers to home appliances. In some cases, communication purpose computers to home appliances. In some cases, communication
options are hard-coded in a client's configuration. However, most options are hard-coded in a client's configuration. However, most
HTTP clients rely on the same resource identification mechanism and HTTP clients rely on the same resource identification mechanism and
configuration techniques as general-purpose Web browsers. configuration techniques as general-purpose Web browsers.
HTTP communication is initiated by a user agent for some purpose. HTTP communication is initiated by a user agent for some purpose.
The purpose is a combination of request semantics, which are defined The purpose is a combination of request semantics, which are defined
in [Part2], and a target resource upon which to apply those in [RFC7231], and a target resource upon which to apply those
semantics. A URI reference (Section 2.7) is typically used as an semantics. A URI reference (Section 2.7) is typically used as an
identifier for the ""target resource"", which a user agent would identifier for the ""target resource"", which a user agent would
resolve to its absolute form in order to obtain the ""target URI"". resolve to its absolute form in order to obtain the ""target URI"".
The target URI excludes the reference's fragment component, if any, The target URI excludes the reference's fragment component, if any,
since fragment identifiers are reserved for client-side processing since fragment identifiers are reserved for client-side processing
([RFC3986], Section 3.5). ([RFC3986], Section 3.5).
5.2. Connecting Inbound 5.2. Connecting Inbound
Once the target URI is determined, a client needs to decide whether a Once the target URI is determined, a client needs to decide whether a
network request is necessary to accomplish the desired semantics and, network request is necessary to accomplish the desired semantics and,
if so, where that request is to be directed. if so, where that request is to be directed.
If the client has a cache [Part6] and the request can be satisfied by If the client has a cache [RFC7234] and the request can be satisfied
it, then the request is usually directed there first. by it, then the request is usually directed there first.
If the request is not satisfied by a cache, then a typical client If the request is not satisfied by a cache, then a typical client
will check its configuration to determine whether a proxy is to be will check its configuration to determine whether a proxy is to be
used to satisfy the request. Proxy configuration is implementation- used to satisfy the request. Proxy configuration is implementation-
dependent, but is often based on URI prefix matching, selective dependent, but is often based on URI prefix matching, selective
authority matching, or both, and the proxy itself is usually authority matching, or both, and the proxy itself is usually
identified by an "http" or "https" URI. If a proxy is applicable, identified by an "http" or "https" URI. If a proxy is applicable,
the client connects inbound by establishing (or reusing) a connection the client connects inbound by establishing (or reusing) a connection
to that proxy. to that proxy.
skipping to change at page 42, line 31 skipping to change at page 42, line 23
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, a server MUST accept the absolute-form in future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in requests, even though HTTP/1.1 clients will only send them in
requests to proxies. requests to proxies.
5.3.3. authority-form 5.3.3. 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 4.3.6 of [Part2]). requests (Section 4.3.6 of [RFC7231]).
authority-form = authority authority-form = authority
When making a CONNECT request to establish a tunnel through one or When making a CONNECT request to establish a tunnel through one or
more proxies, a client MUST send only the target URI's authority more proxies, a client MUST send only the target URI's authority
component (excluding any userinfo and its "@" delimiter) as the component (excluding any userinfo and its "@" delimiter) as the
request-target. For example, request-target. For example,
CONNECT www.example.com:80 HTTP/1.1 CONNECT www.example.com:80 HTTP/1.1
5.3.4. asterisk-form 5.3.4. 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 4.3.7 of [Part2]). OPTIONS request (Section 4.3.7 of [RFC7231]).
asterisk-form = "*" asterisk-form = "*"
When a client wishes to request OPTIONS for the server as a whole, as When a client wishes to request OPTIONS for the server as a whole, as
opposed to a specific named resource of that server, the client MUST opposed to a specific named resource of that server, the client MUST
send only "*" (%x2A) as the request-target. For example, send only "*" (%x2A) 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 46, line 20 skipping to change at page 46, line 13
considerations regarding message routing. considerations regarding message routing.
5.6. Associating a Response to a Request 5.6. Associating a Response to a Request
HTTP does not include a request identifier for associating a given HTTP does not include a request identifier for associating a given
request message with its corresponding one or more response messages. request message with its corresponding one or more response messages.
Hence, it relies on the order of response arrival to correspond Hence, it relies on the order of response arrival to correspond
exactly to the order in which requests are made on the same exactly to the order in which requests are made on the same
connection. More than one response message per request only occurs connection. More than one response message per request only occurs
when one or more informational responses (1xx, see Section 6.2 of when one or more informational responses (1xx, see Section 6.2 of
[Part2]) precede a final response to the same request. [RFC7231]) precede a final response to the same request.
A client that has more than one outstanding request on a connection 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 maintain a list of outstanding requests in the order sent and
MUST associate each received response message on that connection to MUST associate each received response message on that connection to
the highest ordered request that has not yet received a final (non- the highest ordered request that has not yet received a final (non-
1xx) response. 1xx) response.
5.7. Message Forwarding 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
skipping to change at page 48, line 5 skipping to change at page 47, line 44
optional port number of a recipient server or client that optional port number of a recipient server or client that
subsequently forwarded the message. However, if the real host is subsequently forwarded the message. However, if the real host is
considered to be sensitive information, a sender MAY replace it with considered to be sensitive information, a sender MAY replace it with
a pseudonym. If a port is not provided, a recipient MAY interpret a pseudonym. If a port is not provided, a recipient MAY interpret
that as meaning it was received on the default TCP port, if any, for that as meaning it was received on the default TCP port, if any, for
the received-protocol. the received-protocol.
A sender MAY generate comments in the Via header field to identify A sender MAY generate comments in the Via header field to identify
the software of each recipient, analogous to the User-Agent and the software of each recipient, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are Server header fields. However, all comments in the Via field are
optional and a recipient MAY remove them prior to forwarding the optional, and a recipient MAY remove them prior to forwarding the
message. message.
For example, a request message could be sent from an HTTP/1.0 user For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at p.example.net, which forward the request to a public proxy at p.example.net, which
completes the request by forwarding it to the origin server at completes the request by forwarding it to the origin server at
www.example.com. The request received by www.example.com would then www.example.com. The request received by www.example.com would then
have the following Via header field: have the following Via header field:
Via: 1.0 fred, 1.1 p.example.net Via: 1.0 fred, 1.1 p.example.net
skipping to change at page 49, line 28 skipping to change at page 49, line 17
domain name. domain name.
A proxy MUST NOT modify the "absolute-path" and "query" parts of the A proxy MUST NOT modify the "absolute-path" and "query" parts of the
received request-target when forwarding it to the next inbound received request-target when forwarding it to the next inbound
server, except as noted above to replace an empty path with "/" or server, except as noted above to replace an empty path with "/" or
"*". "*".
A proxy MAY modify the message body through application or removal of A proxy MAY modify the message body through application or removal of
a transfer coding (Section 4). a transfer coding (Section 4).
A proxy MUST NOT transform the payload (Section 3.3 of [Part2]) of a A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
message that contains a no-transform cache-control directive (Section a message that contains a no-transform cache-control directive
5.2 of [Part6]). (Section 5.2 of [RFC7234]).
A proxy MAY transform the payload of a message that does not contain A proxy MAY transform the payload of a message that does not contain
a no-transform cache-control directive. A proxy that transforms a a no-transform cache-control directive. A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214 payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see ("Transformation Applied") if one is not already in the message (see
Section 5.5 of [Part6]). A proxy that transforms the payload of a Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
200 (OK) response can further inform downstream recipients that a 200 (OK) response can further inform downstream recipients that a
transformation has been applied by changing the response status code transformation has been applied by changing the response status code
to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
A proxy SHOULD NOT modify header fields that provide information A proxy SHOULD NOT modify header fields that provide information
about the end points of the communication chain, the resource state, about the endpoints of the communication chain, the resource state,
or the selected representation (other than the payload) unless the or the selected representation (other than the payload) unless the
field's definition specifically allows such modification or the field's definition specifically allows such modification or the
modification is deemed necessary for privacy or security. modification is deemed necessary for privacy or security.
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
layer connection protocol(s). HTTP only presumes a reliable session-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
used for an HTTP interaction are determined by client configuration used for an HTTP interaction are determined by client configuration
and the target URI. For example, the "http" URI scheme and the target URI. For example, the "http" URI scheme
(Section 2.7.1) indicates a default connection of TCP over IP, with a (Section 2.7.1) indicates a default connection of TCP over IP, with a
default TCP port of 80, but the client might be configured to use a default TCP port of 80, but the client might be configured to use a
proxy via some other connection, port, or protocol. proxy via some other connection, port, or protocol.
HTTP implementations are expected to engage in connection management, HTTP implementations are expected to engage in connection management,
which includes maintaining the state of current connections, which includes maintaining the state of current connections,
establishing a new connection or reusing an existing connection, establishing a new connection or reusing an existing connection,
processing messages received on a connection, detecting connection processing messages received on a connection, detecting connection
failures, and closing each connection. Most clients maintain failures, and closing each connection. Most clients maintain
multiple connections in parallel, including more than one connection multiple connections in parallel, including more than one connection
per server endpoint. Most servers are designed to maintain thousands per server endpoint. Most servers are designed to maintain thousands
of concurrent connections, while controlling request queues to enable of concurrent connections, while controlling request queues to enable
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 aside from Connection is used to supply control When a header field aside from Connection is used to supply control
information for or about the current connection, the sender MUST list information for or about the current connection, the sender MUST list
the 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 51, line 13 skipping to change at page 50, line 51
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 send a connection option corresponding to a header A sender MUST NOT send a connection option corresponding to a header
field that is intended for all recipients of the payload. For field that is intended for all recipients of the payload. For
example, Cache-Control is never appropriate as a connection option example, Cache-Control is never appropriate as a connection option
(Section 5.2 of [Part6]). (Section 5.2 of [RFC7234]).
The connection options do not always correspond to a header field The connection options do not always 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 a might not be needed if there are no parameters associated with a
connection option. In contrast, a connection-specific header field connection option. In contrast, a connection-specific header field
that is received without a corresponding connection option usually that is received without a corresponding connection option usually
indicates that the field has been improperly forwarded by an indicates that the field has been improperly forwarded by an
intermediary and ought to be ignored by the recipient. intermediary and ought to be ignored by the recipient.
When defining new connection options, specification authors ought to When defining new connection options, specification authors ought to
skipping to change at page 51, line 51 skipping to change at page 51, line 41
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. Establishment 6.2. 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 6.3. Persistence
HTTP/1.1 defaults to the use of ""persistent connections"", allowing HTTP/1.1 defaults to the use of ""persistent connections"", allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. The "close" connection-option is used to signal that a connection. The "close" connection option is used to signal that a
connection will not persist after the current request/response. HTTP connection will not persist after the current request/response. HTTP
implementations SHOULD support persistent connections. 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
persist after the current response; else, not 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 client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a close connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to In order to remain persistent, all messages on a connection need to
have a self-defined message length (i.e., one not defined by closure 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 of the connection), as described in Section 3.3. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response, since otherwise the remaining data on a persistent its response, since otherwise the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
A proxy server MUST NOT maintain a persistent connection with an 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 HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
discussion of the problems with the Keep-Alive header field discussion of the problems with the Keep-Alive header field
implemented by many HTTP/1.0 clients). implemented by many HTTP/1.0 clients).
See Appendix A.1.2 for more information on backward compatibility See Appendix A.1.2 for more information on backwards compatibility
with HTTP/1.0 clients. with HTTP/1.0 clients.
6.3.1. Retrying Requests 6.3.1. Retrying Requests
Connections can be closed at any time, with or without intention. Connections can be closed at any time, with or without intention.
Implementations ought to anticipate the need to recover from Implementations ought to anticipate the need to recover from
asynchronous close events. asynchronous close events.
When an inbound connection is closed prematurely, a client MAY open a When an inbound connection is closed prematurely, a client MAY open a
new connection and automatically retransmit an aborted sequence of new connection and automatically retransmit an aborted sequence of
requests if all of those requests have idempotent methods (Section requests if all of those requests have idempotent methods (Section
4.2.2 of [Part2]). A proxy MUST NOT automatically retry non- 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry non-
idempotent requests. idempotent requests.
A user agent MUST NOT automatically retry a request with a non- A user agent MUST NOT automatically retry a request with a non-
idempotent method unless it has some means to know that the request idempotent method unless it has some means to know that the request
semantics are actually idempotent, regardless of the method, or some semantics are actually idempotent, regardless of the method, or some
means to detect that the original request was never applied. For means to detect that the original request was never applied. For
example, a user agent that knows (through design or configuration) example, a user agent that knows (through design or configuration)
that a POST request to a given resource is safe can repeat that that a POST request to a given resource is safe can repeat that
request automatically. Likewise, a user agent designed specifically request automatically. Likewise, a user agent designed specifically
to operate on a version control repository might be able to recover to operate on a version control repository might be able to recover
skipping to change at page 53, line 37 skipping to change at page 53, line 25
changes that were partially applied, and then automatically retrying changes that were partially applied, and then automatically retrying
the requests that failed. the requests that failed.
A client SHOULD NOT automatically retry a failed automatic retry. A client SHOULD NOT automatically retry a failed automatic retry.
6.3.2. Pipelining 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 MAY process a sequence of pipelined requests in response). A server MAY process a sequence of pipelined requests in
parallel if they all have safe methods (Section 4.2.1 of [Part2]), parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
but MUST send the corresponding responses in the same order that the but it MUST send the corresponding responses in the same order that
requests were received. the requests were received.
A client that pipelines requests SHOULD retry unanswered requests if A client that pipelines requests SHOULD retry unanswered requests if
the connection closes before it receives all of the corresponding the connection closes before it receives all of the corresponding
responses. When retrying pipelined requests after a failed responses. When retrying pipelined requests after a failed
connection (a connection not explicitly closed by the server in its connection (a connection not explicitly closed by the server in its
last complete response), a client MUST NOT pipeline immediately after last complete response), a client MUST NOT pipeline immediately after
connection establishment, since the first remaining request in the connection establishment, since the first remaining request in the
prior pipeline might have caused an error response that can be lost prior pipeline might have caused an error response that can be lost
again if multiple requests are sent on a prematurely closed again if multiple requests are sent on a prematurely closed
connection (see the TCP reset problem described in Section 6.6). connection (see the TCP reset problem described in Section 6.6).
Idempotent methods (Section 4.2.2 of [Part2]) are significant to Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to
pipelining because they can be automatically retried after a pipelining because they can be automatically retried after a
connection failure. A user agent SHOULD NOT pipeline requests after connection failure. A user agent SHOULD NOT pipeline requests after
a non-idempotent method, until the final response status code for a non-idempotent method, until the final response status code for
that method has been received, unless the user agent has a means to that method has been received, unless the user agent has a means to
detect and recover from partial failure conditions involving the detect and recover from partial failure conditions involving the
pipelined sequence. pipelined sequence.
An intermediary that receives pipelined requests MAY pipeline those An intermediary that receives pipelined requests MAY pipeline those
requests when forwarding them inbound, since it can rely on the requests when forwarding them inbound, since it can rely on the
outbound user agent(s) to determine what requests can be safely outbound user agent(s) to determine what requests can be safely
skipping to change at page 54, line 29 skipping to change at page 54, line 17
agent(s) can recover accordingly. agent(s) can recover accordingly.
6.4. Concurrency 6.4. Concurrency
A client ought to limit the number of simultaneous open connections A client ought to limit the number of simultaneous open connections
that it maintains to a given server. that it maintains 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 a server might reject traffic that it deems abusive or Note that a server might reject traffic that it deems abusive or
characteristic of a denial of service attack, such as an excessive characteristic of a denial-of-service attack, such as an excessive
number of open connections from a single client. number of open connections from a single client.
6.5. Failures and Time-outs 6.5. Failures and Timeouts
Servers will usually have some time-out value beyond which they will Servers will usually have some timeout 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 proxy server. The use of more connections through the same proxy server. The use of
persistent connections places no requirements on the length (or persistent connections places no requirements on the length (or
existence) of this time-out for either the client or the server. existence) of this timeout for either the client or the server.
A client or server that wishes to time-out SHOULD issue a graceful A client or server that wishes to time out SHOULD issue a graceful
close on the connection. Implementations SHOULD constantly monitor close on the connection. Implementations SHOULD constantly monitor
open connections for a received closure signal and respond to it as open connections for a received closure signal and respond to it as
appropriate, since prompt closure of both sides of a connection appropriate, since prompt closure of both sides of a connection
enables allocated system resources to be reclaimed. enables allocated system resources to be reclaimed.
A client, server, or proxy MAY close the transport connection at any A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle" at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a closed while it was idle, but from the client's point of view, a
request is in progress. request is in progress.
A server SHOULD sustain persistent connections, when possible, and A server SHOULD sustain persistent connections, when possible, and
allow the underlying transport's flow control mechanisms to resolve allow the underlying transport's flow-control mechanisms to resolve
temporary overloads, rather than terminate connections with the temporary overloads, rather than terminate connections with the
expectation that clients will retry. The latter technique can expectation that clients will retry. The latter technique can
exacerbate network congestion. exacerbate network 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 response while it is transmitting the request. If the for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
6.6. 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
close the connection after reading the final response message MUST 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
close of the connection (see below) after it sends the final response close of the connection (see below) after it sends the final response
to the request that contained close. The server SHOULD send a close to the request that contained "close". The server SHOULD send a
connection option in its final response on that connection. The "close" connection option in its final response on that connection.
server MUST NOT process any further requests received on that The server MUST NOT process any further requests received on that
connection. connection.
A server that sends a close connection option MUST initiate a close A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing of the connection (see below) after it sends the response containing
close. The server MUST NOT process any further requests received on "close". The server MUST NOT process any further requests received
that connection. 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 NOT requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server. assume that they will be processed by the server.
If a server performs an immediate close of a TCP connection, there is If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the HTTP response. If the server receives additional data from the
client on a fully-closed connection, such as another request that was client on a fully closed connection, such as another request that was
sent by the client before receiving the server's response, the sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client; server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser. by the client's HTTP parser.
To avoid the TCP reset problem, servers typically close a connection To avoid the TCP reset problem, servers typically close a connection
in stages. First, the server performs a half-close by closing only in stages. First, the server performs a half-close by closing only
the write side of the read/write connection. The server then the write side of the read/write connection. The server then
continues to read from the connection until it receives a continues to read from the connection until it receives a
skipping to change at page 57, line 31 skipping to change at page 57, line 20
The following is a hypothetical example sent by a client: The following is a hypothetical example sent by a client:
GET /hello.txt HTTP/1.1 GET /hello.txt HTTP/1.1
Host: www.example.com Host: www.example.com
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The capabilities and nature of the application-level communication The capabilities and nature of the application-level communication
after the protocol change is entirely dependent upon the new after the protocol change is entirely dependent upon the new
protocol(s) chosen. However, immediately after sending the 101 protocol(s) chosen. However, immediately after sending the 101
response, the server is expected to continue responding to the (Switching Protocols) response, the server is expected to continue
original request as if it had received its equivalent within the new responding to the original request as if it had received its
protocol (i.e., the server still has an outstanding request to equivalent within the new protocol (i.e., the server still has an
satisfy after the protocol has been changed, and is expected to do so outstanding request to satisfy after the protocol has been changed,
without requiring the request to be repeated). and is expected to do so without requiring the request to be
repeated).
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, it first responds with a and the server decides to switch protocols, it first responds with a
101 (Switching Protocols) message in HTTP/1.1 and then immediately 101 (Switching Protocols) message in HTTP/1.1 and then immediately
follows that with the new protocol's equivalent of a response to a follows that with the new protocol's equivalent of a response to a
GET on the target resource. This allows a connection to be upgraded GET on the target resource. This allows a connection to be upgraded
to protocols with the same semantics as HTTP without the latency cost to protocols with the same semantics as HTTP without the latency cost
of an additional round-trip. A server MUST NOT switch protocols of an additional round trip. A server MUST NOT switch protocols
unless the received message semantics can be honored by the new unless the received message semantics can be honored by the new
protocol; an OPTIONS request can be honored by any protocol. protocol; an OPTIONS request can be honored by any protocol.
The following is an example response to the above hypothetical The following is an example response to the above hypothetical
request: request:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: upgrade Connection: upgrade
Upgrade: HTTP/2.0 Upgrade: HTTP/2.0
skipping to change at page 58, line 25 skipping to change at page 58, line 9
When Upgrade is sent, the sender MUST also send a Connection header When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.1) that contains an "upgrade" connection option, in field (Section 6.1) that contains an "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.
A client cannot begin using an upgraded protocol on the connection A client cannot begin using an upgraded protocol on the connection
until it has completely sent the request message (i.e., the client until it has completely sent the request message (i.e., the client
can't change the protocol it is sending in the middle of a message). can't change the protocol it is sending in the middle of a message).
If a server receives both Upgrade and an Expect header field with the If a server receives both an Upgrade and an Expect header field with
"100-continue" expectation (Section 5.1.1 of [Part2]), the server the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
MUST send a 100 (Continue) response before sending a 101 (Switching server MUST send a 100 (Continue) response before sending a 101
Protocols) response. (Switching Protocols) response.
The Upgrade header field only applies to switching protocols on top The Upgrade header field only applies to switching protocols on top
of the existing connection; it cannot be used to switch the of the existing connection; it cannot be used to switch the
underlying connection (transport) protocol, nor to switch the underlying connection (transport) protocol, nor to switch the
existing communication to a different connection. For those existing communication to a different connection. For those
purposes, it is more appropriate to use a 3xx (Redirection) response purposes, it is more appropriate to use a 3xx (Redirection) response
(Section 6.4 of [Part2]). (Section 6.4 of [RFC7231]).
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 ought to be registered with IANA specification. Additional tokens ought to be registered with IANA
using the registration procedure defined in Section 8.6. using the registration procedure defined in Section 8.6.
7. ABNF list extension: #rule 7. 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).
In any production that uses the list construct, a sender MUST NOT In any production that uses the list construct, a sender MUST NOT
skipping to change at page 59, line 22 skipping to change at page 59, line 6
#element => [ 1#element ] #element => [ 1#element ]
and for n >= 1 and m > 1: and for n >= 1 and m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
For compatibility with legacy list rules, a recipient MUST parse and For compatibility with legacy list rules, a recipient MUST parse and
ignore a reasonable number of empty list elements: enough to handle ignore a reasonable number of empty list elements: enough to handle
common mistakes by senders that merge values, but not so much that common mistakes by senders that merge values, but not so much that
they could be used as a denial of service mechanism. In other words, they could be used as a denial-of-service mechanism. In other words,
a recipient MUST accept lists that satisfy the following syntax: a recipient MUST accept lists that satisfy the following syntax:
#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
Empty elements do not contribute to the count of elements present. Empty elements do not contribute to the count of elements present.
For example, given these ABNF productions: For example, given these ABNF productions:
example-list = 1#example-list-elmt example-list = 1#example-list-elmt
skipping to change at page 60, line 9 skipping to change at page 59, line 40
"," ","
", ," ", ,"
Appendix B shows the collected ABNF for recipients after the list Appendix B shows the collected ABNF for recipients after the list
constructs have been expanded. constructs have been expanded.
8. IANA Considerations 8. IANA Considerations
8.1. Header Field Registration 8.1. Header Field Registration
HTTP header fields are registered within the Message Header Field HTTP header fields are registered within the "Message Headers"
Registry maintained at registry maintained at
<http://www.iana.org/assignments/message-headers/>. <http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so the
associated registry entries shall be updated according to the "Permanent Message Header Field Names" registry has been updated
permanent registrations below (see [BCP90]): accordingly (see [BCP90]).
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
| 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.4 | | Trailer | http | standard | Section 4.4 |
| Transfer-Encoding | http | standard | Section 3.3.1 | | Transfer-Encoding | http | standard | Section 3.3.1 |
| Upgrade | http | standard | Section 6.7 | | Upgrade | http | standard | Section 6.7 |
| Via | http | standard | Section 5.7.1 | | Via | http | standard | Section 5.7.1 |
+-------------------+----------+----------+---------------+ +-------------------+----------+----------+---------------+
Furthermore, the header field-name "Close" shall be registered as Furthermore, the header field-name "Close" has been 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
header field (Section 6.1). field (Section 6.1).
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Close | http | reserved | Section 8.1 | | Close | http | reserved | Section 8.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".
8.2. URI Scheme Registration 8.2. URI Scheme Registration
IANA maintains the registry of URI Schemes [BCP115] at IANA maintains the registry of URI Schemes [BCP115] at
<http://www.iana.org/assignments/uri-schemes/>. <http://www.iana.org/assignments/uri-schemes/>.
This document defines the following URI schemes, so their associated This document defines the following URI schemes, so the "Permanent
registry entries shall be updated according to the permanent URI Schemes" registry has been updated accordingly.
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 |
+------------+------------------------------------+---------------+ +------------+------------------------------------+---------------+
8.3. Internet Media Type Registration 8.3. Internet Media Type Registration
IANA maintains the registry of Internet media types [BCP13] at IANA maintains the registry of Internet media types [BCP13] at
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
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 has been
registered with IANA. registered with IANA.
8.3.1. Internet Media Type message/http 8.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
skipping to change at page 62, line 17 skipping to change at page 62, line 4
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors Section. See Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors Section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
8.3.2. Internet Media Type application/http 8.3.2. Internet Media Type application/http
The application/http type can be used to enclose a pipeline of one or The application/http type can be used to enclose a pipeline of one or
more HTTP request or response messages (not intermixed). more HTTP request or response messages (not intermixed).
Type name: application Type name: application
skipping to change at page 63, line 7 skipping to change at page 62, line 40
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
"1.1"). If not present, the version can be determined from the "1.1"). If not present, the version can be determined from the
first line of the body. first line of the body.
msgtype: The message type -- "request" or "response". If not msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first line of the present, the type can be determined from the first line of the
body. body.
Encoding considerations: HTTP messages enclosed by this type are in Encoding considerations: HTTP messages enclosed by this type are in
"binary" format; use of an appropriate Content-Transfer-Encoding "binary" format; use of an appropriate Content-Transfer-Encoding
is required when transmitted via E-mail. is required when transmitted via email.
Security considerations: see Section 9 Security considerations: see Section 9
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: This specification (see Section 8.3.2). Published specification: This specification (see Section 8.3.2).
Applications that use this media type: N/A Applications that use this media type: N/A
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): N/A File extension(s): N/A
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Person and email address to contact for further information:
Authors Section. See Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors Section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
8.4. Transfer Coding Registry 8.4. Transfer Coding Registry
The HTTP Transfer Coding Registry defines the name space for transfer The "HTTP Transfer Coding Registry" defines the namespace for
coding names. It is maintained at transfer coding names. It is maintained at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.4.1. Procedure
Registrations MUST include the following fields: Registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of transfer codings MUST NOT overlap with names of content Names of transfer codings MUST NOT overlap with names of content
codings (Section 3.1.2.1 of [Part2]) unless the encoding codings (Section 3.1.2.1 of [RFC7231]) unless the encoding
transformation is identical, as is the case for the compression transformation is identical, as is the case for the compression
codings defined in Section 4.2. codings defined in Section 4.2.
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see Section
Section 4.1 of [RFC5226]), and MUST conform to the purpose of 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
transfer coding defined in this specification. defined in this specification.
Use of program names for the identification of encoding formats is Use of program names for the identification of encoding formats is
not desirable and is discouraged for future encodings. not desirable and is discouraged for future encodings.
8.4.2. Registration 8.4.2. Registration
The HTTP Transfer Coding Registry shall be updated with the The "HTTP Transfer Coding Registry" has been 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" data format [Welch] | Section 4.2.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | | | | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 | | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 | | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
8.5. Content Coding Registration 8.5. Content Coding Registration
IANA maintains the registry of HTTP Content Codings at IANA maintains the "HTTP Content Coding Registry" at
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
The HTTP Content Codings Registry shall be updated with the The "HTTP Content Coding Registry" has been updated with the
registrations below: registrations below:
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
| deflate | "deflate" compressed data | Section 4.2.2 | | deflate | "deflate" compressed data | Section 4.2.2 |
| | ([RFC1951]) inside the "zlib" data | | | | ([RFC1951]) inside the "zlib" data | |
| | format ([RFC1950]) | | | | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 | | gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 | | x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
+------------+--------------------------------------+---------------+ +------------+--------------------------------------+---------------+
8.6. Upgrade Token Registry 8.6. Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for protocol- The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
name tokens used to identify protocols in the Upgrade header field. defines the namespace for protocol-name tokens used to identify
The registry is maintained at protocols in the Upgrade header field. The registry is maintained at
<http://www.iana.org/assignments/http-upgrade-tokens>. <http://www.iana.org/assignments/http-upgrade-tokens>.
8.6.1. Procedure 8.6.1. Procedure
Each registered protocol name is associated with contact information Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection and an optional set of specifications that details how the connection
will be processed after it has been upgraded. will be processed after it has been upgraded.
Registrations happen on a "First Come First Served" basis (see Registrations happen on a "First Come First Served" basis (see
Section 4.1 of [RFC5226]) and are subject to the following rules: Section 4.1 of [RFC5226]) and are subject to the following rules:
skipping to change at page 66, line 10 skipping to change at page 65, line 40
7. The IESG MAY reassign responsibility for a protocol token. This 7. The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party will normally only be used in the case when a responsible party
cannot be contacted. cannot be contacted.
This registration procedure for HTTP Upgrade Tokens replaces that This registration procedure for HTTP Upgrade Tokens replaces that
previously defined in Section 7.2 of [RFC2817]. previously defined in Section 7.2 of [RFC2817].
8.6.2. Upgrade Token Registration 8.6.2. Upgrade Token Registration
The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated The "HTTP" entry in the upgrade token registry has been updated with
with the registration below: the registration below:
+-------+----------------------+----------------------+-------------+ +-------+----------------------+----------------------+-------------+
| Value | Description | Expected Version | Reference | | Value | Description | Expected Version | Reference |
| | | Tokens | | | | | Tokens | |
+-------+----------------------+----------------------+-------------+ +-------+----------------------+----------------------+-------------+
| 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".
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security considerations relevant to HTTP message and users of known security considerations relevant to HTTP message
syntax, parsing, and routing. Security considerations about HTTP syntax, parsing, and routing. Security considerations about HTTP
semantics and payloads are addressed in [Part2]. semantics and payloads are addressed in [RFC7231].
9.1. Establishing Authority 9.1. Establishing Authority
HTTP relies on the notion of an "authoritative response": a response HTTP relies on the notion of an "authoritative response": a response
that has been determined by (or at the direction of) the authority that has been determined by (or at the direction of) the authority
identified within the target URI to be the most appropriate response identified within the target URI to be the most appropriate response
for that request given the state of the target resource at the time for that request given the state of the target resource at the time
of response message origination. Providing a response from a non- of response message origination. Providing a response from a non-
authoritative source, such as a shared cache, is often useful to authoritative source, such as a shared cache, is often useful to
improve performance and availability, but only to the extent that the improve performance and availability, but only to the extent that the
skipping to change at page 67, line 13 skipping to change at page 66, line 42
unknown or untrusted source. unknown or untrusted source.
When a registered name is used in the authority component, the "http" When a registered name is used in the authority component, the "http"
URI scheme (Section 2.7.1) relies on the user's local name resolution URI scheme (Section 2.7.1) relies on the user's local name resolution
service to determine where it can find authoritative responses. This service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names, means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address obtains resolution results, could impact the authenticity of address
mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
improve authenticity.
Furthermore, after an IP address is obtained, establishing authority Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol for an "http" URI is vulnerable to attacks on Internet Protocol
routing. routing.
The "https" scheme (Section 2.7.2) is intended to prevent (or at The "https" scheme (Section 2.7.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity the client properly verifies that the communicating server's identity
matches the target URI's authority component (see [RFC2818]). matches the target URI's authority component (see [RFC2818]).
Correctly implementing such verification can be difficult (see Correctly implementing such verification can be difficult (see
[Georgiev]). [Georgiev]).
9.2. Risks of Intermediaries 9.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle, and By their very nature, HTTP intermediaries are men-in-the-middle and,
thus represent an opportunity for man-in-the-middle attacks. thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about access to security-related information, personal information about
individual users and organizations, and proprietary information individual users and organizations, and proprietary information
belonging to users and content providers. A compromised belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks. commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable Intermediaries that contain a shared cache are especially vulnerable
to cache poisoning attacks, as described in Section 8 of [Part6]. to cache poisoning attacks, as described in Section 8 of [RFC7234].
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.
9.3. Attacks via Protocol Element Length 9.3. Attacks via Protocol Element Length
skipping to change at page 68, line 20 skipping to change at page 67, line 47
expecting a protocol element with no predefined length. expecting a protocol element with no predefined length.
To promote interoperability, specific recommendations are made for To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3.1.1) and header fields minimum size limits on request-line (Section 3.1.1) and header fields
(Section 3.2). These are minimum recommendations, chosen to be (Section 3.2). These are minimum recommendations, chosen to be
supportable even by implementations with limited resources; it is supportable even by implementations with limited resources; it is
expected that most implementations will choose substantially higher expected that most implementations will choose substantially higher
limits. limits.
A server can reject a message that has a request-target that is too A server can reject a message that has a request-target that is too
long (Section 6.5.12 of [Part2]) or a request payload that is too long (Section 6.5.12 of [RFC7231]) or a request payload that is too
large (Section 6.5.11 of [Part2]). Additional status codes related large (Section 6.5.11 of [RFC7231]). Additional status codes related
to capacity limits have been defined by extensions to HTTP [RFC6585]. to capacity limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values, methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to buffer overflows, arithmetic overflows, or increased vulnerability to
denial of service attacks. denial-of-service attacks.
9.4. Response Splitting 9.4. Response Splitting
Response splitting (a.k.a, CRLF injection) is a common technique, Response splitting (a.k.a, CRLF injection) is a common technique,
used in various attacks on Web usage, that exploits the line-based used in various attacks on Web usage, that exploits the line-based
nature of HTTP message framing and the ordered association of nature of HTTP message framing and the ordered association of
requests to responses on persistent connections [Klein]. This requests to responses on persistent connections [Klein]. This
technique can be particularly damaging when the requests pass through technique can be particularly damaging when the requests pass through
a shared cache. a shared cache.
skipping to change at page 70, line 39 skipping to change at page 70, line 20
A server is in the position to save personal data about a user's A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction, intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users. across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis. securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries Anonymization of personal information within individual entries
helps, but is generally not sufficient to prevent real log traces helps, but it is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous. client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and user- information, including user identifiers, IP addresses, and user-
provided query parameters, as soon as that information is no longer provided query parameters, as soon as that information is no longer
necessary to support operational needs for security, auditing, or necessary to support operational needs for security, auditing, or
fraud control. fraud control.
10. Acknowledgments 10. Acknowledgments
This edition of HTTP/1.1 builds on the many contributions that went This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and substantial contributions made by the previous authors, editors, and
working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as working and Paul J. Leach. Mark Nottingham oversaw this effort as Working
group chair. 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, Adrian Cole, Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,
Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek
Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
skipping to change at page 72, line 50 skipping to change at page 72, line 29
Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
editor team), Zed A. Shaw, and Zhong Yu. editor team), Zed A. Shaw, and Zhong Yu.
See Section 16 of [RFC2616] for additional acknowledgements from See Section 16 of [RFC2616] for additional acknowledgements from
prior revisions. prior revisions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-26 (work in progress),
February 2014.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-26 (work in
progress), February 2014.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-26 (work in
progress), February 2014.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-26 (work in progress),
February 2014.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-26 (work in progress),
February 2014.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[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
skipping to change at page 73, line 51 skipping to change at page 73, line 5
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[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.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-latest (work in
progress), June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in
progress), June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-latest (work in
progress), June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress),
June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-latest (work in progress),
June 2014.
[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.
[Welch] Welch, T., "A Technique for High Performance Data [Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984. Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References 11.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
and Registration Procedures for New URI Schemes", and Registration Procedures for New URI Schemes",
BCP 115, RFC 4395, February 2006. BCP 115, RFC 4395, February 2006.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
skipping to change at page 76, line 27 skipping to change at page 76, line 5
HTTP has been in use since 1990. The first version, later referred HTTP has been in use since 1990. The first version, later referred
to as HTTP/0.9, was a simple protocol for hypertext data transfer to as HTTP/0.9, was a simple protocol for hypertext data transfer
across the Internet, using only a single request method (GET) and no across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics. transferred and modifiers placed on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of connections, or name-based virtual hosts. The proliferation of
incompletely-implemented applications calling themselves "HTTP/1.0" incompletely implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two further necessitated a protocol version change in order for two
communicating applications to determine each other's true communicating applications to determine each other's true
capabilities. capabilities.
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient features that can either be safely ignored by an HTTP/1.0 recipient
or only sent when communicating with a party advertising conformance or only be sent when communicating with a party advertising
with HTTP/1.1. conformance with HTTP/1.1.
HTTP/1.1 has been designed to make supporting previous versions easy. HTTP/1.1 has been designed to make supporting previous versions easy.
A general-purpose HTTP/1.1 server ought to be able to understand any A general-purpose HTTP/1.1 server ought to be able to understand any
valid request in the format of HTTP/1.0, responding appropriately valid request in the format of HTTP/1.0, responding appropriately
with an HTTP/1.1 message that only uses features understood (or with an HTTP/1.1 message that only uses features understood (or
safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client
can be expected to understand any valid HTTP/1.0 response. can be expected to understand any valid HTTP/1.0 response.
Since HTTP/0.9 did not support header fields in a request, there is Since HTTP/0.9 did not support header fields in a request, there is
no mechanism for it to support name-based virtual hosts (selection of no mechanism for it to support name-based virtual hosts (selection of
skipping to change at page 77, line 10 skipping to change at page 76, line 36
implements name-based virtual hosts ought to disable support for implements name-based virtual hosts ought to disable support for
HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
badly constructed HTTP/1.x requests caused by a client failing to badly constructed HTTP/1.x requests caused by a client failing to
properly encode the request-target. properly encode the request-target.
A.1. Changes from HTTP/1.0 A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0 This section summarizes major differences between versions HTTP/1.0
and HTTP/1.1. and HTTP/1.1.
A.1.1. Multi-homed Web Servers A.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header The requirements that clients and servers support the Host header
field (Section 5.4), report an error if it is missing from an field (Section 5.4), report an error if it is missing from an
HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among
the most important changes defined by HTTP/1.1. the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was to which that request was directed. The Host header field was
skipping to change at page 78, line 23 skipping to change at page 77, line 49
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to (Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over 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
HTTP's approach to error handling has been explained. (Section 2.5) HTTP's approach to error handling has been explained. (Section 2.5)
The HTTP-version ABNF production has been clarified to be case- The HTTP-version ABNF production has been clarified to be case-
sensitive. Additionally, version numbers has been restricted to sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6) handle multi-digit version numbers incorrectly. (Section 2.6)
Userinfo (i.e., username and password) are now disallowed in HTTP and Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1) on the wire. (Section 2.7.1)
The HTTPS URI scheme is now defined by this specification; The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it
implies end-to-end security. (Section 2.7.2) implies end-to-end security. (Section 2.7.2)
HTTP messages can be (and often are) buffered by implementations; HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is despite it sometimes being available as a stream, HTTP is
skipping to change at page 79, line 4 skipping to change at page 78, line 29
because accepting it represents a security vulnerability. The ABNF because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value. productions defining header fields now only list the field value.
(Section 3.2) (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.3) specifically defined in the ABNF. (Section 3.2.3)
Header fields that span multiple lines ("line folding") are Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4) deprecated. (Section 3.2.4)
The NUL octet is no longer allowed in comment and quoted-string text, The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-ASCII content in header fields and the reason phrase than HTAB. Non-US-ASCII content in header fields and the reason
has been obsoleted and made opaque (the TEXT rule was removed). phrase has been obsoleted and made opaque (the TEXT rule was
(Section 3.2.6) removed). (Section 3.2.6)
Bogus "Content-Length" header fields are now required to be handled Bogus Content-Length header fields are now required to be handled as
as errors by recipients. (Section 3.3.2) errors by recipients. (Section 3.3.2)
The algorithm for determining the message body length has been The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection. longer a way of determining message body length detection.
(Section 3.3.3) (Section 3.3.3)
The "identity" transfer coding token has been removed. (Sections 3.3 The "identity" transfer coding token has been removed. (Sections 3.3
skipping to change at page 80, line 49 skipping to change at page 80, line 28
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
RWS = 1*( SP / HTAB ) RWS = 1*( SP / HTAB )
TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
transfer-coding ] ) transfer-coding ] )
URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> URI-reference = <URI-reference, see [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, see [RFC3986], Section 4.3>
absolute-form = absolute-URI absolute-form = absolute-URI
absolute-path = 1*( "/" segment ) absolute-path = 1*( "/" segment )
asterisk-form = "*" asterisk-form = "*"
authority = <authority, defined in [RFC3986], Section 3.2> authority = <authority, see [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-string chunk-ext-val = token / quoted-string
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-pair / comment ) ")" comment = "(" *( ctext / quoted-pair / comment ) ")"
connection-option = token connection-option = token
ctext = HTAB / SP / %x21-27 ; '!'-''' ctext = HTAB / SP / %x21-27 ; '!'-'''
/ %x2A-5B ; '*'-'[' / %x2A-5B ; '*'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-name = token field-name = token
field-value = *( field-content / obs-fold ) field-value = *( field-content / obs-fold )
field-vchar = VCHAR / obs-text field-vchar = VCHAR / obs-text
fragment = <fragment, defined in [RFC3986], Section 3.5> fragment = <fragment, see [RFC3986], Section 3.5>
header-field = field-name ":" OWS field-value OWS header-field = field-name ":" OWS field-value OWS
http-URI = "http://" authority path-abempty [ "?" query ] [ "#" http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
fragment ] fragment ]
https-URI = "https://" authority path-abempty [ "?" query ] [ "#" https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
fragment ] fragment ]
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 1*( SP / HTAB ) obs-fold = CRLF 1*( SP / HTAB )
obs-text = %x80-FF obs-text = %x80-FF
origin-form = absolute-path [ "?" 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, see [RFC3986], Section 3.3>
port = <port, defined in [RFC3986], Section 3.2.3> port = <port, see [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 = HTAB / SP / "!" / %x23-5B ; '#'-'[' qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
/ %x5D-7E ; ']'-'~' / %x5D-7E ; ']'-'~'
/ obs-text / obs-text
query = <query, defined in [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
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, see [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
scheme = <scheme, defined in [RFC3986], Section 3.1> scheme = <scheme, see [RFC3986], Section 3.1>
segment = <segment, defined in [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
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
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 = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
uri-host = <host, defined in [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Appendix C. Change Log (to be removed by RFC Editor before publication)
C.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in <http://
trac.tools.ietf.org/html/
draft-ietf-httpbis-p1-messaging-24#appendix-C>.
C.2. Since draft-ietf-httpbis-p1-messaging-24
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR
review of draft-ietf-httpbis-p1-messaging-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
parsing"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
registrations to correct draft"
C.3. Since draft-ietf-httpbis-p1-messaging-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/526>: "check media
type registration templates"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/528>: "Redundant
rule quoted-str-nf"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/531>: "IESG ballot
on draft-ietf-httpbis-p1-messaging-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/540>: "clarify ABNF
layering"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/541>: "use of 'word'
ABNF production"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/544>: "moving 2616/
2068/2145 to historic"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/551>:
"intermediaries handling trailers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/552>: "allow privacy
proxies to be conformant"
Index Index
A A
absolute-form (of request-target) 42 absolute-form (of request-target) 41
accelerator 10 accelerator 10
application/http Media Type 62 application/http Media Type 62
asterisk-form (of request-target) 42 asterisk-form (of request-target) 42
authoritative response 66 authoritative response 66
authority-form (of request-target) 42 authority-form (of request-target) 42
B B
browser 7 browser 7
C C
cache 11 cache 11
cacheable 11 cacheable 11
captive portal 11 captive portal 11
chunked (Coding Format) 28, 31, 35 chunked (Coding Format) 28, 31, 35
client 7 client 7
close 50, 55 close 50, 55
compress (Coding Format) 38 compress (Coding Format) 38
connection 7 connection 7
Connection header field 50, 55 Connection header field 50, 55
Content-Length header field 30 Content-Length header field 29
D D
deflate (Coding Format) 38 deflate (Coding Format) 38
Delimiters 26 Delimiters 26
downstream 9 downstream 9
E E
effective request URI 44 effective request URI 44
G G
gateway 10 gateway 10
Grammar Grammar
absolute-form 41-42 absolute-form 41
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
ALPHA 6 ALPHA 6
asterisk-form 41-42 asterisk-form 41-42
authority 16 authority 16
authority-form 41-42 authority-form 41-42
BWS 24 BWS 24
chunk 35 chunk 35
chunk-data 35 chunk-data 35
chunk-ext 35-36 chunk-ext 35-36
chunk-ext-name 36 chunk-ext-name 36
chunk-ext-val 36 chunk-ext-val 36
chunk-size 35 chunk-size 35
chunked-body 35-36 chunked-body 35-36
comment 27 comment 27
Connection 51 Connection 50
connection-option 51 connection-option 50
Content-Length 30 Content-Length 29
CR 6 CR 6
CRLF 6 CRLF 6
ctext 27 ctext 27
CTL 6 CTL 6
DIGIT 6 DIGIT 6
DQUOTE 6 DQUOTE 6
field-content 22 field-content 22
field-name 22, 39 field-name 22, 39
field-value 22 field-value 22
field-vchar 22 field-vchar 22
skipping to change at page 86, line 19 skipping to change at page 84, line 38
request-target 41 request-target 41
RWS 24 RWS 24
scheme 16 scheme 16
segment 16 segment 16
SP 6 SP 6
start-line 20 start-line 20
status-code 22 status-code 22
status-line 22 status-line 22
t-codings 38 t-codings 38
t-ranking 38 t-ranking 38
tchar 27 tchar 26
TE 38 TE 38
token 27 token 26
Trailer 39 Trailer 39
trailer-part 35-36 trailer-part 35-36
transfer-coding 35 transfer-coding 35
Transfer-Encoding 28 Transfer-Encoding 28
transfer-extension 35 transfer-extension 35
transfer-parameter 35 transfer-parameter 35
Upgrade 56 Upgrade 56
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
VCHAR 6 VCHAR 6
skipping to change at page 88, line 4 skipping to change at page 86, line 24
U U
Upgrade header field 56 Upgrade header field 56
upstream 9 upstream 9
URI scheme URI scheme
http 16 http 16
https 18 https 18
user agent 7 user agent 7
V V
Via header field 47 Via header field 46
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. 194 change blocks. 
359 lines changed or deleted 303 lines changed or added

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