- From: Carsten Bormann <cabo@tzi.org>
- Date: Tue, 12 Jul 2016 08:41:52 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Willy Tarreau <w@1wt.eu>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Yanick Rochon <yanick.rochon@gmail.com>, Phil Hunt <phil.hunt@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
> 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. 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.) 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. Grüße, Carsten
Received on Tuesday, 12 July 2016 06:42:21 UTC