Reference articles on history, science, culture and more
Encyclopedia

HTTP/1.1 Upgrade header

HTTP header field introduced in HTTP/1.1

Image credit is listed at the end of this article.

The Upgrade header field is an HTTP header field introduced in HTTP/1.1. In the exchange, the client begins by making a cleartext request, which is later upgraded to a newer HTTP protocol version or switched to a different protocol. A connection upgrade must be requested by the client; if the server wants to enforce an upgrade it may send a 426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.

01Use with TLS

One use is to begin a request on the normal HTTP port but switch to Transport Layer Security (TLS) as described in RFC 2817. In practice such use is rare, with HTTPS being a far more common way to initiate encrypted HTTP.

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

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

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

If the same resources are available from the server via both encrypted secure means and unencrypted clear means, a man-in-the-middle may maintain an unencrypted and unauthenticated connection with the client while maintaining an encrypted connection with the server.

Disadvantages of this method include:

  • The client cannot specify the requirement for a secure HTTP in the URI (though the client can require such via the upgrade negotiation); and
  • Since HTTP is defined on a hop basis, HTTP tunneling may be required to bypass proxy servers.

02Use with WebSocket

WebSocket also uses this mechanism to set up a connection with a HTTP server in a compatible way. The WebSocket Protocol has two parts: a handshake to establish the upgraded connection, then the actual data transfer. First, a client requests a WebSocket connection by using the Upgrade: websocket and Connection: Upgrade headers, along with a few protocol-specific headers to establish the version being used and set up a handshake. The server, if it supports the protocol, replies with the same Upgrade: websocket and Connection: Upgrade headers and completes the handshake. Once the handshake is completed successfully, data transfer begins.

03Use with HTTP/2

The HTTP Upgrade mechanism is used to establish HTTP/2 starting from plain HTTP. The client starts an HTTP/1.1 connection and sends an Upgrade: h2c header. If the server supports HTTP/2, it replies with HTTP 101 Switching Protocol status code. The HTTP Upgrade mechanism is used only for cleartext HTTP2 (h2c). In the case of HTTP2 over TLS (h2), the ALPN TLS protocol extension is used instead.

Watch videos about HTTP/1.1 Upgrade headerExplainers and documentaries on YouTube (opens in a new tab)

Sources and credits

This article is adapted from the Wikipedia article HTTP/1.1 Upgrade header, written by its contributors and licensed under CC BY-SA 4.0. Fathomly has changed the layout, removed citation markers, navigation and maintenance notices, and adjusted punctuation. This adapted version is shared under the same license. For references, see the original article.

Images, from Wikimedia Commons:

  • HTTP logo.svg by IETF HTTP Working Group (HTTPbis), Public domain

Fathomly is not affiliated with or endorsed by the Wikimedia Foundation. Spotted a problem? Tell us.