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 Sat, 24 Aug 2002 07:43:04 GMT

Stas Bekman <stas@stason.org> writes:

> William A. Rowe, Jr. wrote:
> > At 02:46 AM 8/23/2002, Stas Bekman wrote:

[...]

> >> No, the problem I'm referring to is how to invoke the filter in first 
> >> place. It won't be invoked if the response handler won't call 
> >> ap_get_brigade. Hmm, I think I know how this should work.
> >>
> >> Any time anybody does any enquiry from apreq, we check a flag whether 
> >> we have the data consumed and parsed (which is done already). If it 
> >> wasn't consumed yet, apreq inserts its input filter and performs the 
> >> ap_get_brigade call.
> > 
> > 
> > Up to some, sane limit.  I wouldn't want us pulling more than 64k or so 
> > without
> > some extra thought.
> 
> of course.

I don't agree.  IMO (using your terminology) the warehouse should 
be off-limits until the POST data has been parsed *completely*.  That
means *only* the content handler should be making any enquiries.  

Furthermore, if the content handler wants to call ap_get_brigade 
itself to get at a portion of the POST stream, it should do that
*before* ever visiting our warehouse.  Otherwise apreq_request_parse
should just gobble it all up.

I still think this invocation issue you're grappling with is a red 
herring for apreq.  The content-handler simply must adhere to the 
HTTP protocol- if it decides to ignore the request body when it
shouldn't have, that's not the apreq library's fault.   Moreover, 
AFAICT this problem does not apprear to be exclusive to our hypothetical 
apreq filter.

[...]

> How do we protect from injecting the filter too late, if something has 
> already pulled the data in? just document this potential problem?

Right- that's a (hopefully) detectable error.

-- 
Joe Schaefer

Mime
View raw message