Re: END_SEGMENT? (#397)

>
> 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.
>
>