Open eriksjolund opened 8 years ago
Looking in https://tools.ietf.org/html/rfc7159 I was surprised to see: "A JSON parser MAY accept non-JSON forms or extensions"
Anyway, I think it it still better to fail on non-JSON input than to silently accept the input.
I'd prefer that the extended set of white space be a feature and be documented rather than breaking on Windows created/edited files. I have no love of the carriage return plus line feed standard but it annoyingly produces inputs to my programs.
An alternative is a strict mode.
-Jason 604.644.8611 On Dec 13, 2015 6:53 AM, "Erik Sjölund" notifications@github.com wrote:
Looking in https://tools.ietf.org/html/rfc7159 I was surprised to see: "A JSON parser MAY accept non-JSON forms or extensions"
Anyway, I think it it still better to fail on non-JSON input than to silently accept the input.
— Reply to this email directly or view it on GitHub https://github.com/lloyd/yajl/issues/180#issuecomment-164266433.
Carriage return (\r) and line feed (\n) are allowed white space characters according to the RFC7159. I was referring to formfeed (\f) and vertical tab (\v). I don't know how common they are and for what they are normally used.
Yes, having two parsing modes, strict mode and extension mode, is an alternative.
strict mode would be fine, but ideally not by default. since json is commonly used in network APIs, "Be conservative in what you send, be liberal in what you accept" should be the default behavior.
The JSON format specification https://tools.ietf.org/html/rfc7159 talks about these white space characters:
It seems to me that yajl also allows for \v (vertical tab) and \f (form feed).
It looks like a bug to me.