Re: END_SEGMENT? (#397)

Combining replies to Martin and Daniel.

On 2014–07–01, at 1:20 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 30 June 2014 10:06, David Krauss <potswa@gmail.com> wrote:
>> Special-purpose proxies can ignore any part of the protocol that their designer knows will not occur in the local environment. It’s not a normative issue.
> 
> That's an argument for the new application negotiation token.

Such a proxy should only be put in a place where no negotiation is necessary. Bailing out at any END_SEGMENT would be acceptable then.

>> Fully conforming proxies should support interactive applications.
> 
> That's an argument against the new application negotiation token.

Yes.


On 2014–07–01, at 1:19 AM, Daniel Sommermann <dcsommer@fb.com> wrote:

> David, we had a discussion on this thread about two weeks ago about the layering violations and constraints on intermediaries that are introduced by END_SEGMENT and whether END_SEGMENT is needed for the core spec.

Ah, now I see. Your complaint regarding APIs is similar to mine, raised earlier in other threads (April 16 and 19). Indeed, this is not something applications should be encouraged to fool with.

However, do note that as uncovered by the April 19 thread, END_SEGMENT is only duplicating the intended semantics of mid-stream header blocks, which also act as a fence against DATA coalescing. Reasonable handling of headers likewise would seem to suggest flushing, since they tend to indicate a new request. In effect, END_SEGMENT is only a compressed representation of an empty (non-delta encoded) header block.

> Also, I brought up the fact that END_SEGMENT's requirements on intermediary behavior is not compatible with HTTP/1.1 interfaces. There is no concept of segments in HTTP/1.1, so there is no way to transfer those semantics through an HTTP/1.1 interface.

An HTTP/1.1 intermediary interceding on an HTTP/2 Websockets stream should cause the same degradation as on an HTTP/1.1 Websockets stream. Does translating 2<=>1.1 require knowledge of the original WebSockets protocol? Yes. But that’s unavoidable, and in the long run HTTP/1.1 proxies will go away. That process will start sooner if HTTP/2 normalizes the behavior as opposed to waiting for HTTP/3.

It would perhaps be nice to have an end-to-end SETTINGS indicator that every hop is HTTP/2. Then endpoints could generally moderate their expectations, regarding PRIORITY, etc.

> I've updated the linked issue in the subject line.


Thanks.

Received on Monday, 30 June 2014 18:23:53 UTC