Long time fan, not a first time caller.

 

Libapreq2 was intended to be a safe,fast, standards compliant library- 
primarily *safe* before all other priorities.  Some of the work going on lately 
in util.c is starting to undermine that prime directive, so I’d like to better 
understand why these changes are happening, and why they are snowballing into a 
less functional, less secure software product that is driving up my support 
costs on CPAN.

 

For instance, this revision 1867789 is a pure pessimization:  it trades 
userland RAM for filesystem cache RAM, that’s it, but it’s not a big deal.  
Just churn.

 

Everything in the crufty, old apreq_header_attribute code I wrote was 
completely tossed and reimplemented.  Why?  We’re just racking up CVE’s, people 
are disabling the mfd parser altogether, and it no longer support common use 
cases that people now complain about because it supported cases in the wild 
that the new work does not.

 

With the latest code coming out of p5p for Perl, there’s a whole new reason for 
excitement in httpd-land: the mod_perl2 + mpm_event combination is rock solid 
and screaming fast with HTTP/2.  The only reason I resubbed here is in the 
hopes of some synergy retaking these perl-related projects, since mod_perl2 is 
the only game in town for embedded interpreters in httpd2 (and no, lua is not 
the answer, it’s not thread safe either).

 

 

Joe Schaefer, Ph.D.

<j...@sunstarsys.com <mailto:j...@sunstarsys.com> >

954.253.3732 <tel://954.253.3732/> 

SunStar Systems CMS <https://sunstarsys.com/CMS/>  - The Original Markdown JAM 
Stack™

 

Attachment: openpgp-digital-signature.asc
Description: PGP signature

Reply via email to