httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: dev question: apreq 2 as a filter?
Date Mon, 26 Aug 2002 14:08:47 GMT
At 02:07 AM 8/26/2002, Stas Bekman wrote:
>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. 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.

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

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

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.

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

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

Bill


Mime
View raw message