Off-by-1 error in JSON string escaping test (2.4, 2.5, ...)

[Toby Thain]

This affected a Lift 2.4 application that we are running (the 0x1f character that sneaked through killed, as expected, the client's parser) but is in HEAD.

Details: https://github.com/lift/framework/pull/1331

Ref: http://www.ietf.org/rfc/rfc4627.txt

I'm also curious as to the purpose of the 2nd and 3rd range checks. Can somebody explain why they are needed?

--Toby

[Denis Bardadym]

It seems you are right.
\u001f it is control character.
Second range check it is Latin-1 Supplement Block - and not a control
characters (http://www.charbase.com/block/latin-supplement)
Third range check it is punctuation block - and not a control
charcters (http://www.charbase.com/block/general-punctuation).

Denis.

2012/10/8 Toby Thain <to...@telegraphics.com.au>:

> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
>
>

[Joni Freeman]

Hi,

Fixed in trunk now. Thanks for reporting!

Cheers Joni

[Toby Thain]

On Monday, 8 October 2012 01:10:21 UTC-4, Denis Bardadym wrote:

It seems you are right.
\u001f it is control character.

Certainly.
 

Second range check it is Latin-1 Supplement Block - and not a control
characters (http://www.charbase.com/block/latin-supplement)
Third range check it is punctuation block - and not a control
charcters (http://www.charbase.com/block/general-punctuation).

Do you know why it is necessary to handle these ranges specially? It wasn't obvious to me (e.g. from RFC) and there's no explanatory comment in the code.

--Toby

 

[Denis Bardadym]

Nope, i have no ideas.

-- 

Denis Bardadym

Отправлено при помощи Sparrow

вторник, 9 октября 2012 г. в 3:42, Toby Thain написал:

[Joni Freeman]

Hi,

On Tuesday, October 9, 2012 2:42:57 AM UTC+3, Toby Thain wrote:

Do you know why it is necessary to handle these ranges specially? It wasn't obvious to me (e.g. from RFC) and there's no explanatory comment in the code.

I no longer recall why those two blocks are escaped. Presumably I looked how
some other JSON parsers handled quoting and got it from there. I'll remove
that behaviour since the spec does not require escaping of those ranges.

Cheers Joni