Ticket #90 (defect)

Could someone explain this one?

This is to protect us against attacks ... Someone could send a huge request header or body and block a thread for a long time ... So if the request header or body is over a certain limit we should just stop reading the request and abort. These parameters should be configurable.

True.

And in this case, we should send HTTP code 413 : http://rfc.net/rfc2616.html#s10.4.14

See also :

http://rfc.net/rfc2616.html#s10.4.14

oops i meant:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20

To be useful we need to test the length of the header entity and the body entity early in the process.

It either means we need to let the server handlers (WSGI, built-in HTTP, or else) do the job, or we need to do that in processRequestHeaders() and processRequestBody().

The former one seems to get the headers through self.requestHeaders which is a generator, thus we can't compute its length. We can wait for the request.headerMap to be filled up. But then it seems to be lae in the process IMO.

The latter is either to be done once FieldStorage? has been called or before, but again it sounds late to be really useful.

So, I feel like we should leave that to the server handlers instead as a good practice.

server.maxRequestSize can now be used to set the maximum size a post body.

Changeset [585] partially addresses this.

Do we really need per-path config on this, though? It seems to me that server.maxRequestSize could be inspected once (on server.start()) to set cgi.maxlen. I certainly don't think we need a threadlocal object involved; in fact, I have my doubts it's working as expected. It would be good to see a decisive test in test_core.

>>> cgi.maxlen
<cherrypy._cpcgifs.LocalInt instance at 0x01062710>
>>> cgi.maxlen == 5
False

I'm perfectly happy making this a global setting.

Implementation done in [626]. Still need to write docs for new config options

Done in changeset [626] (code) and [628] (docs)