- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 11 Jul 2016 08:12:12 +0200
- To: Andy Green <andy@warmcat.com>, 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 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
Received on Monday, 11 July 2016 06:13:14 UTC