Uploaded image for project: 'mod_python'
  1. mod_python
  2. MODPYTHON-92

Raise more specific IOError when req.write() fails.

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.3.x
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      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":

      1. if this is an IOError while writing to client,
      2. it is probably better not to try to write to the cleint
      3. 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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              grahamd Graham Phillip Dumpleton
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: