httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Issac Goldstand" <mar...@beamartyr.net>
Subject Re: dev question: apreq 2 as a filter?
Date Wed, 28 Aug 2002 00:04:31 GMT

----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "Issac Goldstand" <igoldstand@followmecorp.com>
Cc: "Joe Schaefer" <joe@sunstarsys.com>; "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 2:16 PM
Subject: Re: dev question: apreq 2 as a filter?


> Issac Goldstand wrote:
> > ----- 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"...
>
> 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.

No, quite the contrary, you proved my point...  Consider the two possible
scenarios:

1) Old apreq_1-style: A simple handler calls $q->parse, or
$q->param('somevalue').  In this case, the user is making a request from the
"warehouse manager".  If the entry is not "in stock", apreq will continue to
call ap_get_brigade() until the warehouse manager can return something
(either a value or an error if the parser set "warehouse full" in response
to EOS).
2) New Apache 2-style:  A more complex handler or filter wants to start
reading in the post body.  Since content-handlers are supposed to read the
data, a programmer might call ap_get_brigade() on his own.  This presents no
problem as the data will go through our filter anyway, which will in turn
happily pass the data to the apreq_parser.  Technically, as far as I've
understood, this is actually proper behavior for Apache 2 handlers...  Am I
missing something here?


Mime
View raw message