On Tue, Dec 29, 2015 at 10:35 AM, Jim Jagielski <[email protected]> wrote:
> > > On Dec 29, 2015, at 11:28 AM, Yann Ylavic <[email protected]> wrote: > > > > On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <[email protected]> wrote: > >> In a sep thread on dev@apr, OtherBill appears to be trying to > >> determine the "right" name for the APR impl... maube we should > >> wait to see what it's decided on there and we can follow > >> suit. > > > > OK, although we won't be able to use APR's functions until we require > > (at least) APR-1.6.x. > > Maybe a follow up patch/backport could later "#define ap_casecmpstr[n] > > apr_whatever" when available? > > > > Right. I was just thinking we'd use whatever APR uses but substitute > 'ap_' for the 'apr_', as norm. > +1 - minimal delta. Easily becomes an ap_compat.h macro moving forwards to make things easier for porters moving modules from 2.4.x to [23].next. > >> PS: What determines "abusive" usage? > > > > When used to compare something which is not a HTTP token or a scheme > > (eg. config parameters). > > As I see it, the valid usage is against remote/untrusted data known to > > be defined in POSIX/C locale only... > > IMO, anything we check regarding config directives (like all the > proxy params) are also candidates for using "our" function. We > *know* our config directives are ASCII. > Directive names, yes. Directive arguments - not as much. Some are (boolean flag tests, keywords) but others such as path and url args shouldn't touch that function, IMHO. One thing to consider, is it a startup-path test (e.g. on initial config read only) or going to be accessed frequently (.htaccess parsing)?
