Articulo de referencia

HTTP/1.1 Upgrade header

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 HT...

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.

Use 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 426status 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.

Use with WebSocket

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 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

El mecanismo HTTP Upgrade se utiliza para establecer HTTP/2 a partir de HTTP simple. [ 3 ] El cliente inicia una conexión HTTP/1.1 y envía una Upgrade: h2ccabecera. Si el servidor admite HTTP/2, responde con el código de estado HTTP 101 Switching Protocol . El mecanismo HTTP Upgrade se utiliza únicamente para HTTP/2 en texto plano (h2c). En el caso de HTTP/2 sobre TLS (h2), se utiliza la extensión de protocolo ALPN TLS.

Véase también

Referencias

  1. Fette, I.; Melnikov, A. (2011). "El protocolo WebSocket" . IETF. doi : 10.17487/RFC6455 . Recuperado el 15 de diciembre de 2013 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  2. Raymor, Brian. "WebSockets: Estable y listo para desarrolladores" . Microsoft Developer Network. Archivado del original el 16 de diciembre de 2013. Consultado el 15 de diciembre de 2013 .
  3. "Inicio de HTTP/2 para URI "http" . Protocolo de transferencia de hipertexto versión 2 (HTTP/2) . IETF . doi : 10.17487/RFC7540 . RFC 7540 .
  • Registro de tokens de actualización del protocolo de transferencia de hipertexto (HTTP) en IANA