Skip to content

api: add detectMisdirectedRequests to EnvoyProxy - #9675

Open
mmmommm wants to merge 2 commits into
envoyproxy:mainfrom
mmmommm:feat/detect-misdirected-requests-api
Open

api: add detectMisdirectedRequests to EnvoyProxy#9675
mmmommm wants to merge 2 commits into
envoyproxy:mainfrom
mmmommm:feat/detect-misdirected-requests-api

Conversation

@mmmommm

@mmmommm mmmommm commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:

This is part 1 of 3 for #5879, adding API support for GEP-3567 misdirected request detection.

This PR adds the detectMisdirectedRequests field to EnvoyProxy and updates the generated API artifacts.

Follow-up PRs will add:

  1. The IR/xDS implementation that returns 421 responses when the feature is enabled.
  2. Conformance test enablement for HTTPRouteHTTPSListenerDetectMisdirectedRequests.

The field defaults to disabled, and this PR does not change runtime behavior. The implementation is intentionally left for a follow-up PR so this PR can focus on the API
shape: field name, type, placement, and documentation.

Which issue(s) this PR fixes:

Fixes #5879


PR Checklist

  • Authorship & ownership: Coding agents / AI assistants are welcome, but I have reviewed every change, understand how and why it works, can explain and maintain it, and take full responsibility for this PR. I have not submitted generated output I do not understand.
  • DCO: All commits are signed off (git commit -s). See DCO: Sign your work.
  • API agreed first: If this PR contains API changes (changes under /api), the API was discussed and agreed before the implementation. The API change can be in a separate PR, or in the same PR, but the API must be agreed before implementation. N/A if this PR does not contain API changes.
  • Required checks pass: make generate gen-check, make lint, and the unit-test/coverage build pass. (Flaky e2e failures are not considered breakages, but gen-check, lint, and coverage MUST pass.)
  • Tests added/updated: New/changed code is covered by appropriate tests. N/A if this PR does not contain code changes.
  • Docs: User-facing changes update the docs, either in this PR or a follow-up PR. N/A if this PR does not contain user-facing changes.
  • Release notes: For any non-trivial change, added a release-note fragment under release-notes/current/<section>/<pr-number>-<slug>.md (see release-notes/current/README.md for sections and naming). N/A if this PR does not contain non-trivial changes.
  • Generated files committed: Ran make gen-check and committed the result if API/helm charts/modules changed.
  • Scope & compatibility: The PR is reasonably scoped (no unrelated changes) and preserves backward compatibility, or any breaking change is called out above and documented in release-notes/current/breaking_changes/.
  • Codex review: Requested a Codex review and addressed all of its comments.
  • Copilot review: Requested a Copilot review and addressed all of its comments.

@netlify

netlify Bot commented Aug 5, 2026

Copy link
Copy Markdown

Deploy Preview for cerulean-figolla-1f9435 ready!

Name Link
🔨 Latest commit f6ae4f0
🔍 Latest deploy log https://app.netlify.com/projects/cerulean-figolla-1f9435/deploys/6a94ae1907b05d0008e929f3
😎 Deploy Preview https://deploy-preview-9675--cerulean-figolla-1f9435.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@codecov

codecov Bot commented Aug 5, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.27%. Comparing base (3b80726) to head (f6ae4f0).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #9675      +/-   ##
==========================================
- Coverage   81.29%   81.27%   -0.02%     
==========================================
  Files         263      263              
  Lines       40859    40859              
==========================================
- Hits        33216    33210       -6     
- Misses       7643     7649       +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Comment thread api/v1alpha1/envoyproxy_types.go Outdated
// Default: false
//
// +optional
DetectMisdirectedRequests *bool `json:"detectMisdirectedRequests,omitempty"`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have another top level fields for features like this may happen in the future?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. How about a typed struct named features like following?

spec:
  features:
    detectMisdirectedRequests: true

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@envoyproxy/gateway-maintainers wdyt?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated. I moved detectMisdirectedRequests under a typed features field.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer OverlappingTLSHandling to this, and then we should define as enum to extend feature in the future.

