Earlier quoted context omitted.
Yes, unfortunately. I've confirmed it with their support. Requests always hit their CDN. For example, set up a small server that sends the following response headers: Date: Original-Date: Cloudflare will always rewrite the Date header, you just won't notice it until the Date header happens to fall on a time a few ms from the next second (e.g. Wed, 13 Sep 2023 22:02:51.999). This is because by the time Cloudflare proc…
Will your solution work with any CDN at all? It seems the issue is not specific to Cloudflare. `Date` is a registered field [0] used by origin server as defined in RFC 9110 [1]. Any CDN server will add its own date to that header since it's acting as the origin server for that request. For Cloudflare in particular, you could try setting Cache-Control to Private=Date and see if the edge cache skips the override [2]. W…
But per RFC 9110 [^0], "the Date header field represents the date and time at which the message was originated." The message comes from my server, not Cloudflare. If they're getting the message from me, i.e. it's not cached by their CDN, they should leave the Date header alone because the message didn't originate with them. [^1]
Maybe I have a misunderstanding of where Cloudflare sits as the "origin server" when their CDN isn't used for caching (i.e. it's bypassed as much as is allowable). I would think my server is the "origin" and theirs is the "edge."
And unfortunately, workers do not allow you to set the Date header -- Cloudflare support and I already tried that a couple years back (i.e. setting Date = Keygen-Date via a worker).
I will take a look at 2. I doubt that'd work, but it's worth a try.
[^0]: https://www.rfc-editor.org/rfc/rfc9110.html#name-date
[^1]: https://httpwg.org/specs/rfc7230.html#rfc.section.5.7.2