- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Mon, 11 Jul 2016 13:05:44 +0900
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Julian Reschke <julian.reschke@gmx.de>
- CC: Yanick Rochon <yanick.rochon@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Could you give some more background on why speed-wise, de/serializing is
okay for you, but duplicate detection isn't?
> But this time we can shut them all with one single line of text:
>
> "Duplicate keys in JSON objects SHALL cause and be treated
> as connection failure."
How are you going to tell your favorite JSON library to behave that way?
Regards, Martin.
Received on Monday, 11 July 2016 04:06:24 UTC