Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7230

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Pages: 89
Obsoletes:  21452616
Obsoleted by:  91109112
Updates:  28172818
Updated by:  8615
Part 4 of 4 – Pages 67 to 89
First   Prev   None

Top   ToC   RFC7230 - Page 67   prevText

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
Top   ToC   RFC7230 - Page 68
   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
   improve authenticity.

   Furthermore, after an IP address is obtained, establishing authority
   for an "http" URI is vulnerable to attacks on Internet Protocol
   routing.

   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
   [Georgiev]).

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].
Top   ToC   RFC7230 - Page 69
   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
   configuration).

   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 limits. 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 denial-of-service attacks.

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
Top   ToC   RFC7230 - Page 70
   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
   stream.

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 usage. 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
Top   ToC   RFC7230 - Page 71
   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.
Top   ToC   RFC7230 - Page 72
   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.

10. Acknowledgments

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 Group Chair. 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
Top   ToC   RFC7230 - Page 73
   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
   prior revisions.
Top   ToC   RFC7230 - Page 74

11. References

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, January 2008. [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.
Top   ToC   RFC7230 - Page 75
   [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, <http://doi.acm.org/10.1145/2382196.2382204>. [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/ papers/general/whitepaper_httpresponse.pdf>. [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and Politics", ACM Transactions on Internet Technology 1(2), November 2001, <http://arxiv.org/abs/cs.SE/0105018>. [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP Request Smuggling", June 2005, <http://www.watchfire.com/news/whitepapers.aspx>.
Top   ToC   RFC7230 - Page 76
   [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,
                 May 1996.

   [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,
                 January 2001.

   [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.
Top   ToC   RFC7230 - Page 77
   [RFC5246]     Dierks, T. and E. Rescorla, "The Transport Layer
                 Security (TLS) Protocol Version 1.2", RFC 5246,
                 August 2008.

   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
                 October 2008.

   [RFC6265]     Barth, A., "HTTP State Management Mechanism", RFC 6265,
                 April 2011.

   [RFC6585]     Nottingham, M. and R. Fielding, "Additional HTTP Status
                 Codes", RFC 6585, April 2012.
Top   ToC   RFC7230 - Page 78

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 capabilities. 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 and HTTP/1.1.

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.
Top   ToC   RFC7230 - Page 79
   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
   requests.

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 hung connection. 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.
Top   ToC   RFC7230 - Page 80

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. (Section 3.2) 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
Top   ToC   RFC7230 - Page 81
   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.
   (Section 3.3.3)

   The "identity" transfer coding token has been removed.  (Sections 3.3
   and 4)

   Chunk length does not include the count of the octets in the chunk
   header and trailer.  Line folding in chunk extensions is disallowed.
   (Section 4.1)

   The meaning of the "deflate" content coding has been clarified.
   (Section 4.2.2)

   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.
   (Section 5.7.1)

   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
   (Section 8.4)
Top   ToC   RFC7230 - Page 82
   This specification now defines the Upgrade Token Registry, previously
   defined in Section 7.2 of [RFC2817].  (Section 8.6)

   The expectation to support HTTP/0.9 requests has been removed.
   (Appendix A)

   Issues with the Keep-Alive and Proxy-Connection header fields in
   requests are pointed out, with use of the latter being discouraged
   altogether.  (Appendix A.1.2)

Appendix B. Collected ABNF

BWS = OWS Connection = *( "," OWS ) connection-option *( OWS "," [ OWS connection-option ] ) Content-Length = 1*DIGIT HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ] HTTP-name = %x48.54.54.50 ; HTTP HTTP-version = HTTP-name "/" DIGIT "." DIGIT Host = uri-host [ ":" port ] OWS = *( SP / HTAB ) RWS = 1*( SP / HTAB ) TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS transfer-coding ] ) URI-reference = <URI-reference, see [RFC3986], Section 4.1> Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS comment ] ) ] ) absolute-URI = <absolute-URI, see [RFC3986], Section 4.3> absolute-form = absolute-URI absolute-path = 1*( "/" segment ) asterisk-form = "*" authority = <authority, see [RFC3986], Section 3.2> authority-form = authority
Top   ToC   RFC7230 - Page 83
   chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
   chunk-data = 1*OCTET
   chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
   chunk-ext-name = token
   chunk-ext-val = token / quoted-string
   chunk-size = 1*HEXDIG
   chunked-body = *chunk last-chunk trailer-part CRLF
   comment = "(" *( ctext / quoted-pair / comment ) ")"
   connection-option = token
   ctext = HTAB / SP / %x21-27 ; '!'-'''
    / %x2A-5B ; '*'-'['
    / %x5D-7E ; ']'-'~'
    / obs-text

   field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
   field-name = token
   field-value = *( field-content / obs-fold )
   field-vchar = VCHAR / obs-text
   fragment = <fragment, see [RFC3986], Section 3.5>

   header-field = field-name ":" OWS field-value OWS
   http-URI = "http://" authority path-abempty [ "?" query ] [ "#"
    fragment ]
   https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
    fragment ]

   last-chunk = 1*"0" [ chunk-ext ] CRLF

   message-body = *OCTET
   method = token

   obs-fold = CRLF 1*( SP / HTAB )
   obs-text = %x80-FF
   origin-form = absolute-path [ "?" query ]

   partial-URI = relative-part [ "?" query ]
   path-abempty = <path-abempty, see [RFC3986], Section 3.3>
   port = <port, see [RFC3986], Section 3.2.3>
   protocol = protocol-name [ "/" protocol-version ]
   protocol-name = token
   protocol-version = token
   pseudonym = token

   qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
    / %x5D-7E ; ']'-'~'
    / obs-text
   query = <query, see [RFC3986], Section 3.4>
   quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
Top   ToC   RFC7230 - Page 84
   quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE

   rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
   reason-phrase = *( HTAB / SP / VCHAR / obs-text )
   received-by = ( uri-host [ ":" port ] ) / pseudonym
   received-protocol = [ protocol-name "/" ] protocol-version
   relative-part = <relative-part, see [RFC3986], Section 4.2>
   request-line = method SP request-target SP HTTP-version CRLF
   request-target = origin-form / absolute-form / authority-form /
    asterisk-form

   scheme = <scheme, see [RFC3986], Section 3.1>
   segment = <segment, see [RFC3986], Section 3.3>
   start-line = request-line / status-line
   status-code = 3DIGIT
   status-line = HTTP-version SP status-code SP reason-phrase CRLF

   t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
   t-ranking = OWS ";" OWS "q=" rank
   tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
    "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
   token = 1*tchar
   trailer-part = *( header-field CRLF )
   transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
    transfer-extension
   transfer-extension = token *( OWS ";" OWS transfer-parameter )
   transfer-parameter = token BWS "=" BWS ( token / quoted-string )

   uri-host = <host, see [RFC3986], Section 3.2.2>
Top   ToC   RFC7230 - Page 85

Index

A absolute-form (of request-target) 42 accelerator 10 application/http Media Type 63 asterisk-form (of request-target) 43 authoritative response 67 authority-form (of request-target) 42-43 B browser 7 C cache 11 cacheable 12 captive portal 11 chunked (Coding Format) 28, 32, 36 client 7 close 51, 56 compress (Coding Format) 38 connection 7 Connection header field 51, 56 Content-Length header field 30 D deflate (Coding Format) 38 Delimiters 27 downstream 10 E effective request URI 45 G gateway 10 Grammar absolute-form 42 absolute-path 16 absolute-URI 16 ALPHA 6 asterisk-form 41, 43 authority 16 authority-form 42-43 BWS 25 chunk 36 chunk-data 36 chunk-ext 36 chunk-ext-name 36
Top   ToC   RFC7230 - Page 86
         chunk-ext-val  36
         chunk-size  36
         chunked-body  36
         comment  27
         Connection  51
         connection-option  51
         Content-Length  30
         CR  6
         CRLF  6
         ctext  27
         CTL  6
         DIGIT  6
         DQUOTE  6
         field-content  23
         field-name  23, 40
         field-value  23
         field-vchar  23
         fragment  16
         header-field  23, 37
         HEXDIG  6
         Host  44
         HTAB  6
         HTTP-message  19
         HTTP-name  14
         http-URI  17
         HTTP-version  14
         https-URI  18
         last-chunk  36
         LF  6
         message-body  28
         method  21
         obs-fold  23
         obs-text  27
         OCTET  6
         origin-form  42
         OWS  25
         partial-URI  16
         port  16
         protocol-name  47
         protocol-version  47
         pseudonym  47
         qdtext  27
         query  16
         quoted-pair  27
         quoted-string  27
         rank  39
         reason-phrase  22
         received-by  47
Top   ToC   RFC7230 - Page 87
         received-protocol  47
         request-line  21
         request-target  41
         RWS  25
         scheme  16
         segment  16
         SP  6
         start-line  21
         status-code  22
         status-line  22
         t-codings  39
         t-ranking  39
         tchar  27
         TE  39
         token  27
         Trailer  40
         trailer-part  37
         transfer-coding  35
         Transfer-Encoding  28
         transfer-extension  35
         transfer-parameter  35
         Upgrade  57
         uri-host  16
         URI-reference  16
         VCHAR  6
         Via  47
      gzip (Coding Format)  39

   H
      header field  19
      header section  19
      headers  19
      Host header field  44
      http URI scheme  17
      https URI scheme  17
   I
      inbound  9
      interception proxy  11
      intermediary  9

   M
      Media Type
         application/http  63
         message/http  62
      message  7
      message/http Media Type  62
      method  21
Top   ToC   RFC7230 - Page 88
   N
      non-transforming proxy  49

   O
      origin server  7
      origin-form (of request-target)  42
      outbound  10

   P
      phishing  67
      proxy  10

   R
      recipient  7
      request  7
      request-target  21
      resource  16
      response  7
      reverse proxy  10

   S
      sender  7
      server  7
      spider  7

   T
      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
      tunnel  10

   U
      Upgrade header field  57
      upstream  9
      URI scheme
         http  17
         https  17
      user agent  7

   V
      Via header field  47
Top   ToC   RFC7230 - Page 89

Authors' Addresses

Roy T. Fielding (editor) Adobe Systems Incorporated 345 Park Ave San Jose, CA 95110 USA EMail: fielding@gbiv.com URI: http://roy.gbiv.com/ Julian F. Reschke (editor) greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany EMail: julian.reschke@greenbytes.de URI: http://greenbytes.de/tech/webdav/