Re: JSON headers

[Julian Reschke <[e-mail]>]

On 2016-07-12 08:41, Carsten Bormann wrote:
>> It is allowed by the structure of the *wire format*.
>
> The syntax indeed cannot prevent it.
> It's still not *allowed* in JSON.
>
>> The *specification* has a "SHOULD have unique names", but then, that's
>> only a SHOULD (exactly because we know we can't rely on it, otherwise we
>> wouldn't have the prose about what recipients can do with it).
>
> It is a SHOULD because people were chickening out because of a possible
> political conflict with ECMA 404.  Note well that no reason is given to
> ever violate that SHOULD.

But we do know why it's violated in practice:

1) Streaming might make it hard to check for senders,

2) People abusing it to add comments to JSON (by choosing a member name 
for comments, and repeating it).

...and probably for other reasons I'm not aware of.

> Now, for performance reasons, there is no requirement on a receiver to
> check for this constraint.  Protocol design 101 tells us that a lack of
> checking will cause implementations to emit invalid JSON just because
> they can (the "soup" effect).  Hence the description in RFC 7159 what
> goes wrong when you do that.  (However, the security considerations fail
> to mention the check-vs-use vulnerabilities that inevitably come from
> the variety in implementation strategies; the last paragraph of Section
> 8 of RFC 7049 does apply.)

Maybe something for JSONbis?

> This discussion may be a bit off-topic for the HTTP WG, but I think it
> is important to understand JSON when using it in HTTP.

Absolutely; and the conclusion might well be that we won't use JSON on 
the wire.

Best regards, Julian