p1-messaging.unpg.txt   rfc7230.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7230 Adobe
Obsoletes: 2145, 2616 J. Reschke, Ed. Obsoletes: 2145, 2616 J. Reschke, Ed.
(if approved) greenbytes Updates: 2817, 2818 greenbytes
Updates: 2817, 2818 (if approved) June 6, 2014 Category: Standards Track June 2014
Intended status: Standards Track ISSN: 2070-1721
Expires: December 8, 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-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.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 8, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7230.
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 38 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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. Requirements 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 ....................................17
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 .............................27
3.2.6. Field Value Components . . . . . . . . . . . . . . . . 26 3.3. Message Body ..............................................28
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 ................................32
3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 3.4. Handling Incomplete Messages ..............................34
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 ...................................36
4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 4.1.1. Chunk Extensions ...................................36
4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 4.1.2. Chunked Trailer Part ...............................37
4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 4.1.3. Decoding Chunked ...................................38
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 ........................................39
4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 4.3. TE ........................................................39
4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Trailer ...................................................40
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 ........................................41
5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 5.3. Request Target ............................................41
5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 5.3.1. origin-form ........................................42
5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 5.3.2. absolute-form ......................................42
5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 41 5.3.3. authority-form .....................................43
5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 5.3.4. asterisk-form ......................................43
5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 5.4. Host ......................................................44
5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.5. Effective Request URI .....................................45
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 ........................................47
5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 5.7.1. Via ................................................47
5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.7.2. Transformations ....................................49
5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 6. Connection Management ..........................................50
6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 6.1. Connection ................................................51
6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 6.2. Establishment .............................................52
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 .........................................54
6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 6.4. Concurrency ...............................................55
6.5. Failures and Timeouts .....................................55
6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 6.6. Tear-down .................................................56
6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54 6.7. Upgrade ...................................................57
6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 7. ABNF List Extension: #rule .....................................59
6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 8. IANA Considerations ............................................61
7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58 8.1. Header Field Registration .................................61
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 8.2. URI Scheme Registration ...................................62
8.1. Header Field Registration . . . . . . . . . . . . . . . . 59 8.3. Internet Media Type Registration ..........................62
8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 8.3.1. Internet Media Type message/http ...................62
8.3. Internet Media Type Registration . . . . . . . . . . . . . 60 8.3.2. Internet Media Type application/http ...............63
8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 8.4. Transfer Coding Registry ..................................64
8.3.2. Internet Media Type application/http . . . . . . . . . 62 8.4.1. Procedure ..........................................65
8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 8.4.2. Registration .......................................65
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 8.5. Content Coding Registration ...............................66
8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 8.6. Upgrade Token Registry ....................................66
8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 8.6.1. Procedure ..........................................66
8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64 8.6.2. Upgrade Token Registration .........................67
8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 9. Security Considerations ........................................67
8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65 9.1. Establishing Authority ....................................67
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 9.2. Risks of Intermediaries ...................................68
9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 9.3. Attacks via Protocol Element Length .......................69
9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 9.4. Response Splitting ........................................69
9.3. Attacks via Protocol Element Length . . . . . . . . . . . 67 9.5. Request Smuggling .........................................70
9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 9.6. Message Integrity .........................................70
9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 9.7. Message Confidentiality ...................................71
9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 9.8. Privacy of Server Log Information .........................71
9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 69 10. Acknowledgments ...............................................72
9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 11. References ....................................................74
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 11.1. Normative References .....................................74
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11.2. Informative References ...................................75
11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 Appendix A. HTTP Version History ..................................78
11.2. Informative References . . . . . . . . . . . . . . . . . . 73 A.1. Changes from HTTP/1.0 ....................................78
Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 75 A.1.1. Multihomed Web Servers ............................78
A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 A.1.2. Keep-Alive Connections ............................79
A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 76 A.1.3. Introduction of Transfer-Encoding .................79
A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 A.2. Changes from RFC 2616 ....................................80
A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 77 Appendix B. Collected ABNF ........................................82
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 Index .............................................................85
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
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:
skipping to change at page 7, line 36 skipping to change at page 7, line 36
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 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of
[RFC7231] 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
(O). server (O).
request > request >
UA ======================================= O UA ======================================= O
< response < response
A client sends an HTTP request to a server in the form of a request A client sends an HTTP request to a server in the form of a request
message, beginning with a request-line that includes a method, URI, message, beginning with a request-line that includes a method, URI,
and protocol version (Section 3.1.1), followed by header fields and protocol version (Section 3.1.1), followed by header fields
containing request modifiers, client information, and representation containing request modifiers, client information, and representation
metadata (Section 3.2), an empty line to indicate the end of the metadata (Section 3.2), an empty line to indicate the end of the
skipping to change at page 12, line 47 skipping to change at page 13, line 4
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 that 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
name and field-value components, but then forward the header field field-name and field-value components, but then forward the header
without further parsing inside the field-value. field 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.
skipping to change at page 13, line 25 skipping to change at page 13, line 30
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
extensions to this specification, unless the recipient has determined extensions to this specification, unless the recipient has determined
(through experience or configuration) that the sender incorrectly (through experience or configuration) that the sender incorrectly
implements what is implied by those semantics. For example, an implements what is implied by those semantics. For example, an
origin server might disregard the contents of a received Accept- origin server might disregard the contents of a received
Encoding header field if inspection of the User-Agent header field Accept-Encoding header field if inspection of the User-Agent header
indicates a specific implementation version that is known to fail on field indicates a specific implementation version that is known to
receipt of certain content codings. fail on receipt of certain content codings.
Unless noted otherwise, a recipient MAY attempt to recover a usable Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to systems control client might consider any form of error recovery to
be dangerous. be dangerous.
skipping to change at page 14, line 45 skipping to change at page 14, line 50
version if their defined semantics allow them to be safely ignored by version if their defined semantics allow them to be safely ignored by
recipients that do not recognize them. Header field extensibility is recipients that do not recognize them. Header field extensibility is
discussed in Section 3.2.1. discussed in Section 3.2.1.
Intermediaries that process HTTP messages (i.e., all intermediaries Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they are not allowed to in forwarded messages. In other words, they are not allowed to
blindly forward the first line of an HTTP message without ensuring blindly forward the first line of an HTTP message without ensuring
that the protocol version in that message matches a version to which that the protocol version in that message matches a version to which
that intermediary is conformant for both the receiving and sending of that intermediary is conformant for both the receiving and sending of
messages. Forwarding an HTTP message without rewriting the HTTP- messages. Forwarding an HTTP message without rewriting the
version might result in communication errors when downstream HTTP-version might result in communication errors when downstream
recipients use the message sender's version to determine what recipients use the message sender's version to determine what
features are safe to use for later communication with that sender. features are safe to use for later communication with that sender.
A client SHOULD send a request version equal to the highest version A client SHOULD send a request version equal to the highest version
to which the client is conformant and whose major version is no to which the client is conformant and whose major version is no
higher than the highest version supported by the server, if this is higher than the highest version supported by the server, if this is
known. A client MUST NOT send a version to which it is not known. A client MUST NOT send a version to which it is not
conformant. conformant.
A client MAY send a lower request version if it is known that the A client MAY send a lower request version if it is known that the
skipping to change at page 16, line 40 skipping to change at page 16, line 44
path-abempty = <path-abempty, see [RFC3986], Section 3.3> path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3> segment = <segment, see [RFC3986], Section 3.3>
query = <query, see [RFC3986], Section 3.4> query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, see [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
URI), only the path and optional query components, or some (absolute-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.
skipping to change at page 19, line 20 skipping to change at page 19, line 29
algorithm defined in Section 6 of [RFC3986], using the defaults algorithm defined in Section 6 of [RFC3986], using the defaults
described above for each scheme. described above for each scheme.
If the port is equal to the default port for a scheme, the normal If the port is equal to the default port for a scheme, the normal
form is to omit the port subcomponent. When not being used in form is to omit the port subcomponent. When not being used in
absolute form as the request target of an OPTIONS request, an empty absolute form as the request target of an OPTIONS request, an empty
path component is equivalent to an absolute path of "/", so the path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead. The scheme and host normal form is to provide a path of "/" instead. The scheme and host
are case-insensitive and normally provided in lowercase; all other are case-insensitive and normally provided in lowercase; all other
components are compared in a case-sensitive manner. Characters other components are compared in a case-sensitive manner. Characters other
than those in the "reserved" set are equivalent to their percent- than those in the "reserved" set are equivalent to their
encoded octets: the normal form is to not encode them (see Sections percent-encoded octets: the normal form is to not encode them (see
2.1 and 2.2 of [RFC3986]). Sections 2.1 and 2.2 of [RFC3986]).
For example, the following three URIs are equivalent: For example, the following three URIs are equivalent:
http://example.com:80/~smith/home.html http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html http://EXAMPLE.com:/%7esmith/home.html
3. Message Format 3. Message Format
All HTTP/1.1 messages consist of a start-line followed by a sequence All HTTP/1.1 messages consist of a start-line followed by a sequence
skipping to change at page 21, line 39 skipping to change at page 21, line 47
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 predefined limit on the length of a request- HTTP does not place a predefined limit on the length of a
line, as described in Section 2.5. A server that receives a method request-line, as described in Section 2.5. A server that receives a
longer than any that it implements SHOULD respond with a 501 (Not method longer than any that it implements SHOULD respond with a 501
Implemented) status code. A server that receives a request-target (Not Implemented) status code. A server that receives a
longer than any URI it wishes to parse MUST respond with a 414 (URI request-target longer than any URI it wishes to parse MUST respond
Too Long) status code (see Section 6.5.12 of [RFC7231]). with a 414 (URI 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,
skipping to change at page 25, line 25 skipping to change at page 25, line 38
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 whitespace: 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
whitespace octet of the field value ought to be excluded by parsers non-whitespace octet of the field value ought to be excluded by
when extracting the field value from a header field. parsers 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
the obs-fold rule) unless the message is intended for packaging the obs-fold rule) unless the message is intended for packaging
within the message/http media type. within the message/http media type.
skipping to change at page 26, line 6 skipping to change at page 26, line 21
A proxy or gateway that receives an obs-fold in a response message A proxy or gateway that receives an obs-fold in a response message
that is not within a message/http container MUST either discard the that is not within a message/http container MUST either discard the
message and replace it with a 502 (Bad Gateway) response, preferably message and replace it with a 502 (Bad Gateway) response, preferably
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
fold with one or more SP octets prior to interpreting the field obs-fold with one or more SP octets prior to interpreting the field
value. value.
Historically, HTTP has allowed field content with text in the Historically, HTTP has allowed field content with text in the
ISO-8859-1 charset [ISO-8859-1], supporting other charsets only ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
through use of [RFC2047] encoding. In practice, most HTTP header through use of [RFC2047] encoding. In practice, most HTTP header
field values use only a subset of the US-ASCII charset [USASCII]. field values use only a subset of the US-ASCII charset [USASCII].
Newly defined header fields SHOULD limit their field values to Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data. content (obs-text) as opaque data.
skipping to change at page 27, line 42 skipping to change at page 28, line 17
The message body (if any) of an HTTP message is used to carry the The message body (if any) of an HTTP message is used to carry the
payload body of that request or response. The message body is payload body of that request or response. The message body is
identical to the payload body unless a transfer coding has been identical to the payload body unless a transfer coding has been
applied, as described in Section 3.3.1. applied, as described in Section 3.3.1.
message-body = *OCTET message-body = *OCTET
The rules for when a message body is allowed in a message differ for The rules for when a message body is allowed in a message differ for
requests and responses. requests and responses.
The presence of a message body in a request is signaled by a Content- The presence of a message body in a request is signaled by a
Length or Transfer-Encoding header field. Request message framing is Content-Length or Transfer-Encoding header field. Request message
independent of method semantics, even if the method does not define framing is independent of method semantics, even if the method does
any use for a message body. not define 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 [RFC7231]) 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 [RFC7231]). 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
[RFC7231]) switch to tunnel mode instead of having a message body. [RFC7231]) switch to tunnel mode instead of having a message body.
skipping to change at page 28, line 50 skipping to change at page 29, line 25
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 [RFC7231]), Transfer- Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
Encoding is a property of the message, not of the representation, and Transfer-Encoding is a property of the message, not of the
any recipient along the request/response chain MAY decode the representation, and any recipient along the request/response chain
received transfer coding(s) or apply additional transfer coding(s) to MAY decode the received transfer coding(s) or apply additional
the message body, assuming that corresponding changes are made to the transfer coding(s) to the message body, assuming that corresponding
Transfer-Encoding field-value. Additional information about the changes are made to the Transfer-Encoding field-value. Additional
encoding parameters can be provided by other header fields not information about the encoding parameters can be provided by other
defined by this specification. header fields not defined by this specification.
Transfer-Encoding MAY be sent in a response to a HEAD request or in a Transfer-Encoding MAY be sent in a response to a HEAD request or in a
304 (Not Modified) response (Section 4.1 of [RFC7232]) 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.
skipping to change at page 30, line 40 skipping to change at page 31, line 14
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
[RFC7231]). [RFC7231]).
Aside from the cases defined above, in the absence of Transfer- Aside from the cases defined above, in the absence of
Encoding, an origin server SHOULD send a Content-Length header field Transfer-Encoding, an origin server SHOULD send a Content-Length
when the payload body size is known prior to sending the complete header field when the payload body size is known prior to sending the
header section. This will allow downstream recipients to measure complete header section. This will allow downstream recipients to
transfer progress, know when a received message is complete, and measure transfer progress, know when a received message is complete,
potentially reuse the connection for additional requests. and potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is Any Content-Length field value greater than or equal to zero is
valid. Since there is no predefined limit to the length of a valid. Since there is no predefined limit to the length of a
payload, a recipient MUST anticipate potentially large decimal payload, a recipient MUST anticipate potentially large decimal
numerals and prevent parsing errors due to integer conversion numerals and prevent parsing errors due to integer conversion
overflows (Section 9.3). overflows (Section 9.3).
If a message is received that has multiple Content-Length header If a message is received that has multiple Content-Length header
fields with field-values consisting of the same decimal value, or a fields with field-values consisting of the same decimal value, or a
single Content-Length header field with a field value containing a single Content-Length header field with a field value containing a
list of identical decimal values (e.g., "Content-Length: 42, 42"), list of identical decimal values (e.g., "Content-Length: 42, 42"),
indicating that duplicate Content-Length header fields have been indicating that duplicate Content-Length header fields have been
generated or combined by an upstream message processor, then the generated or combined by an upstream message processor, then the
recipient MUST either reject the message as invalid or replace the recipient MUST either reject the message as invalid or replace the
duplicated field-values with a single valid Content-Length field duplicated field-values with a single valid Content-Length field
containing that decimal value prior to determining the message body containing that decimal value prior to determining the message body
length or forwarding the message. length or forwarding the message.
Note: HTTP's use of Content-Length for message framing differs Note: HTTP's use of Content-Length for message framing differs
significantly from the same field's use in MIME, where it is an significantly from the same field's use in MIME, where it is an
optional field used only within the "message/external-body" media- optional field used only within the "message/external-body"
type. media-type.
3.3.3. Message Body Length 3.3.3. Message Body Length
The length of a message body is determined by one of the following The length of a message body is determined by one of the following
(in order of precedence): (in order of precedence):
1. Any response to a HEAD request and any response with a 1xx 1. Any response to a HEAD request and any response with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status (Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the header fields, regardless of the header fields present in the
skipping to change at page 32, line 39 skipping to change at page 33, line 23
incomplete and close the connection. incomplete and close the connection.
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,
delimited message from a partially received message interrupted by close-delimited message from a partially received message interrupted
network failure, a server SHOULD generate encoding or length- by network failure, a server SHOULD generate encoding or
delimited messages whenever possible. The close-delimiting feature length-delimited messages whenever possible. The close-delimiting
exists primarily for backwards compatibility with HTTP/1.0. feature 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
in advance, rather than the chunked transfer coding, since some in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required) existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding. status code even though they understand the chunked transfer coding.
skipping to change at page 35, line 18 skipping to change at page 35, line 48
/ "gzip" ; Section 4.2.3 / "gzip" ; Section 4.2.3
/ transfer-extension / transfer-extension
transfer-extension = token *( OWS ";" OWS transfer-parameter ) transfer-extension = token *( OWS ";" OWS transfer-parameter )
Parameters are in the form of a name or name=value pair. Parameters are in the form of a name or name=value pair.
transfer-parameter = token BWS "=" BWS ( token / quoted-string ) transfer-parameter = token BWS "=" BWS ( token / quoted-string )
All transfer-coding names are case-insensitive and ought to be All transfer-coding names are case-insensitive and ought to be
registered within the HTTP Transfer Coding registry, as defined in registered within the HTTP Transfer Coding registry, as defined in
Section 8.4. They are used in the TE (Section 4.3) and Transfer- Section 8.4. They are used in the TE (Section 4.3) and
Encoding (Section 3.3.1) header fields. Transfer-Encoding (Section 3.3.1) header fields.
4.1. Chunked Transfer Coding 4.1. Chunked Transfer Coding
The chunked transfer coding wraps the payload body in order to The chunked transfer coding wraps the payload body in order to
transfer it as a series of chunks, each with its own size indicator, transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing header fields. Chunked followed by an OPTIONAL trailer containing header fields. Chunked
enables content streams of unknown size to be transferred as a enables content streams of unknown size to be transferred as a
sequence of length-delimited buffers, which enables the sender to sequence of length-delimited buffers, which enables the sender to
retain connection persistence and the recipient to know when it has retain connection persistence and the recipient to know when it has
received the entire message. received the entire message.
skipping to change at page 36, line 9 skipping to change at page 36, line 39
when a chunk with a chunk-size of zero is received, possibly followed when a chunk with a chunk-size of zero is received, possibly followed
by a trailer, and finally terminated by an empty line. by a trailer, and finally terminated by an empty line.
A recipient MUST be able to parse and decode the chunked transfer A recipient MUST be able to parse and decode the chunked transfer
coding. coding.
4.1.1. Chunk Extensions 4.1.1. Chunk Extensions
The chunked encoding allows each chunk to include zero or more chunk The chunked encoding allows each chunk to include zero or more chunk
extensions, immediately following the chunk-size, for the sake of extensions, immediately following the chunk-size, for the sake of
supplying per-chunk metadata (such as a signature or hash), mid- supplying per-chunk metadata (such as a signature or hash),
message control information, or randomization of message body size. mid-message control information, or randomization of message body
size.
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
The chunked encoding is specific to each connection and is likely to The chunked encoding is specific to each connection and is likely to
be removed or recoded by each recipient (including intermediaries) be removed or recoded by each recipient (including intermediaries)
before any higher-level application would have a chance to inspect before any higher-level application would have a chance to inspect
the extensions. Hence, use of chunk extensions is generally limited the extensions. Hence, use of chunk extensions is generally limited
skipping to change at page 40, line 7 skipping to change at page 40, line 41
5. Message Routing 5. Message Routing
HTTP request message routing is determined by each client based on HTTP request message routing is determined by each client based on
the target resource, the client's proxy configuration, and the target resource, the client's proxy configuration, and
establishment or reuse of an inbound connection. The corresponding establishment or reuse of an inbound connection. The corresponding
response routing follows the same connection chain back to the response routing follows the same connection chain back to the
client. client.
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
purpose computers to home appliances. In some cases, communication general-purpose computers to home appliances. In some cases,
options are hard-coded in a client's configuration. However, most communication options are hard-coded in a client's configuration.
HTTP clients rely on the same resource identification mechanism and However, most HTTP clients rely on the same resource identification
configuration techniques as general-purpose Web browsers. mechanism and 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 [RFC7231], 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).
skipping to change at page 43, line 48 skipping to change at page 44, line 37
<http://www.example.org/pub/WWW/> would begin with: <http://www.example.org/pub/WWW/> would begin with:
GET /pub/WWW/ HTTP/1.1 GET /pub/WWW/ HTTP/1.1
Host: www.example.org Host: www.example.org
A client MUST send a Host header field in an HTTP/1.1 request even if A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host. that might not have implemented Host.
When a proxy receives a request with an absolute-form of request- When a proxy receives a request with an absolute-form of
target, the proxy MUST ignore the received Host header field (if any) request-target, the proxy MUST ignore the received Host header field
and instead replace it with the host information of the request- (if any) and instead replace it with the host information of the
target. A proxy that forwards such a request MUST generate a new request-target. A proxy that forwards such a request MUST generate a
Host field-value based on the received request-target rather than new Host field-value based on the received request-target rather than
forward the received Host field-value. forward the received Host field-value.
Since the Host header field acts as an application-level routing Since the Host header field acts as an application-level routing
mechanism, it is a frequent target for malware seeking to poison a mechanism, it is a frequent target for malware seeking to poison a
shared cache or redirect a request to an unintended server. An shared cache or redirect a request to an unintended server. An
interception proxy is particularly vulnerable if it relies on the interception proxy is particularly vulnerable if it relies on the
Host field-value for redirecting requests to internal servers, or for Host field-value for redirecting requests to internal servers, or for
use as a cache key in a shared cache, without first verifying that use as a cache key in a shared cache, without first verifying that
the intercepted connection is targeting a valid IP address for that the intercepted connection is targeting a valid IP address for that
host. host.
skipping to change at page 46, line 18 skipping to change at page 47, line 8
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
[RFC7231]) 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
1xx) response. (non-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
roles in the processing of HTTP requests and responses. Some roles in the processing of HTTP requests and responses. Some
intermediaries are used to improve performance or availability. intermediaries are used to improve performance or availability.
Others are used for access control or to filter content. Since an Others are used for access control or to filter content. Since an
HTTP stream has characteristics similar to a pipe-and-filter HTTP stream has characteristics similar to a pipe-and-filter
architecture, there are no inherent limits to the extent an architecture, there are no inherent limits to the extent an
intermediary can enhance (or interfere) with either direction of the intermediary can enhance (or interfere) with either direction of the
skipping to change at page 52, line 50 skipping to change at page 54, line 8
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 [RFC7231]). A proxy MUST NOT automatically retry non- 4.2.2 of [RFC7231]). A proxy MUST NOT automatically retry
idempotent requests. non-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
from partial failure conditions by checking the target resource from partial failure conditions by checking the target resource
skipping to change at page 54, line 21 skipping to change at page 55, line 28
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
side processing and/or has a large payload blocks subsequent requests server-side processing and/or has a large payload blocks subsequent
on the same connection. However, each connection consumes server requests on the same connection. However, each connection consumes
resources. Furthermore, using multiple connections can cause server 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 Timeouts 6.5. Failures and Timeouts
Servers will usually have some timeout 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
skipping to change at page 58, line 32 skipping to change at page 59, line 48
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
delimited lists of elements. The full form is "<n>#<m>element" comma-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
generate empty list elements. In other words, a sender MUST generate generate empty list elements. In other words, a sender MUST generate
lists that satisfy the following syntax: lists that satisfy the following syntax:
1#element => element *( OWS "," OWS element ) 1#element => element *( OWS "," OWS element )
and: and:
skipping to change at page 66, line 18 skipping to change at page 67, line 45
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 [RFC7231]. 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
authoritative source, such as a shared cache, is often useful to non-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
source can be trusted or the distrusted response can be safely used. source can be trusted or the distrusted response can be safely used.
Unfortunately, establishing authority can be difficult. For example, Unfortunately, establishing authority can be difficult. For example,
phishing is an attack on the user's perception of authority, where phishing is an attack on the user's perception of authority, where
that perception can be misled by presenting similar branding in that perception can be misled by presenting similar branding in
hypertext, possibly aided by userinfo obfuscating the authority hypertext, possibly aided by userinfo obfuscating the authority
component (see Section 2.7.1). User agents can reduce the impact of component (see Section 2.7.1). User agents can reduce the impact of
phishing attacks by enabling users to easily inspect a target URI phishing attacks by enabling users to easily inspect a target URI
prior to making an action, by prominently distinguishing (or prior to making an action, by prominently distinguishing (or
skipping to change at page 69, line 22 skipping to change at page 70, line 48
usage. usage.
This specification has introduced new requirements on request This specification has introduced new requirements on request
parsing, particularly with regard to message framing in parsing, particularly with regard to message framing in
Section 3.3.3, to reduce the effectiveness of request smuggling. Section 3.3.3, to reduce the effectiveness of request smuggling.
9.6. Message Integrity 9.6. Message Integrity
HTTP does not define a specific mechanism for ensuring message HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or chunk- underlying transport protocols and the use of length or
delimited framing to detect completeness. Additional integrity chunk-delimited framing to detect completeness. Additional integrity
mechanisms, such as hash functions or digital signatures applied to mechanisms, such as hash functions or digital signatures applied to
the content, can be selectively added to messages via extensible the content, can be selectively added to messages via extensible
metadata header fields. Historically, the lack of a single integrity metadata header fields. Historically, the lack of a single integrity
mechanism has been justified by the informal nature of most HTTP mechanism has been justified by the informal nature of most HTTP
communication. However, the prevalence of HTTP as an information communication. However, the prevalence of HTTP as an information
access mechanism has resulted in its increasing use within access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial. environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those detecting and reporting failures of message integrity such that those
skipping to change at page 70, line 27 skipping to change at page 72, line 7
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 it 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
provided query parameters, as soon as that information is no longer user-provided query parameters, as soon as that information is no
necessary to support operational needs for security, auditing, or longer necessary to support operational needs for security, auditing,
fraud control. or 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.
skipping to change at page 73, line 7 skipping to change at page 74, line 35
[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 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content", Transfer Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-latest (work in RFC 7231, June 2014.
progress), June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in RFC 7232, June 2014.
progress), June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-latest (work in Requests", RFC 7233, June 2014.
progress), June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, June 2014.
June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-latest (work in progress), RFC 7235, June 2014.
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
skipping to change at page 77, line 31 skipping to change at page 79, line 41
hung connection. hung connection.
One attempted solution was the introduction of a Proxy-Connection One attempted solution was the introduction of a Proxy-Connection
header field, targeted specifically at proxies. In practice, this header field, targeted specifically at proxies. In practice, this
was also unworkable, because proxies are often deployed in multiple was also unworkable, because proxies are often deployed in multiple
layers, bringing about the same problem discussed above. layers, bringing about the same problem discussed above.
As a result, clients are encouraged not to send the Proxy-Connection As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests. header field in any requests.
Clients are also encouraged to consider the use of Connection: keep- Clients are also encouraged to consider the use of Connection:
alive in requests carefully; while they can enable persistent keep-alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them will need to connections with HTTP/1.0 servers, clients using them will need to
monitor the connection for "hung" requests (which indicate that the monitor the connection for "hung" requests (which indicate that the
client ought stop sending the header field), and this mechanism ought client ought stop sending the header field), and this mechanism ought
not be used by clients at all when a proxy is being used. not be used by clients at all when a proxy is being used.
A.1.3. Introduction of Transfer-Encoding A.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). 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.
skipping to change at page 79, line 11 skipping to change at page 81, line 20
and 4) and 4)
Chunk length does not include the count of the octets in the chunk Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed. header and trailer. Line folding in chunk extensions is disallowed.
(Section 4.1) (Section 4.1)
The meaning of the "deflate" content coding has been clarified. The meaning of the "deflate" content coding has been clarified.
(Section 4.2.2) (Section 4.2.2)
The segment + query components of RFC 3986 have been used to define The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The asterisk- the request-target, instead of abs_path from RFC 1808. The
form of the request-target is only allowed with the OPTIONS method. asterisk-form of the request-target is only allowed with the OPTIONS
(Section 5.3) method. (Section 5.3)
The term "Effective Request URI" has been introduced. (Section 5.5) The term "Effective Request URI" has been introduced. (Section 5.5)
Gateways do not need to generate Via header fields anymore. Gateways do not need to generate Via header fields anymore.
(Section 5.7.1) (Section 5.7.1)
Exactly when "close" connection options have to be sent has been Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop- in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1) by-hop in this specification doesn't exempt them. (Section 6.1)
skipping to change at page 82, line 29 skipping to change at page 85, line 8
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, see [RFC3986], Section 3.2.2> uri-host = <host, see [RFC3986], Section 3.2.2>
Index Index
A A
absolute-form (of request-target) 41 absolute-form (of request-target) 42
accelerator 10 accelerator 10
application/http Media Type 62 application/http Media Type 63
asterisk-form (of request-target) 42 asterisk-form (of request-target) 43
authoritative response 66 authoritative response 67
authority-form (of request-target) 42 authority-form (of request-target) 42-43
B B
browser 7 browser 7
C C
cache 11 cache 11
cacheable 11 cacheable 12
captive portal 11 captive portal 11
chunked (Coding Format) 28, 31, 35 chunked (Coding Format) 28, 32, 36
client 7 client 7
close 50, 55 close 51, 56
compress (Coding Format) 38 compress (Coding Format) 38
connection 7 connection 7
Connection header field 50, 55 Connection header field 51, 56
Content-Length header field 29 Content-Length header field 30
D D
deflate (Coding Format) 38 deflate (Coding Format) 38
Delimiters 26 Delimiters 27
downstream 9 downstream 10
E E
effective request URI 44 effective request URI 45
G G
gateway 10 gateway 10
Grammar Grammar
absolute-form 41 absolute-form 42
absolute-path 16 absolute-path 16
absolute-URI 16 absolute-URI 16
ALPHA 6 ALPHA 6
asterisk-form 41-42 asterisk-form 41, 43
authority 16 authority 16
authority-form 41-42 authority-form 42-43
BWS 24 BWS 25
chunk 35 chunk 36
chunk-data 35 chunk-data 36
chunk-ext 35-36 chunk-ext 36
chunk-ext-name 36 chunk-ext-name 36
chunk-ext-val 36 chunk-ext-val 36
chunk-size 35 chunk-size 36
chunked-body 35-36 chunked-body 36
comment 27 comment 27
Connection 50 Connection 51
connection-option 50 connection-option 51
Content-Length 29 Content-Length 30
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 23
field-name 22, 39 field-name 23, 40
field-value 22 field-value 23
field-vchar 22 field-vchar 23
fragment 16 fragment 16
header-field 22, 36 header-field 23, 37
HEXDIG 6 HEXDIG 6
Host 43 Host 44
HTAB 6 HTAB 6
HTTP-message 19 HTTP-message 19
HTTP-name 13 HTTP-name 14
http-URI 16 http-URI 17
HTTP-version 13 HTTP-version 14
https-URI 18 https-URI 18
last-chunk 35 last-chunk 36
LF 6 LF 6
message-body 27 message-body 28
method 21 method 21
obs-fold 22 obs-fold 23
obs-text 27 obs-text 27
OCTET 6 OCTET 6
origin-form 41 origin-form 42
OWS 24 OWS 25
partial-URI 16 partial-URI 16
port 16 port 16
protocol-name 47 protocol-name 47
protocol-version 47 protocol-version 47
pseudonym 47 pseudonym 47
qdtext 27 qdtext 27
query 16 query 16
quoted-pair 27 quoted-pair 27
quoted-string 27 quoted-string 27
rank 38 rank 39
reason-phrase 22 reason-phrase 22
received-by 47 received-by 47
received-protocol 47 received-protocol 47
request-line 21 request-line 21
request-target 41 request-target 41
RWS 24 RWS 25
scheme 16 scheme 16
segment 16 segment 16
SP 6 SP 6
start-line 20 start-line 21
status-code 22 status-code 22
status-line 22 status-line 22
t-codings 38 t-codings 39
t-ranking 38 t-ranking 39
tchar 26 tchar 27
TE 38 TE 39
token 26 token 27
Trailer 39 Trailer 40
trailer-part 35-36 trailer-part 37
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 57
uri-host 16 uri-host 16
URI-reference 16 URI-reference 16
VCHAR 6 VCHAR 6
Via 47 Via 47
gzip (Coding Format) 39
gzip (Coding Format) 38
H H
header field 19 header field 19
header section 19 header section 19
headers 19 headers 19
Host header field 43 Host header field 44
http URI scheme 16 http URI scheme 17
https URI scheme 18 https URI scheme 17
I I
inbound 9 inbound 9
interception proxy 11 interception proxy 11
intermediary 9 intermediary 9
M M
Media Type Media Type
application/http 62 application/http 63
message/http 61 message/http 62
message 7 message 7
message/http Media Type 61 message/http Media Type 62
method 21 method 21
N N
non-transforming proxy 48 non-transforming proxy 49
O O
origin server 7 origin server 7
origin-form (of request-target) 41 origin-form (of request-target) 42
outbound 9 outbound 10
P P
phishing 66 phishing 67
proxy 10 proxy 10
R R
recipient 7 recipient 7
request 7 request 7
request-target 21 request-target 21
resource 16 resource 16
response 7 response 7
reverse proxy 10 reverse proxy 10
S S
sender 7 sender 7
server 7 server 7
spider 7 spider 7
T T
target resource 40 target resource 40
target URI 40 target URI 40
TE header field 38 TE header field 39
Trailer header field 39 Trailer header field 40
Transfer-Encoding header field 28 Transfer-Encoding header field 28
transforming proxy 48 transforming proxy 49
transparent proxy 11 transparent proxy 11
tunnel 10 tunnel 10
U U
Upgrade header field 56 Upgrade header field 57
upstream 9 upstream 9
URI scheme URI scheme
http 16 http 17
https 18 https 17
user agent 7 user agent 7
V V
Via header field 46 Via header field 47
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. 78 change blocks. 
305 lines changed or deleted 280 lines changed or added

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