Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3D644BC4.9010705@stason.org>
Date: Thu, 22 Aug 2002 10:26:12 +0800
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020510
MIME-Version: 1.0
To: Joe Schaefer <joe@sunstarsys.com>
Cc: apreq list <apreq-dev@httpd.apache.org>
Subject: Re: dev question: apreq 2 as a filter?
References: <m33ct8f3oe.fsf@mumonkan.sunstarsys.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Schaefer wrote:
> During the ongoing discussion on dev regarding apreq-2,
> William Rowe suggested we might implement apreq-2 as an
> apache filter.  In principle, I think this is a great idea.
> But I have a feeling it will require substantial reworking of
> all our parser-based code (basically everything in 
> apreq_parser.c).
> 
> Here's why:  running apreq-2 as an input filter means (I think)
> that we'd need to reimplement the parsers as callbacks which
> relinquish control after they've read a few chunks of data.
> Currently they consume everything, but there's really no
> reason they can't stop after locating a urlword or a block of 
> data from a file upload.  It's possible that we could rework
> the parsers themselves to be filters, instead of maintaining
> our own internal parser stack (req->parsers).  Unfortunately
> I've no experience with the apache filter API, so this may
> all be a lot of hot air.
> 
> Thoughts on API changes?  Should apreq_parser_register() register
> an apache filter instead?

As mentioned before, I'd rather wait before httpd-dev decides how they
want apreq to be in order to accept it.

Regarding filters, I think there shouldn't be a lot to change regarding 
the parsing. You simply suck in all the data as before and parse it as 
before. Look at mod_deflate, which does a more complicated thing since 
it also modifies the data, whereas we aren't. Once the data is parsed it 
should be stuck into the connection context, so it's available to the 
letter stages.

Joe, see my preliminary diagrams/explanations at 
http://perl.apache.org/docs/2.0/user/handlers/handlers.html
to get a quick intro on how things work in 2.0. This is rather mod_perl 
2.0 specific but not much different from Apache itself, which does more 
things. The concepts are the same.

The point is that you don't need to relinquish control since you never 
take it in first place, think of a passive filter and read my perl 
implementation of MyApache::FilterSnoop, which perfectly shows how this 
works:
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#All_in_One_Filter

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com