httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Issac Goldstand" <igoldst...@followmecorp.com>
Subject Re: dev question: apreq 2 as a filter?
Date Tue, 27 Aug 2002 10:37:10 GMT

----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "Joe Schaefer" <joe@sunstarsys.com>
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>; "Issac Goldstand"
<margol@beamartyr.net>; "apreq list" <apreq-dev@httpd.apache.org>
Sent: Tuesday, August 27, 2002 6:29 AM
Subject: Re: dev question: apreq 2 as a filter?


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

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

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

> > [...]
> >
> >
> >>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 :)
>

Agreed.

  Issac


Mime
View raw message