1. 15 Jan, 2015 1 commit
  2. 31 Jul, 2013 2 commits
    • Junio C Hamano's avatar
      config: add generic callback wrapper to parse section.<url>.key · 836b6fb5
      Junio C Hamano authored
      Existing configuration parsing functions (e.g. http_options() in
      http.c) know how to parse two-level configuration variable names.
      We would like to exploit them and parse something like this:
      
      	[http]
      		sslVerify = true
      	[http "https://weak.example.com"]
      		sslVerify = false
      
      and pretend as if http.sslVerify were set to false when talking to
      "https://weak.example.com/path".
      
      Introduce `urlmatch_config_entry()` wrapper that:
      
       - is called with the target URL (e.g. "https://weak.example.com/path"),
         and the two-level variable parser (e.g. `http_options`);
      
       - uses `url_normalize()` and `match_urls()` to see if configuration
         data matches the target URL; and
      
       - calls the traditional two-level configuration variable parser
         only for the configuration data whose <url> part matches the
         target URL (and if there are multiple matches, only do so if the
         current match is a better match than the ones previously seen).
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      836b6fb5
    • Kyle J. McKay's avatar
      config: add helper to normalize and match URLs · 3402a8dc
      Kyle J. McKay authored
      Some http.* configuration variables need to take values customized
      for the URL we are talking to.  We may want to set http.sslVerify to
      true in general but to false only for a certain site, for example,
      with a configuration file like this:
      
      	[http]
      		sslVerify = true
      	[http "https://weak.example.com"]
      		sslVerify = false
      
      and let the configuration machinery pick up the latter only when
      talking to "https://weak.example.com".  The latter needs to kick in
      not only when the URL is exactly "https://weak.example.com", but
      also is anything that "match" it, e.g.
      
      	https://weak.example.com/test
      	https://me@weak.example.com/test
      
      The <url> in the configuration key consists of the following parts,
      and is considered a match to the URL we are attempting to access
      under certain conditions:
      
        . Scheme (e.g., `https` in `https://example.com/`). This field
          must match exactly between the config key and the URL.
      
        . Host/domain name (e.g., `example.com` in `https://example.com/`).
          This field must match exactly between the config key and the URL.
      
        . Port number (e.g., `8080` in `http://example.com:8080/`).  This
          field must match exactly between the config key and the URL.
          Omitted port numbers are automatically converted to the correct
          default for the scheme before matching.
      
        . Path (e.g., `repo.git` in `https://example.com/repo.git`). The
          path field of the config key must match the path field of the
          URL either exactly or as a prefix of slash-delimited path
          elements.  A config key with path `foo/` matches URL path
          `foo/bar`.  A prefix can only match on a slash (`/`) boundary.
          Longer matches take precedence (so a config key with path
          `foo/bar` is a better match to URL path `foo/bar` than a config
          key with just path `foo/`).
      
        . User name (e.g., `me` in `https://me@example.com/repo.git`). If
          the config key has a user name, it must match the user name in
          the URL exactly. If the config key does not have a user name,
          that config key will match a URL with any user name (including
          none), but at a lower precedence than a config key with a user
          name.
      
      Longer matches take precedence over shorter matches.
      
      This step adds two helper functions `url_normalize()` and
      `match_urls()` to help implement the above semantics. The
      normalization rules are based on RFC 3986 and should result in any
      two equivalent urls being a match.
      Signed-off-by: default avatarKyle J. McKay <mackyle@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      3402a8dc