Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
   supplied within a Connection header field (section 14.10) whenever
   Upgrade is present in an HTTP/1.1 message".

3.2 Mandatory Upgrade

   If an unsecured response would be unacceptable, a client MUST send an
   OPTIONS request first to complete the switch to TLS/1.0 (if
   possible).

       OPTIONS * HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

3.3 Server Acceptance of Upgrade Request

   As specified in HTTP/1.1 [1], if the server is prepared to initiate
   the TLS handshake, it MUST send the intermediate "101 Switching
   Protocol" and MUST include an Upgrade response header specifying the
   tokens of the protocol stack it is switching to:





 
RFC 2817                  HTTP Upgrade to TLS                   May 2000


       HTTP/1.1 101 Switching Protocols
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

   Note that the protocol tokens listed in the Upgrade header of a 101
   Switching Protocols response specify an ordered 'bottom-up' stack.

   As specified in  HTTP/1.1 [1], Section 10.1.2: "The server will
   switch protocols to those defined by the response's Upgrade header
   field immediately after the empty line which terminates the 101
   response".

   Once the TLS handshake completes successfully, the server MUST
   continue with the response to the original request. Any TLS handshake
   failure MUST lead to disconnection, per the TLS error alert
   specification.

4. Server Requested Upgrade to HTTP over TLS

   The Upgrade response header field advertises possible protocol
   upgrades a server MAY accept. In conjunction with the "426 Upgrade
   Required" status code, a server can advertise the exact protocol
   upgrade(s) that a client MUST accept to complete the request.

4.1 Optional Advertisement

   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed.

4.2 Mandatory Advertisement

   A server MAY indicate that a client request can not be completed
   without TLS using the "426 Upgrade Required" status code, which MUST
   include an an Upgrade header field specifying the token of the
   required TLS version.

       HTTP/1.1 426 Upgrade Required
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

   The server SHOULD include a message body in the 426 response which
   indicates in human readable form the reason for the error and
   describes any alternative courses which may be available to the user.

   Note that even if a client is willing to use TLS, it must use the
   operations in Section 3 to proceed; the TLS handshake cannot begin
   immediately after the 426 response.




 
RFC 2817                  HTTP Upgrade to TLS                   May 2000


5. Upgrade across Proxies

   As a hop-by-hop header, Upgrade is negotiated between each pair of
   HTTP counterparties.  If a User Agent sends a request with an Upgrade
   header to a proxy, it is requesting a change to the protocol between
   itself and the proxy, not an end-to-end change.

   Since TLS, in particular, requires end-to-end connectivity to provide
   authentication and prevent man-in-the-middle attacks, this memo
   specifies the CONNECT method to establish a tunnel across proxies.

   Once a tunnel is established, any of the operations in Section 3 can
   be used to establish a TLS connection.