-
Notifications
You must be signed in to change notification settings - Fork 5.1k
http conn man: Introduce host simplification rules #40874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
e6f6f9d
3bd0d82
024a9e2
1cae50f
880b39c
f6b40c3
4a37f22
0926cca
6eb0a2d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ package envoy.config.route.v3; | |
import "envoy/config/core/v3/base.proto"; | ||
import "envoy/config/core/v3/config_source.proto"; | ||
import "envoy/config/route/v3/route_components.proto"; | ||
import "envoy/type/matcher/v3/regex.proto"; | ||
|
||
import "google/protobuf/any.proto"; | ||
import "google/protobuf/wrappers.proto"; | ||
|
@@ -23,7 +24,7 @@ option (udpa.annotations.file_status).package_version_status = ACTIVE; | |
// * Routing :ref:`architecture overview <arch_overview_http_routing>` | ||
// * HTTP :ref:`router filter <config_http_filters_router>` | ||
|
||
// [#next-free-field: 18] | ||
// [#next-free-field: 19] | ||
message RouteConfiguration { | ||
option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.RouteConfiguration"; | ||
|
||
|
@@ -155,6 +156,34 @@ message RouteConfiguration { | |
// For instance, if the metadata is intended for the Router filter, | ||
// the filter name should be specified as ``envoy.filters.http.router``. | ||
core.v3.Metadata metadata = 17; | ||
|
||
// The host simplification rules are a set of regex substitutions | ||
// that can modify the :authority used when matching | ||
// VirtualHosts. It will not change what is sent upstream. This can | ||
// be used to implement multiple-wildcard matching, by converting | ||
// all but one of the wildcards into a static string. | ||
// This is similar to ignore_port_in_host_matching (above), but more flexible. | ||
// To use this, at least one simplification rule must be configured, | ||
// and then a | ||
// :ref:`envoy_v3_api_msg_config.route.v3.VirtualHost`.domains field | ||
// must be set to match the results of the simplification rule. | ||
// An example may help: | ||
// > host_simplification_rules: | ||
// > - pattern: | ||
// > regex: "^(foo)[.]([^.]+)[.](example[.]org)$" | ||
// > substitution: \1.bar.\3 | ||
// will allow a HTTP request with an :authority header of | ||
// 'foo.anything.example.org' or 'foo.something.example.org' to both | ||
// be matched by a VirtualHost with a domain entry of | ||
// 'foo.bar.example.org', due to the second label in the domain | ||
// being replaced by the simplification rule to 'bar'. | ||
pugmajere marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// If multiple rules are provided, they are processed in order. The | ||
// results of the first rule will be used by the second rule, and so | ||
// on. It is unlikely that you want to depend on this behavior, | ||
// however, due to the potential for confusion. It is recommended | ||
// that, if you need multiple simplification rules, they should be | ||
// as independent of each other as possible. | ||
repeated type.matcher.v3.RegexMatchAndSubstitute host_simplification_rules = 18; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This could benefit from an example I think. regexes are pretty hard to understand (for most people), and we need to give some guidance. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, that's fair. I wrote more words, though I'm unsure on how the formatting will work out. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I also slightly improved the example from the one I used in the tests by putting the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What will happens if there are multiple rules? Will the final result will be used to find vhost or every rule's result will be used one by one? And at least give it a meaning for name like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. final result; I think the updated comments explain that better now, at least. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about |
||
} | ||
|
||
message Vhds { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember seeing some discussions about the disadvantages of using general-regex matching (for non-prefix/non-suffix) use-cases, but I cannot recall the details, and whether it was related to host-matching.
cc @yanavlasov @mattklein123 may have more context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw a proposal a while back about using
domain_regex
as a list in virtual hosts; this is arguably somewhat similar, but hopefully done in a way that the host matching algorithm itself can be changed to use alternate structures (a trie comes to mind, for example), where a list of regexs in the virtualhosts doesn't allow that.