Re: Parsing error when parsing the second time

Andy Grundman <[email protected]>
Newsgroups gmane.comp.apache.apreq
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.