Drop client-supplied x-restate-* headers at the ingress

[pjdurden]

Closes #4187.

The HTTP ingress forwarded every incoming request header to the service, including caller-supplied x-restate-* headers. That namespace is reserved for the ingress (e.g. x-restate-ingress-path), so a caller could inject or override reserved metadata.

parse_headers now drops any incoming header whose name starts with x-restate-, so only ingress-set values are forwarded. (x-restate-limit-key is unaffected — it's consumed by parse_limit_key before parse_headers runs.)

Added a regression test that sends a spoofed x-restate-ingress-path plus an arbitrary x-restate-foo header and asserts they don't reach the service while normal headers still do. It passes with the fix and fails without it. Also added a release note for the behavior change.

Verified with cargo test -p restate-ingress-http, cargo fmt --check, and cargo clippy.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR prevents clients from spoofing ingress-reserved metadata by stripping any incoming x-restate-* headers before forwarding requests to services, and documents the behavior.

Changes:

• Drop client-supplied x-restate-* headers in the HTTP ingress handler.
• Add a regression test to ensure reserved headers can’t be injected/overridden.
• Add release notes describing the behavioral/security change and migration guidance.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
release-notes/unreleased/4187-ingress-overwrite-x-restate-headers.md	Documents the reserved-header stripping behavior and its user impact.
crates/ingress-http/src/handler/tests.rs	Adds regression coverage ensuring x-restate-* isn’t forwarded and ingress sets its own reserved headers.
crates/ingress-http/src/handler/service_handler.rs	Implements the actual filtering of x-restate-* headers from incoming requests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[pjdurden]

I have read the CLA Document and I hereby sign the CLA

[slinkydeveloper]

@tillrohrmann this is a valid fix, up to you to merge if you wanna push it in 1.7 . Not critical

[tillrohrmann]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

ℹ️ 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".

[tillrohrmann]

Thanks a lot for creating this PR @pjdurden. The changes look great. I will take care of merging this PR.

[tillrohrmann]

Could we fold this note into the now existing https://github.com/restatedev/restate/blob/main/release-notes/v1.7.0.md?

[pjdurden]

v1.7.0 shipped on Jun 18 without this change, so folding it there would document something that isn't in that release. Left it in unreleased/ to get consolidated into whatever version this lands in, same as the other open notes there.

[tillrohrmann]

Before merging we need to resolve one open question regarding whether and how these headers are being used by the SaaS offering.

[pjdurden]

Thanks a lot for creating this PR @pjdurden. The changes look great. I will take care of merging this PR.

Sounds good @tillrohrmann . Thanks

[pjdurden]

Before merging we need to resolve one open question regarding whether and how these headers are being used by the SaaS offering.

Hi @tillrohrmann, one thing. Did the question about SaaS usage of the x-restate-* headers get resolved? Happy to gate the stripping behind a flag or allowlist if needed.

[tillrohrmann]

We didn't resolve it yet on the SaaS side. It shouldn't take super long to fix. Once this happens, I'll merge this PR. Sorry for the delay.

[pjdurden]

Any movement on the SaaS side? Branch is still clean against main. If it helps unblock, I can put the stripping behind a config flag defaulting to off so SaaS can migrate on its own timeline.

[tillrohrmann]

Sorry for the slow turnaround @pjdurden. I am looking into including this fix for the upcoming v1.8.0 release.

[pcholakov]

This is now safe to merge!