expected_path_prefix defined in http endpoint renamed to rule_path_ma…

…tch_prefix

docs/content/docs/configuration/rules/providers.adoc

@@ -70,7 +70,7 @@ Whether the configured `endpoints` should be polled for updates. Defaults to `0s
 +
 Each entry of that array supports all the properties defined by link:{{< relref "/docs/configuration/reference/configuration_types.adoc#_endpoint" >}}[Endpoint], except `method`, which is always `GET`. As with the link:{{< relref "/docs/configuration/reference/configuration_types.adoc#_endpoint" >}}[Endpoint] type, at least the `url` must be defined. Following properties are defined in addition:
 +
-** *`expected_path_prefix`*: _string_ (optional)
+** *`rule_path_match_prefix`*: _string_ (optional)
 +
 This property can be used to create kind of a namespace for the rule sets retrieved from the different endpoints. If set, the provider checks whether the urls specified in all rules retrieved from the referenced endpoint have the defined path prefix. If not, a warning is emitted and the rule set is ignored. This can be used to ensure a rule retrieved from one endpoint does not collide with a rule from another endpoint.
 
@@ -95,17 +95,17 @@ Here, the provider is configured to poll the two defined rule set endpoints for
 
 The configuration for the first endpoint instructs heimdall to ensure all urls defined in the rules coming from that endpoint must match the defined path prefix.
 
-The configuration for the second endpoint defines the `expected_path_prefix` as well. It also defines a couple of other properties. One to ensure the communication to that endpoint is more resilient by setting the `retry` options and since this endpoint is protected by an API key, it defines the corresponding options as well.
+The configuration for the second endpoint defines the `rule_path_match_prefix` as well. It also defines a couple of other properties. One to ensure the communication to that endpoint is more resilient by setting the `retry` options and since this endpoint is protected by an API key, it defines the corresponding options as well.
 
 [source, yaml]
 ----
 http_endpoint:
   watch_interval: 5m
   endpoints:
     - url: http://foo.bar/ruleset1
-      expected_path_prefix: /foo/bar
+      rule_path_match_prefix: /foo/bar
     - url: http://foo.bar/ruleset2
-      expected_path_prefix: /bar/foo
+      rule_path_match_prefix: /bar/foo
       retry:
         give_up_after: 5s
         max_delay: 250ms

internal/config/test_data/test_config.yaml

@@ -275,7 +275,7 @@ rules:
       watch_interval: 5m
       endpoints:
         - url: http://foo.bar/rules.yaml
-          expected_path_prefix: /foo
+          rule_path_match_prefix: /foo
         - url: http://bar.foo/rules.yaml
           headers:
             bla: bla

internal/rules/provider/httpendpoint/ruleset_endpoint.go

@@ -18,7 +18,7 @@ import (
 type ruleSetEndpoint struct {
 	endpoint.Endpoint `mapstructure:",squash"`
 
-	RulesPathPrefix pathprefix.PathPrefix `mapstructure:"expected_path_prefix"`
+	RulesPathPrefix pathprefix.PathPrefix `mapstructure:"rule_path_match_prefix"`
 }
 
 func (e *ruleSetEndpoint) ID() string { return e.URL }

schema/config.schema.json

@@ -343,7 +343,7 @@
             }
           ]
         },
-        "expected_path_prefix": {
+        "rule_path_match_prefix": {
           "description": "The path prefix to be checked in each rule retrieved from the endpoint",
           "type": "string",
           "examples": [

test_config.yaml

@@ -177,7 +177,7 @@ rules:
       watch_interval: 5m
       endpoints:
         - url: http://foo.bar/rules.yaml
-          expected_path_prefix: /foo
+          rule_path_match_prefix: /foo
         - url: http://bar.foo/rules.yaml
           headers:
             bla: bla