httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul G. Weiss" <>
Subject Re: Problem with posting lots of data
Date Wed, 25 Feb 2004 05:42:32 GMT
Here are the results of the experiments using multipart/form-data and use  
Apache::Request together with CGI.

First, using multipart/form-data. Apache::Request script gets it right for  
n <= 77. Using CGI, it is correct for n <= 635. I don't know what the  
problem is for n > 635 for CGI, but this is the apreq-dev list.   
Incidentally there is a little weirdness here with Apache::Request even  
w/o using ssl.  On a fresh server restart, it gets it wrong for high n,  
say n=400.  However, after a few requests, it gets it right for high n.

Now combining Apache::Request and CGI.  First note that there are two way  
to do this, and they have different results:

The first way is to do:

     my $req = Apache::Request->new($r, POST_MAX => 10_000_000, FIELD_LIMIT  
=> 20_000);
     my $cgi = CGI->new;

     my $cgi_name_count = scalar(grep(/^name\.\d+$/, $cgi->param));
     my $name_count = scalar(grep(/^name\.\d+$/, $req->param));

i.e. do the CGI read before the Apache::Request one.  Here, both  
Apache::Request and CGI report correct results for n<=1000.  After that it  
starts screwing up.  Once it screws up a few times, then it doesn't even  
work for n=1000.  (I ran with -X so as to have a single server).

The second is to do:

     my $req = Apache::Request->new($r, POST_MAX => 10_000_000, FIELD_LIMIT  
=> 20_000);
     my $name_count = scalar(grep(/^name\.\d+$/, $req->param));

     my $cgi = CGI->new;
     my $cgi_name_count = scalar(grep(/^name\.\d+$/, $cgi->param));

i.e. do the Apache::Request read before the CGI one.  Here, CGI is no  
help.  It still fails for n>442.  When it fails, sometimes CGI and  
Apache::Request agree on the count, sometimes they don't.

On Tue, 24 Feb 2004 19:57:23 -0500, Paul G. Weiss  
<> wrote:

> Joe Schaefer writes:
>> "Paul G. Weiss" <> writes:
>>> But for n>442 the numbers don't match.
>>  That is somewhat expected, since the parsers will currently give up  
>> when the number of fields exceeds 200  (the actual
>> number depends on the amount of data still inside the input brigade at  
>> that particular moment.)
>>> That isn't all.  It works fine through http
>>  By "it works fine", you mean the script below works for n < 200?
> By "it works fine" I mean that it works even for n <= 10_000 (which is  
> what I set FIELD_LIMIT to) for http, and fails for n >= 443 for https.   
> For CGI, it works for arbitrary n.
>>> (as long as n < FIELD_LIMIT),
>>  FIELD_LIMIT is going away, along with the max_fields and read_ahead
>> attributes of apreq_config_t.
> So 200 fields will be a hard limit then?  But we will still be allowed  
> to have many values per field, right?
>>> but fails through https.  So you would think that the problem is with
>>> mod_ssl/openssl.  However, if you use CGI instead of Apache::Request
>>> (see below - comment out the Apache::Request line and uncomment the
>>> CGI line), it works fine, even through https!
>>  I'm curious- what happens if both of them are uncommented?
>> (In mp2, Apache::Request and can both be used simultaneously
>> within the same request).
> I'll try tonight, but wouldn't it depend upon the order?  Won't CGI  
> consume the posted data, making it unavailable for Apache::Request.  And  
> similarly the other way around?
>> What about using "multipart/form-data" for the encoding, instead
>> of the default ("application/x-www-form-urlencoded")?  Does that
>> change anything?
> Again, I'll try tonight when I have access to the machine.
>>> This tells me that it isn't mod_ssl/openssl alone, but in the
>>> interaction between it and libapreq2, perhaps some difference in how
>>> the data is buffered?  Can anyone confirm this? I'm using
>>> 	Apache 2.0.48
>>> 	mod_perl/1.99_12
>>> 	Perl/v5.8.1
>>> 	mod_ssl/2.0.48
>>> 	OpenSSL/0.9.7a
>>  Not easily- at the moment my current build box looks nothing like  
>> yours (no SSL in particular).  Anyone else able to take a crack?  --  
>> Joe Schaefer

View raw message