Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Wed, Mar 2, 2016 at 11:47 PM, Yann Ylavic  wrote:
> On Wed, Mar 2, 2016 at 8:08 PM, Jim Jagielski  wrote:
>>
>> Hmmm... iirc, if there is a mismatch, the old files are
>> automagically removed.
>
> You are right, I was still influenced by PR58024 triggering AH02599
> (painful fix), but that was due to the missing unlink() semantic on
> Windows...
>
> I still think AH02599 can be triggered on unclean shutdown, with name
> based SHMs when the cleanup is not called (this has nothing to do with
> mod_proxy_hcheck, though).
>
> Couldn't we use anonymous SHMs for slotmem_shm(s) since we
> create/destroy them for each restart anyway?
> I don't think the apr_shm_attach() path in slotmem_create() should
> ever be hit (thanks to the caching of in 'globallistmem' of the
> process' created SHMs, and other processes should use slotmem_attach()
> anyway).
> Hmm, I may miss some Windows MPM thingy again...

Nevermind, we still need to attach() in children processes!

Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

On Wed, Mar 2, 2016 at 8:08 PM, Jim Jagielski  wrote:
>
> Hmmm... iirc, if there is a mismatch, the old files are
> automagically removed.

You are right, I was still influenced by PR58024 triggering AH02599
(painful fix), but that was due to the missing unlink() semantic on
Windows...

I still think AH02599 can be triggered on unclean shutdown, with name
based SHMs when the cleanup is not called (this has nothing to do with
mod_proxy_hcheck, though).

Couldn't we use anonymous SHMs for slotmem_shm(s) since we
create/destroy them for each restart anyway?
I don't think the apr_shm_attach() path in slotmem_create() should
ever be hit (thanks to the caching of in 'globallistmem' of the
process' created SHMs, and other processes should use slotmem_attach()
anyway).
Hmm, I may miss some Windows MPM thingy again...

Re: httpd-trunk/modules/http2/NWGNUmod_http2 svn EOL Setting

[Yann Ylavic]

On Wed, Mar 2, 2016 at 11:08 PM, NormW  wrote:
> G/M,
> Could someone with a few free seconds set the
>  httpd-trunk/modules/http2/NWGNUmod_http2
> file to have the appropriate svn EOL setting?

Done in r1733382.

Regards,
Yann.

httpd-trunk/modules/http2/NWGNUmod_http2 svn EOL Setting

[NormW]

G/M,
Could someone with a few free seconds set the
 httpd-trunk/modules/http2/NWGNUmod_http2
file to have the appropriate svn EOL setting?

TIA
Norm

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Jim Jagielski]

Attached... just in case

svn.merge
Description: Binary data


svn.record
Description: Binary data

> On Mar 2, 2016, at 2:10 PM, Jim Jagielski  wrote:
> 
> yeah, I use svn.merge and svn.record (for those cases where
> I use a actual patch file, but want to record the SVN metadata)
> 
> 

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Jim Jagielski]

yeah, I use svn.merge and svn.record (for those cases where
I use a actual patch file, but want to record the SVN metadata)

Re: BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

[Jim Jagielski]

> On Mar 2, 2016, at 11:13 AM, Yann Ylavic  wrote:
> 
> re: mod_proxy_hcheck backport
> 
>>  ylavic: Looks like the changes on struct proxy_worker_shared would break
>>  startup with "BalancerPersist on" due to the strict checks on
>>  the sizes of existing slotmems (slotmem_create/attach)?
>> + jim: Yes, that is right (re: breakage)... this would be noted at
>> +  release.
> 
> Maybe we could have a "BalancerPersist try" option which would
> remove/reset the existing persistent files/SHMs when the sizes change
> (either corrupted files or this kind of upgrade change).
> 
> That could save the admin from having to locate the relevent
> files/SHMs (on disk/ipc/dev) and remove them, which is not obvious
> when you have multiple httpd instances running and only some of them
> need this administrative cleanage (the others keep running), since the
> names of the files/SHMs is not "configurable" (the ID based on
> servername/line/.. is finally ap_proxy_hashfunc()ed for practical
> reasons) and can hardly be related to an httpd instance...

Hmmm... iirc, if there is a mismatch, the old files are
automagically removed.

Re: conn_rec needs a context

[Stefan Eissing]

> Am 02.03.2016 um 17:20 schrieb Graham Leggett :
> 
> On 02 Mar 2016, at 2:26 AM, Yann Ylavic  wrote:
> 
 Would it make sense to add a vector of contexts that same way we have a 
 vector of configs, one slot for each module, which will allow any module 
 to add a context of it’s own to conn_rec without having to extend conn_rec?
>>> 
>>> Can't the existing ap_[gs]et_module_config(c->conn_config, ...) be
>>> used for that purpose?
>> 
>> I mean, put the context in the module config?
> 
> If we can it would be great - but is there an API guarantee that the memory 
> pointed to by the config is a per-connection copy of the config, and not the 
> raw underlying server wide config instead?

Does not, for example, mod_ssl rely on that?

Re: conn_rec needs a context

[Graham Leggett]

On 02 Mar 2016, at 2:26 AM, Yann Ylavic  wrote:

>>> Would it make sense to add a vector of contexts that same way we have a 
>>> vector of configs, one slot for each module, which will allow any module to 
>>> add a context of it’s own to conn_rec without having to extend conn_rec?
>> 
>> Can't the existing ap_[gs]et_module_config(c->conn_config, ...) be
>> used for that purpose?
> 
> I mean, put the context in the module config?

If we can it would be great - but is there an API guarantee that the memory 
pointed to by the config is a per-connection copy of the config, and not the 
raw underlying server wide config instead?

Regards,
Graham
—

Re: svn commit: r1733239 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Stefan Eissing]

> Am 02.03.2016 um 17:05 schrieb Yann Ylavic :
> 
> On Wed, Mar 2, 2016 at 10:51 AM,   wrote:
>> Author: icing
>> Date: Wed Mar  2 09:51:05 2016
>> New Revision: 1733239
>> 
>> URL: http://svn.apache.org/viewvc?rev=1733239=rev
>> Log:
>> adding default port numbers for h2/h2x proxy schemes, by jchampion
>> 
>> Modified:
>>httpd/httpd/trunk/modules/proxy/proxy_util.c
>> 
>> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1733239=1733238=1733239=diff
>> ==
>> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
>> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Wed Mar  2 09:51:05 2016
>> @@ -3681,6 +3681,8 @@ static proxy_schemes_t pschemes[] =
>> {"fcgi", 8000},
>> {"ajp",  AJP13_DEF_PORT},
>> {"scgi", SCGI_DEF_PORT},
>> +{"h2c",  DEFAULT_HTTP_PORT},
>> +{"h2",   DEFAULT_HTTPS_PORT},
> 
> We possibly need another way to define/lookup/compare proxy schemes
> (likewise with APR's), the more this list grows, the more it is cycle
> consuming (jfclere reported an issue possibly related to it some time
> ago).
> 
> Maybe a load-time-constructed hash table ?

Hmmm, the things above are not all real URI schemes and, as such, have no real 
definition outside our project. I *would* like each canon_handler to return the 
port number or something like it. The knowledge about default ports would 
better reside in the mod_proxy_XXX source than the common util.

-Stefan

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Yann Ylavic]

On Wed, Mar 2, 2016 at 5:04 PM, Eric Covener  wrote:
>
> Dunno if this is always clear to newcomers but some of use a script called
> svn.merge which helps with routine merges.
>
> http://webcache.googleusercontent.com/search?q=cache:WHtgz59cWzoJ:people.apache.org/~jorton/svn.merge+=1=en=clnk=us

Oh, it seems you just saved me a lot of time and repetitive work :)

>
> It's good for the crude but effective gmail archive searches.

Thanks a bunch!

BalancerPersist "relaxable" checks (was: svn commit: r1733283 - /httpd/httpd/branches/2.4.x/STATUS)

[Yann Ylavic]

re: mod_proxy_hcheck backport

