source: draft-ietf-httpbis/orig/rfc2817.xml @ 682

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>

<!DOCTYPE rfc [
  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
]>

<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" number="2817" updates="2616" category="std">
  <front>
    <title>Upgrading to TLS Within HTTP/1.1</title>
    <author initials='R.' surname='Khare' fullname='Rohit Khare'>
      <organization>4K Associates / UC Irvine</organization>
      <address><email>rohit@4K-associates.com</email></address>
    </author>
    <author initials='S.' surname='Lawrence' fullname='Scott Lawrence'>
      <organization>Agranat Systems, Inc.</organization>
      <address><email>lawrence@agranat.com</email></address>
    </author>
    <date year='2000' month='May' />
    <abstract>
<t>
   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
   initiate Transport Layer Security (TLS) over an existing TCP
   connection. This allows unsecured and secured HTTP traffic to share
   the same well known port (in this case, http: at 80 rather than
   https: at 443). It also enables "virtual hosting", so a single HTTP +
   TLS server can disambiguate traffic intended for several hostnames at
   a single IP address.
</t>
<t>
   Since HTTP/1.1 <xref target="RFC2616"/> defines Upgrade as a hop-by-hop mechanism, this
   memo also documents the HTTP CONNECT method for establishing end-to-end
   tunnels across HTTP proxies. Finally, this memo establishes new
   IANA registries for public HTTP status codes, as well as public or
   private Upgrade product tokens.
</t>
<t>
   This memo does NOT affect the current definition of the 'https' URI
   scheme, which already defines a separate namespace
   (http://example.org/ and https://example.org/ are not equivalent).
</t>
    </abstract>
  </front>
  <middle>
<section title="Motivation">
<t>
   The historical practice of deploying HTTP over SSL3 <xref target="RFC2818"/> has
   distinguished the combination from HTTP alone by a unique URI scheme
   and the TCP port number. The scheme 'http' meant the HTTP protocol
   alone on port 80, while 'https' meant the HTTP protocol over SSL on
   port 443.  Parallel well-known port numbers have similarly been
   requested -- and in some cases, granted -- to distinguish between
   secured and unsecured use of other application protocols (e.g.
   snews, ftps). This approach effectively halves the number of
   available well known ports.
</t>
<t>
   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security <xref target="RFC2246"/> to an open
   HTTP connection.
</t>
<t>
   In the nearly two years since, there has been broad acceptance of the
   concept behind this proposal, but little interest in implementing
   alternatives to port 443 for generic Web browsing. In fact, nothing
   in this memo affects the current interpretation of https: URIs.
   However, new application protocols built atop HTTP, such as the
   Internet Printing Protocol <xref target="RFC2565"/>, call for just such a mechanism in
   order to move ahead in the IETF standards process.
</t>
<t>
   The Upgrade mechanism also solves the "virtual hosting" problem.
   Rather than allocating multiple IP addresses to a single host, an
   HTTP/1.1 server will use the Host: header to disambiguate the
   intended web service. As HTTP/1.1 usage has grown more prevalent,
   more ISPs are offering name-based virtual hosting, thus delaying IP
   address space exhaustion.
</t>
<t>
   TLS (and SSL) have been hobbled by the same limitation as earlier
   versions of HTTP: the initial handshake does not specify the intended
   hostname, relying exclusively on the IP address. Using a cleartext
   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
   certificates based on the initial Host: header -- will allow ISPs to
   provide secure name-based virtual hosting as well.
</t>
</section>

<section title="Introduction">
<t>
   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end
   connection, optionally including strong mutual authentication,
   using a variety of cryptosystems. Initially, a handshake phase uses
   three subprotocols to set up a record layer, authenticate endpoints,
   set parameters, as well as report errors.  Then, there is an ongoing
   layered record protocol that handles encryption, compression, and
   reassembly for the remainder of the connection. The latter is
   intended to be completely transparent. For example, there is no
   dependency between TLS's record markers and or certificates and
   HTTP/1.1's chunked encoding or authentication.
</t>
<t>
   Either the client or server can use the HTTP/1.1 <xref target="RFC2616"/> Upgrade
   mechanism (<xref target="RFC2616" x:fmt="sec" x:sec="14.42"/>) to indicate that a TLS-secured connection
   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
   token, and a new HTTP Status Code, "426 Upgrade Required".
</t>
<t>
   <xref target="client.requested.upgrade.to.http.over.tls"/> and <xref target="server.requested.upgrade.to.http.over.tls"/> describe the operation of a directly
   connected client and server. Intermediate proxies must establish an
   end-to-end tunnel before applying those operations, as explained in
   <xref target="upgrade.across.proxies"/>.
</t>

<section title="Requirements Terminology">
<t>
   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC 2119 <xref target="RFC2119"/>.
</t>
</section>

</section>

<section title="Client Requested Upgrade to HTTP over TLS" anchor="client.requested.upgrade.to.http.over.tls">
<t>
   When the client sends an HTTP/1.1 request with an Upgrade header
   field containing the token "TLS/1.0", it is requesting the server to
   complete the current HTTP/1.1 request after switching to TLS/1.0.
</t>

<section title="Optional Upgrade">
<t>
   A client &MAY; offer to switch to secured operation during any clear
   HTTP request when an unsecured response would be acceptable:
</t>
<figure><artwork type='message/http: msgtype="request"'>
    GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
    Host: example.bank.com
    Upgrade: TLS/1.0
    Connection: Upgrade
</artwork></figure>
<t>
   In this case, the server &MAY; respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   section).
