This refers to and follows another thread originally entitled "mod perl installed but not running", started by Mike Cardeiro.

It seemed better to start a new thread with a subject more to the point of this 
issue.

Perrin Harkins wrote:
> On Tue, Feb 7, 2012 at 7:26 PM, André Warnier <a...@ice-sa.com> wrote:
>> You can also look at $CGI::POST_MAX in the same documentation.
>
> See also LimitRequestBody:
> http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
>

As long as we have an expert..

What Mike wants to do (and me too), is to limit the size of a file that a specific user is uploading via a POST, in real-time and depending on a limit variable on a per-user, per-POST manner. And he wants to do this in such a way as to interrupt the POST itself, while it is taking place (aka if possible while the browser is still sending data to the server), to avoid a waste of time and bandwidth when a user is exceeding his quota e.g.

As far as I know, LimitRequestBody is an absolute POST size limit set once and for all in the server config, and valid for all POSTs (and PUTs) after server restart. And it is calculated on the base of the real bytes being sent by the browser, this including the overhead caused by Base64 encoding the content of a file sent for example. (So that if you set the limit to 1MB, this will actually kick in as soon as the net unencoded size of the file being uploaded exceeds 660KB or so.)

Then there is the $CGI_POST_MAX, which may very well be the same server value being manipulated by the CGI module, or it may be a private copy by CGI.pm. What is not really clear is if that value is "thread-safe" in all scenarios.

In the normal scenario, when retrieving the uploaded file's handle via the CGI.pm call to param(file_input_name) or upload(file_input_name), what one actually gets is a handle onto a local temporary file, into which Apache/CGI.pm has already stored the whole content of the uploaded file. By that time, the original file upload from the browser has already happened, so doing something at this point would be too late to interrupt the browser POST itself (and the bandwidth and time have already been spent).

On the other hand, the CGI.pm documentation seems to say that if one uses the "hook" functionality for a file upload, then Apache/CGI.pm do not use a temporary file, and one gets a handle directly into the POST body content (so to speak), as it is being received by Apache. And thus this could be a way to achieve what Mike wants. (I suppose that we can assume that even though we get a handle into the POST body content, what we are reading is the decoded data, right ?).

Now the question is, are my above interpretations correct ?



Reply via email to