httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Problem use Apache::Upload
Date Sat, 31 Jul 2004 16:48:52 GMT
Markus Wichitill <mawic@gmx.de> writes:

[...]

> my $apr = Apache::Request->new($ap,
>    POST_MAX => $cfg->{maxAttachLen},
>    TEMP_DIR => $cfg->{attachFsPath},
> );
> if ($ap->method eq 'GET') {
>    $ap->discard_request_body() == 0

In your case (a content-handler using Apache::Request) 
you should always call discard_request_body (not just for GET).
The way to think of the discard_request_body call is

  "my content handler does not need the raw POST data,
   so tell apache to pull it through the input 
   filters via ap_get_brigade(), and then delete 
   all the resulting buckets."

[...]

> [error] [client 127.0.0.1] (70022)There is no error, this value
> signifies an initialized error code: 

Blech- I'll change this APR_EINIT to an APR_EGENERAL.

> Content-Length header (4959211) exceeds configured max_body limit
> (1000000)


Are you certain the server is segfaulting there?
Is there anything in the error log after this message?

In any case, I see there are a few problems with the way
we're currently reporting and checking errors for the POST data.
Originally all error reporting was the parser's responsibility,
however it made more sense to move some of the configuration 
checks (like POST_MAX) into the environment (mod_apreq) instead.

This means POST data errors can be generated by either the 
environment module or the parser itself.  We may need a body_status 
field in apreq_request_t to allow the parser and environment module 
to communicate their combined state to the user.

-- 
Joe Schaefer


Mime
View raw message