Skip to content

httproute: pluralize hostname and allow for wildcards #214

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jun 24, 2020
Merged

httproute: pluralize hostname and allow for wildcards #214

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
309 changes: 159 additions & 150 deletions api/v1alpha1/generated.pb.go
View file
Open in desktop

Large diffs are not rendered by default.

28 changes: 20 additions & 8 deletions api/v1alpha1/generated.proto
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

28 changes: 20 additions & 8 deletions api/v1alpha1/httproute_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,26 +31,38 @@ type HTTPRouteSpec struct {
Default *HTTPRouteHost `json:"default" protobuf:"bytes,2,opt,name=default"`
}

// HTTPRouteHost is the configuration for a given host.
// HTTPRouteHost is the configuration for a given set of hosts.
type HTTPRouteHost struct {
// Hostnames defines a set of hostname that should match against
// the HTTP Host header to select a HTTPRoute to process a the request.
// Hostname is the fully qualified domain name of a network host,
// as defined by RFC 3986. Note the following deviations from the
// "host" part of the URI as defined in the RFC:
//
// 1. IPs are not allowed.
// 2. The `:` delimiter is not respected because ports are not allowed.
//
// Incoming requests are matched against Hostname before processing HTTPRoute
// rules. For example, if the request header contains host: foo.example.com,
// an HTTPRoute with hostname foo.example.com will match. However, an
// HTTPRoute with hostname example.com or bar.example.com will not match.
// If Hostname is unspecified, the Gateway routes all traffic based on
// the specified rules.
// Incoming requests are matched against the hostnames before the
// HTTPRoute rules. If no hostname is specified, traffic is routed
// based on the HTTPRouteRules.
//
// Hostname can be "precise" which is a domain name without the terminating
// dot of a network host (e.g. "foo.example.com") or "wildcard", which is
// a domain name prefixed with a single wildcard label (e.g. "*.example.com").
// The wildcard character '*' must appear by itself as the first DNS
// label and matches only a single label.
// You cannot have a wildcard label by itself (e.g. Host == "*").
// Requests will be matched against the Host field in the following order:
// 1. If Host is precise, the request matches this rule if
// the http host header is equal to Host.
// 2. If Host is a wildcard, then the request matches this rule if
// the http host header is to equal to the suffix
// (removing the first label) of the wildcard rule.
//
// Support: Core
//
// +optional
Hostname string `json:"hostname,omitempty" protobuf:"bytes,1,opt,name=hostname"`
Hostnames []string `json:"hostnames,omitempty" protobuf:"bytes,1,opt,name=hostnames"`

// Rules are a list of HTTP matchers, filters and actions.
Rules []HTTPRouteRule `json:"rules" protobuf:"bytes,2,rep,name=rules"`
Expand Down
5 changes: 5 additions & 0 deletions api/v1alpha1/zz_generated.deepcopy.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

74 changes: 50 additions & 24 deletions config/crd/bases/networking.x-k8s.io_httproutes.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,19 +79,31 @@ spec:
- name
- resource
type: object
hostname:
description: "Hostname is the fully qualified domain name of a
network host, as defined by RFC 3986. Note the following deviations
from the \"host\" part of the URI as defined in the RFC: \n
1. IPs are not allowed. 2. The `:` delimiter is not respected
because ports are not allowed. \n Incoming requests are matched
against Hostname before processing HTTPRoute rules. For example,
if the request header contains host: foo.example.com, an HTTPRoute
with hostname foo.example.com will match. However, an HTTPRoute
with hostname example.com or bar.example.com will not match.
If Hostname is unspecified, the Gateway routes all traffic based
on the specified rules. \n Support: Core"
type: string
hostnames:
description: "Hostnames defines a set of hostname that should
match against the HTTP Host header to select a HTTPRoute to
process a the request. Hostname is the fully qualified domain
name of a network host, as defined by RFC 3986. Note the following
deviations from the \"host\" part of the URI as defined in the
RFC: \n 1. IPs are not allowed. 2. The `:` delimiter is not
respected because ports are not allowed. \n Incoming requests
are matched against the hostnames before the HTTPRoute rules.
If no hostname is specified, traffic is routed based on the
HTTPRouteRules. \n Hostname can be \"precise\" which is a domain
name without the terminating dot of a network host (e.g. \"foo.example.com\")
or \"wildcard\", which is a domain name prefixed with a single
wildcard label (e.g. \"*.example.com\"). The wildcard character
'*' must appear by itself as the first DNS label and matches
only a single label. You cannot have a wildcard label by itself
(e.g. Host == \"*\"). Requests will be matched against the Host
field in the following order: 1. If Host is precise, the request
matches this rule if the http host header is equal to Host.
2. If Host is a wildcard, then the request matches this rule
if the http host header is to equal to the suffix (removing
the first label) of the wildcard rule. \n Support: Core"
items:
type: string
type: array
rules:
description: Rules are a list of HTTP matchers, filters and actions.
items:
Expand Down Expand Up @@ -369,7 +381,8 @@ spec:
hosts:
description: Hosts is a list of Host definitions.
items:
description: HTTPRouteHost is the configuration for a given host.
description: HTTPRouteHost is the configuration for a given set
of hosts.
properties:
extensionRef:
description: "ExtensionRef is an optional, implementation-specific
Expand Down Expand Up @@ -410,19 +423,32 @@ spec:
- name
- resource
type: object
hostname:
description: "Hostname is the fully qualified domain name of
a network host, as defined by RFC 3986. Note the following
hostnames:
description: "Hostnames defines a set of hostname that should
match against the HTTP Host header to select a HTTPRoute to
process a the request. Hostname is the fully qualified domain
name of a network host, as defined by RFC 3986. Note the following
deviations from the \"host\" part of the URI as defined in
the RFC: \n 1. IPs are not allowed. 2. The `:` delimiter is
not respected because ports are not allowed. \n Incoming requests
are matched against Hostname before processing HTTPRoute rules.
For example, if the request header contains host: foo.example.com,
an HTTPRoute with hostname foo.example.com will match. However,
an HTTPRoute with hostname example.com or bar.example.com
will not match. If Hostname is unspecified, the Gateway routes
all traffic based on the specified rules. \n Support: Core"
type: string
are matched against the hostnames before the HTTPRoute rules.
If no hostname is specified, traffic is routed based on the
HTTPRouteRules. \n Hostname can be \"precise\" which is a
domain name without the terminating dot of a network host
(e.g. \"foo.example.com\") or \"wildcard\", which is a domain
name prefixed with a single wildcard label (e.g. \"*.example.com\").
The wildcard character '*' must appear by itself as the first
DNS label and matches only a single label. You cannot have
a wildcard label by itself (e.g. Host == \"*\"). Requests
will be matched against the Host field in the following order:
1. If Host is precise, the request matches this rule if the
http host header is equal to Host. 2. If Host is a wildcard,
then the request matches this rule if the http host header
is to equal to the suffix (removing the first label) of
the wildcard rule. \n Support: Core"
items:
type: string
type: array
rules:
description: Rules are a list of HTTP matchers, filters and
actions.
Expand Down
31 changes: 21 additions & 10 deletions docs-src/spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1486,7 +1486,7 @@ that includes the HTTPRoute will be true.</p>
<a href="#networking.x-k8s.io/v1alpha1.HTTPRouteSpec">HTTPRouteSpec</a>)
</p>
<p>
<p>HTTPRouteHost is the configuration for a given host.</p>
<p>HTTPRouteHost is the configuration for a given set of hosts.</p>
</p>
<table>
<thead>
Expand All @@ -1498,26 +1498,37 @@ that includes the HTTPRoute will be true.</p>
<tbody>
<tr>
<td>
<code>hostname</code></br>
<code>hostnames</code></br>
<em>
string
[]string
</em>
</td>
<td>
<em>(Optional)</em>
<p>Hostname is the fully qualified domain name of a network host,
<p>Hostnames defines a set of hostname that should match against
the HTTP Host header to select a HTTPRoute to process a the request.
Hostname is the fully qualified domain name of a network host,
as defined by RFC 3986. Note the following deviations from the
&ldquo;host&rdquo; part of the URI as defined in the RFC:</p>
<ol>
<li>IPs are not allowed.</li>
<li>The <code>:</code> delimiter is not respected because ports are not allowed.</li>
</ol>
<p>Incoming requests are matched against Hostname before processing HTTPRoute
rules. For example, if the request header contains host: foo.example.com,
an HTTPRoute with hostname foo.example.com will match. However, an
HTTPRoute with hostname example.com or bar.example.com will not match.
If Hostname is unspecified, the Gateway routes all traffic based on
the specified rules.</p>
<p>Incoming requests are matched against the hostnames before the
HTTPRoute rules. If no hostname is specified, traffic is routed
based on the HTTPRouteRules.</p>
<p>Hostname can be &ldquo;precise&rdquo; which is a domain name without the terminating
dot of a network host (e.g. &ldquo;foo.example.com&rdquo;) or &ldquo;wildcard&rdquo;, which is
a domain name prefixed with a single wildcard label (e.g. &ldquo;<em>.example.com&rdquo;).
The wildcard character &lsquo;</em>&rsquo; must appear by itself as the first DNS
label and matches only a single label.
You cannot have a wildcard label by itself (e.g. Host == &ldquo;*&rdquo;).
Requests will be matched against the Host field in the following order:
1. If Host is precise, the request matches this rule if
the http host header is equal to Host.
2. If Host is a wildcard, then the request matches this rule if
the http host header is to equal to the suffix
(removing the first label) of the wildcard rule.</p>
<p>Support: Core</p>
</td>
</tr>
Expand Down
35 changes: 23 additions & 12 deletions docs/spec/index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1811,7 +1811,7 @@ <h3 id="networking.x-k8s.io/v1alpha1.HTTPRouteHost">HTTPRouteHost
<a href="#networking.x-k8s.io/v1alpha1.HTTPRouteSpec">HTTPRouteSpec</a>)
</p>
<p>
<p>HTTPRouteHost is the configuration for a given host.</p>
<p>HTTPRouteHost is the configuration for a given set of hosts.</p>
</p>
<table>
<thead>
Expand All @@ -1823,26 +1823,37 @@ <h3 id="networking.x-k8s.io/v1alpha1.HTTPRouteHost">HTTPRouteHost
<tbody>
<tr>
<td>
<code>hostname</code></br>
<code>hostnames</code></br>
<em>
string
[]string
</em>
</td>
<td>
<em>(Optional)</em>
<p>Hostname is the fully qualified domain name of a network host,
<p>Hostnames defines a set of hostname that should match against
the HTTP Host header to select a HTTPRoute to process a the request.
Hostname is the fully qualified domain name of a network host,
as defined by RFC 3986. Note the following deviations from the
&ldquo;host&rdquo; part of the URI as defined in the RFC:</p>
<ol>
<li>IPs are not allowed.</li>
<li>The <code>:</code> delimiter is not respected because ports are not allowed.</li>
</ol>
<p>Incoming requests are matched against Hostname before processing HTTPRoute
rules. For example, if the request header contains host: foo.example.com,
an HTTPRoute with hostname foo.example.com will match. However, an
HTTPRoute with hostname example.com or bar.example.com will not match.
If Hostname is unspecified, the Gateway routes all traffic based on
the specified rules.</p>
<p>Incoming requests are matched against the hostnames before the
HTTPRoute rules. If no hostname is specified, traffic is routed
based on the HTTPRouteRules.</p>
<p>Hostname can be &ldquo;precise&rdquo; which is a domain name without the terminating
dot of a network host (e.g. &ldquo;foo.example.com&rdquo;) or &ldquo;wildcard&rdquo;, which is
a domain name prefixed with a single wildcard label (e.g. &ldquo;<em>.example.com&rdquo;).
The wildcard character &lsquo;</em>&rsquo; must appear by itself as the first DNS
label and matches only a single label.
You cannot have a wildcard label by itself (e.g. Host == &ldquo;<em>&rdquo;).
Requests will be matched against the Host field in the following order:
1. If Host is precise, the request matches this rule if
the http host header is equal to Host.
2. If Host is a wildcard, then the request matches this rule if
the http host header is to equal to the suffix
(removing the first label) of the wildcard rule.</p>
<p>Support: Core</p>
</td>
</tr>
Expand Down Expand Up @@ -2340,7 +2351,7 @@ <h3 id="networking.x-k8s.io/v1alpha1.ListenerAddress">ListenerAddress
</em>
</td>
<td>
<p>Type of the Address. This is one of the <em>AddressType constants.</p>
<p>Type of the Address. This is one of the </em>AddressType constants.</p>
<p>Support: Extended</p>
</td>
</tr>
Expand Down Expand Up @@ -2802,7 +2813,7 @@ <h3 id="networking.x-k8s.io/v1alpha1.TLSConfig">TLSConfig
<td>
<em>(Optional)</em>
<p>MinimumVersion of TLS allowed. It is recommended to use one of
the TLS<em></em> constants above. Note: MinimumVersion is not strongly
the TLS<em>* constants above. Note: MinimumVersion is not strongly
typed to allow implementation-specific versions to be used without
requiring updates to the API types. String must be of the form
&ldquo;<protocol><major></em><minor>&rdquo;.</p>
Expand Down