>   ylavic: Looks like the changes on struct proxy_worker_shared would break
>   startup with "BalancerPersist on" due to the strict checks on
>   the sizes of existing slotmems (slotmem_create/attach)?
> + jim: Yes, that is right (re: breakage)... this would be noted at
> +  release.

Maybe we could have a "BalancerPersist try" option which would
remove/reset the existing persistent files/SHMs when the sizes change
(either corrupted files or this kind of upgrade change).

That could save the admin from having to locate the relevent
files/SHMs (on disk/ipc/dev) and remove them, which is not obvious
when you have multiple httpd instances running and only some of them
need this administrative cleanage (the others keep running), since the
names of the files/SHMs is not "configurable" (the ID based on
servername/line/.. is finally ap_proxy_hashfunc()ed for practical
reasons) and can hardly be related to an httpd instance...

Re: svn commit: r1733239 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Yann Ylavic]

On Wed, Mar 2, 2016 at 10:51 AM,   wrote:
> Author: icing
> Date: Wed Mar  2 09:51:05 2016
> New Revision: 1733239
>
> URL: http://svn.apache.org/viewvc?rev=1733239=rev
> Log:
> adding default port numbers for h2/h2x proxy schemes, by jchampion
>
> Modified:
> httpd/httpd/trunk/modules/proxy/proxy_util.c
>
> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1733239=1733238=1733239=diff
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Wed Mar  2 09:51:05 2016
> @@ -3681,6 +3681,8 @@ static proxy_schemes_t pschemes[] =
>  {"fcgi", 8000},
>  {"ajp",  AJP13_DEF_PORT},
>  {"scgi", SCGI_DEF_PORT},
> +{"h2c",  DEFAULT_HTTP_PORT},
> +{"h2",   DEFAULT_HTTPS_PORT},

We possibly need another way to define/lookup/compare proxy schemes
(likewise with APR's), the more this list grows, the more it is cycle
consuming (jfclere reported an issue possibly related to it some time
ago).

Maybe a load-time-constructed hash table ?

>  { NULL, 0x } /* unknown port */
>  };

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Eric Covener]

On Wed, Mar 2, 2016 at 10:59 AM, Yann Ylavic  wrote:
> Honestly I didn't really know it was a required practice (is it?),
> just always seen it in merge messages and found it useful, so just
> proposed...


Dunno if this is always clear to newcomers but some of use a script called
svn.merge which helps with routine merges.

http://webcache.googleusercontent.com/search?q=cache:WHtgz59cWzoJ:people.apache.org/~jorton/svn.merge+=1=en=clnk=us

It's good for the crude but effective gmail archive searches.

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Yann Ylavic]

tl;dr
I like commit messages :)

On Wed, Mar 2, 2016 at 3:31 PM, Stefan Eissing
 wrote:
> I can do that. However - smartass mode on - if one uses the actual
> "svn merge -c NNN,NNN", subversion will track that and
>
>   svn mergeinfo --show-revs merged ^/httpd/httpd/trunk .
>
> in a 2.4.x checkout will show it.

The command above is nice but does not show the 2.4.x revision the
trunk one I'm looking for is merged into.

Eg., for this current merge, the relevant output is:


r1732252 | jailletc36 | 2016-02-25 07:51:13 +0100 (Thu, 25 Feb 2016) | 1 line

Save a few bytes in conf pool when parsing 'DefaultRuntimeDir' directive.

r1732353 | jailletc36 | 2016-02-25 20:49:21 +0100 (Thu, 25 Feb 2016) | 1 line

Save a few bytes in conf pool when parsing 'DocumentRoot' directive on some OS.

r1732369 | jailletc36 | 2016-02-25 22:00:46 +0100 (Thu, 25 Feb 2016) | 1 line

Save a few bytes in conf pool when parsing 'Mutex' directive on some OS.


but I can't find any r1733279 there, and had to look at the original
STATUS' change:

-  *) Save a few bytes in conf pool when parsing some directives
- Trunk patch:
- http://svn.apache.org/r1732252
- http://svn.apache.org/r1732353
- http://svn.apache.org/r1732369
- 2.4.x patch:
- Trunk version of patch works
- +1: jailletc36, ylavic, icing

