fix: ensure that Origin header is rewritten as necessary

[petebacondarwin]

The wrangler dev command puts the Worker under test behind a proxy server. This proxy server should be transparent to the client and the Worker, which means that the Request arriving at the Worker with the correct url property, and Host and Origin headers.

Previously we fixed the Host header but missed the Origin header which is only added to a request under certain circumstances, such as cross-origin requests.

What this PR solves / how to test:

This change fixes the Origin header as well, so that it is rewritten, when it exists, to use the origin of the url property.

A nice way to test this is to simply clone the reproduction from #4761 - https://github.com/Le0Developer/wrangler-host-header-repro, then replace the local Miniflare with the pre-release one from this PR.

Fixes #4761

Author has addressed the following:

• Tests
  • Included (updated worker-app fixture tests)
  • Not necessary because:
• Changeset (Changeset guidelines)
  • Included
  • Not necessary because:
• Associated docs
  • Issue(s)/PR(s):
  • Not necessary because: no user facing change

[changeset-bot]

🦋 Changeset detected

Latest commit: 0337596

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
miniflare	Patch
@cloudflare/pages-shared	Patch
wrangler	Patch

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

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7631624262/npm-package-wrangler-4812

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/4812/npm-package-wrangler-4812

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7631624262/npm-package-wrangler-4812 dev path/to/script.js

Additional artifacts:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7631624262/npm-package-create-cloudflare-4812 --no-auto-update

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7631624262/npm-package-miniflare-4812

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/7631624262/npm-package-cloudflare-pages-shared-4812

Note that these links will no longer work once the GitHub Actions artifact expires.

---

wrangler@3.24.0 includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	3.20231218.3
workerd	1.20231218.0	1.20231218.0
workerd --version	1.20231218.0	2023-12-18

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (77b0bce) 70.56% compared to head (0337596) 70.63%.
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4812      +/-   ##
==========================================
+ Coverage   70.56%   70.63%   +0.06%     
==========================================
  Files         290      290              
  Lines       15089    15089              
  Branches     3828     3828              
==========================================
+ Hits        10648    10658      +10     
+ Misses       4441     4431      -10     

see 7 files with indirect coverage changes

[mrbbot]

Ooo this should be " instead of '. I guess we're not running miniflare's linting checks in CI?

[petebacondarwin]

😱

[petebacondarwin]

It is purposefully ignored -

workers-sdk/.prettierignore

Line 38 in 93e88c4

# Miniflare shouldn't be formatted with the root `prettier` version

[petebacondarwin]

I'll fix up that formatting. But we should probably bring miniflare into the fold with the same prettier settings as the rest of the mono-repo. As far as I can tell the only difference is trailing commas.

[mrbbot]

I think the other difference is that Miniflare uses Prettier 3, whereas the rest use Prettier 2.

[petebacondarwin]

I was basing it off of removing the prettier ignore and running the formatting fix up command at the root.

[afonsocrg]

Hey @petebacondarwin and @mrbbot, I have a question regarding this PR and would be very grateful if you could clarify it for me 🙂

I am building an application that has a React frontend making requests to Cloudflare workers. Whenever any request is sent, the Origin header is correctly set in the browser (in my case to localhost:5173). However, when the worker starts processing it, that header has the same value of the request url (in my case localhost:8787). I checked with wireshark that the request is actually being sent with the correct Origin header, so I believe this change took place between the request being received and the worker starts processing it. The issue with this behavior is that without the original Origin header value, I cannot set the correct Access-Control-Allow-Origin header, making the frontend reject every response.

After looking at this PR, I noticed that the Origin header is being set in the following lines:

if (rewriteHeadersFromOriginalUrl) {
    request.headers.set("Host", url.host);
    // Only rewrite Origin header if there is already one
    if (request.headers.has("Origin")) {
        request.headers.set("Origin", url.origin);
    }
}

I'm having trouble figuring out why the Origin header needs to be set to the request url, and not to its original value (request.headers.get("Origin"), or no change at all, since the original request was used to build the new one). I would be very grateful if you could clarify that for me!

[petebacondarwin]

@afonsocrg - happy to try to help. Can you confirm what version of Wrangler you are using, and exactly what your setup is here? It seems from what you are saying that you are running wrangler pages dev and testing this locally?
Also when you say that the request in the browser has the Origin set to localhost:5172, what is the actual request you are making? Are you setting the url to localhost:8787 but the Origin to localhost:5172?

[afonsocrg]

@petebacondarwin thanks for the fast reply!! This behavior happens only in versions 3.25 and 3.26. The worker was running using wrangler dev. If I ran with the --remote flag, I did not have this issue, but I'd rather not have to use that flag.

The React app is running on localhost:5173, and when it sends any request (OPTIONS, POST, etc.), the same happens: The browser sends the correct Origin header (localhost:5173, which is the endpoint the frontend is running), but the worker receives Origin: http://localhost:8787, which is incorrect. I changed the worker code to only print the headers and return an empty response, so the headers must have been modified before the worker code has been called.

I expected the headers to be the same as the ones sent by the browser, so that the wrangler layer is transparent to the worker

[petebacondarwin]

How does the request get to the Worker if it is running at localhost:8787 and the browser is making a request to locahost:5173?

[afonsocrg]

Sorry, the frontend is running at localhost:5173, and is sending the requests to localhost:8787.
According to MDN, I believe the origin header should be set to localhsot:5173, and the Host header should be the one set to localhost:8787

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host

[petebacondarwin]

This stuff is so confusing but here is my take on how this should work.

• Host is where the request is going to, it is very likely going to match the request.url property since this is also what is used to route the request to the correct end point.
• Origin (as noted in MDN) is effectively the server where the response being processed by a client originated from.

So as I understand it, if you have a web page hosted at localhost:5173 and you make a client side fetch() request to a server at localhost:8787, then the Request should have localhost:5173 as its Origin and localhost:8787 as its Host headers.

With that in mind, you might be right that something in our implementation is a bit off in our implementation of this fix, since we are reconstructing the Origin header from the request url origin, rather than the referring URL...