15 Security Considerations

   This section is meant to inform application developers, information
   providers, and users of the security limitations in HTTP/1.1 as
   described by this document. The discussion does not include
   definitive solutions to the problems revealed, though it does make
   some suggestions for reducing security risks.

15.1 Personal Information

   HTTP clients are often privy to large amounts of personal information
   (e.g. the user's name, location, mail address, passwords, encryption
   keys, etc.), and SHOULD be very careful to prevent unintentional
   leakage of this information via the HTTP protocol to other sources.
   We very strongly recommend that a convenient interface be provided
   for the user to control dissemination of such information, and that
   designers and implementors be particularly careful in this area.
   History shows that errors in this area often create serious security
   and/or privacy problems and generate highly adverse publicity for the
   implementor's company.

15.1.1 Abuse of Server Log Information

   A server is in the position to save personal data about a user's
   requests which might identify their reading patterns or subjects of
   interest. This information is clearly confidential in nature and its
   handling can be constrained by law in certain countries. People using
   the HTTP protocol to provide data are responsible for ensuring that
   such material is not distributed without the permission of any
   individuals that are identifiable by the published results.

15.1.2 Transfer of Sensitive Information

   Like any generic data transfer protocol, HTTP cannot regulate the
   content of the data that is transferred, nor is there any a priori
   method of determining the sensitivity of any particular piece of
   information within the context of any given request. Therefore,
   applications SHOULD supply as much control over this information as
   possible to the provider of that information. Four header fields are
   worth special mention in this context: Server, Via, Referer and From.

   Revealing the specific software version of the server might allow the
   server machine to become more vulnerable to attacks against software
   that is known to contain security holes. Implementors SHOULD make the
   Server header field a configurable option.

   Proxies which serve as a portal through a network firewall SHOULD
   take special precautions regarding the transfer of header information
   that identifies the hosts behind the firewall. In particular, they
   SHOULD remove, or replace with sanitized versions, any Via fields
   generated behind the firewall.

   The Referer header allows reading patterns to be studied and reverse
   links drawn. Although it can be very useful, its power can be abused
   if user details are not separated from the information contained in

   the Referer. Even when the personal information has been removed, the
   Referer header might indicate a private document's URI whose
   publication would be inappropriate.

   The information sent in the From field might conflict with the user's
   privacy interests or their site's security policy, and hence it
   SHOULD NOT be transmitted without the user being able to disable,
   enable, and modify the contents of the field. The user MUST be able
   to set the contents of this field within a user preference or
   application defaults configuration.

   We suggest, though do not require, that a convenient toggle interface
   be provided for the user to enable or disable the sending of From and
   Referer information.

   The User-Agent (section 14.43) or Server (section 14.38) header
   fields can sometimes be used to determine that a specific client or
   server have a particular security hole which might be exploited.
   Unfortunately, this same information is often used for other valuable
   purposes for which HTTP currently has no better mechanism.

15.1.3 Encoding Sensitive Information in URI's

   Because the source of a link might be private information or might
   reveal an otherwise private information source, it is strongly
   recommended that the user be able to select whether or not the
   Referer field is sent. For example, a browser client could have a
   toggle switch for browsing openly/anonymously, which would
   respectively enable/disable the sending of Referer and From
   information.

   Clients SHOULD NOT include a Referer header field in a (non-secure)
   HTTP request if the referring page was transferred with a secure
   protocol.

   Authors of services which use the HTTP protocol SHOULD NOT use GET
   based forms for the submission of sensitive data, because this will
   cause this data to be encoded in the Request-URI. Many existing
   servers, proxies, and user agents will log the request URI in some
   place where it might be visible to third parties. Servers can use
   POST-based form submission instead

15.1.4 Privacy Issues Connected to Accept Headers

   Accept request-headers can reveal information about the user to all
   servers which are accessed. The Accept-Language header in particular
   can reveal information the user would consider to be of a private
   nature, because the understanding of particular languages is often

   strongly correlated to the membership of a particular ethnic group.
   User agents which offer the option to configure the contents of an
   Accept-Language header to be sent in every request are strongly
   encouraged to let the configuration process include a message which
   makes the user aware of the loss of privacy involved.

   An approach that limits the loss of privacy would be for a user agent
   to omit the sending of Accept-Language headers by default, and to ask
   the user whether or not to start sending Accept-Language headers to a
   server if it detects, by looking for any Vary response-header fields
   generated by the server, that such sending could improve the quality
   of service.

   Elaborate user-customized accept header fields sent in every request,
   in particular if these include quality values, can be used by servers
   as relatively reliable and long-lived user identifiers. Such user
   identifiers would allow content providers to do click-trail tracking,
   and would allow collaborating content providers to match cross-server
   click-trails or form submissions of individual users. Note that for
   many users not behind a proxy, the network address of the host
   running the user agent will also serve as a long-lived user
   identifier. In environments where proxies are used to enhance
   privacy, user agents ought to be conservative in offering accept
   header configuration options to end users. As an extreme privacy
   measure, proxies could filter the accept headers in relayed requests.
   General purpose user agents which provide a high degree of header
   configurability SHOULD warn users about the loss of privacy which can
   be involved.

