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

Last change on this file since 598 was 598, checked in by julian.reschke@…, 10 years ago

fix Makefile, add RFC 2817/2818, re-gen HTML

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 32.6 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
3<?rfc toc="yes" ?>
4<?rfc symrefs="no" ?>
5
6<!DOCTYPE rfc [
7  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
8  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
9  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
10  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
11  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
12  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
13  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
14  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
15  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
16  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
17]>
18
19<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" number="2817" updates="2616" category="std">
20  <front>
21    <title>Upgrading to TLS Within HTTP/1.1</title>
22    <author initials='R.' surname='Khare' fullname='Rohit Khare'>
23      <organization>4K Associates / UC Irvine</organization>
24      <address><email>rohit@4K-associates.com</email></address>
25    </author>
26    <author initials='S.' surname='Lawrence' fullname='Scott Lawrence'>
27      <organization>Agranat Systems, Inc.</organization>
28      <address><email>lawrence@agranat.com</email></address>
29    </author>
30    <date year='2000' month='May' />
31    <abstract>
32<t>
33   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
34   initiate Transport Layer Security (TLS) over an existing TCP
35   connection. This allows unsecured and secured HTTP traffic to share
36   the same well known port (in this case, http: at 80 rather than
37   https: at 443). It also enables "virtual hosting", so a single HTTP +
38   TLS server can disambiguate traffic intended for several hostnames at
39   a single IP address.
40</t>
41<t>
42   Since HTTP/1.1 <xref target="RFC2616"/> defines Upgrade as a hop-by-hop mechanism, this
43   memo also documents the HTTP CONNECT method for establishing end-to-end
44   tunnels across HTTP proxies. Finally, this memo establishes new
45   IANA registries for public HTTP status codes, as well as public or
46   private Upgrade product tokens.
47</t>
48<t>
49   This memo does NOT affect the current definition of the 'https' URI
50   scheme, which already defines a separate namespace
51   (http://example.org/ and https://example.org/ are not equivalent).
52</t>
53    </abstract>
54  </front>
55  <middle>
56<section title="Motivation">
57<t>
58   The historical practice of deploying HTTP over SSL3 <xref target="RFC2818"/> has
59   distinguished the combination from HTTP alone by a unique URI scheme
60   and the TCP port number. The scheme 'http' meant the HTTP protocol
61   alone on port 80, while 'https' meant the HTTP protocol over SSL on
62   port 443.  Parallel well-known port numbers have similarly been
63   requested -- and in some cases, granted -- to distinguish between
64   secured and unsecured use of other application protocols (e.g.
65   snews, ftps). This approach effectively halves the number of
66   available well known ports.
67</t>
68<t>
69   At the Washington DC IETF meeting in December 1997, the Applications
70   Area Directors and the IESG reaffirmed that the practice of issuing
71   parallel "secure" port numbers should be deprecated. The HTTP/1.1
72   Upgrade mechanism can apply Transport Layer Security <xref target="RFC2246"/> to an open
73   HTTP connection.
74</t>
75<t>
76   In the nearly two years since, there has been broad acceptance of the
77   concept behind this proposal, but little interest in implementing
78   alternatives to port 443 for generic Web browsing. In fact, nothing
79   in this memo affects the current interpretation of https: URIs.
80   However, new application protocols built atop HTTP, such as the
81   Internet Printing Protocol <xref target="RFC2565"/>, call for just such a mechanism in
82   order to move ahead in the IETF standards process.
83</t>
84<t>
85   The Upgrade mechanism also solves the "virtual hosting" problem.
86   Rather than allocating multiple IP addresses to a single host, an
87   HTTP/1.1 server will use the Host: header to disambiguate the
88   intended web service. As HTTP/1.1 usage has grown more prevalent,
89   more ISPs are offering name-based virtual hosting, thus delaying IP
90   address space exhaustion.
91</t>
92<t>
93   TLS (and SSL) have been hobbled by the same limitation as earlier
94   versions of HTTP: the initial handshake does not specify the intended
95   hostname, relying exclusively on the IP address. Using a cleartext
96   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
97   certificates based on the initial Host: header -- will allow ISPs to
98   provide secure name-based virtual hosting as well.
99</t>
100</section>
101
102<section title="Introduction">
103<t>
104   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end
105   connection, optionally including strong mutual authentication,
106   using a variety of cryptosystems. Initially, a handshake phase uses
107   three subprotocols to set up a record layer, authenticate endpoints,
108   set parameters, as well as report errors.  Then, there is an ongoing
109   layered record protocol that handles encryption, compression, and
110   reassembly for the remainder of the connection. The latter is
111   intended to be completely transparent. For example, there is no
112   dependency between TLS's record markers and or certificates and
113   HTTP/1.1's chunked encoding or authentication.
114</t>
115<t>
116   Either the client or server can use the HTTP/1.1 <xref target="RFC2616"/> Upgrade
117   mechanism (<xref target="RFC2616" x:fmt="sec" x:sec="14.42"/>) to indicate that a TLS-secured connection
118   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
119   token, and a new HTTP Status Code, "426 Upgrade Required".
120</t>
121<t>
122   <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
123   connected client and server. Intermediate proxies must establish an
124   end-to-end tunnel before applying those operations, as explained in
125   <xref target="upgrade.across.proxies"/>.
126</t>
127
128<section title="Requirements Terminology">
129<t>
130   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
131   "MAY" that appear in this document are to be interpreted as described
132   in RFC 2119 <xref target="RFC2119"/>.
133</t>
134</section>
135
136</section>
137
138<section title="Client Requested Upgrade to HTTP over TLS" anchor="client.requested.upgrade.to.http.over.tls">
139<t>
140   When the client sends an HTTP/1.1 request with an Upgrade header
141   field containing the token "TLS/1.0", it is requesting the server to
142   complete the current HTTP/1.1 request after switching to TLS/1.0.
143</t>
144
145<section title="Optional Upgrade">
146<t>
147   A client &MAY; offer to switch to secured operation during any clear
148   HTTP request when an unsecured response would be acceptable:
149</t>
150<figure><artwork type='message/http: msgtype="request"'>
151    GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
152    Host: example.bank.com
153    Upgrade: TLS/1.0
154    Connection: Upgrade
155</artwork></figure>
156<t>
157   In this case, the server &MAY; respond to the clear HTTP operation
158   normally, OR switch to secured operation (as detailed in the next
159   section).
160</t>
161<t>   
162   Note that HTTP/1.1 <xref target="RFC2616"/> specifies "the upgrade keyword &MUST; be
163   supplied within a Connection header field (section 14.10) whenever
164   Upgrade is present in an HTTP/1.1 message".
165</t>
166</section>
167
168<section title="Mandatory Upgrade">
169<t>
170   If an unsecured response would be unacceptable, a client &MUST; send an
171   OPTIONS request first to complete the switch to TLS/1.0 (if
172   possible).
173</t>
174<figure><artwork type='message/http: msgtype="request"'>
175    OPTIONS * HTTP/1.1
176    Host: example.bank.com
177    Upgrade: TLS/1.0
178    Connection: Upgrade
179</artwork></figure>
180</section>
181
182<section title="Server Acceptance of Upgrade Request">
183<t>
184   As specified in HTTP/1.1 <xref target="RFC2616"/>, if the server is prepared to initiate
185   the TLS handshake, it &MUST; send the intermediate "101 Switching
186   Protocol" and &MUST; include an Upgrade response header specifying the
187   tokens of the protocol stack it is switching to:
188</t>
189<figure><artwork type='message/http: msgtype="response"'>
190    HTTP/1.1 101 Switching Protocols
191    Upgrade: TLS/1.0, HTTP/1.1
192    Connection: Upgrade
193</artwork></figure>
194<t>
195   Note that the protocol tokens listed in the Upgrade header of a 101
196   Switching Protocols response specify an ordered 'bottom-up' stack.
197</t>
198<t>
199   As specified in  HTTP/1.1 <xref target="RFC2616" x:fmt="," x:sec="10.1.2"/>: "The server will
200   switch protocols to those defined by the response's Upgrade header
201   field immediately after the empty line which terminates the 101
202   response".
203</t>
204<t>
205   Once the TLS handshake completes successfully, the server &MUST;
206   continue with the response to the original request. Any TLS handshake
207   failure &MUST; lead to disconnection, per the TLS error alert
208   specification.
209</t>
210</section>
211</section> 
212
213<section title="Server Requested Upgrade to HTTP over TLS" anchor="server.requested.upgrade.to.http.over.tls">
214<t>
215   The Upgrade response header field advertises possible protocol
216   upgrades a server &MAY; accept. In conjunction with the "426 Upgrade
217   Required" status code, a server can advertise the exact protocol
218   upgrade(s) that a client &MUST; accept to complete the request.
219</t>
220
221<section title="Optional Advertisement">
222<t>
223   As specified in HTTP/1.1 <xref target="RFC2616"/>, the server &MAY; include an Upgrade
224   header in any response other than 101 or 426 to indicate a
225   willingness to switch to any (combination) of the protocols listed.
226</t>
227</section>
228
229<section title="Mandatory Advertisement">
230<t>
231   A server &MAY; indicate that a client request can not be completed
232   without TLS using the "426 Upgrade Required" status code, which &MUST;
233   include an an Upgrade header field specifying the token of the
234   required TLS version.
235</t>
236<figure><artwork type='message/http: msgtype="request"'>
237    HTTP/1.1 426 Upgrade Required
238    Upgrade: TLS/1.0, HTTP/1.1
239    Connection: Upgrade
240</artwork></figure>
241<t>
242   The server &SHOULD; include a message body in the 426 response which
243   indicates in human readable form the reason for the error and
244   describes any alternative courses which may be available to the user.
245</t>
246<t>
247   Note that even if a client is willing to use TLS, it must use the
248   operations in <xref target="client.requested.upgrade.to.http.over.tls"/> to proceed; the TLS handshake cannot begin
249   immediately after the 426 response.
250</t>
251</section>
252</section>
253
254<section title="Upgrade across Proxies" anchor="upgrade.across.proxies">
255<t>
256   As a hop-by-hop header, Upgrade is negotiated between each pair of
257   HTTP counterparties.  If a User Agent sends a request with an Upgrade
258   header to a proxy, it is requesting a change to the protocol between
259   itself and the proxy, not an end-to-end change.
260</t>
261<t>
262   Since TLS, in particular, requires end-to-end connectivity to provide
263   authentication and prevent man-in-the-middle attacks, this memo
264   specifies the CONNECT method to establish a tunnel across proxies.
265</t>
266<t>
267   Once a tunnel is established, any of the operations in <xref target="client.requested.upgrade.to.http.over.tls"/> can
268   be used to establish a TLS connection.
269</t>
270
271<section title="Implications of Hop By Hop Upgrade">
272<t>
273   If an origin server receives an Upgrade header from a proxy and
274   responds with a 101 Switching Protocols response, it is changing the
275   protocol only on the connection between the proxy and itself.
276   Similarly, a proxy might return a 101 response to its client to
277   change the protocol on that connection independently of the protocols
278   it is using to communicate toward the origin server.
279</t>
280<t>
281   These scenarios also complicate diagnosis of a 426 response.  Since
282   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
283   might remove the accompanying Upgrade header and prevent the client
284   from determining the required protocol switch.  If a client receives
285   a 426 status without an accompanying Upgrade header, it will need to
286   request an end to end tunnel connection as described in <xref target="requesting.a.tunnel.with.connect"/>
287   and repeat the request in order to obtain the required upgrade
288   information.
289</t>
290<t>
291   This hop-by-hop definition of Upgrade was a deliberate choice.  It
292   allows for incremental deployment on either side of proxies, and for
293   optimized protocols between cascaded proxies without the knowledge of
294   the parties that are not a part of the change.
295</t>
296</section>
297
298<section title="Requesting a Tunnel with CONNECT" anchor="requesting.a.tunnel.with.connect">
299<t>
300   A CONNECT method requests that a proxy establish a tunnel connection
301   on its behalf. The Request-URI portion of the Request-Line is always
302   an 'authority' as defined by URI Generic Syntax <xref target="RFC2396"/>, which is to say
303   the host name and port number destination of the requested connection
304   separated by a colon:
305</t>
306<figure><artwork type='message/http: msgtype="request"'>
307   CONNECT server.example.com:80 HTTP/1.1
308   Host: server.example.com:80
309</artwork></figure>
310<t>
311   Other HTTP mechanisms can be used normally with the CONNECT method --
312   except end-to-end protocol Upgrade requests, of course, since the
313   tunnel must be established first.
314</t>
315<t>
316   For example, proxy authentication might be used to establish the
317   authority to create a tunnel:
318</t>
319<figure><artwork type='message/http: msgtype="request"'>
320   CONNECT server.example.com:80 HTTP/1.1
321   Host: server.example.com:80
322   Proxy-Authorization: basic aGVsbG86d29ybGQ=
323</artwork></figure>
324<t>
325   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
326   sent immediately after the blank line. The usual caveats also apply:
327   data may be discarded if the eventual response is negative, and the
328   connection may be reset with no response if more than one TCP segment
329   is outstanding.
330</t>
331</section>
332
333<section title="Establishing a Tunnel with CONNECT">
334<t>
335   Any successful (2xx) response to a CONNECT request indicates that the
336   proxy has established a connection to the requested host and port,
337   and has switched to tunneling the current connection to that server
338   connection.
339</t>
340<t>
341   It may be the case that the proxy itself can only reach the requested
342   origin server through another proxy.  In this case, the first proxy
343   &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
344   to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
345   unless it has either a direct or tunnel connection established to the
346   authority.
347</t>
348<t>
349   An origin server which receives a CONNECT request for itself &MAY;
350   respond with a 2xx status code to indicate that a connection is
351   established.
352</t>
353<t>
354   If at any point either one of the peers gets disconnected, any
355   outstanding data that came from that peer will be passed to the other
356   one, and after that also the other connection will be terminated by
357   the proxy. If there is outstanding data to that peer undelivered,
358   that data will be discarded.
359</t>
360</section>
361</section>
362
363<section title="Rationale for the use of a 4xx (client error) Status Code" anchor="rationale.for.the.use.of.a.4xx.status.code">
364<t>
365   Reliable, interoperable negotiation of Upgrade features requires an
366   unambiguous failure signal. The 426 Upgrade Required status code
367   allows a server to definitively state the precise protocol extensions
368   a given resource must be served with.
369</t>
370<t>
371   It might at first appear that the response should have been some form
372   of redirection (a 3xx code), by analogy to an old-style redirection
373   to an https: URI.  User agents that do not understand Upgrade:
374   preclude this.
375</t>
376<t>
377   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
378   user agent that did not recognize it would treat it as 300.  It would
379   then properly look for a "Location" header in the response and
380   attempt to repeat the request at the URL in that header field. Since
381   it did not know to Upgrade to incorporate the TLS layer, it would at
382   best fail again at the new URL.
383</t>
384</section>
385
386<section title="IANA Considerations">
387<t>
388   IANA shall create registries for two name spaces, as described in BCP
389   26 <xref target="RFC2434"/>:
390  <list style="symbols">
391    <t>HTTP Status Codes</t>
392    <t>HTTP Upgrade Tokens</t>
393  </list>
394</t>
395
396<section title="HTTP Status Code Registry">
397<t>
398   The HTTP Status Code Registry defines the name space for the Status-Code
399   token in the Status line of an HTTP response.  The initial
400   values for this name space are those specified by:
401  <list style="numbers">
402    <t>Draft Standard for HTTP/1.1 <xref target="RFC2616"/></t>
403    <t>Web Distributed Authoring and Versioning <xref target="RFC2518"/> [defines 420-424]</t>
404    <t>WebDAV Advanced Collections <xref target="ADVCOL"/> (Work in Progress) [defines 425]</t>
405    <t><xref target="rationale.for.the.use.of.a.4xx.status.code"/> [defines 426]</t>
406  </list>
407</t>
408<t>
409   Values to be added to this name space &SHOULD; be subject to review in
410   the form of a standards track document within the IETF Applications
411   Area.  Any such document &SHOULD; be traceable through statuses of
412   either 'Obsoletes' or 'Updates' to the Draft Standard for
413   HTTP/1.1 <xref target="RFC2616"/>.
414</t>
415</section>
416
417<section title="HTTP Upgrade Token Registry">
418<t>
419   The HTTP Upgrade Token Registry defines the name space for product
420   tokens used to identify protocols in the Upgrade HTTP header field.
421   Each registered token should be associated with one or a set of
422   specifications, and with contact information.
423</t>
424<t>
425   The Draft Standard for HTTP/1.1 <xref target="RFC2616"/> specifies that these tokens obey
426   the production for 'product':
427</t>
428<figure><artwork type="abnf2616">
429   product         = token ["/" product-version]
430   product-version = token
431</artwork></figure>
432<t>
433   Registrations should be allowed on a First Come First Served basis as
434   described in BCP 26 <xref target="RFC2434"/>. These specifications need not be IETF
435   documents or be subject to IESG review, but should obey the following
436   rules:
437  <list style="numbers">
438    <t>A token, once registered, stays registered forever.</t>
439    <t>The registration &MUST; name a responsible party for the
440       registration.</t>
441    <t>The registration &MUST; name a point of contact.</t>
442    <t>The registration &MAY; name the documentation required for the
443       token.</t>
444    <t>The responsible party &MAY; change the registration at any time.
445       The IANA will keep a record of all such changes, and make them
446       available upon request.</t>
447    <t>The responsible party for the first registration of a "product"
448       token &MUST; approve later registrations of a "version" token
449       together with that "product" token before they can be registered.</t>
450    <t>If absolutely required, the IESG &MAY; reassign the responsibility
451       for a token. This will normally only be used in the case when a
452       responsible party cannot be contacted.</t>
453  </list>
454</t>
455<t>
456   This specification defines the protocol token "TLS/1.0" as the
457   identifier for the protocol specified by The TLS Protocol <xref target="RFC2246"/>.
458</t>
459<t>
460   It is NOT required that specifications for upgrade tokens be made
461   publicly available, but the contact information for the registration
462   &SHOULD; be.
463</t>
464</section>
465</section>
466
467<section title="Security Considerations">
468<t>
469   The potential for a man-in-the-middle attack (deleting the Upgrade
470   header) remains the same as current, mixed http/https practice:
471  <list style="symbols">
472    <t>Removing the Upgrade header is similar to rewriting web pages to
473      change https:// links to http:// links.</t>
474    <t>The risk is only present if the server is willing to vend such
475      information over both a secure and an insecure channel in the
476      first place.</t>
477    <t>If the client knows for a fact that a server is TLS-compliant, it
478      can insist on it by only sending an Upgrade request with a no-op
479      method like OPTIONS.</t>
480    <t>Finally, as the https: specification warns, "users should
481      carefully examine the certificate presented by the server to
482      determine if it meets their expectations".</t>
483  </list>
484</t>
485<t>
486   Furthermore, for clients that do not explicitly try to invoke TLS,
487   servers can use the Upgrade header in any response other than 101 or
488   426 to advertise TLS compliance. Since TLS compliance should be
489   considered a feature of the server and not the resource at hand, it
490   should be sufficient to send it once, and let clients cache that
491   fact.
492</t>
493
494<section title="Implications for the https: URI Scheme">
495<t>
496   While nothing in this memo affects the definition of the 'https' URI
497   scheme, widespread adoption of this mechanism for HyperText content
498   could use 'http' to identify both secure and non-secure resources.
499</t>
500<t>
501   The choice of what security characteristics are required on the
502   connection is left to the client and server.  This allows either
503   party to use any information available in making this determination.
504   For example, user agents may rely on user preference settings or
505   information about the security of the network such as 'TLS required
506   on all POST operations not on my local net', or servers may apply
507   resource access rules such as 'the FORM on this page must be served
508   and submitted using TLS'.
509</t>
510</section>
511
512<section title="Security Considerations for CONNECT">
513<t>
514   A generic TCP tunnel is fraught with security risks. First, such
515   authorization should be limited to a small number of known ports.
516   The Upgrade: mechanism defined here only requires onward tunneling at
517   port 80. Second, since tunneled data is opaque to the proxy, there
518   are additional risks to tunneling to other well-known or reserved
519   ports. A putative HTTP client CONNECTing to port 25 could relay spam
520   via SMTP, for example.
521</t>
522</section>
523</section>
524
525  </middle>
526  <back>
527<references>
528
529<reference anchor="RFC2616">
530  <front>
531    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
532    <author initials="R." surname="Fielding" fullname="R. Fielding">
533      <organization>University of California, Irvine</organization>
534      <address><email>fielding@ics.uci.edu</email></address>
535    </author>
536    <author initials="J." surname="Gettys" fullname="J. Gettys">
537      <organization>W3C</organization>
538      <address><email>jg@w3.org</email></address>
539    </author>
540    <author initials="J." surname="Mogul" fullname="J. Mogul">
541      <organization>Compaq Computer Corporation</organization>
542      <address><email>mogul@wrl.dec.com</email></address>
543    </author>
544    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
545      <organization>MIT Laboratory for Computer Science</organization>
546      <address><email>frystyk@w3.org</email></address>
547    </author>
548    <author initials="L." surname="Masinter" fullname="L. Masinter">
549      <organization>Xerox Corporation</organization>
550      <address><email>masinter@parc.xerox.com</email></address>
551    </author>
552    <author initials="P." surname="Leach" fullname="P. Leach">
553      <organization>Microsoft Corporation</organization>
554      <address><email>paulle@microsoft.com</email></address>
555    </author>
556    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
557      <organization>W3C</organization>
558      <address><email>timbl@w3.org</email></address>
559    </author>
560    <date month="June" year="1999"/>
561  </front>
562  <seriesInfo name="RFC" value="2616"/>
563</reference>
564
565<reference anchor='RFC2396'>
566  <front>
567    <title abbrev='URI Generic Syntax'>Uniform Resource Identifiers (URI): Generic Syntax</title>
568    <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
569      <organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
570      <address>
571      <facsimile>+1(617)258-8682</facsimile>
572      <email>timbl@w3.org</email></address>
573    </author>
574    <author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
575      <organization abbrev='U.C. Irvine'>University of California, Irvine</organization>
576      <address>
577      <facsimile>+1(949)824-1715</facsimile>
578      <email>fielding@ics.uci.edu</email></address>
579    </author>
580    <author initials='L.' surname='Masinter' fullname='Larry Masinter'>
581      <organization abbrev='Xerox Corporation'>Xerox PARC</organization>
582      <address>
583      <facsimile>+1(415)812-4333</facsimile>
584      <email>masinter@parc.xerox.com</email></address>
585    </author>
586    <date month='August' year='1998' />
587    <area>Applications</area>
588  </front>
589  <seriesInfo name='RFC' value='2396' />
590</reference>
591
592<reference anchor='RFC2818'>
593  <front>
594    <title>HTTP Over TLS</title>
595    <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
596      <organization>RTFM, Inc.</organization>
597      <address><email>ekr@rtfm.com</email></address>
598    </author>
599    <date year='2000' month='May' />
600  </front>
601  <seriesInfo name='RFC' value='2818' />
602</reference>
603
604<reference anchor="RFC2518">
605  <front>
606    <title>HTTP Extensions for Distributed Authoring -- WEBDAV</title>
607    <author initials="Y." surname="Goland" fullname="Y. Goland">
608      <organization>Microsoft Corporation</organization>
609      <address><email>yarong@microsoft.com</email></address>
610    </author>
611    <author initials="E." surname="Whitehead" fullname="E. J. Whitehead, Jr.">
612      <organization abbrev="UC Irvine">Dept. Of Information and Computer Science, University of California, Irvine</organization>
613        <address><email>ejw@ics.uci.edu</email></address>
614    </author>
615    <author initials="A." surname="Faizi" fullname="A. Faizi">
616      <organization abbrev="Netscape">Netscape</organization>
617      <address><email>asad@netscape.com</email></address>
618    </author>
619    <author initials="S.R." surname="Carter" fullname="S. R. Carter">
620      <organization abbrev="Novell">Novell</organization>
621      <address><email>srcarter@novell.com</email></address>
622    </author>
623    <author initials="D." surname="Jensen" fullname="D. Jensen">
624      <organization abbrev="Novell">Novell</organization>
625      <address><email>dcjensen@novell.com</email></address>
626    </author>
627    <date month="February" year="1999"/>
628  </front>
629  <seriesInfo name="RFC" value="2518"/>
630</reference>
631
632<reference anchor="ADVCOL">
633  <front>
634    <title>WebDAV Advanced Collection Protocol</title>
635    <author initials="J." surname="Slein" fullname="J. Slein">
636      <organization/>
637    </author>
638    <author initials="E.J." surname="Whitehead" fullname="E.J. Whitehead">
639      <organization/>
640    </author>
641    <date/>
642  </front>
643  <annotation>Work In Progress.</annotation>
644</reference>
645
646<reference anchor="RFC2246">
647  <front>
648    <title>The TLS Protocol Version 1.0</title>
649    <author fullname="Tim Dierks" surname="Dierks" initials="T.">
650      <organization>Certicom</organization>
651      <address>
652      <email>tdierks@certicom.com</email></address>
653    </author>
654    <author fullname="Christopher Allen" surname="Allen" initials="C.">
655      <organization>Certicom</organization>
656      <address>
657      <email>callen@certicom.com</email></address>
658    </author>
659    <date month="January" year="1999"></date>
660  </front>
661  <seriesInfo name="RFC" value="2246"></seriesInfo>
662</reference>
663 
664<reference anchor='RFC2565'>
665  <front>
666    <title abbrev='IPP/1.0: Encoding and Transport'>Internet Printing Protocol/1.0: Encoding and Transport</title>
667    <author initials='R.' surname='Herriot' fullname='Robert Herriot'>
668      <organization>Xerox Corporation</organization>
669      <address>
670      <phone>+1 650 813 7696</phone>
671      <facsimile>+1 650 813 6860</facsimile>
672      <email>rherriot@pahv.xerox.com</email></address>
673    </author>
674    <author initials='S.' surname='Butler' fullname='Sylvan Butler'>
675      <organization>Hewlett-Packard</organization>
676      <address>
677      <phone>+1 208 396 6000</phone>
678      <facsimile>+1 208 396 3457</facsimile>
679      <email>sbutler@boi.hp.com</email></address>
680    </author>
681    <author initials='P.' surname='Moore' fullname='Paul Moore'>
682      <organization>Microsoft</organization>
683      <address>
684      <phone>+1 425 936 0908</phone>
685      <facsimile>+1 425 936 7329</facsimile>
686      <email>paulmo@microsoft.com</email></address>
687    </author>
688    <author initials='R.' surname='Turner' fullname='Randy Turner'>
689      <organization>Sharp Laboratories</organization>
690      <address>
691      <phone>+1 360 817 8456</phone>
692      <facsimile>+1 360 817 8436</facsimile>
693      <email>rturner@sharplabs.com</email></address>
694    </author>
695    <date year='1999' month='April' />
696  </front>
697  <seriesInfo name='RFC' value='2565' />
698</reference>
699
700<reference anchor="Luo97">
701  <front>
702    <title>Tunneling TCP based protocols through Web proxy servers</title>
703    <author initials="A." surname="Luotonen" fullname="Ari Luotonen">
704      <organization/>
705    </author>
706    <date/>
707  </front>
708  <annotation>
709Work In Progress.  (Also available in: Luotonen, Ari.
710        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
711  </annotation>
712</reference>
713
714<reference anchor='RFC2629'>
715  <front>
716    <title>Writing I-Ds and RFCs using XML</title>
717    <author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
718      <organization>Invisible Worlds, Inc.</organization>
719      <address>
720        <postal>
721          <street>660 York Street</street>
722          <city>San Francisco</city>
723          <region>CA</region>
724          <code>94110</code>
725          <country>US</country>
726        </postal>
727        <phone>+1 415 695 3975</phone>
728        <email>mrose@not.invisible.net</email>
729        <uri>http://invisible.net/</uri>
730      </address>
731    </author>
732    <date month='June' year='1999' />
733  </front>
734  <seriesInfo name='RFC' value='2629' />
735</reference>
736
737<reference anchor="RFC2434">
738  <front>
739    <title abbrev="Guidelines for IANA Considerations">Guidelines for Writing an IANA Considerations Section in RFCs</title>
740    <author initials="T." surname="Narten" fullname="Thomas Narten">
741    <organization>IBM Corporation</organization>
742    <address>
743    <postal>
744    <street>3039 Cornwallis Ave.</street>
745    <street>PO Box 12195 - BRQA/502</street>
746    <street>Research Triangle Park</street>
747    <street>NC 27709-2195</street></postal>
748    <phone>919-254-7798</phone>
749    <email>narten@raleigh.ibm.com</email></address></author>
750    <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
751    <organization>Maxware</organization>
752    <address>
753    <postal>
754    <street>Pirsenteret</street>
755    <street>N-7005 Trondheim</street>
756    <country>Norway</country></postal>
757    <phone>+47 73 54 57 97</phone>
758    <email>Harald@Alvestrand.no</email></address></author>
759    <date year="1998" month="October"/>
760    <area>General</area>
761  </front>
762  <seriesInfo name="BCP" value="26"/>
763  <seriesInfo name="RFC" value="2434"/>
764</reference>
765
766<reference anchor="RFC2119">
767  <front>
768    <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
769    <author initials="S." surname="Bradner" fullname="Scott Bradner">
770    <organization>Harvard University</organization>
771    <address>
772      <email>sob@harvard.edu</email>
773    </address></author>
774    <date month="March" year="1997"/>
775  </front>
776  <seriesInfo name="BCP" value="14"/>
777  <seriesInfo name="RFC" value="2119"/>
778</reference>
779
780</references>
781
782<section title="Acknowledgments">
783<t>
784   The CONNECT method was originally described in a Work in Progress
785   titled, "Tunneling TCP based protocols through Web proxy servers",
786   <xref target="Luo97"/> by Ari Luotonen of Netscape Communications Corporation.  It was
787   widely implemented by HTTP proxies, but was never made a part of any
788   IETF Standards Track document. The method name CONNECT was reserved,
789   but not defined in <xref target="RFC2616"/>.
790</t>
791<t>
792   The definition provided here is derived directly from that earlier
793   memo, with some editorial changes and conformance to the stylistic
794   conventions since established in other HTTP specifications.
795</t>
796<t> 
797   Additional Thanks to:
798  <list style="symbols">
799    <t>Paul Hoffman for his work on the STARTTLS command extension for
800      ESMTP.</t>
801    <t>Roy Fielding for assistance with the rationale behind Upgrade:
802      and its interaction with OPTIONS.</t>
803    <t>Eric Rescorla for his work on standardizing the existing https:
804      practice to compare with.</t>
805    <t>Marshall Rose, for the xml2rfc document type description and tools
806      <xref target="RFC2629"/>.</t>
807    <t>Jim Whitehead, for sorting out the current range of available HTTP
808      status codes.</t>
809    <t>Henrik Frystyk Nielsen, whose work on the Mandatory extension
810      mechanism pointed out a hop-by-hop Upgrade still requires
811      tunneling.</t>
812    <t>Harald Alvestrand for improvements to the token registration
813      rules.</t>
814  </list>
815</t>
816</section>
817
818  </back>
819</rfc>
Note: See TracBrowser for help on using the repository browser.