Middleware OK on `pages.dev`, not on custom domain?
I tried
_middleware.js stuff with CF Pages, in an attempt to use it instead of an existing CF Worker. The middleware worked perfectly on the pages.dev version — but, on the custom-domain version from that pages.dev, only the HTML files were affected even though the middleware was supposed to apply for all routes and files (location: functions/_middleware.js, thus presumably for all routes).
To be more specific: on the pages.dev version, a number of custom headers (such as for caching) were added to a variety of file types, including CSS and image files; but, on the custom-domain version, this worked for only the HTML files.
Is there something special I have to do in the domain’s DNS, or elsewhere, to make the middleware work properly on the custom domain, too? (And I did remove the custom domain’s routes from the Worker for the test, so the Worker shouldn’t have been interfering.)
The pages.dev domain = static-site-2to.pages.dev
The custom domain = brycewray.com
Note: I had to re-add the custom domain routes to the Worker and take the _middleware.js file out of the project in order to regain the previous functionality, at least until I could learn from you folks why the middleware file wouldn’t work on the custom domain. Let me know if/when you want me to restore the test setup (assuming GitHub is stable at the time, that is 😄 ).5 Replies
Any thoughts on this?
Sounds like the custom domain is maybe doing some caching in front of the asset requests?
Check your caching settings and reduce the TTL as necessary. If you want to disable caching entirely, that should give you the authentic pages.dev experience.
Thanks for replying! I checked the domain caching settings. Caching Level is set to Standard and Browser Cache TTL is set to Respect Existing Headers. This combination has always worked properly with my Worker, so I guess I thought the same would be true for the middleware, given that it's really a Worker behind the scenes and is adjusting the same assets’ settings.
Also, it wasn’t just that custom caching was ignored. There were other headers in the middleware (some just for testing purposes), and none was attached to the non-HTML files under the custom domain. 🤔
. . . Or should I perform a Purge Everything under Purge Cache before trying the middleware again? Just not sure how to proceed.
I am now seeing that this may be related to the Cloudflare 1.1.1.1/Warp add-on I use with my Mac and iOS devices. When I toggle it, it seems to fix the issue. (I did try that the other night when I first was experimenting with the middleware, but seemed to get no good results. Today, it’s a different story, for whatever reason.) So this may very well have been fine all along. I apologize for troubling you, and — again — appreciate your help!
Hey, thanks for doing that testing. I’m afk right now, try disabling caching entirely. If there’s no setting for that on the Caching Configuration section, there might be a Page Rule you can apply?
I suspect that this is going to become our recommended set up as more and more people get into full-stack apps, but we definitely need to do a deeper investigation into all the complexities and trade-offs here.
Did briefly disable caching through one of the (beta) Cache Rules, but still saw same need to toggle Warp off/on to see middleware changes even after hard-reload-and-refresh cycles on multiple browsers/devices. Seems to be 95% Warp and 5% CF caching (if that).
Have now restored CF caching and reported this as a (possible) Warp bug. Weird that it doesn’t seem to affect CFP sites without the custom domains, but... 🤷♂️ Anyway, I will tag this with “Solved.” Thanks.