to figure out.

I often have to search for a particular commit revision, mainly in my
mailbox (cvs@), to find out what's related, and for this the commit
message helps a lot ;)

But I agree that I may not be svn expert enough to find the right
command by myself...

The online viewvc's "Revision Log" does not show the svn properties
too, useful tool when you don't have you working copy (or svn) at
hand.

> But I am not trying to change existing
> practise here that works.

Honestly I didn't really know it was a required practice (is it?),
just always seen it in merge messages and found it useful, so just
proposed...

> And with pre-supplied 2.4 patches, this
> information might not be there - depends how it was created.

Right, it should/must? be in STATUS "Trunk patch(es):" though, if
referring to a real trunk commit at least (this helps finding and
commenting the original commit on review too).


No strict opinion on all that though, my personal use of commit
messages may be abusive, and if the information I need is missing,
well I'll find it some other way...

Regards,
Yann.

PS: I don't like too much top posting too :p
There seems to be two "real" schools here, so I adapt...

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Stefan Eissing]

I will add the revision numbers to the log when merging - no problem. 
You are correct that things can only work when everyone follows common 
practise, or - lacking knowledge - learns to do so.

-Stefan

> Am 02.03.2016 um 16:15 schrieb William A Rowe Jr :
> 
> On Wed, Mar 2, 2016 at 8:31 AM, Stefan Eissing  
> wrote:
> I can do that. However - smartass mode on - if one uses the actual
> "svn merge -c NNN,NNN", subversion will track that and
> 
>   svn mergeinfo --show-revs merged ^/httpd/httpd/trunk .
> 
> in a 2.4.x checkout will show it. But I am not trying to change existing
> practise here that works. And with pre-supplied 2.4 patches, this
> information might not be there - depends how it was created.
> 
> Counter-smart-ass reply; while dealing in email/commit history through
> viewvc and similar, the svn:mergeinfo is similarly clear and easily
> reviewed. I follow both practices, svn merge for the summary you are
> looking at above, combined with a log message that can be followed 
> by a later reviewer or troubleshooter.
> 
> Please do stick with practice and follow the svn conventions in use here?
> Those are always up for discussion but should be discussed and even
> more-so agreed upon on the dev list.  That includes attribution plus PR 
> and revision references in the commit log text (and CVE references, but
> we will often edit those logs after a security release has been shipped
> as not to call attention to the side-effects of a bug fix too quickly).
> 
> 

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[William A Rowe Jr]

On Wed, Mar 2, 2016 at 8:31 AM, Stefan Eissing  wrote:

> I can do that. However - smartass mode on - if one uses the actual
> "svn merge -c NNN,NNN", subversion will track that and
>
>   svn mergeinfo --show-revs merged ^/httpd/httpd/trunk .
>
> in a 2.4.x checkout will show it. But I am not trying to change existing
> practise here that works. And with pre-supplied 2.4 patches, this
> information might not be there - depends how it was created.
>

Counter-smart-ass reply; while dealing in email/commit history through
viewvc and similar, the svn:mergeinfo is similarly clear and easily
reviewed. I follow both practices, svn merge for the summary you are
looking at above, combined with a log message that can be followed
by a later reviewer or troubleshooter.

Please do stick with practice and follow the svn conventions in use here?
Those are always up for discussion but should be discussed and even
more-so agreed upon on the dev list.  That includes attribution plus PR
and revision references in the commit log text (and CVE references, but
we will often edit those logs after a security release has been shipped
as not to call attention to the side-effects of a bug fix too quickly).

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Stefan Eissing]

I can do that. However - smartass mode on - if one uses the actual 
"svn merge -c NNN,NNN", subversion will track that and 

  svn mergeinfo --show-revs merged ^/httpd/httpd/trunk .

in a 2.4.x checkout will show it. But I am not trying to change existing
practise here that works. And with pre-supplied 2.4 patches, this 
information might not be there - depends how it was created.

-Stefan

