httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: dev question: apreq 2 as a filter?
Date Fri, 23 Aug 2002 06:10:34 GMT
William A. Rowe, Jr. wrote:

>> Also I think that we should keep the old mechanism as well. In case 
>> someone wants to decide at run time whether to run apreq or not. The 
>> more flexible apreq is the better.
> Well, if it's done correctly, they could believe they are invoking it
> at 'run time' while really inserting the filter.  It would appear that it's
> the old fashioned method, but it would be more secure if we have one
> mechanism to audit.

That might not always work, because you don't know if the body wasn't 
parsed already even if partially.

>> The is one question regarding the request pool. apreq works with query 
>> string as well, should it then invoke r->args when it needs that data? 
>> I thought it could grab it from the request headers since it's a 
>> filter, no?
> I would still choose r->args.  This filter would go in between the 
> HTTP_IN filter,
> and the handler plus other content filters.  It would never see the 
> headers in
> raw form.

sounds fine to me.

>> I have one blind spot though. If a response phase doesn't call 
>> ap_get_brigade to get the body, the request input filters won't be 
>> invoked. The connection input filters will be invoked, when httpd will 
>> suck the rest of the request in before generating the output, but... 
>> that's too late, the response phase will be over by that time. So how 
>> do we do that?
> Yup.  It isn't pretty.  But if we are clever, we may be able to force
> the body to be read once we are inserted in the chain, up to some
> arbitrary length (say 64kb, for example).  The apreq filter would then
> set aside the data if the read was for only 0 bytes, so the next read
> from ap_get_brigade (for the real body, from the handler) would return
> the data we set aside.

can you do that? I don't remember if there is such a hook

> This points to another optimization.  Wouldn't it be nice to be able
> to optimize ap_discard_request_body() by simply passing a note
> down to the apreq filter (if it's present and did its work) to toss the
> data once it has parsed the input?

it depends. if the apreq filter copies the data it parses and passes the 
brigade unmodified, there is no need to do anything at all, as the 
generic thing will just work. If on the other hand apreq consumes the 
body and doesn't leave anything in the brigades, then yes, it should 
short-cut and bring to a faster completion of the request assuming that 
the body is big (e.g. HEAD requests)

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message