Response Set-Cookie not working, but only on Cloudflare Pages/Workers? Let’s Crack the Code!
Image by Rolfe - hkhazo.biz.id

Response Set-Cookie not working, but only on Cloudflare Pages/Workers? Let’s Crack the Code!

Posted on

Are you stuck in the frustrating loop of trying to set cookies on Cloudflare Pages or Workers, only to find that it’s not working? Relax, friend, you’re not alone! Many developers have been there, done that, and got the t-shirt. In this article, we’ll dive into the world of cookies, Cloudflare, and the mysterious case of the missing Set-Cookie response header.

What’s the Deal with Cookies and Cloudflare?

Cookies are small text files stored on a user’s browser, used to remember preferences, track sessions, or store data. In the context of Cloudflare, cookies play a crucial role in shaping the user experience. However, when it comes to setting cookies using the Set-Cookie response header, things can get a bit wonky.

When you set a cookie using the Set-Cookie response header, you expect it to be stored on the user’s browser. But, on Cloudflare Pages or Workers, this might not happen. The cookie might not be set, or it might be set incorrectly. This can lead to issues with user authentication, session management, or even break your application’s functionality.

Understanding Cloudflare’s caching and proxying

To grasp the root of the problem, let’s talk about how Cloudflare works its magic.

Cloudflare acts as a reverse proxy between your users and your origin server. When a user requests a resource, Cloudflare caches the response from your origin server. This caching layer helps reduce the load on your server, lowers latency, and improves performance.

However, this caching layer can sometimes interfere with your Set-Cookie response headers. Here’s what might happen:

  • Cloudflare caches the response from your origin server, including the Set-Cookie header.
  • When the user requests the same resource again, Cloudflare serves the cached response, which might not include the Set-Cookie header.
  • The user’s browser never receives the Set-Cookie header, and the cookie is not set.

Fixing the Issue

Now that we know the culprit, let’s explore the solutions to get your Set-Cookie response headers working on Cloudflare Pages/Workers.

1. Disabling caching for the specific response

You can disable caching for a specific response by setting the Cache-Control header. This tells Cloudflare to bypass caching for that particular response.

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Set-Cookie: mycookie=value; Expires=Wed, 21-Jan-2026 01:23:45 GMT; Path=/

In this example, we’ve added the Cache-Control header with the no-cache, no-store, and must-revalidate directives. This instructs Cloudflare to not cache the response and always revalidate it with the origin server.

2. Using Cloudflare’s Cache-Everything response header

Cloudflare provides a Cache-Everything response header that allows you to control caching behavior. By setting Cache-Everything to false, you can disable caching for the specific response.

HTTP/1.1 200 OK
Cache-Everything: false
Set-Cookie: mycookie=value; Expires=Wed, 21-Jan-2026 01:23:45 GMT; Path=/

Note that this header only works if you’re using Cloudflare’s Enterprise plan.

3. Implementing Edge-side includes (ESI)

Edge-side includes (ESI) allow you to dynamically inject content into a cached response. You can use ESI to set cookies on the edge, ensuring they’re always sent to the user’s browser.

<esi:include src="/set-cookie"></esi:include>

In this example, the ESI tag includes a separate endpoint (/set-cookie) that sets the cookie. This ensures the cookie is always set, even when the main response is cached.

4. Using Cloudflare Workers

Cloudflare Workers provide a powerful way to manipulate requests and responses at the edge. You can use Workers to set cookies programmatically.

worker.addEventListener('fetch', (event) => {
  event.respondWith(
    fetch(event.request).then((response) => {
      response.headers.set('Set-Cookie', 'mycookie=value; Expires=Wed, 21-Jan-2026 01:23:45 GMT; Path=/');
      return response;
    })
  );
});

In this example, the Worker sets the Set-Cookie header programmatically, ensuring it’s always included in the response.

Best Practices for Working with Cookies on Cloudflare

To avoid future issues, keep the following best practices in mind:

  • Always specify the Secure and HttpOnly flags when setting cookies.
  • Use a secure protocol (HTTPS) to set cookies.
  • Avoid setting cookies with a short expiration date or without an expiration date.
  • Use a consistent cookie naming convention and avoid using special characters.
  • Test your cookie-setting functionality on Cloudflare Pages/Workers before deploying to production.

Conclusion

Setting cookies on Cloudflare Pages/Workers can be a bit tricky, but with the right techniques, you can overcome the challenges. By understanding how Cloudflare’s caching and proxying work, and applying the solutions outlined in this article, you’ll be able to set cookies successfully and provide a seamless user experience.

Remember, when it comes to cookies and Cloudflare, it’s all about control and flexibility. By taking advantage of Cloudflare’s features and configuring your application correctly, you can ensure that your Set-Cookie response headers work as intended, even on Cloudflare Pages/Workers.

Solution Pros Cons
Disabling caching for the specific response Easy to implement, works for most cases May impact performance, as caching is disabled
Using Cloudflare’s Cache-Everything response header Simple to implement, provides granular control Only available on Cloudflare’s Enterprise plan
Implementing Edge-side includes (ESI) Provides a flexible way to set cookies on the edge Requires additional infrastructure and complexity
Using Cloudflare Workers Provides programmatic control over cookies, flexible Requires knowledge of Cloudflare Workers, additional complexity

Now, go forth and conquer the world of cookies on Cloudflare Pages/Workers!

Frequently Asked Question

Getting stuck with Response Set-Cookie not working on Cloudflare Pages/Workers? Don’t worry, we’ve got you covered!

Why is my Set-Cookie response not working on Cloudflare Pages/Workers?

This issue might be due to Cloudflare’s caching mechanism. By default, Cloudflare strips out Set-Cookie headers from responses to prevent caching issues. To fix this, you can add the `CF-Cache-Status: DYNAMIC` header to your response, which tells Cloudflare not to cache the response. Alternatively, you can also use the `Cache-Control: private` header to achieve the same result.

Is there a way to bypass Cloudflare’s caching for Set-Cookie responses?

Yes, you can bypass Cloudflare’s caching for Set-Cookie responses by using the `Cache-Control: no-cache` header. This will prevent Cloudflare from caching the response, allowing the Set-Cookie header to pass through. However, keep in mind that this will also disable caching for the entire response, which might affect performance.

Can I use Cloudflare Workers to set cookies instead?

Yes, you can use Cloudflare Workers to set cookies instead of relying on the Set-Cookie response header. You can use the `cookies` object in the Worker script to set cookies. This approach gives you more control over how cookies are set and allows you to bypass Cloudflare’s caching restrictions.

Will using `CF-Cache-Status: DYNAMIC` affect my site’s performance?

Using `CF-Cache-Status: DYNAMIC` will prevent Cloudflare from caching the response, which might affect your site’s performance. This is because dynamic content is not cached, resulting in more requests to your origin server. However, the performance impact should be minimal if you’re only using this header for specific Set-Cookie responses.

Are there any other workarounds for Set-Cookie issues on Cloudflare Pages/Workers?

Yes, another workaround is to use a separate domain or subdomain for your cookie-setting endpoint. This way, you can configure Cloudflare to bypass caching for that specific domain or subdomain, allowing the Set-Cookie response to pass through.