Skip to content

chore: fix cors for envoys#4720

Draft
NathanFlurry wants to merge 1 commit into04-23-chore_fix_serverlessfrom
04-23-chore_fix_cors_for_envoys
Draft

chore: fix cors for envoys#4720
NathanFlurry wants to merge 1 commit into04-23-chore_fix_serverlessfrom
04-23-chore_fix_cors_for_envoys

Conversation

@NathanFlurry
Copy link
Copy Markdown
Member

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Copy link
Copy Markdown
Member Author

NathanFlurry commented Apr 24, 2026

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@claude
Copy link
Copy Markdown

claude Bot commented Apr 24, 2026

Review: chore: fix cors for envoys

Overall: Good architectural direction -- centralizing CORS at the guard routing layer rather than in each gateway implementation is cleaner, avoids duplication, and ensures auth error responses carry CORS headers (the key bug being fixed). The lifetime/ownership fixes for the target string are also correct.


Security: allow_credentials: true + allow_origin: "*" fallback

File: engine/packages/guard/src/routing/pegboard_gateway/cors.rs

If a request arrives without an Origin header, origin_header() returns "*" and set_non_preflight_cors will emit Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true. The CORS spec explicitly forbids this combination -- browsers reject credentialed responses with a wildcard origin. In practice, browser CORS requests always include Origin, so the "*" fallback is only reached by non-browser clients where CORS doesn't apply. The behavior is harmless in practice, but the server is emitting a technically invalid CORS configuration that could confuse intermediary caches or reverse proxies. Consider omitting CORS headers entirely when Origin is absent, or at minimum not setting allow_credentials: true for the wildcard case.

The same unwrap_or("*") pattern in CorsPreflight::handle_request produces a preflight response of Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true, which browsers will also reject.


OPTIONS check ordering in route_request_path_based

File: engine/packages/guard/src/routing/pegboard_gateway/mod.rs

The OPTIONS intercept comes after parse_actor_path, so a preflight request to a path that does not conform to the actor-path format falls through this handler entirely. For header-based routing (route_request), the OPTIONS check correctly appears before any header parsing. If any path that browsers preflight will not pass parse_actor_path, it will silently not receive a CORS preflight response. Worth confirming this ordering is intentional.


Origin read inconsistency in CorsPreflight

CorsPreflight::handle_request reads the origin from the raw req: Request<...> parameter, while set_non_preflight_cors reads it from req_ctx via origin_header(req_ctx). They access the same underlying headers and should be equivalent today, but origin_header is not the single source of truth. Consider refactoring CorsPreflight to extract the origin via req_ctx too, or at least add a comment explaining why the raw request is used there.


expose_headers: "*" with allow_credentials: true

Per the Fetch spec, the "*" wildcard for Access-Control-Expose-Headers is not treated as a wildcard for credentialed responses -- it is matched literally as a header named "*". All modern browsers now implement the 2020 amendment and handle this correctly in practice, so this is a spec-compliance note rather than a live bug. Worth confirming that wildcard expose-headers with credentials is acceptable for your target environments.


Observation: envoy routing has no CORS handling

engine/packages/guard/src/routing/envoy.rs does not set CORS headers and does not intercept OPTIONS. This appears intentional (envoy connections are actor-to-engine, not browser-initiated), but worth confirming no browser client ever hits /envoys/connect.


Test coverage

No new tests accompany these changes. Given that CORS mis-configuration is a common source of hard-to-debug browser regressions, even a simple integration test asserting that OPTIONS returns 204 with the expected headers and that non-OPTIONS responses include Access-Control-Allow-Origin would be valuable before this merges.


Summary:

Priority Issue
Fix before merging allow_credentials: true + allow_origin: "*" in the no-Origin-header fallback (spec violation, could confuse caches)
Worth confirming OPTIONS ordering after parse_actor_path in route_request_path_based
Nice to have Consolidate origin extraction into origin_header() inside CorsPreflight
Low priority expose_headers: "*" + credentials spec note
Nice to have Test coverage for CORS preflight and non-preflight behavior

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 24, 2026

Preview packages published to npm

Install with:

npm install rivetkit@pr-4720

All packages published as 0.0.0-pr.4720.878b7fb with tag pr-4720.

Engine binary is shipped via @rivetkit/engine-cli on linux-x64-musl, linux-arm64-musl, darwin-x64, and darwin-arm64. Windows users should use the release installer or set RIVET_ENGINE_BINARY.

Docker images:

docker pull rivetdev/engine:slim-878b7fb
docker pull rivetdev/engine:full-878b7fb
Individual packages
npm install rivetkit@pr-4720
npm install @rivetkit/react@pr-4720
npm install @rivetkit/rivetkit-napi@pr-4720
npm install @rivetkit/workflow-engine@pr-4720

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.

1 participant