On 2021-11-30 at 07:33:25, Jeff King wrote:
> On Mon, Nov 29, 2021 at 06:16:54PM -0800, Junio C Hamano wrote:
> 
> > --------------------------------------------------
> > [Graduated to 'master']
> >
> > [...]
> > * jk/loosen-urlmatch (2021-10-12) 1 commit
> >   (merged to 'next' on 2021-10-25 at f66ca39ebe)
> >  + urlmatch: add underscore to URL_HOST_CHARS
> > 
> >  Treat "_" as any other URL-valid characters in an URL when matching
> >  the per-URL configuration variable names.
> 
> Sorry, I hadn't noticed that this one had even made it to 'next', and
> was surprised to see it graduate.
> 
> I think brian corrected my assertion in the commit message that RFC 1738
> says that underscores are OK. They are for URIs in general, but not the
> specific case of hostnames in HTTP schemes.

From my memory of the research I did, they're okay for URIs according to
the grammar, but they're acceptable only if you're using something that
isn't DNS, which as a practical matter is never the case.

> Now that isn't strictly a reason to drop the patch. Even though
> underscores aren't allowed, they do work in some limited circumstances,
> and curl is happy to take them. So in some sense this is harmonizing our
> urlmatch behavior with curl for an iffy-but-workable practice, and there
> may be value in that. But it does take us further away from the
> standards, which could possibly have surprising consequences down the
> road.
> 
> I don't have a strong feeling either way on reverting it at this point.
> But I wanted to make sure that if we kept it in, we were doing so
> consciously, and not just because folks involved in the discussion
> didn't realize it was still working its way through the process.

I don't think it's necessarily worth reverting, but we should avoid
continuing to make further improvements in this area.  In other words,
we shouldn't take this as an opportunity to support more of this.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA