httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1715876 - in /httpd/httpd/trunk: modules/cache/ modules/filters/ modules/generators/ modules/http/ modules/http2/ modules/loggers/ modules/mappers/ modules/metadata/ modules/proxy/ modules/slotmem/ modules/test/ server/
Date Tue, 24 Nov 2015 04:28:00 GMT
On Nov 23, 2015 14:12, "Yann Ylavic" <> wrote:
> On Mon, Nov 23, 2015 at 9:00 PM, Marion & Christophe JAILLET
> <> wrote:
> >
> > Moreover, this kind of patch is a good candidate for backport as it
> > introduces many small differences between 2.4 and trunk.
> > Without a backport, backporting future patches may become a nightmare.
> Agreed.
> >
> > I would find useful to split it into several pieces.
> > The first one should apply cleanly to 2.4.x to ease backport.
> > Other parts should be splitted in "as many piece as necessary" for
> > future backport.
> I'll try to merge with svn, and resolve conflicts...


I didn't have a chance to review the patch, but all of the instances that
1. map to an RFC protocol string comparison and 2. occur in 2.4 code base
*should* be coalesced into one patch.  I'm +1 for every such change.  The
rest of the RFC token comparisons can be added individually for later
merging with their associated bug or enhancement backports.

I'm strongly -1 for using this function to 'optimize' what is otherwise a
non-spec string comparison.  There is no excuse for us to defeat good
implementations of strcasecmp for the benefit of platforms with shoddy

Jim proposed this as an optimization but I reject that, and wholeheartedly
support his suggested use of a predictable ASCII-only folding comparison
when following any spec that defines token strings in terms of ASCII alpha

We aren't writing a clib but we do have to be mindful of i18n side-effects
of the clib we are running within.

View raw message