</t>
<t>   
   Note that HTTP/1.1 <xref target="RFC2616"/> specifies "the upgrade keyword &MUST; be
   supplied within a Connection header field (section 14.10) whenever
   Upgrade is present in an HTTP/1.1 message".
</t>
</section>

<section title="Mandatory Upgrade">
<t>
   If an unsecured response would be unacceptable, a client &MUST; send an
   OPTIONS request first to complete the switch to TLS/1.0 (if
   possible).
</t>
<figure><artwork type='message/http: msgtype="request"'>
    OPTIONS * HTTP/1.1
    Host: example.bank.com
    Upgrade: TLS/1.0
    Connection: Upgrade
</artwork></figure>
</section>

<section title="Server Acceptance of Upgrade Request">
<t>
   As specified in HTTP/1.1 <xref target="RFC2616"/>, if the server is prepared to initiate
   the TLS handshake, it &MUST; send the intermediate "101 Switching
   Protocol" and &MUST; include an Upgrade response header specifying the
   tokens of the protocol stack it is switching to:
</t>
<figure><artwork type='message/http: msgtype="response"'>
    HTTP/1.1 101 Switching Protocols
    Upgrade: TLS/1.0, HTTP/1.1
    Connection: Upgrade
</artwork></figure>
<t>
   Note that the protocol tokens listed in the Upgrade header of a 101
   Switching Protocols response specify an ordered 'bottom-up' stack.
</t>
<t>
   As specified in  HTTP/1.1 <xref target="RFC2616" x:fmt="," x:sec="10.1.2"/>: "The server will
   switch protocols to those defined by the response's Upgrade header
   field immediately after the empty line which terminates the 101
   response".
</t>
<t>
   Once the TLS handshake completes successfully, the server &MUST;
   continue with the response to the original request. Any TLS handshake
   failure &MUST; lead to disconnection, per the TLS error alert
   specification.
</t>
</section>
</section>  

<section title="Server Requested Upgrade to HTTP over TLS" anchor="server.requested.upgrade.to.http.over.tls">
<t>
   The Upgrade response header field advertises possible protocol
   upgrades a server &MAY; accept. In conjunction with the "426 Upgrade
   Required" status code, a server can advertise the exact protocol
   upgrade(s) that a client &MUST; accept to complete the request.
</t>

<section title="Optional Advertisement">
<t>
   As specified in HTTP/1.1 <xref target="RFC2616"/>, the server &MAY; include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed.
</t>
</section>

<section title="Mandatory Advertisement">
<t>
   A server &MAY; indicate that a client request can not be completed
   without TLS using the "426 Upgrade Required" status code, which &MUST;
   include an an Upgrade header field specifying the token of the
   required TLS version.
</t>
<figure><artwork type='message/http: msgtype="request"'>
    HTTP/1.1 426 Upgrade Required
    Upgrade: TLS/1.0, HTTP/1.1
    Connection: Upgrade
