Re: END_SEGMENT? (#397)

>
> I'm less concerned about this particular problem, especially now that
> we've effectively opened the door to extension.  Websockets is always
> going to be dependent - at least a little - on the next hop
> understanding something of the request.  We've talked in the past
> about a new ALPN token for that, but it might be as simple now as
> SETTINGS_ENABLE_WEBSOCKETS.

I don't want to require all intermediaries to understand WS over HTTP/2.
With END_SEGMENT, intermediaries only have to transfer the data without
understanding WS over HTTP/2.

If we don't have END_SEGMENT, we have to specify WS_END_SEGMENT in WS_DATA
frame type
which are specific to WS over HTTP/2 and all intermediaries have to
understand WS over HTTP/2.

I have one question:
Suppose we have WS_END_SEGMENT and WS_DATA.
Suppose there is an intermediary that doesn't support WS over HTTP/2.
The intermediary ignores the SETTINGS values specific to WS over HTTP/2, so
the handshake succeeds.
The intermediary discards the frames specific to WS over HTTP/2, so two
endpoints can't communicate
whereas the handshake succeeds.
Is that right?



On Thu, Jun 19, 2014 at 11:21 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 18 June 2014 17:46, Yutaka Hirano <yhirano@google.com> wrote:
> > I'm interested in WebSocket over HTTP/2 and it uses END_SEGMENT.
> > The problem of specifying END_SEGMENT in WebSocket over HTTP/2 not in
> HTTP/2
> > is, WebSocket over HTTP/2 can't be used with intermediaries that merely
> > understand HTTP/2.
>
> I'm less concerned about this particular problem, especially now that
> we've effectively opened the door to extension.  Websockets is always
> going to be dependent - at least a little - on the next hop
> understanding something of the request.  We've talked in the past
> about a new ALPN token for that, but it might be as simple now as
> SETTINGS_ENABLE_WEBSOCKETS.
>
> It would be relatively easy to port the necessary flags to a
> websockets draft if we decided to remove them from HTTP/2.
>
> I do think that we should be looking more seriously at your draft.  In
> light of recent changes, but more because we agreed to do this, and I
> think that you have the most fully developed proposal that we've
> deferred due to increased attention on getting HTTP/2 done.
>