httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Grundman <a...@hybridized.org>
Subject Re: Parsing error when parsing the second time
Date Sat, 31 Mar 2007 04:17:47 GMT

On Mar 31, 2007, at 12:02 AM, Joe Schaefer wrote:

> You're wandering into largely unchartered territory
> by using APR:: outside of mod-perl, so  I would try
> to be conservative if possible, and follow the examples
> in the test code. APR::Pool has a good set of tests,
> so I'm really not sure the problem is there or somewhere
> in apreq's xs.  It just stood out that you were using
> a new pool for each subroutine call, which probably
> isn't the best way to do things.

OK, thanks for the advice.  I'm actually a bit surprised this is  
uncharted territory.

I'm working on trying to improve the performance of Catalyst's body  
parsing.  We're currently using the all-Perl HTTP::Body, and it  
actually beats APR::Request for urlencoded data.  The regexes are  
pretty simple, so this isn't too surprising.

Where I hope it will help a lot more is multipart/form-data parsing,  
but I don't have this working yet to see.  I also want to use it to  
replace some uses of URI::Escape which is fairly slow compared to apreq.

The reason I want it to work outside of Apache is so that people  
running Catalyst is FastCGI mode, or using one of the standalone Perl  
servers, can benefit from the improved performance.  I have a grand  
plan of building a standalone XS module that does a lot of what apreq  
does, but without all the Apache requirements.  URI escaping/ 
unescaping, header parsing, cookies, query strings, body data, etc.   
A lot of the apreq code could be used in something like this I  
think.  The barrier to entry with apreq is pretty high at the moment,  
when compared to a standard CPAN module.

-Andy

Mime
View raw message