every h2 extension bilaterally negotiated via settings is a revision to h2. hpack can do that right? On Mon, Jul 18, 2016 at 4:51 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2016-07-18 16:38, Poul-Henning Kamp wrote: > >> -------- >> In message <01f2be81-5fd2-1af5-97f6-75c51ae9cc2c@gmx.de>, Julian Reschke >> writes >> : >> >>> On 2016-07-18 15:00, Poul-Henning Kamp wrote: >>> >>>> ... >>>> >>>>> That's a fine thing to do, but how would it help for HTTP/2? >>>>> >>>> >>>> We left a lot of low hanging fruit on the tree with HPACK, notably >>>> the Date header. >>>> >>>> If we decide to do structured headers, they might be another good >>>> reason for HPACK2, which could then know about these fields and >>>> do the smart thing. >>>> ... >>>> >>> >>> Agreed, but changing HPACK implies revising HTTP/2, thus HTTP/3, right?? >>> >> >> Maybe, but for HTTP/3 we should have even higher ambitions, so maybe >> a better HPACK for H2 is a good partial goal. >> > > AFAIU, there can not be such as thing as a "better HPACK" for HTTP/2, > because we can't revise HPACK without also revising HTTP/2. > > Best regards, Julian > > >
Received on Monday, 18 July 2016 15:28:57 UTC