Re: Wildcard URL config matching

[Patrick Steinhardt <patrick.steinhardt@elego.de>]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

Hi Brian,

On Mon, Nov 05, 2018 at 08:56:52PM +0000, brian m. carlson wrote:
> In a272b9e70a ("urlmatch: allow globbing for the URL host part",
> 2017-01-31), we added support for wildcard matching for URLs when
> reading from .git/config.  Now it's possible to specify an option like
> http.http://*.example.com/.cookieFile and have it match for the URL
> http://foo.example.com.  However, since this option also allows
> wildcards at any level, the following also matches:
> http.http://*.*.*/.cookieFile.
> 
> I'm wondering if it was intentional to allow this behavior or if we
> intended to allow only the leftmost label (or labels) to be a wildcard.
> The tests seem to test only the leftmost label, and that is the behavior
> that one has for TLS certificates, for example.  I don't really see a
> situation where one would want to match hostname labels in an arbitrary
> position, but perhaps I'm simply not being imaginative enough in
> thinking through the use cases.

The behavior is intentional. The above example of "http://*.*.*/"
obviously doesn't make a lot of sense, but e.g. the pattern
"http://*.*.example.com" should match all sub-sub domains of
"example.com" like for example "http://foo.bar.example.com". The
ability to use multiple globs is necessary as they aren't "true"
globs, but will only match the current component of the subdomain
separated by dots. So they behave similar to globs in the shell,
where they only match up to the next directory separator.

If we were to remove the ability to use globs for multiple
components, then one would have to again explicitly list patterns
for all possible combinations.

> Regardless of what we decide, I'll be sending a patch, either to add
> additional tests, or correct the code (or both).

I agree that there should've been additional tests to also verify
that multiple globs work as expected. So thanks for doing that!

> I ask because we're implementing this behavior for Git LFS, where we
> don't iterate over all configuration keys, instead looking up certain
> values in a hash.  We'll need to make some changes in order to have
> things work correctly if we want to implement the current Git behavior
> to prevent combinatorial explosion.

Regards
Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]