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 Fri, 23 Aug 2002 04:50:38 GMT
Stas Bekman <stas@stason.org> writes:

[...]

> Also I think that we should keep the old mechanism as well. In case 
> someone wants to decide at run time whether to run apreq or not. The 
> more flexible apreq is the better.

I'm viewing the current implementation it in this way (please suspend 
your disbelief until the end :) -

--------------------------------------------------
When a content-handler calls apreq_request_new, that does two things: 
creates a placeholder for the parsed data (apreq_request_t *), and 
installs the "virtual apreq filter" at the very end of the input filters 
chain.  The "virtual apreq filter" holds the stack of registered parsers 
(imagine we've replaced req->parsers with req->filter in apreq_request_t).

The next thing the content-handler does is call apreq_request_parse 
(implicitly or explicitly).  Its only job is to pull all the data buckets 
through the input filters.  The content-handler will block here until 
apreq_request_parse's job is done.

Although this is a fairly bizarre portrait of how the current code
"works",  do you see any conceptual problems here?  If not, then reworking
the "virtual apreq filter" into a real input filter should give us the
current mechanism for free.
--------------------------------------------------

Extending support from content-handlers to filters:

If we s/content-handler/output filter/g above, we need to figure out
how to make apreq_request_new locate the parsed apreq_request_t object.
If the "apreq filter" object is still around, maybe we could pull it
from that?

I'm still pondering the s/content-handler/input filter/g case.
At the moment I'm wondering why another input filter would ever
want to call apreq_request_parse().

> I have one blind spot though. If a response phase doesn't call 
> ap_get_brigade to get the body, the request input filters won't be 
> invoked. The connection input filters will be invoked, when httpd will 
> suck the rest of the request in before generating the output, but... 
> that's too late, the response phase will be over by that time. So how do 
> we do that?

I don't see what you're concerned about here.  Can you make up
an example for me?

-- 
Joe Schaefer

Mime
View raw message