9. Security Considerations
This section is meant to inform developers, information providers,
and users of known security considerations relevant to HTTP message
syntax, parsing, and routing. Security considerations about HTTP
semantics and payloads are addressed in [RFC7231].
9.1. Establishing Authority
HTTP relies on the notion of an authoritative response: a response
that has been determined by (or at the direction of) the authority
identified within the target URI to be the most appropriate response
for that request given the state of the target resource at the time
of response message origination. Providing a response from a
non-authoritative source, such as a shared cache, is often useful to
improve performance and availability, but only to the extent that the
source can be trusted or the distrusted response can be safely used.
Unfortunately, establishing authority can be difficult. For example,
phishing is an attack on the user's perception of authority, where
that perception can be misled by presenting similar branding in
hypertext, possibly aided by userinfo obfuscating the authority
component (see Section 2.7.1). User agents can reduce the impact of
phishing attacks by enabling users to easily inspect a target URI
prior to making an action, by prominently distinguishing (or
rejecting) userinfo when present, and by not sending stored
credentials and cookies when the referring document is from an
unknown or untrusted source.
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
service to determine where it can find authoritative responses. This
means that any attack on a user's network host table, cached names,
or name resolution libraries becomes an avenue for attack on
establishing authority. Likewise, the user's choice of server for
Domain Name Service (DNS), and the hierarchy of servers from which it
obtains resolution results, could impact the authenticity of address
mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
Furthermore, after an IP address is obtained, establishing authority
for an "http" URI is vulnerable to attacks on Internet Protocol
The "https" scheme (Section 2.7.2) is intended to prevent (or at
least reveal) many of these potential attacks on establishing
authority, provided that the negotiated TLS connection is secured and
the client properly verifies that the communicating server's identity
matches the target URI's authority component (see [RFC2818]).
Correctly implementing such verification can be difficult (see
9.2. Risks of Intermediaries
By their very nature, HTTP intermediaries are men-in-the-middle and,
thus, represent an opportunity for man-in-the-middle attacks.
Compromise of the systems on which the intermediaries run can result
in serious security and privacy problems. Intermediaries might have
access to security-related information, personal information about
individual users and organizations, and proprietary information
belonging to users and content providers. A compromised
intermediary, or an intermediary implemented or configured without
regard to security and privacy considerations, might be used in the
commission of a wide range of potential attacks.
Intermediaries that contain a shared cache are especially vulnerable
to cache poisoning attacks, as described in Section 8 of [RFC7234].
Implementers need to consider the privacy and security implications
of their design and coding decisions, and of the configuration
options they provide to operators (especially the default
Users need to be aware that intermediaries are no more trustworthy
than the people who run them; HTTP itself cannot solve this problem.
9.3. Attacks via Protocol Element Length
Because HTTP uses mostly textual, character-delimited fields, parsers
are often vulnerable to attacks based on sending very long (or very
slow) streams of data, particularly where an implementation is
expecting a protocol element with no predefined length.
To promote interoperability, specific recommendations are made for
minimum size limits on request-line (Section 3.1.1) and header fields
(Section 3.2). These are minimum recommendations, chosen to be
supportable even by implementations with limited resources; it is
expected that most implementations will choose substantially higher
A server can reject a message that has a request-target that is too
long (Section 6.5.12 of [RFC7231]) or a request payload that is too
large (Section 6.5.11 of [RFC7231]). Additional status codes related
to capacity limits have been defined by extensions to HTTP [RFC6585].
Recipients ought to carefully limit the extent to which they process
other protocol elements, including (but not limited to) request
methods, response status phrases, header field-names, numeric values,
and body chunks. Failure to limit such processing can result in
buffer overflows, arithmetic overflows, or increased vulnerability to
9.4. Response Splitting
Response splitting (a.k.a, CRLF injection) is a common technique,
used in various attacks on Web usage, that exploits the line-based
nature of HTTP message framing and the ordered association of
requests to responses on persistent connections [Klein]. This
technique can be particularly damaging when the requests pass through
a shared cache.
Response splitting exploits a vulnerability in servers (usually
within an application server) where an attacker can send encoded data
within some parameter of the request that is later decoded and echoed
within any of the response header fields of the response. If the
decoded data is crafted to look like the response has ended and a
subsequent response has begun, the response has been split and the
content within the apparent second response is controlled by the
attacker. The attacker can then make any other request on the same
persistent connection and trick the recipients (including
intermediaries) into believing that the second half of the split is
an authoritative answer to the second request.
For example, a parameter within the request-target might be read by
an application server and reused within a redirect, resulting in the
same parameter being echoed in the Location header field of the
response. If the parameter is decoded by the application and not
properly encoded when placed in the response field, the attacker can
send encoded CRLF octets and other content that will make the
application's single response look like two or more responses.
A common defense against response splitting is to filter requests for
data that looks like encoded CR and LF (e.g., "%0D" and "%0A").
However, that assumes the application server is only performing URI
decoding, rather than more obscure data transformations like charset
transcoding, XML entity translation, base64 decoding, sprintf
reformatting, etc. A more effective mitigation is to prevent
anything other than the server's core protocol libraries from sending
a CR or LF within the header section, which means restricting the
output of header fields to APIs that filter for bad octets and not
allowing application servers to write directly to the protocol
9.5. Request Smuggling
Request smuggling ([Linhart]) is a technique that exploits
differences in protocol parsing among various recipients to hide
additional requests (which might otherwise be blocked or disabled by
policy) within an apparently harmless request. Like response
splitting, request smuggling can lead to a variety of attacks on HTTP
This specification has introduced new requirements on request
parsing, particularly with regard to message framing in
Section 3.3.3, to reduce the effectiveness of request smuggling.
9.6. Message Integrity
HTTP does not define a specific mechanism for ensuring message
integrity, instead relying on the error-detection ability of
underlying transport protocols and the use of length or
chunk-delimited framing to detect completeness. Additional integrity
mechanisms, such as hash functions or digital signatures applied to
the content, can be selectively added to messages via extensible
metadata header fields. Historically, the lack of a single integrity
mechanism has been justified by the informal nature of most HTTP
communication. However, the prevalence of HTTP as an information
access mechanism has resulted in its increasing use within
environments where verification of message integrity is crucial.
User agents are encouraged to implement configurable means for
detecting and reporting failures of message integrity such that those
means can be enabled within environments for which integrity is
necessary. For example, a browser being used to view medical history
or drug interaction information needs to indicate to the user when
such information is detected by the protocol to be incomplete,
expired, or corrupted during transfer. Such mechanisms might be
selectively enabled via user agent extensions or the presence of
message integrity metadata in a response. At a minimum, user agents
ought to provide some indication that allows a user to distinguish
between a complete and incomplete response message (Section 3.4) when
such verification is desired.
9.7. Message Confidentiality
HTTP relies on underlying transport protocols to provide message
confidentiality when that is desired. HTTP has been specifically
designed to be independent of the transport protocol, such that it
can be used over many different forms of encrypted connection, with
the selection of such transports being identified by the choice of
URI scheme or within user agent configuration.
The "https" scheme can be used to identify resources that require a
confidential connection, as described in Section 2.7.2.
9.8. Privacy of Server Log Information
A server is in the position to save personal data about a user's
requests over time, which might identify their reading patterns or
subjects of interest. In particular, log information gathered at an
intermediary often contains a history of user agent interaction,
across a multitude of sites, that can be traced to individual users.
HTTP log information is confidential in nature; its handling is often
constrained by laws and regulations. Log information needs to be
securely stored and appropriate guidelines followed for its analysis.
Anonymization of personal information within individual entries
helps, but it is generally not sufficient to prevent real log traces
from being re-identified based on correlation with other access
characteristics. As such, access traces that are keyed to a specific
client are unsafe to publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log
information ought to be purged of personally identifiable
information, including user identifiers, IP addresses, and
user-provided query parameters, as soon as that information is no
longer necessary to support operational needs for security, auditing,
or fraud control.
This edition of HTTP/1.1 builds on the many contributions that went
into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
substantial contributions made by the previous authors, editors, and
Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
and Paul J. Leach. Mark Nottingham oversaw this effort as Working
Since 1999, the following contributors have helped improve the HTTP
specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues:
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,
Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek
Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander
Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin
Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern
Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens,
Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann,
Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus
Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg,
Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave
Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty,
Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan
Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D.
Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik
Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian
Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser,
Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham,
Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz
Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,
Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido
Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll,
James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with
the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim
Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel
Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp,
John Panzer, John Schneider, John Stracke, John Sullivan, Jonas
Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore,
Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien
Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin
James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith
Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin
Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault,
Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark
Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler,
Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson,
Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge,
Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael
Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen,
Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin,
Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater,
Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.
Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska,
Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil
Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-
Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto
Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby
Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence
(who maintained the original issues list), Sean B. Palmer, Sean
Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon
Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane
Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart
Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares,
Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya
Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas
Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim
Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent
Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez
Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang,
Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang,
Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
editor team), Zed A. Shaw, and Zhong Yu.
See Section 16 of [RFC2616] for additional acknowledgements from
11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", RFC 7233, June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication",
RFC 7235, June 2014.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[Welch] Welch, T., "A Technique for High-Performance Data
Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References
[BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
and Registration Procedures for New URI Schemes",
BCP 115, RFC 4395, February 2006.
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
[Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R.,
Boneh, D., and V. Shmatikov, "The Most Dangerous Code
in the World: Validating SSL Certificates in Non-
browser Software", In Proceedings of the 2012 ACM
Conference on Computer and Communications Security (CCS
'12), pp. 38-49, October 2012,
[ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998.
[Klein] Klein, A., "Divide and Conquer - HTTP Response
Splitting, Web Cache Poisoning Attacks, and Related
Topics", March 2004, <http://packetstormsecurity.com/
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet
Technology 1(2), November 2001,
[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
Request Smuggling", June 2005,
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies",
RFC 1919, March 1996.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2068, January 1997.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
"Use and Interpretation of HTTP Version Numbers",
RFC 2145, May 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040,
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012.
Appendix A. HTTP Version History
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
across the Internet, using only a single request method (GET) and no
metadata. HTTP/1.0, as defined by [RFC1945], added a range of
request methods and MIME-like messaging, allowing for metadata to be
transferred and modifiers placed on the request/response semantics.
However, HTTP/1.0 did not sufficiently take into consideration the
effects of hierarchical proxies, caching, the need for persistent
connections, or name-based virtual hosts. The proliferation of
incompletely implemented applications calling themselves "HTTP/1.0"
further necessitated a protocol version change in order for two
communicating applications to determine each other's true
HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
requirements that enable reliable implementations, adding only those
features that can either be safely ignored by an HTTP/1.0 recipient
or only be sent when communicating with a party advertising
conformance with HTTP/1.1.
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
valid request in the format of HTTP/1.0, responding appropriately
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
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
no mechanism for it to support name-based virtual hosts (selection of
resource by inspection of the Host header field). Any server that
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,
badly constructed HTTP/1.x requests caused by a client failing to
properly encode the request-target.
A.1. Changes from HTTP/1.0
This section summarizes major differences between versions HTTP/1.0
A.1.1. Multihomed Web Servers
The requirements that clients and servers support the Host header
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
the most important changes defined by HTTP/1.1.
Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address
to which that request was directed. The Host header field was
introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional
requirements were placed on all HTTP/1.1 requests in order to ensure
complete adoption. At the time of this writing, most HTTP-based
services are dependent upon the Host header field for targeting
A.1.2. Keep-Alive Connections
In HTTP/1.0, each connection is established by the client prior to
the request and closed by the server after sending the response.
However, some implementations implement the explicitly negotiated
("Keep-Alive") version of persistent connections described in Section
19.7.1 of [RFC2068].
Some clients and servers might wish to be compatible with these
previous approaches to persistent connections, by explicitly
negotiating for them with a "Connection: keep-alive" request header
field. However, some experimental implementations of HTTP/1.0
persistent connections are faulty; for example, if an HTTP/1.0 proxy
server doesn't understand Connection, it will erroneously forward
that header field to the next inbound server, which would result in a
One attempted solution was the introduction of a Proxy-Connection
header field, targeted specifically at proxies. In practice, this
was also unworkable, because proxies are often deployed in multiple
layers, bringing about the same problem discussed above.
As a result, clients are encouraged not to send the Proxy-Connection
header field in any requests.
Clients are also encouraged to consider the use of Connection:
keep-alive in requests carefully; while they can enable persistent
connections with HTTP/1.0 servers, clients using them will need to
monitor the connection for "hung" requests (which indicate that the
client ought stop sending the header field), and this mechanism ought
not be used by clients at all when a proxy is being used.
A.1.3. Introduction of Transfer-Encoding
HTTP/1.1 introduces the Transfer-Encoding header field
(Section 3.3.1). Transfer codings need to be decoded prior to
forwarding an HTTP message over a MIME-compliant protocol.
A.2. Changes from RFC 2616
HTTP's approach to error handling has been explained. (Section 2.5)
The HTTP-version ABNF production has been clarified to be case-
sensitive. Additionally, version numbers have been restricted to
single digits, due to the fact that implementations are known to
handle multi-digit version numbers incorrectly. (Section 2.6)
Userinfo (i.e., username and password) are now disallowed in HTTP and
HTTPS URIs, because of security issues related to their transmission
on the wire. (Section 2.7.1)
The HTTPS URI scheme is now defined by this specification;
previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it
implies end-to-end security. (Section 2.7.2)
HTTP messages can be (and often are) buffered by implementations;
despite it sometimes being available as a stream, HTTP is
fundamentally a message-oriented protocol. Minimum supported sizes
for various protocol elements have been suggested, to improve
interoperability. (Section 3)
Invalid whitespace around field-names is now required to be rejected,
because accepting it represents a security vulnerability. The ABNF
productions defining header fields now only list the field value.
Rules about implicit linear whitespace between certain grammar
productions have been removed; now whitespace is only allowed where
specifically defined in the ABNF. (Section 3.2.3)
Header fields that span multiple lines ("line folding") are
deprecated. (Section 3.2.4)
The NUL octet is no longer allowed in comment and quoted-string text,
and handling of backslash-escaping in them has been clarified. The
quoted-pair rule no longer allows escaping control characters other
than HTAB. Non-US-ASCII content in header fields and the reason
phrase has been obsoleted and made opaque (the TEXT rule was
removed). (Section 3.2.6)
Bogus Content-Length header fields are now required to be handled as
errors by recipients. (Section 3.3.2)
The algorithm for determining the message body length has been
clarified to indicate all of the special cases (e.g., driven by
methods or status codes) that affect it, and that new protocol
elements cannot define such special cases. CONNECT is a new, special
case in determining message body length. "multipart/byteranges" is no
longer a way of determining message body length detection.
The "identity" transfer coding token has been removed. (Sections 3.3
Chunk length does not include the count of the octets in the chunk
header and trailer. Line folding in chunk extensions is disallowed.
The meaning of the "deflate" content coding has been clarified.
The segment + query components of RFC 3986 have been used to define
the request-target, instead of abs_path from RFC 1808. The
asterisk-form of the request-target is only allowed with the OPTIONS
method. (Section 5.3)
The term "Effective Request URI" has been introduced. (Section 5.5)
Gateways do not need to generate Via header fields anymore.
Exactly when "close" connection options have to be sent has been
clarified. Also, "hop-by-hop" header fields are required to appear
in the Connection header field; just because they're defined as hop-
by-hop in this specification doesn't exempt them. (Section 6.1)
The limit of two connections per server has been removed. An
idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when
the server prematurely closes the connection has been removed. Also,
some extraneous requirements about when servers are allowed to close
connections prematurely have been removed. (Section 6.3)
The semantics of the Upgrade header field is now defined in responses
other than 101 (this was incorporated from [RFC2817]). Furthermore,
the ordering in the field value is now significant. (Section 6.7)
Empty list elements in list productions (e.g., a list header field
containing ", ,") have been deprecated. (Section 7)
Registration of Transfer Codings now requires IETF Review
non-transforming proxy 49
origin server 7
origin-form (of request-target) 42
reverse proxy 10
target resource 40
target URI 40
TE header field 39
Trailer header field 40
Transfer-Encoding header field 28
transforming proxy 49
transparent proxy 11
Upgrade header field 57
user agent 7
Via header field 47