httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: dev question: apreq 2 as a filter?
Date Tue, 27 Aug 2002 03:29:34 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
>>Joe Schaefer wrote:
>>
>>>Joe Schaefer <joe@sunstarsys.com> 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.

>   (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.

> [...]
> 
> 
>>Not sure why have you added a note about s/upstream/downstream/g, any 
>>filter cares only about the upstream filter (which may block), because 
>>that's where the data is coming from. it passes through the data to the 
>>downstream filter, but it doesn't care about it.
> 
> 
> Does this clear things up now?

I guess so. Having a spec will help, as the current emails with 
scenarios are getting longer and longer and many repeat themselves using 
different wordings :)

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message