[wsgi] Message body size validation is slow

[Kurt Griffiths]

Even trivial documents, such as {}, still takes 10 us or so.

I don't think we've seen this in our benchmarks because it has been short-circuited when message_size_uplimit == content_max_length

[Zhihao Yuan (zyuan)]

Proposed change:

Redefine "document size" in terms of values/objects inside a document, neither JSON bytes nor JSON chars.

For example, each empty object/array/null has size 8, true/false have size 1, any number has size 8, string size == len(s). Walk trough the whole document and sum them up.

I guess 64K for each message, 256K in total should be enough.

This can also solve the msgpack problem, which has no concept of "chars". Same Python dictionary, no matter
how it's being represented, msgpack or JSON, has same size.

[Zhihao Yuan (zyuan)]

2 examples about why "count by values" is important:

Imagine a client receives a matrix, and divides it by 3.0, BOOM, the result matrix is rejected, because 1 becomes 0.3333333333333333. A behavior like that is completely not predicatable. However, 0.3333333333333333 is not a problem to
1. transport, because as you said, server limits is larger than the content_length we currently have;
2. storage, neither MongoDB nor SQL, which should use msgpack;
3. Other media type in the future, like msgpack.

Why a client sending "\uXXXX" strings has a much higher chance to exceed the limits? Don't forget that Python's json module and simplejson both uses ASCII form by default; not every software expect UTF-8.

[Kurt Griffiths (kgriffs)]

This bug is no longer valid, since we are redefining what "max message size means" to just be "max size of post message request, including whitespace".