dhoworth at mrc-lmb
Aug 26, 2011, 5:57 AM
Post #2 of 2
James Spath wrote:
Re: Catalyst::Controller:REST and JSON vs JSONP issue
[In reply to]
>> FWIW, IMHO the issue is better fixed in JSON::XS et al than in
>> Catalyst::Action::Serialize::JSON. I don't see why JSON can't always
>> encode the two problematic characters.
> I suppose it could be in JSON::XS .. but JSON::XS is doing nothing
> wrong ... the two characters are perfectly valid JSON ... but they are
That's strictly true, but neither is it doing anything wrong by encoding
the two characters. From the spec <http://www.ietf.org/rfc/rfc4627.txt>:
"Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+0000 through U+FFFF), then it may be
represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point."
And it's going against the spirit of the specification, which says, in
section 6 under Security considerations:
It appears to be a simple oversight in the specification.
> Perhaps it could be an option in JSON::XS?
Well that would fit with TMTOWDTI but I'd suggest asking the world
whether anybody has a use case before adding the complication :)
List: Catalyst [at] lists
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/