Re: Protocol switch before, or after the 101 response?

lör 2010-09-11 klockan 23:20 +0200 skrev Bjoern Hoehrmann:

>   In http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-11 on
> the Upgrade header, "The capabilities and nature of the application-
> layer communication after the protocol change is entirely dependent
> upon the new protocol chosen, although the first action after changing
> the protocol MUST be a response to the initial HTTP request containing
> the Upgrade header field."

A bit unfortunate wording there. But it's copied as-is from 2616
definition of Upgrade.

The change in protocol happens technically after the 101 has been
transmitted, with the 101 being an acknowledgement "yes we will upgrade
the connection". But the 101 as such may contain details relating to the
new protocol state making it sit somewhere inbetween. But the transport
is technically still HTTP/1.x as before until after the 101 response.

The wording in the definition of the 101 response (p2) is correct and
concise. Don't see any room for misunderstanding there.

> (I noticed this when wondering what happens to pipelined requests that
> succeed a request to switch protocols if the server decides to switch.)

Short answer: don't send such request sequences stupid.

Pretty much in the same category as pipelining requests after a request
with Connection: close, but with much less defined result. Those
pipelined requests will be processed by the server using either the
upgraded transport protocol or the original depending on if the upgrade
was accepted, which clearly won't work out well especially not if the
upgrade is to a incompatible transport such as TLS where those pipelied
requests will not make any sense at all.

Pipelining after an Upgrade requests generally SHOULD NOT be done,
unless the Upgrade onnly changes response transport format and request
format stays 100% compatible. One example of such exception is an
Upgrade to a transport protocol supporting interleaved responses of
pipelined requests.

Regards
Henrik

Received on Saturday, 11 September 2010 23:44:13 UTC