rfc3205.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

   For certain applications it may be necessary to require or limit use
   of certain HTTP features, for example, to defeat caching of responses
   by proxies.  Each protocol layered on HTTP must therefore specify the
   specific way that HTTP will be used, and in particular, how the
   client and server should interact with HTTP proxies.

8.  Issues regarding use of HTTP status codes

   HTTP's three-digit status codes were designed for use with
   traditional HTTP applications (e.g., document retrieval, forms-based
   queries), and are unlikely to be suitable to communicate the
   specifics of errors encountered in dissimilar applications.  Even
   when it seems like there is a close match between HTTP status codes
   and the codes needed by the application, experience with reuse of
   other protocols indicates that subtle variations in usage are likely;
   and that this is likely to degrade interoperability of both the
   original protocol (in this case HTTP) and any layered applications.

   HTTP status codes therefore should not be used to indicate subtle
   errors of layered applications.  At most, the "generic" HTTP codes
   200 (for complete success) and 500 (for complete failure) should be
   used to indicate errors resulting from the content of the request
   message-body.  Under certain circumstances, additional detail about
   the nature of the error can then be included in the response
   message-body.  Other status codes than 200 or 500 should only appear
   if the error was detected by the HTTP server or by an intermediary.

   A layered application should not define new HTTP status codes.  The
   set of available status codes is small, conflicts in code assignment
   between different layered applications are likely, and they may be
   needed by future versions of, or extensions to, mainstream HTTP.



Moore                    Best Current Practice                 [Page 10]

RFC 3205                     HTTP Layering                 February 2002


   Use of HTTP's error codes is problematic when the layered application
   does not share same notion of success or failure as HTTP.  The
   problem exists when the client does not connect directly to the
   origin server, but via one or more HTTP caches or proxies.  (Since
   the ability of HTTP to communicate through intermediaries is often
   the primary motivation for reusing HTTP, the ability of the
   application to operate in the presence of such intermediaries is
   considered very important.)  Such caches and proxies will interpret
   HTTP's error codes and may take additional action based on those
   codes.  For instance, on receipt of a 200 error code from an origin
   server (and under other appropriate conditions) a proxy may cache the
   response and re-issue it in response to a similar request.  Or a
   proxy may modify the result of a request which returns a 500 error
   code in order to add a "helpful" error message.  Other response codes
   may produce other behaviors.

   A few guidelines are therefore in order:

   o  A layered application should use appropriate HTTP error codes to
      report errors resulting from information in the HTTP request-line
      and header fields associated with the request.  This request
      information is part of the HTTP protocol and errors which are
      associated with that information should therefore be reported
      using HTTP protocol mechanisms.

   o  A layered application for which all errors resulting from the
      message-body can be classified as either "complete success" or
      "complete failure" may use 200 and 500 for those conditions,
      respectively.  However, the specification for such an application
      must define the mechanism which ensures that its successful (200)
      responses are not cached by intermediaries, or demonstrate that
      such caching will do no harm; and it must be able to operate even
      if the message-body of an error (500) response is not transmitted
      back to the client intact.

   o  A layered application may return a 200 response code for both
      successfully processed requests and errors (or other exceptional
      conditions) resulting from the request message-body (but not from
      the request headers).  Such an application must return its error
      code as part of the response message body, and the specification
      for that application protocol must define the mechanism by which
      the application ensures that its responses are not cached by
      intermediaries.  In this case a response other than 200 should be
      used only to indicate errors with, or the status of, the HTTP
      protocol layer (including the request headers), or to indicate the
      inability of the HTTP server to communicate with the application
      server.




Moore                    Best Current Practice                 [Page 11]

RFC 3205                     HTTP Layering                 February 2002


   o  A layered application which cannot operate in the presence of
      intermediaries or proxies that cache and/or alter error responses,
      should not use HTTP as a substrate.

9. Summary of recommendations regarding reuse of HTTP

   1. All protocols should provide adequate security.  The security
      needs of a particular application will vary widely depending on
      the application and its anticipated use environment.  Merely using
      HTTP and/or TLS as a substrate for a protocol does not
      automatically provide adequate security for all environments, nor
      does it relieve the protocol developers of the need to analyze
      security considerations for their particular application.

   2. New protocols - including but not limited to those using HTTP -
      should not attempt to circumvent users' firewall policies,
      particularly by masquerading as existing protocols.
      "Substantially new services" should not reuse existing ports.

   3. In general, new protocols or services should not reuse http: or
      other URL schemes.

   4. Each new protocol specification that uses HTTP as a substrate
      should describe the specific way that HTTP is to be used by that
      protocol, including how the client and server interact with
      proxies.

   5. New services should follow the guidelines in section 8 regarding
      use of HTTP status codes.

10.  Security Considerations

   Much of this document is about security.  Section 2.3 discusses
   whether HTTP security is adequate for the needs of a particular
   application, section 2.4 discusses interactions between new HTTP-
   based protocols and firewalls, section 3 discusses use of separate
   ports so that firewalls are not circumvented, and section 4 discusses
   the inadequacy of the "s" suffix of a URL prefix for specifying
   security levels.

11.  References

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






Moore                    Best Current Practice                 [Page 12]

RFC 3205                     HTTP Layering                 February 2002


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

   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [4]   Postel, J. and J. Reynolds, "Telnet Protocol Specification",
         STD 8, RFC 854, May 1983.

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

   [6]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
         2001.

   [7]   Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

   [8]   Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

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

   [10]  Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
         Directory Information", RFC 2425, September 1998.

   [11]  Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
         Language (XML)" World Wide Web Consortium Recommendation REC-
         xml-19980210, February 1998.  http://www.w3.org/TR/1998/REC-
         xml-19980210.

   [12]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

12.  Author's Address

   Keith Moore
   University of Tennessee
   Computer Science Department
   1122 Volunteer Blvd, Suite 203
   Knoxville TN, 37996-3450
   USA

   EMail: [e-mail]




Moore                    Best Current Practice                 [Page 13]

RFC 3205                     HTTP Layering                 February 2002


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Moore                    Best Current Practice                 [Page 14]