- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 11 Jul 2016 05:53:06 +0000
- To: duerst@it.aoyama.ac.jp
- cc: Julian Reschke <julian.reschke@gmx.de>, Yanick Rochon <yanick.rochon@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
-------- >My understanding is that you are extremely concerned about the speed at >which headers can be processed. Speed, reliability *and* security. HTTP is so infested with weird corner-cases that 10 RFC's were needed to explain _most_ of them, whatever we do going forward, we should strive for the simplest realistic solution. Therefore I want to eliminate as many cornercases as possible before they ever appear in the wild. >Could you give some more background on why speed-wise, de/serializing is >okay for you, but duplicate detection isn't? De-serialization of JSON objects already perform duplicate detection, why should we have to do it again in the application code ? What happens when people who don't know about this fine detail fails to deduplication in their application code ? >> 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? I don't need to. As long as a relevant fraction of HTTP speakers do, then attempting to send duplicate keys will be sufficiently broken that it won't work in practice. Look at it as "herd immunity". Also, my JSON parser was 500 linies of C-code in first try, it's not like it is rocket science. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 11 July 2016 05:53:34 UTC