Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <410ABD71.5070305@gmx.de>
Date: Fri, 30 Jul 2004 23:28:17 +0200
From: Markus Wichitill <mawic@gmx.de>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
MIME-Version: 1.0
To: Joe Schaefer <joe+gmane@sunstarsys.com>
CC: apreq-dev@httpd.apache.org
Subject: Re: Problem use Apache::Upload
References: <1091171298.4109f3e2f2210@webmail.vcsn.com>
 <410A38BD.7010207@gmx.de> <1091193034.410a48ca2ed08@webmail.vcsn.com>
 <410A4E0A.5000506@gmx.de> <1091195154.410a511229eea@webmail.vcsn.com>
 <410A5F6B.5080506@gmx.de> <87acxha49x.fsf@gemini.sunstarsys.com>
 <410A9CB1.8040702@gmx.de> <87hdrp8ei5.fsf@gemini.sunstarsys.com>
In-Reply-To: <87hdrp8ei5.fsf@gemini.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Schaefer wrote:
> Markus Wichitill <mawic@gmx.de> writes:
>>So is parse() still the recommended way of checking for upload errors?
> 
> Yes, if you're really demanding a final status (versus a current one),
> and you're not writing a content-handler.

Well, my applications usually need all their parameters anyway, so I don't 
really see the point of delayed parsing. Also, if the input is too big, 
incomplete or otherwise corrupted, I want to exit early, since there's no 
point in working with incomplete or even corrupted data.

This is what I currently do during initialization in mwForum, my 
CGI/mod_perl hybrid forum application (registry scripts using the mp1/mp2 
API instead of CGI stuff when running under mod_perl):

my $apr = Apache::Request->new($ap,
   POST_MAX => $cfg->{maxAttachLen},
   TEMP_DIR => $cfg->{attachFsPath},
);
if ($ap->method eq 'GET') {
   $ap->discard_request_body() == 0
     or error("discard_request_body() failed.");
}
elsif ($ap->method eq 'POST') {
   $apr->parse() == 0
     or error("Input exceeds maximum allowed size or is corrupted.");
}
else {
   $ap->status(405);
   exit;
}

>>On Win32 however, posting a big upload > POST_MAX and then calling parse() to
>>get the status will crash Apache. I can reproduce that by using a 4MB file in
>>upload.t, setting POST_MAX=1MB and calling parse() in upload.pm.
> 
> parse() in void context is supposed to croak in that case, but it 
> shouldn't ever crash the server (as a last resort mod_perl should 
> catch the exception, so eg. the tempfiles should still get cleaned up).
> 
> Can you please show us, explicitly, what happens?

Getting a stacktrace on Win32 would mean I have to swap my ASF and 
ActiveState binaries with self-compiled debug builds, which would take a 
while. So I had hoped that maybe Randy can reproduce the segfaults with a 
modified test, before I go to all the trouble.

strace on Linux may show somewhat useful output even without debug builds, 
but on Windows I'v never seen anything useful in VC6 with release builds.

Without a stacktrace, there isn't much to see:

# Failed test 21 in t\apreq\upload.t at line 71
# testing : fh test for ff.exe
# expected:
# type: application/octet-stream
# size: 4959023
# filename: ff.exe
# md5: 65e0f588c3a8b44b0f575363995c1ff5
# received: 500 Unknown error
not ok 21
# Failed test 22 in t\apreq\upload.t at line 71 fail #2
# testing : io test for ff.exe
# expected:
# type: application/octet-stream
# size: 4959023
# filename: ff.exe
# md5: 65e0f588c3a8b44b0f575363995c1ff5
# received: 500 Can't connect to localhost:8529 (connect: Unknown error)
not ok 22
[...]

[error] [client 127.0.0.1] (70022)There is no error, this value signifies an 
initialized error code: Content-Length header (4959211) exceeds configured 
max_body limit (1000000)