Re: structured headers "why not JSON" FAQ

On 2018-06-13 10:37, Mark Nottingham wrote:
> After some thought and offline discussion, I've taken another stab at explaining the underlying reason here -- that using JSON means that people will tend to point JSON implementations at it and violate the constraints that make it "fit" into HTTP headers.
> 
> Review appreciated.
> ...

Here we go:

> A.1. Why Not JSON?
> 
> Earlier proposals for structured headers were based upon JSON [RFC8259]. However, constraining its use to make it suitable for HTTP header fields requires senders and recipients to implement specific additional handling.

The constraints are on the senders. *If* they follow them, recipients 
using off-the-shelf JSON parsers will be fine. (And yes, the *if* is the 
potential issue).

> Because of JSON’s broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments would fail to enforce them, thereby harming interoperability.

...but interop would only be harmed for non-conformant field values.

> For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., [RFC7493]), it cannot be relied upon.

(see above)

> Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce.

Not sure what interop problems you are referring to. SH currently only 
has ASCII, forcing non-ASCII content (when needed) into binary values. 
That doesn't seem to be an advantage for those who actually need non-ASCII.

> Another example is JSON’s ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it’s necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it’s likely that some header field definition will find a need to violate it.

a) A limit could be enforced *before* feeding the field values into the 
JSON parser.

b) "and even if a limit is specified, it’s likely that some header field 
definition will find a need to violate it" - how is that different in SH?

> Since a major goal for Structured Headers is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serialiser.
> 
> Finally, there were widely shared feelings that JSON doesn’t “look right” in HTTP headers.

Best regards, Julian

Received on Wednesday, 13 June 2018 09:01:44 UTC