15.2 Attacks Based On File and Path Names

   Implementations of HTTP origin servers SHOULD be careful to restrict
   the documents returned by HTTP requests to be only those that were
   intended by the server administrators. If an HTTP server translates
   HTTP URIs directly into file system calls, the server MUST take
   special care not to serve files that were not intended to be
   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
   other operating systems use ".." as a path component to indicate a
   directory level above the current one. On such a system, an HTTP
   server MUST disallow any such construct in the Request-URI if it
   would otherwise allow access to a resource outside those intended to
   be accessible via the HTTP server. Similarly, files intended for
   reference only internally to the server (such as access control
   files, configuration files, and script code) MUST be protected from
   inappropriate retrieval, since they might contain sensitive
   information. Experience has shown that minor bugs in such HTTP server
   implementations have turned into security risks.

15.3 DNS Spoofing

   Clients using HTTP rely heavily on the Domain Name Service, and are
   thus generally prone to security attacks based on the deliberate
   mis-association of IP addresses and DNS names. Clients need to be
   cautious in assuming the continuing validity of an IP number/DNS name
   association.

   In particular, HTTP clients SHOULD rely on their name resolver for
   confirmation of an IP number/DNS name association, rather than
   caching the result of previous host name lookups. Many platforms
   already can cache host name lookups locally when appropriate, and
   they SHOULD be configured to do so. It is proper for these lookups to
   be cached, however, only when the TTL (Time To Live) information
   reported by the name server makes it likely that the cached
   information will remain useful.

   If HTTP clients cache the results of host name lookups in order to
   achieve a performance improvement, they MUST observe the TTL
   information reported by DNS.

   If HTTP clients do not observe this rule, they could be spoofed when
   a previously-accessed server's IP address changes. As network
   renumbering is expected to become increasingly common [24], the
   possibility of this form of attack will grow. Observing this
   requirement thus reduces this potential security vulnerability.

   This requirement also improves the load-balancing behavior of clients
   for replicated servers using the same DNS name and reduces the
   likelihood of a user's experiencing failure in accessing sites which
   use that strategy.

15.4 Location Headers and Spoofing

   If a single server supports multiple organizations that do not trust
   one another, then it MUST check the values of Location and Content-
   Location headers in responses that are generated under control of
   said organizations to make sure that they do not attempt to
   invalidate resources over which they have no authority.

15.5 Content-Disposition Issues

   RFC 1806 [35], from which the often implemented Content-Disposition
   (see section 19.5.1) header in HTTP is derived, has a number of very
   serious security considerations. Content-Disposition is not part of
   the HTTP standard, but since it is widely implemented, we are
   documenting its use and risks for implementors. See RFC 2183 [49]
   (which updates RFC 1806) for details.

