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

Re: END_SEGMENT? (#397)

From: David Krauss <potswa@gmail.com>
Date: Tue, 1 Jul 2014 02:45:39 +0800
Cc: Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>, Yutaka Hirano <yhirano@google.com>
Message-Id: <348F5552-4B3E-4764-BC4B-F54507BC79BB@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 20140701, 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

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