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 16:18:27 GMT
"William A. Rowe, Jr." <wrowe@rowe-clan.net> writes:

> At 02:07 AM 8/26/2002, Stas Bekman wrote:

[...]

> >The things that I see weird about this is that the normal filter is not 
> >supposed to call ap_get_brigade more than once. our apreq_ filter calls 
> >ap_get_brigade more than once, because if it doesn't, there is no way to 
> >consume the data (the response handler) will usually not ask for the raw 
> >body. So apreq_ is really a semi-filter, since it acts as a filter and 
> >consumer at the same time.
> 
> I'm suggesting we have a broken assumption... until you have pulled x bytes
> of data, you won't have x bytes of information.

Right; please see the appended steps (g), (h), and (i) that I sent in
my followup to Stas.

> This all implies that the body must be slurped by the handler, complete,
> before the filters can trust that they have all the variables.  That's
> why I'd  a status flag, NOT_READ, IN_PROGRESS, COMPLETE and NO_BODY
> (in that order so that <COMPLETE has a well-defined meaning.)

+1 to adopting Bill's conventions for the status flag.

> Because filters work in-line, this means a filter authors will have to trust
> handler authors to slurp the client's body before sending their response.
> Since we can't trust that, a given filter can insist we continue to read and
> set aside the client's body until it's complete [or hits some arbitrary len]
> so that filter can 'react'.

OK, that makes sense.  *Now* I see why we may need to set aside
some of the client's body.

> That could happen after the handler sends the first output brigade.
> Since the filter isn't prepared to process that brigade without
> complete knowledge of the post input body, it will have to block on
> some apreq_complete_get_brigade() sort of call.  That apreq filter
> will have to set aside the read so that it's fulfilled when the handler
> resumes reading the client body.

Got it.

[...]

> This adds one interesting question... where in the filter stack does the
> apreq filter belong?  After other filters transform the input?  I'd presume
> so [if we are trying to normalize the input to, say, utf-8, we would want to
> do so before we parse the input into apreq variables.]

I think the apreq filter belongs somewhere towards the end of the 
input filters (closer to the content-handler than the HTTP_INPUT filter).
What concerns me here is that whatever mechanism we use to prefetch
some of the POST data may cause a problem with other filters that are
injected by the content handler.

For instance, it would be a bad thing if the content-handler injects
apreq at the end of the filter chain, then "does something" to cause
apreq to prefetch some post DATA, and *then* wants to inject utf-8
somewhere upstream from the apreq filter.

-- 
Joe Schaefer

Mime
View raw message