Transform Rules not working on .pages.dev

General Rules
1

What is the name of the domain?

sweetdevilswares.pages.dev

What is the issue you’re encountering

“Modify Response Header” rules don’t seem to be working on ‘pages.dev’ but they work on the main domain.

2

Hi there!

This is expected behavior. Pages.dev is not a zone in your account, so your rules will not apply there.

1 Like
3

Hi, @sdayman.
Is there a way to modify the response headers for pages.dev? I’m especially interested in CSP and other security-related headers, but ability to use custom headers would be best.

4

You can do this by proxying requests to pages.dev through your zone: either via a custom domain or via Snippets / Workers. Once this is done, your Transform Rule will work correctly. You can also add security headers directly in your snippet if you wish.

5

I’m already using a custom domain for the production site, and rules are indeed working correctly there. I’ve also configured bulk redirects for various things, including redirecting from the production .pages.dev domain to my custom domain. However, I’m still using [hash].[appname].pages.dev for development previews, and I have configured Zero Trust to require authentication for those FQDNs so that only I can access those. For consistency, I’d like my development previews to reflect every aspect of actual production versions, including their rules. Are you saying that, using a Worker, I can intercept requests to static Pages resources and modify the response headers? If this is correct, wouldn’t that count toward my Worker requests quota as I’m currently on the free plan? If that’s the case, is there a different way to achieve consistency in the response headers?

Thanks for your help

6

I’m afraid what I meant was using a snippet or a worker to serve requests on [hash].[appname].yourdomain even for your dev environment. This way you can route them to [hash].[appname].pages.dev under the hood and apply all the rules and policies at least to requests going through your zone. Since pages.dev is something that doesn’t exist within your account, unfortunately you cannot enforce rules that apply to pages.dev hostnames directly.

If you choose to use Snippets, you won’t have to think about quota for requests since Snippets come free of charge for Pro plan and above.

As an alternative solution, you could add custom response headers directly to your Pages project. Depending on the framework you’re using, it might be possible — here’s an example for Next.js.

7

I’m afraid what I meant was using a snippet or a worker to serve requests on [hash].[appname].yourdomain even for your dev environment.

This is interesting. However, if Cloudflare automatically generates a different [hash] on every deployment, how would it be possible to make my custom domain have one subdomain for every generated hash?

As an alternative solution, you could add custom response headers directly to your Pages project. Depending on the framework you’re using, it might be possible

I’m not using any framework, but deploying static content using Cloudflare Pages. Though I’ve just found that a _headers can be added to change Cloudflare Pages response, and I’m wondering if this would solve my issue. What do you think?

8

I tried using the _headers file and it’s working. My issue is solved

2 Likes
9

Glad to hear that you’ve solved it with _headers!

You could create a wildcard DNS record for *.[appname].yourdomain, point it to 100:: (discard prefix) or any other target you want, and then deploy a snippet that is executed on any request where hostname ends with .[appname].yourdomain. Inside your snippet code, you could parse the hostname and send a subrequest to the corresponding hash subdomain of [appname].pages.dev derived from [hash].[appname].yourdomain, then return that response to the end-user with additional headers.

1 Like
10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.