HTTP/1.1 Upgrade header

HTTP/1.1 introduced support for the Upgrade header field. In the exchange, the client begins by making a clear-text request, which is later upgraded to Transport Layer Security (TLS). Either the client or the server may request that the connection be upgraded. The most common usage is a clear-text request by the client followed by a server demand to upgrade the connection:

Client:

GET /encrypted-area HTTP/1.1
Host: www.example.com

Server:

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

The server returns a 426 status-code to alert legacy clients that the failure was client-related (400 level codes indicate a client failure: List of HTTP status codes).

This method for establishing a secure connection is advantageous because it:

• Does not require messy and problematic redirection and URL rewriting on the server side.
• Enables virtual hosting of secured websites (although HTTPS also allows this using Server Name Indication).
• Reduces the potential for user confusion by providing a single way to access a particular resource.

A disadvantage of this method is that the client cannot specify the requirement for a secure HTTP in the URI. Thus, the (untrusted) server will be responsible for enabling secure HTTP, not the (trusted) client.