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 Tue, 27 Aug 2002 11:16:30 GMT
Issac Goldstand wrote:
> ----- Original Message -----
> From: "Stas Bekman" <>
> To: "Joe Schaefer" <>
> Cc: "William A. Rowe, Jr." <>; "Issac Goldstand"
> <>; "apreq list" <>
> Sent: Tuesday, August 27, 2002 6:29 AM
> Subject: Re: dev question: apreq 2 as a filter?
>>Joe Schaefer wrote:
>>>Stas Bekman <> writes:
>>>>Joe Schaefer wrote:
>>>>>Joe Schaefer <> writes:
>>>>>>I think the apreq filter can/should operate in a completely
>>>>>>transparent way, since all it has to do is read a copy of the buckets
>>>>>>into the apreq_list _as the upstream_ _filters dictate_.  Every time
>>>>>>our filter is invoked, it can make a stab at parsing the apreq_list
>>>>>>data, so the list should never get very big.
>>>>>Um, you may need to s/upstream/downstream/g in everything I wrote in
>>>>>the aforementioned post.  It'd be nice if what I write actually matched
>>>>>the picture in my head :-)
>>>>The things that I see weird about this is that the normal filter is not
>>>>supposed to call ap_get_brigade more than once.
>>>It is, I just didn't spell it out.  In the filter section, there
>>>should've been a
>>>  (g) content-handler calls ap_get_brigade again, and winds up
>>>      engaging the apreq filter again.  The filter picks up where
>>>      it last left off.
>>it's really the apreq part of the content handler is the one that calls
>>ap_get_brigade, the user code only calls apreq_*() calls and shouldn't
>>have to do anything with ap_get_brigade.
> Wait - I thought that the *user* calls ap_get_brigade() which causes data to
> pass through the apreq filter?  The only time apreq should directly call
> ap_get_brigade() on its own is in reponse to a query made by the "warehouse
> manager" if the entry in question is not marked "in stock"...

the user of apreq() generally has no idea that ap_get_brigade() exists 
at all. It just calls apreq_*() methods and the handler part of the 
apreq calls ap_get_brigade.

Think of it this way: the mod_perl 1.0 handlers using Apache::Request 
should work under 2.0 unmodified. Now you get the idea.

>>>  (h) the content-handler repeats (g) until it has whatever portion
>>>      of the POST data it wants.
>>>  (i) the content-handler wants some data from our warehouse.  The
>>>      apreq library calls apreq_request_parse to complete the parsing
>>>      of POST data (should it need to), and *then* fetches the data
>>>      requested.
>>>In the model I'm  presenting, the apreq filter *never* consumes
>>>more data than the downstream filter has requested of it.  If
>>>the downstream filter asks for 2KB, we should read in at most
>>>2KB, and use the filter's state mechanism to keep track of where
>>>we left off.  However, as soon as the content-handler wants something
>>>from the warehouse, it must abandoned any future claims to the remaining
>>>POST data, since apreq needs the full amount in order to access the
>>>warehouse and may call apreq_request_parse (prior to any access) to
>>>enforce that.
>>ok. just need to remember to apreq now is really two parts.
> Even 3 parts according to my approach - the filter, the parser and the
> warehouse manager.

that's a secondary separation. The first one into the filter and the 
response handler part, the latter is then can be split further.

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

View raw message