- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 13 Jun 2018 18:37:37 +1000
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#why-not-json > On 13 Jun 2018, at 6:01 pm, Mark Nottingham <mnot@mnot.net> wrote: > > > >> On 13 Jun 2018, at 5:09 pm, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> Hmmm. It's good to have a FAQ, but it shouldn't be misleading... > > That was a first attempt in an editors' draft from memory; improvements welcome. > >> >>> A.1. Why Not JSON? >>> Earlier proposals for structured headers were based upon JSON [RFC8259], but failed to get traction for a variety of reasons, including: >>> Interoperability issues (e.g., regarding large numbers and objects with duplicate members) >> >> <https://greenbytes.de/tech/webdav/draft-reschke-http-jfv-08.html#interop> > > My recollection is that people felt that merely cautioning people not to use UTF-8 or big numbers was not sufficient to avoid interoperability problems. > > >>> Difficulties specifying field values using ABNF [RFC5234] >> >> Please elaborate. What are the difficulties, and how is this different in structured headers? > > How can you use ABNF to define the allowable structures in JFV? See the editors' draft of SH for an example there (a work in progress). > > >>> Need to encode JSON to appear in HTTP headers, thereby making it not-JSON >> >> Not true. > > I'll change this to "Need to process JSON to assure that characters are escaped in a manner that's appropriate for HTTP headers." > > >>> Reluctance to embed a JSON parser in some HTTP implementations (e.g., servers and intermediaries) >> >> Well, there was also reluctance to add yet another parser, when JSON is already available. Just saying. > > Ack. > > >>> Concerns about JSON’s ability to nest to arbitrary depths, and the resulting memory commitment that might involve >> >> If this is really a problem, a simple fix would be to restrict the size in characters, just as in structured headers. Exactly the same problem. > > Again, specifying this as JSON is going to make developers believe that it *is* JSON, and therefore just as flexible as JSON; any limitations you put into the spec are likely to be ignored by at least some implementers, since they'll be able and very inclined to just hook up their JSON parser/serialiser to their HTTP implementation. > > >>> Feelings that JSON doesn’t “look right” in HTTP headers >> >> True, it's not pretty. > > It's good to find common ground. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 13 June 2018 08:38:06 UTC