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

Re: END_SEGMENT? (#397)

From: Yutaka Hirano <yhirano@google.com>
Date: Tue, 1 Jul 2014 22:42:52 +0900
Message-ID: <CABihn6FQKQJmp0oeREU97zNQYUCDcK+obOwkUx1Ki6rhK87SkQ@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
>
> b) A new protocol needs a new application negotiation token.

Does this option mean that all intermediaries should express its support
for the application?

Thanks,


On Tue, Jul 1, 2014 at 3:45 AM, David Krauss <potswa@gmail.com> wrote:

>
> 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 Tuesday, 1 July 2014 13:43:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC