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
   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].

   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

   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

   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.

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

   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.

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.

   [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>.

   [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.

   [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.

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.

   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.

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

   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)

   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

   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 )

   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>

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

         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

         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

   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

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/