Re: JSON headers

[Julian Reschke <[e-mail]>]

On 2016-07-11 08:37, Andy Green wrote:
> ...
>>> I'm a bit bemused why the world needs JSON headers instead of the
>>> cool
>>> stuff for header coding in http/2, but I can give one point of view
>>> related to duplicate headers and efficiency.
>>> ...
>>
>> I don't understand the "instead" here. The data model for header
>> fields
>> exactly the same in HTTP/1.1 and HTTP/2, so the proposed format
>> applies
>> to both.
>
> I mean now it exists and is formalized, and implementations exist,
> shouldn't people be being encouraged to directly use HPACK?

Doesn't parse.

If you use HTTP/2, you always use HPACK. If you use HTTP/1.1, you never 
use HPACK. There is nothing to choose here.

> Agreed, JSON would in retrospect be cooler than HTTP/1.x headers.  But
> I'm surprised there is any energy to go and make more ways to send HTTP
> headers.

Actually, it's an attempt to have *less* ways, in that it gives people 
defining new header fields a framework to use, instead of having to 
invent new micro-syntax every time.

> Mightn't it be better to look at tweaking HPACK to have a "strict flag"
> or somesuch to give some of the qualities discussed here, like only one
> instance of each header?  Otherwise HPACK is pretty nice.
>
> Apologies if I miss the point but JSON headers won't directly fly on
> HPACK AFAICS, unless your idea is making an uber-header and its value
> is the whole JSON payload.  But that's needlessly incompatible when
> it's dealing with the same traditional headers and values HPACK already
> supports actually.

They "fly" exactly the same way as in HTTP/1.1; could you elaborate on 
where you see a difference?

Best regards, Julian