> Am 02.03.2016 um 15:05 schrieb Yann Ylavic :
> 
> On Wed, Mar 2, 2016 at 2:10 PM,   wrote:
>> Author: icing
>> Date: Wed Mar  2 13:10:05 2016
>> New Revision: 1733279
>> 
>> URL: http://svn.apache.org/viewvc?rev=1733279=rev
>> Log:
>> backport
> 
> We should try to reference the backported (trunk) revisions in the
> commit messages.
> Otherwise it could be hard later to figure which commit was backported
> (or not), and we sometimes need to search by revision number (either
> in revision logs, or even gg)...

Re: svn commit: r1733279 - in /httpd/httpd/branches/2.4.x: ./ STATUS server/core.c server/util_mutex.c

[Yann Ylavic]

On Wed, Mar 2, 2016 at 2:10 PM,   wrote:
> Author: icing
> Date: Wed Mar  2 13:10:05 2016
> New Revision: 1733279
>
> URL: http://svn.apache.org/viewvc?rev=1733279=rev
> Log:
> backport

We should try to reference the backported (trunk) revisions in the
commit messages.
Otherwise it could be hard later to figure which commit was backported
(or not), and we sometimes need to search by revision number (either
in revision logs, or even gg)...

Re: mod_proxy_http2

[Stefan Eissing]

> Am 02.03.2016 um 13:04 schrieb Jim Jagielski :
> 
> I think if we could get mod_proxy_http2 and mod_proxy_hcheck into
> the next 2.4.x release, we would really, really be Happy.
> 
> :)

Totally agreed. I'll try to finish up some rough edges on proxy_http2 and then 
make a proposal.

> 
>> On Mar 2, 2016, at 6:25 AM, Stefan Eissing  
>> wrote:
>> 
>> Yeah, that's what I thought. I just wanted to test the water temperature...
>> 
>>> Am 02.03.2016 um 12:22 schrieb Jim Jagielski :
>>> 
>>> I would think that it is not covered under the http2 exception
>>> and would require a backport proposal and vote...
>>> 
 On Mar 2, 2016, at 5:06 AM, Stefan Eissing  
 wrote:
 
 to backport or not to backport that is the question. opinions?
>>> 
>> 
> 

Re: mod_proxy_http2

[Jim Jagielski]

I think if we could get mod_proxy_http2 and mod_proxy_hcheck into
the next 2.4.x release, we would really, really be Happy.

:)

> On Mar 2, 2016, at 6:25 AM, Stefan Eissing  
> wrote:
> 
> Yeah, that's what I thought. I just wanted to test the water temperature...
> 
>> Am 02.03.2016 um 12:22 schrieb Jim Jagielski :
>> 
>> I would think that it is not covered under the http2 exception
>> and would require a backport proposal and vote...
>> 
>>> On Mar 2, 2016, at 5:06 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> to backport or not to backport that is the question. opinions?
>> 
> 

Re: mod_proxy_http2

[Stefan Eissing]

Yeah, that's what I thought. I just wanted to test the water temperature...

> Am 02.03.2016 um 12:22 schrieb Jim Jagielski :
> 
> I would think that it is not covered under the http2 exception
> and would require a backport proposal and vote...
> 
>> On Mar 2, 2016, at 5:06 AM, Stefan Eissing  
>> wrote:
>> 
>> to backport or not to backport that is the question. opinions?
> 

Re: conn_rec needs a context

[Stefan Eissing]

+1

> Am 02.03.2016 um 12:21 schrieb Jim Jagielski :
> 
> 
>> On Mar 1, 2016, at 7:09 PM, Graham Leggett  wrote:
>> 
>> Hi all,
>> 
>> In order to get connections to have async behaviour, it must be possible for 
>> the process_connection hook to exit in the expectation of being called again 
>> when an async mpm is present - this is easy, the mpms already do that.
>> 
>> The missing bit is that conn_rec needs a context so that when is is called a 
>> second time it knows what state it is in.
>> 
>> There is a void *ctx variable that was added in r1565657, but I’m not sure 
>> it is enough.
>> 
>> Would it make sense to add a vector of contexts that same way we have a 
>> vector of configs, one slot for each module, which will allow any module to 
>> add a context of it’s own to conn_rec without having to extend conn_rec?
>> 
>> It would be nice to have the same for requests, for the same reason.
>> 
> 
> Makes sense to me...
> 

