httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <...@sunstarsys.com>
Subject Re: dev question: apreq 2 as a filter?
Date Mon, 26 Aug 2002 11:09:44 GMT
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.

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

[...]

> 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?

-- 
Joe Schaefer

Mime
View raw message