W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: END_SEGMENT? (#397)

From: Yutaka Hirano <yhirano@google.com>
Date: Thu, 19 Jun 2014 16:51:41 +0900
Message-ID: <CABihn6Ho9H-h7uzPRzuds8Ty3nWcmnrDoJYc9m9XDcLt471r9w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Daniel Sommermann <dcsommer@fb.com>, Jeff Pinner <jpinner@twitter.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, HTTP Working Group <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
>
> 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.
>
Received on Thursday, 19 June 2014 07:52:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC