3 ms·
It's also the same thing with the "server" header right? Cloudflare will override the server header to their own name. I think this an old thing, not a new feat
by nanankcornering 5y ago
It's also the same thing with the "server" header right? Cloudflare will override the server header to their own name. I think this an old thing, not a new feature introduced recently.
Well, not an issue for me though. Why not use your own headers?
- ezekg 5y agoThanks for the suggestion. And yes, it likely is an old thing. Using my own X-Date header was an option I tossed around, but unfortunately, this issue was not discovered and fully understood until the feature had been out for a couple months. The issue is so infrequent due to the timing/latency involved that most customers didn't realize there was an issue. It was only after a high volume customer pinged me about the occasional (but frequent with high volume) 'invalid' signatures that the issue started to surface. Ultimately, since I have customers relying on the standard Date header within the signed data, and they're in a variety of environments (some not easily updated), I'm unwilling to introduce a breaking change like this simply to keep CF enabled. I ultimately had to disable CF to resolve the issue, and am looking to fully migrate away from the platform soon. Honestly, it just seems like odd behavior for CF to even do this and I thought I'd give others a heads up. I know startups like Cognito [0] follow that signature spec too, so this could effect other startups as well which implement HTTP response signatures. Especially if it eventually becomes standardized... [0]: https://cognitohq.com/docs/authenticating/ https://cognitohq.com/docs/authenticating/