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

LimitRequestBody directive doesn't work well with mod_python handlers.

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2.10, 3.3.1
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      The problem is that mod_python doesn't check whether LimitRequestBody would be triggered before actually calling the mod_python handler. Thus, that the post data exceeds the limit is only found when req.read() of mod_python request object is called and a Python exception is generated because of an unknown read error.

      Now, because a read error of some sort is generated, mod_python handlers would normally see it as an unexpected exception and it would propagate back and result in a 500 Internal Server Error page rather than a 413 error back to the client. Thus a ErrorDocument handler for 413 errors would never be triggered.

      FWIW, in mod_wsgi the following is done before the WSGI application is even triggered.

      /*

      • Setup policy to apply if request contains a body. Note
      • that it is not possible to have chunked transfer encoding
      • for the request content. This is actually a limitation in
      • WSGI specification as it has no way of indicating that
      • there is content of unknown length, nor a way to deal
      • with trailers appearing after any chunked content.
        */

      status = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR);

      if (status != OK)
      return status;

      /*

      • Check to see if request content is too large and end
      • request here. We do this as otherwise it will not be done
      • until first time input data is read in application.
      • Problem is that underlying HTTP output filter will
      • also generate a 413 response and the error raised from
      • the application will be appended to that. The call to
      • ap_discard_request_body() is hopefully enough to trigger
      • sending of the 413 response by the HTTP filter.
        */

      limit = ap_get_limit_req_body(r);

      if (limit && limit < r->remaining)

      { ap_discard_request_body(r); return OK; }

      Do note though that the size check can only be done after ap_setup_client_block() is called. At the moment this is done first time req.read() is called. If that is to remain there, then req.read() would need to do the equivalent of:

      raise apache.SERVER_RETURN, apache.HTTP_REQUEST_ENTITY_TOO_LARGE

      Problem is that by doing this in req.read() an application may still catch it and treat it like an unexpected exception and raise a 500 error response instead.

      It is for this reason that mod_wsgi does the check even before the application is called. If a custom error page is required then ErrorDocument directive would be used to redirect to a handler.

      If an application itself wants to check POST content size, it simply shouldn't be using LimitRequestBody directive.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated: