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