On 12/11/2015 02:36 AM, Bert Huijben wrote:
-----Original Message-----
From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
Protocol implementations should make up their minds in the "propose"
phase, I think,
because once a protocol gets selected, the upgrade *should* succeed unless
the
connection catches fire or something. Not upgrading is better than
failing.
+1
Not upgrading is 100% better than failing.
...except for those protocols for which failure instead of upgrade is
*required* by their spec (e.g. WebSocket). Protocol switch
implementations need to have the opportunity to fail after they have
been selected for that reason, but of course the TLS and HTTP/2
implementations should/would not make use of that.
One other thing that sticks in my mind:
Is it possible to upgrade to TLS in one request and to h2c later?
I believe so; is there anything in the specs that would make you think
otherwise? An Upgrade: TLS by itself still results in an HTTP/1.1
connection, which can respond to further upgrades, right?
I'll go further though: is it possible to upgrade to TLS and then to h2c
in the *same* request?:
Upgrade: TLS/1.2, h2c
TLS and then websockets...
I don't think that scenario should be supported either. Webbrowsers aren't
going to use it... and dedicated clients probably use a direct connection of
some sort instead of websockets.
IMHO, dedicated clients who are serious about WebSocket security will
have connected via a wss:// connection instead of upgrading from an
initially unsecure connection. (I'm not saying it's impossible to design
a secure system that uses an upgrade, but the percentage of users who
can get it 100% right is likely to be low.)
--Jacob
