ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/JSON-XS/XS.pm
(Generate patch)

Comparing JSON-XS/XS.pm (file contents):
Revision 1.154 by root, Sun Mar 2 22:09:38 2014 UTC vs.
Revision 1.155 by root, Mon Nov 24 18:42:51 2014 UTC

… …
402character, after which more white-space and comments are allowed. 402character, after which more white-space and comments are allowed.
403 403
404 [ 404 [
405 1, # this comment not allowed in JSON 405 1, # this comment not allowed in JSON
406 # neither this one... 406 # neither this one...
407 ]
408
409=item * literal ASCII TAB characters in strings
410
411Literal ASCII TAB characters are now allowed in strings (and treated as
412C<\t>).
413
414 [
415 "Hello\tWorld",
416 "Hello<TAB>World", # literal <TAB> would not normally be allowed
407 ] 417 ]
408 418
409=back 419=back
410 420
411=item $json = $json->canonical ([$enable]) 421=item $json = $json->canonical ([$enable])
… …
1623 1633
1624Again, this has some limitations - the magic string must not be encoded 1634Again, this has some limitations - the magic string must not be encoded
1625with character escapes, and the constructor arguments must be non-empty. 1635with character escapes, and the constructor arguments must be non-empty.
1626 1636
1627 1637
1628=head1 RFC7158 1638=head1 RFC7159
1629 1639
1630Since this module was written, Google has written a new JSON RFC, RFC 1640Since this module was written, Google has written a new JSON RFC, RFC 7159
16317158. Unfortunately, this RFC breaks compatibility with both the original 1641(and RFC7158). Unfortunately, this RFC breaks compatibility with both the
1632JSON specification on www.json.org and RFC4627. 1642original JSON specification on www.json.org and RFC4627.
1633 1643
1634As far as I can see, you can get partial compatibility when parsing by 1644As far as I can see, you can get partial compatibility when parsing by
1635using C<< ->allow_nonref >>. However, consider thew security implications 1645using C<< ->allow_nonref >>. However, consider thew security implications
1636of doing so. 1646of doing so.
1637 1647
1638I haven't decided yet whether to break compatibility with RFC4627 by 1648I haven't decided yet when to break compatibility with RFC4627 by default
1639default (and potentially leave applications insecure), or change the 1649(and potentially leave applications insecure) and change the default to
1640default to follow RFC7158. 1650follow RFC7159, but application authors are well advised to call C<<
1651->allow_nonref(0) >> even if this is the current default, if they cannot
1652handle non-reference values, in preparation for the day when the4 default
1653will change.
1641 1654
1642 1655
1643=head1 THREADS 1656=head1 THREADS
1644 1657
1645This module is I<not> guaranteed to be thread safe and there are no 1658This module is I<not> guaranteed to be thread safe and there are no

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines