You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2005/11/18 06:04:41 UTC

[jira] Created: (MODPYTHON-92) Raise more specific IOError when req.write() fails.

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