Re: END_SEGMENT? (#397)

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 
exchange
* 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 
received
     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.