Skip to content

Commit 055c241

Browse files
committed
Expand and clarify Listeners definition
Explicitly define Listener compatibility as definitively routable and allowed on the same address by the implementation. Narrow language about collapsing compatible Listeners to mean assigning multiple Gateways the same addresses if their Listeners are compatible, Expand Listeners examples to include mixed TCP and UDP and indicate that they are not compatible if an implementation does not support that combination. Add language about Gateway-level conditions for incompatible Listeners.
1 parent 1dca4af commit 055c241

File tree

1 file changed

+44
-30
lines changed

1 file changed

+44
-30
lines changed

apis/v1beta1/gateway_types.go

Lines changed: 44 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -85,38 +85,52 @@ type GatewaySpec struct {
8585
//
8686
// Port and protocol combinations not listed above are considered Extended.
8787
//
88-
// An implementation MAY group Listeners by Port and then collapse each
89-
// group of Listeners into a single Listener if the implementation
90-
// determines that the Listeners in the group are "compatible". An
91-
// implementation MAY also group together and collapse compatible
92-
// Listeners belonging to different Gateways.
93-
//
94-
// For example, an implementation might consider Listeners to be
95-
// compatible with each other if all of the following conditions are
96-
// met:
97-
//
98-
// 1. Either each Listener within the group specifies the "HTTP"
99-
// Protocol or each Listener within the group specifies either
100-
// the "HTTPS" or "TLS" Protocol.
101-
//
102-
// 2. Each Listener within the group specifies a Hostname that is unique
103-
// within the group.
104-
//
105-
// 3. As a special case, one Listener within a group may omit Hostname,
106-
// in which case this Listener matches when no other Listener
107-
// matches.
108-
//
109-
// If the implementation does collapse compatible Listeners, the
110-
// hostname provided in the incoming client request MUST be
111-
// matched to a Listener to find the correct set of Routes.
112-
// The incoming hostname MUST be matched using the Hostname
113-
// field for each Listener in order of most to least specific.
114-
// That is, exact matches must be processed before wildcard
88+
// A Gateway's Listeners are considered "compatible" if:
89+
//
90+
// 1. The implementation can serve them in compliance with the Addresses
91+
// requirement that all Listeners are available on all assigned
92+
// addresses.
93+
// 2. No Listeners sharing the same Port share the same Hostname value,
94+
// including the empty value, if this would prevent the implementation
95+
// from matching an inbound request to a specific Listener.
96+
//
97+
// Compatible combinations in Extended support are expected to vary across
98+
// implementations. A combination that is compatible for one implementation
99+
// may not be compatible for another.
100+
//
101+
// If this field specifies multiple Listeners that are not compatible, the
102+
// implementation MUST raise a true "Conflicted" condition in the Listener
103+
// Status.
104+
//
105+
// Implementations MAY choose to still accept a Gateway with conflicted
106+
// Listeners if they accept a partial Listener set that contains no
107+
// incompatible Listeners. They MUST set a "ListenersNotValid" condition
108+
// the Gateway Status when the Gateway contains incompatible Listeners
109+
// whether or not they accept the Gateway.
110+
//
111+
// For example, the following Listener scenarios may be compatible
112+
// depending on implementation capabilities:
113+
//
114+
// 1. Multiple Listeners with the same Port that all use the "HTTP"
115+
// Protocol that all have unique Hostname values.
116+
// 2. Multiple Listeners with the same Port that use either the "HTTPS" or
117+
// "TLS" Protocol that all have unique Hostname values.
118+
// 3. A mixture of "TCP" and "UDP" Protocol Listeners, where no Listener
119+
// with the same Protocol has the same Port value.
120+
//
121+
// An implementation that cannot serve both TCP and UDP listens on the same
122+
// address, or cannot mix HTTPS and generic TLS listens on the same port
123+
// would not consider those cases compatible.
124+
//
125+
// Implementations using the Hostname value to select between same-Port
126+
// Listeners MUST match inbound request hostnames from the most specific
127+
// to least specific Hostname values to find the correct set of Routes.
128+
// Exact matches must be processed before wildcard matches, and wildcard
129+
// matches must be processed before fallback (empty Hostname value)
115130
// matches.
116131
//
117-
// If this field specifies multiple Listeners that have the same
118-
// Port value but are not compatible, the implementation must raise
119-
// a "Conflicted" condition in the Listener status.
132+
// Implementations MAY collapse separate Gateways onto a single set of
133+
// Addresses if the Listeners across all Gateways are compatible.
120134
//
121135
// Support: Core
122136
//

0 commit comments

Comments
 (0)