Json: workaroud for PHP fatal error

[JanTvrdik]

PHP function json_decode has a nasty bug which lead to fatal error if key starts with a NULL byte. Simple workaround for this is to pass true as the second parameter. Any tips how to solve this issue in Nette\Utils\Json?

This pull contains only failing test for now.

[stekycz]

What about escape these characters before json_decode, process and then unescape in the result? If none character is found before escaping then there does not have to be escaping and unescaping to keep current performance. Do you think it is often to happen?

[JanTvrdik]

This passes the test, but it fails on strings such as "\\u0000" 😸

[JanTvrdik]

I've improved the fix. But will this really work in all cases?

[JanTvrdik]

ping @dg

[dg]

This replaces all correct NULLs after " with invalid charater, so it leads to „Control character error, possibly incorrectly encoded“. Strange ;-)

[JanTvrdik]

Damn. In that case I have no idea how to efficiently prevent the fatal error.

[dg]

This means "invalid" key [^\]"\u0000([^\"]|\\.)*": and this json should be rejected immediately.

[JanTvrdik]

Or should I use Strings::match?

[dg]

Are two nesting levels needed?

[dg]

Strings::match is not needed, RE is corrent and when you use #[^\\\\]"\\\\u0000(?:[^"\\\\]|\\\\.)*+"\s*+: (two + added), there will be no chance for backtracking error.

[fprochazka]

👍 I don't like people sending me invalid jsons to my API to make my server throw a fatal error.

This should be merged ASAP (I seems finished to me) and backported to 2.1

[dg]

This is faster '#(?<!\\\\)"\\\\u0000(?:[^"\\\\]|\\\\.)*+"\s*+:#'

[JanTvrdik]

Nice, you can take the same trick one step further – assuming that " is a lot more common in JSON than \ we get '#(?<=[^\\\\]")\\\\u0000(?:[^"\\\\]|\\\\.)*+"\s*+:#'. Performance on real-world JSON is 820 μs for my original, 157 μs for your improvement and 20 μs for my using \ as base matching character.

[dg]

👍

[lookyman]

👍 nice job guys