# HTTP/1.1 Upgrade header

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/HTTP/1.1_Upgrade_header
> Markdown URL: https://mediated.wiki/source/HTTP/1.1_Upgrade_header.md
> Source: https://en.wikipedia.org/wiki/HTTP%2F1.1_Upgrade_header
> Source revision: 1344924315
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

The **Upgrade header** field is an [HTTP header field](/source/List_of_HTTP_header_fields) introduced in [HTTP/1.1](/source/HTTP/1.1). In the exchange, the client begins by making a [cleartext](/source/Cleartext) request, which is later upgraded to a newer [HTTP](/source/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.

## Use with TLS

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

The server returns a 426 [status code](/source/List_of_HTTP_status_codes) 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](/source/URL_redirection) on the server side;
- Enables [virtual hosting](/source/Virtual_hosting) of secured websites (although HTTPS also allows this using [Server Name Indication](/source/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](/source/Man-in-the-middle_attack) 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](/source/Hop_(networking)) basis, [HTTP tunneling](/source/HTTP_tunnel) may be required to bypass proxy servers.

## Use with WebSocket

[WebSocket](/source/WebSocket) also uses this mechanism to set up a connection with a HTTP server in a compatible way.[1] The WebSocket Protocol has two parts: a [handshake](/source/Handshake_(computing)) 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.[2] Once the handshake is completed successfully, data transfer begins.

## Use with HTTP/2

The HTTP Upgrade mechanism is used to establish [HTTP/2](/source/HTTP/2) starting from plain HTTP.[3] 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](/source/List_of_HTTP_status_codes#101) status code. The HTTP Upgrade mechanism is used only for cleartext HTTP2 (h2c). In the case of HTTP2 over TLS (h2), the [ALPN](/source/Application-Layer_Protocol_Negotiation) TLS protocol extension is used instead.

## See also

- [Opportunistic encryption](/source/Opportunistic_encryption)
- [Secure Hypertext Transfer Protocol](/source/Secure_Hypertext_Transfer_Protocol)

## References

1. Fette, I. & Melnikov, A. (2011). ["The WebSocket Protocol"](http://tools.ietf.org/html/rfc6455). IETF. [doi:10.17487/RFC6455](https://doi.org/10.17487/RFC6455). Retrieved 15 December 2013.

1. Raymor, Brian. ["WebSockets: Stable and Ready for Developers"](https://web.archive.org/web/20131216093539/http://msdn.microsoft.com/en-us/hh969243.aspx). Microsoft Developer Network. Archived from [the original](http://msdn.microsoft.com/en-us/hh969243.aspx) on 16 December 2013. Retrieved 15 December 2013.

1. ["Hypertext Transfer Protocol Version 2 (HTTP/2)"](https://tools.ietf.org/html/rfc7540#section-3.2)

## External links

- Hypertext Transfer Protocol (HTTP) Upgrade Token Registry at [IANA](/source/Internet_Assigned_Numbers_Authority)

---
Adapted from the Wikipedia article [HTTP/1.1 Upgrade header](https://en.wikipedia.org/wiki/HTTP%2F1.1_Upgrade_header) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/HTTP%2F1.1_Upgrade_header?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.