Re: JSON headers

[Julian Reschke <[e-mail]>]

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.

Best regards, Julian