I would consider the case-insensitive key handling in Go’s JSON parser and the malleability in the XML parser to both be “classic” examples of differential-prone behavior, which is the ultimate point made by the article.

(This is why the more formal definition of a parser is useful to ground on: a parser is a type of recognizer, and disagreements between recognizers that claim to recognize the same thing can be exploited. This doesn’t require a bug per se, only difference, which is why it’s a footgun.)

▲ yencabulator 13 hours ago | parent [-]

> case-insensitive key handling in Go’s JSON parser

This was an explicit decision for convenience, because the Go struct fields will be Capitalized to export them but JSON tends to follow a lower case convention.

▲ woodruffw 3 hours ago | parent [-]

Just because it’s convenient doesn’t make it a good idea! It’s also not what Go’s other parsers do per the rest of the post.

	▲	yencabulator 2 hours ago \| parent [-]
		The "other parsers" in stdlib are gob and encoding/xml. Gob is a format made for Go, so it does not have a field naming convention mismatch; what's on wire is the Go convention. encoding/xml isn't really structured as a "convert between equivalent-shaped structs and a message" utility, its struct tags are more like a query language, like a simpler cousin of XPath. Most real-world code using it does things like type Person struct { FirstName string `xml:"name>first"` LastName string `xml:"name>last"` } Where as with JSON there was a clear desire to have `{"email": "jdoe@example.com", "name": "John Doe"}` parse with as little noise as possible: `type Person struct { Email string Name string }`