Re: JSON headers

[Andy Green <[e-mail]>]

On Mon, 2016-07-11 at 08:12 +0200, Julian Reschke wrote:
> On 2016-07-11 06:37, Andy Green wrote:
> > On Mon, 2016-07-11 at 13:05 +0900, Martin J. Dürst wrote:
> > > Hello Paul-Henning,
> > > 
> > > On 2016/07/11 07:20, Poul-Henning Kamp wrote:
> > > 
> > > > If we instead, as I propose, require that JSON headers *never*
> > > > be
> > > > split, then it becomes both possible and rather obviously
> > > > smarter
> > > > to define this header as a JSON object, keyed by the media
> > > > type:
> > > > 
> > > > 	Accept: { 					\
> > > > 		"text/plain": <JSON for "q=0.5">,	\
> > > > 		"text/html": <JSON for no parameter>,	\
> > > > 		"text-xdvi": <JSON for "q=0.8">,	\
> > > > 		"text/x-c": <JSON for no parameter>	\
> > > > 	}
> > > > 
> > > > A sender wishing to modify the priority, just sets the
> > > > corresponding JSON object using the native languages
> > > > JSON facility:
> > > > 
> > > > 	req.accept["text/plain"] = <JSON for "q=0">
> > > 
> > > My understanding is that you are extremely concerned about the
> > > speed
> > > at
> > > which headers can be processed. My guess would be that
> > > deserializing,
> > > changing, and reserialising JSON headers takes more time than
> > > detecting/processing duplicate headers. But I of course might be
> > > wrong.
> > 
> > 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?

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.

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.

-Andy

> Best regards, Julian