2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
set: 1
|
|
|
|
|
code: 101
|
|
|
|
|
title: Switching Protocols
|
2015-11-07 01:41:41 +01:00
|
|
|
references:
|
|
|
|
|
"Rails HTTP Status Symbol": ":switching_protocols"
|
2016-01-27 23:08:33 +01:00
|
|
|
"Go HTTP Status Constant": "http.StatusSwitchingProtocols"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-08 23:48:01 +01:00
|
|
|
The server understands and is willing to comply with the client's request, via
|
|
|
|
|
the Upgrade header field<sup>[1](#ref-1)</sup>, for a change in the application
|
|
|
|
|
protocol being used on this connection.
|
2015-11-07 06:24:24 +01:00
|
|
|
|
2015-11-08 23:48:01 +01:00
|
|
|
The server MUST generate an Upgrade header field in the response that indicates
|
|
|
|
|
which protocol(s) will be switched to immediately after the empty line that
|
|
|
|
|
terminates the 101 response.
|
2015-11-07 01:28:15 +01:00
|
|
|
|
|
|
|
|
It is assumed that the server will only agree to switch protocols when it is
|
|
|
|
|
advantageous to do so. For example, switching to a newer version of HTTP might
|
|
|
|
|
be advantageous over older versions, and switching to a real-time, synchronous
|
|
|
|
|
protocol might be advantageous when delivering resources that use such features.
|
|
|
|
|
|
2015-11-08 23:48:01 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-09 19:23:21 +01:00
|
|
|
* <span id="ref-1"><sup>1</sup> Upgrade [RFC7230 Section 6.7][2]</span>
|
2015-11-08 23:48:01 +01:00
|
|
|
* Source: [RFC7231 Section 6.2.2][1]
|
2015-11-07 01:28:15 +01:00
|
|
|
|
2015-11-07 03:59:14 +01:00
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
|
2016-01-27 23:08:33 +01:00
|
|
|
[2]: <http://tools.ietf.org/html/rfc7230#section-6.7>
|