// +kubebuilder:validation:Enum=DowngradeToHTTP1;Reject
// +optional
OverlappingTLSHandling *OverlappingTLSHandling

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I’m fine with the OverlappingTLSHandling name too.
Do you expect this to support three or more handling modes in the future?
Since this is currently just two states, enabled or disabled, I think a bool is reasonable. If we expect more handling modes soon, an enum would make sense.

@sivchari sivchari Aug 7, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure we'd like to add another option to this field in the future. But v1alpha1 must migrate to v1alpha2 if we'd like to add any mode since bool can only handle two states literally. Whereas if we goes with this as enum, we won't care about migration.

@mmmommm
mmmommm force-pushed the feat/detect-misdirected-requests-api branch from 5646738 to d851ccf Compare August 6, 2026 07:13
@mmmommm
mmmommm marked this pull request as ready for review August 6, 2026 07:19
@mmmommm
mmmommm requested a review from a team as a code owner August 6, 2026 07:19

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d851ccf213

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread api/v1alpha1/envoyproxy_types.go Outdated
Comment on lines +219 to +222

// Features defines the features that are enabled for this EnvoyProxy.
// +optional
Features *EnvoyProxyFeatures `json:"features,omitempty"`

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Add a release note for the new EnvoyProxy API

This introduces a user-visible EnvoyProxy API field, but the commit adds no fragment under release-notes/current/. When the next release notes are generated, this API addition will therefore be omitted; add a new_features/ fragment describing the new field and its currently disabled-by-default behavior.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@mmmommm
mmmommm force-pushed the feat/detect-misdirected-requests-api branch from d851ccf to 99eac78 Compare August 6, 2026 07:48
@mmmommm

mmmommm commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Fixed Hugo Docs / docs-lint (pull_request) ci fails in #9684

Comment thread api/v1alpha1/envoyproxy_types.go Outdated

