Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

2016-10-20 10:31 GMT+09:00 Tom Bergan <tombergan@chromium.org>:
> On Wed, Oct 19, 2016 at 5:48 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> Hi,
>>
>> 2016-10-20 1:50 GMT+09:00 Ilari Liusvaara <ilariliusvaara@welho.com>:
>> > On Wed, Oct 19, 2016 at 10:03:18AM -0400, Van Catha wrote:
>> >> I am particularly interest in the future of 2 way binary streaming.  So
>> >> the
>> >> topics of WebSocket, Streams API and other related. I have even put
>> >> forward
>> >> a draft related to the WebSocket part.
>> >> https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/
>> >
>> > Some quick review comments:
>> >
>> > - The handshake seems to negotiate compression and then the frames
>> >   contain compression method indicator. Are there really multiple
>> >   compression methods available on per-frame basis, or should the
>> >   compression just be 1 bit (compressed or not)?
>> > - The abbrevations in frame diagram are bit difficult to understand
>> >   (have those be expanded in above text?).
>> > - Somebody needs to try what this does against many HTTP/2 origins
>> >   that don't support WebSockets2 and against intermediaries with
>> >   custom server that actually supports it. Just to see what the
>> >   heck happens (if it is nasty, one might need to use SETTINGS to
>> >   signal support, either for WebSockets directly or for some sort
>> >   of strict scheme).
>>
>> That's a good point.
>>
>> In case of H2O, all schemes are handling equally at the protocol
>> layer. In other words, whatever the :scheme is, the server is designed
>> to wait for a request, and then send response.
>>
>> My understanding is that the HTTP/2 specification is written in mind
>> to allow such implementations, and that it would be a violation of
>> HTTP/2 to introduce different interactions by using :scheme as an
>> indicator. For example, transition of the stream states described in
>> section 5.1 is not restricted to specific schemes.
>>
>> So if we are to start using the HTTP/2 framing layer to transmit
>> websocket or other bi-directional communication, I think we should
>> require negotiation using SETTINGS frame. Also, it might be beneficial
>> to use a frame type other than DATA to convey bi-directional
>> information to avoid potential issues (since the transition of the
>> stream states are mostly related to how DATA frames are handled).
>
>
> Ignoring the practical issues for a moment (which are obviously important),
> which part of the H2 spec forbids bidirectional communication as desired by
> WebSockets2? The stream state diagram in section 5.1 says that a stream
> transitions from "idle" to "open" when the client/server sends/receives a
> HEADERS frame (with CONTINUATIONs). A stream doesn't transition to a
> "closed" state until a peer sends an ENDS_STREAM flag. Section 5.1 says: "A
> stream in the 'open' state may be used by both peers to send frames of any
> type." This seems to explicitly allow bidirectional communication with DATA
> frames as desired by WebSockets2. Further, WebSockets2's bidirectional
> communication looks very similar to bidirectional streaming in gRPC:
> http://www.grpc.io/docs/guides/concepts.html#bidirectional-streaming-rpc
> http://www.grpc.io/docs/guides/wire.html

Thank you for your comment.

I agree that a stream remains in open state until a frame with an
END_STREAM flag is sent by either of the two communication bodies. So
HTTP/2 as a spec. does not forbid using DATA frames for bidirectional
communication.

> In practice, I could see that some servers will try to consume the entire
> request before returning any kind of response, and this definitely might
> interact poorly with WebSockets2.

Yes.

This could be the case for any HTTP/2 gateway that translates incoming
requests to HTTP/1, that does not reject unknown schemes. And whether
such gateway needs to reject schemes that do not match to the
request-response model of HTTP seems to be vague in reading RFC 7540.
Section 8.1.2.3 states that:

      ":scheme" is not restricted to "http" and "https" schemed URIs.  A
      proxy or gateway can translate requests for non-HTTP schemes,
      enabling the use of HTTP to interact with non-HTTP services.

My interpretation of this paragraph would be that it is permitted for
an HTTP/2 intermediary to transmit requests with schemes other than
"http" or "https", expecting that an upstream server would process the
request according to the scheme, considering the fact that (per my
understanding) such action is permitted in HTTP/1.1.

-- 
Kazuho Oku

Received on Thursday, 20 October 2016 03:46:37 UTC