perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Interrupting a POST with file upload
Date Wed, 08 Feb 2012 11:05:35 GMT
You probably don't want to do this with a hook if you can
avoid it.  The reason is that once httpd sends the 100 Continue
it will read the entire upload, even after CGI.pm or apreq
has stopped parsing it.



----- Original Message -----
> From: André Warnier <aw@ice-sa.com>
> To: mod_perl list <modperl@perl.apache.org>
> Cc: 
> Sent: Wednesday, February 8, 2012 4:14 AM
> Subject: Interrupting a POST with file upload
> 
>T his 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 <aw@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 ?
> 

Mime
View raw message