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: FW: Help with Apache::Request module
Date Wed, 14 Jan 2004 15:47:01 GMT
Geoffrey Young <geoff@modperlcookbook.org> writes:

[...]

> just one thing of interest.  if the client posts 10MB (assuming it passes
> the configured POST limit) then all 10MB are always cached? 

It actually depends on what's going on with the handlers themselves.
If the first handler is an auth handler which uses libapreq2, then
the unless the handler NEEDS all 10MB, libapreq2 will just fetch
enough data for the handler to make its decision.  For instance, if
it needs to check whether a POST parameter named "password" was set to 
"foo":

  sub auth_handler {
        my $req = Apache::Request->new(shift);

        if ($req->param("password") eq "foo") {
            return OK;
        }        
        else {
            return AUTH_ERROR;
        }
  }

The scalar $req->param call will cause libapreq2 to keep fetching POST
data until it's found the "password" param.  If that param is near
the front of the POST body, then libapreq2 will have only fetched 
about 64KB before returning from the param() call.  

If the "password" param never appears, then libapreq2 will gobble up the 
entire POST data before giving up, with param() returning undef.  At
this point the POST is data is both parsed (into $req->body) and spooled
(to disk if the POST is larger than 256KB) by the mod_apreq filter.

> is this configurable, so that end-users can specify whether this is
> desirable for their application?  part of the reason we introduced
> instance() (over overriding new() ) was to let users have a choice in
> the matter.

I wasn't aware of a significant difference in memory footprint between
instance() and new() in mp1 (the reason being that the underlying C 
strings representing libapreq's parser output are always allocated from
the request pool, so they're not cleaned up until the request pool 
is destroyed).

> anyway, I guess the answer to future questions about instance() is
> that the functionality has been integrated into new(), making
> instance() unnecessary in libapreq2.  not merely that instance()
> hasn't been ported or isn't around anymore.

+1.

> I can patch Request_pod to that effect if I have my info correct.

Cool!
-- 
Joe Schaefer


Mime
View raw message