OK, I will investigate the LimitRequestBody problem.
Graham Dumpleton wrote:
What probably needs to be investigated is whether the default can't
just be REQUEST_CHUNKED_DECHUNK all the time and code behave just as
it did before. If this can be done, then all that needs to be solved
is your ability to do non blocking reads.
I suppose the only problem with making it the default is exposing
security holes in people's apps that were previously protected against
by CHUNKED_ERROR, since it's unlikely anyone will rely on getting a
chunked failure in normal operation. The only thing I can think of is
something depending on the content length (request.clength), but I would
guess it's already possible for attackers to pass in requests without
content lengths by using "Connection: close" or HTTP/1.0. Don't have any
ideas of what else to investigate.
For non blocking reads, I rather don't like the idea of a special read
function. What I have instead thought about for this in the past for
mod_wsgi, even though support for chunked and non blocking is outside
of WGSI specification, is to have a setblocking() function just like
sockets do. Technically one may even be able to implement the more
general settimeout() since timeouts can be specified for Apache
connections if you do it right.
I thought someone already submitted a patch because read(len) used to
return < len bytes in the past, and it was considered to be breaking the
file-like object API.
And if you restrict it to returning either len bytes or a "would block"
exception, it would not solve the original problem I was intending to
solve - having to process and respond to < len bytes from the client
before the client will send any more.
Perhaps setblocking()/settimeout() is orthogonal to partial read
support. In some cases you might like to read() in non-blocking mode to
retrieve blocks of known size (or get an exception), and in some cases
you might like to read_partial() in non-blocking mode too.
I think partial read support is useful even if you don't have full
non-blocking support, and non-blocking could be significantly more work
to add.
The only thing is what exception you use to indicate socket would
block and/or timeout. Do you reuse socket exception and use it in same
way as sockets do for indicating this, or use a new exception.
I would suggest a new exception, as it looks like mod_python code is
currently completely isolated from any use of sockets or the Python
socket module by Apache.
Alex
