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

On Wed, Nov 22, 2017 at 8:58 PM, Bence Béky <bnc@chromium.org> wrote:

>
>
> Since there is no requirement for the server to wait for settings ACK
> before accepting Websockets requests, there should be no harm in the
> client sending such a request right after sending its initial SETTINGS
> on a freshly opened h2 connection.  If the server supports Websockets,
> the request will go through.  If the server does not, then it will
> reset the frame because of the undefined pseudo-header.  The earlier
> the client sends the request, the better latency we get.  The earlier
> the client gets a failure, the better latency we get for the
> retry-over-h1 case.  Am I missing something here?
>
>
the opt-in settings is there to allow non-7540 compatible behavior.
otherwise we wouldn't need it at all.

a server that didn't opt-in to this extension must issue a protocol error
upon receipt of the unknown pseudo header. So a client better not send it :)

similarly a CONNECT with :scheme and :path elements must generate a
protocol error on a server that didn't opt-in because they are explicitly
disallowed by 7540 (in the absence of the extension).

an alternative design with a new method and the protocol field stuffed
somewhere else has end-to-end problems because there is no equivalent of
"Connection" in h2 and also practical problems with any non-CONNECT method
that has a fully bidi stream behavior (as opposed to request before
response) in that kind of scenario.

opt-in is annoying, but in this case I don't think its a big deal to move
the ball forward - especially as you say the no-connection case is not
expected to be all that common.


> Or if this behavior is not desirable, then instead just default to h1
> every time there is no open h2 connection with Websockets support to
> the server.  As Andy mentioned, most of the cases we expect a warm
> connection when a script requests a Websocket anyway.  We can gather
> some data about this and try to be clever later.
>
> Bence
>
>

Received on Wednesday, 22 November 2017 23:45:46 UTC