HTTP/1.1 Upgrade header

<h2 id="use-with-tls">Use with TLS</h2>
<p>One use is to begin a request on the normal HTTP port but switch to <a href="/facts/Transport_Layer_Security/pGy16TnA">Transport Layer Security</a> (TLS).<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> In practice such use is rare, with <a href="/facts/HTTPS/MSWYz4zo">HTTPS</a> being a far more common way to initiate encrypted HTTP.
</p><p>The server returns a 426 <a href="/facts/List_of_HTTP_status_codes/nTtX2f6r">status code</a> to alert legacy clients that the failure was client-related (400 level codes indicate a client failure).
</p><p>This method for establishing a secure connection is advantageous because it:
</p>
<ul><li>Does not require messy and problematic <a href="/facts/URL_redirection/4o1p9l7C">URL redirection</a> on the server side;</li>
<li>Enables <a href="/facts/Virtual_hosting/ohXUdpYR">virtual hosting</a> of secured websites (although HTTPS also allows this using <a href="/facts/Server_Name_Indication/8owM2IWM">Server Name Indication</a>); and</li>
<li>Reduces the potential for user confusion by providing a single way to access a particular resource.</li></ul>
<p>If the same resources are available from the server via both encrypted secure means and unencrypted clear means, a <a href="/facts/Man-in-the-middle_attack/dx4cojdz">man-in-the-middle</a> may maintain an unencrypted and unauthenticated connection with the client while maintaining an encrypted connection with the server.
</p><p>Disadvantages of this method include:
</p>
<ul><li>The client cannot specify the requirement for a secure HTTP in the URI (though the client can require such via the upgrade negotiation); and</li>
<li>Since HTTP is defined on a <a href="/facts/Hop_(networking)/gRRnovwr">hop</a> basis, <a href="/facts/HTTP_tunnel/AH8doB4F">HTTP tunneling</a> may be required to bypass proxy servers.</li></ul>
<h2 id="use-with-websocket">Use with WebSocket</h2>
<p><a href="/facts/WebSocket/NcQrqpnv">WebSocket</a> also uses this mechanism to set up a connection with a HTTP server in a compatible way.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> The WebSocket Protocol has two parts: a <a href="/facts/Handshake_(computing)/fqKIh1VW">handshake</a> 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.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a>  Once the handshake is completed successfully, data transfer begins.
</p>
<h2 id="use-with-http2">Use with HTTP/2</h2>
<p>The HTTP Upgrade mechanism is used to establish <a href="/facts/HTTP%2f2/L7V7rfeP">HTTP/2</a> starting from plain HTTP.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> 
The client starts an HTTP/1.1 connection and sends an Upgrade: h2c header. If the server supports HTTP/2, it replies with <a href="/facts/List_of_HTTP_status_codes/nTtX2f6r">HTTP 101 Switching Protocol</a> status code. The HTTP Upgrade mechanism is used only for cleartext HTTP2 (h2c). In the case of HTTP2 over TLS (h2), the <a href="/facts/Application-Layer_Protocol_Negotiation/Hy5Y3tWu">ALPN</a> TLS protocol extension is used instead.
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Opportunistic_encryption/lnPSmsJz">Opportunistic encryption</a></li>
<li><a href="/facts/Secure_Hypertext_Transfer_Protocol/SbMgJPhu">Secure Hypertext Transfer Protocol</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li>Hypertext Transfer Protocol (HTTP) Upgrade Token Registry at <a href="/facts/Internet_Assigned_Numbers_Authority/b6MlP6zQ">IANA</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>RFC 2817 <a href="/wiki/RFC_(identifier)" target="_blank">/wiki/RFC_(identifier)</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Fette, I.; Melnikov, A. (2011). "The WebSocket Protocol". IETF. doi:10.17487/RFC6455. Retrieved 15 December 2013. {{cite journal}}: Cite journal requires |journal= (help) <a href="http://tools.ietf.org/html/rfc6455" target="_blank">http://tools.ietf.org/html/rfc6455</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Raymor, Brian. "WebSockets: Stable and Ready for Developers". Microsoft Developer Network. Archived from the original on 16 December 2013. Retrieved 15 December 2013. <a href="https://web.archive.org/web/20131216093539/http://msdn.microsoft.com/en-us/hh969243.aspx" target="_blank">https://web.archive.org/web/20131216093539/http://msdn.microsoft.com/en-us/hh969243.aspx</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>"Starting HTTP/2 for "http" URIs". Hypertext Transfer Protocol Version 2 (HTTP/2). doi:10.17487/RFC7540. RFC 7540. <a href="https://tools.ietf.org/html/rfc7540#section-3.2" target="_blank">https://tools.ietf.org/html/rfc7540#section-3.2</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
</ol>

HTTP/1.1 Upgrade header open-in-new

HTTP/1.1 Upgrade header