Mojo::JSON should allow disabling / escaping

[yoe]

• Mojolicious version: 8.12
• Perl version: 5.28
• Operating system: Debian 10 "buster"

The Mojo::JSON POD documentation contains:

   The character "/" will always be escaped to prevent XSS attacks.

     "</script>" -> "<\/script>"

While I can (kind of) understand the reasoning for this, it makes interoperability an issue: I want to provide a REST API for some stuff that includes file names (i.e., with embedded forward slashes) to some people who prefer to use python, and they now have to run the equivalent of s/\\// over my JSON files before they're able to use it. That's... rather annoying.

Please make this an optional thing, so I can switch it off if I need to.

[kraih]

A JSON parser would have to be broken to not understand the escaped solidus. https://tools.ietf.org/html/rfc8259#section-7

[kraih]

Here's also an annotated picture from http://json.org in case you have to report this as a bug in their JSON parser.

[Grinnz]

For the record, escaped slashes appear to work fine on the python.org shell:

Python 3.8.0 (default, Nov 14 2019, 22:29:45) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.loads('"\\"foo/bar"')
'"foo/bar'
>>> json.loads('"\\"foo\\/bar"')
'"foo/bar'

[yoe]

Okay, so I must've missed something then.

Still, it would be nice if it were possible to disable this escaping. It can sometimes make sense to have it, but force-enabling it seems wrong.

[karenetheridge]

Not doing it would be violating the JSON specification, and also how would a JSON decoder know if escaping had been done, so it can be sure to match the escaping-or-not behaviour on the other side?

Is the recipient of your JSON parsing the files with something like substr() rather than a JSON decoder? I don't see how else this would be a problem.

[jberger]

Is the recipient of your JSON parsing the files with something like substr() rather than a JSON decoder? I don't see how else this would be a problem.

Sadly, I absolutely have seen this in the wild. Some BMCs seem to, for example. That said, it doesn't make it Mojo's fault.

[yoe]

Is the recipient of your JSON parsing the files with something like substr() rather than a JSON decoder? I don't see how else this would be a problem.

Sadly, I absolutely have seen this in the wild. Some BMCs seem to, for example. That said, it doesn't make it Mojo's fault.

I have seen this in the wild too.

I'm not saying that it's Mojo's fault that there are broken implementations out there. However, not being able to change defaults, even if they make sense, is a choice that Mojo made; and if that means there is less interoperability with other implementations out there, then that is Mojo's fault.

[kraih]

Then this is a fringe use case though, which means that using Cpanel::JSON::XS instead of Mojo::JSON should be good enough.

[yoe]

I wasn't aware I could tell Mojolicious to use a different JSON implementation for the json=> rendering. What did I miss?

[karenetheridge]

You can use your own renderer to emit whatever content you like, but it won't be JSON, so you won't be able to convince Mojo::JSON to do it through the automatic $c->res->json handler :)

Did you find out why the client side is not parsing your content properly? Python itself doesn't seem to have a broken decoder. Is something else altering your content before it gets json-decoded?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It may be closed if no further activity occurs. Thank you for your contributions.

[kraih]

I'm afraid it looks like there is not much interest in this feature. Thanks for sending a feature request.