conformance: Coverage for request routing to TLSRoute with no valid BackendRefs

[sunjayBhatia]

What would you like to be added:

As a follow up to https://github.com/kubernetes-sigs/gateway-api/pull/2076, we should add test coverage to the TLSRoute test in that PR that makes an assertion on what a client sees when making a connection/request that match a Gateway/TLSRoute with no valid backends (due to invalid ReferenceGrant etc.)

Before we add a test, the language here likely needs a little more specificity (and we should make sure to write tests that match the new language), particularly what "reject" means: https://github.com/kubernetes-sigs/gateway-api/blob/a5ede12430c31639349ae6c00666890591f72a40/apis/v1alpha2/tlsroute_types.go#L104-L108

"Reject" could mean:

• Connection refused, so nothing listening on the relevant Gateway Listener port (probably not the right answer, since you could have multiple hostnames for the same port)
• Server sends TCP RST (what Envoy/Contour will do if there the Listener port is open but no proxying set up)
• Specific TLS error (seems less likely to be uniform across all implementors)
• other ideas welcome

Why this is needed:

Full coverage of TLSRoute API surface.

Related to https://github.com/kubernetes-sigs/gateway-api/issues/1579

We can probably do something similar for TCPRoute

[shaneutt]

Sounds like a reasonable improvement.

/triage accepted

Given that this is about TLSRoute, it seems like something we can do after our GA release.

/priority backlog

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale