Fix CORS on redirect responses and add Vary: Origin#62
Merged
Conversation
Cross-origin fetches run the CORS check on every response in a redirect chain, so the 302 produced for non-wasm assets needs an Access-Control-Allow-Origin header too — without it the redirect was blocked before the final asset response (which did set the header) was reached. Also add `Vary: Origin` everywhere the header is emitted, since its value varies by request origin (dprint.dev / localhost / 127.0.0.1).
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
dprint-plugins | 439da8f | Commit Preview URL Branch Preview URL |
Jun 27 2026, 07:06 PM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Cross-origin fetches from
https://dprint.devto schema/plugin URLs were failing with:A request for a non-wasm asset (e.g.
schema.json,plugin.json) returns a302redirect to the/asset/...path so relative URLs resolve correctly. The final asset response setAccess-Control-Allow-Origin, but the302fromResponse.redirect()did not. For CORS-mode requests the browser runs the CORS check on every response in the redirect chain, so the naked redirect was blocked before the final response was reached.Fix
createRedirectResponse(request, location)helper that builds the302with theAccess-Control-Allow-Originheader (reusing the existinggetAccessControlAllowOrigin, which already echoeslocalhost/127.0.0.1origins for local dev). Both redirect sites now use it.Vary: Originto every response that emits the dynamic ACAO header (plugin, JSON, and redirect responses), so caches don't serve a response cached for one origin to another.Tests
Extended the two existing redirect tests to assert the ACAO header is present. The only failing tests (
info.json,cli.json) are pre-existing and require live GitHub credentials.Closes #52