</artwork></figure>
<t>
   The server &SHOULD; include a message body in the 426 response which
   indicates in human readable form the reason for the error and
   describes any alternative courses which may be available to the user.
</t>
<t>
   Note that even if a client is willing to use TLS, it must use the
   operations in <xref target="client.requested.upgrade.to.http.over.tls"/> to proceed; the TLS handshake cannot begin
   immediately after the 426 response.
</t>
</section>
</section>

<section title="Upgrade across Proxies" anchor="upgrade.across.proxies">
<t>
   As a hop-by-hop header, Upgrade is negotiated between each pair of
   HTTP counterparties.  If a User Agent sends a request with an Upgrade
   header to a proxy, it is requesting a change to the protocol between
   itself and the proxy, not an end-to-end change.
</t>
<t>
   Since TLS, in particular, requires end-to-end connectivity to provide
   authentication and prevent man-in-the-middle attacks, this memo
   specifies the CONNECT method to establish a tunnel across proxies.
</t>
<t>
   Once a tunnel is established, any of the operations in <xref target="client.requested.upgrade.to.http.over.tls"/> can
   be used to establish a TLS connection.
</t>

<section title="Implications of Hop By Hop Upgrade">
<t>
   If an origin server receives an Upgrade header from a proxy and
   responds with a 101 Switching Protocols response, it is changing the
   protocol only on the connection between the proxy and itself.
   Similarly, a proxy might return a 101 response to its client to
   change the protocol on that connection independently of the protocols
   it is using to communicate toward the origin server.
</t>
<t>
   These scenarios also complicate diagnosis of a 426 response.  Since
   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
   might remove the accompanying Upgrade header and prevent the client
   from determining the required protocol switch.  If a client receives
   a 426 status without an accompanying Upgrade header, it will need to
   request an end to end tunnel connection as described in <xref target="requesting.a.tunnel.with.connect"/>
   and repeat the request in order to obtain the required upgrade
   information.
</t>
<t>
   This hop-by-hop definition of Upgrade was a deliberate choice.  It
   allows for incremental deployment on either side of proxies, and for
   optimized protocols between cascaded proxies without the knowledge of
   the parties that are not a part of the change.
</t>
</section>

<section title="Requesting a Tunnel with CONNECT" anchor="requesting.a.tunnel.with.connect">
<t>
   A CONNECT method requests that a proxy establish a tunnel connection
   on its behalf. The Request-URI portion of the Request-Line is always
   an 'authority' as defined by URI Generic Syntax <xref target="RFC2396"/>, which is to say
   the host name and port number destination of the requested connection
   separated by a colon:
</t>
<figure><artwork type='message/http: msgtype="request"'>
   CONNECT server.example.com:80 HTTP/1.1
   Host: server.example.com:80
</artwork></figure>
<t>
   Other HTTP mechanisms can be used normally with the CONNECT method --
   except end-to-end protocol Upgrade requests, of course, since the
   tunnel must be established first.
</t>
<t>
   For example, proxy authentication might be used to establish the
   authority to create a tunnel:
</t>
<figure><artwork type='message/http: msgtype="request"'>
   CONNECT server.example.com:80 HTTP/1.1
   Host: server.example.com:80
   Proxy-Authorization: basic aGVsbG86d29ybGQ=
</artwork></figure>
<t>
   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
   sent immediately after the blank line. The usual caveats also apply:
   data may be discarded if the eventual response is negative, and the
   connection may be reset with no response if more than one TCP segment
   is outstanding.
</t>
</section>

<section title="Establishing a Tunnel with CONNECT">
<t>
   Any successful (2xx) response to a CONNECT request indicates that the
   proxy has established a connection to the requested host and port,
   and has switched to tunneling the current connection to that server
   connection.
</t>
<t>
   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.
</t>
<t>
   An origin server which receives a CONNECT request for itself &MAY;
   respond with a 2xx status code to indicate that a connection is
   established.
</t>
<t>
   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.
</t>
</section>
</section>

<section title="Rationale for the use of a 4xx (client error) Status Code" anchor="rationale.for.the.use.of.a.4xx.status.code">
<t>
   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.
</t>
<t>
   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.
</t>
<t>
   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.
</t>
</section>

