Ignore:
Timestamp:
20/01/14 07:43:53 (8 years ago)
Author:
julian.reschke@…
Message:

update rfc2617.xml (ABNF alignment was off from published version), regen all HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/orig/rfc2817.html

    r1305 r2564  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    66      <title>Upgrading to TLS Within HTTP/1.1</title><style type="text/css" title="Xml2Rfc (sans serif)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    3936ul.empty {
    4037  list-style-type: none;
     
    5047}
    5148h1 {
    52   font-size: 14pt;
     49  font-size: 130%;
    5350  line-height: 21pt;
    5451  page-break-after: avoid;
     
    5754  page-break-before: always;
    5855}
    59 h1 a {
    60   color: #333333;
    61 }
    6256h2 {
    63   font-size: 12pt;
     57  font-size: 120%;
    6458  line-height: 15pt;
    6559  page-break-after: avoid;
    6660}
    67 h3, h4, h5, h6 {
    68   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6963  page-break-after: avoid;
    7064}
    71 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7269  color: black;
    7370}
     
    7774li {
    7875  margin-left: 2em;
    79   margin-right: 2em;
    8076}
    8177ol {
    8278  margin-left: 2em;
    83   margin-right: 2em;
    8479}
    8580ol.la {
     
    9489p {
    9590  margin-left: 2em;
    96   margin-right: 2em;
    9791}
    9892pre {
     
    10094  background-color: lightyellow;
    10195  padding: .25em;
     96  page-break-inside: avoid;
    10297}
    10398pre.text2 {
     
    129124  border-spacing: 1px;
    130125  width: 95%;
    131   font-size: 10pt;
     126  font-size: 11pt;
    132127  color: white;
    133128}
     
    137132td.topnowrap {
    138133  vertical-align: top;
    139   white-space: nowrap; 
     134  white-space: nowrap;
    140135}
    141136table.header td {
     
    157152  list-style: none;
    158153  margin-left: 1.5em;
    159   margin-right: 0em;
    160154  padding-left: 0em;
    161155}
     
    163157  line-height: 150%;
    164158  font-weight: bold;
    165   font-size: 10pt;
    166159  margin-left: 0em;
    167   margin-right: 0em;
    168160}
    169161ul.toc li li {
    170162  line-height: normal;
    171163  font-weight: normal;
    172   font-size: 9pt;
     164  font-size: 10pt;
    173165  margin-left: 0em;
    174   margin-right: 0em;
    175166}
    176167li.excluded {
     
    179170ul p {
    180171  margin-left: 0em;
     172}
     173.title, .filename, h1, h2, h3, h4 {
     174  font-family: candara, helvetica, arial, sans-serif;
     175}
     176samp, tt, code, pre {
     177  font: consolas, monospace;
    181178}
    182179.bcp14 {
     
    199196  font-weight: bold;
    200197  text-align: center;
    201   font-size: 9pt;
     198  font-size: 10pt;
    202199}
    203200.filename {
    204201  color: #333333;
     202  font-size: 75%;
    205203  font-weight: bold;
    206   font-size: 12pt;
    207204  line-height: 21pt;
    208205  text-align: center;
     
    211208  font-weight: bold;
    212209}
    213 .hidden {
    214   display: none;
    215 }
    216210.left {
    217211  text-align: left;
     
    221215}
    222216.title {
    223   color: #990000;
    224   font-size: 18pt;
     217  color: green;
     218  font-size: 150%;
    225219  line-height: 18pt;
    226220  font-weight: bold;
     
    228222  margin-top: 36pt;
    229223}
    230 .vcardline {
    231   display: block;
    232 }
    233224.warning {
    234   font-size: 14pt;
     225  font-size: 130%;
    235226  background-color: yellow;
    236227}
     
    241232    display: none;
    242233  }
    243  
     234
    244235  a {
    245236    color: black;
     
    256247    background-color: white;
    257248    vertical-align: top;
    258     font-size: 12pt;
    259   }
    260 
    261   ul.toc a::after {
     249    font-size: 110%;
     250  }
     251
     252  ul.toc a:nth-child(2)::after {
    262253    content: leader('.') target-counter(attr(href), page);
    263254  }
    264  
     255
    265256  ul.ind li li a {
    266257    content: target-counter(attr(href), page);
    267258  }
    268  
     259
    269260  .print2col {
    270261    column-count: 2;
     
    276267@page {
    277268  @top-left {
    278        content: "RFC 2817"; 
    279   } 
     269       content: "RFC 2817";
     270  }
    280271  @top-right {
    281        content: "May 2000"; 
    282   } 
     272       content: "May 2000";
     273  }
    283274  @top-center {
    284        content: "Upgrading to TLS Within HTTP/1.1"; 
    285   } 
     275       content: "Upgrading to TLS Within HTTP/1.1";
     276  }
    286277  @bottom-left {
    287        content: "Khare & Lawrence"; 
    288   } 
     278       content: "Khare & Lawrence";
     279  }
    289280  @bottom-center {
    290        content: "Standards Track"; 
    291   } 
     281       content: "Standards Track";
     282  }
    292283  @bottom-right {
    293        content: "[Page " counter(page) "]"; 
    294   } 
    295 }
    296 
    297 @page:first { 
     284       content: "[Page " counter(page) "]";
     285  }
     286}
     287
     288@page:first {
    298289    @top-left {
    299290      content: normal;
     
    322313      <link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc2817">
    323314      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2817">
    324       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.550, 2011-05-30 14:02:12, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     315      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.611, 2013/11/27 12:23:51, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    325316      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    326317      <meta name="dct.creator" content="Khare, R.">
     
    358349      </table>
    359350      <p class="title">Upgrading to TLS Within HTTP/1.1</p>
    360       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    361       <p>This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions
    362          for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization
    363          state and status of this protocol. Distribution of this memo is unlimited.
    364       </p>
    365       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    366       <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
    367       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
     351      <div id="rfc.status">
     352         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     353         <p>This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions
     354            for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization
     355            state and status of this protocol. Distribution of this memo is unlimited.
     356         </p>
     357      </div>
     358      <div id="rfc.copyrightnotice">
     359         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     360         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
     361      </div>
     362      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    368363      <p>This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing
    369364         TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80
    370365         rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended
    371366         for several hostnames at a single IP address.
    372       </p> 
     367      </p>
    373368      <p>Since HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels
    374369         across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or
    375370         private Upgrade product tokens.
    376       </p> 
     371      </p>
    377372      <p>This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/
    378373         and https://example.org/ are not equivalent).
    379       </p> 
     374      </p>
    380375      <hr class="noprint">
    381376      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    382377      <ul class="toc">
    383          <li>1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Motivation</a></li>
    384          <li>2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Introduction</a><ul>
    385                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Requirements Terminology</a></li>
     378         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Motivation</a></li>
     379         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">Introduction</a><ul>
     380               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Requirements Terminology</a></li>
    386381            </ul>
    387382         </li>
    388          <li>3.&nbsp;&nbsp;&nbsp;<a href="#client.requested.upgrade.to.http.over.tls">Client Requested Upgrade to HTTP over TLS</a><ul>
    389                <li>3.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Optional Upgrade</a></li>
    390                <li>3.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Mandatory Upgrade</a></li>
    391                <li>3.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3">Server Acceptance of Upgrade Request</a></li>
     383         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#client.requested.upgrade.to.http.over.tls">Client Requested Upgrade to HTTP over TLS</a><ul>
     384               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Optional Upgrade</a></li>
     385               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Mandatory Upgrade</a></li>
     386               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.3">Server Acceptance of Upgrade Request</a></li>
    392387            </ul>
    393388         </li>
    394          <li>4.&nbsp;&nbsp;&nbsp;<a href="#server.requested.upgrade.to.http.over.tls">Server Requested Upgrade to HTTP over TLS</a><ul>
    395                <li>4.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Optional Advertisement</a></li>
    396                <li>4.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Mandatory Advertisement</a></li>
     389         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#server.requested.upgrade.to.http.over.tls">Server Requested Upgrade to HTTP over TLS</a><ul>
     390               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.1">Optional Advertisement</a></li>
     391               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.4.2">Mandatory Advertisement</a></li>
    397392            </ul>
    398393         </li>
    399          <li>5.&nbsp;&nbsp;&nbsp;<a href="#upgrade.across.proxies">Upgrade across Proxies</a><ul>
    400                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.1">Implications of Hop By Hop Upgrade</a></li>
    401                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#requesting.a.tunnel.with.connect">Requesting a Tunnel with CONNECT</a></li>
    402                <li>5.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">Establishing a Tunnel with CONNECT</a></li>
     394         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#upgrade.across.proxies">Upgrade across Proxies</a><ul>
     395               <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.1">Implications of Hop By Hop Upgrade</a></li>
     396               <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#requesting.a.tunnel.with.connect">Requesting a Tunnel with CONNECT</a></li>
     397               <li><a href="#rfc.section.5.3">5.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.5.3">Establishing a Tunnel with CONNECT</a></li>
    403398            </ul>
    404399         </li>
    405          <li>6.&nbsp;&nbsp;&nbsp;<a href="#rationale.for.the.use.of.a.4xx.status.code">Rationale for the use of a 4xx (client error) Status Code</a></li>
    406          <li>7.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">IANA Considerations</a><ul>
    407                <li>7.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">HTTP Status Code Registry</a></li>
    408                <li>7.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">HTTP Upgrade Token Registry</a></li>
     400         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#rationale.for.the.use.of.a.4xx.status.code">Rationale for the use of a 4xx (client error) Status Code</a></li>
     401         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7">IANA Considerations</a><ul>
     402               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.1">HTTP Status Code Registry</a></li>
     403               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.7.2">HTTP Upgrade Token Registry</a></li>
    409404            </ul>
    410405         </li>
    411          <li>8.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8">Security Considerations</a><ul>
    412                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1">Implications for the https: URI Scheme</a></li>
    413                <li>8.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2">Security Considerations for CONNECT</a></li>
     406         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8">Security Considerations</a><ul>
     407               <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.1">Implications for the https: URI Scheme</a></li>
     408               <li><a href="#rfc.section.8.2">8.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.8.2">Security Considerations for CONNECT</a></li>
    414409            </ul>
    415410         </li>
    416          <li>9.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
     411         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
    417412         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    418          <li>A.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Acknowledgments</a></li>
     413         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Acknowledgments</a></li>
    419414         <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
    420415      </ul>
    421416      <hr class="noprint">
    422       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Motivation
    423       </h1>
    424       <p id="rfc.section.1.p.1">The historical practice of deploying HTTP over SSL3 <a href="#RFC2818"><cite title="HTTP Over TLS">[3]</cite></a> has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant
    425          the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers
    426          have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application
    427          protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports.
    428       </p>
    429       <p id="rfc.section.1.p.2">At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice
    430          of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[6]</cite></a> to an open HTTP connection.
    431       </p>
    432       <p id="rfc.section.1.p.3">In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in
    433          implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation
    434          of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol <a href="#RFC2565"><cite title="Internet Printing Protocol/1.0: Encoding and Transport">[7]</cite></a>, call for just such a mechanism in order to move ahead in the IETF standards process.
    435       </p>
    436       <p id="rfc.section.1.p.4">The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single
    437          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
    438          prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion.
    439       </p>
    440       <p id="rfc.section.1.p.5">TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify
    441          the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake
    442          -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting
    443          as well.
    444       </p>
    445       <hr class="noprint">
    446       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Introduction
    447       </h1>
    448       <p id="rfc.section.2.p.1">TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end connection, optionally including strong mutual authentication,
    449          using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate
    450          endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption,
    451          compression, and reassembly for the remainder of the connection. The latter is intended to be completely transparent. For
    452          example, there is no dependency between TLS's record markers and or certificates and HTTP/1.1's chunked encoding or authentication.
    453       </p>
    454       <p id="rfc.section.2.p.2">Either the client or server can use the HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> Upgrade mechanism (<a href="http://tools.ietf.org/html/rfc2616#section-14.42">Section 14.42</a>) to indicate that a TLS-secured connection is desired or necessary. This memo defines the "TLS/1.0" Upgrade token, and a
    455          new HTTP Status Code, "426 Upgrade Required".
    456       </p>
    457       <p id="rfc.section.2.p.3"> <a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> and <a href="#server.requested.upgrade.to.http.over.tls" title="Server Requested Upgrade to HTTP over TLS">Section&nbsp;4</a> describe the operation of a directly connected client and server. Intermediate proxies must establish an end-to-end tunnel
    458          before applying those operations, as explained in <a href="#upgrade.across.proxies" title="Upgrade across Proxies">Section&nbsp;5</a>.
    459       </p>
    460       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Requirements Terminology
    461       </h2>
    462       <p id="rfc.section.2.1.p.1">Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted
    463          as described in RFC 2119 <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[11]</cite></a>.
    464       </p>
    465       <hr class="noprint">
    466       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;<a id="client.requested.upgrade.to.http.over.tls" href="#client.requested.upgrade.to.http.over.tls">Client Requested Upgrade to HTTP over TLS</a></h1>
    467       <p id="rfc.section.3.p.1">When the client sends an HTTP/1.1 request with an Upgrade header field containing the token "TLS/1.0", it is requesting the
    468          server to complete the current HTTP/1.1 request after switching to TLS/1.0.
    469       </p>
    470       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Optional Upgrade
    471       </h2>
    472       <p id="rfc.section.3.1.p.1">A client <em class="bcp14">MAY</em> offer to switch to secured operation during any clear HTTP request when an unsecured response would be acceptable:
    473       </p>
    474       <div id="rfc.figure.u.1"></div><pre class="text2">
     417      <div>
     418         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Motivation
     419         </h1>
     420         <p id="rfc.section.1.p.1">The historical practice of deploying HTTP over SSL3 <a href="#RFC2818"><cite title="HTTP Over TLS">[3]</cite></a> has distinguished the combination from HTTP alone by a unique URI scheme and the TCP port number. The scheme 'http' meant
     421            the HTTP protocol alone on port 80, while 'https' meant the HTTP protocol over SSL on port 443. Parallel well-known port numbers
     422            have similarly been requested -- and in some cases, granted -- to distinguish between secured and unsecured use of other application
     423            protocols (e.g. snews, ftps). This approach effectively halves the number of available well known ports.
     424         </p>
     425         <p id="rfc.section.1.p.2">At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice
     426            of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[6]</cite></a> to an open HTTP connection.
     427         </p>
     428         <p id="rfc.section.1.p.3">In the nearly two years since, there has been broad acceptance of the concept behind this proposal, but little interest in
     429            implementing alternatives to port 443 for generic Web browsing. In fact, nothing in this memo affects the current interpretation
     430            of https: URIs. However, new application protocols built atop HTTP, such as the Internet Printing Protocol <a href="#RFC2565"><cite title="Internet Printing Protocol/1.0: Encoding and Transport">[7]</cite></a>, call for just such a mechanism in order to move ahead in the IETF standards process.
     431         </p>
     432         <p id="rfc.section.1.p.4">The Upgrade mechanism also solves the "virtual hosting" problem. Rather than allocating multiple IP addresses to a single
     433            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
     434            prevalent, more ISPs are offering name-based virtual hosting, thus delaying IP address space exhaustion.
     435         </p>
     436         <p id="rfc.section.1.p.5">TLS (and SSL) have been hobbled by the same limitation as earlier versions of HTTP: the initial handshake does not specify
     437            the intended hostname, relying exclusively on the IP address. Using a cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake
     438            -- choosing the certificates based on the initial Host: header -- will allow ISPs to provide secure name-based virtual hosting
     439            as well.
     440         </p>
     441      </div>
     442      <hr class="noprint">
     443      <div>
     444         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;Introduction
     445         </h1>
     446         <p id="rfc.section.2.p.1">TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-to-end connection, optionally including strong mutual authentication,
     447            using a variety of cryptosystems. Initially, a handshake phase uses three subprotocols to set up a record layer, authenticate
     448            endpoints, set parameters, as well as report errors. Then, there is an ongoing layered record protocol that handles encryption,
     449            compression, and reassembly for the remainder of the connection. The latter is intended to be completely transparent. For
     450            example, there is no dependency between TLS's record markers and or certificates and HTTP/1.1's chunked encoding or authentication.
     451         </p>
     452         <p id="rfc.section.2.p.2">Either the client or server can use the HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> Upgrade mechanism (<a href="http://tools.ietf.org/html/rfc2616#section-14.42">Section 14.42</a>) to indicate that a TLS-secured connection is desired or necessary. This memo defines the "TLS/1.0" Upgrade token, and a
     453            new HTTP Status Code, "426 Upgrade Required".
     454         </p>
     455         <p id="rfc.section.2.p.3"><a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> and <a href="#server.requested.upgrade.to.http.over.tls" title="Server Requested Upgrade to HTTP over TLS">Section&nbsp;4</a> describe the operation of a directly connected client and server. Intermediate proxies must establish an end-to-end tunnel
     456            before applying those operations, as explained in <a href="#upgrade.across.proxies" title="Upgrade across Proxies">Section&nbsp;5</a>.
     457         </p>
     458         <div>
     459            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Requirements Terminology
     460            </h2>
     461            <p id="rfc.section.2.1.p.1">Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted
     462               as described in RFC 2119 <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[11]</cite></a>.
     463            </p>
     464         </div>
     465      </div>
     466      <hr class="noprint">
     467      <div id="client.requested.upgrade.to.http.over.tls">
     468         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#client.requested.upgrade.to.http.over.tls">Client Requested Upgrade to HTTP over TLS</a></h1>
     469         <p id="rfc.section.3.p.1">When the client sends an HTTP/1.1 request with an Upgrade header field containing the token "TLS/1.0", it is requesting the
     470            server to complete the current HTTP/1.1 request after switching to TLS/1.0.
     471         </p>
     472         <div>
     473            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Optional Upgrade
     474            </h2>
     475            <p id="rfc.section.3.1.p.1">A client <em class="bcp14">MAY</em> offer to switch to secured operation during any clear HTTP request when an unsecured response would be acceptable:
     476            </p>
     477            <div id="rfc.figure.u.1"></div><pre class="text2">
    475478    GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
    476479    Host: example.bank.com
     
    478481    Connection: Upgrade
    479482</pre><p id="rfc.section.3.1.p.3">In this case, the server <em class="bcp14">MAY</em> respond to the clear HTTP operation normally, OR switch to secured operation (as detailed in the next section).
    480       </p>
    481       <p id="rfc.section.3.1.p.4">Note that HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> specifies "the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message".
    482       </p>
    483       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Mandatory Upgrade
    484       </h2>
    485       <p id="rfc.section.3.2.p.1">If an unsecured response would be unacceptable, a client <em class="bcp14">MUST</em> send an OPTIONS request first to complete the switch to TLS/1.0 (if possible).
    486       </p>
    487       <div id="rfc.figure.u.2"></div><pre class="text2">
     483            </p>
     484            <p id="rfc.section.3.1.p.4">Note that HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> specifies "the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message".
     485            </p>
     486         </div>
     487         <div>
     488            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Mandatory Upgrade
     489            </h2>
     490            <p id="rfc.section.3.2.p.1">If an unsecured response would be unacceptable, a client <em class="bcp14">MUST</em> send an OPTIONS request first to complete the switch to TLS/1.0 (if possible).
     491            </p>
     492            <div id="rfc.figure.u.2"></div><pre class="text2">
    488493    OPTIONS * HTTP/1.1
    489494    Host: example.bank.com
    490495    Upgrade: TLS/1.0
    491496    Connection: Upgrade
    492 </pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;Server Acceptance of Upgrade Request
    493       </h2>
    494       <p id="rfc.section.3.3.p.1">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, if the server is prepared to initiate the TLS handshake, it <em class="bcp14">MUST</em> send the intermediate "101 Switching Protocol" and <em class="bcp14">MUST</em> include an Upgrade response header specifying the tokens of the protocol stack it is switching to:
    495       </p>
    496       <div id="rfc.figure.u.3"></div><pre class="text">
     497</pre></div>
     498         <div>
     499            <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;Server Acceptance of Upgrade Request
     500            </h2>
     501            <p id="rfc.section.3.3.p.1">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, if the server is prepared to initiate the TLS handshake, it <em class="bcp14">MUST</em> send the intermediate "101 Switching Protocol" and <em class="bcp14">MUST</em> include an Upgrade response header specifying the tokens of the protocol stack it is switching to:
     502            </p>
     503            <div id="rfc.figure.u.3"></div><pre class="text">
    497504    HTTP/1.1 101 Switching Protocols
    498505    Upgrade: TLS/1.0, HTTP/1.1
    499506    Connection: Upgrade
    500507</pre><p id="rfc.section.3.3.p.3">Note that the protocol tokens listed in the Upgrade header of a 101 Switching Protocols response specify an ordered 'bottom-up'
    501          stack.
    502       </p>
    503       <p id="rfc.section.3.3.p.4">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.1.2">Section 10.1.2</a>: "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line
    504          which terminates the 101 response".
    505       </p>
    506       <p id="rfc.section.3.3.p.5">Once the TLS handshake completes successfully, the server <em class="bcp14">MUST</em> continue with the response to the original request. Any TLS handshake failure <em class="bcp14">MUST</em> lead to disconnection, per the TLS error alert specification.
    507       </p>
    508       <hr class="noprint">
    509       <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;<a id="server.requested.upgrade.to.http.over.tls" href="#server.requested.upgrade.to.http.over.tls">Server Requested Upgrade to HTTP over TLS</a></h1>
    510       <p id="rfc.section.4.p.1">The Upgrade response header field advertises possible protocol upgrades a server <em class="bcp14">MAY</em> accept. In conjunction with the "426 Upgrade Required" status code, a server can advertise the exact protocol upgrade(s) that
    511          a client <em class="bcp14">MUST</em> accept to complete the request.
    512       </p>
    513       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Optional Advertisement
    514       </h2>
    515       <p id="rfc.section.4.1.p.1">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, the server <em class="bcp14">MAY</em> include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of
    516          the protocols listed.
    517       </p>
    518       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;Mandatory Advertisement
    519       </h2>
    520       <p id="rfc.section.4.2.p.1">A server <em class="bcp14">MAY</em> indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which <em class="bcp14">MUST</em> include an an Upgrade header field specifying the token of the required TLS version.
    521       </p>
    522       <div id="rfc.figure.u.4"></div><pre class="text2">
     508               stack.
     509            </p>
     510            <p id="rfc.section.3.3.p.4">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.1.2">Section 10.1.2</a>: "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line
     511               which terminates the 101 response".
     512            </p>
     513            <p id="rfc.section.3.3.p.5">Once the TLS handshake completes successfully, the server <em class="bcp14">MUST</em> continue with the response to the original request. Any TLS handshake failure <em class="bcp14">MUST</em> lead to disconnection, per the TLS error alert specification.
     514            </p>
     515         </div>
     516      </div>
     517      <hr class="noprint">
     518      <div id="server.requested.upgrade.to.http.over.tls">
     519         <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#server.requested.upgrade.to.http.over.tls">Server Requested Upgrade to HTTP over TLS</a></h1>
     520         <p id="rfc.section.4.p.1">The Upgrade response header field advertises possible protocol upgrades a server <em class="bcp14">MAY</em> accept. In conjunction with the "426 Upgrade Required" status code, a server can advertise the exact protocol upgrade(s) that
     521            a client <em class="bcp14">MUST</em> accept to complete the request.
     522         </p>
     523         <div>
     524            <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;Optional Advertisement
     525            </h2>
     526            <p id="rfc.section.4.1.p.1">As specified in HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>, the server <em class="bcp14">MAY</em> include an Upgrade header in any response other than 101 or 426 to indicate a willingness to switch to any (combination) of
     527               the protocols listed.
     528            </p>
     529         </div>
     530         <div>
     531            <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;Mandatory Advertisement
     532            </h2>
     533            <p id="rfc.section.4.2.p.1">A server <em class="bcp14">MAY</em> indicate that a client request can not be completed without TLS using the "426 Upgrade Required" status code, which <em class="bcp14">MUST</em> include an an Upgrade header field specifying the token of the required TLS version.
     534            </p>
     535            <div id="rfc.figure.u.4"></div><pre class="text2">
    523536    HTTP/1.1 426 Upgrade Required
    524537    Upgrade: TLS/1.0, HTTP/1.1
    525538    Connection: Upgrade
    526539</pre><p id="rfc.section.4.2.p.3">The server <em class="bcp14">SHOULD</em> include a message body in the 426 response which indicates in human readable form the reason for the error and describes any
    527          alternative courses which may be available to the user.
    528       </p>
    529       <p id="rfc.section.4.2.p.4">Note that even if a client is willing to use TLS, it must use the operations in <a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> to proceed; the TLS handshake cannot begin immediately after the 426 response.
    530       </p>
    531       <hr class="noprint">
    532       <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;<a id="upgrade.across.proxies" href="#upgrade.across.proxies">Upgrade across Proxies</a></h1>
    533       <p id="rfc.section.5.p.1">As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with
    534          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.
    535       </p>
    536       <p id="rfc.section.5.p.2">Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks,
    537          this memo specifies the CONNECT method to establish a tunnel across proxies.
    538       </p>
    539       <p id="rfc.section.5.p.3">Once a tunnel is established, any of the operations in <a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> can be used to establish a TLS connection.
    540       </p>
    541       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;Implications of Hop By Hop Upgrade
    542       </h2>
    543       <p id="rfc.section.5.1.p.1">If an origin server receives an Upgrade header from a proxy and responds with a 101 Switching Protocols response, it is changing
    544          the protocol only on the connection between the proxy and itself. Similarly, a proxy might return a 101 response to its client
    545          to change the protocol on that connection independently of the protocols it is using to communicate toward the origin server.
    546       </p>
    547       <p id="rfc.section.5.1.p.2">These scenarios also complicate diagnosis of a 426 response. Since Upgrade is a hop-by-hop header, a proxy that does not recognize
    548          426 might remove the accompanying Upgrade header and prevent the client from determining the required protocol switch. If
    549          a client receives a 426 status without an accompanying Upgrade header, it will need to request an end to end tunnel connection
    550          as described in <a href="#requesting.a.tunnel.with.connect" title="Requesting a Tunnel with CONNECT">Section&nbsp;5.2</a> and repeat the request in order to obtain the required upgrade information.
    551       </p>
    552       <p id="rfc.section.5.1.p.3">This hop-by-hop definition of Upgrade was a deliberate choice. It allows for incremental deployment on either side of proxies,
    553          and for optimized protocols between cascaded proxies without the knowledge of the parties that are not a part of the change.
    554       </p>
    555       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="requesting.a.tunnel.with.connect" href="#requesting.a.tunnel.with.connect">Requesting a Tunnel with CONNECT</a></h2>
    556       <p id="rfc.section.5.2.p.1">A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line
    557          is always an 'authority' as defined by URI Generic Syntax <a href="#RFC2396"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[2]</cite></a>, which is to say the host name and port number destination of the requested connection separated by a colon:
    558       </p>
    559       <div id="rfc.figure.u.5"></div><pre class="text2">
     540               alternative courses which may be available to the user.
     541            </p>
     542            <p id="rfc.section.4.2.p.4">Note that even if a client is willing to use TLS, it must use the operations in <a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> to proceed; the TLS handshake cannot begin immediately after the 426 response.
     543            </p>
     544         </div>
     545      </div>
     546      <hr class="noprint">
     547      <div id="upgrade.across.proxies">
     548         <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#upgrade.across.proxies">Upgrade across Proxies</a></h1>
     549         <p id="rfc.section.5.p.1">As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with
     550            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.
     551         </p>
     552         <p id="rfc.section.5.p.2">Since TLS, in particular, requires end-to-end connectivity to provide authentication and prevent man-in-the-middle attacks,
     553            this memo specifies the CONNECT method to establish a tunnel across proxies.
     554         </p>
     555         <p id="rfc.section.5.p.3">Once a tunnel is established, any of the operations in <a href="#client.requested.upgrade.to.http.over.tls" title="Client Requested Upgrade to HTTP over TLS">Section&nbsp;3</a> can be used to establish a TLS connection.
     556         </p>
     557         <div>
     558            <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;Implications of Hop By Hop Upgrade
     559            </h2>
     560            <p id="rfc.section.5.1.p.1">If an origin server receives an Upgrade header from a proxy and responds with a 101 Switching Protocols response, it is changing
     561               the protocol only on the connection between the proxy and itself. Similarly, a proxy might return a 101 response to its client
     562               to change the protocol on that connection independently of the protocols it is using to communicate toward the origin server.
     563            </p>
     564            <p id="rfc.section.5.1.p.2">These scenarios also complicate diagnosis of a 426 response. Since Upgrade is a hop-by-hop header, a proxy that does not recognize
     565               426 might remove the accompanying Upgrade header and prevent the client from determining the required protocol switch. If
     566               a client receives a 426 status without an accompanying Upgrade header, it will need to request an end to end tunnel connection
     567               as described in <a href="#requesting.a.tunnel.with.connect" title="Requesting a Tunnel with CONNECT">Section&nbsp;5.2</a> and repeat the request in order to obtain the required upgrade information.
     568            </p>
     569            <p id="rfc.section.5.1.p.3">This hop-by-hop definition of Upgrade was a deliberate choice. It allows for incremental deployment on either side of proxies,
     570               and for optimized protocols between cascaded proxies without the knowledge of the parties that are not a part of the change.
     571            </p>
     572         </div>
     573         <div id="requesting.a.tunnel.with.connect">
     574            <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a href="#requesting.a.tunnel.with.connect">Requesting a Tunnel with CONNECT</a></h2>
     575            <p id="rfc.section.5.2.p.1">A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line
     576               is always an 'authority' as defined by URI Generic Syntax <a href="#RFC2396"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[2]</cite></a>, which is to say the host name and port number destination of the requested connection separated by a colon:
     577            </p>
     578            <div id="rfc.figure.u.5"></div><pre class="text2">
    560579   CONNECT server.example.com:80 HTTP/1.1
    561580   Host: server.example.com:80
    562581</pre><p id="rfc.section.5.2.p.3">Other HTTP mechanisms can be used normally with the CONNECT method -- except end-to-end protocol Upgrade requests, of course,
    563          since the tunnel must be established first.
    564       </p>
    565       <p id="rfc.section.5.2.p.4">For example, proxy authentication might be used to establish the authority to create a tunnel:</p>
    566       <div id="rfc.figure.u.6"></div><pre class="text2">
     582               since the tunnel must be established first.
     583            </p>
     584            <p id="rfc.section.5.2.p.4">For example, proxy authentication might be used to establish the authority to create a tunnel:</p>
     585            <div id="rfc.figure.u.6"></div><pre class="text2">
    567586   CONNECT server.example.com:80 HTTP/1.1
    568587   Host: server.example.com:80
    569588   Proxy-Authorization: basic aGVsbG86d29ybGQ=
    570589</pre><p id="rfc.section.5.2.p.6">Like any other pipelined HTTP/1.1 request, data to be tunneled may be sent immediately after the blank line. The usual caveats
    571          also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
    572          more than one TCP segment is outstanding.
    573       </p>
    574       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;Establishing a Tunnel with CONNECT
    575       </h2>
    576       <p id="rfc.section.5.3.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
    577          host and port, and has switched to tunneling the current connection to that server connection.
    578       </p>
    579       <p id="rfc.section.5.3.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
    580          first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
    581       </p>
    582       <p id="rfc.section.5.3.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established.
    583       </p>
    584       <p id="rfc.section.5.3.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
    585          the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
    586          peer undelivered, that data will be discarded.
    587       </p>
    588       <hr class="noprint">
    589       <h1 id="rfc.section.6" class="np"><a href="#rfc.section.6">6.</a>&nbsp;<a id="rationale.for.the.use.of.a.4xx.status.code" href="#rationale.for.the.use.of.a.4xx.status.code">Rationale for the use of a 4xx (client error) Status Code</a></h1>
    590       <p id="rfc.section.6.p.1">Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status
    591          code allows a server to definitively state the precise protocol extensions a given resource must be served with.
    592       </p>
    593       <p id="rfc.section.6.p.2">It might at first appear that the response should have been some form of redirection (a 3xx code), by analogy to an old-style
    594          redirection to an https: URI. User agents that do not understand Upgrade: preclude this.
    595       </p>
    596       <p id="rfc.section.6.p.3">Suppose that a 3xx code had been assigned for "Upgrade Required"; a user agent that did not recognize it would treat it as
    597          300. It would then properly look for a "Location" header in the response and attempt to repeat the request at the URL in that
    598          header field. Since it did not know to Upgrade to incorporate the TLS layer, it would at best fail again at the new URL.
    599       </p>
    600       <hr class="noprint">
    601       <h1 id="rfc.section.7" class="np"><a href="#rfc.section.7">7.</a>&nbsp;IANA Considerations
    602       </h1>
    603       <p id="rfc.section.7.p.1">IANA shall create registries for two name spaces, as described in BCP 26 <a href="#RFC2434"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[10]</cite></a>:
    604       </p>
    605       <ul>
    606          <li>HTTP Status Codes</li>
    607          <li>HTTP Upgrade Tokens</li>
    608       </ul>
    609       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;HTTP Status Code Registry
    610       </h2>
    611       <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response. The
    612          initial values for this name space are those specified by:
    613       </p>
    614       <ol>
    615          <li>Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a></li>
    616          <li>Web Distributed Authoring and Versioning <a href="#RFC2518"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[4]</cite></a> [defines 420-424]
    617          </li>
    618          <li>WebDAV Advanced Collections <a href="#ADVCOL"><cite title="WebDAV Advanced Collection Protocol">[5]</cite></a> (Work in Progress) [defines 425]
    619          </li>
    620          <li><a href="#rationale.for.the.use.of.a.4xx.status.code" title="Rationale for the use of a 4xx (client error) Status Code">Section&nbsp;6</a> [defines 426]
    621          </li>
    622       </ol>
    623       <p id="rfc.section.7.1.p.2">Values to be added to this name space <em class="bcp14">SHOULD</em> be subject to review in the form of a standards track document within the IETF Applications Area. Any such document <em class="bcp14">SHOULD</em> be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>.
    624       </p>
    625       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;HTTP Upgrade Token Registry
    626       </h2>
    627       <p id="rfc.section.7.2.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade HTTP header
    628          field. Each registered token should be associated with one or a set of specifications, and with contact information.
    629       </p>
    630       <p id="rfc.section.7.2.p.2">The Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> specifies that these tokens obey the production for 'product':
    631       </p>
    632       <div id="rfc.figure.u.7"></div><pre class="inline">
     590               also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
     591               more than one TCP segment is outstanding.
     592            </p>
     593         </div>
     594         <div>
     595            <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;Establishing a Tunnel with CONNECT
     596            </h2>
     597            <p id="rfc.section.5.3.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested
     598               host and port, and has switched to tunneling the current connection to that server connection.
     599            </p>
     600            <p id="rfc.section.5.3.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the
     601               first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority.
     602            </p>
     603            <p id="rfc.section.5.3.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established.
     604            </p>
     605            <p id="rfc.section.5.3.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
     606               the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that
     607               peer undelivered, that data will be discarded.
     608            </p>
     609         </div>
     610      </div>
     611      <hr class="noprint">
     612      <div id="rationale.for.the.use.of.a.4xx.status.code">
     613         <h1 id="rfc.section.6" class="np"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#rationale.for.the.use.of.a.4xx.status.code">Rationale for the use of a 4xx (client error) Status Code</a></h1>
     614         <p id="rfc.section.6.p.1">Reliable, interoperable negotiation of Upgrade features requires an unambiguous failure signal. The 426 Upgrade Required status
     615            code allows a server to definitively state the precise protocol extensions a given resource must be served with.
     616         </p>
     617         <p id="rfc.section.6.p.2">It might at first appear that the response should have been some form of redirection (a 3xx code), by analogy to an old-style
     618            redirection to an https: URI. User agents that do not understand Upgrade: preclude this.
     619         </p>
     620         <p id="rfc.section.6.p.3">Suppose that a 3xx code had been assigned for "Upgrade Required"; a user agent that did not recognize it would treat it as
     621            300. It would then properly look for a "Location" header in the response and attempt to repeat the request at the URL in that
     622            header field. Since it did not know to Upgrade to incorporate the TLS layer, it would at best fail again at the new URL.
     623         </p>
     624      </div>
     625      <hr class="noprint">
     626      <div>
     627         <h1 id="rfc.section.7" class="np"><a href="#rfc.section.7">7.</a>&nbsp;IANA Considerations
     628         </h1>
     629         <p id="rfc.section.7.p.1">IANA shall create registries for two name spaces, as described in BCP 26 <a href="#RFC2434"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[10]</cite></a>:
     630         </p>
     631         <ul>
     632            <li>HTTP Status Codes</li>
     633            <li>HTTP Upgrade Tokens</li>
     634         </ul>
     635         <div>
     636            <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;HTTP Status Code Registry
     637            </h2>
     638            <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response. The
     639               initial values for this name space are those specified by:
     640            </p>
     641            <ol>
     642               <li>Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a></li>
     643               <li>Web Distributed Authoring and Versioning <a href="#RFC2518"><cite title="HTTP Extensions for Distributed Authoring -- WEBDAV">[4]</cite></a> [defines 420-424]
     644               </li>
     645               <li>WebDAV Advanced Collections <a href="#ADVCOL"><cite title="WebDAV Advanced Collection Protocol">[5]</cite></a> (Work in Progress) [defines 425]
     646               </li>
     647               <li><a href="#rationale.for.the.use.of.a.4xx.status.code" title="Rationale for the use of a 4xx (client error) Status Code">Section&nbsp;6</a> [defines 426]
     648               </li>
     649            </ol>
     650            <p id="rfc.section.7.1.p.2">Values to be added to this name space <em class="bcp14">SHOULD</em> be subject to review in the form of a standards track document within the IETF Applications Area. Any such document <em class="bcp14">SHOULD</em> be traceable through statuses of either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>.
     651            </p>
     652         </div>
     653         <div>
     654            <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;HTTP Upgrade Token Registry
     655            </h2>
     656            <p id="rfc.section.7.2.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade HTTP header
     657               field. Each registered token should be associated with one or a set of specifications, and with contact information.
     658            </p>
     659            <p id="rfc.section.7.2.p.2">The Draft Standard for HTTP/1.1 <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a> specifies that these tokens obey the production for 'product':
     660            </p>
     661            <div id="rfc.figure.u.7"></div><pre class="inline">
    633662   product         = token ["/" product-version]
    634663   product-version = token
    635664</pre><p id="rfc.section.7.2.p.4">Registrations should be allowed on a First Come First Served basis as described in BCP 26 <a href="#RFC2434"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[10]</cite></a>. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules:
    636       </p>
    637       <ol>
    638          <li>A token, once registered, stays registered forever.</li>
    639          <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration.
    640          </li>
    641          <li>The registration <em class="bcp14">MUST</em> name a point of contact.
    642          </li>
    643          <li>The registration <em class="bcp14">MAY</em> name the documentation required for the token.
    644          </li>
    645          <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
    646          </li>
    647          <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered.
    648          </li>
    649          <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted.
    650          </li>
    651       </ol>
    652       <p id="rfc.section.7.2.p.5">This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[6]</cite></a>.
    653       </p>
    654       <p id="rfc.section.7.2.p.6">It is NOT required that specifications for upgrade tokens be made publicly available, but the contact information for the
    655          registration <em class="bcp14">SHOULD</em> be.
    656       </p>
    657       <hr class="noprint">
    658       <h1 id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a>&nbsp;Security Considerations
    659       </h1>
    660       <p id="rfc.section.8.p.1">The potential for a man-in-the-middle attack (deleting the Upgrade header) remains the same as current, mixed http/https practice: </p>
    661       <ul>
    662          <li>Removing the Upgrade header is similar to rewriting web pages to change https:// links to http:// links.</li>
    663          <li>The risk is only present if the server is willing to vend such information over both a secure and an insecure channel in the
    664             first place.
    665          </li>
    666          <li>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
    667             a no-op method like OPTIONS.
    668          </li>
    669          <li>Finally, as the https: specification warns, "users should carefully examine the certificate presented by the server to determine
    670             if it meets their expectations".
    671          </li>
    672       </ul>
    673       <p id="rfc.section.8.p.2">Furthermore, for clients that do not explicitly try to invoke TLS, servers can use the Upgrade header in any response other
    674          than 101 or 426 to advertise TLS compliance. Since TLS compliance should be considered a feature of the server and not the
    675          resource at hand, it should be sufficient to send it once, and let clients cache that fact.
    676       </p>
    677       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;Implications for the https: URI Scheme
    678       </h2>
    679       <p id="rfc.section.8.1.p.1">While nothing in this memo affects the definition of the 'https' URI scheme, widespread adoption of this mechanism for HyperText
    680          content could use 'http' to identify both secure and non-secure resources.
    681       </p>
    682       <p id="rfc.section.8.1.p.2">The choice of what security characteristics are required on the connection is left to the client and server. This allows either
    683          party to use any information available in making this determination. For example, user agents may rely on user preference
    684          settings or information about the security of the network such as 'TLS required on all POST operations not on my local net',
    685          or servers may apply resource access rules such as 'the FORM on this page must be served and submitted using TLS'.
    686       </p>
    687       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;Security Considerations for CONNECT
    688       </h2>
    689       <p id="rfc.section.8.2.p.1">A generic TCP tunnel is fraught with security risks. First, such authorization should be limited to a small number of known
    690          ports. The Upgrade: mechanism defined here only requires onward tunneling at port 80. Second, since tunneled data is opaque
    691          to the proxy, there are additional risks to tunneling to other well-known or reserved ports. A putative HTTP client CONNECTing
    692          to port 25 could relay spam via SMTP, for example.
    693       </p>
     665            </p>
     666            <ol>
     667               <li>A token, once registered, stays registered forever.</li>
     668               <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration.
     669               </li>
     670               <li>The registration <em class="bcp14">MUST</em> name a point of contact.
     671               </li>
     672               <li>The registration <em class="bcp14">MAY</em> name the documentation required for the token.
     673               </li>
     674               <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
     675               </li>
     676               <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered.
     677               </li>
     678               <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted.
     679               </li>
     680            </ol>
     681            <p id="rfc.section.7.2.p.5">This specification defines the protocol token "TLS/1.0" as the identifier for the protocol specified by The TLS Protocol <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[6]</cite></a>.
     682            </p>
     683            <p id="rfc.section.7.2.p.6">It is NOT required that specifications for upgrade tokens be made publicly available, but the contact information for the
     684               registration <em class="bcp14">SHOULD</em> be.
     685            </p>
     686         </div>
     687      </div>
     688      <hr class="noprint">
     689      <div>
     690         <h1 id="rfc.section.8" class="np"><a href="#rfc.section.8">8.</a>&nbsp;Security Considerations
     691         </h1>
     692         <p id="rfc.section.8.p.1">The potential for a man-in-the-middle attack (deleting the Upgrade header) remains the same as current, mixed http/https practice: </p>
     693         <ul>
     694            <li>Removing the Upgrade header is similar to rewriting web pages to change https:// links to http:// links.</li>
     695            <li>The risk is only present if the server is willing to vend such information over both a secure and an insecure channel in the
     696               first place.
     697            </li>
     698            <li>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
     699               a no-op method like OPTIONS.
     700            </li>
     701            <li>Finally, as the https: specification warns, "users should carefully examine the certificate presented by the server to determine
     702               if it meets their expectations".
     703            </li>
     704         </ul>
     705         <p id="rfc.section.8.p.2">Furthermore, for clients that do not explicitly try to invoke TLS, servers can use the Upgrade header in any response other
     706            than 101 or 426 to advertise TLS compliance. Since TLS compliance should be considered a feature of the server and not the
     707            resource at hand, it should be sufficient to send it once, and let clients cache that fact.
     708         </p>
     709         <div>
     710            <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;Implications for the https: URI Scheme
     711            </h2>
     712            <p id="rfc.section.8.1.p.1">While nothing in this memo affects the definition of the 'https' URI scheme, widespread adoption of this mechanism for HyperText
     713               content could use 'http' to identify both secure and non-secure resources.
     714            </p>
     715            <p id="rfc.section.8.1.p.2">The choice of what security characteristics are required on the connection is left to the client and server. This allows either
     716               party to use any information available in making this determination. For example, user agents may rely on user preference
     717               settings or information about the security of the network such as 'TLS required on all POST operations not on my local net',
     718               or servers may apply resource access rules such as 'the FORM on this page must be served and submitted using TLS'.
     719            </p>
     720         </div>
     721         <div>
     722            <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;Security Considerations for CONNECT
     723            </h2>
     724            <p id="rfc.section.8.2.p.1">A generic TCP tunnel is fraught with security risks. First, such authorization should be limited to a small number of known
     725               ports. The Upgrade: mechanism defined here only requires onward tunneling at port 80. Second, since tunneled data is opaque
     726               to the proxy, there are additional risks to tunneling to other well-known or reserved ports. A putative HTTP client CONNECTing
     727               to port 25 could relay spam via SMTP, for example.
     728            </p>
     729         </div>
     730      </div>
    694731      <h1 class="np" id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References
    695732      </h1>
    696       <table> 
     733      <table>
    697734         <tr>
    698735            <td class="reference"><b id="RFC2616">[1]</b></td>
    699736            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    700737            </td>
    701          </tr> 
     738         </tr>
    702739         <tr>
    703740            <td class="reference"><b id="RFC2396">[2]</b></td>
    704741            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
    705742            </td>
    706          </tr> 
     743         </tr>
    707744         <tr>
    708745            <td class="reference"><b id="RFC2818">[3]</b></td>
    709746            <td class="top"><a href="mailto:ekr@rtfm.com" title="RTFM, Inc.">Rescorla, E.</a>, “<a href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>”, RFC&nbsp;2818, May&nbsp;2000.
    710747            </td>
    711          </tr> 
     748         </tr>
    712749         <tr>
    713750            <td class="reference"><b id="RFC2518">[4]</b></td>
    714751            <td class="top"><a href="mailto:yarong@microsoft.com" title="Microsoft Corporation">Goland, Y.</a>, <a href="mailto:ejw@ics.uci.edu" title="Dept. Of Information and Computer Science, University of California, Irvine">Whitehead, E.</a>, <a href="mailto:asad@netscape.com" title="Netscape">Faizi, A.</a>, <a href="mailto:srcarter@novell.com" title="Novell">Carter, S.</a>, and <a href="mailto:dcjensen@novell.com" title="Novell">D. Jensen</a>, “<a href="http://tools.ietf.org/html/rfc2518">HTTP Extensions for Distributed Authoring -- WEBDAV</a>”, RFC&nbsp;2518, February&nbsp;1999.
    715752            </td>
    716          </tr> 
     753         </tr>
    717754         <tr>
    718755            <td class="reference"><b id="ADVCOL">[5]</b></td>
    719756            <td class="top">Slein, J. and E. Whitehead, “WebDAV Advanced Collection Protocol”.<br>Work In Progress.
    720757            </td>
    721          </tr> 
     758         </tr>
    722759         <tr>
    723760            <td class="reference"><b id="RFC2246">[6]</b></td>
    724761            <td class="top"><a href="mailto:tdierks@certicom.com" title="Certicom">Dierks, T.</a> and <a href="mailto:callen@certicom.com" title="Certicom">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>”, RFC&nbsp;2246, January&nbsp;1999.
    725762            </td>
    726          </tr> 
     763         </tr>
    727764         <tr>
    728765            <td class="reference"><b id="RFC2565">[7]</b></td>
    729766            <td class="top"><a href="mailto:rherriot@pahv.xerox.com" title="Xerox Corporation">Herriot, R.</a>, <a href="mailto:sbutler@boi.hp.com" title="Hewlett-Packard">Butler, S.</a>, <a href="mailto:paulmo@microsoft.com" title="Microsoft">Moore, P.</a>, and <a href="mailto:rturner@sharplabs.com" title="Sharp Laboratories">R. Turner</a>, “<a href="http://tools.ietf.org/html/rfc2565">Internet Printing Protocol/1.0: Encoding and Transport</a>”, RFC&nbsp;2565, April&nbsp;1999.
    730767            </td>
    731          </tr> 
     768         </tr>
    732769         <tr>
    733770            <td class="reference"><b id="Luo97">[8]</b></td>
    734771            <td class="top">Luotonen, A., “Tunneling TCP based protocols through Web proxy servers”.<br>Work In Progress. (Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
    735772            </td>
    736          </tr> 
     773         </tr>
    737774         <tr>
    738775            <td class="reference"><b id="RFC2629">[9]</b></td>
    739776            <td class="top"><a href="mailto:mrose@not.invisible.net" title="Invisible Worlds, Inc.">Rose, M.</a>, “<a href="http://tools.ietf.org/html/rfc2629">Writing I-Ds and RFCs using XML</a>”, RFC&nbsp;2629, June&nbsp;1999.
    740777            </td>
    741          </tr> 
     778         </tr>
    742779         <tr>
    743780            <td class="reference"><b id="RFC2434">[10]</b></td>
    744781            <td class="top"><a href="mailto:narten@raleigh.ibm.com" title="IBM Corporation">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Maxware">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc2434">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP&nbsp;26, RFC&nbsp;2434, October&nbsp;1998.
    745782            </td>
    746          </tr> 
     783         </tr>
    747784         <tr>
    748785            <td class="reference"><b id="RFC2119">[11]</b></td>
    749786            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
    750787            </td>
    751          </tr> 
     788         </tr>
    752789      </table>
    753790      <hr class="noprint">
    754791      <div class="avoidbreak">
    755792         <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>
    756          <address class="vcard"><span class="vcardline"><span class="fn">Rohit Khare</span><span class="n hidden"><span class="family-name">Khare</span><span class="given-name">Rohit</span></span></span><span class="org vcardline">4K Associates / UC Irvine</span><span class="vcardline">EMail: <a href="mailto:rohit@4K-associates.com"><span class="email">rohit@4K-associates.com</span></a></span></address>
    757          <address class="vcard"><span class="vcardline"><span class="fn">Scott Lawrence</span><span class="n hidden"><span class="family-name">Lawrence</span><span class="given-name">Scott</span></span></span><span class="org vcardline">Agranat Systems, Inc.</span><span class="vcardline">EMail: <a href="mailto:lawrence@agranat.com"><span class="email">lawrence@agranat.com</span></a></span></address>
    758       </div>
    759       <hr class="noprint">
    760       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgments
    761       </h1>
    762       <p id="rfc.section.A.p.1">The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy
    763          servers", <a href="#Luo97"><cite title="Tunneling TCP based protocols through Web proxy servers">[8]</cite></a> by Ari Luotonen of Netscape Communications Corporation. It was widely implemented by HTTP proxies, but was never made a part
    764          of any IETF Standards Track document. The method name CONNECT was reserved, but not defined in <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>.
    765       </p>
    766       <p id="rfc.section.A.p.2">The definition provided here is derived directly from that earlier memo, with some editorial changes and conformance to the
    767          stylistic conventions since established in other HTTP specifications.
    768       </p>
    769       <p id="rfc.section.A.p.3">Additional Thanks to: </p>
    770       <ul>
    771          <li>Paul Hoffman for his work on the STARTTLS command extension for ESMTP.</li>
    772          <li>Roy Fielding for assistance with the rationale behind Upgrade: and its interaction with OPTIONS.</li>
    773          <li>Eric Rescorla for his work on standardizing the existing https: practice to compare with.</li>
    774          <li>Marshall Rose, for the xml2rfc document type description and tools <a href="#RFC2629"><cite title="Writing I-Ds and RFCs using XML">[9]</cite></a>.
    775          </li>
    776          <li>Jim Whitehead, for sorting out the current range of available HTTP status codes.</li>
    777          <li>Henrik Frystyk Nielsen, whose work on the Mandatory extension mechanism pointed out a hop-by-hop Upgrade still requires tunneling.</li>
    778          <li>Harald Alvestrand for improvements to the token registration rules.</li>
    779       </ul>
    780       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    781       <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
    782       <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
    783          explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
    784          restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
    785          works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
    786          to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
    787          in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
    788          translate it into languages other than English.
    789       </p>
    790       <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
    791       <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
    792          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
    793          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
    794          PURPOSE.
    795       </p>
    796       <hr class="noprint">
    797       <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    798       <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
    799          to pertain to the implementation or use of the technology described in this document or the extent to which any license under
    800          such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
    801          Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
    802          found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
    803          or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
    804          or users of this specification can be obtained from the IETF Secretariat.
    805       </p>
    806       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    807          rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
    808          Executive Director.
    809       </p>
    810       <h1>Acknowledgment</h1>
    811       <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
     793         <p><b>Rohit Khare</b><br>4K Associates / UC Irvine<br>EMail: <a href="mailto:rohit@4K-associates.com">rohit@4K-associates.com</a></p>
     794         <p><b>Scott Lawrence</b><br>Agranat Systems, Inc.<br>EMail: <a href="mailto:lawrence@agranat.com">lawrence@agranat.com</a></p>
     795      </div>
     796      <hr class="noprint">
     797      <div>
     798         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Acknowledgments
     799         </h1>
     800         <p id="rfc.section.A.p.1">The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy
     801            servers", <a href="#Luo97"><cite title="Tunneling TCP based protocols through Web proxy servers">[8]</cite></a> by Ari Luotonen of Netscape Communications Corporation. It was widely implemented by HTTP proxies, but was never made a part
     802            of any IETF Standards Track document. The method name CONNECT was reserved, but not defined in <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[1]</cite></a>.
     803         </p>
     804         <p id="rfc.section.A.p.2">The definition provided here is derived directly from that earlier memo, with some editorial changes and conformance to the
     805            stylistic conventions since established in other HTTP specifications.
     806         </p>
     807         <p id="rfc.section.A.p.3">Additional Thanks to: </p>
     808         <ul>
     809            <li>Paul Hoffman for his work on the STARTTLS command extension for ESMTP.</li>
     810            <li>Roy Fielding for assistance with the rationale behind Upgrade: and its interaction with OPTIONS.</li>
     811            <li>Eric Rescorla for his work on standardizing the existing https: practice to compare with.</li>
     812            <li>Marshall Rose, for the xml2rfc document type description and tools <a href="#RFC2629"><cite title="Writing I-Ds and RFCs using XML">[9]</cite></a>.
     813            </li>
     814            <li>Jim Whitehead, for sorting out the current range of available HTTP status codes.</li>
     815            <li>Henrik Frystyk Nielsen, whose work on the Mandatory extension mechanism pointed out a hop-by-hop Upgrade still requires tunneling.</li>
     816            <li>Harald Alvestrand for improvements to the token registration rules.</li>
     817         </ul>
     818      </div>
     819      <div id="rfc.copyright">
     820         <h1><a href="#rfc.copyright">Full Copyright Statement</a></h1>
     821         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
     822         <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
     823            explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
     824            restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
     825            works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
     826            to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
     827            in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
     828            translate it into languages other than English.
     829         </p>
     830         <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
     831         <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
     832            ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
     833            OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
     834            PURPOSE.
     835         </p>
     836      </div>
     837      <hr class="noprint">
     838      <div id="rfc.ipr">
     839         <h1 class="np"><a href="#rfc.ipr">Intellectual Property</a></h1>
     840         <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
     841            to pertain to the implementation or use of the technology described in this document or the extent to which any license under
     842            such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
     843            Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
     844            found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
     845            or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
     846            or users of this specification can be obtained from the IETF Secretariat.
     847         </p>
     848         <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
     849            rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
     850            Executive Director.
     851         </p>
     852      </div>
     853      <div>
     854         <h1>Acknowledgment</h1>
     855         <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
     856      </div>
    812857   </body>
    813858</html>
Note: See TracChangeset for help on using the changeset viewer.