[mod_python] Is it possible to stop file uploading?

Graham Dumpleton grahamd at dscpl.com.au
Thu Jan 25 04:37:24 EST 2007

On 25/01/2007, at 8:14 PM, export at hope.cz wrote:

> Graham and Mike
> Thank you for help and some explanation about my question.
> Mike you say:"It is good practice to send a "Connection: Close"  
> header along with your
> error response",
> But how shall I send that?Can you please send detail?
> Thank you again for help

Probably simpler to return an error status of HTTP_BAD_REQUEST. This
is one of the error status values which is guaranteed to always  
result in the
connection being closed even if keep alive was requested. There are  
which do the same, but I guess it depends on what one classifies a  
to upload an unsupported file type as.

Overall the logic for determining if keep alive is maintained is  
quite convoluted.

#define ap_status_drops_connection(x) \
                                    (((x) ==  
HTTP_BAD_REQUEST)           || \
                                     ((x) ==  
                                     ((x) ==  
                                     ((x) ==  
                                     ((x) ==  
                                     ((x) ==  
                                     ((x) ==  
                                     ((x) == HTTP_NOT_IMPLEMENTED))

     /* The following convoluted conditional determines whether or not
      * the current connection should remain persistent after this  
      * (a.k.a. HTTP Keep-Alive) and whether or not the output message
      * body should use the HTTP/1.1 chunked transfer-coding.  In  
      *   IF  we have not marked this connection as errored;
      *   and the response body has a defined length due to the  
status code
      *       being 304 or 204, the request method being HEAD, already
      *       having defined Content-Length or Transfer-Encoding:  
chunked, or
      *       the request version being HTTP/1.1 and thus capable of  
being set
      *       as chunked [we know the (r->chunked = 1) side-effect is  
      *   and the server configuration enables keep-alive;
      *   and the server configuration has a reasonable inter-request  
      *   and there is no maximum # requests or the max hasn't been  
      *   and the response status does not require a close;
      *   and the response generator has not already indicated close;
      *   and the client did not request non-persistence (Connection:  
      *   and    we haven't been configured to ignore the buggy twit
      *       or they're a buggy twit coming through a HTTP/1.1 proxy
      *   and    the client is requesting an HTTP/1.0-style keep-alive
      *       or the client claims to be HTTP/1.1 compliant (perhaps  
a proxy);
      *   THEN we can be persistent, which requires more headers be  
      * Note that the condition evaluation order is extremely important.

     if ((r->connection->keepalive != AP_CONN_CLOSE)
         && ((r->status == HTTP_NOT_MODIFIED)
             || (r->status == HTTP_NO_CONTENT)
             || r->header_only
             || apr_table_get(r->headers_out, "Content-Length")
             || ap_find_last_token(r->pool,
             || ((r->proto_num >= HTTP_VERSION(1,1))
                 && (r->chunked = 1))) /* THIS CODE IS CORRECT, see  
above. */
         && r->server->keep_alive
         && (r->server->keep_alive_timeout > 0)
         && ((r->server->keep_alive_max == 0)
             || (r->server->keep_alive_max > r->connection->keepalives))
         && !ap_status_drops_connection(r->status)
         && !wimpy
         && !ap_find_token(r->pool, conn, "close")
         && (!apr_table_get(r->subprocess_env, "nokeepalive")
             || apr_table_get(r->headers_in, "Via"))
         && ((ka_sent = ap_find_token(r->pool, conn, "keep-alive"))
             || (r->proto_num >= HTTP_VERSION(1,1)))) {
         int left = r->server->keep_alive_max - r->connection- 

         r->connection->keepalive = AP_CONN_KEEPALIVE;

More information about the Mod_python mailing list