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

* Henrik Nordström wrote:
>A bit unfortunate wording there. But it's copied as-is from 2616
>definition of Upgrade.

(Yes, the point was to get the language improved.)

>> (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.

(It does seem sensible for the specification to say this should not be
done and to require servers to effectively not read incoming data be-
fore deciding whether to accept an upgrade requests as that would re-
sult in undefined behavior; I could not immediately find that in the
specification though, but I did not try hard either.)
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 15 September 2010 06:31:03 UTC