Movatterモバイル変換

HTTP/1.1 Upgrade header

From Wikipedia, the free encyclopedia

HTTP header field introduced in HTTP/1.1

HTTP

Persistence Compression HTTPS QUIC
Request methods
OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT PATCH
Header fields
Cookie ETag Location HTTP referer DNT X-Forwarded-For Upgrade
Response status codes
301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found 451 Unavailable for Legal Reasons
Security access control methods
Basic access authentication Digest access authentication
Security vulnerabilities
HTTP header injection HTTP request smuggling HTTP response splitting HTTP parameter pollution
v t e

TheUpgrade header field is anHTTP header field introduced inHTTP/1.1. In the exchange, the client begins by making acleartext request, which is later upgraded to a newerHTTP 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 a426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.

Use with TLS

[edit]

One use is to begin a request on the normal HTTP port but switch toTransport Layer Security (TLS).^[1] In practice such use is rare, withHTTPS being a far more common way to initiate encrypted HTTP.

The server returns a426status 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 problematicURL redirection on the server side;
Enablesvirtual hosting of secured websites (although HTTPS also allows this usingServer 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, aman-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 ahop basis,HTTP tunneling may be required to bypass proxy servers.

Use with WebSocket

[edit]

WebSocket also uses this mechanism to set up a connection with a HTTP server in a compatible way.^[2] The WebSocket Protocol has two parts: ahandshake to establish the upgraded connection, then the actual data transfer. First, a client requests a WebSocket connection by using theUpgrade: WebSocket andConnection: 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 sameUpgrade: WebSocket andConnection: Upgrade headers and completes the handshake.^[3] Once the handshake is completed successfully, data transfer begins.

Use with HTTP/2

[edit]

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