<section title="IANA Considerations">
<t>
   IANA shall create registries for two name spaces, as described in BCP
   26 <xref target="RFC2434"/>:
  <list style="symbols">
    <t>HTTP Status Codes</t>
    <t>HTTP Upgrade Tokens</t>
  </list>
</t>

<section title="HTTP Status Code Registry">
<t>
   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:
  <list style="numbers">
    <t>Draft Standard for HTTP/1.1 <xref target="RFC2616"/></t>
    <t>Web Distributed Authoring and Versioning <xref target="RFC2518"/> [defines 420-424]</t>
    <t>WebDAV Advanced Collections <xref target="ADVCOL"/> (Work in Progress) [defines 425]</t>
    <t><xref target="rationale.for.the.use.of.a.4xx.status.code"/> [defines 426]</t>
  </list>
</t>
<t>
   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 <xref target="RFC2616"/>.
</t>
</section>

<section title="HTTP Upgrade Token Registry">
<t>
   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.
</t>
<t>
   The Draft Standard for HTTP/1.1 <xref target="RFC2616"/> specifies that these tokens obey
   the production for 'product':
</t>
<figure><artwork type="abnf2616">
   product         = token ["/" product-version]
   product-version = token
</artwork></figure>
<t>
   Registrations should be allowed on a First Come First Served basis as
   described in BCP 26 <xref target="RFC2434"/>. These specifications need not be IETF
   documents or be subject to IESG review, but should obey the following
   rules:
  <list style="numbers">
    <t>A token, once registered, stays registered forever.</t>
    <t>The registration &MUST; name a responsible party for the
       registration.</t>
    <t>The registration &MUST; name a point of contact.</t>
    <t>The registration &MAY; name the documentation required for the
       token.</t>
    <t>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.</t>
    <t>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.</t>
    <t>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.</t>
  </list>
</t>
<t>
   This specification defines the protocol token "TLS/1.0" as the
   identifier for the protocol specified by The TLS Protocol <xref target="RFC2246"/>.
</t>
<t>
   It is NOT required that specifications for upgrade tokens be made
   publicly available, but the contact information for the registration
   &SHOULD; be.
</t>
</section>
</section>

<section title="Security Considerations">
<t>
   The potential for a man-in-the-middle attack (deleting the Upgrade
   header) remains the same as current, mixed http/https practice:
  <list style="symbols">
    <t>Removing the Upgrade header is similar to rewriting web pages to
      change https:// links to http:// links.</t>
    <t>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.</t>
    <t>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.</t>
    <t>Finally, as the https: specification warns, "users should
      carefully examine the certificate presented by the server to
      determine if it meets their expectations".</t>
  </list>
</t>
<t>
   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.
</t>

<section title="Implications for the https: URI Scheme">
<t>
   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.
</t>
<t>
   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'.
</t>
</section>

<section title="Security Considerations for CONNECT">
<t>
   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.
</t>
</section>
</section>

  </middle>
  <back>
<references>

<reference anchor="RFC2616">
  <front>
    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
    <author initials="R." surname="Fielding" fullname="R. Fielding">
      <organization>University of California, Irvine</organization>
      <address><email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials="J." surname="Gettys" fullname="J. Gettys">
      <organization>W3C</organization>
      <address><email>jg@w3.org</email></address>
    </author>
    <author initials="J." surname="Mogul" fullname="J. Mogul">
      <organization>Compaq Computer Corporation</organization>
      <address><email>mogul@wrl.dec.com</email></address>
    </author>
    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
      <organization>MIT Laboratory for Computer Science</organization>
      <address><email>frystyk@w3.org</email></address>
    </author>
    <author initials="L." surname="Masinter" fullname="L. Masinter">
      <organization>Xerox Corporation</organization>
      <address><email>masinter@parc.xerox.com</email></address>
    </author>
    <author initials="P." surname="Leach" fullname="P. Leach">
      <organization>Microsoft Corporation</organization>
      <address><email>paulle@microsoft.com</email></address>
    </author>
    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
      <organization>W3C</organization>
      <address><email>timbl@w3.org</email></address>
    </author>
    <date month="June" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2616"/>
</reference>

