Re: END_SEGMENT? (#397)

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

> On 30 June 2014 11:23, David Krauss <potswa@gmail.com> wrote:
>>> 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.
> 
> There's an obvious counterargument to that one...
> 
> That's fine, but if you want to operate sans-standard, then you can
> add your own END_SEGMENT.

Should be explicitly prohibited.

> I really don't care either way here.  I'm just enumerating the
> options, and noting that what is currently specified isn't
> particularly well-supported.  Our responsibility is to either more
> clearly define it, or remove it.

This I agree with. Actually the same goes for mid-stream headers.

I gave up on the earlier thread, but I still think that END_SEGMENT should be explicitly defined as a compressed representation of an empty header set, to be processed after the current frame.

This puts HTTP/1.1 intermediary support exactly on par. No worries about semantics, no hook for application designers to work their twisted magic.

Received on Monday, 30 June 2014 18:46:14 UTC