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

On 11/21/2017 12:21 PM, Adam Rice wrote:
> On 21 November 2017 at 04:20, Patrick McManus <mcmanus@ducksong.com 
> <mailto:mcmanus@ducksong.com>> wrote:
> 
>     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.
> 
> 
> I'm concerned about this "wait an arbitrary amount of time before 
> falling back" semantic. When we first implement it I expect to be 
> falling back almost all of the time. In fact, most developers would 
> probably have a better experience if we never attempted h2 at all. We 
> could race an h2 connection with an h1 connection but that seems suboptimal.

It's a very common pattern a script is served in HTML from a server, 
only after getting the script does the client try to make the ws 
connection back.

If the ws connection is back to the same server that gave it the script, 
the client knows the connection SETTINGS situation already, as it says 
in RFC7540 6.5

"SETTINGS frames always apply to a connection, never a single stream."

So you can use the existing connection's SETTINGS to know if it's worth 
trying the h2 path for ws, when it's targeting the same server.

If it's targeting a different server you're a bit stuck as you say... it 
will be fairly expensive to set up SSL and try h2 on that, fail to get 
the SETTINGS you want, then retry setting up SSL for h1.

-Andy

Received on Tuesday, 21 November 2017 05:08:37 UTC