You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2015/12/29 15:24:39 UTC
Re: Better ap_casecmpstr[n]?
ping.
Just a reminder that right now, trunk uses ap_casecmpstr[n](),
which can make some backport requests "problematic" due to
possible merge conflicts.
Can we *please* decide what we are doing?
trunk is starting to accumulate a bunch of kruft, which
will make it difficult when we decide to start 2.6 in earnest.
All you have to do is look at the 2.4 backports which are
based on some of that trunk "kruft" which is not in a
state which we feel comfortable backporting. Now certainly
some stuff can't be backported easily, but it's also not
good having stuff in trunk which is wonky enough that we
don't feel like it's ready for prime-time in 2.4 no matter
what we do (or is simply being ignored).
> On Nov 25, 2015, at 11:17 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> What is the current status? Is this on hold?
Re: Better ap_casecmpstr[n]?
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Dec 29, 2015 at 5:35 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> On Dec 29, 2015, at 11:28 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>> 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.
Makes sense, maybe we can enforce that in future patches and backport
them easily, the first "use case" already requires enough changes IMHO
:)
Re: Better ap_casecmpstr[n]?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Dec 29, 2015, at 5:14 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>
> Directive names, yes. Directive arguments - not as much.
Yeah... that's what I said. We know our names :)
Re: Better ap_casecmpstr[n]?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Dec 29, 2015 at 10:35 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Dec 29, 2015, at 11:28 AM, Yann Ylavic <yl...@gmail.com> wrote:
> >
> > On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <ji...@jagunet.com> 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)?
Re: Better ap_casecmpstr[n]?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Dec 29, 2015, at 11:28 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <ji...@jagunet.com> 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.
>>
>> 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.
Re: Better ap_casecmpstr[n]?
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski <ji...@jagunet.com> 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?
>
> 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...
Re: Better ap_casecmpstr[n]?
Posted by Jim Jagielski <ji...@jaguNET.com>.
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.
PS: What determines "abusive" usage?
> On Dec 29, 2015, at 10:56 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> On Tue, Dec 29, 2015 at 3:24 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> ping.
>>
>> Just a reminder that right now, trunk uses ap_casecmpstr[n](),
>> which can make some backport requests "problematic" due to
>> possible merge conflicts.
>
> I've just committed (in r1722150) more reverts of abusive
> ap_casecmpstr[n]() usage I introduced in r1715880.
> This now leave us the attached 2.4.x backport patch should we decide
> to apply these changes to 2.4.x.
>
>>
>> Can we *please* decide what we are doing?
>
> I'd vote for the backport...
> <httpd-2.4.x-ap_casecmpstr.patch>
Re: Better ap_casecmpstr[n]?
Posted by Yann Ylavic <yl...@gmail.com>.
On Tue, Dec 29, 2015 at 3:24 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> ping.
>
> Just a reminder that right now, trunk uses ap_casecmpstr[n](),
> which can make some backport requests "problematic" due to
> possible merge conflicts.
I've just committed (in r1722150) more reverts of abusive
ap_casecmpstr[n]() usage I introduced in r1715880.
This now leave us the attached 2.4.x backport patch should we decide
to apply these changes to 2.4.x.
>
> Can we *please* decide what we are doing?
I'd vote for the backport...