httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Upgrade Summary
Date Fri, 11 Dec 2015 20:12:59 GMT
On Fri, Dec 11, 2015 at 1:13 PM, Jacob Champion <>

> On 12/11/2015 02:36 AM, Bert Huijben wrote:
>> -----Original Message-----
>>> From: Stefan Eissing []
>>> 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).

No, no protocol overrides the HTTP/1 RFCs *until* 101-switching protocols
has occurred at which point the new protocol definition is in force, this
behavior is all defined by RFC7230 section 6.7.

If there is an http:// representation of the websocket resource, that is
served instead of the 101-switching protocols.  If there isn't such a
representation, then the request of course does fail :)

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

Any module can cause a request to fail for any of hundreds of reasons, we
must avoid that logic in the Protocol API schema because the protocol
handler module can deal with this in any of the request hooks it likes and
is most appropriate for the failure case.

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 was under the impression that particular case was disallowed by the
HTTP/2 RFC, but I could be mistaken.

> 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

By RFC 7230, yes (and in the order you illustrated - "if multiple protocol
layers are being switched, the sender MUST list the protocols in
layer-ascending order.").

But by RFC 7540 I think the answer is a clear "no"...

   A server MUST ignore an "h2" token in an Upgrade header field.
   Presence of a token with "h2" implies HTTP/2 over TLS, which is
   instead negotiated as described in Section 3.3

3.3 <>.  Starting
HTTP/2 for "https" URIs

   A client that makes a request to an "https" URI uses TLS [TLS12
<>] with
   the application-layer protocol negotiation (ALPN) extension
   [TLS-ALPN <>].

   HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c"
   protocol identifier MUST NOT be sent by a client or selected by a
   server; the "h2c" protocol identifier describes a protocol that does
   not use TLS.

In other words, there is one and only one recognized mechanism to establish
a TLS h2 connection.  I don't think we want to honor other mechanics.

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

Your call as a websocket implementer, but I'd be inclined to ignore this
just as with TLS+h2c.

View raw message