Re: JSON headers

[Julian Reschke <[e-mail]>]

On 2016-07-11 07:53, Poul-Henning Kamp wrote:
> --------
>
>> 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.

10?

> Therefore I want to eliminate as many cornercases as possible before
> they ever appear in the wild.

I understand that, and it's an important topic for new versions of HTTP. 
*This* spec however isn't about a new version of HTTP. It tries to 
address a concrete problem (people consistently getting definitions for 
new header fields wrong), and it's supposed to apply to all HTTP 
versions currently in us.

>> 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 ?

It doesn't do that.

> 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".

But then, recipients are already free to do that on the layer above 
(think broken Content-Length information), so if applying pressure to 
broken senders is the goal, this is not really needed.

> Also, my JSON parser was 500 linies of C-code in first try, it's not
> like it is rocket science.

Well, people having to write a custom parser is exactly what I want to 
avoid, because most get it wrong.

Best regards, Julian