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

Re: New Version Notification for draft-kerwin-http2-encoded-data-01.txt

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 23 Jul 2014 00:38:15 -0700
Message-ID: <CAP+FsNcFVu+pTRDYeD8KayiSOkpGPAUddyLK2UnegJHn8Zcubg@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
That is what the END_SEGMENT flag *was*, except without the overhead. Ah
well.

Unless the extensions are deployed along with the first versions of HTTP2,
it seems unlikely, given a requirement all intermediaries to understand a
new extension, that an extension will survive transit through any generic
intermediary. Intermediaries (that aren't controlled by the origin server
or client) almost always upgrade more slowly than everything else.



On Wed, Jul 23, 2014 at 12:30 AM, Matthew Kerwin <matthew@kerwin.net.au>
wrote:

> On 23/07/2014, Roberto Peon <grmocg@gmail.com> wrote:
> > Actually, it is an issue, so long as there is no ordering requirement on
> > extension frames (as we'd have had with END_SEGMENT).
> >
> > We've not imposed (actually removed) such restrictions on proxies, and so
> > we may find that there is no way to do it in the future. That would be a
> > sad day.
> >
>
> Not entirely sure I follow. Extension frames are support-or-discard,
> yeah? So what proxy is going to understand the frames well enough to
> fragment them, but not enough to realise reordering is bad?
>
> I do see the earlier point about fragemntation, though. Maybe it would
> be better to include a "do not coalesce across this boundary" marker
> that's more than just the frame boundary.
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>
Received on Wednesday, 23 July 2014 07:38:44 UTC

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