rfc2817.txt

RFC 的详细文档！

   It may be the case that the proxy itself can only reach the requested
   origin server through another proxy.  In this case, the first proxy
   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
   to the authority.  A proxy MUST NOT respond with any 2xx status code
   unless it has either a direct or tunnel connection established to the
   authority.

   An origin server which receives a CONNECT request for itself MAY
   respond with a 2xx status code to indicate that a connection is
   established.

   If at any point either one of the peers gets disconnected, any
   outstanding data that came from that peer will be passed to the other
   one, and after that also the other connection will be terminated by
   the proxy. If there is outstanding data to that peer undelivered,
   that data will be discarded.

6. Rationale for the use of a 4xx (client error) Status Code

   Reliable, interoperable negotiation of Upgrade features requires an
   unambiguous failure signal. The 426 Upgrade Required status code
   allows a server to definitively state the precise protocol extensions
   a given resource must be served with.




Khare & Lawrence            Standards Track                     [Page 7]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


   It might at first appear that the response should have been some form
   of redirection (a 3xx code), by analogy to an old-style redirection
   to an https: URI.  User agents that do not understand Upgrade:
   preclude this.

   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
   user agent that did not recognize it would treat it as 300.  It would
   then properly look for a "Location" header in the response and
   attempt to repeat the request at the URL in that header field. Since
   it did not know to Upgrade to incorporate the TLS layer, it would at
   best fail again at the new URL.

7. IANA Considerations

   IANA shall create registries for two name spaces, as described in BCP
   26 [10]:

   o  HTTP Status Codes
   o  HTTP Upgrade Tokens

7.1 HTTP Status Code Registry

   The HTTP Status Code Registry defines the name space for the Status-
   Code token in the Status line of an HTTP response.  The initial
   values for this name space are those specified by:

   1.  Draft Standard for HTTP/1.1 [1]
   2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
   4.  Section 6 [defines 426]

   Values to be added to this name space SHOULD be subject to review in
   the form of a standards track document within the IETF Applications
   Area.  Any such document SHOULD be traceable through statuses of
   either 'Obsoletes' or 'Updates' to the Draft Standard for
   HTTP/1.1 [1].

7.2 HTTP Upgrade Token Registry

   The HTTP Upgrade Token Registry defines the name space for product
   tokens used to identify protocols in the Upgrade HTTP header field.
   Each registered token should be associated with one or a set of
   specifications, and with contact information.

   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
   the production for 'product':





Khare & Lawrence            Standards Track                     [Page 8]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


      product         = token ["/" product-version]
      product-version = token

   Registrations should be allowed on a First Come First Served basis as
   described in BCP 26 [10]. These specifications need not be IETF
   documents or be subject to IESG review, but should obey the following
   rules:

   1.  A token, once registered, stays registered forever.
   2.  The registration MUST name a responsible party for the
       registration.
   3.  The registration MUST name a point of contact.
   4.  The registration MAY name the documentation required for the
       token.
   5.  The responsible party MAY change the registration at any time.
       The IANA will keep a record of all such changes, and make them
       available upon request.
   6.  The responsible party for the first registration of a "product"
       token MUST approve later registrations of a "version" token
       together with that "product" token before they can be registered.
   7.  If absolutely required, the IESG MAY reassign the responsibility
       for a token. This will normally only be used in the case when a
       responsible party cannot be contacted.

   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol [6].

   It is NOT required that specifications for upgrade tokens be made
   publicly available, but the contact information for the registration
   SHOULD be.

8. Security Considerations

   The potential for a man-in-the-middle attack (deleting the Upgrade
   header) remains the same as current, mixed http/https practice:

   o  Removing the Upgrade header is similar to rewriting web pages to
      change https:// links to http:// links.
   o  The risk is only present if the server is willing to vend such
      information over both a secure and an insecure channel in the
      first place.
   o  If the client knows for a fact that a server is TLS-compliant, it
      can insist on it by only sending an Upgrade request with a no-op
      method like OPTIONS.
   o  Finally, as the https: specification warns, "users should
      carefully examine the certificate presented by the server to
      determine if it meets their expectations".




Khare & Lawrence            Standards Track                     [Page 9]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


   Furthermore, for clients that do not explicitly try to invoke TLS,
   servers can use the Upgrade header in any response other than 101 or
   426 to advertise TLS compliance. Since TLS compliance should be
   considered a feature of the server and not the resource at hand, it
   should be sufficient to send it once, and let clients cache that
   fact.

8.1 Implications for the https: URI Scheme

   While nothing in this memo affects the definition of the 'https' URI
   scheme, widespread adoption of this mechanism for HyperText content
   could use 'http' to identify both secure and non-secure resources.

   The choice of what security characteristics are required on the
   connection is left to the client and server.  This allows either
   party to use any information available in making this determination.
   For example, user agents may rely on user preference settings or
   information about the security of the network such as 'TLS required
   on all POST operations not on my local net', or servers may apply
   resource access rules such as 'the FORM on this page must be served
   and submitted using TLS'.

8.2 Security Considerations for CONNECT

   A generic TCP tunnel is fraught with security risks. First, such
   authorization should be limited to a small number of known ports.
   The Upgrade: mechanism defined here only requires onward tunneling at
   port 80. Second, since tunneled data is opaque to the proxy, there
   are additional risks to tunneling to other well-known or reserved
   ports. A putative HTTP client CONNECTing to port 25 could relay spam
   via SMTP, for example.

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.

   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
        Syntax", RFC 2396, August 1998.

   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
        "Web Distributed Authoring and Versioning", RFC 2518, February
        1999.





Khare & Lawrence            Standards Track                    [Page 10]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
        Protocol",  Work In Progress.

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

   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
        1999.

   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)

   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
        1999.

   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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

Authors' Addresses

   Rohit Khare
   4K Associates / UC Irvine
   3207 Palo Verde
   Irvine, CA  92612
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.4K-associates.com/


   Scott Lawrence
   Agranat Systems, Inc.
   5 Clocktower Place
   Suite 400
   Maynard, MA  01754
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.agranat.com/





Khare & Lawrence            Standards Track                    [Page 11]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


Appendix A. Acknowledgments

   The CONNECT method was originally described in a Work in Progress
   titled, "Tunneling TCP based protocols through Web proxy servers",
   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
   widely implemented by HTTP proxies, but was never made a part of any
   IETF Standards Track document. The method name CONNECT was reserved,
   but not defined in [1].

   The definition provided here is derived directly from that earlier
   memo, with some editorial changes and conformance to the stylistic
   conventions since established in other HTTP specifications.

   Additional Thanks to:

   o  Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP.
   o  Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.
   o  Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.
   o  Marshall Rose, for the xml2rfc document type description and tools
      [9].
   o  Jim Whitehead, for sorting out the current range of available HTTP
      status codes.
   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
      mechanism pointed out a hop-by-hop Upgrade still requires
      tunneling.
   o  Harald Alvestrand for improvements to the token registration
      rules.





















Khare & Lawrence            Standards Track                    [Page 12]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


Full Copyright Statement

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



















Khare & Lawrence            Standards Track                    [Page 13]