[vite-plugin] Preserve the port on requests that arrive over HTTP/2 - #15237
Open
amitvijapur wants to merge 3 commits into
Open
[vite-plugin] Preserve the port on requests that arrive over HTTP/2#15237amitvijapur wants to merge 3 commits into
amitvijapur wants to merge 3 commits into
Conversation
Over HTTPS the dev server could lose the port from `request.url` and `X-Forwarded-Host`, so a Worker saw `https://localhost` where the browser had asked for `https://localhost:5173`. Auth libraries that rebuild redirect URLs from the request then redirected to the wrong origin and could loop. Plain HTTP was unaffected. Browsers usually negotiate HTTP/2 over HTTPS, and HTTP/2 carries the authority in the `:authority` pseudo-header rather than in `Host`. `createHeaders` drops pseudo-headers when building the Fetch `Request`, so no `Host` was found and the host fell back to a bare `localhost`. `toMiniflareRequest` was gated on the same missing header, so `X-Forwarded-Host` was not set at all. Read the authority from `:authority` when `Host` is absent, and fall back to the resolved request URL when forwarding the host. `Host` is still preferred whenever present, so HTTP/1.1 requests are unchanged. This completes the host and protocol forwarding work in cloudflare#8706, cloudflare#13920. Closes cloudflare#14931
🦋 Changeset detectedLatest commit: e70475b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
workers-devprod
requested review from
a team and
emily-shen
and removed request for
a team
August 17, 2026 10:50
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/codemods
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
REVIEW.md requires changesets to target users rather than maintainers, so the request-conversion mechanics are dropped in favour of the effect a user sees.
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
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.
Closes #14931
Serving the Vite dev server over HTTPS could drop the port from
request.urland
X-Forwarded-Host, so a Worker sawhttps://localhostwhere the browserhad asked for
https://localhost:5173. Auth libraries that rebuild redirectURLs from the request — Clerk's handshake in the original report — then
redirected to the wrong origin and could loop. Plain HTTP was unaffected,
which is what made it look HTTPS-specific.
Cause
Browsers usually negotiate HTTP/2 over HTTPS, and HTTP/2 carries the authority
in the
:authoritypseudo-header rather than inHost.createHeadersdropspseudo-headers when building the Fetch
Request, socreateRequestForIncomingMessagefound no
Hostand fell back to a bare"localhost", losing the port:toMiniflareRequestwas gated on the same missing header, soX-Forwarded-Hostwas not set at all on those requests.
Change
getRequestAuthority, which reads:authorityfrom theNode request when
Hostis absent. It mirrors the shape of the neighbouringgetForwardedProtohelper added for theX-Forwarded-Protowork.X-Forwarded-Hostfalls back to the resolved request URL, which now carriesthe correct authority.
Hostis still preferred whenever it is present, so HTTP/1.1 requests areunchanged. This is the port/authority half of the host and protocol forwarding
addressed in #8706 and #13920.
Verification
vitest run src/__tests__— 20 files, 203 tests passingtsc --build— cleanoxfmt --checkandoxlint --deny-warnings— clean7 new unit tests sit alongside the existing
getForwardedProtoblock, coveringHostpresent, the:authorityfallback,Hostpreferred when both are set, anon-default port surviving into the reconstructed origin, array header values,
and empty or whitespace-only values.
I could not reproduce the original Clerk handshake loop end to end, since that
needs an HTTPS dev server with a Clerk app, so the tests target the host
resolution directly rather than the redirect behaviour.