RFC 2817 (rfc2817) - Page 4 of 13

Upgrading to TLS Within HTTP/1

RFC 2817                  HTTP Upgrade to TLS                   May 2000


2.1 Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC 2119 [11].

3. Client Requested Upgrade to HTTP over TLS

   When the client sends an HTTP/1.1 request with an Upgrade header
   field containing the token "TLS/1.0", it is requesting the server to
   complete the current HTTP/1.1 request after switching to TLS/1.0.

3.1 Optional Upgrade

   A client MAY offer to switch to secured operation during any clear
   HTTP request when an unsecured response would be acceptable:

       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

   In this case, the server MAY respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   section).

   Note that HTTP/1.1 [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:




Khare & Lawrence            Standards Track