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

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.



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