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

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 11 Sep 2010 23:20:43 +0200

Hi,

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

In http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11 in
definition of the 101 status code this seems to be contradicted, "The
server will switch protocols to those defined by the response's Upgrade
header field immediately after the empty line which terminates the 101
response."

One says you switch and then send the 101, the other says you send the
101 and then switch. (There is also a singular/plural mismatch, but
that is probably no problem here).

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

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · 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/

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 12 Sep 2010 01:43:42 +0200

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

> 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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2010 08:30:31 +0200

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

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

>Upgrade to a transport protocol supporting interleaved responses of

(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:[email-masked] · 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/

---

From: Henrik Nordström <[email-masked]>
Date: Wed, 15 Sep 2010 09:54:29 +0200

> specification though, but I did not try hard either.)

The only requirement is rightfully on clients (including proxy clients)
to not pipeline non-idempotent sequences, not on servers on handling
them.

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2).

But I agree that this may need to be clarified to highlight the nature
of Upgrade. And not sure idempotent is the right property to classify
Upgrade by either.

Regards
Henrik