httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wichitill <ma...@gmx.de>
Subject Re: Problem use Apache::Upload
Date Fri, 30 Jul 2004 21:28:17 GMT
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)

Mime
View raw message