Re: Precision of numbers using JSON Header Field Values

On 19/07/2016, Julian Reschke <> wrote:
> On 2016-07-18 16:38, Poul-Henning Kamp wrote:
>> --------
>> In message <>, 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.

I may be misremembering, but weren't a few "difficult" issues (like
efficient binary headers) kept out of H2 precisely because H3 could
be, relatively speaking, just around the corner? H2 has blazed a
trail; people are coming on board with the idea of new web protocols,
ALPN is a demonstrable success, the idea of 'evergreen servers' seems
to be emerging. This all says to me that the jump from H2 to H3 should
be much smoother than 1.x to 2 (and that hasn't exactly been rough.)

Also, since we dropped the Minor protocol version number, doesn't that
suggest that the step from H2 to H3 could be quite.. well.. minor? In
fact, the smaller the better -- we're still learning how to
rearchitect our sites for H2's streaming model; if we keep that model
but improve some background properties there's a gain to be had by
upgrading, with no hidden cost.

No need to reach for the stars, every improvement is an improvement
(if it's incremental *enough*.)

> Best regards, Julian

  Matthew Kerwin

Received on Monday, 18 July 2016 23:39:53 UTC