git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v1 0/2] urlmatch: allow regexp-based matches

From
Patrick Steinhardt <patrick.steinhardt@elego.de>
Date
Jan 24, 2017, 11:29 UTC
Message-ID
<20170124112952.GA2603@pks-pc>
In-Reply-To
<xmqqsho9r1rs.fsf@gitster.mtv.corp.google.com>
On Mon, Jan 23, 2017 at 11:53:43AM -0800, Junio C Hamano wrote:
Show 30 quoted lines
> Patrick Steinhardt <patrick.steinhardt@elego.de> writes:
> 
> > This patch is mostly a request for comments. The use case is to
> > be able to configure an HTTP proxy for all subdomains of a
> > certain domain where there are hundreds of subdomains. The most
> > flexible way I could imagine was by using regular expressions for
> > the matching, which is how I implemented it for now. So users can
> > now create a configuration key like
> > `http.?http://.*\\.example\\.com.*` to apply settings for all
> > subdomains of `example.com`.
> 
> While reading 2/2, I got an impression that this is "too" flexible
> and possibly operates at a wrong level.  I would have expected that
> the wildcarding to be limited to the host part only and hook into
> match_urls(), allowing the users of the new feature to still take
> advantage of the existing support of "http://me@example.com" that
> limits the match to the case that the connection is authenticated
> for a user, for example, by newly allowing "http://me@*.example.com"
> or something like that.
> 
> Because you cannot have a literal '*' in your hostname, I would
> imagine that supporting a match pattern "http://me@*.example.com"
> would be already backward compatible without requiring a leading
> question-mark.
> 
> I also personally would prefer these textual matching to be done
> with glob not with regexp, by the way, as the above description of
> mine shows.
> 
> Thanks.

Thanks for your feedback. Using globs in the hostname only was my first intent, as well. I later on took regular expressions instead so as to allow further flexibility for the user. The reasoning was that there might be other use cases which cannot actually be solved with using globs only, even if I myself wasn't aware of different ones. So this might be indeed over-engineered when using regular expressions.

There are several questions though regarding semantics with globs, where I'd like to have additional opinions on.

- should a glob only be allowed for actual subdomains, allowing
  "http://*.example.com" but not "http://*example.com"?
- should a glob also match multiple nestings of subdomains? E.g.
  "http://*.example.com" would match "http://foo.example.com" but
  not "http://foo.bar.example.com"?
I'll send a version 2 soon-ish.

Regards Patrick

Previous: Junio C HamanoNext: Patrick Steinhardt
Message 5 of 12 in “urlmatch: allow regexp-based matches”
  1. 0/2 urlmatch: allow regexp-based matchesPatrick Steinhardt, Jan 23, 2017
  2. 2/2 urlmatch: allow regex-based URL matchingPatrick Steinhardt, Jan 23, 2017
  3. 1/2 mailmap: add Patrick Steinhardt's work addressPatrick Steinhardt, Jan 23, 2017
  4. Junio C HamanoJan 23, 2017
  5. Patrick SteinhardtJan 24, 2017
  6. 0/4 urlmatch: allow regexp-based matchesPatrick Steinhardt, Jan 24, 2017
  7. 1/4 mailmap: add Patrick Steinhardt's work addressPatrick Steinhardt, Jan 24, 2017
  8. 2/4 urlmatch: enable normalization of URLs with globsPatrick Steinhardt, Jan 24, 2017
  9. 3/4 urlmatch: split host and port fields in `struct url_info`Patrick Steinhardt, Jan 24, 2017
  10. 4/4 urlmatch: allow globbing for the URL host partPatrick Steinhardt, Jan 24, 2017
  11. Philip OakleyJan 24, 2017
  12. Patrick SteinhardtJan 25, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.