Fine-Tuning when Upgrade takes effect

[mnot@…]

It's not clear exactly when Upgrade takes effect for each message, which leads to complications when interacting with features like Expect/Continue?.

Proposal from list:

​http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.2.2

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.

+ which protocol(s) will be switched to. The new protocol takes effect + on each direction after the end of the current message, which means + on the request path immediately after any advertised payload body, and + on the response path immediately after the empty line that terminates + the 101 response. + + When receiving a 101 status code, a client that was waiting for a 100 + status code before emitting its payload body must immediately send it + in order to complete the protocol switch. + + A client waiting for a 101 status code to upgrade the protocol must still + be prepared to handle other 1xx interim responses first before receiving + the 101 status code confirming the protocol upgrade.

[mnot@…]

Fixed in [2410].

[julian.reschke@…]

From [2413]:

Note change for [2410] (see #497)