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"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-07 01:28:15 +01:00
|
|
|
The 101 (Switching Protocols) status code indicates that the server understands
|
|
|
|
|
and is willing to comply with the client's request, via the Upgrade header field
|
2015-11-07 01:42:48 +01:00
|
|
|
([Section 6.7 of RFC7230][1]), for a change in the application protocol being
|
2015-11-07 01:28:15 +01:00
|
|
|
used on this connection. 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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Source: [RFC7231 Section 6.2.2][2]
|
|
|
|
|
|
|
|
|
|
[1]: <http://tools.ietf.org/html/rfc7230#section-6.7>
|
|
|
|
|
[2]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>
|
