Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of jkaluza@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <5450CD01.7040503@redhat.com>
Date: Wed, 29 Oct 2014 12:18:25 +0100
From: =?UTF-8?B?SmFuIEthbHXFvmE=?= <jkaluza@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Fix DirectoryMatch to not match regular files?
Content-Type: multipart/mixed;
 boundary="------------040209040904050003010401"

This is a multi-part message in MIME format.
--------------040209040904050003010401
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I was trying to fix PR41867 using attached patch. While the patch seems 
to work, I'm thinking if the behaviour change introduced by the patch 
can bring some problems.

Currently, "<DirectoryMatch ^/var/www/html/private>" matches also 
"/var/www/html/private.txt" even it is a regular file and not a 
directory. With the patch, DirectoryMatch won't match "private.txt" in 
this case, because it's a file.

While I think this is excepted behaviour of DirectoryMatch, I'm not sure 
if it's acceptable change in 2.4.x branch (or even trunk?). What do you 
think?

Regards,
Jan Kaluza

--------------040209040904050003010401
Content-Type: application/x-download;
 name="httpd-trunk-directorymatch-no-files-match.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="httpd-trunk-directorymatch-no-files-match.patch"

SW5kZXg6IGluY2x1ZGUvaHR0cF9jb3JlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaW5jbHVkZS9o
dHRwX2NvcmUuaAkocmV2aXNpb24gMTYzMzA4MykKKysrIGluY2x1ZGUvaHR0cF9jb3JlLmgJ
KHdvcmtpbmcgY29weSkKQEAgLTYxOSw2ICs2MTksNyBAQAogCiAgICAgdW5zaWduZWQgaW50
IGFsbG93X2VuY29kZWRfc2xhc2hlc19zZXQgOiAxOwogICAgIHVuc2lnbmVkIGludCBkZWNv
ZGVfZW5jb2RlZF9zbGFzaGVzX3NldCA6IDE7CisgICAgdW5zaWduZWQgaW50IGRfaXNfZGly
ZWN0b3J5IDogMTsKIAogICAgIC8qKiBOYW1lZCBiYWNrIHJlZmVyZW5jZXMgKi8KICAgICBh
cHJfYXJyYXlfaGVhZGVyX3QgKnJlZnM7CkluZGV4OiBzZXJ2ZXIvY29yZS5jCj09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KLS0tIHNlcnZlci9jb3JlLmMJKHJldmlzaW9uIDE2MzMwODMpCisrKyBzZXJ2ZXIv
Y29yZS5jCSh3b3JraW5nIGNvcHkpCkBAIC0yMjI0LDYgKzIyMjQsNyBAQAogICAgIGNvbmYt
PnIgPSByOwogICAgIGNvbmYtPmQgPSBjbWQtPnBhdGg7CiAgICAgY29uZi0+ZF9pc19mbm1h
dGNoID0gKGFwcl9mbm1hdGNoX3Rlc3QoY29uZi0+ZCkgIT0gMCk7CisgICAgY29uZi0+ZF9p
c19kaXJlY3RvcnkgPSAxOwogCiAgICAgaWYgKHIpIHsKICAgICAgICAgY29uZi0+cmVmcyA9
IGFwcl9hcnJheV9tYWtlKGNtZC0+cG9vbCwgOCwgc2l6ZW9mKGNoYXIgKikpOwpJbmRleDog
c2VydmVyL3JlcXVlc3QuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzZXJ2ZXIvcmVxdWVzdC5jCShy
ZXZpc2lvbiAxNjMzMDgzKQorKysgc2VydmVyL3JlcXVlc3QuYwkod29ya2luZyBjb3B5KQpA
QCAtMTIxNiw2ICsxMjE2LDEzIEBACiAgICAgICAgICAgICAgICAgcG1hdGNoID0gYXByX3Bh
bGxvYyhyeHBvb2wsIG5tYXRjaCpzaXplb2YoYXBfcmVnbWF0Y2hfdCkpOwogICAgICAgICAg
ICAgfQogCisgICAgICAgICAgICAvKiBjb3JlX2Rpcl9jb25maWcgaXMgRGlyZWN0b3J5Kiwg
YnV0IHRoZSByZXF1ZXN0ZWQgZmlsZSBpcworICAgICAgICAgICAgICogbm90IGEgZGlyZWN0
b3J5LCBzbyBhbHRob3VnaCB0aGUgcmVnZXhwIGNvdWxkIG1hdGNoLAorICAgICAgICAgICAg
ICogd2Ugc2tpcCBpdC4gKi8KKyAgICAgICAgICAgIGlmIChlbnRyeV9jb3JlLT5kX2lzX2Rp
cmVjdG9yeSAmJiByLT5maW5mby5maWxldHlwZSAhPSBBUFJfRElSKSB7CisgICAgICAgICAg
ICAgICAgY29udGludWU7CisgICAgICAgICAgICB9CisKICAgICAgICAgICAgIGlmIChhcF9y
ZWdleGVjKGVudHJ5X2NvcmUtPnIsIHItPmZpbGVuYW1lLCBubWF0Y2gsIHBtYXRjaCwgMCkp
IHsKICAgICAgICAgICAgICAgICBjb250aW51ZTsKICAgICAgICAgICAgIH0K
--------------040209040904050003010401--