From 56f980890fa809aee5d6c5c146cace1bce476eb1 Mon Sep 17 00:00:00 2001 From: Dave Protasowski Date: Thu, 25 May 2023 17:23:10 -0400 Subject: [PATCH 1/4] define core protocol/port combinations --- apis/v1beta1/gateway_types.go | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/apis/v1beta1/gateway_types.go b/apis/v1beta1/gateway_types.go index 6eb7cf4eca..003f9f2b7d 100644 --- a/apis/v1beta1/gateway_types.go +++ b/apis/v1beta1/gateway_types.go @@ -70,7 +70,12 @@ type GatewaySpec struct { // At least one Listener MUST be specified. // // Each listener in a Gateway must have a unique combination of Hostname, - // Port, and Protocol. + // Port, and Protocol. Combinations that are considered Core are: + // + // 1. Port: 80, Protocol: HTTP + // 2. Port: 443, Protocol: HTTPS + // + // Port and protocol combinations not in this list are considered Extended. // // An implementation MAY group Listeners by Port and then collapse each // group of Listeners into a single Listener if the implementation From cee9cc925e72e42046c02cffc81c68d56decf04c Mon Sep 17 00:00:00 2001 From: Dave Protasowski Date: Thu, 25 May 2023 17:27:01 -0400 Subject: [PATCH 2/4] Update codegen --- .../gateway.networking.k8s.io_gateways.yaml | 90 ++++++++++--------- .../gateway.networking.k8s.io_gateways.yaml | 90 ++++++++++--------- 2 files changed, 96 insertions(+), 84 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml index 089f8c5c96..04fb5d1e91 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml @@ -108,27 +108,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - \n An implementation MAY group Listeners by Port and then collapse - each group of Listeners into a single Listener if the implementation - determines that the Listeners in the group are \"compatible\". An - implementation MAY also group together and collapse compatible Listeners - belonging to different Gateways. \n For example, an implementation - might consider Listeners to be compatible with each other if all - of the following conditions are met: \n 1. Either each Listener - within the group specifies the \"HTTP\" Protocol or each Listener - within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. - \n 2. Each Listener within the group specifies a Hostname that is - unique within the group. \n 3. As a special case, one Listener within - a group may omit Hostname, in which case this Listener matches when - no other Listener matches. \n If the implementation does collapse - compatible Listeners, the hostname provided in the incoming client - request MUST be matched to a Listener to find the correct set of - Routes. The incoming hostname MUST be matched using the Hostname - field for each Listener in order of most to least specific. That - is, exact matches must be processed before wildcard matches. \n - If this field specifies multiple Listeners that have the same Port - value but are not compatible, the implementation must raise a \"Conflicted\" - condition in the Listener status. \n Support: Core" + Combinations that are considered Core are: \n 1. Port: 80, Protocol: + HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations + not in this list are considered Extended. \n An implementation MAY + group Listeners by Port and then collapse each group of Listeners + into a single Listener if the implementation determines that the + Listeners in the group are \"compatible\". An implementation MAY + also group together and collapse compatible Listeners belonging + to different Gateways. \n For example, an implementation might consider + Listeners to be compatible with each other if all of the following + conditions are met: \n 1. Either each Listener within the group + specifies the \"HTTP\" Protocol or each Listener within the group + specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener + within the group specifies a Hostname that is unique within the + group. \n 3. As a special case, one Listener within a group may + omit Hostname, in which case this Listener matches when no other + Listener matches. \n If the implementation does collapse compatible + Listeners, the hostname provided in the incoming client request + MUST be matched to a Listener to find the correct set of Routes. + The incoming hostname MUST be matched using the Hostname field for + each Listener in order of most to least specific. That is, exact + matches must be processed before wildcard matches. \n If this field + specifies multiple Listeners that have the same Port value but are + not compatible, the implementation must raise a \"Conflicted\" condition + in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. @@ -811,27 +814,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - \n An implementation MAY group Listeners by Port and then collapse - each group of Listeners into a single Listener if the implementation - determines that the Listeners in the group are \"compatible\". An - implementation MAY also group together and collapse compatible Listeners - belonging to different Gateways. \n For example, an implementation - might consider Listeners to be compatible with each other if all - of the following conditions are met: \n 1. Either each Listener - within the group specifies the \"HTTP\" Protocol or each Listener - within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. - \n 2. Each Listener within the group specifies a Hostname that is - unique within the group. \n 3. As a special case, one Listener within - a group may omit Hostname, in which case this Listener matches when - no other Listener matches. \n If the implementation does collapse - compatible Listeners, the hostname provided in the incoming client - request MUST be matched to a Listener to find the correct set of - Routes. The incoming hostname MUST be matched using the Hostname - field for each Listener in order of most to least specific. That - is, exact matches must be processed before wildcard matches. \n - If this field specifies multiple Listeners that have the same Port - value but are not compatible, the implementation must raise a \"Conflicted\" - condition in the Listener status. \n Support: Core" + Combinations that are considered Core are: \n 1. Port: 80, Protocol: + HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations + not in this list are considered Extended. \n An implementation MAY + group Listeners by Port and then collapse each group of Listeners + into a single Listener if the implementation determines that the + Listeners in the group are \"compatible\". An implementation MAY + also group together and collapse compatible Listeners belonging + to different Gateways. \n For example, an implementation might consider + Listeners to be compatible with each other if all of the following + conditions are met: \n 1. Either each Listener within the group + specifies the \"HTTP\" Protocol or each Listener within the group + specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener + within the group specifies a Hostname that is unique within the + group. \n 3. As a special case, one Listener within a group may + omit Hostname, in which case this Listener matches when no other + Listener matches. \n If the implementation does collapse compatible + Listeners, the hostname provided in the incoming client request + MUST be matched to a Listener to find the correct set of Routes. + The incoming hostname MUST be matched using the Hostname field for + each Listener in order of most to least specific. That is, exact + matches must be processed before wildcard matches. \n If this field + specifies multiple Listeners that have the same Port value but are + not compatible, the implementation must raise a \"Conflicted\" condition + in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. diff --git a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml index 4334414ac7..b82874e7ab 100644 --- a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml @@ -108,27 +108,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - \n An implementation MAY group Listeners by Port and then collapse - each group of Listeners into a single Listener if the implementation - determines that the Listeners in the group are \"compatible\". An - implementation MAY also group together and collapse compatible Listeners - belonging to different Gateways. \n For example, an implementation - might consider Listeners to be compatible with each other if all - of the following conditions are met: \n 1. Either each Listener - within the group specifies the \"HTTP\" Protocol or each Listener - within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. - \n 2. Each Listener within the group specifies a Hostname that is - unique within the group. \n 3. As a special case, one Listener within - a group may omit Hostname, in which case this Listener matches when - no other Listener matches. \n If the implementation does collapse - compatible Listeners, the hostname provided in the incoming client - request MUST be matched to a Listener to find the correct set of - Routes. The incoming hostname MUST be matched using the Hostname - field for each Listener in order of most to least specific. That - is, exact matches must be processed before wildcard matches. \n - If this field specifies multiple Listeners that have the same Port - value but are not compatible, the implementation must raise a \"Conflicted\" - condition in the Listener status. \n Support: Core" + Combinations that are considered Core are: \n 1. Port: 80, Protocol: + HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations + not in this list are considered Extended. \n An implementation MAY + group Listeners by Port and then collapse each group of Listeners + into a single Listener if the implementation determines that the + Listeners in the group are \"compatible\". An implementation MAY + also group together and collapse compatible Listeners belonging + to different Gateways. \n For example, an implementation might consider + Listeners to be compatible with each other if all of the following + conditions are met: \n 1. Either each Listener within the group + specifies the \"HTTP\" Protocol or each Listener within the group + specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener + within the group specifies a Hostname that is unique within the + group. \n 3. As a special case, one Listener within a group may + omit Hostname, in which case this Listener matches when no other + Listener matches. \n If the implementation does collapse compatible + Listeners, the hostname provided in the incoming client request + MUST be matched to a Listener to find the correct set of Routes. + The incoming hostname MUST be matched using the Hostname field for + each Listener in order of most to least specific. That is, exact + matches must be processed before wildcard matches. \n If this field + specifies multiple Listeners that have the same Port value but are + not compatible, the implementation must raise a \"Conflicted\" condition + in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. @@ -811,27 +814,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - \n An implementation MAY group Listeners by Port and then collapse - each group of Listeners into a single Listener if the implementation - determines that the Listeners in the group are \"compatible\". An - implementation MAY also group together and collapse compatible Listeners - belonging to different Gateways. \n For example, an implementation - might consider Listeners to be compatible with each other if all - of the following conditions are met: \n 1. Either each Listener - within the group specifies the \"HTTP\" Protocol or each Listener - within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. - \n 2. Each Listener within the group specifies a Hostname that is - unique within the group. \n 3. As a special case, one Listener within - a group may omit Hostname, in which case this Listener matches when - no other Listener matches. \n If the implementation does collapse - compatible Listeners, the hostname provided in the incoming client - request MUST be matched to a Listener to find the correct set of - Routes. The incoming hostname MUST be matched using the Hostname - field for each Listener in order of most to least specific. That - is, exact matches must be processed before wildcard matches. \n - If this field specifies multiple Listeners that have the same Port - value but are not compatible, the implementation must raise a \"Conflicted\" - condition in the Listener status. \n Support: Core" + Combinations that are considered Core are: \n 1. Port: 80, Protocol: + HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations + not in this list are considered Extended. \n An implementation MAY + group Listeners by Port and then collapse each group of Listeners + into a single Listener if the implementation determines that the + Listeners in the group are \"compatible\". An implementation MAY + also group together and collapse compatible Listeners belonging + to different Gateways. \n For example, an implementation might consider + Listeners to be compatible with each other if all of the following + conditions are met: \n 1. Either each Listener within the group + specifies the \"HTTP\" Protocol or each Listener within the group + specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener + within the group specifies a Hostname that is unique within the + group. \n 3. As a special case, one Listener within a group may + omit Hostname, in which case this Listener matches when no other + Listener matches. \n If the implementation does collapse compatible + Listeners, the hostname provided in the incoming client request + MUST be matched to a Listener to find the correct set of Routes. + The incoming hostname MUST be matched using the Hostname field for + each Listener in order of most to least specific. That is, exact + matches must be processed before wildcard matches. \n If this field + specifies multiple Listeners that have the same Port value but are + not compatible, the implementation must raise a \"Conflicted\" condition + in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. From c135a342d5051e55ccc0fde4a91bb403eacfbe3c Mon Sep 17 00:00:00 2001 From: Dave Protasowski Date: Fri, 26 May 2023 09:30:54 -0400 Subject: [PATCH 3/4] Reword clause and include MUST requirement --- apis/v1beta1/gateway_types.go | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/apis/v1beta1/gateway_types.go b/apis/v1beta1/gateway_types.go index 003f9f2b7d..2c8548cfac 100644 --- a/apis/v1beta1/gateway_types.go +++ b/apis/v1beta1/gateway_types.go @@ -70,7 +70,8 @@ type GatewaySpec struct { // At least one Listener MUST be specified. // // Each listener in a Gateway must have a unique combination of Hostname, - // Port, and Protocol. Combinations that are considered Core are: + // Port, and Protocol. Below combinations are considered Core and MUST be + // supported: // // 1. Port: 80, Protocol: HTTP // 2. Port: 443, Protocol: HTTPS From 7ad2d5f1846dfdacfa5245615f0d9f4bff0ba19c Mon Sep 17 00:00:00 2001 From: Dave Protasowski Date: Fri, 26 May 2023 10:36:06 -0400 Subject: [PATCH 4/4] run ./hack/update-codegen.sh --- .../gateway.networking.k8s.io_gateways.yaml | 96 +++++++++---------- .../gateway.networking.k8s.io_gateways.yaml | 96 +++++++++---------- 2 files changed, 96 insertions(+), 96 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml index 04fb5d1e91..9d9958c4b5 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_gateways.yaml @@ -108,30 +108,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - Combinations that are considered Core are: \n 1. Port: 80, Protocol: - HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations - not in this list are considered Extended. \n An implementation MAY - group Listeners by Port and then collapse each group of Listeners - into a single Listener if the implementation determines that the - Listeners in the group are \"compatible\". An implementation MAY - also group together and collapse compatible Listeners belonging - to different Gateways. \n For example, an implementation might consider - Listeners to be compatible with each other if all of the following - conditions are met: \n 1. Either each Listener within the group - specifies the \"HTTP\" Protocol or each Listener within the group - specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener - within the group specifies a Hostname that is unique within the - group. \n 3. As a special case, one Listener within a group may - omit Hostname, in which case this Listener matches when no other - Listener matches. \n If the implementation does collapse compatible - Listeners, the hostname provided in the incoming client request - MUST be matched to a Listener to find the correct set of Routes. - The incoming hostname MUST be matched using the Hostname field for - each Listener in order of most to least specific. That is, exact - matches must be processed before wildcard matches. \n If this field - specifies multiple Listeners that have the same Port value but are - not compatible, the implementation must raise a \"Conflicted\" condition - in the Listener status. \n Support: Core" + Below combinations are considered Core and MUST be supported: \n + 1. Port: 80, Protocol: HTTP 2. Port: 443, Protocol: HTTPS \n Port + and protocol combinations not in this list are considered Extended. + \n An implementation MAY group Listeners by Port and then collapse + each group of Listeners into a single Listener if the implementation + determines that the Listeners in the group are \"compatible\". An + implementation MAY also group together and collapse compatible Listeners + belonging to different Gateways. \n For example, an implementation + might consider Listeners to be compatible with each other if all + of the following conditions are met: \n 1. Either each Listener + within the group specifies the \"HTTP\" Protocol or each Listener + within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. + \n 2. Each Listener within the group specifies a Hostname that is + unique within the group. \n 3. As a special case, one Listener within + a group may omit Hostname, in which case this Listener matches when + no other Listener matches. \n If the implementation does collapse + compatible Listeners, the hostname provided in the incoming client + request MUST be matched to a Listener to find the correct set of + Routes. The incoming hostname MUST be matched using the Hostname + field for each Listener in order of most to least specific. That + is, exact matches must be processed before wildcard matches. \n + If this field specifies multiple Listeners that have the same Port + value but are not compatible, the implementation must raise a \"Conflicted\" + condition in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. @@ -814,30 +814,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - Combinations that are considered Core are: \n 1. Port: 80, Protocol: - HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations - not in this list are considered Extended. \n An implementation MAY - group Listeners by Port and then collapse each group of Listeners - into a single Listener if the implementation determines that the - Listeners in the group are \"compatible\". An implementation MAY - also group together and collapse compatible Listeners belonging - to different Gateways. \n For example, an implementation might consider - Listeners to be compatible with each other if all of the following - conditions are met: \n 1. Either each Listener within the group - specifies the \"HTTP\" Protocol or each Listener within the group - specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener - within the group specifies a Hostname that is unique within the - group. \n 3. As a special case, one Listener within a group may - omit Hostname, in which case this Listener matches when no other - Listener matches. \n If the implementation does collapse compatible - Listeners, the hostname provided in the incoming client request - MUST be matched to a Listener to find the correct set of Routes. - The incoming hostname MUST be matched using the Hostname field for - each Listener in order of most to least specific. That is, exact - matches must be processed before wildcard matches. \n If this field - specifies multiple Listeners that have the same Port value but are - not compatible, the implementation must raise a \"Conflicted\" condition - in the Listener status. \n Support: Core" + Below combinations are considered Core and MUST be supported: \n + 1. Port: 80, Protocol: HTTP 2. Port: 443, Protocol: HTTPS \n Port + and protocol combinations not in this list are considered Extended. + \n An implementation MAY group Listeners by Port and then collapse + each group of Listeners into a single Listener if the implementation + determines that the Listeners in the group are \"compatible\". An + implementation MAY also group together and collapse compatible Listeners + belonging to different Gateways. \n For example, an implementation + might consider Listeners to be compatible with each other if all + of the following conditions are met: \n 1. Either each Listener + within the group specifies the \"HTTP\" Protocol or each Listener + within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. + \n 2. Each Listener within the group specifies a Hostname that is + unique within the group. \n 3. As a special case, one Listener within + a group may omit Hostname, in which case this Listener matches when + no other Listener matches. \n If the implementation does collapse + compatible Listeners, the hostname provided in the incoming client + request MUST be matched to a Listener to find the correct set of + Routes. The incoming hostname MUST be matched using the Hostname + field for each Listener in order of most to least specific. That + is, exact matches must be processed before wildcard matches. \n + If this field specifies multiple Listeners that have the same Port + value but are not compatible, the implementation must raise a \"Conflicted\" + condition in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. diff --git a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml index b82874e7ab..ad4b556e2f 100644 --- a/config/crd/standard/gateway.networking.k8s.io_gateways.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_gateways.yaml @@ -108,30 +108,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - Combinations that are considered Core are: \n 1. Port: 80, Protocol: - HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations - not in this list are considered Extended. \n An implementation MAY - group Listeners by Port and then collapse each group of Listeners - into a single Listener if the implementation determines that the - Listeners in the group are \"compatible\". An implementation MAY - also group together and collapse compatible Listeners belonging - to different Gateways. \n For example, an implementation might consider - Listeners to be compatible with each other if all of the following - conditions are met: \n 1. Either each Listener within the group - specifies the \"HTTP\" Protocol or each Listener within the group - specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener - within the group specifies a Hostname that is unique within the - group. \n 3. As a special case, one Listener within a group may - omit Hostname, in which case this Listener matches when no other - Listener matches. \n If the implementation does collapse compatible - Listeners, the hostname provided in the incoming client request - MUST be matched to a Listener to find the correct set of Routes. - The incoming hostname MUST be matched using the Hostname field for - each Listener in order of most to least specific. That is, exact - matches must be processed before wildcard matches. \n If this field - specifies multiple Listeners that have the same Port value but are - not compatible, the implementation must raise a \"Conflicted\" condition - in the Listener status. \n Support: Core" + Below combinations are considered Core and MUST be supported: \n + 1. Port: 80, Protocol: HTTP 2. Port: 443, Protocol: HTTPS \n Port + and protocol combinations not in this list are considered Extended. + \n An implementation MAY group Listeners by Port and then collapse + each group of Listeners into a single Listener if the implementation + determines that the Listeners in the group are \"compatible\". An + implementation MAY also group together and collapse compatible Listeners + belonging to different Gateways. \n For example, an implementation + might consider Listeners to be compatible with each other if all + of the following conditions are met: \n 1. Either each Listener + within the group specifies the \"HTTP\" Protocol or each Listener + within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. + \n 2. Each Listener within the group specifies a Hostname that is + unique within the group. \n 3. As a special case, one Listener within + a group may omit Hostname, in which case this Listener matches when + no other Listener matches. \n If the implementation does collapse + compatible Listeners, the hostname provided in the incoming client + request MUST be matched to a Listener to find the correct set of + Routes. The incoming hostname MUST be matched using the Hostname + field for each Listener in order of most to least specific. That + is, exact matches must be processed before wildcard matches. \n + If this field specifies multiple Listeners that have the same Port + value but are not compatible, the implementation must raise a \"Conflicted\" + condition in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections. @@ -814,30 +814,30 @@ spec: logical endpoints that are bound on this Gateway's addresses. At least one Listener MUST be specified. \n Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. - Combinations that are considered Core are: \n 1. Port: 80, Protocol: - HTTP 2. Port: 443, Protocol: HTTPS \n Port and protocol combinations - not in this list are considered Extended. \n An implementation MAY - group Listeners by Port and then collapse each group of Listeners - into a single Listener if the implementation determines that the - Listeners in the group are \"compatible\". An implementation MAY - also group together and collapse compatible Listeners belonging - to different Gateways. \n For example, an implementation might consider - Listeners to be compatible with each other if all of the following - conditions are met: \n 1. Either each Listener within the group - specifies the \"HTTP\" Protocol or each Listener within the group - specifies either the \"HTTPS\" or \"TLS\" Protocol. \n 2. Each Listener - within the group specifies a Hostname that is unique within the - group. \n 3. As a special case, one Listener within a group may - omit Hostname, in which case this Listener matches when no other - Listener matches. \n If the implementation does collapse compatible - Listeners, the hostname provided in the incoming client request - MUST be matched to a Listener to find the correct set of Routes. - The incoming hostname MUST be matched using the Hostname field for - each Listener in order of most to least specific. That is, exact - matches must be processed before wildcard matches. \n If this field - specifies multiple Listeners that have the same Port value but are - not compatible, the implementation must raise a \"Conflicted\" condition - in the Listener status. \n Support: Core" + Below combinations are considered Core and MUST be supported: \n + 1. Port: 80, Protocol: HTTP 2. Port: 443, Protocol: HTTPS \n Port + and protocol combinations not in this list are considered Extended. + \n An implementation MAY group Listeners by Port and then collapse + each group of Listeners into a single Listener if the implementation + determines that the Listeners in the group are \"compatible\". An + implementation MAY also group together and collapse compatible Listeners + belonging to different Gateways. \n For example, an implementation + might consider Listeners to be compatible with each other if all + of the following conditions are met: \n 1. Either each Listener + within the group specifies the \"HTTP\" Protocol or each Listener + within the group specifies either the \"HTTPS\" or \"TLS\" Protocol. + \n 2. Each Listener within the group specifies a Hostname that is + unique within the group. \n 3. As a special case, one Listener within + a group may omit Hostname, in which case this Listener matches when + no other Listener matches. \n If the implementation does collapse + compatible Listeners, the hostname provided in the incoming client + request MUST be matched to a Listener to find the correct set of + Routes. The incoming hostname MUST be matched using the Hostname + field for each Listener in order of most to least specific. That + is, exact matches must be processed before wildcard matches. \n + If this field specifies multiple Listeners that have the same Port + value but are not compatible, the implementation must raise a \"Conflicted\" + condition in the Listener status. \n Support: Core" items: description: Listener embodies the concept of a logical endpoint where a Gateway accepts network connections.