Jump to content

HTTP/1.1 Upgrade header

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rystheguy (talk | contribs) at 08:48, 23 January 2016 (Undid revision 701233197 by 63.225.91.169 (talk)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

HTTP
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

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 a newer http protocol version or switched to a different protocol. 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 (TLS).[1] In practice such use is rare with the https URL scheme 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: 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. Therefore, a man-in-the-middle may maintain an unencrypted and unauthenticated connection with the client while maintaining an encrypted connection with the server.

Use with WebSockets

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: 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.[3] Once the handshake is completed successfully, data transfer begins.

Use with HTTP/2

HTTP Upgrade mechanism is used to establish HTTP/2 starting from plain http.[4] The client starts a HTTP/1.1 connection and sends "Upgrade: h2c" header. If the server supports HTTP/2, it replies with HTTP 101 Switching Protocol status code.

See also

References

  1. ^ RFC 2817
  2. ^ "The WebSocket Protocol". IETF. Retrieved 15 December 2013.
  3. ^ Raymor, Brian. "WebSockets: Stable and Ready for Developers". Microsoft Developer Network. Retrieved 15 December 2013.
  4. ^ "Hypertext Transfer Protocol version 2 draft". HTTPbis Working Group. Retrieved 27 November 2014.
Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP/1.1_Upgrade_header&oldid=701233331"