RE: Precision of numbers using JSON Header Field Values

Yes, but you can’t get it in the first RTT unless it’s implied by the ALPN token.  Depending on the scope of the changes, you could enable it with SETTINGS, though, yes.  (Additional operations allowed => good; changes to existing values in header table => bad)

From: Patrick McManus [mailto:mcmanus@ducksong.com]
Sent: Monday, July 18, 2016 5:28 PM
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>; Willy Tarreau <w@1wt.eu>; Kazuho Oku <kazuhooku@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Precision of numbers using JSON Header Field Values

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<mailto:julian.reschke@gmx.de>> wrote:
On 2016-07-18 16:38, Poul-Henning Kamp wrote:
--------
In message <01f2be81-5fd2-1af5-97f6-75c51ae9cc2c@gmx.de<mailto: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