Network Working Group R. Khare Internet-Draft 4K Associates / UC Irvine Expires:
December 21, 1999February 15, 2000 S. Lawrence Agranat Systems, Inc. June 22,August 17, 1999 Upgrading to TLS Within HTTP/1.1 draft-ietf-tls-http-upgrade-01.txtdraft-ietf-tls-http-upgrade-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 1999.February 15, 2000. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo appliesexplains how to use the Upgrade mechanism in HTTP/1.1 to employinitiate 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). ThisIt also enables "virtual hosting," by allowingso a single HTTP + TLS server tocan disambiguate traffic intended for several hostnames at a single IP address. ThisSince HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this memo also clarifies how to exploitdocuments the HTTP/1.1 Upgrade mechanism in general. It createsHTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, andas well as public or private Upgrade product tokens. This memo also argues thatdoes NOT affect the current definition of the 'https' is insufficient to discriminate between secure and non-secure URIs, and henceforth http: alone should be used. That is to say, both https:URI scheme, which already defines a separate namespace (http://example.org/ and port 443 could be safely deprecated upon deployment of this mechanism.https://example.org/ are not equivalent). Status Notes This memo is intended to proceed directly to Proposed Standard, since its functionality has been extensively debated, but not implemented, over the last two years. It is expected to update RFC 2616. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4 3.1 RequestingOptional Upgrade When Unsecured Is Not Acceptable. . . . . . . . . . . . . . . . . . . . . . . 4 3.2 RequestingMandatory Upgrade When Unsecured Is Acceptable. . . . . . . . . . . . . . . . . . . . . . 4 3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 5 4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5 4.1 Server Required Upgrade to HTTP over TLSOptional Advertisement . . . . . . . . . . . . . . . . . . . . 5 4.2 Server Advertised HTTP over TLSMandatory Advertisement . . . . . . . . . . . . . . . 6. . . . 5 5. HTTPUpgrade Usage Considerationsacross Proxies . . . . . . . . . . . . . . . . . . . . 6 5.1 Upgrading across HTTP ProxiesImplications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6 5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6 6. Rationale for the use of5.3 Establishing a 4xx (client error) response codeTunnel with CONNECT . . . . . 7 7. Rationale for the HTTP+TLS/1.0 Upgrade token. . . . . . . . . 7 8.6. Rationale for the use of a 4xx (client error) Status Code . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8.17.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8 8.27.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8 9.8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9.18.1 Implications for the https: URI Scheme . . . . . . . . . . . . 9 References10 8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 1011 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 1. Motivation The historical practice forof deploying HTTP over SSL3SSL3  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. Other protocolsParallel well-known port numbers have similarly been requested (and-- and in some cases were issued) a second well known port so that they cancases, granted -- to distinguish thebetween secured and unsecured modesuse of operation in this way as well. Taken to its extreme, thisother application protocols (e.g. snews, ftps). This approach in effect cuts in halfeffectively halves the number of available well known ports. At the Washington DC IETF meeting in December 1997, the Applications Area Directors,Directors and the IESG broadly,reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can indeedapply Transport Layer SecuritySecurity to an open HTTP connection, over the same port.connection. 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. However,In fact, nothing in this memo affects the Internet Printing Protocol, onecurrent interpretation of the firsthttps: URIs. However, new application protocols built atop HTTP, has calledsuch as the Internet Printing Protocol, call for just such a mechanism in order to move forwardahead in the IETF standards process. 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. 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. 2. Introduction Either the client or server can use the HTTP/1.1 Upgrade mechanism (Section 14.42) to indicate that a TLS-secured connection is desired or necessary. This draft defines the "HTTP+TLS/1.0" Upgrade token and a new HTTP Reply Code, "426 Upgrade Required".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. This specification provides a procedure for either aEither the client or server can use the HTTP/1.1 Upgrade mechanism (Section 14.42) to requestindicate that this TLS handshake phase begin ona TLS-secured connection is desired or necessary. This draft defines the "TLS/1.0" Upgrade token, and a new HTTP Status Code, "426 Upgrade Required". Section 3 and Section 4 describe the operation of a directly connected client and server. Intermediate proxies must establish an existing HTTP/1.1 connection.end-to-end tunnel before applying those operations, as explained in Section 5. 3. Client Requested Upgrade to HTTP over TLS TheWhen the client sends an HTTP/1.1 request with an Upgrade header field containing the token "HTTP+TLS/1.0". 3.1 Requesting Upgrade When Unsecured Is Not Acceptable To"TLS/1.0", it is requesting the server to complete the current HTTP/1.1 request after switching to TLS/1.0. 3.1 Optional Upgrade A client MAY offer to switch to secured operation before sendingduring any clear HTTP traffic, the client MAY use a method such as "OPTIONS*". OPTIONS * HTTP/1.1 Host: bank.example.com Upgrade: HTTP+TLS/1.0 Connection: Upgrade The client MUST use the OPTIONS method ifrequest when an unsecured operation is unacceptable. 3.2 Requesting Upgrade When Unsecured Is Acceptable The client MAY offer to switch to secured operation during a clear HTTP operation:response would be acceptable: GET http://bank.example.com/acct_stat.html?749394889300http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 Host: bank.example.comexample.bank.com Upgrade: HTTP+TLS/1.0TLS/1.0 Connection: Upgrade In this case, the server MAY respond to the clear HTTP operation normally, OR switch to secured operation (as detailed in the next section). Note that HTTP/1.1 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." 3.2 Mandatory Upgrade 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). OPTIONS * HTTP/1.1 Host: example.bank.com Upgrade: TLS/1.0 Connection: Upgrade 3.3 Server Acceptance of Upgrade Request As specified in HTTP/1.1, 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 upgradetokens of the protocol stack it is switching to: HTTP/1.1 101 Switching Protocols Upgrade: HTTP+TLS/1.0 The TLS handshake bytes begin afterTLS/1.0, HTTP/1.1 Connection: Upgrade Note that the protocol tokens listed in the final CRNLUpgrade header of a 101 Switching Protocols response specify an ordered 'bottom-up' stack. As specified in HTTP/1.1, Section 10.1.2: "The server will switch protocols to those defined by the HTTP response. Ifresponse's Upgrade header field immediately after the empty line which terminates the 101 response." Once the TLS handshake completes,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. In the 'required upgrade' case described in Section 3.1, the client will send the real request after the OPTIONS ("no-op") request has completed.4. Server Requested Upgrade to HTTP over TLS 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 be used in HTTP responses toadvertise server policy.the exact protocol upgrade(s) that a client MUST accept to complete the request. 4.1 Server RequiredOptional Advertisement As specified in HTTP/1.1, the server MAY include an Upgrade header in any response other than 101 or 426 to HTTP over TLSindicate a willingness to switch to any (combination) of the protocols listed. 4.2 Mandatory Advertisement A server canMAY indicate that a client request can not be fulfilledcompleted without TLS secured operationusing the "426 Upgrade Required" status code [see Section 6 for the rationale for why this is not a 3xx redirect response]. The 426 responsecode, which MUST include an an Upgrade header field specifying the token forof the required TLS version. HTTP/1.1 426 Upgrade Required Upgrade: HTTP+TLS/1.0 ... The server cannot know whether or not the client is willing or able to Upgrade. The use of 426 means that the request has failed, as any 4xx code would. This has two important implications: 1.TLS/1.0, HTTP/1.1 Connection: Upgrade 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. 2. Neither the server nor theNote that even if a client can immediately beginis willing to use TLS, it must use the operations in Section 3 to proceed; the TLS handshake -- a new request must be made, whether over the same TCP connection or not. Ifcannot begin immediately after the client426 response. 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is capablenegotiated between each pair of the protocol set specified by the server in theHTTP counterparties. If a User Agent sends a request with an Upgrade header ofto a 426 response,proxy, it MAY beginis requesting a client-initiated sequence as specified in Section 3change to repeatthe request. [Sinceprotocol between itself and the original request was presumably sentproxy, not an end-to-end change. Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks, this memo specifies the clear, the Section 3.2CONNECT method reduce the numberto establish a tunnel across proxies. Once a tunnel is established, any of round-tripsthe operations in this case] 4.2 Server Advertised HTTP overSection 3 can be used to establish a TLS As specified in [HTTP], theconnection. 5.1 Implications of Hop By Hop Upgrade If an origin server MAY includereceives an Upgrade header in any response to indicatefrom a willingnessproxy 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 switchits client to any (combination)change the protocol on that connection independently of the protocols listed. Onlyit is using to communicate toward the origin server. These scenarios also complicate diagnosis of a 101 or426 response listsresponse. Since Upgrade tokensis a hop-by-hop header, a proxy that MUST be used to successfully completedoes not recognize 426 might remove the request. 5. HTTPaccompanying Upgrade Usage Considerations Inheader and prevent the course of formalizing this mechanism, several principlesclient 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 Section 5.2 and repeat the request in order to obtain the required upgrade information. This hop-by-hop definition of HTTPUpgrade usage have been clarifiedwas a deliberate choice. It allows for future users. o Servers MUST select at most oneincremental deployment on either side of proxies, and for optimized protocols between cascaded proxies without the offered Upgrade tokens inknowledge of the 101 Switching Protocols response. o This impliesparties that Upgrade tokens represent "bundles"are not a part of functionality. Skippingthe change. 5.2 Requesting a sequential upgrade to X/1.0 then to Y/1.0 would require definingTunnel with CONNECT A CONNECT method requests that a joint XY/1.0 token, for example. o This implies public Upgrade tokens should be managedproxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line is always an 'authority' as defined by IANA, accordingURI Generic Syntax, which is to say the process in . o Reliable deploymenthost name and port number destination of new protocol extensions requiresthe requested connection separated by a definitive failure error, "426 Upgrade Required" in this case. This is broadly useful for any Upgrade usage. Note that since Upgrade was only defined incolon: CONNECT server.example.com:80 HTTP/1.1 (and above), upgraded protocols can assume persistent-connections by default. 5.1 Upgrading acrossHost: server.example.com:80 Other HTTP Proxies As a hop-by-hop header, Upgrade mustmechanisms can be negotiated between each pair of HTTP counterparties. As an end-to-end protocol, HTTP+TLS/1.0 is only applicable across tunnels. The HTTPused normally with the CONNECT method explicitly constructed-- except end-to-end protocol Upgrade requests, of course, since the tunnel must be established first. For example, proxy authentication might be used to establish the authority to create a tunnel, but it requires unique port numberstunnel: CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 Proxy-Authorization: basic aGVsbG86d29ybGQ= Like any other pipelined HTTP/1.1 request, data to disambiguate services.be tunneled may be sent immediately after the blank line. The following rules applyusual 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. 5.3 Establishing a Tunnel with CONNECT Any successful (2xy) response to relaying Upgrade requests: 1. Upon receipt of an Upgrade header field,a CONNECT request indicates that the proxy server MUST either discard allhas established a connection to the offers, or chooserequested host and port, and has switched to forward only those it agreestunneling the current connection to becomethat server connection. 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 tunnel for. 2. Upon receiptCONNECT request of that next proxy, requesting a "101 Switching Protocols" response, atunnel to the authority. A proxy serverMUST becomeNOT respond with any 2xy status code unless it has either a tunnel,direct or report a more detailed proxytunnel connection established to the authority. An origin server error. Furthermorewhich receives a caching proxy SHOULD not replyCONNECT request for itself MAY respond with a 2xy status code to indicate that a request with Upgrade tokensconnection is established. If at any point either one of the peers gets disconnected, any outstanding data that came from its cache. Clients are still advisedthat peer will be passed to explicitly include "Cache-control: no-cache" in this case. Notethe other one, and after that these scenarios slightly complicate diagnosis of a 426-status response. Since Upgrade: is a hop-by-hop header, a proxy may have removedalso the client's original Upgrade request, whileother connection will be terminated by the origin server continuesproxy. If there is outstanding data to insist no offer was received.that peer undelivered, that data will be discarded. 6. Rationale for the use of a 4xx (client error) response codeStatus 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. Otherwise, there would be no solution in the Section 4.1 case.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:this. Suppose that thea 3xx code 3YZhad 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 HTTP+TLS/1.0,incorporate the TLS layer, it would at best fail again at the new URL. 7. Rationale for the HTTP+TLS/1.0 Upgrade token While TLS (and SSL) are properly ignorant of the syntax and semantics of encapsulated, encrypted traffic, it remains inappropriate to infer the protocol being secured by TCP port number. To reinforce the point that the upgraded protocol is now the composition of HTTP and TLS/1.0, we explicitly named the Upgrade token HTTP+TLS/1.0. Note that the version number in the product token refers to the version of TLS employed; the version of HTTP to be used over TLS following the switch is calculated normally, viz. per the version compatibility rules of HTTP. [Note that while TLS is compatible with previous versions of SSL, they do not have TLS version numbers. If there were a backwards-compatible Upgrade, it might have specified HTTP+SSL/3.0 instead.] Purely HTTP-compliant extensions such as IPP will reuse HTTP+TLS/1.0, while derivative works such as the Session Initiation Protocol are encouraged to define their own Upgrade mechanism and their own tokens. 8.IANA Considerations IANA shall create registries for two name spaces, as described in BCP 26:26: o HTTP Status Codes o HTTP Upgrade Tokens 8.17.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 2. Web Distributed Authoring and VersioningVersioning [defines 420-424] 3. WebDAV Advanced CollectionsCollections (Work in Progress) [defines 425] 4. sectionSection 6 of this specification.[defines[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. 8.27.2 HTTP Upgrade Token Registry The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the theUpgrade 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 specifies that these tokens obey the production for 'product': product = token ["/" product-version] product-version = token Registrations should be allowed on a First Come First Served basis as described in BCP 26.26. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules: 1. The registration for a given token MUST NOT be changed once registered. 2. The registry MUST NOT register a token whose 'product' component is the same as that of an already registered token, unless the source of the authority for the registration is the same as the previous registry (if company XYZ, Inc. registered "XYZ/1.0", then no other entity should be allowed to register any token whose product component is "XYZ" without the consent of XYZ, Inc. An initial value in this namespace is defined in Section Section 7 of this specification.This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol. It is NOT required that specifications for upgrade tokens be made publicallypublicly available, but the contact information for the registration SHOULD be. 9.8. Security Considerations The potential for a man-in-the-middle attack (deleting the HTTP+TLS/1.0 upgrade token)Upgrade header) remains the same as current, mixed http/https practice: o Removing the Upgrade tokenheader 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 thatsuch 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 connecting as https: (currently) or by onlysending 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." -- there is no substitute for vigilance.it meets their expectations." Furthermore, for clients whichthat do not activelyexplicitly try to invoke TLS, servers can use Upgrade:the Upgrade header in any response other than 101 or 426 to advertise TLS compliance, too.compliance. Since TLS-complianceTLS 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. 9.18.1 Implications for the https: URI Scheme This mechanism does not useWhile nothing in this memo affects the URI scheme name to indicatedefinition of the protocol used. That is, any http:'https' URI scheme, widespread adoption of this mechanism for HyperText content could be upgraded;use 'http' to identify both secure and that https: URIs are no guarantee the server will upgrade. Instead, thenon-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 netnet', or VPN', andservers may apply resource access rules such as 'the formFORM on this page must be served and submitted using TLS'. This also implies both parties have the option of fallback8.2 Security Considerations for CONNECT A generic TCP tunnel is fraught with security risks. First, such authorization should be limited to a less secure modesmall number of operation if either party cannot shift to TLS and such unsecured operationknown ports. The Upgrade: mechanism defined here only requires onward tunneling at port 80. Second, since tunneled data is acceptable to both andopaque to the human user; this is not possible with the 'https' scheme.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  Fielding, R.T.,R.T. and et. al, ,"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.  Berners-Lee, T., Fielding, R.T. and L. Masinter, "URI Generic Syntax", RFC 2396, August 1998.  Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In Progress),Progress) draft-ietf-tls-https-02, September 1998.  Goland, Y.Y., Whitehead, E.J.,E.J. and et. al, ,"Web Distributed Authoring and Versioning", RFC 2518, February 1999.  Slein, J., Whitehead, E.J.,E.J. and et. al, ,"WebDAV Advanced Collections Protocol", Internet-Draft (Work in Progress),In Progress) draft-ietf-webdav-collection-protocol-04, June 1999.  Dierks, T.,T. and C. Allen, C.,"The TLS Protocol", RFC 2246, January 1999.  Herriot, R., Butler, S., Moore, P.,P. and R. Turner, R.,"Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.  Luotonen, A., "Tunneling TCP based protocols through Web proxy servers", Internet-Draft (Work In Progress) draft-luotonen-web-proxy-tunneling-01, August 1998.  Rose, M.T., "Writing I-Ds and RFCs using XML", AprilRFC 2629, June 1999.  Narten, T.,T. and H.T. Alvestrand, H.,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, October 1998. Authors' Addresses Rohit Khare 4K Associates / UC Irvine 3207 Palo Verde Irvine, CA 92612 US Phone: +1 626 806 7574 EMail: rohit@4K-associates.com URI: http://www.4K-associates.com/ Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place Suite 400 Maynard, MA 01754 US Phone: +1 978 461 0888 EMail: firstname.lastname@example.org URI: http://www.agranat.com/ Appendix A. Acknowledgments The CONNECT method was originally described in an Internet-Draft titled Tunneling TCP based protocols through Web proxy servers 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 . The definition provided here is derived directly from that earlier draft, 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.tools. 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. 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 implmentation 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.