Re: mod_proxy_http2

[Jim Jagielski]

I would think that it is not covered under the http2 exception
and would require a backport proposal and vote...

> On Mar 2, 2016, at 5:06 AM, Stefan Eissing  
> wrote:
> 
> to backport or not to backport that is the question. opinions?

Re: conn_rec needs a context

[Jim Jagielski]

> On Mar 1, 2016, at 7:09 PM, Graham Leggett  wrote:
> 
> Hi all,
> 
> In order to get connections to have async behaviour, it must be possible for 
> the process_connection hook to exit in the expectation of being called again 
> when an async mpm is present - this is easy, the mpms already do that.
> 
> The missing bit is that conn_rec needs a context so that when is is called a 
> second time it knows what state it is in.
> 
> There is a void *ctx variable that was added in r1565657, but I’m not sure it 
> is enough.
> 
> Would it make sense to add a vector of contexts that same way we have a 
> vector of configs, one slot for each module, which will allow any module to 
> add a context of it’s own to conn_rec without having to extend conn_rec?
> 
> It would be nice to have the same for requests, for the same reason.
> 

Makes sense to me...

mod_proxy_http2

[Stefan Eissing]

to backport or not to backport that is the question. opinions?

Re: mod_speling changes in trunk and backport

[Rainer Jung]

Am 02.03.2016 um 08:03 schrieb Christophe JAILLET:

Le 23/02/2016 20:24, Rainer Jung a écrit :

There were two changes to mod_speling in trunk in 2013/2014. They were
motivated by PR 44221: although the docs claim that using
"CheckCaseOnly On" "limits the action of the spelling correction to
lower/upper case changes. Other potential corrections are not
performed." In fact mod_speling still checks for content files which
only differ in the file name suffix form the request URI. That part of
the code was contained in an #ifdef but active by default. The changes
introduce a new directive that allows to control that part of the
behavior by configuration.

Now the question: it seems to me that due to the change being done in
two steps, now the directive CheckCaseOnly and the new one
CheckBasenameMatch are not independent of each other. Setting
CheckBasenameMatch  to "On" only enables the suffix handling if
CheckCaseOnly if "Off". For improved compatibility and for better
orthogonality I would suggest to keep the features separate from each
other, ie.:

Index: modules/mappers/mod_speling.c
===
--- modules/mappers/mod_speling.c   (revision 1731929)
+++ modules/mappers/mod_speling.c   (working copy)
@@ -326,8 +326,7 @@
  * because it won't find anything matching that spelling.
  * With the extension-munging, it would locate "foobar.html".
  */
-else if ((cfg->check_case_only == 0) &&
- (cfg->check_basename_match == 1)) {
+else if (cfg->check_basename_match == 1) {
 /*
  * Okay... we didn't find anything. Now we take out the
hard-core
  * power tools. There are several cases here. Someone
might have


That way the old changes could be ported back to 2.4 with the only
change that the default for CheckBasenameMatch would be "On" in 2.4
for compatibility reasons and "Off" in trunk to satisfy the principle
of least surprise.

Regards,

Rainer


Hi,

One other remark from Eric at the time being [1] was that is also
changed the legacy behavior.
Having CheckBasenameMatch default to 1 (at least for 2.4.x) would keep
compatibility with existing config.

Keeping the 2 options independent would also require a tweak in the doc.

CJ

[1]
http://mail-archives.apache.org/mod_mbox/httpd-cvs/201401.mbox/%3c20140128052621.21f912388...@eris.apache.org%3E


I already tweaked the trunk docs (hopefully understandable) and indeed 
plan to backport with a different default for CheckBasenameMatch.


I haven't yet proposed the backport, because I don't like that 
mod_speling has no merge code for the config. IMHO that means if a 
config has a hierarchy of mod_speling settings, non-set values will 
always be reset to their defaults in the non-merging. I plan to add 
merging using a "set" flag.


Regards,

Rainer