Raise more specific IOError when req.write() fails.
---------------------------------------------------
Key: MODPYTHON-92
URL: http://issues.apache.org/jira/browse/MODPYTHON-92
Project: mod_python
Type: Improvement
Components: core
Versions: 3.3
Reporter: Graham Dumpleton
Priority: Minor
Currently when req.write() fails in being able to be write back response
content due to the client side connection having been dropped, an IOError
exception is raised.
if (len > 0 ) {
Py_BEGIN_ALLOW_THREADS
rc = ap_rwrite(buff, len, self->request_rec);
if (flush && (rc != -1))
rc = ap_rflush(self->request_rec);
Py_END_ALLOW_THREADS
if (rc == -1) {
PyErr_SetString(PyExc_IOError, "Write failed, client closed
connection.");
return NULL;
}
}
In the top level HandlerDispatch() function, when dealing with exceptions
raised by a handler it has a special case whereby it traps instances of the
IOError exception.
if str(etype) == "exceptions.IOError" \
and str(evalue)[:5] == "Write":
# if this is an IOError while writing to client,
# it is probably better not to try to write to the cleint
# even if debug is on.
debug = 0
Specifcally, it assumes that if an IOError occurs and the first part of the
associated error value string is "Write" it assumes that the IOError is because
of req.write() failing.
In reality this need not actually be the case as feasibly something else
entirely different could raise an IOError exception whereby the first part of
the error value string contains the same thing. Thus it is not really a good
distinguisher.
If one was going to be rigorous, mod_python would define an exception class
which derives from IOError and raise as an exception an instance of the derived
class instead. By being a derived class, all user code which currently tried to
catch an IOError being raised from req.write() would still work, but the
HandlerDispatch() function could explicitly catch the derived class type and
thus be 100% certain that it was actually an error from req.write().
Note that in practice all that is affected by mod_python currently being too
broad in what it catches is that when PythonDebug is enabled, the details of
those exceptions wrongly caught wouldn't be displayed back to the browser. As
such, the impact is very minimal and fixing it should be regarded as being very
low priority.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