// Features defines the features that are enabled for this EnvoyProxy.
// +optional
Features *EnvoyProxyFeatures `json:"features,omitempty"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This project is for envoy, so I think it's clearer.

Suggested change
Features *EnvoyProxyFeatures `json:"features,omitempty"`
ProxyFeatures *ProxyFeatures `json:"proxyFeatures,omitempty"`

Comment thread api/v1alpha1/envoyproxy_types.go Outdated
Comment on lines +221 to +222
// +optional
Features *EnvoyProxyFeatures `json:"features,omitempty"`

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// +optional
Features *EnvoyProxyFeatures `json:"features,omitempty"`
// +optional
// +kubebuilder:validation:MinProperties=1
Features EnvoyProxyFeatures `json:"features,omitempty"`

You can define this field without using pointer if you add MinProperties field = 1 since it doesn't admit zero value struct.

@mmmommm

mmmommm commented Aug 21, 2026

Copy link
Copy Markdown
Contributor Author

@arkodg @zhaohuabing
Could you please review this when you have some time?

@arkodg arkodg added this to the v1.10.0-rc.1 Release milestone Aug 24, 2026
@arkodg

arkodg commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

hey @zirain can you elaborate on #5879 (comment) ?

@zirain

zirain commented Aug 24, 2026

Copy link
Copy Markdown
Member

hey @zirain can you elaborate on #5879 (comment) ?

I'm not sure if it's reasonable to add a CTP in test/config/gatewayclass.yaml to enabled detectMisdirectedRequests for the conformance test, EnvoyProxy sounds good to me.

@arkodg

arkodg commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

imo the focus should be UX, ALPN lives in CTP should it makes sense for this behavior knob to live close to it

@zirain

zirain commented Aug 24, 2026

Copy link
Copy Markdown
Member

imo the focus should be UX, ALPN lives in CTP should it makes sense for this behavior knob to live close to it

I have no strong opinion on UX part, since I believe it should be default behavior.

@mmmommm

mmmommm commented Aug 30, 2026

Copy link
Copy Markdown
Contributor Author

To keep it next to alpnProtocols (as @arkodg suggested), I'll add detectMisdirectedRequests *bool to ClientTrafficPolicy.spec.tls. When it is enabled, the listener keeps HTTP/2 and returns 421 on an SNI/:authority mismatch, instead of downgrading ALPN.

I'd like to confirm a few things before implementing

  1. Is the placement and name OK?
  2. Should the default be on or off? (@zirain suggested it should be default behavior, though defaulting to on would change the current behavior for overlapping listeners.)

Signed-off-by: Kise Ryota <kiseryota.contact@gmail.com>
Signed-off-by: Kise Ryota <kiseryota.contact@gmail.com>
@mmmommm
mmmommm force-pushed the feat/detect-misdirected-requests-api branch from e363de1 to f6ae4f0 Compare August 30, 2026 22:26
@zhaohuabing

zhaohuabing commented Aug 31, 2026

Copy link
Copy Markdown
Member

Is the placement and name OK?

How about making it more explicit?


OverlappingTLSHandling *OverlappingTLSHandling `json:"overlappingTLSHandling,omitempty"`

// +kubebuilder:validation:Enum=DowngradeToHTTP1;Reject
type OverlappingTLSHandling string

const (
      // Downgrade ALPN to http/1.1 so clients cannot coalesce. Default.
      OverlappingTLSHandlingDowngradeToHTTP1 OverlappingTLSHandling = "DowngradeToHTTP1"
      // Keep HTTP/2 and respond 421 Misdirected Request when the request
      // :authority does not match the SNI the connection was accepted on.
      OverlappingTLSHandlingReject OverlappingTLSHandling = "Reject"
)

Should the default be on or off?

I'd prefer to keep the existing behavior to avoid breaking change. If adding a CTP to pass comformance tests is not feasible, then we can make the default on and add a breaking change note to warn users who have old clients in production that don't understand 421 Misdirected Request, and ask them to turn it off with CTP.

@arkodg

arkodg commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Is the placement and name OK?
+1
Should the default be on or off? (@zirain suggested it should be default behavior, though defaulting to on would change the current behavior for overlapping listeners.)

vote for off to avoid a breaking change

@arkodg

arkodg commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Is the placement and name OK?

How about making it more explicit?


OverlappingTLSHandling *OverlappingTLSHandling `json:"overlappingTLSHandling,omitempty"`

// +kubebuilder:validation:Enum=DowngradeToHTTP1;Reject
type OverlappingTLSHandling string

const (
      // Downgrade ALPN to http/1.1 so clients cannot coalesce. Default.
      OverlappingTLSHandlingDowngradeToHTTP1 OverlappingTLSHandling = "DowngradeToHTTP1"
      // Keep HTTP/2 and respond 421 Misdirected Request when the request
      // :authority does not match the SNI the connection was accepted on.
      OverlappingTLSHandlingReject OverlappingTLSHandling = "Reject"
)

Should the default be on or off?

I'd prefer to keep the existing behavior to avoid breaking change. If adding a CTP to pass comformance tests is not feasible, then we can make the default on and add a breaking change note to warn users who have old clients in production that don't understand 421 Misdirected Request, and ask them to turn it off with CTP.

+1 to enum over bool

@mmmommm

mmmommm commented Sep 4, 2026

Copy link
Copy Markdown
Contributor Author

@arkodg @zhaohuabing
Thanks for the feedback, and sorry for the late reply.

Agreed on moving from a bool to an enum and no breaking change. I’ll go with OverlappingTLSHandling as suggested:


// +kubebuilder:validation:Enum=DowngradeToHTTP1;Reject
OverlappingTLSHandling *OverlappingTLSHandling

@zirain

zirain commented Sep 4, 2026

Copy link
Copy Markdown
Member

Is the placement and name OK?
+1
Should the default be on or off? (@zirain suggested it should be default behavior, though defaulting to on would change the current behavior for overlapping listeners.)

vote for off to avoid a breaking change

it should be default off it live in CTP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix conformance for GatewayHTTPSListenerDetectMisdirectedRequests

5 participants