<reference anchor='RFC2396'>
  <front>
    <title abbrev='URI Generic Syntax'>Uniform Resource Identifiers (URI): Generic Syntax</title>
    <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
      <organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
      <address>
      <facsimile>+1(617)258-8682</facsimile>
      <email>timbl@w3.org</email></address>
    </author>
    <author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
      <organization abbrev='U.C. Irvine'>University of California, Irvine</organization>
      <address>
      <facsimile>+1(949)824-1715</facsimile>
      <email>fielding@ics.uci.edu</email></address>
    </author>
    <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
      <organization abbrev='Xerox Corporation'>Xerox PARC</organization>
      <address>
      <facsimile>+1(415)812-4333</facsimile>
      <email>masinter@parc.xerox.com</email></address>
    </author>
    <date month='August' year='1998' />
    <area>Applications</area>
  </front>
  <seriesInfo name='RFC' value='2396' />
</reference>

<reference anchor='RFC2818'>
  <front>
    <title>HTTP Over TLS</title>
    <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
      <organization>RTFM, Inc.</organization>
      <address><email>ekr@rtfm.com</email></address>
    </author>
    <date year='2000' month='May' />
  </front>
  <seriesInfo name='RFC' value='2818' />
</reference>

<reference anchor="RFC2518">
  <front>
    <title>HTTP Extensions for Distributed Authoring -- WEBDAV</title>
    <author initials="Y." surname="Goland" fullname="Y. Goland">
      <organization>Microsoft Corporation</organization>
      <address><email>yarong@microsoft.com</email></address>
    </author>
    <author initials="E." surname="Whitehead" fullname="E. J. Whitehead, Jr.">
      <organization abbrev="UC Irvine">Dept. Of Information and Computer Science, University of California, Irvine</organization>
        <address><email>ejw@ics.uci.edu</email></address>
    </author>
    <author initials="A." surname="Faizi" fullname="A. Faizi">
      <organization abbrev="Netscape">Netscape</organization>
      <address><email>asad@netscape.com</email></address>
    </author>
    <author initials="S.R." surname="Carter" fullname="S. R. Carter">
      <organization abbrev="Novell">Novell</organization>
      <address><email>srcarter@novell.com</email></address>
    </author>
    <author initials="D." surname="Jensen" fullname="D. Jensen">
      <organization abbrev="Novell">Novell</organization>
      <address><email>dcjensen@novell.com</email></address>
    </author>
    <date month="February" year="1999"/>
  </front>
  <seriesInfo name="RFC" value="2518"/>
</reference>

<reference anchor="ADVCOL">
  <front>
    <title>WebDAV Advanced Collection Protocol</title>
    <author initials="J." surname="Slein" fullname="J. Slein">
      <organization/>
    </author>
    <author initials="E.J." surname="Whitehead" fullname="E.J. Whitehead">
      <organization/>
    </author>
    <date/>
  </front>
  <annotation>Work In Progress.</annotation>
</reference>

<reference anchor="RFC2246">
  <front>
    <title>The TLS Protocol Version 1.0</title>
    <author fullname="Tim Dierks" surname="Dierks" initials="T.">
      <organization>Certicom</organization>
      <address>
      <email>tdierks@certicom.com</email></address>
    </author>
    <author fullname="Christopher Allen" surname="Allen" initials="C.">
      <organization>Certicom</organization>
      <address>
      <email>callen@certicom.com</email></address>
    </author>
    <date month="January" year="1999"></date>
  </front>
  <seriesInfo name="RFC" value="2246"></seriesInfo>
</reference>
 
<reference anchor='RFC2565'>
  <front>
    <title abbrev='IPP/1.0: Encoding and Transport'>Internet Printing Protocol/1.0: Encoding and Transport</title>
    <author initials='R.' surname='Herriot' fullname='Robert Herriot'>
      <organization>Xerox Corporation</organization>
      <address>
      <phone>+1 650 813 7696</phone>
      <facsimile>+1 650 813 6860</facsimile>
      <email>rherriot@pahv.xerox.com</email></address>
    </author>
    <author initials='S.' surname='Butler' fullname='Sylvan Butler'>
      <organization>Hewlett-Packard</organization>
      <address>
      <phone>+1 208 396 6000</phone>
      <facsimile>+1 208 396 3457</facsimile>
      <email>sbutler@boi.hp.com</email></address>
    </author>
    <author initials='P.' surname='Moore' fullname='Paul Moore'>
      <organization>Microsoft</organization>
      <address>
      <phone>+1 425 936 0908</phone>
      <facsimile>+1 425 936 7329</facsimile>
      <email>paulmo@microsoft.com</email></address>
    </author>
    <author initials='R.' surname='Turner' fullname='Randy Turner'>
      <organization>Sharp Laboratories</organization>
      <address>
      <phone>+1 360 817 8456</phone>
      <facsimile>+1 360 817 8436</facsimile>
      <email>rturner@sharplabs.com</email></address>
    </author>
    <date year='1999' month='April' />
  </front>
  <seriesInfo name='RFC' value='2565' />
</reference>

<reference anchor="Luo97">
  <front>
    <title>Tunneling TCP based protocols through Web proxy servers</title>
    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
      <organization/>
    </author>
    <date/>
  </front>
  <annotation>
Work In Progress.  (Also available in: Luotonen, Ari.
        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
  </annotation>
</reference>

<reference anchor='RFC2629'>
  <front>
    <title>Writing I-Ds and RFCs using XML</title>
    <author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
      <organization>Invisible Worlds, Inc.</organization>
      <address>
        <postal>
          <street>660 York Street</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94110</code>
          <country>US</country>
        </postal>
        <phone>+1 415 695 3975</phone>
        <email>mrose@not.invisible.net</email>
        <uri>http://invisible.net/</uri>
      </address>
    </author>
    <date month='June' year='1999' />
  </front>
  <seriesInfo name='RFC' value='2629' />
</reference>

<reference anchor="RFC2434">
  <front>
    <title abbrev="Guidelines for IANA Considerations">Guidelines for Writing an IANA Considerations Section in RFCs</title>
    <author initials="T." surname="Narten" fullname="Thomas Narten">
    <organization>IBM Corporation</organization>
    <address>
    <postal>
    <street>3039 Cornwallis Ave.</street>
    <street>PO Box 12195 - BRQA/502</street>
    <street>Research Triangle Park</street>
    <street>NC 27709-2195</street></postal>
    <phone>919-254-7798</phone>
    <email>narten@raleigh.ibm.com</email></address></author>
    <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
    <organization>Maxware</organization>
    <address>
    <postal>
    <street>Pirsenteret</street>
    <street>N-7005 Trondheim</street>
    <country>Norway</country></postal>
    <phone>+47 73 54 57 97</phone>
    <email>Harald@Alvestrand.no</email></address></author>
    <date year="1998" month="October"/>
    <area>General</area>
  </front>
  <seriesInfo name="BCP" value="26"/>
  <seriesInfo name="RFC" value="2434"/>
</reference>

<reference anchor="RFC2119">
  <front>
    <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
    <author initials="S." surname="Bradner" fullname="Scott Bradner">
    <organization>Harvard University</organization>
    <address>
      <email>sob@harvard.edu</email>
    </address></author>
    <date month="March" year="1997"/>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
</reference>

</references>

<section title="Acknowledgments">
<t>
   The CONNECT method was originally described in a Work in Progress
   titled, "Tunneling TCP based protocols through Web proxy servers",
   <xref target="Luo97"/> 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 <xref target="RFC2616"/>.
</t>
<t>
   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.
</t>
<t>  
   Additional Thanks to:
  <list style="symbols">
    <t>Paul Hoffman for his work on the STARTTLS command extension for
      ESMTP.</t>
    <t>Roy Fielding for assistance with the rationale behind Upgrade:
      and its interaction with OPTIONS.</t>
    <t>Eric Rescorla for his work on standardizing the existing https:
      practice to compare with.</t>
    <t>Marshall Rose, for the xml2rfc document type description and tools
      <xref target="RFC2629"/>.</t>
    <t>Jim Whitehead, for sorting out the current range of available HTTP
      status codes.</t>
    <t>Henrik Frystyk Nielsen, whose work on the Mandatory extension
      mechanism pointed out a hop-by-hop Upgrade still requires
      tunneling.</t>
    <t>Harald Alvestrand for improvements to the token registration
      rules.</t>
  </list>
</t>
</section>

  </back>
</rfc>