Re: JSON headers


>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