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

Re: END_SEGMENT? (#397)

From: Daniel Sommermann <dcsommer@fb.com>
Date: Thu, 19 Jun 2014 09:17:31 -0700
Message-ID: <53A30D1B.1060205@fb.com>
To: Yutaka Hirano <yhirano@google.com>, Martin Thomson <martin.thomson@gmail.com>
CC: 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>
On 06/19/2014 12:51 AM, Yutaka Hirano wrote:
> 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.

Both options require changes. Even if the intermediary doesn't 
understand WS, normal day-to-day HTTP/1.1 APIs would have to change to 
accommodate segments. In my mind, that is nearly the same as requiring 
the proxy to understand WS.

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

I think it would be worth noting in the spec how SETTING negotiation 
works. There's some text in 5.5 already, but perhaps we could be a bit 
more explicit. Here's how I think it can work:

* Extension negotiation happens only during the initial SETTINGS frame 
* A negotiated extension is active if
     1) A SETTINGS frame with the extension setting enabled has been sent
     2) A SETTINGS frame with the extension setting enabled has been 
     3) A SETTINGS frame with the ack flag has been sent

Negotiated settings should take effect for all sent frames after step 
#3. An HTTP/2 endpoint should be prepared to receive extension frames 
after step #2.

This might be more strict than necessary, but it prevents the situation 
of one side believing the extension is ON and the other thinks it is OFF.
Received on Thursday, 19 June 2014 16:18:05 UTC

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