Re: JSON headers

[Andy Green <[e-mail]>]

On Mon, 2016-07-11 at 08:56 +0200, Julian Reschke wrote:
> 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.

In there thread there's talk of this becoming HTTP/1.2...

> > 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.

Maybe following this thread I get the wrong end of the stick... if it's
just the additional option of JSON-formatted values where there is
structure in the header value, that makes sense all around, and works
fine with HPACK.

In the thread it seemed people discuss actual JSON formatted headers as
a whole, ie, the whole header block becomes JSON.

I dunno there is any point to that, and it won't fly with HPACK.  But
maybe I just misread what was suggested.

> > 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?

JSON formatted values would be fine... in fact websocket extensions
option negotiation could have done with that...

-Andy

> Best regards, Julian