- From: David Krauss <potswa@gmail.com>
- Date: Tue, 1 Jul 2014 02:45:39 +0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>, Yutaka Hirano <yhirano@google.com>
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