15.6 Authentication Credentials and Idle Clients

   Existing HTTP clients and user agents typically retain authentication
   information indefinitely. HTTP/1.1. does not provide a method for a
   server to direct clients to discard these cached credentials. This is
   a significant defect that requires further extensions to HTTP.
   Circumstances under which credential caching can interfere with the
   application's security model include but are not limited to:

      - Clients which have been idle for an extended period following
        which the server might wish to cause the client to reprompt the
        user for credentials.

      - Applications which include a session termination indication
        (such as a `logout' or `commit' button on a page) after which
        the server side of the application `knows' that there is no
        further reason for the client to retain the credentials.

   This is currently under separate study. There are a number of work-
   arounds to parts of this problem, and we encourage the use of
   password protection in screen savers, idle time-outs, and other
   methods which mitigate the security problems inherent in this
   problem. In particular, user agents which cache credentials are
   encouraged to provide a readily accessible mechanism for discarding
   cached credentials under user control.

15.7 Proxies and Caching

   By their very nature, HTTP proxies are men-in-the-middle, and
   represent an opportunity for man-in-the-middle attacks. Compromise of
   the systems on which the proxies run can result in serious security
   and privacy problems. Proxies have access to security-related
   information, personal information about individual users and
   organizations, and proprietary information belonging to users and
   content providers. A compromised proxy, or a proxy implemented or
   configured without regard to security and privacy considerations,
   might be used in the commission of a wide range of potential attacks.

   Proxy operators should protect the systems on which proxies run as
   they would protect any system that contains or transports sensitive
   information. In particular, log information gathered at proxies often
   contains highly sensitive personal information, and/or information
   about organizations. Log information should be carefully guarded, and
   appropriate guidelines for use developed and followed. (Section
   15.1.1).

   Caching proxies provide additional potential vulnerabilities, since
   the contents of the cache represent an attractive target for
   malicious exploitation. Because cache contents persist after an HTTP
   request is complete, an attack on the cache can reveal information
   long after a user believes that the information has been removed from
   the network. Therefore, cache contents should be protected as
   sensitive information.

   Proxy implementors should consider the privacy and security
   implications of their design and coding decisions, and of the
   configuration options they provide to proxy operators (especially the
   default configuration).

   Users of a proxy need to be aware that they are no trustworthier than
   the people who run the proxy; HTTP itself cannot solve this problem.

   The judicious use of cryptography, when appropriate, may suffice to
   protect against a broad range of security and privacy attacks. Such
   cryptography is beyond the scope of the HTTP/1.1 specification.

15.7.1 Denial of Service Attacks on Proxies

   They exist. They are hard to defend against. Research continues.
   Beware.

16 Acknowledgments

   This specification makes heavy use of the augmented BNF and generic
   constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
   reuses many of the definitions provided by Nathaniel Borenstein and
   Ned Freed for MIME [7]. We hope that their inclusion in this
   specification will help reduce past confusion over the relationship
   between HTTP and Internet mail message formats.

   The HTTP protocol has evolved considerably over the years. It has
   benefited from a large and active developer community--the many
   people who have participated on the www-talk mailing list--and it is
   that community which has been most responsible for the success of
   HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
   VanHeyningen deserve special recognition for their efforts in
   defining early aspects of the protocol.

   This document has benefited greatly from the comments of all those
   participating in the HTTP-WG. In addition to those already mentioned,
   the following individuals have contributed to this specification:

       Gary Adams                  Ross Patterson
       Harald Tveit Alvestrand     Albert Lunde
       Keith Ball                  John C. Mallery
       Brian Behlendorf            Jean-Philippe Martin-Flatin
       Paul Burchard               Mitra
       Maurizio Codogno            David Morris
       Mike Cowlishaw              Gavin Nicol
       Roman Czyborra              Bill Perry
       Michael A. Dolan            Jeffrey Perry
       David J. Fiander            Scott Powers
       Alan Freier                 Owen Rees
       Marc Hedlund                Luigi Rizzo
       Greg Herlihy                David Robinson
       Koen Holtman                Marc Salomon
       Alex Hopmann                Rich Salz
       Bob Jernigan                Allan M. Schiffman
       Shel Kaphan                 Jim Seidman
       Rohit Khare                 Chuck Shotton
       John Klensin                Eric W. Sink
       Martijn Koster              Simon E. Spero
       Alexei Kosut                Richard N. Taylor
       David M. Kristol            Robert S. Thau
       Daniel LaLiberte            Bill (BearHeart) Weinman
       Ben Laurie                  Francois Yergeau
       Paul J. Leach               Mary Ellen Zurko
       Daniel DuBois               Josh Cohen


   Much of the content and presentation of the caching design is due to
   suggestions and comments from individuals including: Shel Kaphan,
   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.

   Most of the specification of ranges is based on work originally done
   by Ari Luotonen and John Franks, with additional input from Steve
   Zilles.

   Thanks to the "cave men" of Palo Alto. You know who you are.

   Jim Gettys (the current editor of this document) wishes particularly
   to thank Roy Fielding, the previous editor of this document, along
   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
   Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
   Larry Masinter for their help. And thanks go particularly to Jeff
   Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.

   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
   Frystyk implemented RFC 2068 early, and we wish to thank them for the
   discovery of many of the problems that this document attempts to
   rectify.

17 References

   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
       1766, March 1995.

   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
       D. and B. Alberti, "The Internet Gopher Protocol (a distributed
       document search and retrieval protocol)", RFC 1436, March 1993.

   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
       1630, June 1994.

   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
       Locators (URL)", RFC 1738, December 1994.

   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
       2.0", RFC 1866, November 1995.

   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
       Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

   [8] Braden, R., "Requirements for Internet Hosts -- Communication
       Layers", STD 3, RFC 1123, October 1989.

   [9] Crocker, D., "Standard for The Format of ARPA Internet Text
       Messages", STD 11, RFC 822, August 1982.

   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
        Functional Specification," (v1.5), Thinking Machines
        Corporation, April 1990.

   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
        June 1995.

   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
        Messages", RFC 1036, December 1987.

   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
        977, February 1986.

   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
        November 1996.

   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
        1867, November 1995.

   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
        August 1982.

   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
        November 1996.

   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
        959, October 1985.

   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        October 1994.

   [20] Sollins, K. and L. Masinter, "Functional Requirements for
        Uniform Resource Names", RFC 1737, December 1994.

   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
        Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.

   [22] ISO-8859. International Standard -- Information Processing --
        8-bit Single-Byte Coded Graphic Character Sets --
        Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
        Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
        Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
        Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
        Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
        Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
        Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
        Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
        Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.

   [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
        1864, October 1995.

   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
        1900, February 1996.

   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
        1952, May 1996.

   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
        Dec. 1995. Slightly revised version of paper in Proc. 2nd
        International WWW Conference '94: Mosaic and the Web, Oct. 1994,
        which is available at
        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
        ency.html.

   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
        Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
        ISI Research Report ISI/RR-98-463, (original report dated Aug.
        1996), USC/Information Sciences Institute, August 1998.

   [28] Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation and Analysis", RFC 1305, March 1992.

   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
        version 1.3", RFC 1951, May 1996.

   [30] S. Spero, "Analysis of HTTP Performance Problems,"
        http://sunsite.unc.edu/mdma-release/http-prob.html.

   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
        Specification version 3.3", RFC 1950, May 1996.

   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
        Digest Access Authentication", RFC 2069, January 1997.

   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
        2068, January 1997.

   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [35] Troost, R. and Dorner, S., "Communicating Presentation
        Information in Internet Messages: The Content-Disposition
        Header", RFC 1806, June 1995.

   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
        [jg639]

   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
        1997. [jg640]

   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
        ISO-10646", RFC 2279, January 1998. [jg641]

   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
        Lie, H., and C. Lilley. "Network Performance Effects of
        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
        France, September 1997.[jg642]

   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996. [jg643]

   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
        BCP 18, RFC 2277, January 1998. [jg644]

   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
        August 1998. [jg645]

   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
        Authentication: Basic and Digest Access Authentication", RFC
        2617, June 1999. [jg646]

   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers," Work in Progress. [jg647]

   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
        1997.

   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
        (HTCPCP/1.0)", RFC 2324, 1 April 1998.

   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Five: Conformance Criteria and Examples",
        RFC 2049, November 1996.

   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
        Information in Internet Messages: The Content-Disposition Header
        Field", RFC 2183, August 1997.

18 Authors' Addresses

   Roy T. Fielding
   Information and Computer Science
   University of California, Irvine
   Irvine, CA 92697-3425, USA

   Fax: +1 (949) 824-1715
   EMail: fielding@ics.uci.edu


   James Gettys
   World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: jg@w3.org


   Jeffrey C. Mogul
   Western Research Laboratory
   Compaq Computer Corporation
   250 University Avenue
   Palo Alto, California, 94305, USA

   EMail: mogul@wrl.dec.com


   Henrik Frystyk Nielsen
   World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: frystyk@w3.org


   Larry Masinter
   Xerox Corporation
   3333 Coyote Hill Road
   Palo Alto, CA 94034, USA

   EMail: masinter@parc.xerox.com

   Paul J. Leach
   Microsoft Corporation
   1 Microsoft Way
   Redmond, WA 98052, USA

   EMail: paulle@microsoft.com


   Tim Berners-Lee
   Director, World Wide Web Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, USA

   Fax: +1 (617) 258 8682
   EMail: timbl@w3.org

19 Appendices

19.1 Internet Media Type message/http and application/http

   In addition to defining the HTTP/1.1 protocol, this document serves
   as the specification for the Internet media type "message/http" and
   "application/http". The message/http type can be used to enclose a
   single HTTP request or response message, provided that it obeys the
   MIME restrictions for all "message" types regarding line length and
   encodings. The application/http type can be used to enclose a
   pipeline of one or more HTTP request or response messages (not
   intermixed). The following is to be registered with IANA [17].

       Media Type name:         message
       Media subtype name:      http
       Required parameters:     none
       Optional parameters:     version, msgtype
        version: The HTTP-Version number of the enclosed message
                 (e.g., "1.1"). If not present, the version can be
                 determined from the first line of the body.
        msgtype: The message type -- "request" or "response". If not
                 present, the type can be determined from the first
                 line of the body.
       Encoding considerations: only "7bit", "8bit", or "binary" are
                                permitted
       Security considerations: none

       Media Type name:         application
       Media subtype name:      http
       Required parameters:     none
       Optional parameters:     version, msgtype
        version: The HTTP-Version number of the enclosed messages
                 (e.g., "1.1"). If not present, the version can be
                 determined from the first line of the body.
        msgtype: The message type -- "request" or "response". If not
                 present, the type can be determined from the first
                 line of the body.
       Encoding considerations: HTTP messages enclosed by this type
                 are in "binary" format; use of an appropriate
                 Content-Transfer-Encoding is required when
                 transmitted via E-mail.
       Security considerations: none

19.2 Internet Media Type multipart/byteranges

   When an HTTP 206 (Partial Content) response message includes the
   content of multiple ranges (a response to a request for multiple
   non-overlapping ranges), these are transmitted as a multipart
   message-body. The media type for this purpose is called
   "multipart/byteranges".

   The multipart/byteranges media type includes two or more parts, each
   with its own Content-Type and Content-Range fields. The required
   boundary parameter specifies the boundary string used to separate
   each body-part.

       Media Type name:         multipart
       Media subtype name:      byteranges
       Required parameters:     boundary
       Optional parameters:     none
       Encoding considerations: only "7bit", "8bit", or "binary" are
                                permitted
       Security considerations: none


   For example:

   HTTP/1.1 206 Partial Content
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...the first range...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...the second range
   --THIS_STRING_SEPARATES--

      Notes:

      1) Additional CRLFs may precede the first boundary string in the
         entity.

      2) Although RFC 2046 [40] permits the boundary string to be
         quoted, some existing implementations handle a quoted boundary
         string incorrectly.

      3) A number of browsers and servers were coded to an early draft
         of the byteranges specification to use a media type of
         multipart/x-byteranges, which is almost, but not quite
         compatible with the version documented in HTTP/1.1.

19.3 Tolerant Applications

   Although this document specifies the requirements for the generation
   of HTTP/1.1 messages, not all applications will be correct in their
   implementation. We therefore recommend that operational applications
   be tolerant of deviations whenever those deviations can be
   interpreted unambiguously.

   Clients SHOULD be tolerant in parsing the Status-Line and servers
   tolerant when parsing the Request-Line. In particular, they SHOULD
   accept any amount of SP or HT characters between fields, even though
   only a single SP is required.

   The line terminator for message-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.

   The character set of an entity-body SHOULD be labeled as the lowest
   common denominator of the character codes used within that body, with
   the exception that not labeling the entity is preferred over labeling
   the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
   and 3.4.1.

   Additional rules for requirements on parsing and encoding of dates
   and other potential problems with date encodings include:

      - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
        which appears to be more than 50 years in the future is in fact
        in the past (this helps solve the "year 2000" problem).

      - An HTTP/1.1 implementation MAY internally represent a parsed
        Expires date as earlier than the proper value, but MUST NOT
        internally represent a parsed Expires date as later than the
        proper value.

      - All expiration-related calculations MUST be done in GMT. The
        local time zone MUST NOT influence the calculation or comparison
        of an age or expiration time.

      - If an HTTP header incorrectly carries a date value with a time
        zone other than GMT, it MUST be converted into GMT using the
        most conservative possible conversion.

19.4 Differences Between HTTP Entities and RFC 2045 Entities

   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
   822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
   allow entities to be transmitted in an open variety of
   representations and with extensible mechanisms. However, RFC 2045
   discusses mail, and HTTP has a few features that are different from
   those described in RFC 2045. These differences were carefully chosen
   to optimize performance over binary connections, to allow greater
   freedom in the use of new media types, to make date comparisons
   easier, and to acknowledge the practice of some early HTTP servers
   and clients.

   This appendix describes specific areas where HTTP differs from RFC
   2045. Proxies and gateways to strict MIME environments SHOULD be
   aware of these differences and provide the appropriate conversions
   where necessary. Proxies and gateways from MIME environments to HTTP
   also need to be aware of the differences because some conversions
   might be required.

19.4.1 MIME-Version

   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
   include a single MIME-Version general-header field to indicate what
   version of the MIME protocol was used to construct the message. Use
   of the MIME-Version header field indicates that the message is in
   full compliance with the MIME protocol (as defined in RFC 2045[7]).
   Proxies/gateways are responsible for ensuring full compliance (where
   possible) when exporting HTTP messages to strict MIME environments.

       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   MIME version "1.0" is the default for use in HTTP/1.1. However,
   HTTP/1.1 message parsing and semantics are defined by this document
   and not the MIME specification.

19.4.2 Conversion to Canonical Form

   RFC 2045 [7] requires that an Internet mail entity be converted to
   canonical form prior to being transferred, as described in section 4
   of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
   allowed for subtypes of the "text" media type when transmitted over
   HTTP. RFC 2046 requires that content with a type of "text" represent
   line breaks as CRLF and forbids the use of CR or LF outside of line

   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
   line break within text content when a message is transmitted over
   HTTP.

   Where it is possible, a proxy or gateway from HTTP to a strict MIME
   environment SHOULD translate all line breaks within the text media
   types described in section 3.7.1 of this document to the RFC 2049
   canonical form of CRLF. Note, however, that this might be complicated
   by the presence of a Content-Encoding and by the fact that HTTP
   allows the use of some character sets which do not use octets 13 and
   10 to represent CR and LF, as is the case for some multi-byte
   character sets.

   Implementors should note that conversion will break any cryptographic
   checksums applied to the original content unless the original content
   is already in canonical form. Therefore, the canonical form is
   recommended for any content that uses such checksums in HTTP.

19.4.3 Conversion of Date Formats

   HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
   simplify the process of date comparison. Proxies and gateways from
   other protocols SHOULD ensure that any Date header field present in a
   message conforms to one of the HTTP/1.1 formats and rewrite the date
   if necessary.

19.4.4 Introduction of Content-Encoding

   RFC 2045 does not include any concept equivalent to HTTP/1.1's
   Content-Encoding header field. Since this acts as a modifier on the
   media type, proxies and gateways from HTTP to MIME-compliant
   protocols MUST either change the value of the Content-Type header
   field or decode the entity-body before forwarding the message. (Some
   experimental applications of Content-Type for Internet mail have used
   a media-type parameter of ";conversions=<content-coding>" to perform
   a function equivalent to Content-Encoding. However, this parameter is
   not part of RFC 2045.)

19.4.5 No Content-Transfer-Encoding

   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
   remove any non-identity CTE ("quoted-printable" or "base64") encoding
   prior to delivering the response message to an HTTP client.

   Proxies and gateways from HTTP to MIME-compliant protocols are
   responsible for ensuring that the message is in the correct format
   and encoding for safe transport on that protocol, where "safe

   transport" is defined by the limitations of the protocol being used.
   Such a proxy or gateway SHOULD label the data with an appropriate
   Content-Transfer-Encoding if doing so will improve the likelihood of
   safe transport over the destination protocol.

19.4.6 Introduction of Transfer-Encoding

   HTTP/1.1 introduces the Transfer-Encoding header field (section
   14.41). Proxies/gateways MUST remove any transfer-coding prior to
   forwarding a message via a MIME-compliant protocol.

   A process for decoding the "chunked" transfer-coding (section 3.6)
   can be represented in pseudo-code as:

       length := 0
       read chunk-size, chunk-extension (if any) and CRLF
       while (chunk-size > 0) {
          read chunk-data and CRLF
          append chunk-data to entity-body
          length := length + chunk-size
          read chunk-size and CRLF
       }
       read entity-header
       while (entity-header not empty) {
          append entity-header to existing header fields
          read entity-header
       }
       Content-Length := length
       Remove "chunked" from Transfer-Encoding

19.4.7 MHTML and Line Length Limitations

   HTTP implementations which share code with MHTML [45] implementations
   need to be aware of MIME line length limitations. Since HTTP does not
   have this limitation, HTTP does not fold long lines. MHTML messages
   being transported by HTTP follow all conventions of MHTML, including
   line length limitations and folding, canonicalization, etc., since
   HTTP transports all message-bodies as payload (see section 3.7.2) and
   does not interpret the content or any MIME header lines that might be
   contained therein.

19.5 Additional Features

   RFC 1945 and RFC 2068 document protocol elements used by some
   existing HTTP implementations, but not consistently and correctly
   across most HTTP/1.1 applications. Implementors are advised to be
   aware of these features, but cannot rely upon their presence in, or
   interoperability with, other HTTP/1.1 applications. Some of these

   describe proposed experimental features, and some describe features
   that experimental deployment found lacking that are now addressed in
   the base HTTP/1.1 specification.

   A number of other headers, such as Content-Disposition and Title,
   from SMTP and MIME are also often implemented (see RFC 2076 [37]).

19.5.1 Content-Disposition

   The Content-Disposition response-header field has been proposed as a
   means for the origin server to suggest a default filename if the user
   requests that the content is saved to a file. This usage is derived
   from the definition of Content-Disposition in RFC 1806 [35].

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )

   An example is

        Content-Disposition: attachment; filename="fname.ext"

   The receiving user agent SHOULD NOT respect any directory path
   information present in the filename-parm parameter, which is the only
   parameter believed to apply to HTTP implementations at this time. The
   filename SHOULD be treated as a terminal component only.

   If this header is used in a response with the application/octet-
   stream content-type, the implied suggestion is that the user agent
   should not display the response, but directly enter a `save response
   as...' dialog.

   See section 15.5 for Content-Disposition security issues.

19.6 Compatibility with Previous Versions

   It is beyond the scope of a protocol specification to mandate
   compliance with previous versions. HTTP/1.1 was deliberately
   designed, however, to make supporting previous versions easy. It is
   worth noting that, at the time of composing this specification
   (1996), we would expect commercial HTTP/1.1 servers to:

      - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
        1.1 requests;

      - understand any valid request in the format of HTTP/0.9, 1.0, or
        1.1;

      - respond appropriately with a message in the same major version
        used by the client.

   And we would expect HTTP/1.1 clients to:

      - recognize the format of the Status-Line for HTTP/1.0 and 1.1
        responses;

      - understand any valid response in the format of HTTP/0.9, 1.0, or
        1.1.

   For most implementations of HTTP/1.0, each connection is established
   by the client prior to the request and closed by the server after
   sending the response. Some implementations implement the Keep-Alive
   version of persistent connections described in section 19.7.1 of RFC
   2068 [33].

19.6.1 Changes from HTTP/1.0

   This section summarizes major differences between versions HTTP/1.0
   and HTTP/1.1.

19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
         Addresses

   The requirements that clients and servers support the Host request-
   header, report an error if the Host request-header (section 14.23) is
   missing from an HTTP/1.1 request, and accept absolute URIs (section
   5.1.2) are among the most important changes defined by this
   specification.

   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 changes outlined above will
   allow the Internet, once older HTTP clients are no longer common, to
   support multiple Web sites from a single IP address, greatly
   simplifying large operational Web servers, where allocation of many
   IP addresses to a single host has created serious problems. The
   Internet will also be able to recover the IP addresses that have been
   allocated for the sole purpose of allowing special-purpose domain
   names to be used in root-level HTTP URLs. Given the rate of growth of
   the Web, and the number of servers already deployed, it is extremely

   important that all implementations of HTTP (including updates to
   existing HTTP/1.0 applications) correctly implement these
   requirements:

      - Both clients and servers MUST support the Host request-header.

      - A client that sends an HTTP/1.1 request MUST send a Host header.

      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
        request does not include a Host request-header.

      - Servers MUST accept absolute URIs.

19.6.2 Compatibility with HTTP/1.0 Persistent Connections

   Some clients and servers might wish to be compatible with some
   previous implementations of persistent connections in HTTP/1.0
   clients and servers. Persistent connections in HTTP/1.0 are
   explicitly negotiated as they are not the default behavior. HTTP/1.0
   experimental implementations of persistent connections are faulty,
   and the new facilities in HTTP/1.1 are designed to rectify these
   problems. The problem was that some existing 1.0 clients may be
   sending Keep-Alive to a proxy server that doesn't understand
   Connection, which would then erroneously forward it to the next
   inbound server, which would establish the Keep-Alive connection and
   result in a hung HTTP/1.0 proxy waiting for the close on the
   response. The result is that HTTP/1.0 clients must be prevented from
   using Keep-Alive when talking to proxies.

   However, talking to proxies is the most important use of persistent
   connections, so that prohibition is clearly unacceptable. Therefore,
   we need some other mechanism for indicating a persistent connection
   is desired, which is safe to use even when talking to an old proxy
   that ignores Connection. Persistent connections are the default for
   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
   declaring non-persistence. See section 14.10.

   The original HTTP/1.0 form of persistent connections (the Connection:
   Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]

19.6.3 Changes from RFC 2068

   This specification has been carefully audited to correct and
   disambiguate key word usage; RFC 2068 had many problems in respect to
   the conventions laid out in RFC 2119 [34].

   Clarified which error code should be used for inbound server failures
   (e.g. DNS failures). (Section 10.5.5).

   CREATE had a race that required an Etag be sent when a resource is
   first created. (Section 10.2.2).

   Content-Base was deleted from the specification: it was not
   implemented widely, and there is no simple, safe way to introduce it
   without a robust extension mechanism. In addition, it is used in a
   similar, but not identical fashion in MHTML [45].

   Transfer-coding and message lengths all interact in ways that
   required fixing exactly when chunked encoding is used (to allow for
   transfer encoding that may not be self delimiting); it was important
   to straighten out exactly how message lengths are computed. (Sections
   3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)

   A content-coding of "identity" was introduced, to solve problems
   discovered in caching. (section 3.5)

   Quality Values of zero should indicate that "I don't want something"
   to allow clients to refuse a representation. (Section 3.9)

   The use and interpretation of HTTP version numbers has been clarified
   by RFC 2145. Require proxies to upgrade requests to highest protocol
   version they support to deal with problems discovered in HTTP/1.0
   implementations (Section 3.1)

   Charset wildcarding is introduced to avoid explosion of character set
   names in accept headers. (Section 14.2)

   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
   was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
   14.9.3)

   The Cache-Control: max-age directive was not properly defined for
   responses. (Section 14.9.3)

   There are situations where a server (especially a proxy) does not
   know the full length of a response but is capable of serving a
   byterange request. We therefore need a mechanism to allow byteranges
   with a content-range not indicating the full length of the message.
   (Section 14.16)

   Range request responses would become very verbose if all meta-data
   were always returned; by allowing the server to only send needed
   headers in a 206 response, this problem can be avoided. (Section
   10.2.7, 13.5.3, and 14.27)

   Fix problem with unsatisfiable range requests; there are two cases:
   syntactic problems, and range doesn't exist in the document. The 416
   status code was needed to resolve this ambiguity needed to indicate
   an error for a byte range request that falls outside of the actual
   contents of a document. (Section 10.4.17, 14.16)

   Rewrite of message transmission requirements to make it much harder
   for implementors to get it wrong, as the consequences of errors here
   can have significant impact on the Internet, and to deal with the
   following problems:

      1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
         this was incorrectly placing a requirement on the behavior of
         an implementation of a future version of HTTP/1.x

      2. Made it clear that user-agents should retry requests, not
         "clients" in general.

      3. Converted requirements for clients to ignore unexpected 100
         (Continue) responses, and for proxies to forward 100 responses,
         into a general requirement for 1xx responses.

      4. Modified some TCP-specific language, to make it clearer that
         non-TCP transports are possible for HTTP.

      5. Require that the origin server MUST NOT wait for the request
         body before it sends a required 100 (Continue) response.

      6. Allow, rather than require, a server to omit 100 (Continue) if
         it has already seen some of the request body.

      7. Allow servers to defend against denial-of-service attacks and
         broken clients.

   This change adds the Expect header and 417 status code. The message
   transmission requirements fixes are in sections 8.2, 10.4.18,
   8.1.2.2, 13.11, and 14.20.

   Proxies should be able to add Content-Length when appropriate.
   (Section 13.5.2)

   Clean up confusion between 403 and 404 responses. (Section 10.4.4,
   10.4.5, and 10.4.11)

   Warnings could be cached incorrectly, or not updated appropriately.
   (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
   also needed to be a general header, as PUT or other methods may have
   need for it in requests.

   Transfer-coding had significant problems, particularly with
   interactions with chunked encoding. The solution is that transfer-
   codings become as full fledged as content-codings. This involves
   adding an IANA registry for transfer-codings (separate from content
   codings), a new header field (TE) and enabling trailer headers in the
   future. Transfer encoding is a major performance benefit, so it was
   worth fixing [39]. TE also solves another, obscure, downward
   interoperability problem that could have occurred due to interactions
   between authentication trailers, chunked encoding and HTTP/1.0
   clients.(Section 3.6, 3.6.1, and 14.39)

   The PATCH, LINK, UNLINK methods were defined but not commonly
   implemented in previous versions of this specification. See RFC 2068
   [33].

   The Alternates, Content-Version, Derived-From, Link, URI, Public and
   Content-Base header fields were defined in previous versions of this
   specification, but not commonly implemented. See RFC 2068 [33].

20 Index

   Please see the PostScript version of this RFC for the INDEX.

21.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.