- From: Andy Green <andy@warmcat.com>
- Date: Mon, 11 Jul 2016 14:37:37 +0800
- To: Julian Reschke <julian.reschke@gmx.de>, "Martin J." Dürst <duerst@it.aoyama.ac.jp>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Yanick Rochon <yanick.rochon@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Monday, 11 July 2016 06:38:29 UTC