Re: JSON headers

[Amos Jeffries <[e-mail]>]

On 12/07/2016 6:51 p.m., Julian Reschke wrote:
> 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.
> 


Personally I hope we don't.

I was fine with it as a way to write ABNF-like descriptions in future
RFCs to make everyones custom headers have a more generic syntax that
our parsers could handle easier.

But using a textual representation on the wire for future improvements
is something we should be looking at avoiding, not encouraging.

HTTP/2 HPACK offers some new possibilities by adding integer encoding
for header field-value that the recipient is not required to write in
textual format before processing. Lets not throw that advantage away.

Amos