Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-02.txt

On Tue, Nov 21, 2017 at 4:20 AM, Patrick McManus <mcmanus@ducksong.com>
wrote:

> Hey Bence - thanks for the review.
>
> On Mon, Nov 20, 2017 at 12:31 PM, Bence Béky <bnc@chromium.org> wrote:
>
>> Hi y'all,
>>
>> Patrick, thank you for driving this effort!  A couple of questions from
>> my team:
>>
>> 1. What happens if the client needs to send a Websocket request to a
>> server but there is currently no connection open to the the server: is it
>> okay for the client to open an HTTP/2 connection, and fallback to HTTP/1.1
>> only if the server does not support Websockets over HTTP/2?
>>
>>
> that's pretty much the client's choice; I would expect it to be dictated
> by what the client expects the outcome to be.. for example when you have 6
> pending requests for a new origin and no connections do you open 6 conns
> assuming h1 or open 1 assuming h2? a little of both? Its a local decision
> that might change as server support changes in the market. also caching.
>
>
>
>> If so, does the client need to wait for the initial SETTINGS frame to see
>> if there is an ENABLE_CONNECT_PROTOCOL = 1 parameter in it, or can it send
>> out the Websocket request right away in order to save a roundtrip (it would
>> fail anyway if the server has no support)?  Would it make sense to
>> explicitly allow an HTTP/2 server to process a Websocket request that it
>> receives before the initial SETTINGS frame is ACKed?  The client would
>> still need to wait for the server handshake before it can use the Websocket.
>>
>>
> the client needs to wait because the draft changes the definition of
> CONNECT.. you can't use the new definition against a server that hasn't
> opted into it. Note that there is no technical requirement on the server
> for a settings ack - the requirement is on when the client can send the
> request. This might be 0.5 rtt or not, depending on the style of handshake.
> It is the annoying part here driven by the simplicity of the design. I
> think that's the right choice.
>
>
Doesn't ALPN help here?


>
>
>> 2. "On requests bearing the :protocol pseudo-header, the :scheme and
>> :path pseudo-header fields SHOULD be included."
>>
>> Is there a use case for a request with :protocol but without :scheme or
>> :path headers?  In other words, why could this not be a MUST?
>>
>>
> ought to be MUST. will change. thanks.
>
>
>
>> 3. As I am reading the current specification, there is no restriction on
>> sending ENABLE_CONNECT_PROTOCOL = 1 in a SETTINGS frame other than the
>> initial SETTINGS frame.  Is there any scenario where it would make sense
>> for a server to do this?  If not, would it be overly restrictive to require
>> this setting to be sent only in the initial SETTINGS frame?
>>
>>
> we don't normally do that though obviously a good implementation would
> announce asap and I don't think has an incentive to do otherwise. I think
> its fine for a client to look at an h2 connection where it has received a
> settings without enable_connect_protocol and assume it will never be able
> to do websockets there.
>

The only case I was thinking is suppressing the ENABLE_CONNECT_PROTOCOL
until the main resource of the web app is requested. But I guess there
would be very limited cases where this really works. The client may already
have the main resource (already loaded or just fetched from some cache) and
just want to connect WS.

I don't come up with any situation where we want to route a few to H1 and
then the remaining ones to H2.

Sending ENABLE_CONNECT_PROTOCOL is not expensive. We could just do as
Patrick said.